GC20 1801 10_VM370_Sysgen_Rel_6_Jan80 10 VM370 Sysgen Rel 6 Jan80
User Manual: GC20-1801-10_VM370_Sysgen_Rel_6_Jan80
Open the PDF directly: View PDF 
.
Page Count: 522
| Download | |
| Open PDF In Browser | View PDF |
File No. S370-34
Order No. GC20-1801-10
I BM Virtual Machine
Facility/370:
Planning and
System Generation Gu ide
Systems
I
Release 6 PLC 17
This publication is intended for system
programmers responsible for the planning,
installation, and updating of a VM/370 system. It
includes information about:
•
Planning for system generation
•
Defining your VM/370 system
•
Generating VM/370 (CP, CMS, RSCS, and IPCS)
• Generating a 3704/3705 control program that
runs under VM/370
e Updating VM/370
A prerequisite for understanding this publication
is the publication IBM Virtual Machine
Facility /370: In troduction, Order No. GC20-1800.
--.. -------.--- -...--.-.-- .--_.--.. ----
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
This edition
(GC20-1801-10), together with
Technical Newsletters
GN25-0776, dated March 3, 1980; and GN25-0837, dated April 1, 1981,
applies to Re1ea~ 2 PLC 17 (program Level Change) of the IBM Virtual
Machine Faci1ity/370 and to all subsequent releases unless otherwise
indicated in new editions or Technical Newsletters.
Technical changes and additions to text and illustrations are indicated
by a vertical bar to the left of the change.
Changes are periodically made to the information contained herein;
before using this publication in connection with the operation of IB~
systems, consult the IBM ~em/370 Bib1iog~, Order No. GC2D-0001,
for the editions that are applicable and current.
It is possible that this material may contain reference to, or
information about, IBM products (machines and programs), programming, or
services which are not announced in your country. Such references or
information must not be construed to mean that IB~ intends to announce
such IBM products, programming, or services in your country.
publications are not stocked at the address given below;
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 Progra.ming publications, Dept. G60, P.O. Box 6, Endicott, New York,
U.S.A. 13760.
IBM may use or distribute any of the information you
supply in anv way it believes appropriate without incurrinq any
obligation whatever.
You
may, of course, continue
to use the
information you supply.
©
Copyright International Business Machines corporation
1974, 1975, 1976, 1977, 1979, 1980.1981
1972, 1973,
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Preface
This publication is intended for system
programmers and those responsible for the
planning and installation
of a VM/370
system~
It contains
information about
VM/370 and the procedures used to generate
and support a VM/370 system.
"Part 5. Updating VM/370" describes the
procedures, programs, and EXEC procedures
to update VM/370 source code and macro
libraries.
The
about:
appendixes
include
informa ti on
]Qi~:
Use this publication in conjunction
with the "Memo to Users" (second file on
the System Program Update Tape (PUT»
when
you are installinq a system PUT.
You should have a general understanding
of System/370 data processing techniques
with
teleprocessing
and
be
familiar
techniques.
This publication has
appendixes.
five parts,
plus
"Part 1. Planning for System Generation"
describes the components, features,
and
options of VM/370, and tells you what you
must do during system generation to support
them.
Part 1 includes information about
CMS, RSCS, and other operating systems in a
virtual
machine.
It
also
discusses
performance options, remote
3270s, the
3704/3705 control program, saved systems,
discontiguous saved segments, CMS/DOS, VSAM
under CMS,
Access Method Services, the
Attached
Processor
System,
storage
requirements,
and minidisks;
Part 1 also
lists the devices supported by VM/370.
•
Program products,
and emulators
•
Configuring VM/370
•
CMS regeneration requirements
•
Compatible devices
G
Compatibility between VM/370 and CP-67
•
VM/370 restrictions
•
A sample EXEC procedure to
macros into a CMS MAC LIB
processors
copy DOS/VS
An expanded glossary is available in the
IBM Vi!:iual l1~ch!ne Fa£ilitYL~70: 21Q§§9:.!'.!
ang Ma~ter lng~~, Order No. GC20-1813.
In this publication, the following terms
have extended meanings:
•
"Part
2. Defining Your VM/370 System"
tells you how to create the files that
define
your
system;
the
real
I/O
•
configuration (DMKRIO),
CP system control
(DMKSYS), VM/370 directory (D~KDIB), system
name table
(DMKSNT), forms control buffer
•
load
(DMKFCB) files,
and the macros and
control statements needed to create them,
are described.
I
"part
3. Generating VM/370
(CP, CMS, I •
BSCS, and IPCS)" describes the step-by-step
procedure for installing CP,
CMS, and,
•
optionally,
RSCS and IPCS.
The starter
systems for CP and CMS which are 2314,
3330, 3340, 3350, and FB-512 are discussed.
The Installation
Verification Procedure
(IVP) for
CP and CMS is described. Also
•
included is a description of loading and
saving discontiguous saved segments.
"Part
4. Generating
the
3704/3705
Control Program" describes the step-by-step
procedure
for installing
a
3704/3705
control program that runs under VM/370.
language
•
The term "3330 series" refers to the IBM
3330 Disk Storage Modesl 1, 2, and 11;
and the IBM 3333
Disk Storage and
control; Models 1 and 11e
The term "2305 series" refers to the IBM
2305 Disk Storage, ~odels 1 and 2.
The term "3262" refers to the
Printer, Models 1 and 11.
IB M 3262
The term "3289E" refers to the IBM 3289,
Model 4 Printer.
The term "3340 series" refers to the IBM
3340 Disk Storage, Models A2, B1 and B2,
and the 3344 Direct Access Storage Model
B2.
The term "3350 series" refers to the IBM
3350 Direct Access Storage Models A2 and
B2 in native mode.
The term "FB-512" refers to the IBM 3310
and 3370 Direct Access Storage Devices.
Preface
iii
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
•
The term "3705" refers to the IBM 3705-1
and 3705-11 Communications Controllers,
unless otherwise specified.
•
The term
"3270" is
used in
this
publication to refer
to all VM/370
supported
virtual
machine
display
consoles unless otherwise
noted.
A
specific device type is used only when a
distinction is required between device
types.
•
Information about display terminal usage
also applies to the IBM 3138, 3148 and
3158 Display Consoles, when used in
display mode, unless otherwise noted.
•
Any information pertaining to the IBM
3284 or 3286 printer also pertains to
t~c IE~
3287, 3288, a~d 3289 p~inte~s,
unless otherwise noted.
•
The term "typewriter terminal" refers to
printer-keyboard devices that produce
hard-copy output only (such as the IBM
2741 Communication Terminal, the IBM
3215 Console printer-Keyboard, or the
IBM 3767 Communication Terminal, Model 1
or 2, operatinq as a 2741).
•
The term "2741" refers to the IBM 2741
Communication Terminal, and also the
3767
Communication Terminal
(unless
otherwise noted).
•
The term "display device" refers to any
VM/370 supported system console terminal
that displays data on a screen.
•
Unless otherwise noted, where the term
"Attention
key"
is used
in
this
publication,
the
phrase
"(or
equivalent)" is implied.
Th€ equivalent
key on the 1050 terminal is the RESET
LINE key;
on the 3276, 3277, and 3278
terminal, the Enter key.
Each of the
terminals that can be used with the
V~/370
system has a key that is the
equivalent of the Attention key on the
2741
(with which you can signal an
attention interrupt).
block format;
not included.
CMS's VSAM data
sets are
•
Unless stated otherwise,
reference to
the System/370 Models 138 and 148 also
apply
to Models
135-3 and
145-3,
respectively.
•
The term
"3330V" is used
in this
publication for both volumes and device
addresses.
When used with volumes, i t
refers to a Mass Storage System volume
that has been mounted
and that is
directly accessible from the processor.
When used with device addresses, 3330V
refers to a
device
on which 3330V
volumes may be mounted by the
Mass
Storage System.
'hen an installation
h~s
Ppl~R~p
~
installed and an IBM 3850 Mass Storage
System
attached to
the
processor,
references to 3330 can be thought of as
meaning 3330Vs unless the reference is
to VM/370 system residence, paginq or
spooling devices.
COREQUISITE PUBLICATIONS
Syste~ ~~ss~g~§,
Ter!!!i.n~!
Order No. GC20-1808
Order
User's
No.
GC20-1810
Oper~!!ng ~x§!ems in
~ Virt~~l ~~~h!.n~,
Order No. GC20-1821
•
CMS/DOS is part of the CMS system and is
not
a
separate
system.
The
term
"CMS/DOS" is used in this publication as
a concise way of stating that the DOS
simulation mode of CMS is currently
active; that is, that the CMS command
Inte~ac~!~~
set dos on
(IP~~)
has been previously invoked.
•
iv
The phrase "the CMS
file system" refers
to disk
files that
are in
CMS's
800-byte, 1K, 2K, or 4K fixed physical
proble~
Q§g~~§ Q~id~,
]eleas~ ~ guiQ~,
IB~
l11Q
COIDEon§~!
IBM VM370 Planning and System Generation Guide
Con!£Q!
Order No.
§X§!~~
GC20-182~
Order No. GC20-1834
l~fo~~atiQn
Di§pl~~
§y§!~~
Q§§ign, Order No. GA27-2749.
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Contents
The entries in this Table of contents are accumulative. They' list additions
publication by the following VM/370 System Contol Program Products:
•
•
to this
VM/370 Basic System Extensions, Program Number 5748-XX8
VM/370 System Extensions, program Nu mber 57 48-XE 1
However, the text within the publication is not accumulative; it only relates to the one
SCP program product that is installed on your system. Therefore, there may be topics and
references listed in this Table of contents that are not contained in the body of this
publication.
SUMMARY OF AMENDMENTS • • • • • • • • • xvii
PART 1. PLANNING FOR SYSTEM GENERATION •• 1
INTRODUCTION..
• •••••••••• 3
Virtual Machine Operationg Systems • • • • 3
Introduction to VM/370 System Generation .3
PERFORMANCE GUIDELINES • • • • • • • • • • 7
Performance Measurement and Analysis
.7
using the Performance Options • • • • • • • 8
Specifying a virtual=Real Machine..
.9
Reserving DASD Space for a CP Nucleus
with a Virtual=Real Area • • • • • • • 10
Virtual Storage Requirements • • • • • 11
Specifying the Amount of virtual=Real
space • • • • • • • • • • • • •
11
Virtual Machine Assist • • • • • •
• 17
VM/370 Extended Control-Program
Support • • • • • • • • • • • •
• 18
PLANNING CONSIDERATIONS FOR CMS ••
• 19
CMS Storage Requirements •
19
Auxiliary storage ••
19
Device Support • • • •
• 20
CMS Libraries • • • • •
• 21
CMS Command Language
• 22
CMS Program Language Facilities ••
• 23
CMS Text processing Facility ••
• 24
Limited Support of OS and DOS in CMS • • 24
DL/I in the CMS/DOS Environment.
• 25
CMS Disk and File Management •
• 25
Disk Access. • • • •
• •••
• 25
File Sharing • • • • • •
• 26
CMS Disk File Format • •
• 26
Identifying Disk Files •
• 27
C~S Tape Support • • • •
• 27
CMS unit Record Support.
• 28
Card Reader. • • • • •
• 28
Card punch • • • • • •
28
Card Punch (5748-XX8).
28. 1
Card Punch (~148-XEj) ••
28. 1
Printer ••
• 29
Editing • • •
• 29
CMS Batch Facility
• 29
Saving CMS • • • •
• 30
PLANNING CONSIDERATIONS FOR CMS VSAM AND
ACCESS METHOD SERVICES. • • • • •
Hardware Devices Supported • • • • • • •
programming Languages Supported. ••
Data Set CompatibiLity Considerations. •
ISAM Interface Program (lIP) • • • • •
User Requirements and Considerations • •
Distribution of .VSAM and CMS • • • • • •
Planning Considerations for Installing
VSAM Under CMS (~148-!!~) • • • • • • •
Planning Considerations for Installing
VSAM Under CMS (~l.!!~-X~l) • • • • • • •
PLANNING CONSIDERATIONS FOR CMS/DOS • • •
DOS/VS System Generation Considerations.
DOS/VSE System Generation Considerations
(57.!!8-XX~) • • • • • • • • • • • • • • •
DOS/VSE System Generation Considerations
(57.!!8-XEj) • • • • • • • • • • • • • • •
When the DOS/VS System Must Be Online. •
When the DOS/VSE system Must Be Online
(5748-XX~) • • • • • • • • • • • • • • •
When the DOS/VSE System Must Be Online
(5748-XE1) • • • • • • • • •
•
CMS/DOS Tape Handling. • • •
eMS/DOS Tape Handling (574]=!!~)
•
CMS/DOS Tape Handling (57.!!8-!E1)
•
Standard Label Cylinder. • • • • •
Standard Label Cylinder (~148-!!~)
•
Standard Label Cylinder (~l.!!~-X~l)
•
31
31
32
32
32
33
33
33
33
35
35
35
35
35
36
36
36
37
37
36
37
37
PLANNING CONSIDERATION FOR VIRTUAL
MACHINE OPERATING SYSTEMS (OTHER THAN
CMS). • • • • • • • • • • • • • • • • • 39
The VM/VS Handshaking Feature • • • • • • 39
Multiple virtual Machines Using the Same
Operating System. • • • • • • • •
• 40
The RSCS Virtual Machine • • •
• 41
RSCS Planning Considerations
• q1
VM/370 Using Channel Switching •
• 42
Channel-Set Switching Facility
45
Operating Systems Using Reserve/Release. 46
Sha red DASD. • • • • • • • • • • • • .. 47
Virtual Reserve/Release. • • • • • • • 48
VM/370 Control Program Handling of a
Reserve CCW • • • • • • • • • • • • 48.1
Restrictions: Device Sharing Between
Real Processors • • • • • • • • • • 48.3
Contents
vii
Paqe of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Restrictions: Device/Minidisk
Sharing on a sinqle Processor.
Logical Device Support Facility
( 5 7 ~ 8- !X~). • • • • • • • • • •
•
Loqical Device Support Facility
'-2148- XJ;;j). • • • • • • • • • •
•
Virtual Machine Communication Facility
virtual Machine Communication Facility
(.21.!! 8- XX~). • • • • • • • • • • • • •
virtual Machine Communication Facility
(.2748-X]1). • • • • • • • • • • •
Sum mar y 0 f VMCF Fu n ct ion s •
e
•
..
48. 3
48.3
SAVED SYSTEMS. • • • • • • • • • •
DISCONTIGUOUS SAVED SIGMENTS • • •
Using Discontiguous Saved Segments
Special Considerations for using the
Saved Segment CMSZER (57.!!8-!!~)
Special Considerations for Using the
Saved Segment CMSZER (57!8-!J;;1)
48.4
SMALL CP OPTION (.21.!!8-XX8)
48.4
49
DMKAMAC MACLIB
48.3
4 8. 3
•
••••
=
•
Modules Containinq AP Support. • •
•
PLANNING CONSIDERATIONS FOR 3270S.
Remote Attachments. . • • • • • •
•
~270 Support on Binary Synchronous lines
Remote Hardware Confiquration Supported
System Generation Requirements for
Remotely-Attached Display Systems
•
The CLUSTER Macro. • • • • • • •
•
""T.'IT"loMT'l"'"
..... .u.i..'L.l ....
~
"''1a.~
51
51
52
52
53
54
u-. __ _
".lU,-.LV
•••
The RDEVI CE Macro. • • • • • • •
•
The Resource Identification Codes • • •
An Example of a Remote 3270
Configuration • • • • • • • • • • • •
Local Attachments • • • • • • • • • • • •
Local Hardware Confiquration Supported •
Control Units. •
•
Terminals. • • • • • • • • •
•
printers • • • • • • • • • •
•
System Generation Requirements for
Locally-Supported Display Systems
•
54
56
57
59
60
60
61
62
62
GENERATING A VM/370 SYSTEM THAT SUPPORTS'
THE 3704/3705 • • • . •
• • • • • • 63
Coding the RDEVICE Macro
• • • • • • • 63
Special Considerations for Coding the
RDEVICE Macro • •
66
·
Creating an Entry in the System Name
Table • • • • • • •
68
·
Reserving DASD Space for the 3705/3705
Control program Image.
· 68
Alternate Path Support •
68
· · ·
· · ·· ·
· · · · ·
.
··· ·
·· ·
GENERATING A VM/370 SYSTEM THAT SUPPORTS
THE 3800 IMAGE LIBRARY.
• ••••
Codinq the RDEVICE Macro •
•
Hardware supported . • • •
•
Related Publications . • •
•
Creating and Updatinq a 3800 Named
Systeme supported • • • •
•
69
69
70
70
70
3850 MASS STOFAGE SYSTEM •
• 71
Generating a VM/370 System that Supports
a 3850. • • • . • • • • •
• • • • 71
Hardware Supported • • • • • • • • • . 71
Special Considerations for the VS1/VS2
Central Server Virtual Machine.
• 74
Defininq the MSS Communication
Devices • • . • • • • • • • • •
74. 1
The Mass Storaqe Control Tables • • • 74.1
Creatinq MSS Volumes. • • • • •
• 75
Copyinq 3330-1 Volumes to 3330V
Volumes • • • • • • • • •
• 76
Usinq 3330V Volumes for 1S System
Residence • . • •
• 76
The VM/3 7 0 F DE VICE Ma cr 0 • • • • • • • 7 6
viii
• 84
• 84
• • 84
ATTACHED PROCESSOR SYSTEMS •
=
79
· 81
82
• 85
85
• 85
ESTIMATING VM/370 STORAGE REQUIREMENTS • 87
Real Storage Requirements for CP • • • • 87
Reducing the Size of the CP Nucleus. • • 89
Direct Access Storage Requirements for
CPo • • • • • • • • • • • • •
• 90
CP Nucleus DASD Requirements
• 90
,...........
,,..~
_.
T"I>. . . . . . . ""'"
'r""'I
~r
uu~~cu~
Ufi~U
DCyU~LCWCU~~
_"
_~
..
,
_
(~748-!X8).
• • • • • • • • •
• 90.2
CP Nucleus DASD Requirements
(.2 748- X]1). • . • • • • • • •
90 • 2
Error Recordinq DASD Requirements • • • 91
Warm Start Data DASD Requirements • • • 91
Checkpoint Start Data DASD
Requirements • • • • • • • • • • • • • 91
VM/370 Directory DASD Requirements • • 91
Saved System DASD Requirements • • • • 91
Paging and Spooling DASD Requirements. 91
VSAM and Access Method Services
Requirements. • • • • • • • • •
• 92
IPCS Requirements. • • • • • • • •
• 92
External Storage • • • •
• • • • • 92
Real Storaqe • • • • • • • • • •
• 93
Estimating DASD Storage Requirements for
CMS Minidisks
•• • • • • • •
• 93
MINIDISKS. • • •
• •••
• 95
Defining Minidisks • •
• •••
• 95
Minidisks Space Allocation •
• 97
Track Charactristics • • • • • • •
• 98
Al ter na te Tracks • • • • • • • • •
• 98
Alternate Tracks/Blocks (.21!~=!!~)
• 98
Alternate Tracks/Blocks (.21!~=!~1)
• 98
3330/3350 Disks • • • • •
• 98
3340 Disks • • • • • • •
• 98
2314/2319 Disks • • • • • •
• 100
FB-512 Disks (57~~=!X~).
• • • 100
• • 100
FB-512 Disks (~l~~-X~l).
Labels • • • • • •
• • • • •
.100
• • • 101
Labels (.21~~=!X~). • • • •
Labels (.21.!!8-X]1).
• • • 101
Sharing Minidisks • • • • •
• 101
CONFIGURATIONS
•••••
VM/370 Minimum Configuration •
Configurations Supported by CMS • •
Configurations Supported by RSCS •
Devices Supported by VM/370 • • • •
Processors • • • • • • • • • • • •
Processor Required Features and
Facilities • • • • • • • • • •
Desirable Features • • • • •
Direct Access storage Devices.
Magnetic Tapes • • • • • • • •
IBM VM/370 ?lap-nning and System Generation Guide
• • • 103
• • • 103
• • • 104
.104
.105
• 106
• 106
· . • 107
• 10 9
• 110
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
unit Record Devices • • •
• 111
Terminals. • • • • • . •
• • • • • • 112
Special Considerations and Required
Features • • • • • • • •
• 113
'!'ransmission Control Units • • • • • • .120
2701 Fequired Features • • • • • • • • 120
2702 Required and Optional Features. • 121
2703 Required and Optional Features. • 121
IBM Integrated Communications
Attachment (ICA) Required and
Optional Features • • • • • •
• 122
3704/3705 Pequired Features • •
.123
Remote spooling Devices Supported by
VM/370 • • • • • • • • • • • • • •
.123
Remote Spooling Communications
Subsystew (R SCS) •
•• • • •
• 123
other Considerations for Planning Your
Confiquration • . •
• • • . • • • • 126
Two-Channel Switch
• • . • • • • • 126
Devices Used only by an Operating
System in a virtual Machine and Not
by VM/370 • . • • • • • • • • •
.126
Service Record File. • • • • • • •
.126
Multiple Service Pecord Files. •
.127
PART 2. DEFINING YOUB VM/370 SYSTEM • • • 129
INTRODUCTION .
. .
PREPARING THE REAL I/O CONFIGURATION
FILE (DMKRIO) . •
• •••••
Coding the Real I/O Configuration
Marcos for Remote 3270s •
• •••
CLUSTER Marco.
TERMINAL Marco • .
RDEVICE Marco
RCTLUNIT Marco
RCHA NNEL Marco
RIOGEN Marco •
Example of Coding the Real I/O
Configuration File (DMKRIO) ..
• 131
• 133
.134
.135
.137
• 142
• 151
• 155
.155
.158
PREPARING THE CP SYSTEM CONTROL FILE
(D!1KSYS). • • • • • • • •
• • • • • 163
Performance Considerations for Coding
the DMKSY S File Macros. • • • • • • • • 164
Performance Considerations for Coding"
the (D!1KSYS) File Macros (j148.::XX32) • • 165
Performance Considerations for Coding
the (DMKSYS) File Macros (2748.::XE1) • • 165
SYSOWN Macro .
.166
SYSRES Macro •
• 168
SYSOPR Macro •
• 173
SYSCOR Macro •
.174
S YSTIL1E Macro.
.176
SYSMON Macro.
• 178
SYSJRL Macro •
• 181
SYSACNT Macro (27432-XX~)
• 182
• • • • • 182
SYSACNT Macro (21~8-!]1)
SYSLOCS Macro • . • • • •
• 182
• • • .182. 1
SYSLOCS Macro (2748-Xl~)
SYSLOCS Macro (21~8-XE1) • • • • • • • 182.1
CREATING YOUR VM/370 DIRECTORY
Considerations for Preparing the
Directory Control Statements. • •
System Support virtual Machines.
Sample Directory EntrieS. • • • •
.183
.183
.184
.185
The System Operator's virtual Machine
(OPERATOR). • • • • • • • • • • • • • .185
A Virtual Machine to Receive System
Dumps (OPERATNS) • • • • • • • • •
.186
A virtual Machine for Updating and
Supp orting VM/370 (VMSY S) • • • •
.186
A Hardware Service Virtual Machine
(SERV) • • • • • • • • • • • • • •
.187
The VM/370 Directory Supplied with the
Starter System. • • • • • • •
.187
2314 Starter System Supplied
Directory • • • • • • • • • • •
.188
3330 Starter System Supplied
Directory • • • • • • • • • • •
.190
3340 Starter System Supplied
Directory • • • . • • • • • • •
.192
3350 Starter System Supplied
Directory .
.. 194
FB-512 Starter System Supplied
Directory C2]!!32=XX32). • • • •
• .196
FB-512 Starter System Supplied
Directory (57 4 8=X~). • • • •
• • 196
Allocating DASD Space for the VM/370
Directory • • • • • • • • • • • • • • 196
Allocating DASD Space for the VM/370
Directory (2148=!X8) • • • • • _ • • 196.2
Allocating DASD Space for the VM/370
Di rect ory (21!! 8- X].1). • • • • • • • 196. 2
The Direct ory Program. • • • • • •
• 197
Invoking the Directory Program
(DMKDIR) Uncer eMS. • • • • • •
.198
Invoking Directory as a Standalone
Program. • • • • • • • • • • •
.199
Directory Control Statements • • • • • 200
Directory Entries for CMS/DOS • • • • • 215
PREPARING THE SYSTEM NAME TABLE FILE
(DMK SNT) •
· ·
coding the NAMESYS Macro
Coding the NAMESYS Macro (2148-!!~) •
Coding the NAMESYS Macro <'2148-!~1) •
..
Coding the NAMENCP Macro
Coding the NAMENCP Macro (57!!32=XX32)·
Coding the NAMENCP Macro (214 8- !~.1) •
.
Coding the NAME3800 Macro.
... .
.217
· ·
· · · .220
· · · · · · ·.220.4
· · · · ·
··
.220.4
.. .. 222
.222.1
.222.1
.223
· ··
ALTERING THE FORMS CONTROL BUFFER LOAD
(DMK FCB). •
• • • •
• • • • • 224
PART 3. GENERATING VM/370
RSCS, AND IPCS)
(CP, CMS,
.225
INTRODUCTION. •
General Information. •
.227
.228
GENERATING CP AND CMS USING THE STARTER
SYSTEMS. • • • • • • • • • • •
.229
Step 1. Load the Format Program from
the Starter System Tape • • • • • • • • 229
Step 2. Format, Label, and Allocate
the system Residence Volume • • • • • • 229
Step 3. Label the Starter System
Volume • • • • • • • • • • • • • • • • • 231
Step 4. Load the DASD Dump Restore
Program from the Starter System Tape • • 231
Step 5. Restore the Starter System to
Disk. •
• • • • • • • •
.231
Step 6. IPL the Starter System • • • • • 236
Contents
i x
Paqe of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
step 6. IPL the starter System
(21.!! 82 36. 1
Step 6. IPL the starter System
(5748-X]1) •
• • • • • • • • • • .236.1
Step 7. Define the Devices Needed to
Do the system Generation • • • • • • • • 236
Step 7. Define the Devices Needed to
Do the System Generation (2748-X!~) .236.1
Step 7. Define the Devices Needed to
Do the system Generation (2748-X~1) .236.1
Step 8. Set the Terminal Mode and
Spool the Console • • • • • • • • • • • 238
Step 9. Define or Attach the System
Residence Device • • • • • • • • • • • • 238
Step 10. Make Other Devices Aavailable .239
Step 11. Load CMS • • • • • • • • • • • • 240
Step 12. Define and Format a Temporary
Minidisk • • • • • • • • • • • • • • • • 240
Step 12A. Install the System Extensions
Base Tape (2148-Xn). • • • • • •
.241
Step 13. Applv the Control Proqram
Service. • • • • • • • • • • • •
.241
Step 13. Apply the Control Program
Service (~1~~=.x~1). • • • • • • •
.242
Step 14. Punch the Service Programs • • • 242
Step 14. prepare the Service Programs
(.2748-XX~) • • • • • • • • • • • • • • • 242
Step 14. prepare the Service programs
(5748-XE1). • • • • • • • • • • • • .242. 1
Step 15. Print and Punch the Starter
System Supplied Directory, DMKSNT,
DMKSYS, and
DMKFCB.. • • • • • • • .243
Step 16. Build the VH/370 Directory and
Assemble the Files Defining the Real
I/O and System Devices • • • • • • • • • 244
Step 16. Build the VM/370 Directory and
Assemble the Files Defininq the Real
I/O and System Devices
(.214 8=XX§). • • • • • • • • • • • .244. 1
Step 16. Build the VM/370 Directory and
Assemble the Files Defining the Real
I/O and System Devices
(5748-Xl!1) • • • • • • • • • • • • • 244.1
Format of the READ Control Statement .245
Special Procedure If You Are Using
Only One Tape Drive • • • • • • • • • 245
Invoke the GENERATE EXEC Procedure • • 246
Invoke the GENERBSE EXEC Procedure
(274!!=XX~). • • • • • • • • • • • • .246
Invoke the GENERSEP EXEC Procedure
(j74!!=I{JH). • • • • • • • • • • • • .246
Step 17. Attached Processor Support and
Virtual=Real Machines • • • • • • • • • 246
Step 17. Attached Processor Support and
Virtual=Real Machines (~146-XX]) • •• 246.1
Step 17. Attached Processor Support and
virtual=Real Machines (.274§-XE1) • • • 246.1
Step 18. Load the CP Nucleus. • •
.247
Loading a CP Nucleus without a
virt ual =Real Area • • • • • • •
.248
Loading a CP Nucleus that Has a
virt ual =Real Area • • • • • • •
.249
Examine the CP Load Map. • • • •
.249
Step 19. IPL the NeWly Generated VM/370.250
Step 20. Back up the Newly Generated
VM/370. • • • •
• • • • • • • 254
Step 20. Back up the Newly Generated
VM/370 (21~H~=.!X!!) •
.254. 1
xx.m •
x
• • • • • • • • • • •
Step 20. Back up the Newly Generated
VM/370 (5748=!~1) • • • • • • • • • • 254.1
Step 21. Format the Operator's Virtual
191 Disk • • • • • • • • • • • • •
.255
Step 22. Format the MAINT User's
Virtual 191 Disk • • • • • •
.256
Step 22A. Translate the HELP files
to Uppercase (574~=XX8) • • • • • • • • 256
Step 22A. Translate the HELP files
to Uppercase (.274~=XE1) • •
.256
Step 23. complete the Application of
Service • • • • • • • • • • • • •
.256
Step 24. Save CMS. • • • • • •
.258
Generating the CMMSEG Segment
.258
Generating the CMSZER Segment
(5748- XX]) • • • • • • • • •
• .258.1
Generating the CMSZER Segment
(5748-Xn) • • • • •
• • • • • • 258.1
Saving the CMS System
• • • •
.259
Step 25. Obtaining the MSS
Communicator Program.
.260
OS/VS1 Jobs. • • • • • • • • • •
.260
OS/VS2 Jobs. • • • •
.261
VERIFYING CP AND CMS USING THE IVP • • • 263
Facilities Required for Each IVP
Virtual Machine • • • • • • •
.263
Starting the IVP • • • • • • •
.264
Variations of the IVP • • • • •
• • • 265
Interpreting the Test Results • • •
.266
LOADING AND SAVING DISCONTIGUOUS SAVED
SEGMENTS. • • • •
• •••
.267
Loading and Saving the CMS/DOS Segment
Called INSTVSAM • • • • • • •
.269
Loading and Saving the CMS/DOS Segment
.271
Called INSTVSAM (.2148-XX8) • •
Loading and Savinq the CMS/DOS Segment
Called INSTVSAM (.2748-XE1). •
• • • 271
Loading and Saving the CMSVSAM and
CMSAMS Segments. • • • • • •
.271
Installing CMSVSAM and Access Method
Serv ices (57! 8- XXJH • • • • • • • • • • 273
Installing CMSVSAM and Access Method
Services (57!8-!!.§) • • • • • • • • • • 273
Loading and Saving the CMS/DOS Segment
Called CMSDOS • • • • • • • • • •
.276
····
····
····
GENERATING AND INSTALLING RSCS • •
.279
General Information. • • •
.279
Defining Your RSCS Virtual Machine • • • 280
Defining Your RSCS System. •
• • • 280
Creating the AXSLINKS COPY FILE.
.280
Creating the LAXLINES COPY FILE • • • • 282
Creating the TAGQUEUE COPY FILE.
.282
Generation Procedure for RSCS • • • • • • 282
Step 1. Logon as MAINT and 1PL CMS • • 283
Step 2. Apply the RSCS Updates from
the VM/370 Program Update Tape • • • • 283
Step 3. Format the RSCS System Disk • • 283
Step 4. Create the COpy Files that
Define Your RSCS System • • • • • • • 284
Step 5. Create the DMTLOC Macro
Library • • • • • • • • • • • • • • • 285
Step 6. Assemble the Configuration
Table (DMTSYS). • • • • • • • • • • .285
Step 7. Invoke GENERATE to Create the
RSCS Nucleus • • • • • • • • • • • • • 286
IBM VM/370 Plannning and System Generation Guide
Page of
GC20-1~01-10
.287
.287
.287
INTRODUCTION. • • • • • • • • • •
Deciding Which Procedure to Use. •
.287
A VIRTUAL MACHINE FOR UPDATING VM/370 • • 323
Accessing Disks. • • • •
.326
.288
FILES FOR SYSTEM UPDATES • •
.327
SYSTEM PROGRAM UPDATE TAPE (PUT)
.331
RECOMMENDED PROCEDURES FOR UPDATING
VM/370. • • • • • • • • •
VM/370 Integrity • • • • • • • • • • •
Control File preparation • • • • • • •
Example of a CP Update
•• • • • •
Using VMFASM To Update Source Files ••
Using VMFMAC to Update Macro Libraries
Using VMFLOAD to Punch a New Nucleus •
.333
.333
.334
• 335
.335
.337
.340
BUILDING A NEW CP NUCLEUS.
.345
GENERATING AND INSTALLING IPCS •
Generation Procedure for IPCS. •
Step 1. Logon as MAINT and IPt CMS •
Step 2. Format the IPCS Virtual
Machine 191 Disk. • • • • • •
Step 3. Apply the IPCS Updated Files
from the PUT. •
••• • •
PART 4. GENERATING THE 3704/3705
CONTROL PROGRAM • • • • • •
.289
INTRODUCTION TO THE IBM 3704 and 3705
COMMUNICATIONS CONTROLLERS. • • •
PLANNING CONSIDERATIONS FOR THE
3704/3705 CONTROL PROGRAM • • • •
Related Publications • • • • • • •
3704 adn 3705 Support package. • •
VM/370 support oftne 3704 and 3705
Emulation Program (EP) withVM/370 •
• 291
.293
• 293
.293
.294
•
•
•
•
•
•
•
.319
.319
• 294
GENERATING AND LOADING THE 3704/3705
CONTROL PROGRAM • • • • • • • • • • • • 297
Step 1. Log on the VM/370 System • • • • 297
Step 2. Set Up a CMS virtual Machine • • 297
Step 3. Load the IBM 3704/3705 Control
Program Distribution Tape File onto a
CMS Disk • • •
.298
Step 4. Code the 3704/3705 Control
Program Macro Instructions • • • • • • • 300
BUILD Macro Instruction • • • • • • • • 301
GROUP and LINE Macro Instructions • • • 301
GENEND Macro Instructions • • • • • • • 302
Special Macro Coding Considerations
for the Emulation program (EP).
.302
Step 5. Define the Macro and Text
Libraries. • • • • • • • • • • •
.302
Step 6. The stage 1 Generation
Proced ure • • • • • • •
• 303
The AS M3 7 05 Comm and. • • • •
• 303
Special Considerations for the Stage
1 Assembly. • • • • • • • •
.305
Step 7. The stage 2 Generation
Procedure . . . . . . _ = =
e305
The GEN3705 Command. • • • •
.306
Special Considerations for the Stage
2 Generation Procedure. • • •
.307
step 8. Invoke the EXEC Procedure
Created in step 7 • • • • • • • •
.307
The LKED Command. • • • • • • •
.308
step 9. Save the 3704/3705 Control
program Image on Disk • • • • • •
.310
The SAVECP Command. • • • • • •
.311
Execution of the SAVENCP Program • • • 312
Step 10. Load the 3704/3705 Control
Program • • • • • • • • • • • • • • • • 312
The NETWORK LOAD Command Line • • • • • 312
Execution of the NETWORK LOAD Command.313
Special Considerations for Loading
the EP 3~04/3705 control Program • • • 313
Step 11. Logging on Throuqh the
3704/3705 • • • • • • • • • • • • • • • 314
Turn the Power On. • • • • • • • • • • 314
Check for an Online Message • • • • • • 314
Step 12. Applying PTFs to the 3704/3705
10 a d Li br a r y • • • • • • • • • • • • • • 3 1 5
Testing the 3704/3705 Control Program • • 315
0
As Updated April 1, 1981 by TNL GN25-0837
••
PART 5. UPDATING VM/370 • • • • • • • • • 317
UPDATING CMS • • • • •
.349
Disks for Updating CMS
••••
.349
Formatting a Disk To Test the CMS
Nucleus. • •
• • • • • • • • • 350
Considerations for Creating a New CMS
System Disk. • • • • • • • • •
.350
Punching the CMS Nucleus. • • • •
.350
Creating CMS Disk-Resident Modules
.351
Loading a CMS Nucleus. • • • • • •
.352
Saving CMSSEG and the eMS System •
.356
Saving CMSSEG, CMSZER, and the CMS
System (5748=!X.§) • • • • • •
.356
Saving CMSSEG, CMSZER, and the CMS
System (5148=!~1) • • • • • •
.356
Update Procedures for CMS TSAM and
Access Method Services. • • •
.357
VSAMGEN Update Considerations..
.357
VSAMPP Update Considerations
(,2148-XX8). • • • • • • • • • •
.357
VSAMPP Update Considerations
(,2748-XE1) • • • • • ,. • • • • •
.357
Applying PTFS to the VSAM and Basic
Access Method Shared Segments
(,2748-XX8) • • • • • • • • • • • • • • 358
Applying PTFS to the VSAM and Basic
Access Method Shared Segments
(,2 748- XE1). • • • • • • • • • • • • • 358
Using VSAMGEN To Update CMS VSAM and
Access Method Services • • • • • • • • 358
Updating Considerations for CMS/DOS • • • 361
UPDATING RSCS. • • • • • • •
Creating an RSCS System Disk
Generating the RSCS Nucleus. •
.363
.363
.363
UPDATING IPCS MODULES. • •
.367
UPDATING SERVICE PROGRAMS.
.369
UPDATING THE LOADER PROGRAM • •
The Load Map
•••••
Generating a New Loader. •
.371
• 372
.372
EXEC PROCEDURE AND COMMAND FORMAT
SUMMARIES
ASMGEND. •
CMSGEND. •
.375
.376
.377
contents
xi
Paqe of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
BSEGEND (~1~~-X1~) •
• •
BSEGEND (~1~8-1]1) • •
GENERATE. • • • • •
GENERBSE (~148-11~).
GENERSEP (21~~=1]1) • • • •
• •
PRELOAD (21~~-X1~) • • • •
PRELOAD (21~~=1]1)
VSFASM • • • • • •
VMFASM (57~~=!1~).
VMFASM (57.!!~=!]1) • • • • • • • • •
VMFDOS (57~8-!X~).
VMFDOS (57~8-!]1).
VMFLOAD. • • • • •
•
CP Loadlist Requirements
VMFMAC • • • • • • •
VMSE RV • • • • • • • • • •
How VMS ERV Works. • • •
Initialization Messaqes
Service Application Messages
Return Codes from Service EXECS.
.377
• • • 377
.380
.380
.380
• • .384
• 384
.384
• • 384.3
• .384. 3
.386.1
.386.1
.387
.390
.391
.394
.395
.395
.397
.398
APPENDIX G: A SAMPLE EXEC PROCEDURE FOR
COPYING DOS/VSE MACROS INTO A CMS
(2748-XEj). • • • • • • • • • • •
.443
Creating the DOSMAC EXEC Procedure
.444
APPENDIX H: INSTALLING VM/370 BASIC
SYSTEM EXTENSIONS PROGRAM PRODUCT -AN ALTERNATE METHOD (2748=XX~) • • • • 446.1
Step 1: Load the Format Program from
the Starter System Tape (~748-!!~) • • 446.1
Step 2: Label the Starter System
Volume (5748=!!~) • • • • • • • • • • 446.1
Step 3: Load the DASD Dump Restore
Program from the Starter System Tape
(574 8-XX~). • • • • • • • • • • • • .446.2
Step 4: Restore the Release 6 Starter
Sys tem to Disk (~1.!! 8- XX8) • • • • • .446.2
-tep 5: IPL the Release 6 Starter
System (2748=!!~) • • • • • • • • • • 446.6
~+O"
-
APPENDIXES • •
• 399
APPENDIX A: PROGRAM PRODUCTS, INSTALLED
USER PROGRAMS, FIELD DEVELOPED,
PROGRAMS AND EMULATORS. •
.401
VM/3 70 Assembler • • • •
.401
Proqram Products • • • •
.401
Installed User Programs.
.403
Field Developed Proqram3 •
.403
Inteqrated Emu lators • •
.404
APPENDIX B: CONFIGURATION AID.
.405
APPENDIX C: CP/CMS
NUCLEUS/MODULE/SEGMENT REGENERATION
REQUIREMENTS. • • • • • • • • • •
The DOSGEN • • • • • • • • •
.409
.411
APPENDIX 0: COMPATIBLE DEVICES
.413
APPENDIX E: COMPATIBILITY OF VM/370
WITH CP-67/CMS. • • • • • • • • •
VM/370 CMS Support of CP-67/CMS
Commands. • • • • • • • • • •
CP-67/CMS Macros and Functions and
Correspondinq CMS Macros. • • • •
.415
.421
.429
APPENDIX F: VM/370 RESTRICTIONS. •
.431
Dynamically Modified Channel Programs • • 431
Minidisk Restrictions. • • • • • • • • • 432
T imin q Dependencies. • • • • • • • • • .433
Processor Model-Dependent Functions • • • 434
Channel Model-Dependent Functions.
.434
Channel Model-Dependent Functions
<..214 8- !X~). • • • • • • • • • • • • • 434. 1
Channel Model-Dependent Functions
(21.!! 8- XJH). • . • • • • • • • • • • • 4 3 4. 1
Virt ual Mach ine Characteristics. •
.435
MSS Restrictions. • • • •
.438
CMS Restrictions. • • • • • • • •
.438
Miscellaneous Restrictions. • • •
.440
APPENDIX G: A SAMPLE EXEC PROCEDURE FOR
COPYING DOS/VS MACROS INTO A CMS
MACLIB • • • • • • • • • • • • • • • • • 443
APPENDIX G: A SAMPLE EXEC PROCEDURE FOR
COPYING DOS/VSE MACROS INTO A CMS
(57 ~8-X!ln. • . • • • • • • • • • • • .443
xii
-
-
&:
~.
-..
no¥4no
-- ...
-~
+~o
............ -
no~~~o~
-
-
> - - -- .... -
»~D~O~
.. ,
-
"- '-'- -
......
."
'-" ....
do the System Generation (5748=!!~) .446.7
Step 7: Set the Terminal Mode and
Spool the Console (~148-1X~) • • • • • 446.9
Step 8: Make Other Devices Available
( 574 8- XX~). • • • • • • • • • • • • • 446. 9
Step 9: Load CMS (2148-XX~). • •
446.10
Step 10: Load the Basic System
Extensions Program Product Base
Tape (CP Part) (214 8- X!~) • • • • • 446. 10
Step 11: Prepare to Load CMS Basic
System Extensions Program product
Part (5748-!!~) • • • • • • • • • • 446.11
Step 12: Load the Basic System
Extensions Program Product Base
Tape (CMS Part) (5748-XX8) • • • • • 446.11
Step 13: Build the Scratch Tape
(5748-XX~). • • • • • • • • •
• 446.12
Step 14: Continue to Build the
Scratch Tape (~74~=lX8) • • •
• 446.12
Step 15: Prepare Your CP Basic
System Extensions Program Product
Nucleus (57.!!~=!!.!n. • • • • • • • • 446.11
Step 16: Create Your CP Basic System
Extensions Program Product Nucleus
(5748-XX~) • • • • • • • • • • • • • 446.15
Step 17: Create Your CMS Basic
System Extensions Program Product
Nucleus (574~=!!~). • • • • • • -. • 446. 15
Step 18: Read in the New CMS Basic
System Extensions Program Product
Modules (57.!!~=XX~) • • • • • • • • • 446.16
Step 19: Make Devices Available on
Your Computer (21~8-X!~) • • • • • • 446.16
Step 20: Load the Format Program
from the Tape (21.!!'§=XX~) • • • • • • 446.16
Step 21: Write Your Starter System
Directory (~l.!!]=X!~) • • • • • • • • 446.17
Step 22: Write the CP Basic System
Extensions Program Product Nucleus
on CPB2LO Disk (2148-!X8) • • • • • 446.18
Step 23: IPL the CP Basic System
Extensions Program Product System
(57.!!8-XX~) • • • • • • • • • • • • • 446.18
Step 24: Make Tape 280 Available and
IPL it (2748=!X~).
• • • • • • 446.20
Step 25: Format Your CMS System on
CPB2LO (274~=!!~)
446.20
IBM VM/370 Plannning and System Generation Guide
8
• • • • • •
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
step 26: Fill in the CMS Basic
System Extensions Program Product
System Disk (5748-XX~) • • • • • • •
Step 27: Fill in the 191 CPGEN
~inidisk (21~8-!1~) • • • • • • • •
step 28: Fill in the CP Basic System
Extensions Program Product Staging
Area (574~=!X~) • • • • • • • • • •
Step 29: write the CMS Basic System
Extensions Program Product Nucleus
(~748-!X§).
_ •••••••••
Step 30: IPL the Tape (5748=XX8) • •
446.21
446.22
446.22
446.23
446.23
Step 31: Mount the Basic System
Extensions Base Tape (574]=!!~) • •
Step 32: Regen the Assembler
(57!8-XX]) • • • • • • • • • • • • •
Step 33: Load New Macro Supported by
Basic System Extensio (57~~=!!~) • •
Step 34: Load the IPCS and the Help
Files (~748-!!~) • • • • • • • • • •
Step 35: Backup Your Basic System
Extensions Starter System
(5748-XX~) •
•
INDEX • • • • • • • • • • •
446.24
446.24
446.24
446.25
446.25
• • • • 447
contents
xiii
April 1, 1981
xiv
IBM VM/37Q Plannning and system Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0831
Summary of Amendments
for GC20-1801-10
as updated by GN25-0831
For Release 6 PLC 11
MISCELLANEOUS
Chanqg~:
Documentation Only
This Technical Newsletter incorporates
minor technical and editorial change.
Summary of Amendments
xvii
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Summary of Amendments
for GC20-1801-10
as updated by GN25-0776
For Release 6 PLe 9
IBM 3101 DISPLAY TERMINAL
Ne~:
Hardware Support
VM/370 now supports the IBM 3101 Display
Terminal.
For programming systems which
support
Teletype
Model
ASR
33/35
teletypewriter,
the
3101
can
be
supported as a substitute device.
xviii
IBM VM370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Summary of Amendments
for GC20-1801-10
VM/370 Release 6 PLC 4
MISCELLANEOUS
3704/3705 CONTROL PROGRAM
Ch~:!lg~g
:
Document ation
and
Program
Changed: Documentation
Support
Technical changes have been made to more
adequately reflect the 3704/3705 Control
Program support offered by VM/370.
The
generation procedure for loading the
3704/3705 controllers has
also been
updated to include
the INSTEP EXEC
procedure.
!his procedure is used to
generate the
3705 Assemtler and create
the necessary macro and text libraries
needed to generate the 3704/3705 Control
program.
For more information see Part
Four.
"Generating the 3704/3705 Control
Program. "
various technical and editorial updates
have
been
made
throughout
this
publication to reflect the current level
of the VM/370 System Control Proqram~
SYSTEM PROGRAM UPDATE TAPE
~h~Qg~g:
program Support
VM/370 service update tapes are now
distributed as system Program Update
Tapes.
The system PUT is distributed
regularly by
IBM so that
you may
maintain the current service level.
The
system generation procedure has been
updated to include this new support.
Additionally, the VMSERV EXEC procedure
is included on the PUT to direct the
installation of service.
See Part Five.
"Upda tinq VM/370" for more information.
Summary of Amendments
xi x
Apr i 1 1, 1 98 1
xx
IB~
V~/370
Planning and System Generation Guide
Part 1. Planning for System Generation
Part
contains planning information.
It describes the various
components, options, and features of V~/370 and tells you what you must
do to install them. Part 1 contains the following sections:
•
Introduction
•
Performance Guidelines
•
Planning Considerations for eMS
•
Planning Considerations for
Met hod Services
•
Planning Considerations for CMS/DOS
•
Planning Considerations for Virtual Machine
Operating Systems (Other than CMS)
•
Planning Considerations for 3270s
•
Generating a VM/370 System that Supports the 3704/3705
•
Generating a VM/370 System that Supports the 3800 Image Library
•
3850 Mass Storage System
•
Saved Systems
•
Discontiguous Saved Segments
•
Attached Processor Systems
•
Estimating VM/370 Storage Requirements
,
Minidisks
•
Configurations
C~S
VSAM and Access
Part 1. Planning for System Generation
2
IBM VM/370 Planning and System Generation Guide
Introduction
The IBM Virtual Machine Facility/370 is a System Control Program (SCP)
that manages a real computing system so that all its resources -- ma1n
processor, attached processor, storage, and input/output devices -- are
available to many users at the same timee Each user has at his disposal
the functional equivalent of a real, dedicated computing system.
Because this functional equivalent is simulated
by VM/370 and does not
really exist, it is called a "virtual" machine.
The processors that VM/370 supports are listed under the
"Processors" later in Part 1. The real System/370 must have the
Address Translation feature, a hardware facility that translates
storage addresses to real storage addresses, and the System
facility.
Also, it must operate in extended control mode, a
which all the features of a System/370, including dynamic
translation, are operational.
heading
Dynamic
virtual
Timing
mode in
address
VM/370 has four components:
•
The control program (CP), which controls the resources of
computer to provide multiple virtual machines.
•
The Conversational Monitor System (CMS), which provides a wide range
of conversational and time-sharing facilities.
Using CMS,
you can
create and manage files,
and compile, test, and execute problem
programs.
•
The Remote Spooling Communications SUbsystem (RSCS), which transfers
spool files
between VM/370 users
and remote
locations over
telecommunication lines.
•
The Interactive Problem Control System
(IPCS), which provides VM/370
problem analysis and management facilities, including problem report
creation, problem tracking, and CP abend dump analysis.
For an overview of the
In.iIQdu£iio1!.
functions performed
by VM/370, see
the real
the
!ML31Q
Virtual Machine Operating Systems
While the control program of VM/370 manages the concurrent execution of
the virtual machines,
it is also necessary to have an operating system
managing the work flow within each virtual machine.
Because each
virtual machine executes independently of other virtual machines, each
one may use a different operating system, or different releases of the
same operating system.
Part 1. Planning for System Generation
3
Introduction
The operating systems that can run in virtual machines are:
,-I
Batch or
l~ing!~_Us~~_l~te£~ctiv~
,
DOS
I
DOS/VS
lOS/PCP
,
OS/MFT
I
OS/MVT
,
OS/VS1
I
OS/VS2
lOS-ASP
I
RSCS
l1yltiple=!££g,§,§
VM/370
Time Sharing
Option of as
~Qnve~~iQn~!
CMS
L-
~~ provides
each o~ these with virtual device support and virtual
storage. The operating systems themselves execute as though they were
controlling real devices and real storage, but they must not violate any
of the restrictions listed in "Appendix F: VM/370 Restrictions."
Introduction to VM/370 System Generation
The purpose of the system generation is
your installation's particular needs.
to create a system
that meets
The first step in the system generation procedure is to restore the
starter system, a small working copy of a basic VM/370 system. Using
the starter system, you tailor a VM/370 system to your own hardware
configuration. You also describe your DASD volumes and define how they
are to be used.
The following versions of the starter system can be ordered:
•
2314 Starter System
•
•
3330 Starter System
•
3350 Starter System
3340 Starter System
All starter systems must be restored to a compatible disk (that is, 2314
starter system to a 2314 disk), but all starter systems can then be used
to build any supported system residence volume type
(2314, 3330, 3340,
or 3350).
Before you begin the system generation procedure, you should:
•
Know which devices to include in your VM/370 system.
•
Create the real I/O configuration (DMKRIO) file describing your I/O
configuration. If an IBM Mass Storage System is to be attached to
VM/3 7 0, you must coordinate the real I/O configuration with the Mass
Storage Control's tables.
4
IBM VM/370 Planning and System Generation Guide
Introduction
•
Decide how many virtual machines to define.
•
Create the VM/370 directory
virtual machines.
•
Decide which volumes are to be owned and used by
residence, paging, spooling, and so on), the amount
available to VM/370, and the user identification of
operator.
•
Create the CP system control
(DMKSYS)
file
volumes, the real storage size, and so on.
•
If you wish, you can create your own forms control buffer (module
DMKFCB) and system name table
(module DMKSNT). These modules are,
however, supplied with the starter system.
control statement
file describing
the
CP (for system
of real storag e
the real system
describing
CP-owned
Once you have defined your VM/370 system with these files,
you can
begin the system generation procedure. You should read the rest of Part
1 to be sure
you have all the information you need to generate your
system.
Part 2 has the information you need to code the files that
define your system. Part 3 describes the system generation procedure
step-by-step.
Before you start the system generation procedure be sure
you have the following manuals available:
VM/37Q
Q~~to~§ Guig~.
VM/3 7 Q
~I.§i.§.m Me§.§~~.§
VM/31Q
]~1.§~.§~
§ Qyid~
If you are using the MSS support, you will also need the following:
OS/VS
Creai~,
~~§§ ~tor~g~
~Y§!~m
(~~~)
InstallatiQ~ £l~nnin~
~n~
!abl~
Order No. GC35-0068
or
OSL!~l ~2i.§.ID .F!Qg!~ming Li.!?I.~il:
~y§!:~.! Q~~!atio.n ~~fe~n£~,
Order
No. GC26-3792
During the system generation procedure, you apply the system Program
Update Tape
(PUT) supplied with the starter system. This updates your
system to the current level. Then use the Installation Verification
Procedure
(IVP)
to verify that the VM/370 system is functioning
properly.
Part 1. Planning for System Generation
5
Introduction
BQi~:
If you are installing a system program update tape, use this
publication in conjunction with the "emo to Users supplied on the PUT.
If you wish to install the Remote Spooling Communications Subsystem
(RSCS) do so after running the IVP.
After you generate VM/370 (CP, CMS,
IPCS, and, optionally, RSCS), you can generate the 3704/3705 Control
Program.
Information about gen~rating this program is found in Part 4
of this manual.
6
IBM VM/370 Planning and System Generation Guide
Performance Guidelines
Performance Guidelines
The performance characteristics of an operating system when it is run in
a virtual
machine environment are
difficult to
predict.
This
unpredictability is a result of many factors:
•
The System/370 model used
•
The system environment used (uniprocessor or attached processor)
•
The total number of virtual machines executing
•
The type of work being done by each virtual machine
•
The speed, capacity, and number of the paging devices
•
The amount of real storage available
•
The degree of channel and control unit
contention, affecting the paging device
•
The type and number of VK/370 performance
more virtual machines
•
The availability of VM/370 hardware assist
•
The favored priority and V=R options in effect
contention, as well
as arm
options in use by
one or
Also, the virtual machine's channel mode, block multiplexer or selector,
has an effect on the virtual machine's performance.
!Qig: The performance
and shared with
contention.
of an KSS being accessed by the operating system
other systems depends on the total KSS utilization and
Performance Measurement and Analysis
The VK/370 control program has two commands that measure system
performance and, thus, help you identify problem areas.
The MONITOR
command collects system measurement data offline for the system operator
or system
analyst,
while the
INDICATE command
displays system
measurement data online for the system operator,
system analyst or
gen eral user.
The MONITOR command controls the collection of performance data and
writing it to system spool files or tapes.
Both summary and trace data
can be collected. The classes of data collected may be specified using
either the operands of the MONITOR command or those of the SYSMON macro
instruction. The classes selected depend on the nature of the analysis
to be performed.
The IBM Field Developed Program
(FOP)
VM/370:
Performance/"onitor Analysis Program can be used to reduce the data
collected. The guidelines for using this program provide the user with
information that will
aid him in determining
the overall load
environment and performance
profile of his system.
The VM/370
Performance/Monitor Analysis Program should enable him to analyze the
utilization of and contention for the major system resources such as the
CPU, storage, and I/O paging subsystems.
Part 1. Planning for System Generation
7
Performance Guidelines
The INDICATE command displays, at the terminal, some key information
about the system that shows
the current performance indicators.
Invoking the INDICATE command displays the system conditions existing at
the time the command is issued including attached processor utilization
measurement when operating in an attached processor environment.
If,
after using the INDICATE command, the system analyst wants more
extensive data collection and reduction, he can use the MONITOR command.
The user can specify automatic data collection with the SYSMON macro
in DMKSYS.
Coding
Considerations are contained in
the section
"Preparing the CP System Control File
(DKKSYS)." See the !I1LJIQ .§.y§i~!!!.
~~gr~mm~~~§ ~Yig~
for the directions on using the MONITOR command to
collect performance data on a dedicated tape drive or spool file, the
format and contents of the various classes of data collection available
with MONITOR, and details of the INDICATE command options.
Using the Performance Options
The performance of a specific virtual machine can be improved by
assigning it one or more performance options. These include: favored
execution,
priority,
reserved
page
frames,
locked pages,
and
virtual=real.
The performance of a VM/370 system running virtual storage operating
systems can be improved if you use virtual machine assist or Extended
Control-Program Support. The manner in which these are supported by the
various VK/370 processors is detailed below:
,
r
Virtual Machine Assist
VM/370:ECPS
1---------------------------------------------------------------------------Special
RPQ 1
Not
,Standard
Special I
Not
1 Standard
I Feature
135-3
13A
145-3
14A
3031
3031 AP
4341 1
Feature
135
145
158
158-3
158AP
158MP
4331 1
IAvailablel Feature
168
168-3
168AP
168MP
3032
3033UP
3033AP
3033MP
155
155I1
165
165-3
135-3
138
145-3
148
3031 2
3031 AP2
4341
Feature IAvailable
4331 12
1
1 ITo function with the availability of the hardware feature.
I
I 2See the !~11~~y§1~!-~~Qg~!!!.er·s ~id~ for specific VM/370:
I EPCS functions available on this processor.
L
8
IBM VM/370 Planning and System Generation Guide
135
145
155
155II
158
158-3
158AP
158MP
165
165- 3
168AP
168MP
3032
3033
3033AP
3033MP
Performance Guidelines
In order to invoke the favored execution, priority,
reserved page
frames, and locked pages options you must have a virtual machine defined
with the appropriate command privilege classes. Usually, the operator's
virtual machine has the
appropriate command classes.
Additional
planning is needed to support the virtual=real option and virtual
machine assist as well as VM/370:ECPS.
All of these performance options
are described in detail in the !~70 ~Y.§i~.m Pr.Qg~~J!tm~£..§ ~'yid~.
Specifying a Virtual=Real Machine
Although the virtual=real option eliminates paging, its main function is
to bypass CCW translation. This is possible because I/O from a virtual
machine occupying a virtual=real space contains a list of CCWs whose
data addresses reflect the real storage addresses.
The only exception is virtual page o.
Virtual page 0 does not exist
as real page 0; it is relocated to the highest page of the virtual=real
area. In order for the virtual machine to perform input/output into
virtual page 0, the CCW addresses must be translated.
When CP loads an operating system into a virtual=real area, it turns
on CCW translation.
Once the operating system is loaded, the operator
of the virtual machine may issue a CP command to turn CCW translation
off.
When the virtual machine is operating with CCW translation off, it
must not perform I/O into virtual page O.
Most operating systems can be
generated so that they do not use this area for input/output.
However,
violation of this restriction may cause damage to the entire VM/370
system.
The size of the virtual=real area is specified during CP system
generation. It must be large enough to contain the entire address space
of the largest virtual machine that you execute in the virtual=real
area.
Only one virtual=real area can be defined.
Only one virtual machine at a time can occupy the virtual=real area.
Since the virtual=real option removes pages from the dynamic paging
area, it affects the performance of the other virtual machines.
The virtual=real area is set up at V!/370 initial program load (1PL).
It can be released by the primary system operator to be used as part of
the dynamic paging area. Once released, it cannot be reclaimed except
by reloading VM/370.
The virtual=real area must be released in total,
that is, unused pages of the area cannot be selected for release.
!Qi~:
If a very large virtual=real area is released after V"/370
initialization, a system performance degradation may occur as more and
more users log on and use the released space. The reason for this is
that the number of pages allocated for CP fixed free storage during
VM/370 initialization is based on real machine size minus virtual=real
size. Therefore, the number of fixed free pages allocated for a system
with a virtual=real area may not be enough to accommodate the larger
number of users of the released space, and system overhead may increase
as CP extends to get dynamic free storage pages.
Part 1. Planning for System Generation
9
Performance Guidelines
This problem may be counteracted by using the FREE operand in the
SYSCOR macro instruction in the system control (DMKSYS)
file at system
generation. The SYSCOR macro is described in "Part 2. Defining Your
V8/370 System." The examples used in the following discussions assume
that you are allowing V8/370 to determine the number of free storage
pages to allocate.
To use
the virtual=real
option effectively
on a
multiport
teleprocessing system with no CCW translation (SET NOTRANS ON), lines
must be dedicated to that system via the ATTACH command or by V8/370
directory assignment.
Conversely, on a
multiport teleprocessing
virtual=real operation, virtual 2701/2702/2703 lines, (that is, lines
assigned and used by CP's DEFINE and DIAL command~ operate with CCW
translation. If you issue the DIAL command while SET NOTRANS ON is in
effect, CCW translation is done for I/O involving that line.
Note that you cannot execute programs with dynamic or self-modifying
channel programs in a virtual=real area if you also use the DIAL
command. Also, you cannot load (via IPL) a shared s!~tpm into a virtqal
machine running in the virtual=real area. For a virtual=real machine,
you must issue the IPL command with either a device address or the name
of a non shared system.
To generate CP
the following:
so that it properly supports a
virtual=real area, do
•
Specify the VIRT=REAL option in the VM/370 directory for all the
virtual machines in your installation that you plan to run in the
virtual=real area.
•
Reserve enough DASD space for the CP nucleus.
A CP nucleus that
supports a virtual=real area is larger than one that does not.
•
Make sure the virtual machine you
sufficient virtual storage.
•
Specify the
area.
amount of storage you
are using
to
generate CP
want reserved for
has
a virtual=real
"Part 2. Defining Your V8/370 System" describes the Directory
program, including information about the VIRT=REAL operand of the OPTION
control statement.
RESERVING DASD SPACE FOR A CP NUCLEUS WITH A VIRTUAL=REAL AREA
A CP nucleus with the virtual=real option requires more DASD space for
system residence than a CP nucleus without the option.
Use the
following formulas to calculate the number of cylinders needed for
system residence (disregard any remainders):
Number
Number
Number
Number
of
of
of
of
2314/2319 cylinders
3330/3333 cylinders
2305/3340 cylinders
3350 cylinders
=
=
=
=
(128+(VRSIZE/4»/32
(171+(VRSIZE/4»/57
(144+(VRSIZE/4»)/24
(240+(VRSIZE/4»/120
where VRSIZE is the size of the virtual=real storage area (in K bytes).
K represents 1024 bytes. This size must be at least 32K bytes.
10
IBM V8/370 Planning and System Generation Guide
Performance Guidelines
The number of cylinders you calculate here is the number you reserve
on your system residence device using the FORMAT program DMKFMT. You
need this information to code the SYSRES macro of your CP system control
(DMKSYS) file correctly.
If you do not reserve enough DASD space for your CP nucleus, the
nucleus overlays other cylinders when it is written on the system
residence volume and may itself be overlaid by other disk writes.
VIRTUAL STORAGE REQUIREMENTS
When you are generating VM/370 you have three constraints on the maximum
virtual=real size you can specify: real storage, virtual storage, and
the size of your nucleus.
Before you load the CP nucleus, be sure the virtual
using has enough virtual storage to contain:
•
•
machine you are
CMS (320K)
CP nucleus size (including the virtual=real area)
If your virtual machine does not have enough
storage and 1PL again before continuing.
virtual storage, redefine
SPECIFYING THE AMOUNT OF VIRTUAL=REAL SPACE
If you are generating your VK/370 system to include a virtual=real
machine, in step 16 of the system generation procedure you respond "yes"
to the system message:
VIRTUAL=REAL OPTION REQUIRED (YES, NO) :
You are
size:
then prompted
to enter
the size
of the
virtual=real machine
STORAGE SIZE OF VIRT=REAL (MINIMUM IS 32K):
Normally~ you would not want to specify the largest virtual=real machine
possible, since that would leave few-page frames available for other
virtual machines.
At IPL time, the virtual=real area is locked in storage immediately
following CP page O. The system operator can issue the UNLOCK command
with the VIRT=REAL option to free the virtual=real area for additional
dynamic paging space for other virtual machines.
The area cannot be
relocked; it remains unlocked until another system IPL.
Calculate the maximum amount
your real CPU as follows:
of virtual=real
storage available
on
•
Use Formula 1 to calculate the amount of real storage above the
minimum required by CP at IPL time. If available real storage (ARS)
is negative or zero, CP will not IPL.
•
Use Formula 2 to calculate the
any real machine size. If VRS
area is not supported.
maximum virtual=real size
(VRS) for
is negative or zero, a virtual=real
Part 1. Planning for System Generation
11
Performance Guidelines
Calculate the amount of available real storage (ARS) by subtracting the
amount of storage required by CP from the real machine size.
Formula 1
is:
r
r "
I
IRM - 256KI I
ARS = RM - II + T + 12K + 4KI---------1 I
I
I
64K
II
L
L
.J.J
RM
is the real machine size.
I
is the amount of storage needed to IPL CP. Refer to the load
map produced when the CP nucleus is generated. The amount of
storage needed to IPL CP is all of storage up to, and
including, the module DMKSAV.
T
is the amount of storage allocated for the CP internal trace
table.
CP allocates 4K of storage for each 256K of real
storage for the CP internal trace table:
r
,
I RM I
4K 1----1
f256KI
L
.J
If the calculation RM/256K results in a fraction, the result
should be rounded upward to the next higher integer.
12K
r
is the amount of fixed free
256K of real storage.
storage allocated for
the first
,
IRM - 256KI
4KI---------I
I
641{
,
L
.J
is the amount of fixed free storage allocated for real storage
beyond the first 256K (if there is no virtual=real area).
If
the calculation enclosed in brackets results in a negative
value, replace it with zero.
If the same calculation results
in a fractional number, disregard the fraction.
The result obtained from Formula 1 is the amount of available real
storage (ARS) for a particular real machine size. This result is needed
to calculate the maximum size of a virtual=real area in Formula 2.
12
IBM VM/37Q Planning and System Generation Guide
Performance Guidelines
Calculate the maximum size of the virtual=real area for a particular
real machine size by recalculating the amount of real storage required
by CP and subtracting that value from the real machine size.. When you
calculate the amount of real storage required by CP this time, you do
not permanently allocate free storage for the portion of storage that is
available for the virtual=real area (according to Formula 1).
The
result of Formula 2 is the maximum size virtual=real area (VRS) you can
specify for a particular real machine size. Formula 2 is:
VRS
=
-
RM
,
,
.J
.J
r
r
ARS I
IRft - 256K
I
I
I I + T + 12K + 4KI---------------1 + 16KI
64K
I
I
I
I
-
L
L
Use the same value for RM, I, and T as you used in Formula 1. ARS (the
available real storage) is the result calculated from Formula 1. If the
calculation
RM - 256K - ARS
64K
results in a negative value, replace it with zero. If the saae
calculation results in a fractional number, disregard the fraction (see
Examples 1 and 2). 16K is the amount of storage needed at IPL time for
the dynamic paging area. After VM/370 is loaded (via IPL), the size of
the dynamic paging area is the number of pages from DKKCPE to DKKSAV
plus 16K.
The following table shows the maximum
specify for some real machine sizes.
!!~L.r!ac h i!!.!L.'§i!~
384K
512K
768K
HI
2M
Note that in
244Kl.
size virtual=real area you can
~g!im~~ VIRT=~!L Siz~
104K
232K
484K
732K
1744K
this table it is assumed
the value of I
is equivalent to
lSince the amount of storage required to IPL VM/370 varies with the
inclusion of optional features and the number of devices in DBKRIO,
this figure is used in the following example for illustrative purposes
only.
Part 1. Planning for System Generation
13
Performance Guidelines
Determine the maximum size of the virtual=real area for a real machine
with 768K of storage that executes a VM/370 system that requires 244K to
1PL.
r
r,
r
"
L
L.J
L
.J.J
I
1768K I
1768K - 256KII
ARS = 768K - 1244K + 4KI----1 + 12K + 4KI-----------1 I
I 256K I
I
64K
iI
ARS = 768K - [244K + 12K + 12K + 32K]
ARS = 768K - 300K
ARS = 468K
VRS = 768K
-
r
r
,
L
L
.J
,
r
r,
,
I
144K,
I
VRS = 768K - 1268K + 4KI---1 + 16K I
164K I
I
I
L
VRS
= 768K
VRS
=
L
.J
.J
- [268K + 4K[O] + 16K]
484K
Note that the fraction (44/64) resulting from the
RM - 256K - ARS
64K
calculation in Formula 2 is truncated to zero.
14
,
1768K - 256K - 468KI
I
I
1244K + 12K + 12K + 4KI------------------I + 16K I
64K
I
I
I
IBM VM/370 Planning and System Generation Guide
.J
Performance Guidelines
Determine the maximum size of the virtual=real area for a real machine
with 384K of real storage. The VM/370 system requires 244K to IPL.
r
r,
r
"
L
L
L
.J.J
I
I 384K ,
1384K - 256K"
384K - 1244K + 4KI----1 + 12K + 4KI-----------I'
,
I 256K I
I
64K
,t
ARS
.J
ARS = 384K - [244K + 4K[2] + 12K + 8K]
ARS
= 384K
ARS
112K
- [272K]
Note that the fraction 384/256 in the trace table calculation is rounded
to the next higher integer, two.
r
r
"
L
L
.J
!
1384K - 256K -112KI
I
VRS = 384K - 1244K + 8K + 12K + 4KI-----------------1 + 16K I
,
I
64K
I
,
VRS
VRS
VRS
=
=
=
r
r
,
L
L
L
.J
,
I 16,
I
I
384K - 1264K + 4KI--1 + 16K I
1641
I
I
.J
384K - [28 OK]
104K
Note that the calculation
RM -
256K - ARS
64K
results in a fraction that is then replaced by zero.
Part 1. Planning for System Generation
15
Performance Guidelines
Determine the maximum size virtual=real area for a real machine with
1792K of real storage. The V"/370 system requires 244K to IPt.
r
r,
r
"
L
L.I
L
.1.1
1
11192KI
11192K - 256KII
ARS = 1192K - 1244K + 4KI-----I + 12K + 4KI------------I'
I
I 256KI
,64K
II
ARS = 1192K - [244K + 4K[1] + 12K + 4K[24]]
ARS = 1192K - [244K + 28K + 12K + 96K]
ARS = 179 2K - [3 8 OK ]
ARS = 1412K
r
r
"
L
L
.1.1
I
11192K - 256K - 1412KI
1
VRS = 1192K - 1244K + 28K + 12K + 4KI--------------------I + 16K I
,
I
64K
I
I
r
r,
,
I
11241
I
VRS = 1192K - 1284K + 4KI---I + 16K,
I
I 64,
I
L
L.I
.I
VRS = 1792K - [308K]
VRS = 1484K
Note that the fraction (124/64) resulting from the
R" - 256K - ARS
64K
calculation in Formula 2 is rounded to the next higher integer, two.
16
IB~
VM/370 Planning and System Generation Guide
Performance Guidelines
Determine the maximum size virtual=real area for a real machine with
256K of real storage. The VK/370 system requires 244K to IPt.
r
r,
r
L
L
L
"
I
I 256K I
1256K-256K I I
ARS = 256K - 1244K + 4KI----I + 12K + 4KI---------1 I
,
1256KI
I
64K
II
ARS = 256K - [244K + 4K[ 1 ] + 12K + 4K[ 0]]
ARS = 256K - [26 OK]
ARS = -4K
Since ARS is a negative number, CP cannot IPL and the
message informs the user of this condition:
following error
DKKCPI955W INSUFFICIENT STORAGE FOR VM/370
Virtual Machine Assist
Virtual machine assist is a combination of a processor feature and
VK/310 programming.
It improves the performance of VM/370.
Virtual
storage operating systems that run in problem state under the control of
VM/310 use many privileged instructions and SVCs that cause interrupts
which VK/370 must handle. When virtual machine assist is used, many of
these interrupts are intercepted and handled by the processor; and,
consequently, VM/370 performance is improved.
The manner in which
virtual machine assist and ECPS are supported by the various VM/370
processors is detailed under "Using the Performance Options."
Certain interrupts must be handled by VM/370.
machine assist is not available if it:
•
•
Consequently, virtual
Has an instruction address stop set
Traces SVC and program interrupts
Since an address stop is recognized by an SVC interrupt, VM/370 must
handle SVC interrupts while address stops are set.
Whenever you issue
the ADSTOP command, VM/370 turns off the SVC handling portion of the
assist feature for your virtual machine. The assist feature is turned on
again after the instruction is encountered and the address stop removed.
Whenever a virtual machine issues a TRACE command with the SVC, PRIV,
BRANCH, INSTRUCT, or ALL operands, the virtual machine assist feature is
turned off for that virtual machine.
The assist feature is turned on
again when the tracing is completed.
Part 1. Planning for System Generation
17
Performance Guidelines
If virtual machine assist is available on a processor, the operator
can turn the function off, and on again, for the entire VM/310 system.
Also, if the function is available to VM/310, each virtual machine
operator can turn the function off, and on again, for his own virtual
machine. When you create your VM/370 directory, you can set off the
SVC-handling portion of the virtual machine assist function for various
virtual machines by specifying SVCOFF on the OPTION control statement.
VM/370 EXTENDED CONTROL-PROGRAM SUPPORT
V"/370 Extended control-Program Support is a
that provides support over and above that
machine assist feature described previously,
VM/370's real supervisor state time needed to
VM/370
Extended Control-Program
Support
functions.
•
•
•
hardware assist function
provided by the virtual
and consequently reduces
support virtual machines.
provides the
following
~xpanded virtual machine assist
CP assist
Virtual interval timer assist
Whenever VM/370 is loaded on one of the supported processors, all three
hardware assist functions plus virtual machine assist are activated
unless turned off by the system operator.
Expanded virtual machine assist
includes a more comprehensive
emulation of the SSM, LPSW, STNSK, and STOSM privileged instructions.
Additional privileged instructions are also emulated.
CP assist provides a hardware assist for the high-use portions of the
following CP functions:
•
•
•
•
•
•
Virtual machine I/O
Storage management
Page management
SVC handler
Privileged instruction handler
Dispatcher
If (1) CP assist is turned off, (2) hardware assist does not support the
specific service required, or
(3) an error condition occurs, the
appropriate CP software routine is used.
Virtual interval timer assist provides for hardware updating of the
location 80 interval timer for each virtual machine that has the virtual
timer assist function turned on. This timer assist provides a more
accurate and repeatable interval timer value for virtual machines than
was previously possible through CP software.
Both virtual machine assist and expanded virtual machine assist are
automatically turned off if the user invokes certain TRACE functions.
In addition, virtual interval timer assist is turned off if external
interrupts are traced.
When the tracing function is terminated, CP
automatically reactivates these V"/370 hardware assist functions.
the
1A
For more details on VK/370 Extended control-Program Support, refer to
~LJ70 ~Y§l~ Prgg~~~mer~§ Qyide.
IB~
VM/370 Planning and System Generation Guide
Planning Considerations for CMS
Planning Considerations for eMS
The Conversational Monitor System (CMS) is a component of VM/370 that
provides a comprehensive set of conversational facilities to virtual
machine users.
CMS operates only in a virtual machine, and together
with CP provides a time-sharing system suitable for program development,
problem solving, and general time-sharing work.
CMS is a required component of VM/370. You must generate CMS in order
to support CPo
This section contains the following information about CMS:
•
•
•
•
•
•
•
•
•
•
•
•
storage Requirements
Device Support
Libraries
Command Language
Program Language Facilities
Limited Support of DOS and OS
Disk and File Management
Tape Support
unit Record Support
Editing
Batch Facility
Saving CMS
eMS Storage Requirements
CMS requires virtual storage and auxiliary storage. A minimum of 320K
bytes of virtual storage is required for a CMS virtual machine; this
virtual storage is distributed as follows:
•
1.
1
I
1
•
CMS nucleus -- 128K
Loader
User
tabl~s
program
-- 8K (for virtual machines with up to 384K of
virtual storage)
12K (for
virtual machines with more than 384K
virtual storage)
area -- 184K (for application
programs
disk-resident commands)
or
of
CMS
AUXILIARY STORAGE
The CMS auxiliary storage requirements are:
•
System residence for CMS -- 110 cylinders on a 2314 or 2319, 72
cylinders on a 3330 or 3333, 203 cylinders on a 3340 Model 35 or
Model 70, or 29 cylinders on a 3350 in native mode.
Part 1. Planning for System Generation
19
Planning Considerations for CMS
•
Resident disk space for application programs (CMS commands,
user
programs, IBM Program products) -- the amount of space needed is
program-dependent, and must be assigned by you.
•
Work space for application programs (CMS commands, user programs, IBM
Program Products)
-- the amount of space is program-dependent, and
must be assigned by you.
Device Support
eMS supports the virtual machine devices shown in Figure 2.
,,
r
Virtual
Address 1
Symbolic
Name
3210,3215,1052
2314,231Q,3330,3340,3350
cuu 2
190
CON1
DSKO
2314,2319,3330,3340,3350
191 3
DSK1
2314,2319,3330,3340,3350
2314,2319,3330,3340,3350
2314,231 Q,3330,3340,3350
2314,2319,3330,3340,3350
2314,2319,3330,3340,3350
2314,2319,3330,3340,3350
2314,2319,3330,3340,3350
2314,2319,3330,3340,3350
1403,3203,3211,1443
2540,2501,3505
2540,3525
2401,2402,2403,2415,
2420,3410,3411,3420
cuu
cuu
192 3
cuu
cuu
cuu
19E3
cuu
OOE
OOC
OOD
181- 4
Virtual
IBM Device
DSK2
DSK3
DSK4
DSK5
DSK6
DSK7
DSK8
DSK9
PRN1
RDR1
PCRl
TAP 1-TA P4
Device Type
System console
System disk
(read-only)
Primary disk
(user files)
Disk (user files)
Disk (user files)
Disk (user files)
Disk (user files)
Disk (user files)
Disk (user files)
Disk (use r files)
Disk (user files)
Line printer
Card reader
Card punch
Tape dri ves
1The device addresses shown are those that are preassembled into the
CMS resident device table. You can change the virtual machine
, addresses by using the CP DEFINE command.
12The virtual address of the system console may be any valid
I multiplexer address.
13 The virtual device address (cuu) of a disk for user files can be any
I valid System/370 device address, and can be specified by the CMS user
, when he activates a disk. If the user does not activate a disk
, immediately after loading CMS, CMS automatically activates the user's
I primary disk (A-disk) at virtual address 191, the D-disk at 192, and
, the Y-disk (a read-only extension of the system disk) at 19E.
L
Figure
2.
Devices Supported by a CMS Virtual Machine
Under CP, unit record devices and the system console are simulated
and mapped to different addresses and different devices. For instance,
eMS expects a 3215,
3210, or 1052 type of operator's console, but many
terminals are 2741s or 3270s. Regardless of the real device type, the
virtual system console is a 3215.
The control program (CP)
of VM/370
handles all channel program modifications necessary for this simulation.
eMS virtual disk addresses are mapped by CP to different real device
addresses.
20
IBM VM/370 Planning and System Generation Guide
Planning Considerations for CftS
The CftS system disk, normally located at virtual address 190, is
read-only and contains the CftS nucleus functions and disk-resident CftS
command modules. The CftS nucleus is loaded into virtual storage when you
issue the CP IPt command. CMS remains resident until another IPL command
is entered or until you log off. The disk-resident modules are loaded
into virtual storage only when their services are needed.
The A-disk is a read/write disk and is the primary or first
disk.
Files that you wish to retain for later use are stored on one of your
disks. Information stored on a disk remains there until you erase it.
An exception is the temporary disk; files written on this disk are lost
when you log off.
In addition to the system disk (~-disk) and primary
disk (A-disk), each eMS user can have up to eight additional disks.
You can enter CftS commands and input files
direct output files, program results, and error
back to the terminal.
from the terminal and
and prompting messages
The virtual card reader is used as the input medium for files, source
decks, and data to be processed by your programs. The virtual card
punch is used for your output files, language processor object decks,
and various other types of data.
The virtual printer is used for
program results, storage dumps and language processor output.
Under VM/370, the unit record equipment
supports only spooled unit record devices.
is normally
The following
virtual machine.
directory entry for
is an example
of a VM/370
spooled.
CMS
a CMS
USER USER1 PASSWORD
ACCOUNT NUMBER BIN7
IPL CMS
CONSOLE 009 3215
SPOOL C 2540 READER A
SPOOL D 2540 PUNCH A
SPOOL E 1403 A
LINK ftAINT 190 190 RR
MDISK 191 2314 71 10 UDISK1 W RPASS WPASS
This entry describes the configuration when you log on as USER1. The
Directory program control statements are described in Part 2. Briefly,
this entry describes the USERl virtual machine: it has a console at 009,
a class A -reader at OOC, a class A punch at OOD, a class A printer at
OOE, a link to the CMS system disk (owned by userid MAINT) at 190, and a
minidisk at 191.
Once you are logged on you
can change the
configuration and also the spooling classes of the unit record devices.
You can add devices to the VM/370 directory or dynamically add to the
configuration as needed.
eMS Libraries
efts updates simulated partitioned data sets which contain:
•
CftS and OS macros to be used at assembly time (macro
•
Object routines
libraries)
to be
referred
to
librarie~
at execution-load
time
(text
Part 1. Planning for System Generation
21
Planning Considerations for CMS
The system macro libraries, located on the CMS system disk, are:
1ibIllY
CMSLTB MACLIB
Con.t~nt§
OSMACRO MACLTB
The selected OS macros from SYS1.MACLIB that are
supported under CMS
OSMACROl MACLTB
The
remaining
SYS1. MACLIB
TSOMAC MACLIB
The OS macros distributed in SYS1.TSOMAC
DOSMACRO MACLTB
The DOS/VS macros and
DOS/VS function
All of the CMS macros
distributed
OS
CMS macros
macros
from
that provide
If you have previously created a CMS macro library and called it
DOS MACRO MACLIB, you should rename it so that it does not conflict with
the DOS MACRO MACLIB supplied with the system.
If you plan to assemble DOS programs containing DOS macros in
CMS/DOS, you must first create a CMS macro library that contains all the
DOS macros you need.
"Appendix G: A Sample EXEC Procedure for Copying
DOS/VS Macros into a CMS MlCLIB" shows the procedure for copying an
entire macro library. The procedure for copying individual macros is
described in the !~L1IQ ~MS Q~£~§ Guid~.
The system text libraries, also located on the CMS system disk, are:
LiQrary
CMSLIB TXTLIB
Content§
The CMS system text library
TSOLIB TXTLIB
Selected
certain
products
EREPLIB TXTLIB
Base text library for CPEREP
ERPTFLIB TXTLIB
Updates to CPEREP text library
TSO routines
features of
necessary to
the language
Execution-time libraries are available with
language processors and execute under eMS.
the
program
support
program
product
You can generate your own libraries and add, delete, or list entries
in them via the MACLIB and TXTLIB commands.
You can also specify which
libraries (system and user) to use for program compilation and execution
via the GLOBAL command.
Up to eight libraries may be specified.
Although CMS library files are similar in function to OS partitioned
data sets, OS macros should not be used to update them.
eMS Command language
The CMS command language lets you
language, you can use:
•
•
•
•
•
•
22
converse with CMS.
Language compilers
An assembler
CMS file management system
Context editing and line editing
Execution control
Debugging capability
IBM VM/370 Planning and System Generation Guide
With this command
Planning Considerations for CMS
Additionally, you can invoke the CP commands available to all virtual
machines under VM/370 directly from CMS. Using these CP commands, you
can send messages to the operator or to other users, dynamically change
your virtual machine's configuration, and invoke spooling facilities.
In CMS, the facilities of CP and CMS together appear as those of a
single integrated system.
To use CMS, you must first gain access to a virtual machine via the
CP LOGON command, and IPL CMS. Then you can enter commands or data from
the remote terminal (virtual operator's console). Each command, upon
completion, returns control to you. For information about how to use
CMS and for a description of all CMS commands, see the !~/370 CM~
~Q'!!!'J!!~Q ang ~ggQ Ref~~.!!£~ and the VM/37Q. CM~ !!.§~~.§ Guig~.
eMS Program language Facilities
The languages available under CMS include:
S/370 Assembler
VS BASIC
PL/T
as FORTRAN IV
OS/VS COBOL
DOS PL/I Optimizer
DOS/VS COBOL
VS APL
The assembler is distributed with VM/370.
The language compilers
that are program products must be ordered separately. For a complete
list of language processors that can be executed under CMS, see
"Appendix A: Program Products, Installed User Programs, Field Developed
Programs and Emulators."
CMS executes the compilers via interface modules.
CMS commands are
provided to invoke the compilers within the conversational environment
of CMS.
OS/VS COBOL programs, using the following facilities, can be compiled
under CMS, but must be transferred to a machine (virtual or real)
running as for execution.
QSAM & BDAM spanned records
ISAM
RERUN statement
label-handling options
OPEN REV ERSED
Sort feature
Segmentation feature
ASCII code feature
Forced end of volume
TCAM feature
as PL/I programs, using the following facilities, can be compiled
under CMS, but must be transferred to a machine (virtual or real)
running 05 for execution.
Mul ti tas king
Teleprocessing file support
ISAM
Backwards attribute
Part 1. Planning for System Generation
23
Planning Considerations for CKS
Spanned records for buffered files
. Sort-merge
Checkpoint-restart
ASCII data sets
Track overflow
The DOS/VS COBOL and DOS PL/I Optimizing compilers execute in the
CMS/DOS environment of CKS. The CKS/DOS environment does not support
the execution of DOS programs that use:
•
sort exits. The DOS/VS COBOL and DOS PL/I Optimizer
not supported in CKS/DOS.
•
Teleprocessing, indexed sequential access method (ISAK), or direct
access method (DAM). CMS/DOS supports only the sequential access
method (SAK, and virtual storage access method (VSAK).
•
Kultitasking.
CKS/DOS
background partition.
supports
only
a
single
SORT verbs are
partition,
the
CMS TEXT PROCESSING FACILITY
Text processing facilities that can create formatted output from one or
more CKS files containing text and/or control words are available
through the SCRIPT command. SCRIPT/370 is an IBM Installed User Program
that must be ordered separately.
Limited Support of OS and DOS in eMS
Object programs (TEXT files) produced under CMS and under OS in real or
in virtual machines can be executed under CKS if they do not utilize
certain OS functions not simulated by CKS. Object programs using
nonsimulated OS macro functions must be transferred to an appropriate
real or virtual OS machine for execution.
Sequential and partitioned data sets residing on as disks can be read
by OS programs running under CMS. Also, certain CMS commands can be used
. to process data sets on as disks.
CMS simulates the control blocks, supervisor and I/O macros, linkage
editor and fetch routines necessary to compile, test, and execute DOS/VS
programs under CMS. The support for the DOS user is comparable to that
for the OS user.
CMS supports VSAM and access method services for DOS and OS users.
CMS supports VSAM for the following." compilers: OS/VS COBOL, OS PL/I, VS
BASIC, DOS/VS COBOL,
and DOS PL/I.
CMS does not support VSAM for
assembler language programs or VS APL.
The application programmer who normally uses CMS to interactively
create, modify, and test his programs may require facilities not
supported in CMS
(for example, an OS program using ISAM). He can
alternately execute CKS and another operating system in the same virtual
machine.
A description of the actual processes for reading as or DOS files is
in the !11Ll1Q ~1!'§ Us~!:..!..§ Gu!g~.
A description of alternating operating
systems is in !1!L37Q Q~~~!!Rg 2~stems in ~ virtY~l ~~ch!n~·
24
IBM VM/370 Planning and System Generation Guide
Planning Considerations for CMS
DL/I IN THE CMS/DOS ENVIRONMENT
Batch DL/I application programs can be written and tested in the CMS/DOS
environment. This includes all batch application programs written in
COBOL, PL/I, or Assembler language.
You can also execute any data base description generation and program
specification
block
generation.
The data
base
recovery
and
reorganization utilities must also be executed in a DOS/VS virtual
machine.
For
more information, see the VM/31~
Infofmati2n, GH20-1246.
CMS
~§~f~§
Guig~,
and
DL/I
~OS/VS §~~~~!
eMS Disk and File Management
CMS can manage up to ten virtual disks for each user.
be minidisks or full packs. Moreover, they may be in:
These disks may
format
•
eMS
•
as or DOS format
•
VSAM format
When the VM/370 MSS support is installed, and the VM/370 processor is
attached to an MSS, any CMS virtual disk can be located on an MSS 3330V
volume.
eMS disks are formatted with the CMS FORMAT command; files contained
on these disks are in a format unique to CMS, and cannot be read or
wri tten using other operating systems.as and DOS disks or minidisks may be used in CMS. as or DOS programs
executing in CMS may read data sets or files on as or DOS disks, but may
not write or update them: as and DOS minidisks may be formatted with
the IBCDASDI service program, or with an appropriate OS/VS or DOS/VS
disk initialization program, if the disk is a full pack.
VSAM disks used in CMS are fully compatible with as and DOS VSAM
disks.
Minidisks for use with VSAK must be formatted with the IBCDASDI
program; full disks must be initialized using the appropriate as/iS or
DOS/VS disk initialization program.
DISK ACCESS
Disks can be accessed in two ways: read-only, where files on that disk
can only be read; and read/write, where files can be read and written.
Both CP and CMS can control read/write access.
If a disk is
designated read/write by CP, then the CMS access determines its
read/write status. If a disk is desi9nated read-only by CP, then it can
only be accessed read-only in CMS.
Part 1. Planning for System Generation
25
Planning Considerations for CMS
To access a disk, you must:
•
Identify the
disk to
CP as part
of your
virtual machine
configuration.
This disk is available if it is defined in your
V8/310 directory entry, or it can be acquired dynamically with the CP
LINK or DEFINE commands.
•
Identify the disk to CMS by assigning it a filemode
this using the ACCESS command in CMS.
letter.
You do
While you may have many virtual disks known to CP in your virtual
machine configuration at one time, CMS allows a maximum of ten to be
accessed, with filemode letters A through G, S, Y, and Z.
The S-disk
(usually at virtual address 190)
is the CftS system disk.
The A-disk
(usually at virtual address 191) is the user's primary read/write work
disk. Disks may be dynamically accessed and released during a terminal
session.
FILE SHARING
CP provides for sharing of disks and minidisks among several users. The
type of access (multiple users read-only or read/write) is controlled by
LINK command operands. Password protection is provided. Since CMS does
not provide any control for multiple writes
(such as ENQ, DEQ), it is
not recommended that CftS disks be used with multiple-write access.
CMS DISK FILE FORMAT
All CMS disks (that is, disks that are to contain CMS files)
must be
formatted before being used the first time. The CMS FORMAT command
initializes disks in CMS format and writes a label on the disk. The
10-byte label (written on record 3 of cylinder 0, track 0) consists of
the following:
•
Four characters: CMS=
•
Six characters:
Desired label (blank-filled
characters; truncated if more than 6 characters)
•
The remaining bytes of the record are all binary zeros
if
less
than
6
The disks are formatted into aOO-byte physical records, called
blocks.
Logical records, which may be fixed-length or variable-length,
are imposed on constant physical blocks.
Space required for files is
automatically allocated by CMS.
As a file grows, its space is expanded,
and it is contracted as its space requirements are reduced.
Files on a CMS disk are identified by means of a file directory,
called the master file directory. The file directory is updated when a
command is issued that changes the status of the file on the disk.
Figure 3 compares the disk devices supported by CftS.
For more information about planning CMS minidisk requirements, see
"Estimating VM/370 Storage Requirements" later in this section.
26
IBM VM/370 Planning and System Generation Guide
Planning Considerations for
I
I
,
I
,
.I
,
I
I
I
r
Maximum number of files
that can be contained on
the disk
Maximum minidisk size
(in cylinders)
1
I
..I Number of 800-byte blocks
, per cylinder
.. Maximum data extent
,
,,
I
I
I
I
,,
+-I
I
I
c~S
2314/
2319
3330
3340
3500
3400
3400
I
I 3350
,,
3400
I
I
I
203
246
150
266
~c:;
c:;~c:;
""'-',-'...Iv
,
348
(model 35) ,
682
(model 70) ,
I
96
I
I,
,
115
570
records
12,848,000 bytes
L
Figure
3.
CMS Disk File Statistics
IDENTIFYING DISK FILES
CMS commands are provided to list the identifications of files on eMS
and non-CMS formatted disks and minidisks. The LISTFILE command. lists
the entries in the master file directory for CMS disks; the LISTDS
command lists the entries in the VTOC
(volume table of contents) for as
and DOS disks, or for listing data spaces on VSAM volumes.
eMS Tape Support
Each CMS machine can support up to four magnetic tape units at virtual
addresses 181, 182, 183, and 184. They may be 2401, 2402, 2403, 2415,
2420, 3410/3411, or 3420 drives, or a mixture of tape drives.
Three tape-handling commands (ASSGN, FILEDEF, and TAPE) allow you to
specify the modeset of the tape: track (7-track or 9-track), density,
and, for 7-track tape only, the tape recording technique (odd or even
parity, converter on or off, and translator on or off) •
If you do not specify the modeset for a 7-track tape,
CMS issues a
modeset indicating 7-track, 800 bpi (bits per inch), odd parity,
converter on, and translate off. If the tape is 9-track, the density is
assumed to be 1600 bpi (or whatever bpi the tape drive was last set at)
for dual density drives;
for single density drives, whatever bpi the
drive is (800, 1600, or 6250 bpi) is assumed.
As an alternative to specifying mode in each
tape (for example, FILEDEF), you can issue a CMS
the mode for the tape and stays in effect until
this if one of your programs is to use tapes in
mode.
command that uses the
TAPE command that sets
reissued. You must do
other than the default
With one exception, eMS commands permit only unlabeled tapes to be
read or written.
However, the eMS TAPPDS command can read standard as
tape labels. Your programs executing under eMS must use unlabeled tapes
or provide code to create and read their own labels as data records.
Part 1. Planning for System Generation
27
Planning Considerations for CMS
Multivolume tape files are not supported by CMS.
These restrictions only apply when you run CMS.
DOS and as
systems running in virtual machines can continue to read and write tapes
with standard labels, non-standard labels, and no labels on single and
multireel tape files.
!ot~:
The VM/370 operator must attach tapes to
before any tape operation can take place.
your CMS
For information about tape handling in the
"Planning Considerations for CMS/DOS."
virtual machine
CMS/DOS environment, see
eMS Unit Record Support
CMS supports one virtual card reader at virtual address OOC, one virtual
card punch at virtual address OOD, and one virtual printer at virtual
~~~r~~~
no~.
"n~~~
V~/370i
~h~se
de~i~es
are spcolea.
c~s
does
not
support real or dedicated unit record devices, nor does it support a
virtual 2520 Card Punch.
Figure 2 lists the devices supported as
virtual devices by CMS.
CARD READER
The READCARD command reads data records from the spooled card
a CMS disk. Input records of 151 or fewer characters are
Column binary data is not acceptable. Your card decks must be
the virtual reader before a READCARD command can be issued.
the following:
reader to
accepted.
read into
Do one of
•
Place a card deck, containing only one file, in a real card reader
and have CP read it. The card images are placed on a spool file in
the specified virtual machine's virtual card reader. If you are not
logged on when data is spooled to your virtual card reader, the deck
remains in your virtual card reader until you log on and issue the
READCARD command.
•
Transfer records from your virtual card punch or printer to a virtual
card reader (your own or that of another virtual machine).
For more information on reading files from the CMS
the VML170 ~~~ .!!~~§ Guig~.
card reader, see
CARD PUNCH
The eMS PUNCH command causes the specified file to be punched to the
spooled card punch. Records up to 80 characters long are accepted.
Shorter records are padded to 80 characters with blanks filled in to the
right. The following are not supported:
• Punch stacker select
• Punch feed read
• 3525 Multiline Card Print feature
28
IBM VM/310 Planning and System Generation Guide
Planning Considerations for
C~S
PRINTER
The PRINT command prints the specified disk file on the spooled printer.
You can specify whether the first character of each record is to be
interpreted as a carriage control character or as data. Both AS! and
machine code carriage control characters are supported. The file may
have either fixed- or variable-length records.
Editing
Using the CMS Editor, you can create new
display portions of existing files.
files online
or modify
or
The CMS Editor operates on fixed- and variable-length records. The
maximum record length accepted by the editor is 160 characters. You can
specify file characteristics, such as record length, format,
and tab
locations. The system includes defaults for certain filetypes (such as
ASSEMBLE and EXEC).
Files are edited in virtual storage.
The maximum size file that can
be edited is determined by the amount of virtual storage available to
you, minus that used by the CKS nucleus.
If the file does not fit into virtual storage, it must be divided
into smaller files, and each file edited separately.
Sufficient disk
space must be available to accommodate both parts of the file.
Alternately, you can temporarily increase the size of your virtual
storage by issuing the CP DEFINE STORAGE command.
For more
!~370 ~MS
information about
User's GU.i.g~.
the editing facilities
of CMS,
see the
eMS Batch Facility
The eMS Batch Facility is a VM/370 programming facility that executes
under CMS. It allows you to execute jobs in batch mode. You can submit
jobs from a virtual machine or from a real card reader. You do not have
to be logged on to submit jobs to the batch virtual machine.
If you
want to use the batch facility you must define a C8S batch virtual
machine when you create your V~/370 directory. You should include a
read/write disk at virtual address
195 in the directory entry.
Information about the CMS Batch Facility is in the VM~IQ ~~~ User'2
~ig~·
There must be an entry in the VM/370 directory for any user who wants
to submit jobs to the CMS Batch Facility. This entry can be the
minimum: userid, password, and one device. Alternatively,
you can
provide entries for users who will not be logging on to the system, but
submitting jobs through the real card reader. For these users, you can
code the password in the directory as NOLOG; these users do not ne'ed any
devices defined for their virtual machines. The eMS Batch Facility uses
the FOR operand of the CP SPOOL command to identify their output files.
The batch facility provides two entry points so you can add support
that your installation may require. BATEXIT1 is provided so you can
write your own routine to check non-eMS control statements. BATEXIT2 is
provided so you can process additional information on the IJOB card.
These entry points are described in the VM/31Q ~§!~m PrQgrammer'2
Guide.
Part 1. Planning for System Generation
29
Planning Considerations for CMS
You can write EXEC procedures to control
facility virtual machine. See the VM/J70 ~~~
of these EXEC procedures.
the operation of a batch
Guig~ for examples
~§~f~§
Saving eMS
CMS is designed so that it can be saved easily and so that the second
segment of CMS can be shared by CMS users.
Also, CMS is designed so
that CMS/DOS, CMS VSAM and access method services, the CMS Editor, eMS
EXEC processor, and CMS OS simulation routines can be placed in
discontiguous saved segments.
The VM/370 starter system has entries in
the system name table (DMKSNT) and CP system control file
(DMKSYS) so
that you can save CMS (and the CMS discontiguous saved segments) at the
end of the system generation procedure for eMS.
For more information about saved systems, see the "Saved Systems"
sect.ion of this mannal and. see the !M/370 ~!.§!~.! £I:Qg:.!:2.!.~~I~!: E..!!ioe~
30
IBM VM/370 Planning and System Generation
Gui~e
CMS VSAM and Access Method Services
Planning Considerations for CMS VSAM and
Access Method Services
CMS supports interactive program development for as and DOS programs
using VSAM.
CMS supports VSAM for as programs written in VS BASIC,
OS/VS COBOL, or as PL/I programming languages; or DOS programs written
in DOS/VS COBOL or DOS PL/I programming languages. CMS does not support
VSAM for as or nos assembler language programs.
CMS also supports access
VSAM and SAM data sets.
method services to
manipulate as
and DOS
Under CMS, VSAM data sets can span up to nine DASD volumes.
CMS does
not support VSAM data set sharing; however, CMS already supports the
sharing of minidisks or full pack minidisks.
Only one user may have
write access to the VSAM master catalog, but many other users may read
and reference the catalog at the same time.
VSAM data sets created in CMS are not in the CMS file format.
Therefore, CMS commands currently used to manipulate CMS files cannot be
used for VSAM data sets that are read or written in CMS.
A VSAM data
set created in CMS has a file format that is exactly the same as, and
therefore compatible with, as and DOS VSAM data sets. Thus a VSAM data
set created in CMS can later be read or updated by as or DOS.
Because VSAM data sets in CMS are not a part of the eMS file system,
eMS file size, record length, and minidisk size restrictions do not
apply.
The VSAM data sets are manipulated with access method services
programs executed under CMS, instead of with the eMS file system
commands.
Also, all VSAM minidisks and full packs used in eMS must be
initialized with the IBCDASDI program or an appropriate DOS/VS or OS/VS
disk initialization program (if the minidisk is a full pack);
the eMS
FORMAT command must not be used.
In its support of VSAM data sets, eMS uses RPS (rotational position
sensing) wherever possible. eMS does not use RPS for 2314/2319 devices,
or for 3340 devices that do not have the feature.
Hardware Devices Supported
Because CMS support of VSAM data sets is based on DOS/VS VSAM and DOS/VS
access method services, only disks supported by DOS/VS can be used for
VSAM data sets in eMS or for CMS disk files used as input by access
method services. These disks are:
•
•
•
•
•
•
IBM 2314 Direct Access Storage Facility
IBM 231Q Disk Storage
IBM 3330 Disk Storage, Models 1 and 2
IBM 3330 Disk Storage, Model 11
IBM 3340 Direct Access Storage Facility
IBM 3344 Direct Access storage
Part 1. Planning for System Generation
31
CMS VSAM and Access Method Services
•
IBM 3350 Direct Access storage
•
When VM/370 MSS support is installed, and the VM/370
processor is
attached to an MSS, the CMS disk may be defined as a 3330 Model 1
which is mapped by VM/370 to all or part of a 3330V volume.
Programming Languages Supported
CMS supports VSAM for programs written for the following compilers:
1.2.
~Q.lEiler
~Qqram
OS/VS COBOL Compiler and Library
as COBOL Interactive Debug
VS Basic Processor
as PL/I Optimizing Compiler and Libraries
as PL/I Checkout Compiler
DOS/VS COBOL Compiler and Library
DOS PL/I Optimizing Compiler and Library
57qO-CB1
573q-CBq
57q8-II1
5734-PL3
5734-PL2
57q6-CBl
5736-PL3
Data Set Compatibility Considerations
CMS can read and update VSAM data sets that vere created under DOS/VS or
OS/VS.
In addition,
VSAM data sets created under CMS can be read and
updated by DOS/VSE or OS/VS.
However, if you perform allocation on a minidisk in CMS, you cannot
use that minidisk in an os virtual machine in any .anner that causes
further allocation.
DOS/VS VSAM (and thus CMS) ignores the format-5,
free space DSCB on VSAM disks when it allocates extents. If allocation
later occurs in an as machine, os attempts to create an accurate
format-5 DSCB.
However, the format-5 DSCB created by os does not
correctly reflect the free space on the minidisk because os expects it
to be a full pack.
In CMS, allocation occurs whenever data spaces or
unique data sets are defined, and space is released whenever data
spaces, catalogs, and unique data sets are deleted.
ISAM INTERFACE PROGRAM
(lIP)
CMS does not support the VSAM ISAM Interface Program
(lIP). Thus, any
program that creates and accesses ISAM
(indexed sequential access
method) data sets cannot be used to access VSAM key sequential data
sets.
There is one exception to this restriction.
If you have (1) os PL/I
programs that have files declared as ENV(INDEIED) and (2) if the library
routines detect that the data set being accessed is a VSAM data set,
your programs will execute VSAM I/O requests.
32
IBM VM/370 Planning and System Generation Guide
CMS VSAM and Access Method Services
User Requirements and Considerations
Because the CMS support of VSAM and access method services is based on
DOS/VS access method services, you must order a DOS/VS system (Release
31 and above and use the DOS/VS starter system when you install the eMS
VSAM support. In order to install CMS VSAM from the DOS/VS Release 33
starter system, you must be sure to use the current level of VM/370
installation files (Release 3 PLC 8 or later).
Also, the CMS/DOS
support must be installed before you install VSAM under CMS.
Distribution of VSAM and CMS
VM/370 does not distribute the DOS/VS VSAM and access method services
routines that it uses. You are responsible for ordering Release 31 and
above DOS/VS systems. The VM/370 starter system has an installation
EXEC procedure, VSAMGEN, that generates CMS support for VSAM and access
method services using a restored DOS/VS starter system.
Part 1. Planning for system Generation
33
34
IBM VM/370 Planning and System Generation Guide
eMS/DOS
Planning Considerations for CMS/DOS
Installations that use eMS/DOS must also have available a DOS/VS system
(Release 31 and above). Therefore, if you want to use CMS/DOS you must
first order and install a DOS/VS system. Also, if you want to use the
DOS/VS COBOL and DOS PL/I compilers under CMS/DOS, you must order them
and install them on your DOS/VS system.
DOS/VS System Generation Considerations
The CMS/DOS support in CMS uses a real DOS/VS system pack in read-only
mode. CMS/DOS provides the necessary interface and then fetches DOS/VS
logical transients and system routines directly from the DOS/VS system
libraries.
Also, CMS/DOS fetches the DOS/VS COBOL and DOS PL/I
compilers directly from the DOS/VS system or private core image
libraries.
It is your responsibility to order the DOS/VS system and then
generate it.
Also, if you plan to use DOS compilers, you must order the
DOS/VS COBOL and DOS PL/I Optimizing compilers and install them on the
same DOS/VS system.
When you install the compilers on the DOS/VS system,
link-edit all the compiler relocatable modules using the
linkage editor control statement:
you must
following
ACTION REL
You can place the link-edited phases in either the system or the private
core image library.
When you later invoke the compilers from eMS/DOS, the library (system
or private) containing the compiler phases-must be identified for CMS.
You identify all the system libraries to eMS by coding the filemode
letter that corresponds to that DOS/VS system disk on the SET DOS ON
command when you invoke the CMS/DOS environment. You identify a private
library by coding ASSGN and DLBL commands that describe it.
These
DOS/VS system and private disks must be linked to your virtual machine
and accessed before you issue the commands to identify them for CMS.
CMS/DOS has no effect on the update procedures for DOS/VS, DOS/VS
COBOL, or DOS PL/I. You should follow the normal update procedure for
applying IBM-distributed coding changes to them. PTFs that must be
applied are listed in the current VM/370 Release Guig~.
When the DOS/VS System Must Be Online
Most of what you do in the CMS/DOS environment requires that the DOS/VS
system pack and/or the DOS/VS private libraries be available to eMS/DOS.
In general, you need these DOS/VS volumes whenever:
•
You use the DOS/VS COBOL compiler or DOS PL/I compiler •
The
compilers are executed from the system or private core image
libraries.
Part 1. Planning for System Generation
35
CMS/DOS
•
Your DOS/VS COBOL or DOS PL/I source programs contain COPY, LIBRARY,
%INCLUDE, or CBL statements.
These statements copy books from your
system or private source statement library.
•
You invoke one of the librarian programs: DSERV, RSERV, SSERV, PSERV,
or ESERV.
•
You link-edit DOS programs that use LIOCS modules. CMS/DOS link
edits LIOCS routines with the DOS program from DOS/VS system or
private relocatable libraries.
•
You execute DOS programs that fetch phases
system or private core-image libraries.
directly from
DOS/VS
A DOS/VS system pack is usable when it is:
•
•
•
Defined for your virtual machine
Accessed
Specified, by mode letter, on the SET DOS ON command
A DOS/VS private library is usable when it is:
•
•
•
Defined for your virtual machine
Accessed
Identified via ASSGN and DLBL commands
The DOS/VS system pack and private libraries may reside on full packs or
minidisks.
CMS/DOS Tape Handling
CMS/DOS does not process tape labels.
In general, CMS/DOS either
bypasses labels on input tapes or passes control to a user routine to
process header labels on input tapes. CMS/DOS processes all output
tapes as tapes with no labels.
Trailer labels are not supported for
input tapes or output tapes.
CMS/DOS passes control to user label routines, if there are any, for
input tapes with standard or nonstandard labels.
If a tape which is opened as an output tape already has a header
label (standard or nonstandard), CMS/DOS writes over that label when it
writes data to the tape.
There is no equivalent in CMS/DOS to the DOS/VS TLBL
statement. The TLBL label function is not required in CMS/DOS.
control
Standard Label Cylinder
CMS/DOS does not support a standard label cylinder. If the real DOS/VS
system pack used by CMS/DOS has a standard label cylinder, it is not
used.
In CMS/DOS, ASSGN and DLBL commands
those provided by the DOS/VS ASSGN, DLBL,
In DOS/VS those control statements are
Thus, it is convenient to place often
statements on the standard label cylinder.
36
provide functions similar to
and EXTENT control statements.
in effect only for one job.
used DLBL and EXTENT control
IBM VM/370 Planning and System Generation Guide
CMS/DOS
However, in CMS/DOS, there is no such thing as a job. Consequently,
ASSGN and DLBL commands remain in effect for an entire CMS/DOS session,
unless they are reset by another ASSGB or DLBL command.
Also, in CMS,
you can place all the commands you need to compile and execute a program
in an EXEC file and invoke that EXEC file by its filename.
Part 1. Planning for System Generation
37
38
IBM VM/370 Planning and System Generation Guide
Planning Considerations for Other Virtual
~achines
Planning Considerations for Virtual Machine
Operating Systems (Other than CMS)
This section contains information about the following:
•
•
•
•
•
The V8/VS Handshaking Feature
~ultiple Virtual Machines Using the Same Operating System
The RSCS Virtual ~achine
V~/370 Using Channel Switching
Operating Systems Using Reserve/Release
The VM/VS Handshaking Feature
The V~/VS Handshaking feature is a communication path between VM/370 and
certain other system control programs (such as OS/VS1)
that makes each
system control program aware of certain capabilities and requirements of
the other. The VM/VS Handshaking feature consists of:
•
Processing pseudo page faults
•
Closing VM/370 spool files when the system
writer operation is complete
•
Providing an optional nonpaging mode
under the control of VM/370
•
Providing miscellaneous enhancements for
an operating
virtual machine executing under the control of VM/370
control program's output
for operating systems executing
system's
A page fault is a program interrupt that occurs when a page that is
marked "not in storage" is referred to by an instruction in an active
page. The virtual machine requesting the page is placed in the wait
state while the requested page is brought into real storage.
However,
with the V~/VS handshaking feature, a multiprogramming operating system
executing under the control of VM/370 in a virtual machine may dispatch
one task while waiting for V8/370 to honor a page request for another
task.
When the pseudo page fault portion of V8/VS Handshaking is
active, V8/370 sends a pseudo page fault (program interrupt X'14') to
the guest system. When the guest system recognizes a pseudo page fault,
it places only the task waiting for the page in page wait and can
dispatch any of its other tasks.
Since no paging is done by the operating system using VM/VS
handshaking, ISAM programs are treated by V~/370 as if they are being
run from fixed storage locations. Therefore, in order to execute the
ISAM program successfully, the virtual machine directory must include
the ISAM option.
When the handshaking feature is active, the operating system using
VM/VS handshaking closes the CP spool files by invoking the CP CLOSE
command when the task or job has completed. Once these spool files are
closed, they can be processed by V~/370 without operator intervention.
Part 1. Planning for System Generation
39
Planning Considerations for Other Virtual Machines
Operating systems using VM/VS handshaking can execute in nonpaging
mode.
Nonpaging mode exists when (1) the handshaking feature is active,
and (2)
the operating systems virtual storage size equals the virtual
storage size of the VM/370 virtual machine. When the guest operating
system executes in nonpaging mode, fewer privileged instructions are
executed and duplicate paging is eliminated.
Note that such a virtual
machine may have a larger working set when it is in non paging mode than
when it is not in nonpaging mode.
Also, there are some other enhancements for guest systems using VM/VS
handshaking while executing under the control of VM/310@
With the
handshaking feature,
the guest system avoids some of the instructions
and procedures that would be inefficient in the VM/310 environment.
When the VM/VS Handshaking feature is active, the operation of a
system control program closely resembles the standalone operation
because much redundancy of function between VM/310 and the operating
system is eliminated.
For instance:
•
One VS1 task can be dispatched while another is waiting for a page to
be brought into real storage.
•
There is less need for the virtual machine operator to intervene
because output files are automatically closed and processed.
Even when the handshaking feature is active for a virtual machine,
the pseudo page fault portion of the handshaking feature is not
available until it is set on with the CP SET PAGEX ON command; this
command can set pseudo page fault handling on and off.
BQt~:
MUltiple Virtual Machines Using the Same
Operating System
In general, an operating system which is to run in a virtual machine
should have as few options generated as possible. This is also true
when several virtual machines share a system residence volume. Very
often, options that improve performance on a real machine have no effect
(or possibly an adverse effect) in a virtual machine. For example, seek
separation, which improves performance on the real machine, is redundant
in a virtual machine: CP itself issues a standalone seek for all disk
I/O.
Sharing the system residence volume makes it unnecessary to keep
multiple copies of the operating system online.
The shared system
residence volume should be read-only.
The CMS system residence volume, for example, is read-only, so it can
be shared among virtual machines.
CMS discontiguous saved segments can
also be shared among all virtual machines; they are outside the virtual
storage of each
of the sharing virtual
machines.
The eMS/DOS
environment of
CMS simulates DOS/VS supervisor
and input/output
functions, thereby allowing execution of many DOS programs.
DOS and OS
systems can be shared among users if all data sets with write access are
removed from the system residence volume.
Refer to the VK111Q Syste!
R~Qgramm~£!§ Qui£~ for more details.
40
IBM VM/370 Planning and System Generation Guide
March 3, 1980
Planning Considerations for Other Virtual Machines
The RSeS Virtual Machine
The Remote Spooling Communications Subsystem
(RSCS), operating in a
virtual machine, handles the transmission of files between VM/370 users
and remote terminals and stations. Figure 4 illustrates a typical RSCS
co nfigura tion.
Three lines of the real 3705, operating in 2703 emulation mode, are
shown dedicated to the RSCS virtual machine. The communication lines are
shown attached to a 3780 Data Communication Terminal, a System/3, and an
as/HASP processor running in a remote System/360 or System/370.
The RSCS machine uses the spooling facilities of VM/370 as the
interface between virtual users and itself.
Any user who wishes to have
an output file transmitted to a remote location must associate tag
information (such as destination and priority) with his file via the TAG
command and spool the file to the RSCS machine's virtual reader. RSCS
analyzes the tag data, enables the appropriate line,
and transmits the
data using the line protocol required by the receiving station.
Remote locations can submit card files to the RSCS machine and
address them to either a VK/370 user or to RSCS itself for transmission
to another remote station. RSCS produces a VM/370 spool file by writing
that data to virtual unit record devices and, if the file is destined
for a VM/370 user,
sends it to the user's virtual reader via the CP
SPOOL command.
If the file is addressed to RSCS, it is queued on RSCS's
virtual reader and then handled in the same manner as a file spooled to
RSCS by a VM/370 user. In this case, it is the responsibility of the
remote station that originated the data to supply the tag information.
RSCS can also function as a remote workstation of a HASP/ASP type
batch processor. VM/370 users and remote stations can submit jobs to
RSCS for transmission to the HASP system.
After processing,
HASP can
return printed and/or punched output to RSCS for spooling to the real
system printer or punch. For more information about RSCS, see the
Y~Ll1Q ~~~21~ ~EQQli~ £g~~ygi£~tiQll§ SUQ§Y§te~
(E~£~)
Q§~h~§ ~Y1g~·
RSCS PLANNING CONSIDERATIONS
the files
All
tape.
you need
to generate
RSCS
are
on the
RSCS/IPCS
Before you perform the RSCS generation procedure, be sure you have a
virtual machine defined for RSCS.
The virtual machine you intend to run
RSCS should have:
•
512K of virtual storage
•
A reader
•
A ccnsole
•
A minidisk for the RSCS system residence volume.
The RSCS system
disk must have a write password.
See the section "Defining Your RSCS
Virtual Machine" in Part 3 .•
You can define more than one RSCS virtual machine. Also,
you can
have more than one RSCS virtual machine running at the same time.
However, when multiple RSCS
virtual machines are running at the same
time, each must have a unique user identification (userid)
and local
location identification (ID=linkid).
Part 1. Planning for System Generation
41
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
Planning Considerations for Other Virtual Machines
System/370
VMl
RSCS
I
I
Control Proqram of VM/370
Virtual
2703
I
Virtual
2703
Virtual
2703
I
I
Real 3705 (in 2703 EP Mode)
Figure 4.
I
I
j
Data
Set
Data
Set
Data
Set
J.
.L
1
T
T
T
Data
Set
Data
Set
Data
Set
I
I
I
3780
System/3
as/HASP
Processor
A Remote Spooling Communications Subsystem
When you code the GENLINK
macros during the RSCS generation
procedure, you must code the local location identification on the first
GENLINK macro.
Information about generating and installing RSCS
Generating VM/370 (CP, CMS, RSCS and IPcs).n
is
in "Part
3.
VM/370 Using Channel Switching
The two- or
environments:
four-channel
switch
can
be
used
in
the
following
•
Two processors, one running VM/370 and the other running an operating
system that supports channel switching.
I.
I
I
Two virtual machines
running under VM/370; each virtual machine
operating system must support the channel switch feature
(eMS does
not).
42
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
Planning Considerations for Other Virtual Machines
I.
I
A single virtual machine running under VM/370; the virtual machine
operating system must support the channel switch feature.
I.
I
I
I
A processor running VM/370 and managing multiple paths to devices
through the VM/370 alternate path support.
Refer to the section on
"Alternate Path Support" in this document for a discussion on the
VM/370 alternate path support.
You can use the two- or four-channel switch for devices attached to
two processors. For example, one processor could be running VM/370 and
the ether could be running as as shown in Figure 5.
PROC 1
,..-----,
I
I
I as
lI'-- _ _ - - lI
-----------------r-----~--r------y___---~~--___,
I 2
f
I Channel I
Switch
,
I
I
I
I
I
~---+-----+------+
I
I
I
I
I
I ____
~---L
L-r----..&.---
,290- 2 97
I 390-397
,
I
,
I ______J,
~
I
PROC2
I
r-------,
I
I
I
I
I VM/3701----------J
I
I
'--------'
Figure 5. Channel Switching between Two Processors
VM/370 requires the following
this configuration:
RDEVICE
RDEVICE
RCTLUNIT
RCTLUNIT
RDEVICE and
RCTLUNIT macros
to support
ADDRESS=(290,8),DEVTYPE=3330
ADDRESS=(390,8) ,DEVTYPE=3330
ADDRESS=290,CUTIPE=3830
ADDRESS=390,CUTYPE=3830
These macros make it possible for you to run VM/370 on PROC1 or PROC2.
If you are always going to run VM/370 on PROC2, you can eliminate one
path (eliminate one set of RDEVICE and RCTLUNIT macros).
Part 1. Planning for System Generation
43
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
Planning Considerations for Other Virtual Machines
If any I/O devices controlled by VM/370 for its own exclusive use are
attached to a control unit with a two- or four-channel switch, the
processor controlling the other channel interface must vary the CP-owned
devices offline. For example, if all eight disks in the preceding
configuration are mounted and two of those disks are CP-owned volumes
(such as CP system residence and CP paging and spooling volumes), the Os
system running on PROCl must vary the CP-owned volumes offline. This
procedure protects volumes that CP needs.
You can also use the Two- or Four-Channel Switch for devices attached
to one processor that is running VM/370. For example, one processor
could be running VM/370 with as running in a VM/370 virtual machine as
shown in Figure 6. In this case, the virtual machine operating system
supports channel switching.
,
r
PROCl
r-
I
i
I
r·-~----!.-----~
.J
----,
I VM/370
I
tI
I t I I
10SI
'--___
.J
2Channel
Switch
-_._-
-,
- --
--'·"·--·"~'--~·-''''''''·~·''''''''---T---'
290-297
390-397
I
I
f-·----+-----+------+------I
I
I
I
I
L--r--~
I
I
,
,.1.__
I
,
. __ --.L _ _ _ _-.J
I
L ____________ ---.J
Figure 6. Channel Switching on One Processor
VM/370 requires the following
this configuration:
RDEVICE
RDEVICE
RCTLUNIT
RCTLUNIT
RDEVICE and
RCTLUNIT macros
to support
ADDRESS=(290,8) ,DEVTYPE=2314
ADDRESS=(390,8) ,DEVTYPE=2314
ADDRESS=290,CUTYPE=IFA
ADDRESS=390,CUTYPE=IFA
For this example, you should have all the devices associated with one
path offline when you load V~/370. Otherwise, the following message is
displayed:
DMKCPI954E DASD raddr VOLID volid NOT MOUNTED,
DUPLICATE OF DASD raddr
The 2314 DASD devices can be used by the OS system running in a
virtual machine if they are dedicated to that virtual machine via the
ATTACH command or the DEDICATE
control statement in the VM/370
directory.
The device addresses generated for the virtual machine
operating system need not be the same as those defined for the real
machine.
As another example, consider channel switching for tapes.
If the
real configuration includes a 2816 Switching Unit or a Two- or
Four-Channel Switch Feature, it can be made to operate under control of
a virtual machine operating system. For example, if 580 and 680 are the
alternate device addresses for a particular tape drive, then:
•
44
Generate the virtual machine operating system for the appropriate
hardware (in this case a 2816 Switching Unit on channels 5 and 6).
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated March 3 r 1980 by TNL GN25-0776
Planning Considerations for Other Virtual Machines
•
Generate CP as though 580 and
680
different control units and channels) •
are different
devices
(with
•
Issue the CP ATTACH command for both device addresses
(580 and 680)
whenever the real device is to be attached to the virtual machine.
The device addresses generated for the virtual machine operating
system do not need to be the same as those on the real machine.
The devices must be used by
(a ttached r or def ined
wi th
directcry) •
the virtual machine as dedicated devices
a DEDICATE statement
in the VM/370
VM/370 alternate path logic provides support for the two channel
switch r two channel switch additional feature r and the string switch
feature.
The purpose of alternate path support is to define alternate
paths to a given device on the VM/370 processor. The virtual operating
system does NOT define alternate paths. Instead r VM/370 would define
alternate paths to the device by the RCTLUNIT and RDEVICE macros r
respectively.
VM/370 would then perform
the alternate path I/O
scheduling.
Using Figure 6 r if the installation wanted VM/370 to
perform the alternate path I/O scheduling instead of the virtual
operating system r
the following RDEVICE and RCTLUNIT macros would be
required:
RDEVICE ADDRESS=(290,8) rDEVTYPE=2314
RCTLUNIT ADDRESS=290,CUTYPE=IFA r ALTCH=(3)
RCHANNEL ADDRESS=3
RCHANNEL ADDRESS=2
Channel-Set Switching Facility
The channel-set switching facility is a
feature available on the 3033
attached processor system.
This feature permits a set of channels to be
switched from one processor to another in a multiprocessor or attached
processor environment. A channel-set is the collection of channels that
are switched as a group.
On a 3033 attached processor system r all
online channels comprise the channel-set.
The switching operating directs the execution of I/O instructions and
I/O interruptions from the main processor to an attached processor, thus
permitting an operator to
vary the main processor offline.
The
switching operation does not control other channel activity,
such as
data-transfer operations and chaining.
In 3033 attached processor environments~ channel-set switching is
used to continue system operation in uniprocessor mode when the main
(I/O)
processor is taken offline as the result of a VARY PROCESSOR
OFFLINE command or a main processor failure.
This support switches the
channel-set from the main processor to the attached processor.
There are no required system generation macro instructions to support
channel-set switching.
In the event of a failure on the main (I/O)
processor, trre automatic processor recovery routine determines if
channel-set switching capability exists.
If there is no channel-set
switching capability in the system r CP enters the wait state with a wait
state code of X'OOOl'.
If the error is TaD clock damage and the
processor is in problem state and equipped with the channel-set
switching facility, the I/O processor is taken offline. The channel-set
switching feature is used to disconnect the channel-set from the failing
I/O processor and to reconnect
the channel-set to the attached
processor. The system continues processing on the attached processor in
uniprocessor mode.
Part 1. Planning for System Generation
45
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
Planning Considerations for Other Virtual Machines
The following message is issued when
the attached processor:
the channel-set is connected to
DMKCPU6231 - CHANNEL-SET CONNECTED TO PROCESSOR nn
Operating Systems Using Reserve/Release
Shared DASD is the term
used to describe the capability of accessing
direct access devices from two or more systems.
The systems can be in
virtual machines on the same real processor or on different real
processors.
Device access by the sharing systems is sequential.
Sharing of DASD devices can occur when:
I.
t
A two- or four-channel
or tour channels.
I.
I
String switching is utilized and the control units to which they are
switched are on channels of two different systems.
switch attaches a device's control unit to two
With Shared DASD, an I/O operation may be started to a shared device
from any of the systems able to access the device by means of the
switch. Each sharing system vies for the programmable switch to gain
device access.
The first requesting system gets the switch set to its
interface so that it may perform I/O operations to a shared device.
When the switch returns to the neutral position, any other system, or
the same one,
may select the shared device and have the switch set to
its interface.
It is important to note that none of the sharing systems is aware of
what the other is doing with the data on the shared devices.
Data
integrity is the responsibility of the using program. For this reason,
the hardware command, RESERVE, may be issued by a program to retain
exclusive use of a shared device while a critical update to data is
being performed.
Device RELEASE is issued to terminate the exclusive
reservation.
If a shared device has been reserved for exclusive use,
the system channel through which the reserve was issued will lock out
any other channel,
on the same or different system,
from accessing the
device.
Reasons for Sharing:
There are several
between systems:
reasons an installation would elect
to share devices
I.
I
I
I
I
Scheduling of
jobs is simplified and operator intervention is
minimized.
Instead of being moved from one system to another, the
volume remains mounted and available to each system able to access
the data by means of the two- or four-channel switch or string
switch.
I.
I
I
Updating of data is minimized. One update to a shared data set is
needed, instead of the multiple updates that would be required if
each of several systems had its own copy of the data set.
I.
I
I
Backup and switchover in the event of hardware failure is facilitated
in a multi-system environment if the needed data is accessible to
surviving systems without moving it.
I.
I
Direct access storage space may be saved,
required instead of multiple copies.
46
as one copy of the data is
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
Planning Considerations for Other Virtual Machines
Two assembler language macros, RESERVE and DEQ, are available to effect
the reserving and releasing of a device. The data integrity of shared
devices can be maintained by application program use of the RESERVE
macro or by operating system components which automatically issue the
reserve macro if the target of their update operation is to a shared
device. CMS does not make use of these macros in its CMS file system.
In addition, CMS does not support these macros in the as simulation or
CMS/DOS simulation packages.
The SHAREOPTIONS operand which appears on
the access method services control statement has no function in CMS.
No
attempt is made by CMS VSAM to reserve or release system resources. The
use of shared DASD by virtual machines should be limited to those quest
operating systems which will maintain the integrity of shared data, such
as catalogs, VTOCS, program libraries, etc., and will support the use of
the RESERVE and DEQ macros used by application programs running under
thosE operating systems.
The only other alternative is the use of the
hardware reserve or release CCWs by an application program running under
CMS.
In this case the application program issues the hardware reserve
and release CCWs in a SIO or DIAGNOSE operation to the shared device.
VM/370 reserve/release support can be
DASD and Virtual Reserve/Release.
addressed in two forms: Shared
Shared DASD refers to the use of reserve/release CCW strings by
virtual machine or processor operating systems for the
purpose of
preserving data integrity. The integrity of the data is preserved by the
hardware on a device basis during the interval of time between the
reserve and release CCWs by not allowing access to the reserved device
via any other path.
Virtual reserve/release is the software simulation of reserve/release
CCWs for minidisks. Since virtual devices associated with a minidisk all
map to the same real channel interface to the device, the hardware
protection is lost and a software locking structure is required to
maintain the data integrity during reserve/release seguences.
The VM/370 control program and the CMS operating system do not issue
reserve CCws. The use of reserve/release remains the full responsibility
of
the operating system running in the virtual machine. The VM/370
initialization routine issues a release CCW to tape and DASD devices to
dynamically determine whether the two-or-four channel switch feature is
installed.
I SHARED DASD
Operating systems that support Shared DASD use reserve/release CCws to
preserve data integrity in the following environments:
I •
I
I
I
Two virtual machines running under VM/370 with each operating system
having a separate channel path to the device to be shared; each
virtual operating system uses reserve/release CCws to preserve data
integrity.
Reserve/Release CCWs are recognized by the VM/370 control program CCW
translation routine and are executed by the hardware to preserve data
integrity. In this environment devices should be generated, at system
generation time in DMKRIO, as separate devices. Each device should be
dedicated to a virtual machine by means of the
ATTACH command or
DEDICATE control statement in the directory.
Part 1. Planning for System Generation
47
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
Planning Considerations for Other Virtual Machines
I.
I
I
I
I
I
A virtual machine runs under VM/370 and shares a device with another
processor;
the operating
system in the virtual
machine uses
reserve/release CCWs to preserve data integrity. The operating system
running on the other processor can be VM/370, in which case the
virtual machine operating system uses reserve/release CCWs, or a
non-VM/370 operating system with reserve/release capability.
Tc support this environment, the device should be dedicated to the
VM/370 virtual machine by means of the ATTACH command or DEDICATE
control statement in the VM/370 directory.
In the above shared DASD environments, the use of reserve/release by
virtual machine operating systems and the VM/370 alternate path support
are mutually exclusive. The VM/370 control program changes a reserve CCW
to a sense CCW when an alternate path has been defined for the device.
The protecticn offered by the hardware
reserve is lost. It is
recommended that a single path be defined in VM/370 for devices which
will be dedicated to virtual machines and then shared between other
virtual machines or processors.
I.
I
I
I
I
I
I
A virtual machine runs under VM/370 and shares a device with another
processor;
the operating
system in the virtual
machine uses
reserve/release CCWs to preserve data integrity. The operating system
running on the other processor can be VM/370, in which case the
virtual machine operating system should use reserve/release CCws to
maintain data integrity, or a non-VM/370 operating system with
reserve/release capability.
The device can be defined as a
minidisk, on the VM/370 processor,
which begins at real cylinder O. Again the use of reserve/release and
alternate path support are mutually exclusive. It should be noted that
virtual reserve/release support should not be used in this environment.
The volume being shared should not contain more than one minidisk or be
used for CP paging, spooling, etc., since reservation by the other
processor could lock out virtual machine users or VM/370 system I/O
requests to the same device.
VIRTUAL RESERVE/RELEASE
The reserve/release software simulaticn in VM/370 provides reserve/
release protection at the minidisk
level,
including full volume
minidisks. Virtual
reserve/release is intended for ~se by the virtual
machines that support Shared DASD (not CMS)
runn1ng on the VM/370
processor. Virtual reserve/release simulation is reguested by appending
a character "V" to the mode operand on the MDISK statement in the
directory. All subsequent links to this minidisk are subject to virtual
reserve/release processing. A software locking structure is created to
manage the reservation status by minidisk. The VM/370 control program
then examines virtual machine channel programs and manages the reserve/
release CCWs presented by the sharing virtual machines. The VM/370
control program simulates the hardware reserve by reflecting a "device
busy" condition in response to a virtual machine SIO when the minidisk
is already reserved by another virtual machine.
When the minidisk is
released, a "dev ice end" interrupt is reflected to all virtual machines
users who received a "device busy" indication. Diagnose users can also
issue reserve/release CCws. However, no "device busy" or "device end"
status is reflected to the virtual machine. If a minidisk is already
reserved, a subsequent Diagnose request for another virtual machine is
queued until the minidisk is released, at which time the Diagnose
request will be redriven.
48
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
Planning Considerations for Other Virtual Machines
VM/370 CONTROL PROGRAM HANDLING OF A RESERVE CCW
VM/370 reserve/release support and the VM/370 alternate path support are
mutually exclusive. The VM/370 CCW translation routine changes a reserve
CCW to a sense CCW when alternate paths have been defined to the device
from the VM/370 processor. Data integrity is not preserved when sharing
a device between processors or virtual machines and alternate paths are
defined. When using virtual reserve/release to share a minidisk between
virtual machines on the VM/370 processor, VM/370 still changes a reserve
CCW to a sense CCW when alternate paths are defined to the real device.
Part 1. Planning for System Generation
11 n
"to.
"
I
Page of GC20-1801-10 As Updated Karch 3, 1980 by TNL GN25-0776
Planning Considerations for other Virtual Machines
Ho wever, since the hardware reserve/release is simulated when virtual
reserve/release is being used, the data integrity is preserved when
al ternate pa ths are
defined.
The chart below
identifies those
si tuations when the VK/370 control program changes a reserve CCW to a
sense CCi.
r--
IReserve/Release,Virtual Reserve ,CCi Comnd,
I
I Type
Alternate IExecutes in the,Release Requestedlsent by ,
Pa th
,Hardware (2-4 '(V Added to
,VM/370 to,
I of
I Device
Support
,Channel Switch) I Mode in MDISK)
,Device I Note
I
IDedicatedlNot defined, Not applicable, Not applicable
Reserve
1
,DASD or ,
Not applicable, Not applicable
Sense
ITape
IDefined
2
I
Yes
No
Reserve
IMinidisk INot defined,
1
I
I
l i N ot d~r lil.ad i
i es
Ye!:;
Re serve
I
,
I
,-----------------------I Not def ined I
No
I
1-----------------
I
I
1
No
I Not def inedl
No
YES
I
,Defined
Not applicable, Not applicable
1----------------------11NormalOperation
The
Reserve
,
3,
I
Sense , 4,
-------1
Sense I 5 I
I
,
command is passed unchanged to the hardware. I
2When the VK/370 system has been generated with alternate path support'
for those devices, it prevents the devices from being reserved. Thisl
action causes VK/370 to avoid a possible channel lockout. VM/3701
does not return any indication of this action to the operating system,
issuing the CCW command that the device was not reserved.
,
3Without the two-channel switch special feature, VM/370 sends
the
reserve/release CCW command unchanged to the hardware. However, the
hardware rejects the command and does not reserve the device.
,
+Before sending the command to the hardware, VM/370 changes the
reserve CCW command to a sense CCW command and places a virtual
reserve on the minidisk. The real device is not reserved. The
virtual reserve prevents other operating systems running under the
same VM/370 system from accessing the minidisk; however, these same
virtual operating systems may virtually reserve other minidisks
located on the same real volume. Because the two-channel switch
feature is not installed on the channels, only one address path goes
to the device from the VM/370 processor. This path allows V8/370
virtual reserve/release processing to send a sense CCW to the device,
although the reserve CCW command would be rejected by the hardware.
5When alternate paths to a device have been defined (by the ALTCU
operand on the RDEVICE macro instruction and the ALTCH operand on the
RCTLUNIT macro instruction), VK/370 changes reserve/release CCW
commands to sense CCW commands to prevent a possible channel lockout.
L------------~---------------------------------------------------------J
Figure 7. Summary of VM/370 Reserve/Release Support
48.2
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
Planning Considerations for Other Virtual Machines
RESTRICTIONS: DEVICE SHARING BETWEEN REAL PROCESSORS
I.
I
I
I
I
I
When a device is shared between processors and at least one of the
processors is running VM/370, the shared volume cannot contain more
than one minidisk. The single minidisk may encompass the entire
volume or a small portion of the volume and the remainder of the
volume must not be referenced by CP for use as paging, spooling,
etc., or by any virtual machine.
I.
I
I
I
I
I
I
Devices shared between processors must not be generated in VM/370's
DMKRIO as having alternate paths. If there are multiple paths from
the VM/370 processor to the shared devices, as well as a path from
the same devices to another processor, the paths from the VM/370
processor cannot be generated in DMKRIO as alternate paths via the
ALTCH or ALTCU macro operands. lhi§ mg~n§ ~ha1 1hg deiini1i2n 2i
g!!erna!~ Eg!hs
!~ Q~!jIQ
gng !~~ y§~ 2t ~gg! ~g§~!gL~g!~~~ ~~~
~~!ua!lI ~~£lus~~~.
RESTBICTIONS: DEVICE/MINIDISK SHARING ON A SINGLE PROCESSOR
I.
I
I
I
I
I
I
I
If more than a single path to a volume exists, DMKRIO may be
generated so that each path is defined as a separate path, not as an
alternate path. When this is done, each path can be attached or
dedicated to a different user, and reserve/release CCws issued by
such users preserve the data integrity. In this case, the integrity
is preserved by the hardware, not by the software reserve/release
support. !,gg!n, th~ definitiQll 2t al~~rn~te ,Eath§ in !H1!RIQ gng 1h~
~§§ of ~gl !~~!ve/£§!~g~~ g!~ !~~~!1I ~!£!~§iv~.
I.
I
I
I
I
I
I
I
I
A volume may be defined through the Directory to contain one or more
minidisks.
Such minidisks must be identified through the MDISK
statement as requesting virtual
reserve/release support. These
minidisks may then be shared between virtual machines that support
Shared DASD and the data integrity is preserved by the use of
reserve/release CCWs
in the virtual machine
channel program.
Alternate paths may be defined to the device when using virtual
reserve/release. The reserve CCW will still be changed to a sense CCW
but the integrity will be preserved by the virtual reserve/release
--.:1-
,",vue.
Virtual Machine Communication Facility
The Virtual Machine Communication Facility (VMCF)
allows one virtual
machine to communicate and exchange data with any other virtual machine
operating under the same VM/370 system.
The VKCF external interrupt
masking is controlled by PSW bit 7 and CRO bit 31.
It is to a user's
advantage to always have CRO bit 31 set to 1 (while VMCF is in use) and
control the interrupts with PSW bit 7 only.
This reduces the number of
LCTL instructions.
Part 1. Planning for System Generation
48.3
!1arch 3,
48.4
1980
IBM VM/370 Planning and System Generation Guide
Planning Considerations for Other Virtual Kachines
Kessages and data directed to other virtual machines are logically
identified via the virtual machine's userid.
Data is transferred in
2048-byte blocks from the sending virtual machine's storage to the
receiving virtual machine's storage.
The amount of data that can be
moved in a single transfer is limited only by the sizes of virtual
machine storage of the respective virtual machines.
Use of real storage is minimal. Only one real storage page need be
locked during the data transfer.
A special interrupt is used to notify
one virtual machine of a pending transfer of data; this interrupt is
also used to synchroniz~ sending and receiving of data.
Under the Special Kessage Facility, CP acts as a virtual machine in
behalf of a virtual machine that issues the CP command SKSG. The
receiving virtual machine, properly programmed to accept and process
special messages, authorizes itself to CP. Data (message)
transfer is
from CP, via the message and VKCF modules.
SUMMARY OF VKCF FUNCTIONS
VMCF functions include five data transfer operations and seven control
functions. Figure 8 contains a brief summary of VKCF functions.
A more
detailed description of these functions and how they are implemented in
VK/370 is contained in the !!LlI~ Syste~ programmer's Guid~.
The data transfer operations involve the movement of data from one
virtual machine's storage to another virtual machine's storage.
The
VMCF control functions allow a user to manage data transfer operations
from the virtual machine console.
VKeF is implemented via the CP DIAGNOSE instruction in VM/370; it is
not hardware dependent. VKCF is available to any logged-on, authorized
VK/370 virtual machine.
Part 1. Planning for System Genera tion
49
Planning Considerations for Other Virtual Machines
r
i
ICode t
IFunction
I
AUTHORIZE
I
UNAUTHORIZE
Control
Control
Comments
I
,Terminates VMCF activity.
I
1Directs a message or block of data to another I
virtual machine.
I
Data
SEND/RECV
Data
Provides the capability to send and receive
data on a single transaction.
SENDX
Data
Directs data to another virtual machine on a
faster but more restrictive protocol than the
SEND function.
CANCEL
REPLY
QUIESCE
RESUME
, IDENTIFY
I
I
I REJECT
I
I
I
,Data
I
I
I Control
I
I
I
,
IData
I
I
I Control
I
I
I
I Control
,
I
1
,Control
,
,,, Control
I
,,,
I
SEND
RECEIVE
,
1Initialize VMCF for a given virtual machine.
IOnce AUTHORIZE is executed, the virtual
I
Imachine can execute other VMcr functions and I
Ireceive messages or requests from other
I
,users.
Allows you to accept selective messages or
data sent via a SEND or SEND/RECV function.
Cancels a message or data transfer directed
to another user but not yet accepted by that
user.
Allows you to direct data back to the
originator of a SEND/RECV function,
simulating full duplex communication.
Temporarily rejects further SEND, SENDX,
SEND/RECV, or IDENTIFY requests from other
users.
Resets the status set by the QUIESCE function
and allows execution of subsequent requests
from other users.
Notifies another user that your virtual
machine is available for VMcr communication.
Allows you to reject specific SEND or
SEND/RECV requests pending for your virtual
machine.
r-----------------------~------------------------------------------~
ItData indicates a data transfer function.
I Control indicates a VMCF control function.
L-
Figure 8.
50
Virtual Machine Communication Facility (VMCF) Functions
IBM VM/370 Planning and System Generation Guide
3270s
Planning Considerations for 3270s
attachments can be considered either local or remote.
Local
attachments are all devices that do not require telecommunication lines.
However, many devices that are supported for local attachment are also
supported for remote attachment. Remote attachments are devices that
are attached to binary synchronous lines. Such configurations usually
include:
V~/370
•
•
•
a designated channel
a designated communication controller or transmission control unit
the device or control unit
(for terminal attachment and/or RJE
systems) .
Remote Attachments
Both remote cluster
support includes:
and standalone configurations are
supported.
This
•
Nonswitched point-to-point binary synchronous transmission.
•
Switched binary synchronous transmission
with the Dial feature only.
•
Cluster configurations of up to 32 display stations and/or printers.
•
The local 3270 copy function.
•
EBCDIC (Extended Binary Coded
code only.
•
3270s supported as virtual machine operator consoles.
•
CP commands allowing the operator to activate and deactivate
teleprocessing lines, display stations and printers.
•
CMS Editor support.
•
The recording of MDR (Miscellaneous Data Recorder) records and OBR
(Outboard Recording) records on the VM/370 error recording cylinder.
The MDR records are for the station and the OBR records are for the
line. The CPEREP program edits and prints these records.
for 3275 terminals equipped
Decimal Interchange Code)
transmission
the
The 3270 copy support allows the user to assign a screen copy
function to a 3270 program function key.
pressing that key transfers
the current display image, in its entirety, to an available printer
attached to the same control unit. If the printer is busy or otherwise
not available when the copy function is invoked, the virtual machine
user receives a NOT ACCEPTED message in the screen's status area.
The following restrictions apply to V"/370's support of remote 3270s:
•
3270 terminals cannot
consoles.
be used as primary or
alternate V"/370 system
Part 1. Planning for System Generation
51
3270s
•
The number of binary synchronous lines supported by VM/370 for 3270
use is 16 minus the number of 3704/3705 Communications Controllers in
NCP mode minus one
(if there are any 3704/3705 Communication
Controllers in EP mode).
•
The CP DIAL command is not supported.
3270 Support on Binary Synchronous Lines
The supported display devices on binary synchronous lines have the same
flexibility and usefulness as locally attached 3270 devices, except for
the following limitations:
•
Dis~lay Info~ation lnguiry ~lig Retrieval Speeg -- Because the 3270
remote stations are subject to (1)
relatively slow teleprocessing
transmission speeds and
(2) the mechanics of polling ope~ations,
screen display and data entry are not as rapid for remote 3270
devices as they are for locally attached 3270s.
•
CP DIAL ~ng !TT!~n Com~ng~ -- The CP DIAL and ATTACH commands are
not supported for remote 3270 stations.
•
Hard £2£I of 1270 ~~een Imag~ -- Just as users of locally attached
32 7 0 display devices can spool their virtual console input and output
to the system printer, so can the users of remote 3270 display
devices. However, for remote 3270 users, and those local 3270 users
whose terminals may be physically distant from the system printer,
V~/370 provides a limited hard-copy facility
at the local and remote
locations.
•
IES! RE2Y~ST and ~YSIEK IEST Eeys -- These keys on the 3270 terminal
are not supported for remote 3270s. The Test Request function on
locally-attached 3277s is supported by the TEST REQUEST key; it is
supported on locally-attached 3278s by the SYSTEM TEST key.
Remote Hardware Configurations Supported
VM/370'S support of remote 3270s requires:
•
•
•
a binary synchronous line
a transmission control unit
terminal devices (display stations and/or printers)
and associated control units
The binary synchronous line must
be in 2701/2703 mode.
The
transmission control units supporting remote 3270s on binary synchronous
lines are:
•
Integrated Communications Adapter (ICA).
•
IBM 2701 Data Adapter Unit with Synchronous Data Adapter Type II.
•
IB~
•
IBM 3704 and 3105 Communications Controllers in emulation mode.
A
3704/3705 line is in emulation mode when it is controlled by the
Emulation Program (EP).
52
2703 Transmission Control with Synchronous Data Adapter Type II.
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
3270s
Cluster and standalone control units are supported for remote 3270s.
The IBM 3271 Control unit Model 2, and IBK 3274 Control Unit Kodels 1B
and 1C support clusters of up to 32 display stations and/or printers.
The IBM 3276 Control unit Display Station Models 2, 3, and 4 support
clusters of up to 8 display stations and/or printers. The IBK 3275
Display station, Model 2, is the standalone 3270 device that can be
remotely attached.
Note: The 3276, with a minimum
standalone 3270 device.
configuration can also be
considered a
The following devices are supported when attached to the 3271 control
unit:
•
•
•
•
•
IBM 3277 Display Station, Model 2
IBM 3284 printer, Model 2
IBM 3286 Printer, Model 2
IBM 3287 printer, ~odels 1 and L' \
IBM 3288 Line Printer, Model 2
Note: The 3271/3272 Attachment Feature #8330 is a prerequisite when the
rBM 3287 printer is attached to the 3271 control unit.
The following devices are supported when attached to the 3274 Control
Unit Model 1C:
•
•
•
•
•
•
IBM
IBM
IBM
IBM
IBM
IBM
3277
3278
3284
3286
3287
3289
Display
Display
Printer
Printer
Printer
printer
station Model 2
Station Model 2, 3 and 41
Model 2
Model 2
Models 1 and 2
Models 1 and 2
The following devices can be attached
Display station Models 2, 3, and 4:
•
•
•
to
the
3276 Control
Unit
IBM 3278 Display Station, Models 2, 3, and 41
IBM 3287 printer, Models 1 and 2
IBM 3289 printer, Models 1 and 2
The IBM 3275 Display Station, Model 2, is a standalone control unit
and display station.
IOU
can attach the IBM 3284 Printer, Kodel 3, to
the 3275. In addition, you can attach the IBM 3286 Printer, Model 3, to
the 3275 if RPQ MB4317 is installed.
With the 3275 Dial Feature i3440~
you can connect the 3275 to a computer over switched lines by using a
western Electric 2 or equivalent data set.
The 3275 Dial Feature does
not support full screen read/wr it e.
System Generation Requirements for Remotely
Attached Display Systems
When you generate VM/370 you must code the appropriate CLUSTER,
TERMINAL, and RDEVICE macros and assemble them as part of the DHKRIO
(real I/O configuration) file.
Then, after the DMKRIO file assembles
successfully, you must make a list of the resource identification codes
of all the remote 3270 lines and terminals.
Give the list to the
operations group at your installation; the members of that group need
this information when they issue the CP commands that control the
operation of remote 3270 lines and devices.
IModels 3 and 4 default to the 1920 character screen
functionally equivalent to the Model 2.
2Trademark of Western Electric Co.
size and
Part 1. Planning for System Generation
are
53
A pr ~ 1.
I,
I
::r 0
,
3270s
THE CLUSTER MACRO
Code one CLUSTER macro for each 3271 and 3274 control unit Model 1C,
each 3276 control unit display station, and each 3275 display station.
Only a maximum of 16 CLUSTER macros is allowed.
Each CLUSTER macro must
have a unique label.
The CLUSTER macro is described in the "preparing
the Real I/O Configuration File (DMKRI~" section of "Part 2.
Defining
Your VM/370 System."
THE TERMINAL MACRO
Code one TERMINAL macro for each display
attached to the clustered 3271.
station and printer
that is
Code one TERMINAL macro for each display station and printer that is
attached to tn~ ~lubL~i~a 3274 control unit,
~c~cl 1C.
For a 32 70
control unit Model 1C, the TERMINAL macros for 3278s, 3287s on a Type A
adapter, and 3289s must precede the TERMINAL macros for 3277s, 3284s,
3286s, 3287 on a Type B adapt er and 3288s.
Code one TERhINAL macro for each display station and printer that is
attached to a clustered 3276. Since the 3276 contains one integral
display unit, code one TERMINAL macro for the 3276 as a 3277. Code each
3278 attached to the 3276 as a 3277, and each 3287 attached to the 3276
as a 3284 or 3286. Code each 3289 as a 3288.
Code one TERMINAL macro for the 3275 display station. If a 3284 or
3286 printer is attached to the 3275, code MODEL=3 on the TERMINAL
macro. The TERMINAL macro is described in the "Preparing the Real 1/0
Configuration File (DMKRIO)" section of "Part 2.
Defininq Your VM/370
System."
THE RDEVICE MACRO
Code one RDEVICE macro for each binary synchronous line used for remota
3270s
(code one RDEVICE macro for each CLUSTER macro you code) •
A
maximum of 16 RDEVICE macros for lines to support remote 3270s is
allowed.
The RDEVICE macro is described in Part 2.
However, the format of the
RDEVICE macro for the binary synchronous line and transmission control
unit for remote 3270s is included here to help you code the macro
correctly. The format of an BDEVICE macro for a communication line that
supports remote 3270s is:
54
IBM VM/370 Planning and System Generation Guide
3270s
,-
I Name
I
I
Operation
Operands
RDEVICE
ADDRESS=cuu,
2701\
2703
DEVTYPE= ICA ,
3704
l 3705
ADAPTER=BSCA
( , BASEADD=cuu ]
, CL USTER=label
L
ADDRESS=cuu
is the real I/O address of the binary synchronous line
by remote 3270s.
to be used
The address, cuu, is three hexadecimal digits from 000 to FFF.
DEVTYPE=l~~~j\
3704
3705
is the device
the line.
type of the transmission control
unit that controls
Note: The lines attached to the 3704/3705 must be controlled by the
Emulation Program (EP).
ADA PTER=BSCA
is the terminal adapter for
represents the:
the transmission control
uni t.
•
•
IBM Binary Synchronous Terminal Adapter Type II for a 2701
•
Integrated Communications
Models 135, 135-3, and 138
•
IBM 3704 and 3705 Communications Controllers
BSCA
IBM Binary Synchronous Terminal Control Type II for a 2703
Adapter
(ICA)
on
the
System/370
BASEADD=cuu
is the native subchannel address
(load address) of the 3704/3705
that controls the physical line or lines. This operand is required
for correct operation of VM/370 recovery management for emulator
lines on a 3704/3705.
Specify this operand only for 3704 and 3705.
CLUSTER=label
is the label of a CLUSTER macro that
standalone station attached to this line.
defines
the cluster
or
Part 1. Planning for System Generation
55
3270s
The following examples are RDEVICE macros describing a nonswitched
point-to-point communication line connected to a 2701, 2703, and 3705.
RDEVICE ADDRESS=078,DEVTYPE=2701,ADAPTER=BSCA,CLUSTER=CLUST001
The cluster station that is connected to this line is defined by the
CLUSTER macro labeled CLUST001.
The line at address 078 is controlled
by a 2701 transmission control unit.
RDEVICE ADDRESS=080,DEVTYPE=2703,ADAPTER=BSCA,CLUSTER=CLUST020
The line
uni~ ana
at address 080 is controlled by a 2703 transmission control
corresponding CLuSTER maCLO ib lailel~u C1USTG20.
~he
RDEVICE ADDRESS=OB8,DEVTYPE=3705,ADAPTER=BSCA,
BASEADD=OBO,CLUSTER=CLUST030
x
RDEVICE ADDRESS=OBO,DEVTIPE=3705,ADAPTER=TYPE1,MODEL=B4
CPTYPE=EP,CPNA"E=CEPOBO
x
The line at address OB8 is controlled by a
3705 Communications
Controller and the corresponding CLUSTER macro is labeled CLUST030.
!Qi~:
Failure to code the CPNAME
operand on the RDEVICE macro
instruction for the 3704/3705 base address causes V"/370 to mark the
device "not operational" at IPL time.
The cluster on that 3704/3705 is
therefore unusable.
THE RESOURCE IDENTIFICATION CODES
After the real 1/0 configuration file (DMKRIO)
assembles successfully,
generate a list of the resource identification codes that correspond to
each line address.
Give the list to the operations group at your
installation.
The operator needs to know the resource identification
code when he issues the commands to control the operation of the remote
3270 lines and terminals.
The resource identification code is a four-digit hexadecimal code.
The low-order three digits of the resource identification code are the
resource address. The high-order digit is the line code.
The resource address is generated by V"/370; the order in which the
TERMINAL macros appear in the real I/O configuration file
(DMKRIO)
determines the resource addresses of the terminals defined.
Each
CLUSTER macro defines a 3270 control unit;
each 3270 control unit has a
resource address of X'OO'.
The device defined by the first TERMINAL
macro after the CLUSTER macro (in the DMKRIO file)
has a
resource
address of X'Ol', the second has a resource address of X'02', up to the
maximum of X'20'. This resource address
makes up the low-order three
digits of the resource identification code.
The line code is also generated by V"/370.
Refer to the assembly
listing for D"KRIO to determine the line code (the high-order digit of
the resource identification code). Locate the label DMKRIORN near the
56
IBM V"/370 Planning and System Generation Guide
3270s
end of the DMKRIO assembly listing. This label identifies a list of all
the· lines used by remote
3270s and by 3704/3705 Communications
Controllers in NCP mode.
The high-order digit is the line code and is
assi~ed according
to the order in which the line addresses appear in
the list. The first line address is assigned a line code 0 to complete
its resource identification code, the second is assigned 1, and so on up
to the last line. VM/370 supports a maximum of 16 binary synchronous
lines for use by remote 3270s; thus, the maximum value of the high-order
digit is F. Figure 9 shows you a sample DMKRIO assembly listing and the
corresponding line codes.
r-----------------------------------------------------------------------------------Sample of DMKRIO Assembly Listing
Line
Code (in
hexadecimal)
DMKRIORN
DC
DC
DC
DC
DC
DC
DC
DC
DC
P'4'
AL2«RDV07S-DMKRIODV)/S)
XL2'07S'
AL2«RDV07A-DMKRIODV)/8)
XL2'07A'
AL2«RDV079-DMKRIODV)/8)
XL2'079'
AL2((RDV07B-DMKRIODV)/8)
XL2'07B'
o
2
3
L
Figure 9.
Example of Determining Line Code for Remote 3270 Resource
Identification Codes
Once you determine the resource identification codes for the devices
in your remote 3270 configuration, generate a list for operations. The
list should include the following information:
•
•
•
•
•
•
Line address
Line code
Resource address
Label of plug on control unit panel
Resource Identification code
Device type
The plug panel of the 3271 control unit and 3274 control unit
Model 1C have up to 32 ports where terminals and printers can be
attached. The 3276 has up to S ports where the 3276 integrated display
is attached and where up to 7 additional terminals or printers can be
attached.
!Ql~:
AN EXAMPLE OF A REMOTE 3270 CONFIGURATION
This example shows you the contents of the real 1/0 configuration file
to define the following remote 3270 configuration:
•
•
A clustered 3271 control unit with eight ports
A standalone 3275 display station
The macros are coded so that the 3271 clustered control unit can
support eight display devices, or six display devices and two printers.
To define such a configuration, you must code 2 CLUSTER,
16 TERMINAL,
A 3275
and 2 RDEVICE macros defining the 2 separate clusters.
standalone control unit, with one display and one printer, is also
supported by the following macros. To define it,
you must code one
CLUSTER, one TERMINAL, and one RDEVICE macro.
Part 1. Planning for System Generation
57
3270s
The real I/O configuration file for this example is:
DMKRIO
CLUST078
CLUST07A
CLUST079
CSECT
CLUSTER
TERMINAL
TERMINAL
TERMINAL
TERMINAL
TERMINAL
TERMINAL
TERMINAL
TERMINAL
CLUSTER
TERMINAL
CLUSTER
TERMINAL
TERMINAL
TERMINAL
~~~M~W1T
.~~-~~~~
TERMINAL
TERMINAL
TERMINAL
TERMINAL
RDEVICE
RDEVICE
RDEVICE
CUTYPE=3271,GPOLL=407F,LINE=078
TERM=3277,SELECT=6040,FEATURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C1,FEATURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C2,FE1TURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C3,FEATURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C4,FEATURE=OPRDR,KODEL=2
TERM=3277,SELECT=60C5,FEATURE=OPRDR,MODEL=2
TERM=3286,SELECT=60C6,MODEL=2
TERM=3284,SELECT=60C7,MODEL=2
CUTYPE=3275,GPOLL=407F,LINE=07A
TERM=3275,SELECT=6040,FEATURE=OPRDR,KODEL=3
CUTYPE=3271,GPOLL=407F,LINE=079
TERM=3277,SELECT=6040,FEATURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C1,FEATURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C2,FEATURE=OPRDR,KODEL=2
TER~~32??,SELECT=60C3,FE!TURE=OPRDR,MODEL=2
T~RM=3277,SELECT=60C4,FEATURE=OPRDR,KODEL=2
TERM=3277,SELECT=60C5,FEATURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C6,FEATURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C7,FEATURE=OPRDR,MODEL=2
ADDRESS=078,DEVTYPE=3705,AD1PTER=BSCA,
BASEADD=OBO,CLUSTER=CLUST078
ADDRESS=07A,DEVTYPE=3705,AD1PTER=BSCA,
BASEADD=OBO,CLUSTER=CLUST07A
ADDRESS=079,DEVTYPE=3705,ADAPTER=BSC1,
B1SEADD=OBO,CLUSTER=CLUST079
x
x
x
In this configuration, if the 3271 cluster control unit is on line 078
there are six display devices and two printers supported. If the 3271
cluster control unit is on line 079, eight display devices and no
printers are supported.
Display devices can be interchanged among
resource addresses allocated to display devices and printers can be
interchanged among resource addresses allocated to printers; but a
printer cannot be attached at an address defined for a display device,
and vice versa.
After the DMKRIO file assembles successfully, you should generate a
list of resources for the operations group. Your list should be similar
to the list shown in Figure 10; it corresponds to the preceding example.
58
IBM
V~/370
Planning and System Generation Guide
3270s
,
r
Resource
Address
Label of
Plug in
Control
unit
Panel
000
001
002
003
004
005
006
007
008
0
1
2
3
4
5
6
7
I
Line
Address
018
Line
Code
0
o,q
2
,
,
I
I
I
,
07A
000
001
002
003
004
005
006
007
008
0
1
2
3
4
5
6
7
000
Resource
Identification
Code
0000
0001
0002
0003-0004
0005
0006
0007
0008
Device
Type
I cluster
I display
I display
-I display
I
1
I
I
1
display
display
display
printer
printer
2000
2001
2002
2003
2004
2005
2006
2007
2008
cluster
display
display
display
display
display
display
display
display
1000
cluster
1001
display
001
I
002
1002
printer
I
I
I .Not~: The line code is determined by referring to Figure 9;
I it corresponds to this example.
L
Figure 10.
Sample List of Resource Identification Codes for Operations
Local Attachments
Those control units that are attached directly to the processor channels
include:
•
•
IBM 3272 Control Unit
IBM 3274 Control Unit, Model lB
The display stations
control unit include:
•
•
•
•
•
•
•
3277
3278
3284
3286
3287
IB~ 3288
IBM 3289
IBM
IBM
IBM
IBM
IBM
!ot~:
and printers that are attached
directly to the
Display Station
Display Station
Printer
Printer
Printer
Printer
Printer (will not attach to a 3272)
The printers listed above are supported for the PFnn copy function
only.
Part 1. Planning for System Generation
59
3270S
The 3272 control unit can support the following devices:
•
•
•
•
•
IBM
IBM
IBM
IBM
IBM
3277
3284
3286
3287
3288
Display Station
Printer
Printer
Printer
Printer
The 3274 control unit, Kodel 1B can support the following devices:
•
•
•
•
•
•
•
IBM
IBM
IBM
IBM
IBM
IBM
IBM
3277
3278
3284
3286
3287
3288
3289
Display Station
Display Station
Printer
Printer
Printer
Printer
Printer
Local Hardware Configurations Supported
CONTROL UNITS
The following control units are supported wben locally attached on a
byte multiplexer, block multiplexer, or selector channel to support 3270
devices:
•
IBK 3272 Control Unit Model 2 for attachment of up to 32 3277 Display
Stations Kodel 2, 3284 Printers Kodel 2, 3286 Printers Kodel 2, 3287
Printers, Models 1 and 2, and 3288 Line Printers Kodel 2. To support
this configuration, the following may be required:
--Device Adapter feature (13250)
is required if more than four
devices are attached to the 3272.
Up to four additional devices
can be attached with each device adapter.
--A 3271/3272 Attachment
Printer.
•
(18330) is
required to
attach each
3287
IBK 3274 Control Unit Kodel 1B (supported as a 3272) for attachment
of up to 32 display stations and printers.
All of the 32 devices can
be 3278 Display Stations Kodels 2, 3, and 41 (supported as 3211s),
3287 Printers Models 1 and 2 (supported as 3284s or 3286s), and 3289
Line Printers Models 1 and 2 (supported as 3288s). A maximum of 16
of the 32 devices can be 3271 Display Stations Model 2, 3284 Printers
Model 2, 3286 Printers Model 2, 3287 Printers Kodels 1 and 2, and
3288 Line Printers Model 2. To support this configuration, the
following are required:
--The basic 3274 Control Unit permits attachment of up to 8 devices
(3278, 3287, and 3289). At least one 3278 is required.
--Each of Terminal Adapter Types Al, A2, and A3 (16901, 16902, and
16903) permits the attachment of up to 8 additional devices per
adapter (types 3278, 3287, and 3289).
Only 1 of each type terminal
adapter is permitted.
Terminal Adapter Type A1 is a prerequisite
to Type A2, and Type A2 is a prerequisite to Type A3.
tModels 3 and 4 are supported as Kodel 2 via hardware default.
60
IBM VPJ/370 Planning and System Generation Guide
3270s
--Terminal Adapter Type Bl ('7802) permits the attachment of up to 4
additional devices (types 3277, 3284, 3286, 3287 and 3288). Only 1
adapter is permitted.
--Each of the Terminal Adapter Types B2, B3, and B4
('7803, '7804,
and #7805) permits the attachment of 4 additional devices per
adapter (types 3277, 3284, 3286, 3287, and 3288). Only 1 of each
type terminal adapter is permitted. Terminal Adapter Type Bl is a
prerequisite to Type B2, Type B2 is a prerequisite to Type B3, and
Type B3 is a prerequisite to Type B4. Terminal Adapter Types Al,
and B3 are mutually ex~lusive.
--A 3274/3276 Attachment
(#8331)
is required for each 3287 that
attaches to the basic 3274 Control Unit, or that attaches to
Terminal Adapter Types Al, A2, or A3.
A 3271/3272 Attachment
(#8330) is required for each 3287 that attaches to Terminal Adapter
Types Bi, B2, B3, or B4.
And only required if a Type B adapter is used:
--Control storage Expansion feature (#1801) provides the
access control unit storage addresses above 64K.
ability to
--Extended Function storage feature
(#3622)
provides additional
storage
required
to
support
particular
attachments
or
configurations.
Control storage Expansion feature
('1801) is a
prerequisite.
TERMINALS
The IBM 3277
features:
--66
--66
--78
--78
Key
Key
Key
Key
Display Station
Model 2
requires one
of the
following
EBCDIC Typewriter Keyboard (#4630)
EBCDIC Data Entry Keyboard (#4631)
Operator Console-Keyboard (#4632)
EBCDIC Typewriter Keyboard (14633)
The following features, while not required, enhance the convenience,
security and usability of this terminal:
--Keyboard Numeric Lock (#4690)
--Audible Alarm (#1090)
--Operator Identification Card Reader (#4600)
--Lowercase Character Display (RPQ 18K0366)
--Security Keylock (#6340)
Note: Unless a 3270 terminal is dedicated to a virtual machine, it is
supported only as a virtual 3215; that is, it is not supported by VK/370
as a real local or remote 3270.
The 3278 Display Station requires one of the following features:
--75 Key EBCDIC Typewriter Keyboard (#4621)
--75 EBCDIC Data Entry Keyboard (#4622)
!Qi~:
A prerequisite is the EBCDIC
Character Set feature (#9082) on the
3218.
Part 1. Planning for System Generation
61
3270s
The following features, while not required, enhance the convenience,
security, and usability of this terminal:
--Keyboard Numeric Lock (14690)
--Audible Alarm (#1090)
--Magnetic Slot Reader (#5005) with Magnetic
Reader Control (#4999)
--Security Keylock (16340)
MQi~:
Lowercase Character Set is standard on this terminal.
(The Test Request Function on locally-attached 3277s is supported by the
TEST REQUEST key; it is supported on locally-attached 3278s by the
SYSTEM REQUEST key.)
PRINTERS
The following printers are supported:
•
•
•
•
•
IBM
IBM
IBM
IBM
IBM
3284
3286
3288
3287
3289
Printer,
Printer,
Printer,
printer,
Printer,
Model 2.
Model 2.
Model 2.
Models 1 and 2.
Models 1 and 2.
System Generation Requirements for Locally
Supported Display Systems
System generation requirements for locally-supported terminals and
control units
are no different
than are the
requirements for
DASD-supported or unit record devices. The channel, control unit, and
devices are handled by their respective RCHANNEL, RCTLUNIT, and RDEVICE
macros. See "Part 2. Defining Your VM/370 System" for further details.
62
IBM VM/370 Planning and System Generation Guide
3704/3705 Control Program
Generating a VM/370 System that Supports
the 3704/3705
The generation of a 3704 or 3705 Communications Controller control
program that runs under the control of VM/370 is normally done after the
VM/370 system generation is completed. However, when a 3704 or 3105 is
to be generated, the following preparations must be made:
•
An RDEVICE macro instruction for the 3704 or 3705 must be included in
the real I/O configuration (DMKRIO) file.
•
3704/3705 control programs that are to be used by VM/370 must be
stored on a CP-owned volume in the page format that is currently used
for saved virtual machine systems (that is, those created by the
SAVESYS command).
Each 3104/3705 control program image to be saved
must be defined by a NAMENCP macro instruction in the system name
table (CP module DMKSNT) and saved with the SAVENCP command.
•
Enough space to contain the 3704/3705 control program image must be
allocated on the CP-owned volume specified in the NAMENCP macro
instruction.
Noi~:
The alternate
console
for VM/370
must
not
be on
a
telecommunication line on a real 3704/3705, unless the 3704/3705 is
loaded by another operating system
(OS/VS1, OS/VS2, or DOS/VS) before
VM/370 is loaded.
Part 4 contains a complete discussion on generating a 3704 or 3705
control program. It describes the support provided with the Emulation
Program
(EP)
and tells you how to generate the 3704/3705 control
program, step by step.
Coding the RDEVICE Macro
The RDEVICR macro is described in Part 2. However, the format of the
RDEVICE macro for a 3704/3705 is included here to help you code the
macro correctly. The format of the RDEVICE macro for an IBM 3704/3705
is:
Part 1. Planning for System Generation
63
3704/3 7 05 Control Program
r
,Name
1
1
1
1
,Operation
RDEVICE
Operands
ADDRESS={ cuu
}
(cuu ,nn) ,
,
DEVTYPE= {3704}
3705 ,
1
1
,
,,1
ADAPTER= TYPE 1
TYPE2
TYPE3
TYPE4
IBM 1
TELE2
BSCA
( , MODEL=ab]
L
.J
[,CPNAKE=ncpname]
[ , BASEADD=ccu]
L
ADDRESS={CUU
}
(cuu, nn)
is the real device address (cuu) of the 3104/3705. Use
the (cuu,nn) form to generate multiple (nn) real device
blocks (RDEVBLOKs) when CPTYPE=EP is specified.
DEVTYPE={3704}
3705
is the device type.
You
should specify 3704 or
3105 instead of 2701, 2702, or 2103 when CPTYPE = EP.
ADA PTER= TYPE 1
TYPE2
TYPE3
TYPE4
IBM1
TELE2
BSCA
identifies either the channel adapter accessed by the
specified real address (TYPE1, TYPE2, TYPE3, or TYPE4) ,
or a line adapter if this is an emulator line group
(IBM1, TELE2, or BSCA).
Only TYPEl is valid for a
device type
of
3704.
For
DEVTYPE=3705,
TYPEl
or TYPE4 may
be coded.
In identifying
the line
adapter, IBM1, TELE2, or BSCA can be specified only in
relation
to
another
RDEVICE
macro
that
has
ADAPTER=TYPE1, TYPE2, TYPE3, or TYPE4.
MODEL=ab
is the 3704/3105 model letter and number, respectively.
The model number determines the size of the 3704/3105
storage. See Figure 11 for a list of the model numbers
and the corresponding storage sizes.
You should enter both a letter and a number.
However,
if only a single numeric character is entered, an "NOTE
is issued and the number is treated as model data for a
3104 or 3705-1, depending on the value of DEVTYPE.
64
IBM VM/370 Planning and System Generation Guide
3704/3705 Control Program
indicates which set address (SAD) command must be
issued prior to enabling the emulator lines.
CPTYPE= {EP }
indicates which type of 3704/3705
run in this 3704/3705.
control program
is
The valid adapter types are as follows:
,,
I
I CPTYPE=
I
, ADAPTER=
EP
I
Yes
,TYPE 1
No
1TYPE2
No
I TYPE3
, TYPE4
Yes
,
L--
CPNAME=ncpname
is the one- to eight-character name of the control
program to be automatically loaded in the 3704/3705 at
system IPL time.
If an automatic load is not desired,
omit this operan d.
Note: Failure to code the CPNAME operand on the RDEVICE
macro for the 3704/3705 base address causes VM/370 to
mark the device "not operational" at IPL time.
The
cluster on that 3704/3705 is therefore unusable.
BASEADD=ccu
is the native
that controls
required for
management for
This operand is
address (load address) of the 3704/3705
the physical line (5) • This operand is
correct operation of VM/370 recovery
emulator lines based on a 3704/3705.
valid only if ADAPTER=IBM1,
TELE2, or
BseA ..
Part 1. rlanning for System Generation
65
3704/3705 Control Program
r-
I IBM 3704 Communications
Controller
I
I
~Qgel
I
~lQ!:sg~
16K
A1
I
32K
A2
I
48K
A3
I
64K
A4
I
I
I
IBM 3705 Communications Controller
3705-1
,
,
_ _ Mod~_
Al, B 1, C 1, Dl
A2, B2, C2, D2
B3, C3, D3
B4, C4, D4
C5, D5
C6, D6
D7
D8
StQraq~
16K
48K
80K
112K
144K
176K
208K
240K
I
I
I
I
I
I
3705-11
,,
E 1,
E2,
E3,
E4,
E5,
E6,
'F.7:
E8,
G1,
G2,
G3,
G4,
G5,
G6,
F7: ~7 :
F8, G8,
F 1,
F2,
F3,
F4,
F5,
F6,
Hl
H2
H3
H4
H5
H6
32K
64K
96K
128K
160K
192K
R'7
22UK
256K
H8
L
Figure 11 •
IBM 3704/3705 Models
SPECIAL CONSIDERATIONS FOR CODING THE RDEVICE MACRO
The
3704/3705
Communications
Controllers
Consequently, the control program generation
complex.
have
varied
uses.
for the 3704/3705 is
If the 3704/3705 is to be run in emUlation mode:
•
Use the
(cuu,nn) form
RDEVBLOKs.
•
Speci~y
of the ADDRESS
operand to
generate multiple
the appropriate name for CPNAME.
To generate additional emulator lines for the same 3704/3705, use the
following coding guidelines on subsequent RDEVICE macros:
•
•
Omit the CPTYPE, CPNAME, and MODEL operands.
Specify the ADAPTER as IBM1, TELE2, or BSCA, as appropriate.
For ADAPTER=IBM 1 (or TELE2), the SETADDR operand
specified, exactly as if the device were a 2702 or 2703.
must
also
be
If you use the (cuu,nn) form of the ADDRESS operand to generate
multiple RDEVBLOKs and also specify the CPNAME and ADAPTER=TYPE1
operands on the RDEVICE macro, the additional RDEVBLOKs are generated as
ADAPTER=IBM1 and SETADDR=4.
!Ql~:
66
IBM VM/370 Planning and System Generation Guide
3704/3705 Control Program
For each physical 3704/3705, there should be only one RDEVICE macro
which specifies the ADAPTER=TYPE1, TYPE2, TYPE3, or TYPE4, MODEL,
CPTYPE, and CPNAME operands.
This RDEVICE macro defines the base
address of the 3704/3705 (that is, the real address used to perform the
load and dump operations). If the physical device is a 3705 with two
channel adapters installed, there may be a second RDEVTCE macro that
specifies the ADAPTER=TYPE1, TYPE2, TYPE3, or TYPE4, MODEL, and CPTYPE
operands. There must nell~-be a second use of the CPNAf!E o-perand. - - Even
if CPTYPE=EP is specified, the 3704/3705 base address cannot be used as
a telecommunication line; its function is only to load and dump the
3704/3705, and the device type and class are different from those of all
other lines generated.
Whenever there is more than one subchannel address (CPTYPE=EP);
include in the DMKRIO deck all of the RCTLUNIT macros required to
specify those real addresses which the EP control program may use.
If you have a 3704/3705 and a 2701/2702/2703 on the same V"/370
system, the virtual addresses for the 3704/3705 must not be the same as
any of the real 2701/2702/2703 addresses.
Examples of RDEVICE macro specifications follow. For
continuation character in position 72 is not shown.
convenience, the
RDEVICE ADDRESS=(020,16),
DEVTYPE=3704,
MODEL=A2,
ADAPTER=TYPE1,
CPNAME=CEP020
This describes a 32K 3704 at address X'020', with 15 emulator lines
addresses X'021'
to X'02F'
and with the default parameter of
ADAPTER=IBM1 and SETADDR=4.
The 3704 is to be loaded with the
Emulation Program 'CEP020'.
RDEVICE ADDRESS=(030,16),
DEVTYPE=3704,
ADAPTER=IBM1,
SETADDR=2,
B ASEADD=02-0
This describes an additional 16
specified by Example 1.
emulator
lines on
the same
Part 1. Planning for System Generation
3704
67
3704/3705 control Program
Creating an Entry in the System Name Table
It is necessary to create an entry in the system name table (D"KSNT) for
each unique 3704/3705 control program that you generate. If you can
foresee generating several versions of the 3704/3705 control program,
define extra entries in the system name table when you generate V"/370.
In this way, you need not regenerate the VM/370 system just to update
the system name table. If you should have to regenerate the VM/370
system just to add a new entry to the system name table, see the
discussion about the GENERATE EXEC procedure in "Part 5.
Updating
VM/ 370. "
The NAMENCP macro is described in Part 2.
Reserving DASD Space for the 3704/3705 Control
Program Image
DASD space to contain the 3704/3705 control program image must be
reserved on a CP-owned volume. The DASD space reserved should be
sufficient to contain the number of pages specified in the SYSPGCT
operand of the NAMENCP macro, plus one or more for system use, as
follows:
•
If CPTYPE=EP, allow only one extra page.
These additional pages are used to store
information provided by the SAVENCP program.
the
reference
table
Alternate Path Support
Alternate path logic provides support for the two channel switch and
two-channel Switch Additional Feature and the String Switch Feature by
V"/370. This support allows up to four channels on one control unit to
be attached to V"/370 and/or one device to be attached to two logical
control units. This allows the control program up to eight paths to a
given device when the maximum number of alternate channels and alternate
control units are specified.
When an I/O request is received for a
device, V"/370 can select a free path from any of the available paths to
the device. With this support, even though the primary path to a device
is busy, there may exist an alternate path(s) that is available.
Instead of the I/O request being queued, it can be initiated immediately
on an alternate path.
In the case where no available path to the device
exists, alternate path I/O scheduling is implemented in such a way that
the request is queued off multiple busy/scheduled paths and the first
path to become available will be the path the I/O is started on. This
approach has some distinct advantages over approaches used by other
operating systems:
1.
The I/O starts on the first available path to the device. This
eliminates the arbitrary choice of queuing based on number of
IOBLOKs already queued, primary path, last busy scheduled path
encountered, etc.
2.
No single user is penalized more than any other user.
3.
The first in, first out (FIFO) principle is adhered to.
An example of alternate path usage is shown in the section "3850 "ass
Storage System" later in Part 1.
68
IBM V"/370 Planning and System Generation Guide
3800 Image Library
Generating a VM/370 System that Supports
the 3800 Image Library
The generation of a 3800 image library that runs under the control of
VM/370 is normally done after the VM/370 system generation is completed.
However, when a 3800 image library is to be generated, the following
preparations must be made:
•
An RDEVICE macro instruction for the 3800 printer must be included in
the real I/O configuration (DMKRIO) file.
•
The 3800 image libraries that are to be used by VM/370 must be stored
on a CP-owned volume in the page format that is currently used for
saved virtual machine systems (that is, those created by the SAVESYS
command).
All 3800 image libraries in the system name table
(CP
module DMKSNT) and saved with the IMAGELIB command.
•
Enough space to contain the 3800 image library must be allocated on
the CP-owned volume specified in the NAME3800 macro instruction.
Coding the RDEVICE Macro
The RDEVICE macro is described in Part 2.
However, the format of the
RDEVICE macro for a 3800 is included here to help you code the macro
correctly. The format of the RDEVICE macro for an IBM 3800 is:
r
I Name
Operation
1--------------RDEVICE
I
I
,
,
1
!
I
Operands
ADDRESS= ccu,
DEVTYPE=3800,
[FEATURE=4WCGMS,]
[IMAGE=imagelib,]
[ CHARS=ffff, ]
[FCB=lpi g ]
[ DPM SIZE=n, ]
L
ADDRESS=cuu
is the real device address
DEVTYPE=3800
is the device type.
PEATURE=4WCGMS is a 3800 device with
Modules.
(cuu) of the 3800.
4 Writeable
Character Generation
IMAGE=imagelib is the image library to be used by the 3800 printer
device after a cold start if none is specified on the
ST ART command.
CHARS=ffff
is the character arrangement table for the 3800 printer
device to be used after a cold start if none is specified
on the START command.
FCB=lpi
is the FCB to be used for the page separator for the 3800
printer device after a cold start if none is specified on
the START command.
Part
1~
Planning for System Generation
69
3800 Image Library
DPMSIZE=n
is the maximum size
printer device.
of the delayed
queue for
the 3800
Hardware Supported
As a VM/370 real spooling device, the following hardware features of the
3ROO are supported:
of
character
arrangement
tables
and
graphic
•
Automatic 10aa1ng
modifications
•
Full support of the additional storage character generation feature
•
Forms overlay feature
•
Copy modifications
(flashing)
The use of multiple character arrangement tables for
within one spool file (TRC support) is D21 supported.
printing use
Related Publications
The £QJl~e1§ Q! !.h~ l1H1 lftOO PrintilliI Su~syste.!! manual, Order No.
GC20-1775 is intended as a first reader for those users of printers who
wish to take a quick look at the non-impact IBM 3800 Printing Subsystem,
at its basic concepts and at how these concepts lead to new functions
tha t may offer different options in planning and operations.
The !!ef~n£~ l1~!Ht! i2!: lhe IBM 1800 ~!:inti!!g Subsys.!~!!, Order No.
GA26-1635 provides information on the functions and features of the IBM
3800 Printing Subsystem relating to channel commands,
sense bytes, and
error detection, recovery, and recording.
Specific information and
examples are given of copy modification and control and graphic
character modification.
The IB~ 1.§00 ~!:intilliI Su~syst~ ~rogramm~!:~ Guid~, Order No.
GC26-3846 provides planning and conversion information for the IBM 3800
printing Subsystem and information on how to use the 3800.
Creating and Updating a 3800 Named System
A named system must be established (via the NAME3800 macro)
in DMKSNT
for each system data set capable of image library activation.
The
purpose of the named system is to contain the 3800 character arrangement
tables, copy modifications, graphic modifications, and FCBs.
They can
then be referenced by name and the data for them obtained from this
named system when the file referencing them is about to print on a 3800.
The active named system for a particular 3800 is in its RDEVBLOK and can
be changed by the START command. See the NAME3800 macro description in
"Part 2. Defining Your VM/370 System_"
Programs exist to enable you to dynamically change the character
arrangement tables, graphic modifications, copy modifications, and FCBs
available. With these programs (GENIMAGE and IMAGELIB), and the named
system support discussed above the installation can make these changes
dynamically, without a VM/370 system load. GENIMAGE and IMAGELIB are
described in detail in the !~L11~ OperEto~~ Guig~.
70
IBM VM/370 Planning and System Generation Guide
3850
~SS
3850 Mass Storage System
Generating a VM/370 System that Supports a 3850
The 3850 Mass storage System (~SS) supplies large amounts of data online
under-system coritrol.- Up to ·47 2 billion bytes of data space becomes
available, allowing the user to place significant amounts of tape and
DASD shelf data under direct control of the system.
Up to four virtual
machines concurrently running OS/VS1, MVS, or SVS operating systems with
~SS support can each control an interface
to a common 3850 ~ass Storage
System.
HARDWARE SUPPORTED
Support for the 3850 is available on the following processors supported
by VM/370: system/370 ~odels 145, 145-3,
148, 155II, 158
(attached
processor and uniprocessor mode), 16511, the 168 (attached processor and
uniprocessor mode), the 3031 (attached processor and uniprocessor), 3032
and 3033 processors and the 4331 and 4341 processors.
The major hardware components of MSS are as follows:
•
The 3851 Mass Storage Facility
(MSF)
•
The 3830 Model 3 Storage Control for System/370 ~odels 145, 145-3,
148, 15511, 158, 16511, and 168 or the Integrated Storage Control for
the System/370 ~odels 158 and 168
•
The 3333 Disk Storage and Control (Models 1 or 11)
•
3330 Disk storage Drives
•
3350 Disk storage Drives (Real Only)
(~odels
1, 2, or 11)
The ~ass Storage Control
(ftSC) is a microprogrammed processor that
provides the operational control for the components of the ~ass Storage
System. It is physically housed in the 3851 Mass Storage Facility. The
MSC may have four System/370 channel interface positions, referred to as
A, B, C, and D. A host system attaches to one of these through a
control unit position of either the byte multiplexer channel or block
multiplexer channel operating in burst mode. The ~SC channel interface
is used for transfer of orders, commands, control information, and
status messages between the host system and the ~SC. It does not carry
user application data.
Up to four operating systems containing MSS support (OS/VS1, SVS, or
may be connected to the Mse. These operating systems may be
running in a virtual machine under VM/370, or in a real processor,
connected to the same MSC as VM/370. One of the four MSC interfaces is
dedicated to each virtual machine. Each virtual machine using an MSC
port reduces by one the number of other real processors that may be
connected to the Mass Storage System.
~VS)
Part 1. Planning for System Generation
71
3A 50 MSS
The Mass storage System uses the 3333 control unit and the 3330 ~odel
1, 2, or 11 for staging data and for holding the tables it requires for
its operation. These units connect to the Mass Storage Facility and to
the processor through a Staging Adapter.
The several models of the 3330
may be intermixed on the Staging Adapter.
The 3330 disk drives can be
one of the following:
1.
2.
3.
Real
Staging
Convertible
Real DASD drives are not available to the Mass Storage System for any
activity. They are physically part of the system in that they have a
data and control path through a Staging Adapter, but real drives are not
logically connected to the Mass Storage System. Staging drives are used
to hold data staged from mass storage volumes to be available for
processing by the processor.
Staging packs are divided into pages of
storage.
Each page consists of eight cylinders.
The term virtual
volume is used to refer to pages of space and the data staged to that
space.
Each virtual volume is assigned a virtual unit address.
Staging
~riv@s ~r~ logi~ally divid~d in~o staging
drive groups to assist in the
management of online space.
Each staging drive must belong to one and
only one staging drive group.
There can be no more than two staging
drive groups for each Staging Adapter.
Each staging drive group can
have a maximum of eight logical $taging drives, a logical drive being
the equivalent of one 3330 Model 1. One 3330 Model 11 counts as two
logical staging drives.
Convertible drives can be either real or staging drives, but not both
at the same time.
If the drive is to be made real,
the real path
between the drive and the operating system must be available.
When the
drive is a staging drive, this real path must be offline.
!Qi~:
Information describing
iQ. ihe IBM .J§50 1i~§ ~t0f:,gg~
MSS hardware can be
Sysi~!
found in
In!~odY£!iQR
(M~).
On a 3850 Mass Storage System the Mass Storage Control can contain at
most four channel interfaces to a single processor and the 3830 Model 3
Staging Adapter can have a maximum of four channel interfaces.
The
first channel interface on the 3830 Model 3 must be attached to a lower
control unit position of the 3851 MSC. This control unit position does
not conflict with the previously mentioned MSC port addresses.
The
remaining three channel interfaces of the 3830 may be attached to one or
more host systems.
Only the channels attached to the system being
generated should be defined as primary or alternate channels.
For each of the three rema1n1ng
(available)
channel interface
pOSitions of a Staging Adapter, there are 64 possible device addresses.
Thus, for each 3830 Model 3 control unit, or Integrated Storage Control
with the Staging Adapter feature, there are 192 possible device
addresses. Each device address corresponds to pages of staging space on
the staging DASD. The staging space, which represents a volume, is
allocated by the MSC. The transfer of data between the staging space
and the Mass storage Facility, is also under the control of the MSC.
The MSC maintains the logical connection between a device address known
to the host processor, the staging space allocated to the device, and
the MSS volume mounted on the device.
When an MSS is connected to a VM/370 system, the addresses known to
VM/370 are the MSCts channel interfaces and the device addresses to the
channel interface pOSitions on the Staging Adapter.
The ~SC is
supported in VM/370 only as a dedicated device. For a virtual machine
to access the MSC, at least one of the MSC channel interfaces must be
dedicated to the virtual machine.
72
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
3850 MSS
In this publication, the device addresses corresponding to the
channel interface positions on the Staging Adapter are referred to as
3330V device addresses.
There are 64 3330V devices per channel
interface position, or 192 3330Vs per Staging Adapter. There may be
volumes mounted on all of these devices concurrently. These 3330V
volumes re~resent 3330-1 volumes, and with the proper programming
support, may be used for all purposes that a 3330-1 volume is used
except VM/370 system residence, paging, and spooling.
3330V devices may be used in three different ways in VM/370:
I •
Mounted on the device and used as VM/370 system volumes (excluding
system residence, paging and spooling) under the control of the
control proqram.
I •
Dedicated to a virtual machine as a 3330-1 and accessed
virtual machine using standard 3330-1 su~port.
I.
Dedicated to a virtual machine as a
machine must contain MSS support.
from the
3330V, in which case the virtual
A 3330V device address is not manually available to the VM/370 system
operator. Instead, it is an accumulation of pages of staging space on
MSS staging DASD. Volumes are mounted on, and demounted from, 3330V
devices only through orders passed to the MSC.· The MSC is supported as
a dedicated device under VM/370 and full MSC support is contained in
OS/VS1 and MVS.
Therefore, to mount and demount 3330V volumes for
VM/370 use, the control program communicates with an as/vs system to
which an MSC channel interface is dedicated.
Any programming in a virtual machine that accesses a real 3330-1 can
access a 3330V without modification.
One or all CMS users may access
CMS minidisks on MSS volumes. One MSS 3330V volume may contain the
minidisks for one or many CMS users.,
At the same time, virtual volumes
may also be used as system residence packs for a VS system, and the VS
system can be IPLed from the virtual volume.
The mounting and demounting of 3330V volumes used as VM/370 system
volumes is accomplished by the control program communicating with an
OS/VS system in a virtual machine.
There is an MSS communication
program named DMKMSS which is part of the VM/370 system, but which runs
in supervisor state in an OS/iS1 or MVS system.
This DMKMSS program is
the interface between the VM/370 control program and the MSC support
contained in OS/VS. The steps to install-DMKMSS in an OS/VS system are
listed in the section "Generating CP and CMS Using the starter System"
later in this publication.
It is not necessary to generate a VS operating system specifically
for the virtual machine environment. Any OS/VS1 or MVS system that
supports the MSS can utilize VM/370 MSS support, and can act as the host
for the communicator program. There is, however, a requirement for the
MSS I/O devices in the VS system to match the definition of the virtual
machine.
When OS/VS is IPLed, the system tests for any 3330Vs that are not
online. When one is found, an order is issued to the MSC for demount.
In essence, the 3330V address is passed to the MSC and the order tells
the MSC to demount any volumes currently mounted on that 3330V.
A 3330V may be offline to a virtual machine because none of VM/370's
3330Vs were allocated to the virtual machine at that virtual address.
However, the 3330V may be a valid address to the MSC.
If the virtual
machine issues a demount order to one of these 3330V devices, a volume
in use by VM/370 or another virtual machine MSC can be demounted.
Part 1. Planning for System Generation
73
---
-
-...l
----
-----
---"'
3850 MSS
Therefore, the following rule must be used when defining
(via IOGEN)
3330V devices in a VS system to run in a virtual machine to which an KSC
in ter face is dedicated.
For each 3330V defined in the VS system there must be a corresponding
3330V defined to VM/370 and allocated to the virtual machine.
For example, if you wish to dedicate real 3330Vs 240 through 27F to
virtual CPUID 22222 as virtual devices 140 through 17F, then only 3330Vs
140-17F can be defined (via IOGEN) in the OS/VS system running in CPUID
22222.
I SPECIAL CONSIDERATIONS FOR THE VS1/VS2 CENTRAL SERVER VIRTUAL MACHINE
At detach time, the VM/370 control program destages changed cylinders on
a'volume when the use count for the entire volume reaches zero. The
destaqe function is accomplished by a relinquish order to the MSS
throuqh the central server. A relinquish order iR iRR"~~ ~+ ~~tach ti~e
for volume-IDs mounted on SYSVIRT and VIRTUAL virtual unit addresses
which have had a volume mounted on them by VM/370 on behalf of the guest
operating system. No data are destaged for VIRTUAL units that were not
mounted by VM/370.
The following VS1/VS2 APARs must be applied to the central server
virtual machine operating system when
VM APAR 11344
(relinquish
function) is applied to the VM/370 control program. The following APARs
should be applied regardless of whether the new function is desired:
COMEQNENT
VS1 APAR
VS1 SPE BASE
VS1 SPE MSSE
VS2 APAR
VS2 SPE BASE
VS2 SPE MSSE
SC.1]]
OX27455
UX90058
SC1CI
OX27456
UX90059
SC1DP
OX27453
UX90054
UX90055
~£1DR
OZ49650
UZ90134
OZ49655
UZ90135
OZ49642
UZ90130
UZ90131
OZ49643
UZ90132
UZ90133
OX27454
UX90056
UX90057
VM/370 APAR 11342 permits general use volume sharing on 3330 virtual
unit addresses between a VM/370 system and a native VS1/VS2 system when
the unit control blocks are not generated in the VS1/VS2 central server
virtual machine.
The following VS1/VS2 APARs must be appl~ed to the
central server virtual machine operating system when this fUnction is
desired:
VS1
APAR
PTF
OX24117
UX15678
VS2
APAR
PTF
OZ48289
UZ33530
No1~: If general use
have to be applied.
74
volume sharing is not desired, these
IBM VM/370 Planning and System Generation Guide
APARs do not
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
3850 MSS
DEFINING THE MSS COMMUNICATION DEVICE
The VM/370 control program initiates an MSS mount or demount request by
generating an attention interruption on a specified device.
This device
must be specified in the directory of the virtual machine as a unit
record output device, for example:
SPOOL 017 2540 PUNCH
The same device address must be specified on the job
used to start DMKMSS in VS, for example:
//MSSCOMM
control language
DD UNIT=017
This device address must be constructed in VS at the same time as the
IOGEN for the 3330Vs.
The address chosen must not correspond to an
actual device that VS will attempt to use for any other purpose: This
is done by specifying the device as a DUMMY in the VS IOGEN.
For
example:
IODEVICE ADDRESS=017,UNIT=DUMMY,DEVTYPE=nnnnnnnn
The value of nnnnnnnn is any valid hexadecimal code.
requirement to provide a UNITNAME statement for this
example:
It is a VS
device, for
UNITNAME NAME=017,UNIT=017
T.HE MASS STORAGE CONTROL TABLES
This topic is provided for those installations that intend to run VS
systems in a virtual machine and access the MSS (under control of VS)
from those systems. If you run only one VS virtual machine that has MSS
support, and that virtual machine will access the MSS only upon request
from VM/370, then this section does not apply. However, you must follow
the guidelines in this topic if you have a virtual machine that has
3330Vs dedicated to it (that is, you intend to run more than one MSS
virtual machine or to run VS MSS jobs in the MSS communication virtual
machine).
The MSC is driven from tables that reside on DASD. These tables are
used, among other things, to define the MSS configuration. This
configuration includes such items as the addresses to be used for all
components of the system, and the available paths from all connected
hosts to all these component devices. Thus, the MSC tables define the
allowable paths from any host (as defined by that host's CPUID to a
3330V where the 3330V is defined in terms of the Staging Adapter address
and the specific S/370 channel attachment to the Staging Adapter).
Part 1. Planning for System Generation
74.1
n
74.2
1:"............
.,
IBM VM/370 Planning and System Generation Guide
3850 MSS
When a/virtual machine is given access to the MSS,
one interface to
the MSC is dedicated to that virtual machine. To the MSC, this is the
same as having that interface connected to a native processor. Thus,
the MSC tables must be constructed so that the MSC can process requests
from the virtual machine. The MSC must treat the requests as if they
came from a native processor, controlling the other components of the
MSS such that MSS activity, as seen by VM/370 and the virtual machines,
occurs on the correct 3330V device address.
Consider the example of a virtual machine that is given a virtual
CPUID of 12345. This processor also has one of t~~ MSc~ppe~~interfaces
dedicatecf to -it ~ Su ppose-- that- VPI/370' S 3330V 250 is dedicated to the
virtual machine as virtual device address 150. When virtual CPUID 12345
issues an order to the MSC, the 3330V placed in the order will be 150.
When interruptions are generated for this 3330V they will be sent from
the Staging Adapter on the interface that corresponds to virtual CPUID
12345's 150.
Since that device is known by VM/370 as 250, the MSC
tables must have been constructed such that the definition of 3330V 150
for virtual CPUID 12345 corresponds to the physical connection known to
VM/370 as 250.
Each 3330V in the MSC tables must map to a specific channel
attachment on a specific Staging Adapter. In this case, the MSC table
was constructed so that the definition for 3330V 150 on virtual CPUID
12345 corresponds to the physical connection from the real processor.
This connection is through channel 2 to the same upper interface on the
Staging Adapter.
Thus, interruptions received from
the virtual
machine's 150 are received on VM/370's 250 as long as it is dedicated to
the virtual machine corresponding to virtual CPUID 12345. Similarly,
when the virtual machine issues an MSC order such as demount, the volume
on VM/370's 250 is the volume demounted.
Two different virtual machines, having the same virtual device
addresses can run concurrently under VM/370. If there are two virtual
machines, each of which has defined a 3330V at the virtual machine's
device address 150,
then the MSC tables and
the physical MSS
configuration can be set so that each virtual machine can have a 3330V
at address 150.
One configuration has a native processor with two block multiplexor
channels, channel 1 and 2, and one Staging Adapter.
Channel 1 is
connected to the B interface of the Staging Adapter and channel 2 is
connected to the C interface of the Staging Adapter. The VM/370 system
has 3330Vs generated as 140 through 17F and 240 through 27F.
Two
virtual machines are defined as CPUID 11111 and CPUID 22222.
Each of
these machines can support an operating system in which the 3330Vs are
generated at addresses 140 through 17F. The MSC tables for this
configuration m-ust show CPUID 11111 with its 3330Vs 140-17F mapped to
the Staging Adapter interface Band CPUID 22222 with its 3330Vs 140-17F
mapped to the Staging Adapter interface C.
CREATING MSS VOLUMES
Before a pair of MSS data cartridges can be treated as a volume or
accessed as VM/370 system volumes, they must be initialized as the image
of a ~330-1 disk packe This initialization is accomplished by the use of
an OS/VS access method services command called CREATEV. CREATEV is one
of several commands that are part of the MSS component of the access
method services, which in turn is a standard component of OS/VS1 and
OS/VS2. CREATEV can run either under VS running on a native processor,
Part 1. Planning for System Generation
75
3A50 MSS
or VS running in a virtual machine to which an MSC port has been
dedicated. In either case, once CREATEV has completed, the volume is
known to the MSS and may be referenced in MSC mount and demount orders.
COPYING 3330-1 VOLUMES TO 3330V VOLUMES
A full or partial 3330-1 volume may be copied to 3330V volumes. Once the
MSS volumes have been initialized
as described previously, with
CREATEV, either of the following may be done:
•
The access method services command CONVERTV may be executed from
either a native processor or a VS virtual machine. This will make a
bit by bit copy of the 3330-1 on the MSS 3330V.
•
Allor part of the 3330-1 volume and the 3330V volume can be
allocated to a virtual machine using the directory MDISK or DEDICATE
statements or the operator ATTACH command. Standard CMS. OS. DOS.
OS/VS and stand-alone utilities can then be used to copy data to the
MSS volume.
USING 3330V VOLUMES FOR VS SYSTEM RESIDENCE
A VS system can be loaded in a virtual machine from a 3330V volume
because VM/310 can make the virtual IPL device appear to be a 3330-1.
The following steps describe one way this can be done:
•
Use the CREATEV command to create an
number of VOL001.
MSS volume with a volume serial
•
Define a directory entry for a virtual machine (VS2VK) with an KDISK
statement, describing a minidisk spanning cylinders 1 through 401 on
volume VOL001.
•
VM/310 mounts VOLOOl
and allocates the minidisk when VS2VK logs on.
The operator can then attach a 3330-1 containing a VS2 system to
VS2VM.
•
Copy cylinders 0-400 of the 3330-1 to the minidisk within VS2VK.
•
IPL the virtual device address corresponding to the minidisk as a VS2
system residence device.
THE VM/310 RDEVICE MACRO
The 3330V device addresses generated in the VM/310 control program can
be used for two purposes: they can have 3330V system volumes containing
minidisks mounted on them, or they can be dedicated to a virtual
machine. In either case, the control program can dynamically select a
specific device to satisfy a request.
You must divide the pool of
available 3330V devices into two types, one for system volumes and one
for dedicated volumes. The FEATURE= operand of the RDEVICE macro is used
to first indicate that a device address is a 3330V as opposed to a
3330-1, and second,
to indicate the type of 3330V
system or
dedicated.
76
IBM VM/310 Planning and System Generation Guide
3850 PISS
W.hen coding the RDEVICE macro for a 3330V device address,
FEATURE=VIRTUAL or FEATURE=SYSVIRT must be coded, where:
either
•
VIRTUAL defines a 3330V that may not be used for system volumes.
may be dedicated or attached to virtual machines as a 3330-1
3330V.
It
or
•
SYSVIRT defines a 3330V that is used for VPI/370 system volumes. It
cannot be dedicated or attached to a virtual machine.
PISS volumes
that are 3330V, can be mounted on SYSVIRT 3330V devices but cannot be
dedicated to a virtual machine by address, nor attached to other than
the system.
To specify an alternate control unit on the RDEVICE macro, code:
RDEVICE ADDRESS=cuu,DEVTYPE=nnnn,MODEL=n,ALTCU=cuu
Figure 12 shows how the real I/O control block structure is coded and
logically appears when an alternate control unit is specified.
RDEVICE ~DDRESS=(340,32),DEVTYPE=3330,PlODEL=1,ALTCU=250
RCTLUNIT ADDRESS=340,CUTYPE=3830,FEATURE=32-DEVICE
RCTLUNIT ADDRESS=250,CUTYPE=3830,FEATURE=32-DEVICE
RCU340
RCU348
r-> I
II
,
I
I
I
I
i
I
I
,
,
RCU350
RCU358
I
r->r
RDV340-34F
,
I
I
I
I
I
L-IRCU340 RDEVCUA
I
IRCU250 RDEVCUB
I
I
r->.
I
I
I
I
I<-I-IRCUSUBI
I
I
I
,
I
I
I
RCU250
RCU258
I
I
I
I
I
I
I
I
I
RCU260
RCU268
1
I
1<
,I
I RDV350-35F
I
•
I I
L_I
I
IRCU350lRDEVCUA
I
---I
I
I
RDEVCUBIRCU2601
I
I
I
I
Figure 12. Real I/O Control Block Structure for
Specification
r->.
I
I
1
I-IRCUSUBI
I
I
I
--I
I
•
I
,
I
I
I
I
I
I
I
--I
Alternate Control Unit
Part 1. Planning for System Generation
77
3850 MSS
To specify alternate channel addresses on the RCTLUNIT macro, code:
RCTLUNIT ADDRESS=cuu,CUTYPE=nnnn,FEATURE=xxx-DEVICE,
ALTCH= (1,2,4)
Figure 13 shows how the real I/O control block structure would be coded
and logically appear when alternate channels are specified. Note that
the subordinate control unit blocks do not contain pointers to the
alternate channel blocks. Only the prime control unit block contains
pointers to the alternate RCHBLOKS. This is consistent with the current
CP block structure.
RCTLUNIT
RCHANNEL
RCHANNEL
RCHANNEL
RCHANNEL
ADDRESS=340,CUTYPE=3830,FEATURE=32-DEVICE,ALTCH=(1,2,4)
ADDRESS=1,CHTYPE=MULTIPLEXOR
ADDRESS=2,CHTYPE=MULTIPLEXOR
ADDRESS=3,CHTYPE=MULTIPLEXOR
ADDRESS=4,CHTYPE=MULTIPLEXOR
RCHAN1
r->.I
I
L
RCHAN2
r->.
1
1
1
,
I
I
I
I
I
RCHAN3
r->.
,
I
I
I
L-
RCU340
RCU348
RCU350
RCU358
, ,
•
,
I
L
RCHAN4
r->.
I
1 RCHAN3
I
I
+-1 RCHAN1
I
I
L--IRCHAN2
1
I RCHAN4
L
•
----.I
RCUCHA
RCUCHB
RCUCHC
RCUCHD
----,
1
i
I
I
IRCUSUB 1
I
I
1
I
IRCU340 I
1---1
I
1
1
I
1
I
L
Figure 13. Real I/O Control Block Structure for Alternate Channel
Specification
The following restrictions apply directly to Alternate Path processing:
•
VM/370 does not support alternate paths for devices that issue
attention interrupts to invoke a read response from the host; for
example, the 3851 Mass storage Control (MSC) unit.
•
All devices on one physical control unit must be defined as either
alternate path or no alternate path.
There can be no splitting of
control units when dealing with alternate paths.
78
IBM VM/370 Planning and System Generation Guide
Saved Systems
Saved Systems
Saved systems are described in detail in the VftLJ70 2Y§tem Programmer's
If you plan to save core-image copies of virtual machine
operating systems you should do the following when you generate Vft/370.
~ide.
•
Create an entry in the system name
save.
•
Reserve space on a CP-owned volume for each system you wish to save.
You create
entries in the
table for each system you wish to
system name
table by coding
NAftESYS and
NAMENCP macros and assembling the system name table (DMKSNT) file during
system generation. You specify which volumes are to be owned by CP by
coding the SYSOWN macro and assembling the CP system control (DMKSYS)
file during system generation. These macros and files are described in
Part 2.
If you decide to add entries to the system name table after you have
installed Vft/370, you must code the appropriate NAMESYS or NAMENCP
macros, reassemble the system name table module (DftKSNT), and reload the
CP nucleus. Likewise, if you must add a CP-owned volume after system
generation, you must recode the SYSOWN macro, reassemble the CP system
control module
(DMKSYS), and reload the CP nucleus. Use the GENERATE
EXEC procedure to reassemble DMKSNT and/or DftKSYS and to reload the CP
nucleus.
GENERATE is described in "Part 5. Updating VM/370."
Part 1. Planning for System Generation
79
80
IB~
V"/310 Planning and System Generation Guide
Discontiguous Saved Segments
Discontiguous Saved Segments
VM/370 supports discontiguous
segment protection.
shared
segments
and
provides
shared
With discontiguous saved segment support, you can attach and detach
segments of storage to and from your virtual machine.
These segments
may contain reenterable code that can be shared by many users. Thus,
programs that are required sometimes, but not all the time, can be saved
and only loaded when they are needed.
Also, discontiguous saved
segments can be attached to your virtual machine in nonshared mode for
testing and debugging.
When in attached processor mode, all shared segments are duplicated.
Sufficient storage is obtained to construct duplicate page and swap
tables in contiguous storage. This additional storage space should be
planned for, when running in attached processor mode.
The SHRTABLE SHRPAGE pointer points to the page and swap tables for
the main processor, and the page and swap tables for the attached
processor will be at a fixed offset from the page and swap tables for
the main processor.
DMKCFG initializes both sets of page and swap
tables.
At first, the swap tables for the main processor and attached
processor will point at the DASD locations specified in DMKSNT.
However, as the pages are read into storage and then stolen, each shared
page is allocated its own DASD slot and pointed to by only one swap
table entry. The last user to purge a shared system causes both sets of
page and swap tables to be freed. See the !M/31Q ~Y2tem Pro~rammerls
~Yig~ for a description of shared segments.
Segments that are to be saved in this manner must be loaded at an
address within your virtual machine and then must be saved. To do this
in CMS (following eMS conventions) you must define your virtual machine
size large enough to contain the discontiguous segments, loader tables,
and CMS control block storage at the end of virtual storage; load the
segments; save the segments;
then reduce the virtual storage to its
normal size. When you attach these segments, they are attached beyond
the end of your virtual machine.
The procedures for loading and saving
discontiguous segments are similar to the procedure that already exists
for loading and saving systems.
CMS has three EXEC procedures to help
discontiguous saved segments:
you place portions of
CMS in
•
DOSGEN, which loads and saves CMS/DOS support
•
VSAMGEN, which
support
•
CMSXGEN, which loads and saves the CMS Editor, EXEC processor, and OS
simulation routines
loads and saves
CMS/VSAM and Access
Method Services
See the section "Loading and Saving Discontiguous Saved Segments" in
"Part 3. Generating VM/310 (CP, CMS, RSCS, and IPCS) " for descriptions
of how the DOSGEN and VSAMGEN EXEC procedures are used.
The CMSXGEN
procedure is described in Step 24 of the system generation procedure in
Part 3.
Part 1. Planning for System Generation
81
Discontiguous Saved Segments
CP checks to see whether a virtual machine has altered any shared
segments before it dispatches the next virtual machine.
When a shared
segment is found to have been modified as a result of a CP STORE,
ADSTOP, or TRACE command, CP issues a message to indicate that the
shared copy has been replaced by a nonshared copy. Execution continues
in the virtual machine with the nonshared copy. However, if a protected
shared segment is found to be altered by any other means and segment
protection is on, CP sends a message to the current virtual machine to
identify the altered page. The altered page is made inaccessible and the
virtual machine's execution is stopped by placing it into console
function mode.
Saved systems must be named and may be shared.
The discontiguous
saved segment support is similar to saved system support. Therefore,
you should understand saved systems before you read this section; see
the VMLJ70 ~§iem ~!9g!amme!~2 Guide for a description of saved systems.
A discontiguous saved segment is a segment that:
•
Has a name associated with it
•
Was previously loaded and saved
•
Mayor may not be shared by multiple virtual machines
•
Can be loaded by a particular virtual machine in
testing and debugging
nonshared mode for
A discontiguous saved segment can be logically attached to a virtual
machine when it is needed and detached when it is not needed.
The
attaching and detaching is done by the name associated with the segment.
The virtual machine attaching and detaching discontiguous saved segments
must issue CP DIAGNOSE instructions to perform the proper linkage.
Discontiguous saved segments are loaded at the same address at which
they were saved: this address must be higher than the highest address of
the virtual machine that is attaching it.
A discontiguous saved segment
cannot be attached by a virtual machine executing in the virtual=real
area.
An example of a discontiguous saved segment is the segment of CMS
that supports DOS program development and testing under CMS.
This
segment is reentrant and is named CMSDOS. The starter system includes
an EXEC procedure, DOSGEN, that helps you load and then save this
segment. CMS contains all the necessary linkage to load the CKSDOS
segment when it is needed.
The main advantage of placing the CMS support for DOS in a
discontiguous saved segment is that it conserves real storage. Not all
CMS users need the DOS support, and those who do need it probably do not
need it all the time. CP keeps the segment tables in real nonpageable
storage. These segment tables have an entry for each segment (whether
it is saved or nonsaved)
of virtual storage available to each active
virtual machine.
By putting the DOS support in a discontiguous saved
segment (called CKSDOS), real nonpageable storage is conserved. Your
segment table has entries for the CMSDOS segment (and all segments up to
it) only when the CKSDOS segment is attached to your virtual machine.
Using Discontiguous Saved Segments
To use discontiguous saved segments you must:
•
82
Allocate permanent
segment.
space on a CP-owned
volume to contain
IBM VM/370 Planning and System Generation Guide
the saved
Discontiguous Saved Segments
•
Assign a name to th~ segment and specify where it is to be stored on
disk.
To do this, define an entry in the system name table
(DMKSNTBL) with the NAMESYS macro.. See "Coding the NAMESYS Macro" in
"Part 2. Defining Your VM/370 System." Or you can use the entries in
the DMKSNT module supplied with the starter system.
•
Load and save the segment, using
(CMSXGEN, DOSGEN, or VSAMGEN).
•
Be sure that the proper
linkage for attaching and detaching
di-scontiguous saved segments is in the operating s-ystemthat needs
the segment. CMS contains the linkage necessary to attach and detach
the discontiguous saved segments it supports.
the
appropriate EXEC
procedure
Usually, the direct access storage space is allocated and the system
name table entries are created during system generation. You allocate
DASD space as permanent (PERM) by executing the Format/Allocate program.
This program is executed during system generation, but it is a
standalone program that can be executed at any time. During system
generation, you designate the Cp-owned volumes by coding the SISOWN
macro of the DMKSYS file.
The system name table (DMKSNT) is also
created during system generation.
If, at some time after system
generation, you wish to change the DMKSYS or DMKSNT files, you can do a
partial system generation and reassemble those files using the GENERATE
EXEC procedure. GENERATE is described in "Part 5. Updating VM/370."
You can load and save a
system generation.
discontiguous saved segment any
~E.~cial
Using ,ihe
£Q1!§ideratiQ1!§.!Q!:
~imulation
~dit.Q!:, ~!~£
time after
PrQ£~Q!:,
and
Q.~
Routine~
By the time you complete the VM/370 system generation procedure, the CMS
editor, EXEC, and OS simulation load modules exist on the CMS S-disk.
Also, if you have followed VK/370 recommendations, you have created a
discontiguous saved segment, called CMSSEG, that contains the CMS
editor, EXEC, and OS simulation routines (you save C~SSEG in Step 24).
During virtual machine execution, CMS handles a call to the editor or
EXEC processor as follows:
•
CMS first searches for editor or
CMS disks, except the S-disk.
EXEC load modules on
all accessed
Not~:
If you wanted to test changes made to the editor or EXEC
processor, you could place the load modules on a disk other than the
S-disk (that is available only to your virtual machine) and test
those changes.
•
CMS next attempts to attach the shared segment.
If you have not
reset the name of the shared segment by issuing a SET SYSNAME
command, CMS attempts to attach the CMSSEG segment. If you wish to
use an alternate segment, indicate the alternate segment on a SET
SYSNAME command and issue that command before the segment is
attached. If you do not want CMS to attach a shared segment when
editor, EXEC, or OS simulation routines are needed;
issue a SET
SISNAME command specifying as the segment name any name that does not
correspond to a named saved segment.
•
Last, CMS attempts
S-disk.
to load
the
appropriate modules
from the
Part 1. Planning for System Generation
CMS
83
Discontiguous Saved Segments
handles a call for as simulation routines in a similar manner.
first attempts to attach the named saved segment. Again,
you can
indicate an alternate segment for loading or avoid loading a named saved
segment by specifying a nonexistent segment as the alternate. If a
named saved segment is not available, C~S searches all accessed disks
for the as simulation load modules and loads them into high user storage
when they are found.
The routines are kept in storage until CMS is
reloaded or until a SET SYSNAME command is issued for CMSSEG.
C~S
C~S
Note that there is overhead associated with controlling saved
segments and ensuring their integrity. In small systems, the overhead
associated with using the CMSSEG saved segment may not be offset by the
benefits of sharing storage among users. Therefore, each i~stallation
must decide whether the use of CMSSEG is appropriate for its own
environment.
84
IBM
V~/370
Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Attached Processor Systems
Attached Processor Systems
To produce an
when asked
attached processor system it is necessary
to reply "YES"
ARE YOU GENERATING AN AP SYSTEM?--RESPOND (YESINO)
by the GENERATE or VMS ERV EXECs. A response of "YES" will cau se DMKRnA
CNTRL and APLOAD (or APVRLOAD for a system with a virtual=real area) to
be used in place of DMKRnO CNTRL and CPLOAD (or VRLOAD) EXECs.
.Vi. ,"",IVi
"'"
O I\IIKAI\IIAr'
I\III1CIIR
iV ..........
_.-
DMKAMAC MACLIB contains one member, OPTIONS COPY, which is identical to
OPTIONS COPY in DMKMAC
MACLIB except that the variable n&AP"
is set to
1, causing AP support to be included in the module you are assembling.
The DMKRnA CNTRL file uses this MACLIB and creates a
TXTAP rather than
the usual TEXT, if necessary; that is,
the module is affected by
attached processor support.
Modules Containing AP Support
To find the modules that have
use the following procedure:
attached processor support
the Release 6
TXTAP decks,
1.
List all modules from
filetype of TXTAP.
2.
List all
TX'TAP.
3.
Combine the lists. You should then have a complete list of the
TXTAP decks which include all modules containing AP support.
modules from the system
source tape that
PUT that have a
have a
filetype of
six modules have been created for AP support. The nucleus-resident
modules are DMKEXT, DMKIOK, and DMKMCT.
The pageable modules are
DMKAPI, DMKCLK, and DMKCPU.
These modules have only a TXTAP and their
names are contained only in the AP loadlists (APLOAD and APVRLOAD).
Part 1. Planning for System Generation
85
Ii
8n
lJ.!.
J..!.
"
I j 0
I
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
VM/370 Storage Requirements
Estimating VM/370 Storage Requirements
This section contains information about:
•
•
•
•
Estimating real storage requirements for VM/370
Reducing the size of the CP nucleus
Estimating direct access storage requirements
Estimating storage requirements for CMSminidisks
The "Specifying a virtual=Real Machine" section includes information
about estimating real storage requirements for a virtual=real machine.
Note: The requirements specified here are
not to its extensions.
applicable only to
the SCP,
Real Storage Requirements for CP
Figure 14 lists the various
storage required for each.
CP requirements
and the
amount of
real
r----CP Requirement
Real Storage Allocated
Res iden t nu cleus
Approximately 152K
Internal trace table
Conventionally, 4K of storage is allocated
for each 256K of real storage. This
storage is set aside at IPt time. See
"SYSCOR Macro" in Part 2 for details of
how to increase the size of the internal
trace table.
Real control blocks
There is a control block for each real
dev ice, control unit, and channel:
• 88 bytes/real device
• 72 bytes/real control unit
• 96 bytes/real channel
• 24 bytes for each remote 3270 or real
3704/3705
Permanently allocated
free storage
(virtu al cont rol
blocks and tables).
For installation
control of free
storage, use the
SYSCOR macro. See
"Part 2. Defining
Your VM/370 System."
The default value is a minimum of 12K, plus
an additional 4K for each 64K of real
storage above 256K.1 This storage is set
aside at IPL time. Each logged-on virtual
machine requires a virtual machine ,control
block (VMBLOK), a segment table (SEGTABLE),
a page table (PAGTABLE), a swap table
(SWPTABLE), and a control block for each
virtual device, control unit, and channel.
~-------------------------------------------------------------------------------------~
igure 14. Real Storage Requirements for CP Requirements (Part 1 of 2)
IAn additional 25% of free storaqe is allocated in AP mode.
Part 1. Planning for System Generation
87
--~-
--
---v
. -_ . . -
... ~
"r-- .... -"""'"
~t"'-
.....
"
,J...."
"'J
......... ~
u" ..... .,J
V'J..J'
VM/370 storage Requirements
r---------------------------------------------------------------------------~
CP Requirement
Real storage Allocated
The storage required is:
•
504 bytes for the VMBLOK
• 64 bytes/1M of virtual storage for
the SEGTABLE
• 40 bytes/64K of virtual storage for
the PAGTABLE
•
136 bytes/64K of virtual storage for
the SWPTABLE
• 56 bytes/virtual device
•
40 bytes/virtual control unit
•
40 bytes/virtual channel
L
Figure 14. Real storage Requirements for CP Requirements (Part 2 of 2)
For example, if you have:
1M
29
6
3
of real storage
real dev ices
real cont rol units
real channels
and 12 virtual machines defined, each with:
1 virtual reader
1 virtual printer
1 virtual punch
3 v irtual disks
3 virtual channels
1 virtual machine console
3 virtual control units
320K of virtual storage
you would estimate CP real storage requirements as follows.
152K
16K
4K
for the CP resident nucleus
for the CP internal trace tabl-e (see "SYSCOR Macro")
for the real control blocks, calculated as follows:
88 X 29 = 2552 bytes for the real devices
72 X 6 = 432 bytes for the real control units
96 X 3 = 288 bytes for the real channels
the sum is:
2552
(approximately 4K)
60K
232K
+
432
+
288
=
3272
bytes
for permanently allocated free storage (default value)
real storage required
Also, as each of the 12 virtual machines defined logs on, approximately
2K of real storage is allocated to each from the permanently allocated
free storage.
88
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
VM/370 storage Requirements
504
64
200
680
56
56
56
168
120
56
120
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
for
for
for
for
for
for
for
for
for
for
for
a VMBLOK
the SEGTABLE
the PAGTABLE
the SWPTABLE
a virtual reader
a virtual printer
a virtual punch
three virtual disks
three virtual channels
a virtual machine console
three virtual control units
2080 bytes for each of the logged-on users defined
The number of virtual devices for a virtual machine cannot exceed the
value determined by (7FFFF/VDEVSIZE), where VDEVSIZE is the size of the
VDEVBLOK.
If a greater number of virtual devices is specified, results
may be undesirable.
See the "specifying the Amount of virtual=Real Space" section for an
example of estimating storage requirements and determining the maximum
size of the virtual=real area.
Reducing the Size of the CP Nucleus
Support for the 3340, 3704,
3705, 3066, 3850, and 3270 increases the
size of the CP nucleus.
3340 support is handled by the module DMKTRK.
The 3704/3705 is primarily handled by the module DMKRNH.
3850 Mass
storage system support is provided in module DMKSSS.
The graphic device
support for locally attached terminals is handled by the module DMKGRF
while the remot~ 3270 support is handled by the DMKRGA,
DMKRGB, and
DMKBSC modules.
Each of these modules occupies space in the system
nucleus.
This nucleus area can be reclaimed by deleting DMKTRK,
DMKRNH,
DMKMSS, DMKGRF, DMKRGA, DMKRGB, and DMKBSC from the system loadlist EXEC
file.
caution should be exercised before deleting them from the
loadlist.
If you generate a system which includes 3340 disks in the IIO
configuration, you cannot delete the module DMKTRK. If you generate any
type of locally attached graphic device in the DMKRIO assemble file, you
cannot delete the module DMKGRF. Or, if you generate remote 32705 in
the DMKRIO assemble file, you cannot delete the DMKRGA, DMKRGB, and
DMKBSC modules.
Module DMKSSS cannot be deleted if you are using a
3850. In addition, if you generate the 3704/3705 in the DMKRIO assemble
file, you cannot delete the DMKRNH module.
The following names are undefined during
DMKTRK is deleted from the loadlist:
the VMFLOAD
procedure if
The followinq names are undefined during the VMFLOAD
DMKGRF and DMKRNH are deleted from the loadlist:
procedure if
DMKTRKIN
DMKGRFEN
DMKGRFIC
DMKGRFIN
DMKTRKFP
DMKRNHCT
DMKRNHIC
DMKRNHIN
DMKTRKVA
DMKRNHND
DMKRNHTR
Part 1. Planning for System Generation
89
-I.
-----
--.1:""---
. • . __ .
-1
----
_
.. - - -
---"
VM/370 Storage Requirements
The followinq names are undefined during the VMFLOAD
DMKBSC, DMKRGA, and DMKRGB are deleted from the loadlist:
DMKBSCER
DMKRGBEN
DMKRGBIC
DMKRGAIN
The following names are undefined during
DMKSSS is deleted from the loadlist:
DMKSSSHV
DMKSSSAS
procedure if
1)MKSSSMQ
DMKSSSL 1
DMKSSSI1
DMKSSSL2
the VMFLOAD
procedure if
DMKSSSVA
DMKSSSDE
DMKSSSEN
DMKSSSL3
If you generate your system without the V=R option, the module DMKVSC
can be deleted from the loadlist with no undefined symbols.
Direct Access Storage Requirements for CP
Fiqure 15 shows how much DASD soace CP requires by n~sn typ~ft
~h~
followinq paragraphs describe in detail how you determine the amount of
DASD space CP requires
for the nucleus, error recording, warm start
data, checkpoint data,
directory, saved systems data,
paging, and
spoolinq space.
2319
CP Nucleus
Error Recording 1
Warm Start
Checkpoint Start
Directory
Sa ved Syste ms
pagin g Space
Spoolinq Space
Total System 2
231~
~330
varies
2
varies
2
1
1
1
2
2
varies
32
50
93 cyl
2
varies
18
30
57 cyl
~lQ~
varies
2
1
3
2
varies
40
53 cyl
33~Q
varies
2
1
3
2
varies
40
70
123 cyl
1J~Q
varies
2
1
1
2
varies
10
15
33 cyl
Fiqure 15. DASD Space Requirements by DASD Type
CP NUCLEUS DASD REQUIREMENTS
The CP nucleus (without a virtual=real area) currently requires about
115 pages of disk space for resident and pageable functions.
To determine the number of cylinders required for the CP nucleus,
refer to the load map produced during system generation. One DASD page
is required for each page of fixed and pageable nucleus (for a CP
nucleus without a virtual=real area). The calculations for the amount
of DASD space needed for a CP nucleus with a virtual=real area are in
the" Specifying a virt ual=Real Machine" section.
lThe default is 2 cylinders but up to 9 cylinders may be specified via
the SYSERR operand of the SYSRES macro.
2These figures do not include space for the nucleus or saved systems.
90
IBM VM/370 planning and System Generation Guide
Page of GC20-1801-10 As
Update~
April 1, 1981 by TNL GN25-0837
VM/370 storage Requirements
For example, if the last module entry in the load map is at page 55
(hexadecimal), 85 pages of disk space are required for CP nucleus
residence.
The number of cylinders required depends on the system
residence device used; see the "Saved System DASD Requirements" section
that follows for the number of pages per cylinder each device can
accommodate.
Normally, the number
of cylinders required for
CP nucleus residence
is:
6
5
3
2
cylinders
cylinders
cylinders
cylinders
on
on
on
on
a
a
a
a
2305 or 3340
2314 or 2319
3330 or 3333
3350
Part 1. Planning for System Generation
90.1
ApJ....L.L
90.2
I,
!;I!OI
IBM VM/370 Planning and System Generation Guide
V~/370
ERROR RECORDING DASD
REQUIRE~
storage Requirements
ENTS
Error recording space is variable (from 2 to 9) and is
the SYSERR operand of the SYSRES macro instruction.
WAR~
START DATA DASD
established by
REQUIRE~ENTS
Formulas for calculating the amount of warm start space needed are in
"Part 2. Defining Your VM/370 System" under the discussion of the SYSWR~
operand of the SYSRES macro.
CHECKPOINT START DATA DASD REQUIREMENTS
The amount of space required for the dynamic checkpointing of the V~/370
spool file system is discussed in "Part 2. Defining Your V~/370 System"
under the description of the SYSRES macro.
VM/370 DIRECTORY DASD REQUIREMENTS
The VM/370 directory normally requires two cylinders so that it can be
rewritten without disturbing the active directory and swapped after a
successful update. Equations for computing directory sizes are found in
the "Allocating DASD Space for the VM/370 Directory" section of Part 2.
SAVED SYSTEM DASD REQUIREMENTS
Saved systems require
one page for each page saved,
plus an additional
information pageo
However. a 3704/3705
may require up to four
additional information pages.
To save one copy of the eMS system requires two cylinders on a 23i4,
2319, or 3340, or one cylinder on a 3330, 3333, or 3350.
PAGING AND SPOOLING DASD
REQUIRE~ENTS
Paging and spooling space requirements are installation-dependent.
(The
values shown in the preceding list are for average systems.)
Paging
space is allocated at a rate of:
24 pages/cylinder on
32 pages/cylinder on
51 pages/cylinder on
120 pages/cylinder on
(The 2305 is normally
a 2305 or 3340
a 2314 or 2319
a 3330 or 3333
a 3350 in native mode
used for paging only.)
Spooling data is placed in a 4K-byte buffer with the necessary
channel programs required for each record. Data capacity of spooling
cylinders thus varies with the data and CCWs used.
Part 1. Planning for System Generation
91
VM/370 storage Requirements
The primary system operator is warned when the paging/spooling space
becomes 901 full. The !!/37Q ~Y§iem ~~~~2 manual tells the operator
what he should do if this warning occurs.
VSAM AND ACCESS METHOD SERVICES REQUIREMENTS
The VSAM and access method services
space and virtual storage.
support in CMS requires
both DASD
The amount of DASD space needed is listed in Part 3, in the section,
"Loading and Saving the CMSVSAM and CMSAMS Segments."
The VSAM and access method services support adds approximately 2K to
the size of the CftS nucleus.
In addition, this support uses free
storage to execute the DOS/VS logical transients and for buffers and
work areas. VSAM issues a GETVIS macro to request free storage.
If the CMS/DOS environment is invoked with the VSAM option
set dos on {vsam
part of the CMS/DOS virtual storage is set aside for VSAM use.
IPCS Requirements
IPCS supports the same basic Vft/370 processor configurations that are
supported by other components of VM/370 with a minimum of 3S4K of real
storage. This is the basic VM/370 requirement.
EXTERNAL STORAGE
The disk storage needed by IPCS is divided into two parts.
The first
part does not vary greatly (only problem reports and symptom summary are
affected). It contains the IPCS command modules, the current NUC MAP,
problem reports, and the symptom summary.
These files occupy less than
5 cylinders on a 3330, allocated as shown:
•
•
•
100 problem reports plus symptom summary
NUC MAP
IPCS modules
201
451
35"
The second part contains the dumps. The size of a dump depends mainly
on the size of the system being dumped, and the operand of the CP SET
DUMP command, either ALL or CP. The table below shows typical space
usage by device type for the fixed area and for one dump.
92
IBM VM/370 Planning and System Generation Guide
VM/370 Storage Requirements
,
,
r
Cylinders
I
I
Files
I
I
I I PCS modules
3330
2319
3340
3350
, NUC MAP
I
I
I
I
I
I
I
~OO problem reports
symptom summary
51-2K
512K
1024K
1024K
CP
ALL
CP
ALL
5
9
1.5
2.5
3
6
3
5
6
11
14
3
4
1
7
a
16
1.5
1.5
3
,
I
I
I
I
I
I
I
,
I
I
I
L
REAL STORAGE
The real
storage requirement is
the normal CP
requirement of
approximately 2K for control blocks while the IPCS virtual machine is
logged on. Other real storage usage is controlled by the VM/370 demand
paging implementation.
Estimating DASD Storage Requirements for eMS
The following information is intended to help you
direct access storage space for CMS minidisks.
allocate sufficient
A 2314 cylinder formatted by the CMS FORMAT command contains 150
aOO-byte blocks, which can contain approximately 1300 aO-byte lines of
source programs and data.
A 3330 cylinder formatted by the CMS FORMAT command contains 266
BOO-byte blocks, which can contain approximately 2300 aO-byte lines of
source programs and data.
A 3340 cylinder formatted by the CMS FORMAT command contains 96
which can contain approximately 960 80-byte lines of
source programs and data.
SOO-byte blocks,
A 3350 cylind'er formatted by the CMS FORMAT command contains 570
aOO-byte blocks, which can contain approximately 5000 aO-byte lines of
source programs and data.
Each BOO-byte block contains file control information as well as your
data. A given amount of data requires more file information if put into
many small files instead of a few large files.
For an average
sufficient:
CMS user,
the
following minidisk
space should
be
•
7 cylinders of 2314 space (for
source programs and data)
approxilla tely 9100 aO-byte
lines of
•
4 cylinders of 3330 space (for
source programs and data)
approximately 9600 . aO-byte
lines of
•
11 cylinders of 3340 space (for
source programs and data)
approximately 10560 aD-byte lines of
•
2 cylinders of 3350 space (for
source programs and data.
approximately 9120 aO-byte
lines of
Part 1. Planning for System Generation
93
94
IBM VM/370 Planning and System Generation Guide
Minidisks
Minidisks
The external storage requirements of multiple virtual machines executing
concurrently would be excessive if each virtual machine were assigned
one real direct access storage device for each virtual DASD specified in
its configuration.
Therefore, if you do not require the full capacity of a real DASD,
you can be assigned one or more minidisks instead.
A minidisk is a
logical subdivision of a physical disk pack with its own virtual device
address, virtual cylinders (starting with 0, 1, 2, and so on) and a VTOC
(volume table of contents or disk label identifier).
Each of your
minidisks is preallocated the number of contiguous full cylinders that
were specified in the VM/370 MDISK directory record, and that space is
considered to be a complete virtual disk device.
Minidisks are controlled and managed by CPa
If a virtual machine
attempts to use DASD space beyond the boundaries defined for its
minidisks, CP presents a command reject
(seek check)
to the virtual
machine. If a system is to be run on both a virtual and a real machine,
minidisks for that system must start at real cylinder zero. For a
detailed list of minidisk restrictions,
see "Appendix F: V"/370
Restrict ions. "
The remainder of this section describes the following characteristics
of minid isks:
•
•
•
•
•
Definition
Space allocation
Track characteristics
Alternate tracks
Labels
f""
M"Inl"d"IS k S
O 9_lnlng
Permanent minidisks are defined in the VM/370 directory entry for a
virtual machine. A minidisk defined in the directory via an "DISK
statement is a permanent part of the virtual machine configuration and
the data on the minidisk is available to the user from session to
session.
If any virtual machine has a temporary requirement for direct access
space, this can be filled from a pool of T-disk space. You specify the
size of the T-disk pool when you allocate disk space with the standalone
Format/Allocate program. Minidisks created from the T-disk area must be
initialized and are available to the virtual machine for the duration of
one terminal session.
When the virtual machine logs off or issues a CP
command to release the temporary minidisk, the area is returned to CPa
It is up to you to allocate minidisks on V"/370 disks in a manner
that minimizes arm contention and physical overlap.
Information about
minimizing arm contention is found in the "Preparing the CP System
Control File (D"KSY~" section of Part 2.
!Ql~: The V"/370 directory function
neither checks nor flags overlapped
or duplicate minidisk extents. Nor does the function provide DASD space
records for unused space or used space.
Part 1. Planning for System Generation
95
Minidisks
Figure 16 illustrates the use and definition of minidisks. The disk
labeled OSDOS1 contains several minidisks,
some formatted to OS
requirements and others to DOS requirements. OSDOS1 is a 2314 volume.
The directory entry for userid ABC (an OS user) describes the virtual
device 230 as a 50-cylinder area, and the virtual device 231 as a
20-cylinder area on real volume OSDOS1.
The directo~y entry for userid
XYZ (a DOS user) describes the virtual device 130 as a 50-cylinder disk
area on a real volume OSDOS1.
Real
Cylinder
Number
Virtual
Cylinder
Number
00
Real
Cylinder
Number
001
t
Virtual
Cylinder
Number
000
VOL1CPVOL 1
001
OSDOS1
oo~
~
t
020
19
DOSLIB
J
030
031
49
49
50
00
t
UNASSIGNED
00
SYS1.LlNKLIB
DOSRES
MFTSUB
49
99
100
00
SYS1.COBLIB
MFTWRK
I
119
19
060
061
:
202
120
202
29
CP
SPOOLING
AREA
VM/370 User Directory Entry for user ABC (An OS user)
VM/370 User Directory Entry for user XYZ (A DOS user)
USER
ABC
123
ACCOUNT
985
CONSOLE 009
3215
MOISK
230
2314
MOISK
231
2314
MOISK
232
2314
SPOOL
OOC 2540
000 2540
SPOOL
SPOOL
OOE
1403
USER XYZ PASSWORD
ACCOUNT NUMBER BIN14
CONSOLE
01 F
3215
SPOOL
C
2540 READER
SPOOL
0
2540 PUNCH
SPOOL
E
1403
MDISK
130
2314050050 OSOOSl W
MDISK
131
2314001020 CPVOL1 W
512K
000050 OSDOS1 W
100020 OSDOS1 W
031 030 CPVOL 1 W
READER A
PUNCH A
A
Note: VM/370 allows cylinders on a 2314 or 2319 normally reserved for alternate track assignment
(cylinders 200 to 202) to be optionally used for normal data storage if included within the limits of
a minidisk.
Figure 16.
Use and Definition of Minidisks
The real volume CPVOLl also contains disk areas assigned to userid
ABC (virtual device address 232) and userid XIZ (virtual device address
131) .
96
IBM VM/370 Planning and System Generation Guide
Minidisks
Note! On a 3330, 3340,
real
cylinder 0 unless
or 3350, an OS/VS, or OS minidisk must start at
the VTOC is limited to one track.
See the list
of restrictions
~n
"Appendix F:
VM/370 Restrictions"
for more
information and explanation of 3330/3340/3350 restrictions.
Minidisk Space Allocation
OS bases all of its space allocation parameters on the volume table of
contents (VTOC) label written on each disk; it determines the amount of
space available on that volume from the format-5 (space accounting) data
set control block (DSCB). Thus, for OS to support minidisks, a VTOC
must be written whose format-5 DSCB reflects the desired size of the
minidisk. The remainder of the disk space on the real disk appears to
OS to be permanently dedicated, and not assignable by the OS space
accounting routines.
The IBCDASDI service program should be used to
format minidisks for use by OS or DOS.
A DASD volume containing multiple minidisks contains some tracks in
which the cylinder address in the count fields of records RO and R1 do
not agree with each other. If an attempt is made to read this volume by
IEHDASDR, you may get messages IEH8l3I or IEH869I. To prevent this,
initialize the disk with the FORMAT function of IEHDASDR before using
it. This function rewrites RO and R1 on each track so that the count
fields agree with each other.
DOS space allocation is specified in the EXTENT job control card. It
is your responsibility to see that the EXTENT cards refer to valid
minidisk cylinders. On a 2314 or 2319 volume, the last cylinder of any
minidisk initialized by IBCDASDI is always reserved for use as an
alternate track cylinder. Therefore, a DOS minidisk on a 2314 or 2319,
must have a minimum of two cylinders.
For example, if you are
specifying a ten-cylinder minidisk, the EXTENT card must refer to
cylinders 0 through 8 only. This leaves the last cylinder for alternate
track assignment.
However, on a 3330, 3333, 3340, or 3350 minidisk,
IBCDASDI does not reserve a cylinder for alternate tracks within each
minidisk. Therefore, a ten-cylinder minidisk must be defined in the
EXTENT card as cylinders 0 through 9.
A minidisk always begins at virtual cylinder zero. Its minimum size
is one cylinder unless it is located on a 2314 or 2319 disk and is
formatted by the IBCDASDI service program; in which case, the minimum
number of cylinders is two and the second cylinder is used as the
alternate track cylinder. Except for the 3350, which can be used in
3330-1 or 3330-11 compatibility mode or in native mode, a minidisk must
exist on its real counterpart, that is, a virtual 3340 minidisk must
reside on a real 3340.
When minidisks are defined on MSS 3330V volumes, the minidisks are
virtual 3330-1 disks. The presence of the MSS and 3330V system volumes
is transparent to a virtual machine accessing minidisks.
VM/370 controls the boundaries of minidisks. If an attempt is made
to refer to a DASD address outside the boundaries specified in the MDISK
directory statements, CP presents a command reject (seek check)
IIO
error to the virtual machine.
Nol~: If
the cylinder addresses in the MDISK statements inadvertently
overlap each other, the integrity of data in the overlapped cylinders
may be compromised with no error indicated.
Part 1. Planning for System Generation
97
Plin idisks
Track Characteristics
Like real disks, minidisks must be formatted for use by the appropriate
service program.
A minidisk is initialized for use by executing one of
the following service programs in a virtual machine:
•
For all CPlS
formats the
records.
•
For Cp disKs, t.he standalone CP Format/Allocate program must be used
to format specified tracks into 4096-byte blocks.
•
For OS, DOS, and CMS/VSAM minidisks the IBCDASDI service program
writes read-only track descriptor records for each track, and clears
the remaining portion of each track to binary zeros. It also writes
a format-5 DSCB whose contents reflect the minidisk size (the amount
of free space available for allocation).
Any disk initialization
program that supports the operatinq systems use of the DASD device
type may be used if you are initializing full disks.
disks except CPlS/VSAPI disks, the CMS FORMAT command
specified tracks into 800-byte blocks or physical
Minidisks defined in the VM/370 directory are initialized only once;
temporary minidisks must be initialized each time they are used.
Alternate Tracks
3330/3350 DISKS
Alternate tracks assigned at the factory or by IBCDASDI in the field are
automatically handled on the 3330 or 3350 by the control unit.
Minidisks on the 3330 .Model 1 or 2 should be specified on cylinder 0
through cylinder 403 only.
The remaining cylinders (404 to 411) are
automatically used by the 3830 Control Unit for alternate tracks.
Minidisks on the 3330 Model 11 can be specified on cylinder 0 through
cylinder 807. Minidisks on the 3350 should be specified on cylinder 0
through cylinder 554 only.
The remaining cylinders (555 to 559) are
automatically used by the 3830 control unit for alternate tracks.
3340 DISKS
The 3340 DASD device uses a hardware logic that lessens the dependence
on alternate track usage. The 3340 can bypass the defective portion of
a data track and write the balance of the record in the space remaining.
In the case where an alternate track is required, the alternate track
can be assigned by IBCDASDI standalone using a dedicated 3340 device.
Cylinder 348 on the 3348 Data Module, Model 35 and cylinders 696 and 697
on the 3348 Data Module, Model 70 are reserved for this purpose. Once
IBCDADSI has assigned the alternate track, the disk, including the
cylinder containing the defective track, may be used for any purpose
whatever, including CP system residence, CMS minidisks, and so forth.
There are only two restrictions:
•
A minidisk should not be located where its track 0, cylinder 0 falls
on a defective track because then it will be impossible for the CP
IPL command to function for that minidisk.
•
Any operating system doing 510 to this disk must be capable of doing
the normal alternate track error recovery.
!ot~:
98
eMS qualifies here because it uses DIAGNOSE in place of SIO.
IBM VM/370 Planning and System Generation Guide
Minidisks
When an attempt to do I/O on a defective 3340 or 3344 track results in a
track condition check, software error recovery procedures provide for
switching to an alternate track. For CP I/O and for diagnose I/O issued
from a virtual machine, the switching is fully automatic and the issuer
o-f the I/O request is not aware of it. For SIO issued from a virtual
machine, a track condition check is reflected to the virtual machine so
that the operating system in the virtual machine will run its own error
recovery procedures.
Since alternate tracks are assigned from the high-order cylinders at
the end of the real 3340, the virtual machine will attempt to seek
outside of the minidisk to recover.
The VK/370 CCW translation process
allows seeks outside of the minidisk to an alternate track provided that
the particular alternate track is assigned to a defective track within
that minidisk.
After seeking to the alternate track, any attempts at
head switching to an unowned track in this cylinder are prevented.
On 3340-35 devices, the primary data area is cylinder 0-347. Cylinder
348 is reserved for alternate tracks.
On 3340-70 devices or 3344
devices, the primary data area is cylinder 0-695. Cylinders 696-691 are
reserved for alternate tracks.
Previously, the "alternate tracks" cylinders of 3340/3344 devices were
often used as primary data cylinders, but now these cylinders must be
reserved exclusively for alternate track use. Therefore, when changing
from an old system (prior to Release 5 PLC 6) to a current system, it is
necessary to revise the space allocation and minidisk layouts on any
3340/3344 disk where the "alternate tracks" cylinders had been used as a
primary data area.
~Y2igm
Resid~£~ ~~iic~:
If the system residence device contains
Ital ternate tracks" cylinders that have been used as the primary data
area, the files of existing control statements should be revised prior
to generating a new system. In particular, the allocate function
performed on the system residence disk and other CP-owned disks may have
to be revised, and subsequent to this revision, the specification of the
SYSRES, NAKESYS, and NAKENCP macros should be reviewed.
~inidisk
Devic~: If
any minidisks on a 3340/3344 extend into the
alternate tracks cylinders, they can be copied to another area of the
disk or to another disk using the DASD dump restore (DDR)
utility. In
the past, when a 3340/3344 had a defective track, the cylinder with the
bad track was unusable and minidisks would be allocated adjacent to that
cylinder, but not including it. In this case, all cylinders of the real
disk should be dumped to tape using any version of the DDR utility.
If you use the new version of the DDR utility and the alternate
tracks cylinders have been used as a primary data area, make sure that
you specify the cylinder range explicitly. For example, enter:
DUKP 0 TO 697
Part 1. Planning for System Generation
99
Minidisks
rather than specifying ALL, which no longer dumps anything from the
final cylinders except tracks that have been assigned as alternates.
Then you can execute the IBCDASDI utility to assign alternate tracks to
the defective tracks so that all cylinders become usable. Subsequently,
the new DDR utility can be used to restore minidisks from the tape,
possibly reordering them into the previously unusable cylinders.
Note: Whenever a minidisk is moved to a new location or its size is
changed, the corresponding MDISK statements in the system directory must
be revised.
Only the new versions of the DDR, DIR, and FMT utilities should be
used with 3340/3344 devices after alternate tracks have been assigned.
~ta~t~
Syst~~ ~h~g~§: In release 6 the starter system has been changed
to reserve cylinder 348 for alternate track use. Therefore,
the 3340
starter system can be restored to a disk that has defective tracks
(provided that alternate tracks have already been assigned by IBCDASDI) •
2314/2319 DISKS
On 2314 and 2319 devices, CP and CMS (except CMS/VSAM) do not recognize
or support alternate track techniques for their own use.
DOS, OS, and
CMS/VSAM minidisks, however, do recognize and support alternate tracks
on these types of DASD.
The IBCDASDI service program automatically
assigns the last cylinder in any minidisk as an alternate track
cylinder. When you initialize 2314/2319 devices, you can assign all 203
cylinders for virtual machine and system use.
If a track assigned to a virtual machine
becomes defective, you can:
minidisk area subsequently
•
Run the standalone CP Format/Allocate service program if the minidisk
is used by CP, and flag the whole cylinder containing the defective
track as permanently assigned
(PERM). This prevents CP from ever
allocating that cylinder for CP paging, spooling, or temporary files.
You must remember not to include this cylinder when you allocate disk
space for any virtual machine's minidisk in the VM/370 directory.
•
If the minidisk is used by either DOS, OS, or CMS/VSAM, reformat the
minidisk (including the defective track)
with the IBCDASDI service
program.
An alternate track is assigned at the end of the minidisk.
•
Set up the entire volume containing the defective track as an OS,
DOS, or CMS/VSAM volume and format it with either IBCDASDI or
IEHDASDR for OS or CMS/VSAM disks, or with the DOS Initialize Disk
utility program (INTDK) for DOS disks.
Alternate tracks are assigned
in the standard manner.
Labels
All disks to be handled by CP (as an entity or as a combination of
logical disks) must have a label on real cylinder 0, track 0, record 3.
This label identifies the physical volume to VM/370 and must be in the
form
VOLlxxxxxx
-- or -CMS=xxxxxx
where xxxxxx is a 6-character volume label.
100
IBM VM/370 Planning and System Generation Guide
Minidisks
In addition, all virtual machine minidisks should have a label at
virtual cylinder 0, track 0, record 3. Labels created by IBCDASDI,
IEHDASDR, or INTDK
VOL1xxxxxx
where xxxxxx is a 6-character volume label.
A physical volume that holds only virtual machine minidisks can have
the first of those minidisks starting at real cylinder O. CP recognizes
the physical volume if the first minidisk has a valid label.
In Figure 16, the volume indicated as OSDOS1 has its real cylinder 0
The volume
allocated to a minidisk that is formatted for use by os.
serial number of that minidisk must be OSDOS1, the label that is
associated with the real volume. Since the minidisk label identifies the
physical volume, changing it affects the directory entries of all users
who have minidisks on that volume.
You should not assign real cylinder o to a user as a data area,
because that user (if he has read/write access to the disk) can rewrite
the label on the minidisk.
Additionally, you must not assign user minidisks to begin on real
cylinder 0 of any physical volumes that are to contain CP controlled
areas (for paging, spooling, and so on). On these volumes, cylinder 0
track 0 record 4 contains control information required by CP. The VTOC
labels written are compatible with OS, but indicate to OS that there is
no space on that DASD. The initialization programs used to format OS,
DOS, and CMS/VSAM minidisks write over and destroy this necessary
control information if the space is assigned to a user minidisk, and
this causes CP system failures.
Sharing Minidisks
A minidisk can be shared by multiple virtual machines. One virtual
machine is designated the owner of the minidisk (it has an MDISK control
statement in its VM/370 directory entry describing the minidisk) and
other virtual machines can link to the minidisk.
For example, assume a virtual machine called USERA owns a minidisk at
address
150.
The VM/370 directory entry for USER! contains the
following statement:
MDISK 150 3330 050 010 SYS003 W READPASS
USERA's virtual disk
cylinders 050-059.
is on the volume labeled SYS003
and occupies real
Any other virtual machine that issues the CP LINK command with the
proper password, or has the following LINK statement in its VM/370
directory entry, can read the 150 minidisk belonging to USER!.
LINK USERA 150 cuu RR
The cuu is the virtual device address at which the 150 minidisk
belonging to USERA is linked to another virtual machine. If you define
another virtual machine, USERB, with the following statement in its
VM/3?0 directory entry:
LINK USERA 150 151 RR
Part 1. Planning for System Generation
101
Minidisks
USERB can read data from USERA's 150 virtual disk whenever
read for data on its own 151 virtual disk.
it issues a
You can link to any minidisk that is defined in the V8/370 directory
if that minidisk has a read and/or write password specified in the MDISK
control statement and if the type of link you desire is allowed. Three
types of sharing may exist and, correspondingly, three passwords may be
specified in the MDISK record.
Minidisks may be shared in the following ways:
•
Read-only (R)
indicates that all
are usin9 it in read status.
•
Read/write (W) indicates that one virtual machine may have read/write
access and multiple virtual machines may have concurrent read-only
access.
•
Multi-write (MW) indicates that multiple virtual machines may issue
writes concurrently to the disk.
Generally: +hi~ mod~ of access
requires that the virtual machines include code to control this, such
as the shared DASD support of os.
!Ql~:
See the
description of
£Q!man~ Refer~n£~
to minidisks.
102
!Qr
virtual machines sharing
the disk
the CP LINK command in the !M/370 £f
for more information about linking
Q~~al Q2~
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Configurations
Configurations
Before you begin the system generation procedure,
make sure your
installation has the minimum configuration supported by VM/370 and the
features and facilities required by VM/370.
VM/370 Minimum Configuration
The minimum configuration supported by VM/370 is:
One
One
One
One
One
Two
One
One
One
Processor (393,2i6 bytes of storage)
System Console device
Printer
Card Reader
Card Punch
Spindles of Direct Access Storage
Nine-Track Magnetic Tape Unit
Multiplexer Channel
Selector or Block Multiplexer Channel
To determine
necessar y
for
Requirements."
the amount of real storage and direct access storage
a
configuration,
see
"Estimating VM/370
Storage
A representative VM/370 configuration is:
IBM
4341
2Mb/4Mb Storage
IBM
3278
Display Console Model 2A
IBM
3203
Printer Model 5 -- Two
IBM
3350
Direct Access Storage Model A2
to a 3880 Storage Control Model 1
IBM
2305.
Fixed Head Storage Facility, Model 2
IBM
3420
Magnetic Tape Units -- Two
IBM
3705
Communications Controller
IBM
3277
Display Stations (as needed) with the 3272 Control Unit
(local attachment) or with the 3271 Control unit (remote
attachment)
IBM
3278
Display
Stations (as needed)
with 3274 Control
(local attachment or remote attachment).
Four
drives attached
Part 1. Planning for System Generation
unit
103
page ot
(;;C.lU-H:SU1--IU
AS upaa'tea Aprl.J.
I,
I::::n:n
OJ
~'NL
(;;N.l:>-Uts ..: j /
Configur at ions
Configurations Supported by CMS
CMS supports the following configurations:
•
Virtual storage size:
in multiples of 4K.
minimum of 320K
•
Virtual console:
any terminal
machine operator's console.
bytes, up to 16 million bytes
supported by
VM/370
as a
virtual
I •
,
I
The same unit record devices
(card readers, punches, and printers)
supported by VM/370 as spooling devices,' except the 2520 Punch. See
"Unit Record Devices".
•
Up to ten logical 2314, 2319, 3340,
3330 Model 1, 2, or 11, 3333
Model 1 or 11, or 3350 direct access storage devices.
The maximum
size of a CMS minidisk is:
C 11 S il~A1:!
200
404
808
348
696
555
•
l;UU --1~ A i,j
203
246
246
348
682
115
Dev iCe ~ll'§ (§i
2314/2319 (the entire disk)
3330/3333 Model 1 or 2
3330/3333 Model 11
3340 Model 35
3340 Model 70
3350 (in native mode)
Up to four 2400, 2415, 2420,
track) Magnetic Tape Units.
3410 (9 track
only), or 3420 (7
or 9
Configurations Supported by RSCS
RSCS supports the following configurations:
•
Virtual storage size: Minimum
multiples of 4K.
of 512K,
up to
•
virtual console: any terminal
machine operator's console.
•
Any virtual card readers, punches, and printers
as spooling devices.
•
One logical 2314, 2319, 3330 Model 1, 2, or 11, 3333
3340, or 3350 direct access storage devices.
•
Transmission Control Units: 2701 Data Adapter Unit; 2703 Transmission
Control Unit; or 3704 or 3705 Communications Controllers in EP mode
only.
Only binary
synchronous
communication transmission
is
supported.
supported
by
16 million
VM/370 as
bytes in
a
virtual
supported by VM/370
Model 1 or 11,
The minimum configuration supported by RSCS is:
•
512K virtual storage
•
One console
•
One Reader
•
One Transmission Control Unit
•
One or more binary synchronous lines
machine
104
dedicated to the
IBM VM/370 Planning and System Generation Guide
RSCS virtual
Conf ig uration s
Devices Supported by VM/370
The following devices are supported by VM/370 except as otherwise noted.
The devices are listed by device type:
•
•
•
•
•
•
•
•
Processors
Direct access storage devices
Magnetic tapes
Unit record devices (printers, readers, and punches)
Terminals
Transmission control units and communications controllers
Remote spooling devices
other devices
Part 1. Planning for System Generation
105
Configurations (processors)
Processors
VM/370 supports the following processors:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
IBM
IBM
IBM
IBM
IBM
IBM
IBM
IBM
IBM
IBM
IBt!
IBM
IBM
IBM
IBM
IBM
System/370 Model 135 Submodel 3
System/370 Model 138
System/370 Model 145
System/370 Model 145 Submodel 3
System/370 Model 148
System/370 Model 155 II
System/370 Model 158 UP/I\P/MP1
System/370 Model 158 Submodel 3
System/370 Model 165 II
System/370 Model 168 UP/AP/t!pt
System/370 Model 168 Submodel 3
4331 processor
4341 processor
3031 processor UP/AP
3032 processor UP
3033 processor UP/AP/Mpa
PROCESSOR REQUIRED FEATURES AND FACILITIES
The processor features and facilities required by VM/370 are listed
below. Only the features and facilities that are not standard on a
particular processor are described. For example, the Word Buffer
feature is standard only on the t!odel 148; therefore, the feature number
and requirements are described only for the Models 145 and 145-3.
•
The System Timing facility
(12001),
which includes the
comparator and the processor timer, on the Models 135 and 145.
clock
•
The clock comparator and processor timer (12001) on the Model 145-3.
•
The Floating-point feature
--For the Model 135, feature #3900
--For the Model 145, feature #3910
•
The
•
The Channel Indirect Data Addressing feature on each of the 2860,
28 7 0, and 2880 standalone I/O channels on the Model 165 II or 168.
Ex~ended
Precision Floating feature (13840) on the Model 135-3.
--For the 2860, features 11861, 1862, and 1863
--For the 2870, feature 11861
--For the 2880, features 11861 and 1862
1This System/370 model is supported when running in uniprocessor mode or
with an asymmetric IIO configuration. In an asymmetric configuration,
all I/O devices attached to the system must be attached to one
processor.
106
IBM VM/370 Planning and System Generation Guide
April 1, 1981
Configurations (Processors)
Note: The standalone channels that attach to the System/370 Kodels
165 II and 168 require that the Channel Indirect Data Addressing
feature be ordered as a separate featur'e for proper operation of the
input/output channels in a Dynamic Address Translation environment.
•
The Word Buffer feature (#8810) is required on the System/370 Kodel
145-3.
It is also required on the Model 145 if:
--A 2305 Model 2 Fixed Head Storage device is attached.
--A 3340, 3344, or 3350 Direct Access storage Facility
i~
attached.
--A 3330 configuration includes an Integrated File Adapter
Selector channels, or three or more Selector channels.
and two
No1~: This feature is also recommended for selector channels if 2314,
3330, 3340, or 3350 devices are attached.
DESIRABLE FEATURES
The following processor features are desirable for VK/370:
•
virtual machine assist improves the performance of VK/370 systems
that run virtual storage operating systems in virtual machines. The
manner in which virtual machine assist and VK/370:ECPS
(see below)
are supported on the various VM/370 processors is detailed under
"Using the Performance Options.1!
•
Extended Control - Program Support improves the performance of VM/370
through CP assist and expanded virtual machine assist capabilities.
•
The Extended Floating-point feature, although not required, improves
the
execution of
programs that
use Extended
Floating-point
instructions under VM/370 on Models 135, 155 II, and 158.
--For the Model 135, feature #3840
--For the Model 155 II, feature #3700
--For the Model 158, feature #3700
•
The APL Assist feature provides performance assistance when used with
the VS APL program producte It is available as hardware feature
#1005 on the System/370 Models 135 and 145.
•
The Conditional Swapping feature provides additional instructions
required for the execution of VTAM proqrams. It is available as
feature #1051 on the System/370 Models 135 and 145.
•
The Advanced Control Program Support feature is available only on the
System/370 Model 145 as feature '1001.
It provides additional
instructions required for the execution of KVS (OS/VS2 Release 2 and
above) and/or VTAM.
Note:
The Conditional Swapping feature and the
Program Support feature are mutually exclusive.
Advanced
Control
Part 1. Planning for System Generation
107
l'age or:
l:iL~V-IOVI-IV
AS
upaa~ea
API:"~J.
I~OI
I,
DJ
"!"ftL
l:ift-":>-VO",'
configurations (I/O)
Direct Access Storage Devices
The following direct access
supported by VM/370.
storage
devices
and control
units
are
The direct access storage devices sUpported by VM/370 are:
,.
IBM 2305 Fixed Head Storage, Models 1 and 2.
•
IBM 2314 Direct Access Storage Facility.
•
IBM 2319 Disk storage.
•
IBM 3330 Disk Storage, Models 1, 2, and 11.
•
IBM 3333 Disk Storage and Control, Models 1 and 11.
•
IBM 3340 Direct Access Storage Facility, Models A2, B1, and B2; the
3348 Data ~odules, ~vdels 35, 70, and 7Cr; and the 3344 Direct Acc€sz
Storage, Model B2.
•
IBM 3350 Direct Access Storage, Models A2 and B2.
All of these direct access devices are supported as VM/370 system
residence, paging and spooling devices and as virtual devices for use by
virtual machines. All are supported as dedicated devices. All except
the 2305 are supported by CMS.
The following direct access control units are supported by VM/370:
•
,•
IBM 3345 Storage and Control Frame Models 3, 4, and
145, 145-3, and 148 with the standard ISC for:
--3330
--3333
--3340
--3350
Models 1 and 2
Models 1 and 11
Model A2 and 3344 Model B2
Model A2
IBM 2835 Storage Control Model 1 for 2305 Model 1.
•
•
•
•
IBM 2835 Storage Control Model 2 for 2305 Model 2.
•
IBM 3830 Storage Control
Models 1 and 11.
•
IBM 3880 Storage Control Model 1 for 3330 Models 1,
Models 1 and 11, and 3350 Models A2 and A2F.
•
IBM Integrated File Adapter (#4650) on
for 2319.
108
5 on the Models
IBM 2844 Auxiliary Storage Control for 2314 and 2319.
IBM 3830 Storage Control Model 1 for 3330 Models 1 and 2 only.
IBM 3830 Storage Control Model 2 for 3333 Models 1 and 11 , 3340 Model
A2, and 3350 Model A2.
Model 3 for 3330 Models 1
and 11, and 3333
2, and 11, 3333
System/370 Models 135 and 145
IBM VM/370 Planning and System Generation Guide
Configurations (I/O)
IB~
Integrated File Adapter
(14655) on the System/370 ~odels 135,
135-3, and 138 or the IB~ Integrated storage Control #4660)
on the
System/370 Model 145, 145-3, and 148 for:
•
--3330
--3333
--3340
--3350
Models 1 and 2
Models 1 and 11
Model A2 and 3344 Model B2
Model A2
Noi~: VM/370
does not support any Integrated File
that support more than 64 addresse~.
•
Adapters (IFAs)
IBM Integrated storage Control on the System/370 Model 158 for:
--3330
--3333
--3340
--3350
•
Models 1 and 2
Models 1 and 11
Model 12 and 3344
Model 12
~odel
B2
IBM Integrated Storage Control on the System/370 Model 168:
--3330 ~odels 1 and 2
--3333 Models 1 and 11
--3340 Model 12 and 3344 Model B2
--3350 Model 12
•
IBM 3333 Disk Storage, Models 1 and 11
for the 3330 Models 1, 2, and
11.
•
IBM 3340 Disk Storage, Model 12, and 3344 Model B2.
•
IBM 3350 Disk Storage, Model 12.
2£~cial ~atu~ Reg:!!i~g
.!ith
ih~
3350
Expanded Control Store special feature
(12151)
provides additional
control storage for microprogramming use and is a prerequisite for 3350
disks attached to the 3830 Model 2; or for the 3345 Integrated storage
control units Models 3, 4, and 5 attached to a System/370 Model 145,
145-3, 148, 158 or 168.
The Control
feature 12151.
Store Extension
feature (#2150)
is a
prerequisite for
Notes:
-'~--The IBM 3330 Model 11 can be
used as a system generation device in
the same way as the 3330 Models 1 and 2, since the starter system
does not use cylinders 404-807.
2.
The System/370 Models 145, 145-3, and 148 must have the Word Buffer
feature (#8810) installed in order to attach a 3330, 3340, 3350 or
2305 Model 2.
Part 1. Planning for System Generation
109
Configurations
(Tapes)
Magnetic Tapes
The following magnetic
VM/310.
tape devices and control units
are supported by
The magnetic tape devices supported are:
•
•
•
•
•
•
IBM 2401, 2402, and 2403 Magnetic Tape units
IBM 2415 Magnetic Tape Units, Models 1, 2, 3, 4, 5, and 6
IBM 2420 Magnetic Tape Units, Models 5 and 7
IBl'! 3410/3 (J1 1 Magnetic Tape Unit, l'todels 1, 2, alid 3
IBM 3411 Magnetic Tape Unit and Control, Kodels 1, 2, and 3
IBM 3420 Magnetic Tape Units, Models 3, 4, 5, 6, 7, and 8
The magnetic tape control units supported are:
•
•
•
•
110
IBM 2803 Tape Control
IBM 2804 Tape Control
T'RM
~Ull
fill"! gTH~+
; ('"
rrl"!I'~
"ni + l"!"
{i
r"Tl+ !'''}
IBM 3803 Tape Control
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Configurations (Unit Record)
Unit Record Devices
VM/370 supports the following printers,
readers, punches,
record control units as system spool devices.
and
unit
VM/370 supports the following printers:
•
IBM 1403 Printer Models 2, 3, 7, and N1
•
IBM 1443 Printer Model N1
•
IBM 3203 Printer Model 4 (available on processor Models
only) and Model 5
•
IBM 3211 Printer (Right Indexing only)
•
IBM 3800 Printer
device su pport)
(with 144 print positions)
(complete dedicated
device support;
138 and 148
limited spool
VM/370 supports the following readers/punches:
•
•
•
•
•
IBM
IBM
IBM
IBM
IBM
2501
2520
2540
3505
3525
Card
Card
Card
Card
Card
Reader Models B1 and B2
Punch Models B2 and B3
Read Punch Model 1
Reader Models B1 and B2
Punch Models P1, P2, and P3
VM/370 supports the following unit record control units:
•
IBM 2821 Control Unit
•
IBM 3811 Printer Control Unit
IBM Integrated Printer Adapter (IPA)
•
( on the System/370 Model 135.
IBM Integrated Printer Adapter Basic Control
following on the models 135-3 and 138:
(#4670), and one of the
--1403 Printer Models 2 or N1 Attachment (#4672)
--1403 Printer Model 7 Attachment (#4677)
•
IBM Integrated 3203 Model 4 Printer Attachment, first printer ('8075)
and optionally, second printer (#8076) on the Model 138 and 148~
Part 1. Planning for System Generation
111
page ot GCLU-1tlU1-1U As upaatea Apr1l 1, 1951 by TNL GN25-0537
Configurations (Terminals)
Terminals
The following system consoles are supported
consoles (simulated as 3215 consoles):
by VM/370 as virtual system
•
IBM 2150 Console with 1052 printer-Keyboard Model 7
•
IBM 3066 System Consoles Models 1 and 2 for the System/370 Models 165
II and 168
•
IBM 3210 Console Printer-Keyboard Models 1 and 2
•
IBM 3215 Console printer-Keyboard Model 1
•
for the System/370 Models 138 and 148
IBM System Console
printer-keyboard mode
(3286 printer required) or display mode
•
IBM system Console for the System/370 Model 158 in printer-keyboard
mode (with the 3213 Printer Model 1 required,) or in display mode
•
IBN 7412 Console (via RPQ
Model 1
•
IBM 3036 Console with the 3031, 3032 or 3033 processor
•
IBM 3278 Model 2A Console with the 4331 or 4341 processor
AA2846)
with 32i5 console
in
~rinter-Keyboard
Note:
During system generation only, the primary system operator's
console cannot be connected to the system via a teleprocessing line.
The following terminals are supported by
consoles (simulated as 3215 consoles) :
VM/370 as
virtual system
•
IBM 2741 Communication Terminal
•
IBM 1050 Data Communication System
•
IBM 3101
Display Terminal,
Models 10,
12,
13,
20,. 22,.
(supported as teletype Model ASR 33/35 teletypewriter)
•
Terminals on switched lines compatible with the line control used by
the IBM Telegraph Control Type II Adapter (8-level ASCII code at 110
bps) such as the CPT-TWX (Model 33/35) terminals
•
IBM 3275 Display Station,. Model 2
at tachment only)
•
IBM 3276 Control unit Display Station Models 2, 3,
and 41
with
integral control unit (supported as a 3277 attached to a
3271 for
remote attachment only)
•
IBM 3277 Display Station, Model
(local attachment only)
2,. via
3272 Control Unit,.
Model 2
•
IBM 3277 Display Station, Model
(remote attachment only)
2,. via
3271 Control Unit,.
Model 2
23
with integral control unit (remote
1Models 3 and 4 operate in Model 2 default mode.
112
and
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Configurations (Terminals)
•
IBM 3278 Display Station ~ode1s 2, 3, and 41 via 3274 Control unit
Model 1B (supported as a 3277 attached to a 3272 for local attachment
only)
•
IBM 3278 Display Station
Model 1C
(supported as
at tachment only)
~ode1s
a
2, 3, and 41 via 3274 Control Unit
3277 attached to a 3271 for remote
Note: 3215 console simulation for graphics devices excludes processing
multiple output channel programs which contain CCW's without carriage
returns (X'01' CCW op code) on one line of the screen. These channel
programs are treated separately and VM/370 uses a new line for each
one.
IModels 3 and 4 operate in Model 2 default mode.
Part 1. Planning for System Generation
112.1
A pr i 1
112.2
1, 1 98 1
IBM VM/370 Planning and System Generation Guide
Configurations (Terminals)
•
IB~ 3278 Display
Station aodels 2, 3, and 41 via 3276 Control Unit
Display Station Models 2, 3, and 4 (supported as a 3277 attached to a
3271 for remote attachment only)
•
IBM 3767
2741)
~odels
Communications Terminal,
1
and 2
(operating as
a
SPECIAL CONSIDERATIONS AND REQUIRED FEATURES
Terminals that are equivalent to those explicitly supported may also
function
satisfactorily.
You
are
responsible for
establishing
equivalency.
IBa assumes no responsibility for the impact that any
changes to the IBM-supplied programs or products may have on such
terminals.
Prior availability of an RPQ does not guarantee or imply current or
future availability.
Contact your IB8 branch office for ordering
information concerning the RPQs mentioned with the following features.
The IBK 2741 Communication Terminal is supported on either duplexed
switched or point-to-point nonswitched lines connected to a western
Electric 103A2
(or equivalent data set).
The following features are
required features:
•
PTTC/EBCD (19571, Part 11161963) or standard
Part 11167043) print elements
•
Transmit Interrupt (17900) or Transmit Interrupt Control RPQ IE40681
•
Receive Interrupt (14708)
•
For switched lines, the Data
feature (13255) are required.
e
For point-to-point nonswitched
is required:
Set
Correspondence (19812,
Attachment (#9114)
lines, one of the
Dial~p
and
following features
--Data Set Attachment (19115 duplexed for facility D1) or
--Data Set Attachment (19116 duplexed for facility B2) or
--Data Set Attachment (19120 duplexed for facility B1 or D1) or
--IB~ Line Adapter (14635 for 4-wire limited distance line)
--IBM Line Adapter (14691-4694 for 4-vire shared nonswitched line)
--IBM Line Adapter (14647 for 4-wire nonswitched line)
The
following features,
although not
convenience and usability of the terminal:
•
Print Inhibit (15501)
•
Red Ribbon Control
only)
•
Typamatic Keys (18341)
•
Pin Feed Platen (19509)
RPQ 1868019
lModels 3 and 4 operate in
~odel
(supported
required,
enhance
for PTTC/EBCD
the
keyboard
2 default mode.
Part 1. Planning for System Generation
113
Configurations (Terminals)
lQ2Q
£Qnt£Q! Uni~§,
Q.~§.igbl~ Feat~§
ftogel§, gng
Feature§:
The IBft 1050 Data Communication System is supported on either switched
or point-to-point nonswitched lines with these features:
•
IB~
1051 Control Unit (Model 1 or 2) with these features:
--Transmit
tE26903
Interrupt
(17900)
or
Transmit
Interrupt
Control
RPQ
--Receive Interrupt (16100) or Receive Interrupt Control RPQ tE27428
--Text Time-Out Suppression (19698)
--First Printer Attachment
(14408). This feature is
attach a 1052 Printer-Keyboard to the 1051.
•
IBM 1052 printer-Keyboard (Model
element (19571, Part 11167963)
•
For switched lines, the Data Set Attachment (19114) is required.
•
For point-to-point
required:
nonswitched
1 or 2)
lines,
with the
required
one
of
the
to
PTTC/EBCD print
following
is
--Data Set Attachment (19115 for facility Dl)
-- or
--Data Set Attachment (19116 for facility B2)
-- or
--Data Set Attachment (19120 for facility Bl or Dl)
or
--IB~
Line Adapter (14691-4694 for 4-wire shared nonswitched line)
or --
--IBM Line Adapter (14647 for 4-vire nonsvitched line)
enhance
the
The following control units can be
locally attached on a
multiplexer, block multiplexer, or selector channel to support
devices:
byte
3270
The
following features,
although not
convenience and usability of the terminal:
•
•
Automatic Ribbon Shift and Line Feed Select (11295)
Automatic EOB on Carrier Return RPQ tE28235
111Q
£QmEQ~~1§,
.R!9.uir~g,
114
required,
~gntrQl
and Desira1;!le
Uni!§,
Featy~
IBM VM/370 Planning and System Generation Guide
Configurations (Terminals)
•
IBM 3272 Control Unit Model 2 for attachment of up to thirty-two 3277
Display stations Model 2, 3284 Printers Model 2, 3286 Printers Kodel
2, 3287 Printer Models 1 and 2, and 3288 Line Printers Model 2. To
support this configuration, the following are required:
--Device Adapter feature
(13250) is required if more than 4 devices
are attached to the 3272. Up to 4 additional devices can be
attached with each device adapter.
--A 3271/3272 Attachment
(18330) is required to attach each 3287
Printer.
•
IBM 3274 Control Unit Kodel lB (supported as a 3272) for attachment
of up to 32 display stations and printers. All of the 32 devices can
be 3278 Display Stations Models 2, 3, and 41 (supported as 3277s),
3287 Printers Models 1 and 2, (supported as 3284s or 3286s), and 3289
Line Printers Models 1 and 2.
(supported as 3288s). A maximum of 16
of the 32 devices can be 3211 Display Stations Model 2, 3284 Printers
Model 2, 3286 Printers Model 2, 3281 Printers Models 1 and 2, and
3288 Line Printers Kodel 2. To support this configuration, the
following are required:
--The basic 3214 Control Unit permits attachment of up to 8 devices
(3278, 3287, and 3289). At least one 3278 is required.
--Each of the Terminal Adapter Types Al, A2, and A3
('6901, 16902,
and 16903) permits the attachment of up to 8 additional devices per
adapter
(types 3218, 3281, and 3289).
Only one of each type
terminal adapter is permitted.
Terminal Adapter Type Al is a
prerequisite to Type A2, and A2 is a prerequisite to Type A3.
--Terminal Adapter Type Bl (#1802) permits the attachment of up to 4
additional devices (types 3277, 3284, 3286, 3287, and 3288). Only
one adapter is permitted.
--Each of Terminal Adapter Types B2, B3, and B4 (t1803, #7804 and
#7805) permits the attachment of 4 additional devices per adapter
(types 3211, 3284, 3286, 3287 and 3288).
Only one of each type
terminal adapter is permitted.
Terminal Adapter Type Bl is a
prerequisite to Type B2, Type B2 is a prerequisite to Type B3, and
Tvpe B3 is a prerequisite to Tvpe B4. Terminal Adapter Tvpes Al
and B3 are mutually-exclusive. -----A 327q/3276 Attachment (18331) is required for each 3287 Printer
Models 1 or 2 that attaches to the basic 3214 Control Unit, or that
attaches to Terminal Adapter Types Al, A2, or A3.
A 3271/3272
Attachment (#8330) is required for each 3287 Printer Model 1 or 2
that attaches to Terminal Adapter Types Bl, B2, B3, or B4.
And only needed if a Type B adapter is used:
--Control storage Expansion feature (11801) provides the
access control unit storage addresses above 64K.
ability to
--Extended Function Storage feature
('3622)
provides additional
storage
required
to
support
particular
attachments
or
configurations.
Control Storage Expansion feature
(11801) is a
prerequisite.
lModels 3 and 4 are supported as Model 2 via hardware default.
Part 1. Planning for System Generation
115
Configurations (Terminals)
The following control units can be remotely attached to leased lines via
a 2701 Data Adapter Unit, a 2703 Transmission Control Unit, a 3704/3705
Communications
Controller in
emulation mode,
or an
Integrated
Communications Adapter (ICA) to support 3270 devices:
•
IBM 3271 Control Unit Model 2 for attachment of up to thirty-two 3277
Display Stations Model 2, 3284 Printers Model 2, 3286 Printers Model
2, 3287 Printers Models 1 and 2, and 3288 Line Printers Model 2. To
support this configuration, the following may be required:
--Device Adapter feature
(13250) is required if more than 4 devices
are attached to the 3271. Up to 4 additional devices can be
attached with each device adapter.
--A 3271/3272 Attachment
(18330) is required to attach each 3287
Printer Model 1 or 2.
--Copy feature (11550) is required to use the VM/370 full-screen copy
function.
--Transmission Speed feature (17820 or 17821) is required.
•
TBM ~274 Control nnit Model 1C (snpported a~ a
l271) fnr atta~hment
of up to
32 display stations and printers.
All of the 32 devices
can be 3278 Display Stations Models 2, 3, and 41 (supported as
327 7 s), 3287 Printers Models 1 and 2, (supported as 3284s or 3286s),
and 3289 Line Printers Models 1 and 2.
(supported as 3288s).
A
maximum of 16 of the 32 devices can be 3277 Display Stations Model 2,
3284 Printers Model 2, 3286 Printers Model 2, 3287 Printers, Models 1
and 2,
and 3288
Line Printers Model
2.
To
support this
configuration, the following are required:
--The basic 3274 Control Unit permits attachment of up to 8 devices
(3278, 3287, and 3289).
At least one 3278 is required.
--Each of Terminal Adapter Types Al, A2, and A3 (16901, 16902, and
16903) permits the attachment of up to 8 additional devices per
adapter
(types 3278, 3287, and 3289).
Only one of each type
terminal adapter is permitted.
Terminal Adapter Type A1 is a
prerequisite to Type A2, and Type A2 is a prerequisite to Type A3.
--Terminal Adapter Type Bl (17802) permits the attachment of up to 4
additional devices (types 3277,3284, 3286, 3287, and 3288). Only
one adapter is permitted.
--Each of Terminal Adapter Types B2, B3, and B4 (17803, 17804, and
17805) permits' the attachment of 4 additional devices per adapter
(types 3277, 3284, 3286, 3287, and 3288). Only 1 of each type of
terminal adapter is permitted.
Terminal Adapter Type B1 is a
prerequisite to Type B2, Type B2 is a prerequisite to Type B3, and
Type B3 is a prerequisite to Type B4. Terminal Adapter Types A and
B are mutually exclusive.
--A 3274/3276 Attachment (18331) is required on the printer for each
3287 Printer Kodel 1 or 2 that attaches to the basic 3274 Control
Unit, or that attaches to Terminal Adapter Types Al, A2, or A3.
A
3271/3272 Attachment
(18330) is required on the printer for each
3287 Printer Model 1 or 2 that attaches to Terminal Adapter Types
Bl, B2, B3, or B4.
--Copy feature
(11550) is required
VM/370 full-screen copy function.
if you
are planning to
IModels 3 and 4 are supported as Model 2 via hardware default.
116
IBM VK/370 Planning and System Generation Guide
use the
Configurations (Terminals)
--Device Adapter feature (#3250)
is required if more than four
devices are attached to the 3271.
Up to four additional devices
can be attached with each Device Adapter.
--Transmission Speed feature
(#7820 or 17821) is required.
--Control Storage Expansion feature (#1801) provides the
access control unit storage addresses above 64K.
ability to
--Extended Function Storage feature
(#3622)
provides additional
storage
required
to
!$1,1pport
particular
attachments
or
configurations.
Control Storage Expansion feature
("801) is a
prerequisite.
--Each 3274 Model lC requires a Common Communications Adapter feature
('6302) and an External Modem Interface ('3701).
•
IBM 3276 Control Unit Display Station Models 2, 3, and 41 (supported
as a 3271) for attachment of up to 7 additional 3278 Display Stations
Models 2, 3, and 41 (supported as 3277s), 3287 Printers Models 1 and
2, (supported as 3284s or 3286s), and 3289 Printers Models 1 and 2
(supported on a 3276). To support this configuration, the following
are required:
--The basic 3276 Control Unit Display Station contains 1 integral
display station, (supported as a 3277), and permits a ttachmen t of
either 1 3278 Display Station Model 2, 3, and 41 (supported as a
3217) or 1 3287 Printer Models 1 and 2.
(supported as a 3284 or
3286).
--Terminal Adapter No.
1
(13255) permits attachment of up to 2
additional devices
(3278s,3287s and 3289s).
Only 1 adapter is
permitted.
--Terminal Adapter No. 2
('3256) permits attachment of up to 2
additional devices
(3278s, 3287s and 3289s).
Only 1 adapter is
permitted. Terminal Adapter No. 1 ('3255) is a prerequisite.
--Terminal Adapter No. 3
(#3257) permits attachment of up to 2
additional devices (3278s, 3287s and 3289s).
Only 1 adapter is
permitted. Terminal Adapter No.2 (t3256) is a prerequisite.
--A 3274/3276 Attachment ('8331) is
Model 1 or 2.
required for each
3287 Printer
--Each 3276 requires one of the Communications features
('6301 or
16302) and either the External Modem Interface (#3701) or the 1200
BPS Integrated Modem feature (15500).
The following control unit is remotely attached to either leased or
switched lines via a 2701 Data Adapter Unit, a 2703 Transmission Control
Unit, a 3704/3705 Communications Controller in emulation mode, or an
Integrated Communication Adapter (ICA) to support 3270 devices:
•
IBM 3275 Display Station MOdel 2 standalone control unit and display
station.
A 3284 Printer Model 3 or 3286 Printer Model 3 can be
attached.
Also, the following may be required:
--For the 3275 to be used on a switched line, Dial feature ('3440) is
required.
--Transmission Speed feature ('7820 or 17821) is required.
lModels 3 and 4 are supported as Model 2 via hardware default.
Part 1. Planning for System Generation
117
Configurations (Terminals)
--To attach a 3284 Printer "odel 3, a Printer Adapter feature (15550)
is required.
--To attach a 3286 Printer
~odel
3, RPQ
~B4317
is required.
The 3275 Display station (remote attachment)
and the
Station ~odel 2 require one of the following features:
--66
--66
--78
--78
Key
Key
Key
Key
IB~
3277 Display
EBCDIC Typewriter Keyboard (14630)
EBCDIC Data Entry Keyboard (14631)
Operator Console-Keyboard (14632)
EBCDIC Typewriter Keyboard (tq633)
The 3276 Control Unit Display Station and the
require one of the following features:
IB~
3278 Display Station
--75 Key EBCDIC Typewriter Keyboard (14621)
--75 Key EBCDIC Data Entry Keyboard (14622)
N('\t~ ~
•
pr pr p-ql1i si tp
is t he EBCDIC Cha racter Set
feature (19082\ on
the 3276 or 3278.
The following features, while not
usability of the terminals:
required, enhance the convenience and
--Keyboard Numeric Lock (14690) - All terminals
--Audible Alarm (11090) - All terminals
--Operator Identification Card Reader (14600) - 3275 and 3277 only
--Security Keylock (16340) - All terminals
--~agnetic Slot Reader (15005) with ~agnetic Reader Control ('4999) 3278 only
--Lowercase Character Display (RPQ 18K0366) - 3275 and 3277 only
]2 7 Q APL
~Q!:i
The following 3270 devices are supported by
•
IB~
•
IB" 3277 Display
keyboards:
3271 eodel 2 or IBe 3272
~odel
V~/370's
3270 APL support:
2 Control Unit
Station, eodel 2, with either of
the following APL
jPL ~~boa!:g
Feature
66-character keyboard --.4631
78-character keyboard
14638
Not~:
The 78-character keyboard includes the 12 Program Function
keys, which are required if you wish to use the local copy function.
•
IB~
3284 Printer, eodel 2, the IB"
3287 printer, "odels 1 and 2.
3286 Printer, "odel 2, or the IBe
The 3270 Data Analysis feature (11066) allows the use of APL with any or
all of the above devices.
!Qi~:
The 3270 Data Analysis feature is field-installable.
Since
lowercase display support is included in the APt hardware feature, the
Lowercase Display RPQ 18K0366 must be removed prior to installing the
APL feature.
118
IB" V"/370 Planning and System Generation Guide
March 3, 1980
Configurations
(Terminals)
The following 3270 devices
(although supported by VM/370)
are not
supported by the 3270 Data Analysis-APL feature and therefore cannot be
used to display, print, or enter APL characters:
•
•
•
•
•
•
•
•
The
The
The
The
The
The
The
The
3284
3275
3288
3286
3274
3276
3278
3289
Printer, Model 3
Displa y Station, Model 2
Printer, Model 2
Printer, Model 3
Control Unit, Models 1B and 1C
Control Unit Display Station, Models 2, 3, and 4
Display Station, Models 2, 2A, 3, and 4
Line Printer, Models 1 and 2
Note: With the 3270 Data Analysis-APL feature installed,
all standard
3270 functions remain operational. The only exception is the backtab
key, which is not supported by VM/370.
VM/370's support of the 3270 text feature allows the user to key in, as
well as display and print, all the special characters.
The 3270 Data Analysis-APL feature (#1066)
following 3270 devices if they are to be used
characters:
•
•
•
•
•
3271
3272
3284
3286
3287
is required on the
with th~ special text
Control Unit, Model 2
Control Unit, Model 2
Printer, Model 2
Printer, Model 2
Printer, Models 1 and 2
The 3277 Display Station Model 2 must be equipped with the text keyboard
(#4639).
For a more detailed description of VM/370's text support, see
the Y~Ll1Q !g~mi~l Usg~~§ ~~igg.
The following 3270 devices, although supported by VM/370 for ether uses,
do nct support the text feature:
•
•
•
•
•
•
•
•
3274
3275
3276
3278
3284
3286
3288
3289
Control Uni t, Models 1B and 1C
Display Sta tion, Model 2
Control Unit Display sta tion, Models 2, 3, and 4
Display Station, Models 2, 2A, 3, and 4
Printer, Model 3
Printer, Model 3
Printer, Model 2
Line Printer, Models 1 a.nd 2
Part 1. Planning for System Generation
119
Page ot
GC;.lU-HW1-1U AS
upaat.ea l'larcn
.3,
l~tsU
Dy
'.rl'U••
bN-,:J-UIIO
Configurations (Terminals)
The IBM 3767 Communication Terminal, ,Models 1 and 2, is supported when
it operates as an IBM 2741 Communication Terminal and is attached to a
3704 or 3705 Communications Controller. It requires the following
features on either switched or nonswitched point-to-point lines:
•
2741 START/STOP
(17113)
•
EBCDIC
•
Duplexed, switched or nonswitched line
(#9404) for connecting
Western Electric 103A2 (or equivalent data set)
•
One of the following:
(19391) or Correspondence (19381) keyboard
--EIA Interface with Clock (#3719)
--1200
bp~
I~tcg=~tcd
at 300 bps
(15505 or
~cac=/Intcrrupt
The
following features,
although not
convenience and usability of the terminal:
•
to a
Alternate Character Set (#1291), plus
the keyboard:
required,
enhance
the
a defined character subset for
--If the primary character set is Correspondence
(19381),
alternate character set can b.e APL (#9383) or EBCDIC (19382).
the
--If the primary character set is EBCDIC
(19391), the alternate
character set can be APL (#9393) or Correspondence (19392).
~ot~:
•
Line control is PTTC/EBCD with this feature.
Acoustic Coupler (#1110) at 300 bps
Transmission Control Units
VM/370 supports the following transmission control units:
•
•
•
•
•
IBK
IBK
IBK
IBM
IBM
2701 Data Adapter Unit
2702 Transmission Control
2703 Transmission Centrol
Integrated Communications Attachment (ICA), (#4640)
3704, 3705-1, and 3705-11 Communications Controllers
2701 REQUIRED FEATURES
I.
I
For line control of CPT-TWX (Kodel 33/35) terminals and the 3101
display terminals, the Telegraph Adapter Type II (#7885) is required.
•
For 2770, 2780, 3270, 3770 (as a 2770; 3776 also as a 3780), and 3780
terminal~, the following are required:
--Synchronous Data Adapter Type II
--EBCDIC code (#9060)
--EBCDIC transparency (#8029)
120
(#7698)
IBK VK/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
Configurations (TCUs)
•
For 1050 and 2741 terminals, the following are required:
--IBK Terminal Adapter Type I, Kodel II ('4640)
--Selective Speed, 134.5 bps ('9581)
--2741 Break Feature RPQ #M53193, and Break Command RPQ '858492
•
The Expanded Capability feature (13815) is required if there are:
--More than two low speed adapters (either
Telegraph Type II), or
--More than
II), or
one high
--One high speed and
same 2701.
•
speed adapter
IBM Type I Model
(Synchronous Data
at least one low speed adapter
II, or
Adapter Type
attached to the
The Expansion Feature (#3855; is required for each line adapter after
the first.
2702 REQUIRED AND OPTIONAL FEATURES
•
For 1050 and 2741 terminals, the following are required:
--Terminal Control Base for IBM Terminal Control ('9696)
--IBM Terminal Control Type I ('4615)
--Selective Speed, 134.5 bps ('-9684)
--Type I Terminal Interrupt ('8200)
--Data Set Line Adapter (#3233) or IBM Line
IBM Terminal Control Type I ('4615)
I.
I
Adapter (#4635), 4-wire
For line control of CPT-T~X (Model 33135) terminals and
display terminals, the following are required:
the 3101
--Terminal Control Base for Telegraph Terminal Control ('9697)
--Telegraph Terminal Control Type II ('7912)
--Pluggable End Characters (return key
tE62920, optional
qenerates an
interrupt) RPQ
--Data Set Line Adapter (#3233)
--Terminal Control Expansion ('7935), required only if both of the
terminal bases (#9697 and #7912) are attached to the same 2702.
•
The 31 Line Expansion <'7955) is supported as needed."
2703 REQUIRED AND OPTIONAL FEATURES
•
For 1050 and 2741 terminals, the following are required:
--Start-Stop Base Type I (#7505) or Type II ('7506)
--IBM Terminal Control Base <'4619)
--IBM Ter minal Control Type I (14696)
--Line Speed Option, 134.5 bps (14878)
--Type I Terminal Interrupt (18200)
--Data Line Set (13205) and/or IBM Line Set 1B (#4687)
Part 1. Planning for System Generation
121
rayc
V.L
\3' ...... £V--
,VUI
IV
Aw
U.t'U~,--,;;;;:u.
L.&U,,,-,,,,,,,,
..I,
I-'V\.I
JJI
.L.a."'.I.i
\,;J1.'l1iil.J
VI
rv
Configurations (TCUs)
I.
I
For line control of CPT-TWX
(Model 33/35)
terminals, the following are required:
--Telegraph Terminal Control Base
terminals and 3101 display
(1790~
--Telegraph Ter minal Central Type II (#7912)
--Line Speed Optien, 110 bps (14877)
--Data Line Set
(#3205), and Data Line Set Expander (13206)
--Pluggable End Characters (return key
#E66707, optional
•
generates an
interrupt) RPQ
For 2770, 2780, and 3780 Terminals, the following are required:
--Synchronous Base (#7703, 7704, or 7706)
--Synchronous Terminal Control for EBCDIC (#7715)
--Transparency (#9100)
--Synchronous Line Set (#7710)
•
The Base Expansion feature (#1440) is required if more than one base
type is to be attached to the same 2703.
IBM INTEGRATED COMMUNICATIONS
FEATURES
ATTACHMENT (ICA)
REQUIRED AND
The ICA
(#4640) is available on the System/370 Models 135,
138.
Additio nal lines (#4722-4728) are supported.
•
For 1050,
required:
2741, and 3767
(as a
--Terminal Adapter Type I Model II
2741) terminals, the
OPTIONAL
135-3, and
following are
(# 97 21- 9728)
--Switched Network Facility (#9625-9632), optional
--Write Interrupt (#9745-9752)
--Read Interrupt (#9737-9744)
--Unit Exception Suppression (19729-9730), optional
--For the 3767 only,
(#9593-9600)
•
as a
2741, 200
bps (12711-2718)
or 300
bps
For 2770, 2780, 3270, 3770 (as a 2770; 3776 also as a 3780), and 3780
terminals, the following are required:
--Synchronous Data Adapter Type II (19649-9656)
--Half-Duplex Facility (#9617-9624)
--EBCDIC Transparency (#9673-9680)
t.
I
For line centrol of CPT-TWX
(Model 33/35) terminals and 3101 display
terminals, the following are required:
--Telegraph Adal:'ter Type II (19785-9792)
--switched Network Facility (#9625-9632)
122
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
Configurations (TCUs)
3704/3705 REQUIRED FEATURES
The IB~ 3704 and 3705 Communications Controllers are supported in
Netwcrk Control Program mode, Partitioned Emulation Program mode, and
2701, 2702, 2703 Emulation Program mode.
No!~: VK/370 supports the CPT-TWX (Kodel 33/35) terminals at 110 bps and
the 3101 display terminals at 110, 150, 300, and 600 bps, when attached
to a 3704 or 3705.
VK/370 supports all models of the 3704 and 3705 Communications
Controllers.
However,
because the
network control
program and
partitioned emulaticn program require 48K of storage, the following
models are suppcrted for the emulation program only.
•
•
•
IBM 3704 Communications Controller Models Al and A2
IBM 3705-1 Communications Controller Models Al, Bl, Cl, and Dl
IBM 3705-11 Communications Controllers, Models El, Fl, Gl, and Hl.
The features required on a communications controller do not depend on
VM/370.
VM/370,
when supporting network control mode,
requires a
communications controller with at least 48K of storage. Other 3704/3705
features depend upon the intended use of the communications controller
and the type of 3704/3705 control program
(emulation, network control,
or partitioned emulation program) to be executed.
VM/370 does not support the following 3704/3705 features:
•
•
•
Line Set Type 2A
Line Set Type 3A
Line Set Type 4B
(#4721)
(#4731)
(#4742)
Remote Spooling Devices Supported by VM/370
Remote spooling is
supported
Communications Subsystem (RSCS).
REMOTE SPOOLING
CO~~UNICATIONS
in
VM/370
the
Remote
Spooling
SUBSYSTEM (RSCS)
The VM/370 Remote Spooling Communications
following:
•
•
•
•
•
by
Subsystem (RSCS)
supports the
IBM 2770 Data Communication System
IBM 2780 Data Transmission Terminal, Models 1 and 2
IBM 3770 Data Communication System (as a 2770)
IBM 3780 Data Communication Terminal
HASP supported programmable workstations
The IBM 2770 Data Communication System with the 2772 Multipurpose
Control Unit can be connected to the central System/370 via a switched
or nonswitched point-to-point communication line.
Part 1. Planning for system Generation
123
March 3, 1980
Configurations (Remote Spooling)
The following devices and features are
as an RSCS nonprogrammable terminal:
•
One IBM 2213
1053 Printer
Printer, Model 2, or
•
One IBM 2502 Card Reader, Model A1 or A2
•
EBCDIC Transmission Code (#9761)
required for operating a 2770
one IBM 2203 Printer,
or one IBM
Other supported equipment and features are:
•
•
•
•
•
One IBM 545 Card Punch, Model 3 or 4, with or without 3590 attachment
EECDIC Transparency (#3650)
Additional Buffer Expansion (#1491)
Space Compression/Expansion (#6555)
Synchronous Cloc k (#7705)
The IBM 2780 Data Transmission Terminal,
Models
and 2, can be
connected to the central System/370 via a switched or nonswitched
point-to-point line. EBCDIC Transmission code (#9762) is required.
The following features are optional:
•
•
•
•
EECDIC Transparency (#8030)
120/144 Cha racter Print Line (#5820 or #5821)
Multiple Record Transmission (#5010)
Synchronous Clock (#7705)
The IBM 3770 Data Communication System can be connected to the central
System/370 via a switched or nonswitched point-to-point communications
line. Required features are:
•
•
EECDIC Transmission Code (#9761)
SDLC/BSC Switch Control (#1460), or BSC point-to-point (#1461)
The IBM 3780 Data Communications Terminal can be connected to the
central System/370
via a switched or
nonswitched point-to-point
communications line. EBCDIC transmission code (#9761) is required.
The following devices and features are optional:
•
•
•
•
•
124
One IBM 3781 Card Punch
Component Selection (#1601, required for the 3781)
EECDIC Transparency (#3601)
Additional Print Positions (#5701)
Synchronous Clock (#7705)
IBM VM/370 Planning and System Generation Guide
Configurations (Remote Spooling)
RSCS Spool
!!ULTI-L EAVING1
(S!!L)
supports, as
a V!!/370
remote
workstation, any processor that is supported as a HASP workstation and
is programmed to operate as a HASP workstation.
•
The IBM 1130 Computing System (except
if it has at least 8K words of
Communications Adapter ('7690).
•
Any System/360 or System/370 is supported if it has at least 8K bytes
of main storage and a 2701, 2703 or 3704/3705 in EP mode, equipped
for EBCDIC transmission and binary synchronous communications.
•
Any submodel of the System/360 !!odel 20 or the IB!! 2922 is supported
if it has at least 8K bytes of main storage and the following
features:
Models 4A and 4B) is supported
storage and the Synchronous
--Binary Synchronous Communications Adapter (12074)
--EBCDIC Transmission code (#9060)
--Full Transparency (14100)
•
IBM System/3 !!odels 6,
following features:
8, 10,
12, and
15 are
supported with
the
--Binary Synchronous Communications Adapter (#2074)
--EBCDIC Transmission code (#9060)
--Text transparency (#7850)
•
IB!! System/32 is supported with the following features:
--5320 System Unit (any model A12 through B33)
--Binary Synchronous Communications Adapter (12074)
--System Control Program (5725-SC1)
lTrademark of IB!!
Part 1. Planning for System Generation
125
Configurations (other)
Other Considerations for Planning Your
Configuration
TWO-CHANNEL SWITCH
If any I/O devices controlled by VM/370 for its exclusive use are
attached to control units with two-channel switches, the processor or
virtual machine controlling the other channel interface must vary the
CP-owned devices offline.
See the "VM/370 Using Channel Sw itching" section ea rlier in
for more information about using the two-channel switch.
Part 1
DEVICES USED ONLY BY AN OPERATING SYSTEM IN A VIRTUAL MACHINE AND NOT BY
VM/3 7 0
Any input/output device that can be attached to the IBM System/370 can
be used by a virtual machine under VM/370 as long as there are:
•
No timing dependencies in the device or the program.
•
No dynamically modified channel programs except OS Indexed Sequential
Access Method (ISAM) or OS/VS Telecommunications Access Method (TCAM)
Level 5.
•
None of the other restrictions
Restrictions" are violated.
outlined
in "Appendix
F:
VM/370
Dynamically modified channel programs
(except those that have
input/output involving page zero) are permitted if run in a virtual=real
machine.
Input/output devices
that are
part of
a virtual
configuration require real device equivalents, except for:
machine's
•
Unit record devices, which CP can simulate using spooling techniques.
•
Virtual 2311 Disk Storage Drives, which CP can map onto 2314 or 2319
disks. Up to two full 2311 units can be mapped onto a 2314 or 2319
disk in this manner.
Service Record File
On 3031, 3032, and 3033 processors, each console station of the 3036
system console has a 7443 diskette attached to it, accessible when the
console station is in SRF mode.
In the normal console configuration,
one of the processor's console stations is used as an operator's
console, and the other console station is used as a service console. It
is through the service console that SRF capability is provided. With
the console in degraded configuration (i.e. one console station serves
as both operator and service console), there is no SRF capability.
Thus, it is recommended that the SRF address specified on the RIOGEN
macro instruction at system generation be the address of the service
record file attached to the service console.
126
IBM VM/370 Planning and System Generation Guide
Configurations (Other)
MULTIPLE SERVICE RECORD FILES
In a 3033 attached processor system, there are two 3036 consoles. This
configuration has four service record file devices (one console per
station) .
3033 attached processor environments support multiple service record
file devices.
For VM/370 systems operating on a 3033 AP,
you should
specify multiple SRF devices at system generation. Code DEVTYPE=7443 in
the RDEVICE macro statement and CUTYPE=7443 in the RCTLUNIT macro
statement to generate support for the SRF devices; also code the
ADDRESS=cuu operand in both macro statements. Identify the SRF device
addresses in the RIOGEN macro statement as SRF=(cuu,cuu, ••• ). The SRF
addresses you specify in the RIOGEN macro statement should be the same
as the addresses of the SRF devices attached to the service support
consoles.
In
3033
multiprocessing
environments
with
liD
configured
asymmetrically to one processor, in order to access the SRF devices in
both 3036 consoles, a channel path must be available from the 110
processor to both SRF devices.
If an SRF device specified on the RIOGEN macro statement is found to
be inaccessible during initialization of the error recording cylinders,
an error message is sent to the system operator;
processing continues
without the frames from that SRF device in place on the error recording
cylinders.
The RIOGEN macro statement produces an MNOTE warning
specify more than 32 SRF devices.
message if you
Part 1. Planning for System Generation
127
128
IBM VM/370 Planning and System Generation Guide
Part 2. Defining Your VM/370 System
Part 2 describes the macros and control statements you need
your VM/370 system. It contains the following sections:
•
Introduction
•
Preparing the Real I/O Configuration File (DMKRIO)
•
Preparing the CP System Control File (DMKSYS)
•
Creating Your VM/370 Directory
•
Preparing the System Name Table File (DMKSNT)
•
Altering the Forms Control Buffer Load (D!KFCB)
to define
Part 2. Defining Your VM/370 System
129
130
IB" V"/370 Planning and System Generation Guide
Introduction
Before starting the system generation procedures on a real machine, you
must create three files that describe the V~/370 system you are
generating. There are two additional files, which are optional. You can
use card input, or create these files using the C~S Editor. If you are
modifying an existing V!/370 system, you can use the C~S Editor to alter
the existing files.
The three files that you must prepare are:
•
The real I/O configuration file (module name DKKRIO), which defines
the I/O configuration on the real System/370 machine.
•
The CP system control file
(module name DKKSYS),
CP-controlled DASD volumes, allocation, and so on.
•
The VK/370 directory file (normally a C~S file named USER DIRECT),
which contains the VK/370 directory entries that define the virtual
machine configuration for each userG
which
defines
In addition, you should prepare the system name table (DKKSNT) file
if you plan to save systems.
If you generate the 3704/3705 control
program, you must save it; otherwise, the 3704/3705 control program
cannot be loaded by VK/370. "Part 1. Planning for System Generation" has
a section that describes the requirements for saving systems.
You
D~KFCB)
can also
change
the forms
control
buffer
load (module
name
•
The notational conVentions that describe the macro syntax for VK/370
system generation are listed in "Appendix D: Notational Conventions."
These notational conventions are the same as the conventions used to
describe VK/370 commands.
Part 2. Defining Your VK/370 System
131
132
IBM VM/370 Planning and System Generation Guide
Preparing the Real I/O Configuration File
(DMKRIO)
The real I/O configuration file consists of macros that describe the I/O
devices, control units, and channels attached to the real System/310.
V~/370 uses this information to schedule
I/O operations and to allocate
resources. Therefore, the real I/O macro entries must represent the
real hardware configuration accurat.ely. Generally, there must be one
real I/O macro entry for each hardware unit in your configuration.
You can include entries for more devices than your installation has
so that devices can be added in the future without performing another
system generation, but bear in mind that the control blocks generated
(RDEVBLOK, RCUBLOK i and RCHBLOK) occupy space in real storage.
When preparing the RDEVICE and RCTLUNIT entries, refer to "Appendix
B: Con figuration Aid" to assist you in configuring control units and
devices. Following the descriptions of the CLUSTER, TERMINAL, RDEVICE,
RCTLUNIT, RCHANNEL, and RIOGEN macros, there is an example showing how
these macros are coded for one particular real configuration.
The macros, in their proper sequence, are:
ll~~~~T~~~
Qni t.§~~!~ed TQ
Remote Display Stations
RDEVICE
RCTLUNIT
RCHANNEL
RIOGEN
I/O Devices
Control Units
Channels
System Console
l
TER:INAL~
The file is placed in the reader as follows:
D~KRIO
CSECT
CLUSTER macro 1
TERMINAL macro 1
RDEVICE macros
RCTLUNIT macros
RCHANNEL macros
RIOGEN macro
END
IThere must be a CLUSTER macro for each 3270 control unit for remote
3270s. Each CLUSTER macro must be followed immediately by the TERMINAL
macros representing each display station and printer on that control
unit. The CLUSTER and TERMINAL macro groups must precede all the other
real I/O configuration macros. See the special requirements for the
TERMINAL macros for devices attached to the 3214 Model 1C in the
section on "Coding the Real I/O Configuration Macros for Remote 3270s."
Part 2. Defining Your VM/310 System
133
Real I/O Configuration File
All the groups of CLUSTER and TERMINAL macros must appear first,
followed by all RDEVICE macros, all RCTLUNIT macros, all RCHANNEL
macros, and finally by the RIOGEN macro. In addition,
the first
statement in the file must be the DMKRIO CSECT statement (as shown) and
the last statement must be the assembler END statement.
Coding the Real I/O Configuration Macros for
Remote 32705
Two types of remote 3210 configurations are supported:
a cluster
control unit 3211 with multiple terminals and printers attached and
standalone display stations.
The clustered configurations attach to
either a 3211, 3274 Model 1C, or 3276 control unit, all of which are
coded as a 3271. The standalone station is a 3215 display station which
contains its own built-in control unit.
All remote configurations are
attached via binary synchronous communication lines.
To define remote 3270 stations you must code CLUSTER~ TER"INAL~ and
RDEVICE macros. Code one RDEVICE macro for each binary synchronous line
that supports a remote 3270 configuration.
Code one CLUSTER macro to
define the 3210 control unit for each of those lines and code one or
more TERMINAL macros, as needed, to define the devices in the remote
3270 configuration.
The CLUSTER macro defines the control unit (3271, 3274 Model 1C,
3275, or 3276) for the remote 3270 configuration. Each CLUSTER macro
must have a unique label. This label is coded on the RDEVICE macro that
defines the corresponding binary synchronous line and thus logically
links the line and the cluster. The address of the line (defined by the
ADDRESS=cuu operand of the RDEVICE macro)
is coded in the LINE=cuu
operand of the CLUSTER macro.
Follow each CLUSTER macro with the TERMINAL macros that define the
terminals for the remote 3270 control unit.
For the 3271 and 3276
directly following the CLUSTER macro, code a TERMINAL macro for each
terminal address to which a terminal can be attached (regardless of
whether or not the intermediate addresses are unused). For example, if
terminals are attached to the third, fourth, and eighth addresses, you
code eight TERMINAL macros.
The first macro represents the first
(lowest) address, the last represents the eighth (highest) address.
For the 3214 Model 1C that has only 3278s (attached via Terminal
Adapter Types A1, A2, or A3), 3287s, or 3289s attached, follow the same
procedure as for the 3271 and 3276 in coding the TERMINAL macros. If
the 3274 Model 1C has 3271s, 3284s, 3286s, 3287s (attached via Terminal
Adapter Types Bl, B2, B3, or B4), or 3288s attached, directly following
the CLUSTER macro, first code TERMINAL macros for all 3218s, 3287s
(attached via Terminal Adapter Types A1, A2, or A3), and 3289s. These
devices must occupy the first 8, low-order addresses, and each following
block of 8 addresses until all of these devices are attached.
As
before, a TERMINAL macro must be coded for all unused addresses in each
block of 8 addresses that are required.
Immediately following the last
TERMINAL macro in the block of 8, 16, or 24, code a TERMINAL macro for
each 3277, 3284, 3286, 3281s (attached via Terminal Adapter Types B1,
B2, B3, or B4), and 3288 that can be attached.
These devices will
occupy the higher-order addresses on the controller.
Again, a TERMINAL
macro must be coded for each unused address to which a terminal can be
attached up to the last address occupied.
For the 3215, directly following the CLUSTER macro, code a single
TERMINAL macro specifying TERM=3275. If the 3275 has a 3284 or 3286
Model 3 Printer attached, specify MODEL=3 to define the printer;
otherwise, the printer is ignored.
134
IBM VM/370 Planning and System Generation Guide
Real 1/0 Configuration File
After all the CLUSTER-TERMINAL groups of macros have been coded, code
You must code an RDEVICE macro
the other real I/O configuration macros.
for each binary synchronous line that supports remote 3210 stations.
Specify the label of the corresponding CLUSTER macro on the RDEVICE
macro (CLUSTER=label).
CLUSTER Macro
Use the CLUSTER macro to define a control unit associated with a remote
3270. Each CLUSTER macro represents a display control unit
(a 3211,
3274 Model lC, or 3216, all specified as a 3211) on a leased BSC line,
or a standalone 3215 on either a switched or leased BSC line.
One
CLUSTER macro must be specified for each 3271, 3214 Model lC, 3215, and
3276.
Note: Each CLUSTER macro must immediately precede the TERMINAL macros
defining the devices attached at each remote 3210 station. The groups
of CLUSTER and TERMINAL macros must precede all other macros in the
DMKRIO file.
The format of the CLUSTER macro is:
r
,
,II
,
IName
Operation
'label' CLUSTER
,
,
I
,
I
I
Operands
CUTYPE={3 271}
3215
, GPOLL=cudv
, LINE=cuu
, DIAL= {!~S}
'---
wh~1:~:
label
The label
is a name of the CLUSTER macro; it must be specified.
may be any valid assembler language symbol. The label establishes
a unique symbolic name for this cluster control unit or standalone
station.
CUTYPE={3271}
3215
is the control unit of the station; it is either 3211 or 3215.
Noi~:
Code a 3214 or 3276 as a 3271.
GPOLL=cudv
are the general polling characters that represent the general
polling technique to be used for this station.
When general
polling is used, the first device that the control unit determines
is ready to send data over the line is allowed to do so. The
characters, cudv, are the Q-digit hexadecimal general polling
characters assigned to the control unit of the station.
The
hexadecimal equivalent of the EBCDIC transmission code is in the
form cudv, where:
cu
dv
are the polling characters for the control unit
are the characters for any available input device
Part 2. Defining Your VM/310 System
135
CLUSTER "acro
The general polling characters for the remote 3270 device Cdv) are
always X'7F'
and the general polling characters for the control
unit are defined when the control unit is physically installed.
Use Figure 17 to determine what you should code as the general
polling characters for the control unit.
GPOLL is ignored if
CUTYPE=3275 and DIAL=YES are specified.
~Qi~:
The 3274 and 3276 terminals have control unit address
switches which are set by the user to match the polling and
selection address characters shown in Figure 17.
LINE=cuu
is the line interface address. It is the address specified on the
RDEVICE macro that is associated with this CLUSTER macro.
DIAL={~~S}
specifies whether the 3275 has the Dial feature.
specified if CUTYPE=3271.
DIAL=NO must be
~~g~1~2
The following CLUSTER macro describes a 3271, 3274, or 3276 control unit
with a control unit address of 2 and a line address of 078.
CLUST001 CLUSTER CUTYPE=3271,GPOLL=C27F,LINE=078,DIAL=NO
The following CLUSTER macro describes a 3275 display station (without
the Dial feature)
that has a control unit address of 0 and a line
address of 080.
CLUST020 CLUSTER CUTYPE=3275,GPOLL=407F,LINE=080,DIAL=NO
In the real 1/0 configuration file (DKKRIO), the CLUSTER macro must
immediately precede the TERKINAL macros that define the stations
attached to that cluster or standalone station.
136
IBK VK/370 Planning and System Generation Guide
TERMIN AL l!acro
TERMINAL Macro
Use the TERMINAL macro to define (1) a display station or printer that
is attached to the remote 3270 display system or (2) a terminal address
that is available to attach an additional remote 3270.
Each terminal
address attached to a cluster must be represented by a TERMINAL macro.
Only one TERMINAL macro is specified for a standalone 3275 display
station.
Code one TERMINAL macro for each display device and each printer
attached to a cluster control unit (3271 or 3276) •
You must code a
TERMINAL macro for every terminal address to which a terminal can be
attached, even if a terminal address is unused.
When you code a
specify a valid TERl!=
TERMINAL macro for an unused terminal address,
operand and the correct selection or addressing characters.
For a 3274 Model lC Control Unit that has 3277s, 3284s, 3286s, 3287s
(attached via Terminal Adapter Types Bl, B2, B3,
or B4), or 3288s
attached, first you must code a TERMINAL macro for all 3278s, 3287s, and
3289s in groups of 8 until all 3278s, 3287s, and 3289s have been
included. You must code a TERMINAL macro for every terminal address in
each group of 8. Then, following these macros, you must code a TERMINAL
macro for each 3277, 3284, 3286, 3287, or 3288.
Again, you must code a
TERMINAL macro for every terminal address to which a terminal can be
attached.
Code only one TERMINAL macro to define the display station,
and
optionally a printer, attached to a standalone station
(3275). Code
TERM=3275 to define the 3275 display station and, optionally, code
MODEL=3 to define a 3284 or 3286 printer attached to the 3275.
!Q1~:
All the TERMINAL macros defining the devices attached to a remote
3270 station must follow the CLUSTER macro that defines the control unit
for that station.
The groups of CLUSTER and TER~INAL macros must
precede all other macros in the Dl!KRIO file.
The format of the TERMINAL macro is:
r
I Name
I
I
I
I
I
I
I
1
I
I
I
Operation
TERMINAL
!
Operands
75
I
3277
I
3284
I
3286
I
3288
I
I
I , SEL ECT=cudv
I
I r
" MODEL=ll
I , , MODEL=3,
TERM=r
,
,,
,
,
I
I
I
I [ , FEATURE=OPRDR]
L
.J
L
Part 2. Defining Your Vl!/370 System
137
TERMINAL PIacro
TERM=I~~;~!
3284
3286
3288
is the device type of
clustered or standalone
are allowed:
the remote 3270 station attached to the
3270 control unit. The following devices
Device
IBM~75 Display Station
IBM
IBM
IBM
IBM
IBM
IBM
IBM
IBM
3276
3277
3278
3284
3286
3287
3288
3289
Display Station
Display Station
Display Station
Printer
Printer
Printer
Line Printer
Printer
TERM=
3275
3277
3277
3277
3284
3286
3284 or 3286
3288
3288
SEL ECT=cudv
are the 4-digit hexadecimal selection
assigned to this device r where:
cu
dv
or addressing
characters
are the characters for the control unit
are the characters for the device
Use Figure 17 to determine the selection and addressing characters
for this device. The SELECT operand is ignored if DI1L=YES is
specified for the 3275 in the CLUSTER macro.
Not~:
If a printer is attached to the 3275 r it has the same address
as the 3275 display station.
r
,
11tQJLEL=2 ,
I MODEL=3,
L
.J
is the model number of the printer; the default is model 2.
The following printers can be attached
cluster control unit:
•
•
•
IBM
IBM
IBM
IBM
IBM
3284
3286
3287
3288
3289
Printer
Printer
printer
Printer
Printer
The following
unit:
•
13A
and 3276
to a remote 3274
PIodel 1C
IBM 3284 Printer r Model 2
IBM 3286 Printer, Model 2
IBM 3288 Printer r Model 2
The following printers can be attached
cluster control unit:
•
•
•
•
•
to a 3271, 3274,
Model 2
Model 2
Models 1 and 2
Model 2
Models 1 and 2
printers can be attached
to a 3276
IBM 3287 Printer Models 1 and 2
IBM VM/370 Planning and System Generation Guide
cluster control
TERl!IN1L !acro
The following
station:
•
•
printers
can
be attached
to
a
standalone
3275
IBM 3284 printer, l!odel 3
IBM 3286 Printer, l!odel 3 (via RPQ l!B4317)
FEATURE=OPRDR
specifies the optional feature,
operator identification card
reader, that is available on the 3277 Display Station, l!odel 2, or
the magnetic slot reader on a 3278 Display Station, l!odels 2, 3,
and 4.
1: This TERMINAL macro describes a 3277 with a selection address
of 2, and a control unit address of 2.
~~mple
TER!INAL TERl!=3277,SELECT=E2C2,FEATURE=OPRDR
1: This TERftINAL macro describes a 3286 with a selection address
of 3 and a control unit address of 3.
~~mpl~
TERl!INAL TERl!=3286,SELECT=E3C3
J: This TERl!INAL macro describes a 3284 with a selection address
of 4 and a control unit address of 4.
~xampl~
TER!INAL TERl!=3284,SELECT=E4C4,MODEL=2
!: This TERMINAL macro describes a 3275 Display Station with a
3284 Printer, Model 3, attached and a control unit address of O.
~xampl~
TER!INAL TERM=3275,SELECT=6040,!ODEL=3
If no printer is attached to the 3275, code:
TER!INAL TERM=3275,SELECT=6040
Part 2. Defining Your V!/370 System
139
TER"INAL "acro
,
r
I
I
I
,
Use this column for:
• Device selection
• Specific poll
• General poll
• Fixed return addresses
I
I If the Control
I Unit or Device
I Number is:
I
1
0
1
2
3
4
5
6
..,
8
9
10
11
12
13
14
15
16
17
18
1q
20
21
22
23
24
25
26
27
28
29
30
31
Figure 17.
140
The EBCDIC
Code (in
hex adecimal)
is:
40
C1
C2
C3
C4
C5
C6
r:.7
C8
C9
4A
4B
4C
4D
4E
4F
50
D1
D2
D3
D4
D5
D6
D7
D8
D9
5A
5B
5C
5D
5E
5F
, Use this column for:
,•
,
I
3270 control unit selection
addresses
I
If the Control , The EBCDIC
Unit Number is: I Code (in
I hexadecimal)
I is:
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
60
61
E2
E3
E4
E5
E6
E1
E8
E9
6A
6B
6C
6D
6E
6F
FO
F1
F2
F3
F4
F5
F6
F1
F8
F9
1A
1B
1C
1D
1E
7F
Remote 3270 Control Unit and Device Addressing
IB" V"/370 Planning and System Generation Guide
TERKINAL P.lacro
Figure 18 shows some examples of valid
information on polling sequences, see
~Y§tem £ompon~nt Des£!iEtion.
polling characters.
For more
111Q Info!!ati2n Displa,I
1~~
r
I 3271, 3274, and 3276 Addressing
3275 Addressing
,-----------------------------------------------------------------------,General Poll 1Control
,General Poll I Control ,EBCDIC
I EBCDIC
Ifor Control
I Unit 5
I
I
IUnit
I Address
I
.
I
I
,
------Ifor Control
C5
IUnit 5
C5
I
,
1------------------, Device
7F
I
I
I Address
7F
1Control
IUnit
1 Address
1
C5
C5
,Specific
lPoll Device
,4 on Control
,Unit 5
I
I
,
C5
C5
1-------------------------------7F
7F
ISpecific
IPoIl
I for Control
IUnit 5
IControl
IUnit
1Address
1
I
IDevice
I Address
C5
C5
ISelect
IControl
I Unit 5
I Control
E5
E5
I
I
I
I Device
,,
C4,
C4
I
,Select
,Device 4
Ion Control
I Unit 5
lControl
IUnit
, Address
E5
E5
I
I
I
1----------------------------1
C4
C4
1
I
1Device
I Address
1----------------------------1
I Device
I Address
,
I
I
I
,Device
I Address
,
IUnit
I Address
I
I
IUnit
I Address
IAddress
40
40
40
40
L
Figure 18.
Examples of Remote 3270 Addressing
Part 2. Defining Your VP.I/310 System
141
RDEVICE Macro
RDEVICE Macro
Use the RDEVICE macro instruction to generate a real device block
(RDEVBLOK). You must code an RDEVICE macro for each real I/O device in
your I/O configuration. The maximum number of real devices that can be
in~luded on the real VM/370 system is 3276.
The RDEVICE macro instructions describe each device,
or group of
devices, attached to the System/370.
These can be in any order, but
they must be contiguous, and must precede all RCTLUNIT and RCHANNEL
macros in the real I/O configuration file (DMKRIO).
Also, the RDEVICE
macro instructions must follow all the groups of CLUSTER and TERMINAL
macros, if there are any. The first RDEVICE macro generates the label
DMKRIODV, which indicates the start of the real device blocks to CP.
The name field
may not be specified for
the RDEVICE macro
instruction; if ~ na~~ is ~p~~ifi~d it is ignnrp~- Thp RnRVT~R m~~rn
generates a name by appending the device address to the characters RDV.
For example, the name RDV234 is generated for the device address 234.
Before you code an RDEVICE macro for a 3704 or 3705 device, see the
a VM/370 System that Supports the 3704/3705~ section of Part
1 for additional information and special considerations.
~Generating
Also, see the "Planning Considerations for Remote 3270s" section of
Part 1 before you code an RDEVICE macro for a binary synchronous line
that is used by remote 3270s.
Before you code an RDEVICE macro for a 3800 printer device, see the
"Generating a VM/370 System that Supports the 3800 Printer" section of
Part 1 for additional information and special considerations.
142
IBM VM/370 Planning and System Generation Guide
April 1, 1981
R DEVICE Macro
The format of the RDEVICE macro is:
r------------------------------------------------------------------------~
Name
Operation
RDEVICE
Operands
ADDRESS={CUU
},DEVTYPE=type[,MODEL=model]
(cuu ,nn)
[ , FEATURE= (feature[ , feature] ••• ) ]
,
r
I,CLASS=
I
I
I
,
I
I
(cl[,cl] ••• )
DASD
TAPE
TERM
GRAF
URI
URO
L
,
r
I
I
I
I, ADAPTER=
I
I
I
I
BSCA
IBM1
SDLC
TELE2
TYPE1
TYPE2
TYPE3
TYPE4
L
I
I
f
I
f
I
I
.J
I
I
I
I
I
I
I
I
r
.J
L
,
f ,CPTYPE={EP } I
L
.J
r
,
I , ALTCU=cu u
I
..J
[ ,SETADDR=sadnum]
[ ,CPNAME=cpname]
[ , BASEADD=cuu ]
[ ,CLUSTER=label]
[,IMAGE=imagelib]
[ , CHARS=ffff]
[ , FCB=lpi ]
[ , DPMS IZE=n ]
whgre:
ADDRESS=Jcuu
l
1 (cuu,nn)f
is the real IIO device address (or addresses).
The address, cuu, is 3 hexadecimal digits from 000 to FFF.
The
high-order digit is the address of the channel to which the device
is attached.
The low-order two digits represent the control unit
and device address.
The value, nn, is the number of RDEVBLOK entries to be generated;
it may
be any number from
001 to 256.
For
example, if
ADDRESS=(100,5} is specified, RDEVBLOKs with device address 100,
101, 102, 103, and 104 are generated.
If nn is omitted, a value of
1 is assumed for all devices except the 2305, which has a default
value of 8. For a 2305, the last characters of cuu should be 0 or
8; the maximum value of nn is 16.
If DEVTYPE=3066, 3138, 3148, or 3158, or if DEVTYPE=3278 and
Model=2A, nn can only be 1 because only one system display console
can be specified for each RDEVICE macro.
DEVTYPE=type
is the type of device.
Part 2. Defining Your VM/370 System
143
RDEVICE Macro
The device type can be ICA, CTCA,
1017, 1018, 1052,
1442P, 1442R, 1443, 2150, 2250, 2260, 2265, 2301, 2303,
2314, 2319, 2321, 2401, 2402, 2403, 2404, 2415,
2420,
2520P, 2520R, 2540P, 2540R, 2671, 2701, 2702, 2703,
3066, 3138, 3148, 3158, 3203, 3210, 3211, 3215, 3277,
3287, 3288, 3330, 3333, 3340, 3350, 3410, 3411,
3420,
3704, 3705, 3800, 3851, or 7443.
1053,
2305,
2495,
2955,
3284,
3505,
1403,
2311,
2501,
3036,
3286,
3525,
Coding Considerations
For TWX terminals and 3101 display terminals, specify 270x as the
device type and ADAPTER=TELE2.
Remote terminals such as a 2741 or
a 3767 must be coded as a 2701, 2703, 3704, or 3705.
For a 3350
device in native mode, specify 3350 as the device type. For a 3350
being used in 3330 compatibility mode, specify 3330.
Specify a
3344 disk as a 3340, and a 3333 as a 3330. An MSS 3330V device
address must be defined as DEVTYPE=3330 with one of the two
FEATURE= operands allowed. Befer to the explanation of the FEATURE
operand.
For local 3270 terminals attached via
speGify th€ following .l.VL.
.t:. _ _
J2evic~ ~
3277
3284
3286
3287
3288
DEVTYPE=
3277
3284
3286
3284 or 3286
3288
For local 3270 terminals attached via
specify the following for DEVTYPE=:
]evic~ n~
3277
3278
3284
3286
3287
3288
3289
a 3272 Control unit Model 2,
a 3274 Control Unit Model 1B
DEVTYPE=
-32773277
3284
3286
3284 or 3286
3288
3288
For a local 3270 attached through
3287 as a 3284 or 3286.
a 4341 support processor, code a
For the following devices, which have no device type, specify:
• ICA for Integrated Communications Adapter
• CTCA for Channel-to-Channel Adapter
The system console must be specified in both the RDEVICE and
RCTLUNIT macros.
Specify the system console in both macros as
follows:
~Y§temL370
Model
1 35 , 13 5- 3 , 1 4 5 ,
145-3, 155 II
138
144
3210 or 3215
3138 (if in display mode)
3215 (if in printer-keyboard mode)
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNt GN25-0837
RDEVICE Macro
.§Y§.tem/370 Model
148
158
165 II, 168
3031, 3032, 3033
4331, 4341
.§ystem C01l.§Ql§
3148 (if in display mode)
3215 (if in printer-keyboard mode)
3158 (if in display mode)
3215 (if in printer-keyboard mode
and has the 3213 Printer Model 1)
3066
3036
3278 Model 2A (if in display mode)
3215 (if in printer-keyboard mode)
Part 2. Defining Your VM/370 System
144.1
144.2
IBM VM/370 Planninq and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
RDEVICE Macro
The device types, 2540R and 2540P, refer to the same IBM 2540 Card
Read Punch
(as do 1442P and 1442R, and 2520P and 2520R). Each
logical device must be specified in a separate RDEVICE macro.
In addition, any other device that can be attached to a real
System/370 can be specified in the RDEVICE macro by its device
type.
For unsupported devices that do not have a device type
listed under the DEVTYPE operand, you should code the subclass on
the CLASS operand.
Then unsupported devices can be dedicated to a
virtual machine, and CP can log the error recordings, if there are
any. CP does not use unsupported devices for its own operations.
If a device specified in the RDEVICE macro is not supported by
VM/370, the following MNOTE message (warning level) is generated:
UNSUPPORTED DEVICE TYPE
The device is generated as an unsupported device. An unsupported
device can only be used if it is dedicated to a virtual machine. It
is dedicated to a virtual machine if a DEDICATE control statement
is coded in the VM/370 directory for the virtual machine, or if it
is attached to it by the CP ATTACH command.
Noig: If you code
specified.
a 2702 device
type the
SETADDR value
must be
MODEL=model
is the model letter and number for 3704 or 3705 or the model
number, if any, of a 2305, 3330, or 3333 device, or a tape device,
3278 display or 3203 printer.
Model number, if not specified,
defaults to zero except that for the 3203 it defaults to 4. It
must be coded for 3330 devices, 3278 display, and 3203 printer. If
only a number' is coded for 3704 or 3705 devices, an MNOTE is
generated.
model is a value that can be:
Valy~
1 or 2
4 or 5
1, 2, or
1 or 11
Al - H8
1, 2, 3,
5 or 7
1, 2, or
3, 4, 5,
1
11
4, 5, or 6
3
6, 7 or 8
Device
2305
3203
3330
3333
3704, 3705-1, or 3705-11
2415
2420
3410 or 3411
3"20
3272 or 3274, Kodel 1B
Notg§:
1. The 3277 Model 1 is a 480-character display screen and
is only supported by VM/370 as a dedicated device.
2. If a model number is included for devices that do not
require model numbers, the system generation is terminated
with an error message.
FEATURE=(feature[,feature) ••• )
are the device's optional features.
in any order. These features are:
These features can be written
Part 2. Defining Your VM/370 System
1"5
.r1t'.l...L..L
I,
I~U'
RDEVICE Macro
ExplanatiQ'!!
7-track head on a tape drive
Conversion feature on a 7-track tape drive
Dual density on a tape drive
Operator identification card reader on a 3277 Model
2, or magnetic slot reader on a 3278, Models 2, 3,
or 4
A 3330V (DEVTYPE=3330) device that may be used by
VM/370 for mounting MSS system volumes
Translation feature on a 7-track tape drive
Universal character set printer
A 3330V (DEVTYPE=3330) device that may be dedicated
to a virtual machine
Two-channel switch feature for tape or DASD drive
Four-channel switch feature for tape or DASD drive
A 3800 (DEVTYPE=3800) device with four Writeable
Character Generation Modules
feat!!b:~
7-TRACK
CONY
DUA LDENS
OPRDR
SYSVIRT
TRANS
UNVCHSET
VIRTUAL
2CHANSW
4CHANSW
4WCGMS
]ot~:
For a 3330V device, either FEATURE=VIRTUAL or FEATURE=SYSVIRT
must be specified.
Co~i!!g ~onsideratio.!!§
To allow CMS to correctly verify tape mode set operations,
correct feature code for a tape device must be specified.
the
If the local 3277 or 3278 display device is equipped with the
optional operator identification card reader, or magnetic reader
attachment then the virtual machine operator can gain access to the
system (log on) only if he inserts a magnetically encoded card. Use
the FEATURE=OPRDR operand of the RDEVICE macro to specify a 3277 or
3278 device with a card reader. If you do not want access
authorization by a card reader, do not code FEATURE=OPRDR in the
RDEVICE macro.
FEATURE=OPRDR is invalid if DEVTYPE=3158.
Although still allowable, it is
not necessary to designate
FEATURE=(2CHANSW/4CHANSW) on the RDEVICE macro.
DMKCPI dynamically
determines whether or not the hardware has a two- or four-channel
switch feat ure.
CLASS= (cl[ ,cl ] ••• )
DASD
TAPE
TERM
GRAF
URI
URO
is the device class; either the output spooling class or a special
subclass for unsupported devices.
out!!!!i Spooling ~la§§..§
The spooling classes
(cl,cl ••• ) list up to four output spooling
classes separated by commas. This form of the CLASS operand can
only be specified for a 1403,
1443, or 3211 printer, or 2520P,
2540P or 3525 card punch. The spooling class, cl, is one alphameric
character. If you specify more than one class,
you must separate
them by commas.
If no class is specified, class A is assumed for
printers and punches.
co~ing ~onsideratiQ!!§
The following information
operand:
•
For
more information
should be
helpful when
about spooling
classes,
QEgb:£tob:~ Guig~.
146
IBM VM/370 Planning and System Generation Guide
you code
see the
this
VM/l1Q
March 3, 1980
RDEVICE Macro
•
The class is used by the CP START command and may be changed by
this command. For a complete description of the START command,
see the VML.JIQ Q.~g!Q!~2 ~Yig~.
•
A class C
desired.
~~B£!~§§
!2!
punch should
be
includ ed if
accounting cards
are
Q~suPE2!!~g Q~!i£~§
Specify a device subclass only for unsupported device types. CP
uses the subclass when it translates virtual CCW strings directed
to unsupported devices. This form of the CLASS operand is valid
only if the device type specified on the DEVTY-PE Operand does not
appear in the list of valid device types.
The subclasses are:
DASD
TAPE
TERM
GRAF
URr
URO
Direct Access Storage Devices
Tap e dev ices
Terminals
Display mode terminals
Unit record input devices
Unit record output devices
You must determine the correct subclass to specify for any device
type that does not appear in the list of valid device types under
the DEVTYPE operand. Do not code a subclass for any device type
that appears in that list. For example, a 1287 Optical Reader is
an unsupported device for VM/370. It does not appear in the list
of supported devices in Part 1 and is not listed as a device type
for the DEVTYPE operand of the RDEVICE macro. However, you can
define a 1287 and use it if you dedicate it to a virtual machine.
You must decide the correct subclass. For example,
RDEvrCE ADDRESS=010,DEVTYPE=1287,CLASS=URI
defines a 1287 Optical Reader at address 010. The
the unit record input (URr) subclass.
1287 belongs to
li.Q1:.§§:
1. If you use this form of the CLASS operand and the unsupported
device does not function properly, try dedicating the device
to a virtual=real machine and inhibiting CCW translation (by
issuing SET NOTRANS ON) •
Note that a maximum of 32 sense
bytes can be contained in the RDEVBLOK created for an
unsupported device.
2.
The CLASS operand is
record file devices.
invalid if
you are
specifying service
Part 2. Defining Your VM/370 System
147
Page of GC20=1801-10 As Updated March 3, 1980 by TNL GN25-0776
RDEVICE Macro
ADAPTER= BSCA
IBM1
SOCC
TELE2
TYPE1
TYPE2
TYPE3
TYPE4
is the terminal control or transmission adapter used to connect a
telecommunication I/O device to its control unit. This operand is
required if a DEVTYPE of 2701, 2702, 2703, 3704, 3705, or ICA is
specified, and is ignored if specified for any other device type.
BSCA specifies an IBM Binary Synchronous Terminal Adapter Type II
for a 2701,
or an IBK Binary Synchronous Terminal Control Type II
for a 2703, 3704, or 3705. BSCA must be specified for remote 3270
terminals and printers~
IBK1 specifies that an IBK Terminal Adapter Type I attaches a 1050
or 21ql to a Ll01, or that an IBM Terminal Cont~ol Typ~ I attaches
a 1050 or 2741 to a 2702 or 2703, or that a Line Interface Base
Type I attaches a 1050 or 2741 to a 3704 or 3705.
SDLC specifies that a
4331 Communications Adapter operate its
teleprocessing lines in Synchronous Data Link Control (SDLC) mode.
ADAPTER=SDLC is valid only when you specify DEVTYPE=ICA.
TELE2 specifies that a 3101 display terminal or a CPT-TWX (Models
33/35) Terminal attaches to a Telegraph Terminal Adapter Type II in
a 2701,
or to a Telegraph Terminal Control Type II in a 2702 or
2703, or to a Line Interface Base Type I in a 3704 or 3705.
TYPE1, specifies the channel adapter accessed by a 3704. For
DEVTYPE=3705, TYPE4 should be coded.
In identifying the channel
adapter, TYPE1 or TYPE4 must be specified for the Emulation Program
(EP). In identifying the line adapter, IBM1, TELE2, or BSCA can be
specified only in relation to another RDEVICE macro which has
ADAPTER=TYPE1, or TYPE4.
SETADDR=sadnum
is
the set
address
(SAD)
command
to be
issued for
a
telecommunication line attached to a 2702, 3704, or 3705 control
unit. This operand is required if the device is a 2702.
Sadnum
!~lY~
o
1
2
3
4
CPTYPE={~f
~Q!m~ng
SADZERO
SADONE
SADTWO
SADTHREE
(no SAD command is issued)
}
is the 3704/3705 control program to be run in a 3704 or 3705
Communications Controller.
EP specifies the 2701, 2702, or 2703
Emulation Program.
148
IBM VK/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
RDEVICE Macro
ALTCU=cuu
specifies an alternate control unit address to be used if paths
through the primary control unit are unavailable. cuu 1S a
three-digit hexadecimal address. Only one ALTCU can be specified.
The ALTCU cuu must specify an address with a low order address
position of 0 or 8. otherwise, the following MNOTE is issued:
INVALID ALTCU ADDRESS
The ALTCU operand is only valid for tape and DASD devices. An MNOTE
is issued if an invalid device type is specified.
"ALTCU" IS INVALID FOR DEVICE TYPE "devtype"
The ALTCU operand should only be specified when the installation
has the string switch feature to support two control unit paths to
a device.
The ALTCU cuu address should specify the low address a~sociated
with the alternate real control unit. There is one occasion when
the ALTCU cuu should specify the logical control unit address. When
the FEATURE=xxx-Device operand indicates that the control unit
supports more than sixteen devices and the devices on the second or
subsequent group of sixteen devices are defined by separate RDEVICE
macros. The ALTCU cuu should identify the logical RCUBLOK in
VM/370. VM/370 constructs one RCUBLOK for each set of sixteen
devices supported by the real control unit.
Given an alternate control unit configuration where each of two
control units support thirty-two devices, the following two macro
definitions are acceptable:
RDEVICE ADDRESS=(300,32) ,ALTCU=400
RDEVICE ADDRESS=300,FEATURE=32-DEVICE
RCTLUNIT ADDRESS=400,FEATURE=32-DEVICE
RCHANNEL ADDRESS=3
RCHANNEL ADDRESS=4
RDEVICE ADDRESS=(300,16) ,ALTCU=400
RDEVICE ADDRESS=(410,16),ALTCU=310
RCTLUNIT ADDRESS=300,FEATURE=32-DEVICE
ReTLUNIT ADDRESS=400,FEATURE=32-DEVICE
RCHANNEL ADDRESS=3
RCHANNEL ADDRESS=4
CPNAME=cpname
is the 1- to 8-character name of a 3704/3705 control program that
is to be automatically loaded in the 3704 or 3705 at IPL time. If
an automatic load is not desired, omit this operand.
BASEADD=cuu
is the native address (load address) of the 3704/3705 that controls
the physical line(s).
This operand is required for correct
operation of VM/370 recovery management for emulation lines based
on a 370ij/3105. This operand is valid only if ADAPTER=IBM1 (or
=TELE2 or =BSCA).
CLUSTER=label
is the label of the CLUSTER macro that defines the clustered or
standalone remote 3275 or 3277 station attached to this line. This
operand is valid only if ADAPTER=BSCA is specified.
Part 2. Defining Your VM/370 System
149
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0Tlb
RDEVICE Macro
1M AGE=imagelib
is the image library to be used by the 3800 printer device after a
cold start if none is specified on the STABT command. If this
operand is omitted, the default is IMAG3800.
CHARS=ffff
is 1 to 4 characters that represent the character arrangement table
for the 3800 printer device to be used after a
cold start if none
is specified on the START command.
If this operand is omitted, the
default is GF10.
DP MS IZE=n
is the maximum size of the delayed purge queue for the 3800 printer
device to be used after a cold start if none is specified on the
START command.
If this operand is omit ted, the defa ult is 1.
(The
maximum allowed is 9.)
FCB=lpi
is the FCB to be used for the page separator (6, 8, or 12) for the
3800 printer device after a cold start if none is specified on the
START command.
If this upeLali~ i~ 0~lLLea, the aaf~ult i~ 6.
The following examples illustrate the
use of the RDEVICE macro
instructions to describe a 1403 printer with the Universal Character Set
(UCS) feature,
four 9-track,
800 bpi tape drives,
and eight CPT-TWX
lines on a 2702.
RDEVICE ADDRESS=00E,DEVTYPE=1403,FEATURE=UNVCHSET,
CLASS = (A, C)
RDEVICE ADDRESS=(OCO,4) ,DEVTYPE=2401
RDEVICE ADDRESS=(030,8),DEVTYPE=2702,ADAPTER=TELE2,
SETADDR=2
The RDEVICE macro instruction generates an entry in a table of printers
or
a table of punches or a table of readers for spooling when
DE VT YP E= 1 403 , 3 203 ,
32 1 1, 144 3 ,
25 4 0 P , 3 52 5, 2 5 40 R ,
3 505 ,or 2 5 0 1 is
specified. Each table has a maximum of 32 entries; one of the following
messages results if more than 32 readers, printers, or punches are
specified.
MORE THAN 32 READERS
MORE THAN 32 PRINTERS
MORE THAN 32 PUNCHES
If any of these messages prints,
it indicates that the RDEVBLOK is
generated, but no entry is made 1n the printer or punch table;
the
device cannot be used for CP spooling.
150
IBM VM/370 Planning and system Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
RDEVICE Macro
The RDEVICE macro instruction generates an entry in a table of
programmable communications controllers when DEVTYPE=3704 or 3705 is
specified.
This table can have a maximum of 10 entries; the following
message results if more than ten 3704 or 3705 devices are specified:
MORE THAN 10 TP CONCENTRATORS
If this message prints, it indicates that the RDEVBLOK is generated, but
no entry is made in the programmable Communications controller table.
The RCTLUNIT macro generates an RCUBLOK containing an index to each of
sixteen possible devices.
When AITCU is specified, both the primary and
alternate RCUBLOKS contain an index to the same RDEVBLOK.
The following
MNOTE is issued when an RDEVICE macro specifying the ALTCU operand is
defined and an RDEVICE macro is also defined for a device with the
alternate control unit address:
CONTROL UNIT TABLE FOR raddr1 IN USE by raddr2
For example
RDEVICE ADDRESS=140,ALTCU=150
RDEVICE ADDRESS=150
RCTLUNIT ADDRESS=140
RCTLUNIT ADDRESS=150
RCHANNEL ~DDRESS=1
Device 140 is defined with a primary control unit address of 150 and
an alternate control unit address of 150.
The ALTCU=150 specification
indicates that the 150 RCUBIOK will contain an index to the 150
RDEVBLOK.
In this example, a RDEVICE macro also appears for device 150.
A conflict arises since the RCUBIOK index for control unit 150 cannot
index to both RDEVBLOK 140 and RDEVBLOK 150. In the above example, the
user must remove the 150 RDEVICE macro to resolve the conflict.
Specifying the FEATURE=(2CHANSW/4CHANSW) option on the RDEVICE macro to
indicate whether the hardware will support reserve/release CCWs is
unnecessary.
DMKCPI makes an accurate and dynamic determination by
issuing a release CCW to the tape or count-key-data DASD devices. If
the hardware supports the Two- or Four-Channel Switch Feature,
the
FTRRSRL
bit
is
turned
on
in
the
RDEVFTR
field.
The
FEATURE=(2CHANSW/4CHANSW) option on the RDEVICE macro is ignored since
determination is made by the initialization routine.
For compatibility
reasons, the FEATURE=(2CHANSW/4CHANSW)
operand is still allowed, but
when specified, causes the following MNOTE to be issued:
2CHANSW}
{ 4CHANSW
FEATURE IGNORED
Part 2. Defining Your VM/370 System
150.1
tifJLJ.J.
150.2
I,
I~OI
IBM VM/370 Planninq and System Generation Guide
RCTLUNIT Macro
Use the RCTLUNIT macro to generate a real control unit block (RCUBLOK).
One RCTLUNIT macro must be specified for each real control unit. The
maximum number of real control units is 511, providing you have enough
real storage to hold the real control unit blocks (RCUBLOKs). Control
units generally fall into two categories: those supporting eight or
fewer devices, and those supporting more than eight devices.
A control unit that supports eight or fewer devices must be assigned
an address that is divisible by eight.
All devices with an address
equal to the control unit's address (the base address) or any of the
next seven sequential addresses are mapped to this control unit. For
example, devices with addresses of 018 through 01F are mapped to a
control unit with address 018.
On a multiplexer channel, several device addresses may fall within
the address range of one BCTLUNIT macro.
When this occurs,
only one
RCTLUNIT macro may be coded, eVEn though more than one real control unit
is present.
This case is an exception to the general rule that one
RCTLUNIT macro must be specified for each real control unit.
For
example, a system console at address 009, a 2540 reader at address OOC
and a 2540 punch at address OOD would be defined in a single RCTLUNIT
macro with a control unit address of 008, even though the system console
and the 2540 card reader punch have different real control units. In
this case, any valid control unit type can be coded.
The only exception
to this is that control units that operate on a shared subchannel must
be specified by separate ReTLUNIT macros.
For control units supporting a range of more than eiqht device
addresses, use the FEATURE= operand. The base ad dress must be divisible
by sixteen.
All devices from the base address up to the number of
devices specified by the FEATURE= operand are mapped to the specified
control unit. When a control unit has the hardware feature that allows
it to support more than eight devices, the RCTLUNIT macro must specify
FEATURE=xxx-DEVICE, where xxx is the number of addressable devices that
can be attached to this control unit. The number of devices specified
must be divisible by sixteen and rounded to the next higher increment of
sixteen if not divisible. The maximum number of devices that can be
attached to a control unit is 256.
For example, if you have a 3830 control unit with the 64-device
feature installed, you must specify FEATURE=64-DEVICE for it,
even if
fewer than sixty-four 3330s are installed.
VM/370
specified
supports
addresses)
requires that all devices on one physical control unit be
on a single RCTLUNIT macro. The microcode in the 3830-2 which
3350 DASD allows address
skipping
(in blocks of eight
on the same physical control unit.
Device Addresses 150-157 and 160-167 on first 3830-2
Device Addresses 158-15F and 168-16F on second 3830-2
This address scheme is not supported by Cr.
All addresses on a given
physical control unit must be specified with a single RCTLUNIT macro and
use the FEATUBE=xxx-DEVICE operand, where appropriate, for a contiguous
ranqe of addresses.
A device that attaches directly to the channel without a separate
control unit must still have a RCTLUNIT macro coded for it.
For
example, if a 3210 is defined with an RDEVICE macro,
it must have a
corresponding RCTLUNIT macro.
Part 2. Defining Your VM/370 System
151
_ -
- - -
~
. - -
~
. -
..._ -
- r - - - - -
64
t"- .......
• ,
•
J
V,
U
I
.....
.L~""
U " .. ~ J
-
V V ~ I
RCTLUNIT Macro
The RCTLUNIT macro instructions describing the control units for your
installation's computing system may be in any order, but they must be
contiguous and follow all of the RDEVICE macro instructions in the
module DMKRIO.
The first RCTLUNIT macro instruction also generates the
label DMKRIOCU, which indicates the start of the real control unit
blocks to CP.
The name field may not be
specified for the RCTLONIT macro
instruction; if a name is specified it is ignored. The macro generates
a name by appending the control unit address to the characters RCO. For
example, if the control unit address is 230, the name RCU230 is
generated.
The format of the RCTLUNIT macro is:
Name
Operation
Cperands
ADDRESS= cuu
,CUTYPE=type
ALTC'R= (n. n in) ][ , FE!TUR E~xxx-DEV!CE]
L____________________________________________________________________________
RCTLONIT
r
~
ADDRESS=cuu
is the real address of the control unit.
cuu consists of 3
hexadecimal digits.
The high order digit is the channel address of
this control unit. The low order two digits must be the lowest
address of the control unit.
The
first digit may be any
hexadecimal number from 0 to F. If the xxx-DEVICE feature is
supported, the low order digit must be O. Otherwise, it must be
either 0 or 8.
Noig: If your installation has a 2701, 2702, or 2703, and a 3704 or
3705 executing in emulation mode, you must be sure that their
addresses are not the same.
CUTYPE=t ype
is the device type of the control unit. One
device type numbers can be specified: 1052, 1442,
2319, 2403, 2404, 2415, 2495, 2501, 2520, 2701,
2804, 2820, 2821, 2822, 2826, 2835, 2840, 2841,
2955, 3036, 3066, 3138, 3148, 3158, 3210, 3215,
3411, 3505, 3525, 3704, 3705, 3803, 3811, 3830,
IFA, ISC, CTCA.
of the following
2150, 2250, 2314,
2702, 2703, 2803,
2844, 2845, 2848,
3272, 3274, 3345,
3851, 7443, ICA,
In addition, any other control unit that can be attached to a real
System/370 may be specified in a RCTLONIT macro instruction by its
dev ice type.
!otg: Specify an Integrated Printer Adapter (IPA) as a 2821.
specify a 3274 Model 1B as a 3272. Also, specify a 3880 Model 1 as
a 3830. If using IFA with 3344 or 3350 devices with more than 16
logical units, specify CUTYPE=3830 with either FEATORE=32-DEVICE or
64-DEVICE. If CUTYPE=CTCA, the low order digit of ADDRESS= must be
O. The Integrated File Adapter's 9821 feature provides a range of
addresses that is too large for the RCTLONIT macro to process when
used with 3344s.
The range of addresses (160-1F7) is treated as
invalid.
152
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
RCTLUNIT Macro
Even though some devices attach directly to the channel without a
separate control unit,
a RCTLUNIT macro instruction must be
included for them.
For example, if you want to define a 3215, you
must code an RDEVICE and RCTLUNIT macro for the 3215; even though
the 3215 does not require a control unit, it requires a RCTLUNIT
macro.
If several different devices have addresses that are within
the same control unit address, only one RCTLUNIT mac~o can be
specified. Which control unit you specify is not relevant.
ALTCH= (n, n,n)
specifies the alternate channel(s) to be used with the control unit
address if the primary channel path is unavailable or offline. n
represents the one-digit channel addresses for the alternate
channel paths.
Up to three alternate channels can be specified.
There can be nc splitting of control units when using alternate
channels. All devices on one physical control unit must be defined
as having alternate channel(s) or no alternate channel(s).
FEATURE=xxx-DEVICE
is the optional control unit feature.
The feature,
xxx-DEVICE,
indicates that the control unit is controlling more than eight
devices.
The prefix, xxx, can be 16,32,48,64,80,96,112,. 128,
144,
160, 176, 192,
208,
224,
240, or 256.
"Appendix B:
Configuration Aid" lists the maximum number of devices that may be
specified for each control unit.
This feature may be specified for
a 2403, 2702, 2703, 2803, 2835, 3272, 3345, 3704, 3705, 3803, 3830,
ICA, IFA, or ISC.
For any unsupported control unit, FEATURE=16-DEVICE is valid and is
the maximum you can specify.
Unsupported control units are any
tha t do not a ppear in the "Configurations" section of Part 1.
!g~ni~:
The starter system does not provide support for device
configurations over 16 when you are defining the devices needed to
do the system generation.
Therefore, if your installation includes
control units that share more than
16 devices and are also
switchable to another processor, the channel interface enable
switch from the other processor should be in the disable position
while you perform the system generation.
The following examples illustrate the use of the RCTLUNIT macro
instruction to describe
the control units for:
a
3215 console
printer-keyboard with address 01F, a
2314, and a 3705 with lines 040
through 04B.
RCTLUNIT ADDRESS=018,CUTYPE=3215
RCTLUNIT ADDRESS=230,CUTYPE=2314
RCTLUNIT ADDRESS=040,CUTYPE=3705,FEATURE=16-DEVICE
Part 2. Defininq Your VM/370 System
153
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
RCTLUNIT Kacro
The RCHBLOK contains an index to each of thirty-two possible RCUBLOKS.
When the ALTCH operand is specified on the RCTLUNIT macro, both the
primary and alternate RCHBLOKS contain an index to the same RCUBLOK.
The following message is issued when an RCTLUNIT macro is defined
specifying the ATLCH operand and an RCTLUNIT macro is also defined which
creates an RCUBLOK for the alternate channel address.
CHANNEL TABLE FOR RCUxxx IN USE BY RCUyyy
For Example:
RDEVICE ADDRESS=250
RDEVICE ADDRESS=350
RCTLUNIT ADDRESS=250,ALTCH=(3)
RCTLUNlf ADDRE55=350
RCHANNEL ADDRESS=2
RCHANNEL ADDRESS=3
The ALTCH specification indicates that the RCHBLOK for channel three
should index to the 250 RCUBLOK. The RCTLUNIT macro for 350 causes a
conflict since the RCHBLOK cannot index to both the 250 and 350
RCUBLOKS. In the above configuration, the user must remove the RCTLUNIT
macro and RDEVICE macro for 350.
154
IBK VM/370 Planning and System Generation Guide
April 1, 1981
RCHANNEL Macro
RCHANNEL Macro
Use the RCHANNEL macro to generate a real channel block (RCHBLOK). An
RCHANNEL macro instruction must be coded to define each real channel in
the I/O configuration.
The RCHANNEL macro instructions describing the channels for your
installation may be in any order, but they must be contiguous and follow
all of the RCTLUNIT macro instructions in the module DMKRIO. The first
RCHANNEL macro instruction also generates the label DMKRIOCH,
which
indicates the start of the real channel blocks to CP.
No name is specified for the RCHANNEL macro instruction; if a name is
specified, it is ignored.
The RCHANNEL macro generates a name by
appending the channel address to the characters RCHAN.
For example, if
the channel address is 2, the name RCHAN2 is generated.
The format of the RCHANNEL macro is:
r---------------------------------------------------------------------------~
I Name
1---1
I
I
I
Operation
RCHANNEL
Operands
AD tRESS= address
,CHTYPE={SELECTOR
)
MULTI PLEXOR ~
BLKMPXR
J
ADDRESS=address
is the real address of the channel. It is a hexadecimal number from
o to F.
CHTYPE={SELECTOR
}
MULTIPLEXOR
BLKMPXR
is the type of channel.
SELECTOR indicates a selector channel.
MULTIPLEXOR indicates a byte-multiplexer channel.
BLKMPXR indicates a block multiplexer channel.
The following examples illustrate the use of the RCHANNEL macro
instruction to describe a multiplexer channel whose address is 0, a
selector channel whose address is 1,
and a block multiplexer channel
whose address is 2.
RCHANNEL
RCHANNEL
RCHANNEl
ADDRESS=O,CHTYPE=MULTIPLEXOR
ADDRESS=1,CHTYPE=SELECTOR
ADDRESS=2,CHTYPE=BLK~PXR
If any errors are detected, the real channel block is not generated.
This results in undefined symbols in the real control unit blocks for
this channel.
Part 2. Defining Your VM/370 System
155
RIOGEN Macro
RIOGEN Macro
Use the RIOGEN macro instruction to generate the channel index table and
unit record and console tables. It must appear as the last macro
instruction before the END statement in the DMKRIO file.
The name field must not be specified
format of the RIOGEN macro is:
for the
RIOGEN macro.
The
r---------------------------------------------------------------------------Oper ation
Operands
t
Name
f----------------·------------------------------------------------------RIOGEN
CONS=cuu
I
I
f
[ ,ALTCONS= (cuu[ ,cuu,cuu ••• ]) ]
[ ,SRF= (cuu[ , cuu, cuu ••• ]) ]
I
CONS=cuu
is the address of the VM/370 primary system console. The address
is a hexadecimal device address that was previously specified in an
RDEVICE macro entry. This device must be either a 3036, 3066,
3210, 3215 7412, 3277 (local attachment), or a 3278 Kodel 2A, 1052
(via a 2150 freestanding console), a System Console for the 3158
(in printer-keyboard mode with the 3213 Printer Kodel 1 required),
or a System Console for the 3138 or 3148 (in printer keyboard mode
with a 3286 printer required, or in display mode).
[ , ALTCONS= (cuu=[ ,cuu, cuu ••• ]) ]
is the address or a list of addresses of alternate consoles. These
addresses are hexadecimal device addresses that were previously
specified in an RDEVICE macro instruction. There is no limit on the
number of alternate consoles that may be specified. These devices,
which should be physically located as close as possible to the
primary system console, may be any device supported as a VM/310
logon device (except for those remote terminals connected via
3704/3705 Communications Controllers). If
the primary system
console is not operational at VM/310 system initialization, 'an
attempt will be made to access the first alternate console~ If the
first alternate console is not operational, an attempt will be made
to start the next alternate console.
If an operational console is
found, the console will be used as the VK/310 system operatorLs
console. If no operational alternate console is found (or if no
alternate console was specified), CP enters a disabled wait state
with a wait state code of X'005'
in the instruction address
register (IAR).
Coding Consideration§: The alternate console
must not be a
telecommunications line on a real IBK 3104/3105 Communications
Controller unless the 3704/3105 was previously loaded by some other
operating system with a 210X Emulator Program.
If the alternate console is an IBM 2141 Communication Terminal, or
3767 communication Terminal (operating as a 2141), it must use the
EBCDIC transmission code.
If the alternate console is a local
3277, it must be a Model 2.
156
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNt GN25-0837
RIOGEN Macro
[ , S RF = (c u u [ , c u u , c u u. • • ]) ]
is the address or a list of addresses of SRF (service record file)
devices used for the 3031, 3032, or 3033 processors. cuu is the
hexadecimal device address that was previously specified in an
RDEVICE macro statement. The device type of the SRF is 7443.
In a 3033
AP system, there are two
3036 consoles.
This
configuration has four SRF devices, therefore, you should specify
multiple SRF devices at system generation.
The SRF addresses you
specify in the RIOGEN macro statement should be the same as the
addresses of the SRF devices attached to the service support
consoles. The FIOGEN macro statement produces an "NOTE warning
message if you specify more than 32 SRF devices.
1.
In 3033 MP environments with I/O configured asymmetrically to one
processor, ~n order to access the SRF devices in both 3036
consoles, a channel path must be available from the I/O processor
to both SRF devices.
2.
If an SRF device is found to be inaccessible during initialization
of the error recording cylinders, an error message is sent to the
system operator.
processing continues, however, the frames from
that SRF device are not placed on the error recording cylinders.
Examples:
The following examples define a primary system console (01F)
with an
alternate console (050), a system console (009) with no alternate
console, and a primary system console (01F) with alternates at (050) and
(060) •
RIOGEN CONS=01F,AtTCONS=050
RIOGEN CONS=009
RIOGEN CONS=01F, AtTCONS=(050, 060)
Part 2. Defining Your VM/370 System
157
-t"'--- .,
,."...."
Real I/O Configuration File
Example of Coding the Real I/O Configuration File
(DMKRIO)
In this example, macros are coded to support the following real devices:
1
1
1
2
1
1
1
2
2
1
1
2
1
1
1
1
1
1
3
1
2
2
96
4
2540 Card Reader/Punch
3505 Card Reader
3525 Card Punch
1403 Printers with the Universal Character Set feature
3211 Printer with the Universal Character Set feature
3215 Console printer-Keyboard
2955
3705 Communications Controllers (one with an IBM1 adapter and
the other with a BSCA adapter)
2702 Transmission Control Units (with one that supports Teletype
terminals)
2314 Direct Access Storage Facility with 8 modules, attached via
an Integrated File Adapter
2305 Fixed Head Storage with 8 addresses
3330 Disk Storage (One unit has eight modules and the other has
ten.
The unit with t~n modules has eight of the~ switchablc
between two channels.)
3350 Direct Access storage with 8 addresses
2401 Magnetic Tape Unit with 4 tape drives
3410 Magnetic Tape Unit, Model 3, with 1 tape drive
3420 Magnetic Tape Unit, Model 7, with 2 tape drives
Multiplexer channel
Selector channel
Block multiplexer channels
Channel-to-Channel Adapter
channel interfaces on the 3851 MSC
3830-3 control units for access to 3330V devices, each with a
single channel interface
3330V Direct Access Storage devices,
48 of which can be
dedicated to one or more virtual machines and 48 of which are to
be used for VM/370 system volumes
3330-1 device addresses that are not real spindles, but rather
allow the processor to have direct access to the MSC tables
through the 3830-3 Staging Adapter
Figure 19 shows the real configuration.
158
IBM VM/370 Planning and System Generation Guide
~
...,.
\Q
~
Channd 0
t1
(f)
1.0
~
>I
PI
IS
'1j
I-'
(f)
0
HI
PI
!:d
(f)
P>
I-'
()
I"d
PI
t1
c+
0
1:1
..,.
HI
\Q
N
tj
(f)
..,.
'1:1
..,.
HI
~
t1
P>
CPU
200
c+
..,.
2305
0
1:1
Drives
207
1:1
\Q
~
0
~
t1
"
W
-.....J
0
Ul
(f)
IS
111
\0
390
3411
Magnetic
Tape Unit
and Control
381
y ~ Le In
SYSTEM SUPPORT VIRTUAL MACHINES
At system generation time, two' additional virtual machines should be
created beyond those needed by normal users (one each for hardware and
software support). The IBM FE programming support representative should
be consulted when the configurations for these virtual machines are
being determined.
The hardware support is for:
•
The processor, which must be supported in a dedicated environment
because there is no method currently available that allows concurrent
support of the processor, real storage, or channels when executing
problem programs.
•
The input/output equipment, which can be supported using online test
(OLT) under OLTSEP. The OLTSEP program can be executed in its own
virtual machine.
Any of the offline testing capabilities of the system devices can be
used on inactive units while the system is operating.
To perform online hardware support, a virtual machine must be defined
in the VM/370 directory for the IBM service representative.
The virtual
machine should have enough virtual storage defined to execute OLTSEP.
Normally, the service representative requires that the device being
tested be dedicated to his virtual machine.
(The system operator can
dedicate devices to a virtual machine by issuing the ATTACH command.)
Also the virtual machine for hardware support should have the minimum
configuration required to run online tests,
and provide access to CKS
with a read/write minidisk.
Privilege class F should be assigned to
allow the hardware diagnostics to be run, and error recording and
retrieval facilities to be utilized.
184
IBM VM/370 Planning and System Generation Guide
Directory
The hardware service representative's virtual machine should also
have access to CMS and to the error recording area of the system
residence volume. An EREP program (CPEREP) runs under CMS thus allowing
editing and printing of all VM/370-recorded machine check and channel
check errors.
This directory entry is
with the starter system.
included in
the VM/370
directory provided
The virtual machine for software support should have the minimum
configuration necessary to recreate (virtually) problems that occur on
the r~al machine. The ECMODE option must be specified in the directory
OPTION control statement for this machine. You should assign privilege
class G to the user of this machine. Also, you should assign privilege
class E if he is to examine real storage addresses, and privilege class
B if he is to allocate devices.
Sample Directory Entries
The following sample VM/370 directory entries provide an installation
with some of the entries necessary for operation and updating. The
indentations are for readability and are not required by the directory
program. LINK control statements are used whenever possible to minimize
the number of changes to the VM/370 directory whenever a minidisk extent
is moved. A brief explanation of some of the virtual machine user ids
follows.
THE SYSTEM OPERATOR'S VIRTUAL MACHINE (OPERATOR)
The userid for this directory entry must be the same as the userid on
the SYSOPER operand of the SYSOPR system generation macro.
The USER
control statement gives the operator all command privilege classes
except class F. Actually, if other virtual machines are defined with
command privilege
classes appropriate
for updating
VM/370, the
operator's virtual machine only needs class A command privileges. The
MDISK control statement defines the 191 minidisk which contains CMS
files, EXEC procedures, and service programs to update VM/370.
USER OPERATOR PASSWORD 256K 1M ABCDEG
ACCOUNT ACCTNO BIN1
CONSOLE 009 3215
SPOOL OOC 2540 R
SPOOL OOD 2540 P
SPOOL OOE 1403
LINK VMSYS 190 190 RR
MDISK 191 3330 1 10 UDISKA WR RPASS WPASS
Part 2. Defining Your VM/370 System
185
Directory
A VIRTUAL MACHINE TO RECEIVE SYSTEM DUMPS (OPERATNS)
The userid for the following directory entry is the userid that was
specified on the SYSDUMP operand of the SYSOPR macro when the V"/310
system was generated. All abnormal termination dumps are sent to this
virtual machine. This user normally is given command privilege classes
A,
B, C, and E.
If the directory entry contains all of the disks
normally attached to the system, described as full-volume minidisks, the
user can rewrite the V"/310 directory by using the DIRECT command. The
operations group can also examine any disk while it is attached to the
system, when these disks are defined as full-volume minidisks.
USER OPERATNS PASSWORD 320K 1M ABCEG
ACCOUNT ACCTNO BIN2
CONSOLE 009 3215
SPOOL OOC 2540 R
SPOOL OOD 2540 P
SPOOL OOE 1403 A
1!~K v~SYS 190 190 PP
MDISK 191 3330 101 10 UDISKA WR RPASS WPASS
"DISK 350 3330 0 404 SYSRES WR RPASS WPASS
MDISK 351 3330 0 404 SYSWRK RR RPASS WPASS
MDISK 250 3330 0 404 UDISK1 RR RPASS WPASS
"DISK 251 3330 0 404 UDISK2 RR RPASS WPASS
"DISK 232 2314 0 203 BATCH1 RR RPASS WPASS
"DISK 233 2314 0 203 BATCH2 RR RPASS WPASS
MDISK 234 2314 0 203 TSOSYS RR RPASS WPASS
MDISK 235 2314 0 203 TSOWRK RR RPASS WPASS
Some installations may want to combine the functions of OPERATOR and
OPERATNS into one virtual machine. This can be accomplished in the above
examples by adding the last 8 control statements of the directory entry
for OPERATNS to the directory entry for OPERATOR. The OPERATOR virtual
machine can then perform all the system functions required to operate
the V~/310 system.
In addition to the virtual machines discussed up to this
are those virtual machines whose function is to:
point, there
•
Support and update the VM/310 system
•
Test new releases
status
•
Provide the hardware service representative with the
diagnostics and extract recorded error data
•
Provide other users with a remote file spooling capability
of the system before placing
them into production
ability to run
A VIRTUAL MACHINE FOR UPDATING AND SUPPORTING VM/310 (VMSYS)
The following directory entry defines a virtual machine (VMSYS) that can
support and update the V"/310 system. The 194 minidisk contains
alterations or fixes to CP; these alterations and fixes are not applied
until they have been thoroughly tested and considered stable. The 394
minidisk contains the distributed source files.
The VMSIS virtual
1A6
IBM V"/310 Planning and System Generation Guide
Directory
machine's privilege classes include class E and class G command
privileges, so that it can issue the SAVESYS command to save C~S and
other systems. The 190 minidisk contains the CMS nucleus and all of the
CMS modules and EXEC procedures a vailable to all C~S users. Any virtual
machine that wants to use the CMS system, links to this disk (190). The
393 minidisk contains the distributed CMS
source code in an unaltered
form. The 193 minidisk holds CMS PTFs and updates.
USER VMSYS PASSWORD 512K 16M
ACCOUNT ACCTNO BIN9
OPTION ECMODE REALTI~ER
CONSOLE 01F 3215
SPOOL OOC 2540 R
SPOOL OOD 2540 P
SPOOL OOE 1403
SPOOL 002 3211
MDISK 190 3330 030
MDISK 19 1 3330 017
MDISK 194 3330 115
MDISK 199 3330 029
MDISK 193 3330 001
MDISK 294 3330 031
MDISK 393 3330 061
MDISK 394 3330 141
MDISK 390 3330 231
BCEG
085
007
027
001
030
030
080
090
002
CPRnLO
CPRnLO
CPRnLO
CPRnLO
USERD1
USERD1
USERD1
USERD1
USERDl
fiR
WR
MR
WR
MR
5R
MR
5R
Mi
RPASS
RPASS
RPASS
RPASS
RPASS
RPASS
RPASS
RPASS
RPASS
A HARDWARE SERVICE VIRTUAL MACHINE (SERV)
The following directory entry defines the virtual machine
(SERV) that
can be used by the hardware service representative. This virtual machine
usually has class F command privileges.
For more information on the
hardware service virtual machine, see the publication V5/370 Q1~ ~£
~!!Q! E~£Q!Qing Guide.
USER SERV PASSWORD 256K 1M FG
ACCOUNT ACCTNO BIN10
CONSOLE 009 3215
SPOOL OOC 2540 R
SPOOL OOD 2540 P
SPOOL OOE 1403
LINK VMSYS 190 190 RR
MDISK 191 3330 151 10 UDISKA iR RPASS WPASS
The VM/370 Directory Supplied with the Starter
System
A control
with the:
•
•
•
•
2314
3330
3340
3350
statement file for the
starter
Starter
Starter
Starter
VM/370 directory program
is supplied
System
System
System
System
If the supplied control statement file meets your needs, you can execute
the Directory program using the supplied control statements. Otherwise,
you can code your own control statements or edit the supplied control
statements to produce the file you need for your installation.
Part 2. Defining Your V5/370 System
187
2314 starter system Supplied Directory
2314 STARTER SYSTEM SUPPLIED DIRECTORY
The VM/370 Directory program control file supplied with the 2314 starter
system is:
*
CHANGE THE NEXT ENTRY FOR YOUR SYSTEM RESIDENCE DEVICE
DIRECTORY XXX 2314 LABEL
*
USER OPERATOR OPERATOR 320K 1M ABCDEG
ACCOUNT ACT1 OPERATOR
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
MDISK 191 2314 008 007 CPRnLOt WR READ WRITE
LINK MAINT 194 194 RR
LINK MAINT 190 190 RR
*
USER CE CE 512K 1M EFG
ACCOUNT ACT2 CE
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
MDISK 191 2314 015 004 CPRnLO WR READ WRITE
LINK MAINT 194 194 RR
LINK MAINT 190 190 RR
*USER
MAINT CPCMS 720K 16M BCEG
ACCOUNT ACT3 MAINT
OPTION ECMODE REALTIMER
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
MDISK 1QO 2314 035 135 CPRnLO
MDISK 191 2314 019 010 CPRnLO
MDISK 1Q4 2314 170 033 CPBnLO
MDISK 1Q9 2314 034 001 CPBnLO
MR
WR
MR
WR
READ
READ
READ
READ
*
**
*****
MDISK XXX 2314 000 203 YYYYYY MW
THE ABOVE ENTRY SHOULD BE MODIFIED TO MATCH THE ADDRESS AND LABEL
* OF YOUR SYSTEM RESIDENCE VOLUME. IT MAY THEN BE USED BY THIS ID
* TO LOAD A DIRECTORY AND WRITE A CP NUCLEUS.
*
DEL ETE THE ' * , (IN FRONT OF MDISK) ALSO.
*
******
USER IVPM1 IVPASS 320K 16M G
ACCOUNT ACT4 IVPM1
CONSOLE 009 3210
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
MDISK 191 2314 001 001 CPRnLO iR READ WRITE
LINK MAINT 194 194 RR
LINK MAINT 190 190 RR
tCPRnLO may be CPR4LO, CPR5LO,
release level.
'~8
CPR6LO and
so forth, depending
IBM VM/370 Planning and System Generation Guide
on the
231q starter System Supplied Directory
*
USER IVPK2 IVPASS 320K 1M G
ACCOUNT ACT5 IVPM2
CONSOLE 009 3210
SPOOL OOC 25qO READER A
SPOOL OOD 25qO PUNCH A
SPOOL OOE lq03 A
MDISK lql 231q 002 001 CPRnLO WR READ WRITE
LINK KAINT 19q 19q RR
LINK MAINT 190 190 RR
*
USER RSCS RSCS 512K
ACCOUNT ACT6 RSCS
OPTION ECKODE
CONSOLE 009 3215
SPOOL 001 25qO READER A
SPOOL OGe 2540 READER A
SPOOL OOD 25QO PUNCH A
SPOOL OOE lQ03 A
MDISK 1q1 231Q 003 005 CPRnLO WR READ WRITE
LINK MAINT 190 190 RR
DEDICATE OB 1 078
DEDICATE OB2 079
DEDICATE OB3 07A
*
USER ECMODE ECMODE 512K 1M G
ACCOUNT ACT7 ECMODE
OPTION ECMODE REALTIMER
CONSOLE 009 3215
SPOOL OOC 25QO READER A
SPOOL OOD 25QO PUNCH A
SPOOL OOE 1Q03 A
KDISK 191 231Q 029 005 CPRnLO WR READ WRITE
LINK KAINT 19Q 19Q RR
LINf MAINT 190 190 RR
*
USER OPERATNS OPERATNS 512K 1M BCEG
ACCOUNT ACT8 OPERATNS
CONSOLE 009 3215
SPOOL OOC 25QO READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE lQ03 A
LINK MAINT 190 190 RR
**********
**
*
*
*
*
**
*
*
THE FOLLOWING MINIDISK ENTRY IS PROVIDED AS AN EXAMPLE OF
THE SPACE RECOMMENDED FOR AN IPCS VIRTUAL MACHINE.
IF YOU INTEND TO USE THE OPERATNS USERID AS YOUR IPCS
VIRTUAL MACHINE, YOU SHOULD CHANGE THE FOLLOWING STATEMENT
TO ALLOCATE KINIDISK SPACE ON ONE OF YOUR SYSTEM DASD VOLUMES.
MDISK 1ql 231Q XXX 010 YYYYYY iR READ WRITE
Part 2. Defining Your VM/370 System
189
3330 starter System Supplied Directory
3330 STARTER SYSTEM SUPPLIED DIRECTORY
The VM/370 Directory program control file supplied with the 3330 starter
system is:
*
CHANGE THE NEXT ENTRY FOR YOUR SYSTEM RESIDENCE DEVICE
DIRECTORY XXX 3330 LABEL
* OPERATOR OPERATOR 320K 1M ABCDEG
USER
ACCOUNT ACT1 OPERATOR
CONSOLE 009 3215
SPOOL OOC 2540 READER A.
SPOOL OOD 2540 PUNCH A
SPOOl. OOE 1403 A
MDISK 191 3330 008 005 CPRnLO WR READ WRITE
LINK MAINT 194 194 RR
LINK MAINT 190 190 RR
*
USER
CE CE 512K 1M ~p~
ACCOUNT ACT2 CE
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL ODE 1403 A
"DISK 191 3330 013 004 CPRnLO WR READ WRITE
LINK MAINT 194 194 RR
LINK MAINT 190 190 RR
*
USER
"AINT CPC"S 720K 16M BCEG
ACCOUNT ACT3 MAINT
OPTION ECMODE REALTIMER
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
MDISK 190 3330 030 085 CPRnLO
MDISK 191 3330 017 007 CPRnLO
MDISK 194 3330 115 027 CPRnLO
MDISK ·199 3330 029 001 CPRnLO
MR
WR
MR
WR
READ
READ
READ
READ
******
* MDISK XXX 3330 000 404 YtYYYY MW
* THE ABOVE ENTRY SHOULD BE MODIFIED TO MATCH THE ADDRESS
* OF YOUR SYSTEM RESIDENCE VOLUME. IT MAY THEN BE USED BY
* TO LOAD A DIRECTORY AND WRITE A CP NUCLEUS.
* DEL ETE THE ' * , (IN FRONT OF MDISK) ALSO.
* CHANGE THE '404' TO A '808' IF YOURS IS A 3330-11
******
USER IVPMl IVPASS 320K 16M G
ACCOUNT ACT4 IVPMl
CONSOLE 009 3210
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
MDISK 191 3330 001 001 CPRnLO WR READ WRITE
LINK MAINT 194 194 RR
LINK MAINT 190 190 RR
lQO
IBM VM/370 Planning and System Generation Guide
AND LABEL
THIS ID
3330 starter System Supplied Directory
*
USER IVPM2 IVPASS 320K 1M G
ACCOUNT ACT5 IVPM2
CONSOLE 009 3210
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL ODE 1403 A
MDISK lq1 3330 002 001 CPRnLO WR READ WRITE
LINK MAINT 194 194 RR
LINK MAINT 190 190 RR
*
•
USER RSCS RSCS 512K
ACCOUNT ACT6 RSCS
OPTION ECMODE
CONSOLE 009 3215
SPOOL 001 2540 READER A
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
MDISK 191 3330 003 005 CPRnLO WR READ WRITE
LINK MAINT 190 190 RR
DEDICATE OBl 078
DEDICATE OB2 079
DEDICATE OB3 07A
*
USER ECMODE ECMODE 512K 1M G
ACCOUNT ACT7 ECMODE
OPTION ECMODE REALTIMER
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL DOD 2540 PUNCH A
SPOOL OOE 1403 A
MDISK 1ql 3330 024 005 CPRnLO WR READ WRITE
LINK MAINT 194 194 RR
LINK MAINT 190 190 RR
*
USER OPERATNS OPERATNS 512K 1M BCEG
ACCOUNT ACT8 OPERATNS
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL ODD 2540 PUNCH A
SPOOL DOE 1403 A
LINK MAINT 190 190 FR
****************
** THE FOLLOWING MINIDISK ENTRY IS PROVIDED AS AN EXAMPLE OF
* THE SPACE RECOMMENDED FOR AN IPCS VIRTUAL MACHINE.
* IF YOU INTEND TO USE THE OPERATNS USERID AS YOUR IPCS
* VIRTUAL MACHINE, YOU SHOULD CHANGE THE FOLLOWING STATEMENT
* TO ALLOCATE MINIDISK SPACE ON ONE OF YOUR SYSTEM DASD VOLUMES.
** MDISK 1ql 3330 XXX 005 YYYYYY WR READ WRITE
*
****************
*
*
**
CYLINDERS 142 TO 403 ARE UNUSED AND MAY BE USED FOR
*
ANY OTHER VIRTUAL MINIDISK SPACE. IT CAN ALSO BE
*
USED FOR PAGING, SPOOLING OR T-DSK SPACE.
*
*
*
Part 2. Defining Your V8/370 System
191
3340 starter System Supplied Directory
3340 STARTER SYSTEK SUPPLIED DIRECTORY
The V~/370 Directory program control statements supplied with the 3340 startel
system is:
*
CHANGE THE NEXT ENTRY FOR YOUR
SYSTE~
RESIDENCE DEVICE
DIRECTORY XXX 3340 LABEL
*
USER OPERATOR OPERATOR 320K lK ABCDEG
ACCOUNT ACTl OPERATOR
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
KDISK 191 3340 011 010 CPRnLO iR READ WRITE
LINK KAINT 194 194 RR
LINK MAINT 190 190 RR
*
USER CE CE 512K 1K EFG
ACCOUNT ACT2 CE
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
KDISK 191 3340 021 005 CPRnLO WR READ WRITE
LINK MAINT 194 194 RR
LINK KAINT 190 190 RR
*
USER KAINT CPCKS 720K 16K BCEG
ACCOUNT ACT3 KAINT
OPTION ECKODE REALTIKER
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
KDISK 190 3340 048 240 CPRnLO
KDISK 191 3340 026 015 CPRnLO
KDISK 194 3340 288 060 CPRnLO
KDISK 199 3340 046 002 CPRnLO
KR
WR
KR
iR
READ
READ
READ
READ
******
** KDISK XXX 3340 000 348 XXXXXX MW
* THE ABOVE ENTRY SHOULD BE KODIFIED TO MATCH THE ADDRESS
* OF YOUR SYSTEK RESIDENCE VOLUKE. IT KAY THEN BE USED BY
* TO LOAD A DIRECTORY AND WRITE A CP NUCLEUS.
* DELETE THE ' * , (IN FRONT OF KDISK) ALSO.
* CHANGE THE '348' TO A '696' IF YOURS IS A 3340-70
******
USER IVPK1 IVPASS 320K 16K G
ACCOUNT ACT4 IVPKl
CONSOLE 009 3210
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
MDISK 191 3340 001 002 CPRnLO WR READ WRITE
LINK MAINT 194 194 RR
LINK KAINT 190 190 RR
192
IBM VK/370 Planning and System Generation Guide
AND LABEL
THIS ID
3340 starter System Supplied Directory
*
USER IVP~2 IVPASS 320K 1~ G
ACCOUNT ACT5 IVP~2
CONSOLE 009 3210
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
~DISK 191 3340 003 002 CPRnLO WR READ WRITE
LINK ~AINT 194 194 RR
LINK ~AINT 190 190 RR
*USER
RSCS RSCS 512K
ACCOUNT ACT6 RSCS
OPTION EC~ODE
CONSOLE 009 3215
SPOOL 001 2540 READER A
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
~DISK 191 3340 005 006 CPRnLO WR READ WRITE
LINK ~AINT 190 190 RR
DEDICATE OB 1 078
DEDICATE OB2 079
DEDICATE OB3 07A
*
USER EC~ODE EC~ODE 512K 1K G
ACCOUNT ACT7 EC~ODE
OPTION EC~ODE REALTI~ER
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
~DISK 1q1 3340 041 005 CPRnLO WR READ WRITE
LINK MAINT 194 194 RR
LINK ~AINT 190 190 RR
*
USER OPERATNS OPERATNS 512K
ACCOUNT ACT8 OPERATNS
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
LINK MAINT 190 190 RR
1~
BCEG
**********
**
*
*
*
*
**
THE FOLLOWING MINIDISK ENTRY IS PROVIDED AS AN EXA~PLE OF
THE SPACE RECO~~ENDED FOR AN IPCS VIRTUAL MACHINE.
IF YOU INTEND TO USE THE OPERATNS USERID AS YOUR IPCS
VIRTUAL ~ACHINE, YOU SHOULD CHANGE THE FOLLOWING STATEMENT
TO ALLOCATE MINIDISK SPACE ON ONE OF YOUR SYSTEM DASD VOLUMES.
MDISK 1q1 3340 XXX 015 YYYYYY WR READ WRITE
Part 2. Defining Your VK/370 System
193
3350 starter system Supplied Directory
3350 STARTER SYSTEM SUPPLIED DIRECTORY
The VM/370 Directory program control file supplied with the 3350 starter
system is:
*
CHANGE THE NEXT ENTRY FOR YOUR SYSTEM RESIDENCE DEVICE
DIRECTORY XXX 3350 LABEL
*
USER OPERATOR OPERATOR 320K 1K ABCDEG
ACCOUNT ACTt OPERATOR
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL ODD 2540 PUNCH A
SPOOL ODE 1403 A
MDISK 191 3350 006 003 CPRnLO WR READ WRITE
LINK MAINT 194 194 RR
LINK KAINT 190 190 RR
*
USER CE CE 320K 1M EFG
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL ODD 2540 PUNCH A
SPOOL ODE 1403 A
MDISK 191 3350 009 002 CPRnLO WR READ WRITE
LINK KAINT 194 194 RR
LINK MAINT 190 190 RR
*
USER MAINT CPCKS 720K 16K BCEG
ACCOUNT ACT3 MAINT
OPTION ECMODE REALTIMER
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL ODD 2540 PUNCH A
SPOOL ODE 1403 A
MDIS' 190 3350 021 035 CPRnLO
KDISK 191 3350 011 005 CPRnLO
MDISK 194 3350 056 009 CPRnLO
MDISK 199 3350 020 001 CPRnLO
MR
iR
MR
WR
READ
READ
READ
READ
*
*****
** MDISK XXX 3350 000 555 YYYYYY Mi
* THE ABOVE ENTRY SHOULD BE MODIFIED TO MATCH THE
* OF YOUR SYSTEK RESIDENCE VOLUME. IT MAY THEN BE
*
LOAD A DIRECTORY AND WRITE A CP NUCLEUS.
* TO
DELETE THE ' * , (IN FRONT OF MDISK) ALSO.
*
******
USER IVPMl IVPASS 320K 16M G
ACCOUNT ACT4 IVPKl
CONSOLE 009 3210
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
MDISK 191 3350 001 001 CPRnLO WR READ WRITE
LINK KAINT 194 194 RR
LINK MAINT 190 190 RR
194
IBK VM/370 Planning and System Generation Guide
ADDRESS AND LABEL
USED BY THIS ID
3350 starter System Supplied Directory
* IVPM2 IVPASS 320K 1M G
USER
ACCOUNT ACT5 IVPM2
CONSOLE 009 3210
SPOOL OOC 2540 READER A
SPOOL ODD 2540 PUNCH A
SPOOL OOE 1403 A
MDISK 191 3350 002 001 CPRnLO WR READ WRITE
LINK MAINT 194 194 RR
LINK MAINT 190 190 RR
* RSCS RSCS 512K
USER
ACCOUNT ACT6 RSCS
OPTION ECMODE
CONSOLE 009 3215
SPOOL 001 2540 READER A
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
MDISK 191 3350 003 003 CPRnLO WR READ WRITE
LINK MAINT 190 190 RR
DEDICATE OBl 078
DEDICATE OB2 079
DEDICATE OB3 07A
*
USER
ECMODE ECMODE 512K 1M G
ACCOUNT ACT7 ECMODE
OPTION ECMODE REALTIMER
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
MDISK 191 3350 016 004 CPRnLO WR READ WRITE
LINK MAINT 194 194 RR
LINK MAINT 190 190 RR
* OPERATNS OPERATNS 512K 1M BCEG
USER
ACCOUNT ACT8 OPERATNS
CONSOLE 009 3215
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
LINK MAINT 190 190 RR
****************
** THE FOLLOWING MINIDISK ENTRY IS PROVIDED AS AN EXAMPLE OF
* THE SPACE RECOMMENDED FOR AN IPCS VIRTUAL MACHINE.
* IF YOU INTEND TO USE THE OPERATNS USERID AS YOUR IPCS
* VIRTUAL MACHINE, YOU SHOULD CHANGE THE FOLLOWING STATEMENT
* TO ALLOCATE MINIDISK SPACE ON ONE OF YOUR SYSTEM DASD VOLUMES.
** MDISK 191 3350 XXX 003 YYYYYY WR READ WRITE
*****************
*
** CYLINDERS 065 TO 555 ARE UNUSED AND MAY BE USED FOR
* ANY OTHER VIRTUAL MINI DISK SPACE. IT CAN ALSO BE
* USED FOR PAGING, SPOOLING OR T-DSK SPACE.
*
*
*
Part 2. Defining Your VM/370 System
195
Directory Program
Allocating DASD Space for the VM/370 Directory
Before you create your VM/370 directory using the Directory program, be
sure you have enough DASD space allocated as directory space (DRCT).
Use the CP Format/Allocate service program to format and allocate the
cylinders to be used for the VM/370 directory. The cylinders must be
allocated as DRCT. To calculate the total number of cylinders required,
first calculate the total number of records used:
NR
=
NU
169
+
«NU + NM) x 2) + all other control statements
---------------------------------------------170
NR = total number of records used
NU = number of USER control statements
NM = number of MDISK control statements (except for temporary
disks)
Then, calculate the number of cylinders (NC):
•
For 3330: NC = NR/57
•
For 2314,2319: NC = NR/32
•
For 2305, 3340: NC = NR/24
•
For 3350: NC = NR/120
!Q!~
You should initially format and allocate space for two VM/310
directories.
You can then build a new directory whenever needed,
without overlapping the current one,
and without formatting and
allocating space each time a new directory is created. If you wish to
reallocate the area in which the directory resides, you must reallocate
the DASD space and then rerun the Directory program. When a VM/310
directory is written, space is allocated from available cylinders, a
full cylinder at a time, and a minimum of two cylinders are used for the
VM/370 directory.
Once a new VM/370 directory is successfully written, cylinders used
for the old directory (marked as temporarily allocated during directory
creation) are marked as free. In this way, DASD space allocated for DRCT
cylinders is freed and can be reused for the next directory creation.
If space for two directories is not initially allocated, each time you
want to create a new directory, you must allocate space for the
directory before you create it.
196
IBM VM/370 Planning and System Generation Guide
Directory Program
The Directory Program
The V~/370 directory program can be run under CMS (using the DIRECT
command) or standalone. The standalone version of the directory program
is provided in object deck form (a three card loader, followed by the
DMKDIR text deck), and may be loaded directly from either a real or
virtual card reader.
If you run the directory program under CMS, input records must be in
a CMS file with a default fileid of "USER DIRECT". The DIRECT command
loads the directory creation module. If no filename is specified, the
program looks for a file named USER DIRECT. Otherwise, it looks for a
file named filename DIRECT.
If the file
is not found, or
if an error occurs
during processing,
the directory is not created and the old directory remains unaltered.
Normal completion writes the DASD address of the new VM/370 directory
in the VOLl label, and if it is updating the active system directory, it
places the new directory in use by VM/370. You can print the new
directory by issuing the CMS command PRINT USER DIRECT
(or PRINT
filename DIRECT).
The virtual machine executing the directory program must have write
access to the volume to contain the new directory.
If you create a
directory that is to be written on the active VM/370 system residence
volume, your virtual machine's current directory entry must have write
access to the volume containing the current VM/370 directory.
!Zsmpl~~
Assume that you have the following virtual
directory modification.
USER UPDRCT PASSWORD 256K
ACCOUNT NUMBER BIN2
IPL C~S
CONSOLE 009 3215
SPOOL C 2540 READER A
SPOOL D 2540 PUNCH A
SPOOL E 1403 A
LINK CMSSYS 190 190 R
MDISK 330 3330 o 404
MDISK 331 3330 o 404
MDISK 230 2314 o 203
MDISK 231 2314 o 203
MDISK 232 2314 o 203
MDISK 233 2314 o 203
MDISK 191 3330 26 0110
machine for online
1M ABC
SYSRES
SYSWRK
UDISK 1
UDISK2
BATCH1
BATCH2
VMDSK2
WR
WR
RR
RR
RR
RR
WR
RPASS
RPASS
RPASS
RPASS
RPASS
RPASS
RPASS
WPASS
WPASS
WPASS
WPASS
WPASS
WPASS
WPASS
Using the CMS EDIT command and its subcommands, you can create or
modify a card-image file of the VM/370 directory input. When you are
ready to write a new directory, issue the command:
DIRECT
filename
where filename is a CMS file
(normally named USER) with filetype DIRECT
containing the necessary Directory program control statements.
The
DIRECT command puts this file into the form of a directory, and replaces
the old directory with this new one.
Part 2. Defining Your VM/370 System
197
Directory Program
Loading the DMKDIR object deck via the card reader is the same as
issuing the DIRECT command in CMS, except that after IPL, the program
asks you for the address of a card reader containing the Directory
program control statements~
Once the directory is updated, directory changes for a user currently
logged on to the system do not take effect until the user logs off the
system and then logs back on.
When a new directory is written for a new system residence volume,
the new directory does not take effect until the new system residence
volume is loaded (via IPL).
INVOKING THE DIRECTORY PROGRAM (DMKDIR) UNDER CMS
The iM/370 Directory ~£ugLd& L~~OLab ~n~ ~U~[iYULdLioll vI ~~~n U~~L'~
virtual machine
in the VM/370
directory. Each
virtual machine
confiquration includes counterparts of the components found in a real
System/370: a virtual operator's console, virtual storage, and virtual
I/O devices and control units.
The same version of the Directory service program deck can be placed
in the card reader and loaded directly, or run in a virtual machine
under CMS.
The CMS file named DIRECT can be updated
incluae additional directory entries.
with the
CMS Editor
to
Use the CMS DIRECT command to process any file to see if it follows the
required directory format.
To actually change or swap the currently
active VM/370 directory, you must have both of the following:
1.
User class A, B, or C.
2.
write access to the system-owned (system residence or IPL device)
volume that contains the current directory up to and including the
directory cylinders, or to the volume that is to contain the new
directory.
If you have the above qualifications and wish t~ verify that a CMS
file can be used as a directory file, you must use the EDIT option;
otherwise, if there are no control statement errors, the file is put
into active use.
To build a VM/370 directory on a CP-owned volume using preallocated
cylinders, a new directory should be built so as not to overlay an
existing directory.
You must,
therefore, allow
space for
two
directories, or allocate a new area for the VM/370 directory each time
it is created.
1°8
IBM VM/370 Planning and System Generation Guide
Directory Program
If you execute the Directory program under VM/370, the newly created
directory is dynamically swapped, and placed in use by VM/370 (provided
that you have class A, B, or C and that the directory you updated is the
one that is currently in use by the system).
If you do not have the
proper privilege class, the directory is updated on the directory volume
but not dynamically swapped, so the change will not go into effect until
the next time the system is loaded (via IPL). The format of the DIRECT
command is:
,,
,t
r
DIRECT
r
r
,filename
IUS~R
Ifiletype
IQIRECT
L
L
r
",
I filemode I I I
I
*
III
[ (EDIT) ]
......
L
L
filename [filetype [filemode]]
is the identification of the file containing the control
statements for the Directory program.
If no filename and
filetype are given, the program defaults to a file named USER
DIRECT; otherwise, it looks for the file named. The filetype
must be DIRECT. If only filename is given, filetype defaults
to DIRECT.
The filemode defaults to
if not specified.
*
(EDIT)
specifies
changed.
that
the directory
is
to
be examined,
but
not
Under eMS, the DIRECT command loads the directory creation module.
The first statement encountered must be a DIRECTORY statement. If not
found, or another DIRECTORY statement is found, the program terminates.
A syntax error in any statement generates an error message, and the
directory is not updated. If no critical errors are encountered, the
remaining statements are checked for syntax.
If the Directory program abnormally terminates, the old directory is
not altered. Normal completion places the directory in use by VM/370.
After the new directory is created, it can be printed by issuing the CMS
command PRINT USER DIRECT or PRINT filename DIRECT.
The DIRECT command filename and filetype default to a CMS file
identification of USER DIRECT.
The filemode defaults to
if not
specified. Any or all of the defaults can be overridden by the command
line. The EDIT option allows you to run the program without updating
the directory on disk.
This enables you to check the syntax of the
directory statements without accessing the directory disk.
*
INVOKING DIRECTORY AS A STANDALONE PROGRAM
Standalone operation in a virtual machine is the same as eMS operation,
with this exception: after IPL, the program asks you for the virtual
card reader address.
If you enter a null line, the IPL device address
is the default of OOC.
Part 2. Defining Your VM/370 System
199
Directory Program
DIRECTORY CONTROL STATEMENTS
The control statements should be in the following formats, with one or
more blanks as operand delimiters. All operands are positional from
left to right.
If any operands are omitted, all rema1n1ng operands in
that statement must be omitted, with the exception of the OPTION
statement. Its entries are self-defining and not positional.
Only columns 1 through 71 are inspected by the program.
All data
after the last possible operand on any card is ignored.
Also, blank
cards and cards having an asterisk (*) as the first operand are ignored.
If any input card is found to be in error, the program continues to
process the control statements, validating all control statements before
terminating. If the directory runs out of space, the program terminates
immediately. After an abnormal termination (or, for CMS, the EDIT run) ,
the old directory is not altered, and the new directory is not saved.
The DIRECTORY control statement defines the device on which the
directory is allocated. It must be the first statement. The format of
the DIRECTORY control statement is:
r
,
DIRectory
cuu
devtype
volser
cuu
is the address of the device that is to contain the directory
and is specified in three hexadecimal digits.
devtype
is four decimal digits that represent a supported device type
suitable for the VK/370 directory (231q, 2319, 2305, 3330,
33QO or 3350). For a 3350 device in native mode, specify 3350
as the device type.
For a 3350 used in 3330 compatibility
mode, specify 3330. Specify a 33QQ disk as a 33QO, and a 3333
as a 3330.
3330V (virtual 3330) volumes associated with 3850 Mass
storage System cannot be specified as the residence device for
the VM/370 directory.
Not~~
volser
The
is the volume serial number of
alphameric characters).
USER control
statement defines
a
the directory volume
virtual machine
(1
to 6
and creates
a
A
entry
VM/3 7 0 directory entry. It delimits the directory entry for one user.
separate USER statement must be prepared for each directory
required. The format of the USER control statement is:
r
I
1
I
I
I
r
r
r
r
""
L
L
L
L
.J .... .I
User userid pass (stor [mstor [cl [pri lIe lId Icd les 1111]]]]
ION ION ION tON 1111
10FF lOFF 10FF 10FF 1111
L-
200
IBM VM/370 Planning and System Generation Guide
Directory Program
use rid
is a
1- to 8-character user identification.
Any alphameric
characters may be used except SYSTEM. SYSTEM is the userid of
the VM/370 system VMBLOK, and should never be used for a
virtual machine. Each user in the directory, except for those
whose password is NOLOG, must have at least one device.
Any
of the various devices described meet this requirement; for
example, the device may be a console or spool device.
1.
The userid should not contain the characters "LOGONxxx",
where xxx is a terminal address of the installation. This
character string is assigned to the terminal at address
xxx from the time the initial interrupt is received until
the llser is
identified~
during logon.
2.
Do not specify SYSTEM as a userid. VM/370 reserves SYSTEM
as an identifier for its own use. Similarly, do not use
ALL as a userid as it is reserved by VM/370.
3.
If the userid of AUTOLOG1
(a reserved system user
identification)
is used, then during the VM/370 IPL
operation, the AUTOLOG1 virtual machine is automatically
logged onto the system •
.In application, the AUTOLOG 1 virtual machine could be the
CMS Batch virtual machine,
or a virtual machine that,
through the use of the directory's IPL statements loads a
CMS named system.
Then the CMS system, using a PROFILE
EXEC with AUTOLOG command statements within the EXEC
file, will initiate the logon of other virtual machines
to the system.
pass
is a
1- to 8-character user-security password that must be
entered by the user to gain access to the VM/370 system and
the virtual machine you are
defining in these control
statements.
No1~~
Use the reserved password NOLOG for users who do not
have a virtual machine configuration in the VM/370 directory.
The NOLOG user uses the real card reader spool device as a
means of entry for processing by the eMS batch facility.
NOLOG is used for spooling purposes only; attempts to log on
using this password are. inhibited.
stor
is 1 to 8 decimal digits that define the virtual machine's
storage size.
It must be a multiple of qK.
The last
character must be K or M. The default is 128K. The minimum
size is 8K.
All entries not on a qK boundary are rounded up
to the next qK boundary. The maximum size is 16M.
mstor
is 1 to 8 decimal digits that define the maximum virtual
machine storage size that this user can define as his storage
after logqinq on the system. It must be coded in multiples of
qK. The last digit must be K or M. The default size is 1M.
All entries not on a qK boundary are rounded to the next qK
boundary. The minimum size is 8K.
The maximum size that can
be specified is 16M.
cl
is
to 8 alphabetic characters from A to H (with no
intervening blanks) defining the privilege class(es) given to
this user.
The default is G.
Part 2. Defining Your VM/370 System
201
Directory Program
Not~~
If privilege class F is assigned to a virtual machine,
I/O error recording is not automatically done.
This allows
the class F user to set the kind of error recording he wants
to perform.
pri
is a number from 1 to 99 used by the control program priority
dispatcher.
One is the highest priority and 50 is the
default.
No1~~
The same priority value can be used for several users.
Also, if the specification for this statement is not entered,
then line end
(Ie), line delete (ld), character delete (cd),
and escape (es) characters default to system-defined values.
The following special VM/370 logical editing symbols may be set ON,
OFF, or substituted with two hexadecimal characters or one graphic
character of the user's choice.
N01~~ In
addition to the directory specification, the user can change
these logical editing symbols using the TERMINAL command. The default
value for all symbols is ON.
The exception to this rule 1S a virtual.
machine initiated by the CP AUTOLOG command; in this case all logical
line editing is OFF.
Ie
is a one-character "line end" symbol or a two-character
hexadecimal representation of the symbol.
ON sets the system
default value (I).
OFF disallows "line end" syabol usage. For
example:
"Ie" can be coded as + or 4D or ON or OFF.
ld
is a one-character "line delete" symbol or a two-character
hexadecimal representation of the symbol.
ON sets the system
default value (¢). OFF disallows ",line delete" usage.
cd
is
a
one-character
"character delete"
symbol
or
a
two-character hexadecimal representation of the symbol.
ON
sets the system default value (~. OFF disallows "character
delete" usage.
es
is
a
one-character
"escape-character"
symbol
or
a
two-character hexadecimal representation of the symbol.
ON
sets the system default value
(").
OFF disallows "escape
character" symbol usage.
The
ACCOUNT control
statement defines an account
number and a
distribution identification. The distribution identification has no
internal system use; it is provided for customer use (for example, a
code for distribution of printed output). The ACCOUNT statement is
optional.
However, if this statement is omitted, both the account
number and the distribution code default to the userid. This statement
(if coded) must follow the USER statement and precede the first device
statement. The format of the ACCOUNT control statement is:
r--------·-----------------------------------------------------------------------------------------
I
Account
number
(distribution]
L
202
IBM VM/370 Planning and System Generation Guide
Directory Program
number
is a one- to eight-character account number that is punched in
the accounting data for this virtual machine. The USERID from
the USER statement is also punched in the accounting data.
distribution
is a one- to eight-character distribution identification word
that is printed or punched with the userid in the separator
for spooled output for this user. This value is optional and
defaults to the userid from the USER statement if oJllitted.
The OPTION control statement selects specific options available to the
user. This statement is optional and, if used, must follow the USER
statement or another OPTION statement, and precede the first device
statement (CONSOLE, "DISK, DEDICATE, LINK, or SPOOL) •
Multiple OPTION
statements can be inserted if the options selected exceed the statement
record length. The -format of the OPTION control statement is:
r----·
,
Option
,
Realtimer Ecmode Isam Virt=real
CPUID bbbbbb
AFFinity nn
Acct
Svcoff
BMX
L-
REALTIMER provides a timer for the virtual machine that is updated
during virtual processor run time and also during virtual wait
time.
(If the virtual machine does not have the REALTIMER
option, its timer reflects only the virtual processor run time
used.)
This option is required for virtual machines running
systems or programs that go into a wait state expecting a
timer interruption. This timing ability can also be obtained
by issuing the CP command line SET TIMER REAL.
ECMODE
allows the virtual machine to run in extended control mode.
The ECMODE option must be specified for virtual machines using
operating systems that:
1.
Operate in System/370
VM/370 itself).
2.
Use the dynamic address translation
OS/VS1, OS/VS2, DOS/VS, and VM/370).
3.
(such as OS GTF
Use control registers other than zero
(General Trace Facility), which uses Monitor Call and
requires control register eight) •
4.
Depend on
feature.
the
extended
System/370
control
extended
mode (such
as
facility (such
as
channel
masking
The ECMODE option must also be specified for the virtual
machine that is to perform system support or updating, and for
an RSCS virtual machine. ECMODE is also required when using
the clock comparator.
Note: A virtual machine defined without the ECMODE option in
the-directory is limited to 6 I/O channels, while a virtual
machine with the ECMODE option may address up to 16 I/O
Part 2. Defining Your VM/370 System
203
Directory Program
channels.
If a virtual machine with the EC~ODE option
executes in basic control mode, the I/O masking for channels 6
and higher is simulated by the extended channel feature. If a
virtual machine with the EC"ODE option executes in extended
control mode, the I/O masking for all 16 channels is handled
via extended control register 2.
This facility can also be
obtained by issuing the CP command SET EC"ODE ON.
provides special channel command word translation routines
that permit as/pcP, "FT, and
MVT ISA" programs
(which
dynamically modify their CCis) to operate properly in a
virtual machine. This is required only for virtual machines
that use as/pcP, ~FT, or MVT ISAM access methods or OS/VS ISA"
when executing in a V=R partition under OS/VS. This option is
not needed for DOS, DOS/VS, or OS/VS ISAM when run only in a
V=V partition of OS/VS. This facility can also be obtained by
issuing the CP command SET ISAM ON.
ISAM
VIRT=REAL is a performance option that allows the user to place his
virtual machine in lower storage. such that its virtual
storage addresses correspond to the real storage address
(except for its page zero, which is relocated). The real page
zero is controlled by the CP nucleus. No CCi translation is
required. This option is required for a virtual machine to
successfully execute self-modifying channel programs other
than those generated by OS/VS TCAM (Level 5, generated or
invoked with the VM/370 option) or OS ISAM. VIRT=REAL can be
specified for any number of virtual machines but only one
virtual machine can use this facility at any given time.
A
(via IPL)
in a
named or shared system cannot be loaded
virtual=real area.
The device address must be specified in
the IPL command.
To generate
a VM/370 system with a
virtual=real machine, see "Specifying a Virtual=Real Machine"
in the Part 1.
ACCT
a user with the ACCT option in his directory can charge
another user for virtual machine resources. For example, a
user who sends a job to the CftS batch virtual machine can be
charged for the time that he uses in the batch machine. Note
that the ACCT option should be specified in the directory of
the CftSBATCH virtual machine so that user/job identifying
information will be printed on the forms separator that
separates spooled output files.
SVCOFF
specifies that CP, instead of the virtual machine assist
feature or the V"/370 Extended Control Program Support
handles all SVC interrupts for this virtual machine. A user
whose directory entry contains this option can override it by
issuing SET ASSIST SVC.
All SVC 76 interrupts are handled by CP
the SVCOFF option is specified.
NO!~l
BftX
204
whether or not
specifies that all virtual machine I/O operations are to occur
as block multiplexer channel operations rather than selector
channel (the default) operations.
In block multiplexer mode,
the virtual channel is not busy until the initial 510 is
complete
(selector
mode
operates
similarly).
Block
multiplexer allows the successful start of multiple SIOs to
different devices on the same channel. However, virtual I/O
operations on channel 0 are processed as byte multiplexer
channel operations.
Channels that have a channel-to-channel
adapter are restricted to selector channel operation.
IBft VM/370 Planning and System Generation Guide
Directory Program
The channel mode
channel zero can
CHANNEL command.
setting for all channels except virtual
be changed by the use of the CP DEFINE
CPUID bbbbbb
provides a unique processor identification (CPUID)
to be
stored in response to the STIDP instruction. It is necessary
to associate a unique CPUID with each virtual machine that is
attached to an MSC port since solicited/unsolicited messages
are directed to the host system in the virtual environment by
means of the CPUID. There is no checking by VM/370 to ensure
that all virtual machines using the SET CPUID command have
specified unique processor serials.
The hexadecimal field
Ibbbbbb i
is
the processor
identification number.
The
processor identification number (serial) is only a portion of
the complete CPUID.
The CPUID identification stored in
response to a STIDP instruction is a string of 16 hexadecimal
digits shown as follows:
aabbbbbbccccdddd
aa
is the version code; these two digits are forced to
X'FF' to identify that the virtual machine is running
under VM/370.
bbbbbb
is up to 6 hexadecimal digits that indicate the
processor identification number; this field is set by
the directory OPTION statement values or modified by
the SET CPUID command.
cccc
is the model number; this field contains a high order
digit followed by the three digits of the model
number (0-9). This field defaults to the model number
of the real machine.
dddd
is the machine check extended logout; this field is
forced to X'OOOO' since CP does not reflect machine
checks to the virtual machine.
o
If the CPUID was not specified by means of the SET CPUID
command or the OPTION control statement, the CPUID stored as a
result of the STIDP instruction is the real CPUID with the
first two digits set to X'FF' and the last four digits set to
X'OOOO' (present CPUID logic).
A processor serial of more
than six digits on the SET CPUID command results in an error
message.
A processor identification number (serial)
of less than six
hexadecimal digits results in zeros being padded to the left
of the number. A three-byte field in the VMBLOK (VMCPUID)
contains the value set as a result of invoking this DIRECTORY
option.
AFFINITY nn
is 2 decimal digits between 00 and 63 that specify that
virtual machine execution is to be performed on a designated
processor
(nn). This attribute is only applicable in the
VM/370 attached processor environments. Any hexadecimal value
from 00 to 3F is a valid main or attached processor address;
however, the value selected must match the preset values
established for
your installation's
main and
attached
processor when the system was installed.
If the AFFINITY
option is not selected, then the virtual machine is serviced
Part 2. Defining Your VM/370 System
205
Directory Program
by the first available processor from the Vft/370 dispatch
queue. An affinity setting in the Vft/370 directory can be
overridden by the CP SET AFFINITY command. If the system is
running in attached processor mode and an error forces
recovery to uniprocessor mode, the affinity setting of virtual
machines assigned to the attached processor is nullified and
virtual machine processing may be continued on the main
processor.
The IPL control statement contains a one- to eight-character name of the
system (or one- to three-digit I/O device address) to be loaded for the
user when he logs on. This statement is optional; if specified, it must
follow the USER statement, and must precede the first device statement
(CONSOLE, MDISK, or SPOOL). The IPL statement can be overridden by the
user at logon time by specifying "LOGON userid NOIPL".
!Q!~l
If the
user is the primary
system operator, an automatic
IPL is
n2£ performed when he logs on.
The format of the IPL statement is:
r
,
Ipl
iplsys
L
iplsys
is a one- to eight-character system name or the virtual
address of the device containing the system to be loaded.
The CONSOLE control statement specifies the virtual console.
of the CONSOLE control statement is:
The format
ro-
,
Console
cuu
devtype (class]
L
cuu
is the virtual
digits.
device address
devtype
is the device type:
1052
3210
3215
of one
to three
hexadecimal
Note: The system accepts any of the devtypes indicated
regardless of the real console or terminal being used. Device
types 3275, 3276, 3277, 3278, 3036, 3066, 3138, 3148, 3158,
2741, and 3767 cannot be specified. Only one console can be
specified. If a different console is sometimes required, use
the CP DEFINE command to change the console address or add an
alternate console.
206
IBM VM/370 Planning and System Generation Guide
Directory Program
class
is a one-character spooling class. A through Z and 0 through
q
are valid.
The class governs the printing of the real
spooled output. If the class operand is omitted, the default
is class T and is for console spooling.
For more information about defining consoles, including a tutorial
discussion, see VM/370 Operating Systems in ~ Virtual Kachi~.
The MDISK control statement describes the cylinder extent on a direct
access device to be owned by the user. The DASD area assigned with this
statement becomes the user's minidisk.
~g~tion~
Neither CP nor the directory checks that minidisks defined with
the MDISK statement do not overlap each other and (for 3330, 3340, and
3350 disks) that they do not overlap the "alternate track" cylinders at
the end of the real disk. If overlap occurs, file damage is inevitable.
The format of the MDISK control statement is:
r--------------------------------,
Kdisk cuu devtype {CYlr
cy Is
,
__ T-DISK
cyls
volser [mode [pr [pw [pm J J J J}
.
I
cuu
is the virtual device address of 1 to 3 hexadecimal digits.
devtype
is the device type:
2305
2311
2311
2314
2319
3330
3340
3350
Top
Bottom
(Top half of a 2314 or 2319)
(Bottom half of a 2314 or 2319)
For a 3350 device in native mode, specify 3350 as the device
type. For a 3350 used in 3330 compatibility mode, specify
3330. Specify a 3344 disk as a 3340, and a 3333 as a 3330.
For a 3330V system volume, specify 3330 as the device type.
CYlr }
{ T-DISK
is a three-digit decimal cylinder relocation factor that
specifies the cylinder on a real disk which corresponds to
cylinder 0 of the virtual disk. If T-DISK (temporary disk) is
specified, temporary disk space is obtained at logon time from
preallocated system disk space. This space must be initialized
or formatted by the user when he logs on and is a part of his
virtual configuration until he logs off or detaches the disk,
at w~ich time the data area is returned for reallocation for
another T-DISK area. To maintain security this area should be
physically erased before it is returned.
Part 2. Defining Your VK/370 System
207
Directory Program
Not~~ It is
not advisable to define that a minidisk start at
real cylinder zero (unless the minidisk is to be used by OS
ISA", in which case it must begin at real cylinder zero). If
you do assign a minidisk beginning at real cylinder zero, the
user who owns it must realize that the minidisk label is the
real label that both he and the V"/370 system use to identify
the disk.
Also note that CP-owned volumes must not have
minidisks beginning at real cylinder zero.
cyls
is a 1- to
cylinders.
3-digit decimal number
l1axi!!!'y,!
Disk
l1inidi.§~ Siz~.§
specifying the
number of
lcylinder&
DOS and VSAM
unde~ CMS
Il::e~
2314
200
2319
200
3330-1 or 2 404
3330-11
808
346
3340-35
696
3340-70
696
*3344
3350
555
C"S_
203
203
246
246
348
682
682
115
*MQ1~:
OS/V~
200
200
404
808
348
696
696
555
The number of cylinders indicated for the
each of the four logical 3340-70 devices.
3344 is for
If the device is a 2314 or 2319 and it is to be formatted by
IBCDASDI, then the minimum minidisk size is two cylinders
because, for these devices, IBCDASDI reserves a cylinder at
the end of every minidisk for alternate tracks.
For other
devices, the minimum size is one cylinder.
volser
is the volume serial number
alphameric characters).
mode
is the
primary access mode
requested for
the device
(read-only, write, or multiple-write), and the alternate
access (read-only or write) desired (if any). An optional 'V'
character, when appended to the mode request, specifies
virtual RESERVE/RELEASE processing.
208
of the
DASD
volume
(1 to
6
R
specifies that read-only (RIO) access is requested. The
access is not given if any other user has the disk in
write status.
RR
specifies that read-only access is requested,
another user has the disk in write status.
even if
W
specifies that write access is requested. The
not defined if any other user has the disk in
write status.
disk is
read or
WR
specifies that write access is requested if no other
user has the disk in read or write status, but that an
alternate access of read-only is acceptable if others do
have a link to the disk.
"
specifies that multiple access is requested. This means
that a write link is to be given to the disk unless
another user already has write access to it,
in which
case no link is to be given.
IB" V"/370 Planning and System Generation Guide
-------.,
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
Directory Program
MR
specifies that a
write link is to be given to the disk
unless another user already has write access to it. In
this case, a read link is given to the user and the "DEV
xxxx FORCED R/O" message is issued.
MW
specifies that a
in any case.
V
specifies that CP's virtual reserve/release support is
to be used in the I/O operations for the specified
device.
The V is appended to the immediate right of the
primary access mode specification
(or the alternate
access mode specification, if any).
Thus, if the mode
specified for a minidisk is MWV, then the mini disk will
function
with write
linkage
using CP's
virtual
reserve/release functione
write link is to be given
If a mode specification is
defaults to W.
pr
is the password that
8-character field).
pw
is the password that allows
8-character field).
pm
is the password that allows
1- to 8-character field).
omitted from
allows sharing
the statement,
in read
sharing in
to the disk
mode (a
write mode
(a
it
1- to
1- to
sharing in multiple-write mode
(a
1.
A write password
(pw) cannot be specified without a read password
(pr); a
multiple-write password (pm)
cannot be specified without
1:oth a read password (pr) and a write password (pw).
2.
If a password of ALL is used for pr, pw, or pm,
the owner of the minidisk is allowed to link
without specifying a password.
3.
When MSS support is used t the volume serial number may specify an
MSS 3330V volume. In this case, the volume serial number must be
six characters long.
4.
If the MSS communicator is initialized when the virtual machine
logs on and the system volume having a volume label of 'volser' is
not mounted, then VM/370 will attempt to find an available SYSVIRT
3330V and mount 'volser' on that device.
5.
If virtual Reserve/release processing is requested, minidisk users
with read or write access are prevented from accessing the minidisk
if the minidisk is reserved by another virtual machine.
a user other than
to this minidisk
MDISK 230 3330 5 10 WORKOl W ALL WRITE
is an MDISK statement for a minidisk with read/write access to 10
cylinders located on a
real 3330 disk volume labeled WORK01,
beginning at real cylinder 5. A user other than the owner of this
minidisk can link to it in read status without specifying a read
password, but must specify a password of
'WRITE' in order to gain
write access to it.
Part 2. Defining Your VM/370 System
209
March 3, 1980
Directory Program
MDISK 191 2314 50 15 CPDSK4 W RDPASS WRX2*
is an MDISK statement for a minidisk with read/write access to 15
cylinders located on a real 2314 labeled CPDSK4 starting at cylinder
50. A read password of RDPASS and a write password of WRX2* are
provided. This allows the other users to access the minidisk through
the directory LINK statement (see the description of the LINK
statement in this section) or the LINK command.
The SPOOL control statement specifies the unit record device that is to
be spooled. Multiple readers, punches, and printers may be specified,
each on a separate SPOOL card.
The format of the SPOOL control
st atellent is:
.-I
,
Spool
cuu devtype
(class]
I
J
L-
cuu
is
the virtual device address (1- to 3-hexadecimal digits). The
note that follows the description of ECMODE in the OPTION
control statement describes a restriction on specifying the
channel. For CMS, the followin9 unit record addresses must be
used:
PRINTER OOE
PUNCH 000
READER OOC
de vtype
is the device type:
1403
2501
1443
3203
3211
2540 R(EADER]
2540 P( UNCH]
3525
3505
class
is a 1-character spooling class.
The characters A through Z,
and * are valid. For spool output devices, the
class governs the punching or printing of the real spooled
output. If this operand is omitted, the default class A is
used. This operand is required for all output devices defined
on the spool record.
For spool input devices, the class
controls access to spool files by virtual card readers. The
default class for readers is an asterisk (*), which means the
reader can process any class of spool file.
o through 9,
For example:
SPOOL ODE 1403 A
specifies a SPOOL record for a
The output class is A.
210
virtual 1403 at
IBM VM/370 Planning and System Generation Guide
address ODE.
Directory Program
The DEDICATE control statement specifies that a real device is to be
dedicated to this user.
~SS
3330V (virtual 3330) volumes may be
specified via the DEDICATE statement. If the device is a unit record
device, input and output are not spooled by V~/370. A real device may be
dedicated to only one user at a time. Should a device be specified as
aedicated in more than one directory entry, only the first user to log
on gains access to it. The format of the DEDICATE control statement is:
r----------·----------------------------------------------------------------~
,L--________________________________
Dedicate cuu { rdev I[VOLID] . ________________________________________
volser}
[R/O] [3330V]
~
cuu
is
the virtual device address (1- to 3-hexadecimal digits).
rdev is
the real device address (1- to 3-hexadecimal digits).
VOLID
is the required keyword used if the volser is less than four
characters long. It is optional if volser is four,
five, or
six characters long.
If the VOLID operand is used, the volume must be attached to
the system when the user logs on.
When he logs off, the
operator can then detach the volume from the system.
volser
is the volume serial number of a disk pack mounted on some
real disk storage device (1- to 6-alphameric characters) or of
an ~SS volume to be dedicated to the virtual machine.
R/O
specifies that the virtual
status. If this operand is
read/write.
3330V
specifies that
and attentions
device is to be in read-only
omitted, the status defaults to
all interruptions, including cylinder
received on the rdev are to be passed
faults
to the
virtual machine in its cuu.
1.
When you dedicate a 2305 device, both the real and virtual device
addresses must specify the first exposure on the 2305
(that- is,
device address 0 or 8). When you dedicate a 2305 or detach a
dedicated 2305 from a user, all 8 exposures are processed.
2.
Use caution in defining the hexadecimal addresses of virtual
devices (cuu) in DEDICATE statements, in order to avoid a usage
conflict caused by control unit I/O interface protocol.
The
following is an example of a virtual machine's DEDICATE statements
that can cause operational conflict.
DEDICATE 10E 30E (30R is a real 3211)
DEDICATE 10F 30B (30B is a 2400 tape device)
The virtual addresses of both the 3211 and the _tape device indicate
the use of the same channel and control unit.
By definition the
devices are virtual and therefore will share one virtual control
unit (VCUBLOK) in CP. A real 3211 printer operates on a nonshared
subchannel, and the real 2400 device is designed for shared
subchannel operations.
Both of these real devices are mapped to
the same VCUBLOK. Thus, the subsequent processing of a channel
Part 2. Defining Your
V~/370
System
211
Directory Program
program involving these devices can result in a hung or busy
condition (caused by a conflict in real-to-virtual I/O processing
through the common VCUBLOK). Therefore, when defining devices,
make sured 11 the devices are defined (and separated) within their
own control unit range and not shared with other devices.
DEDICATE OB8 OBO
is a DEDICATE statement for a device at real
virtual address is OB8.
address OBOe
Its
DEDICATE 250 "YPACK
is a DEDICATE statement that defines, for this virtual machine,
virtual address 250 as the real device where DASD volume MYPACK
is mounted.
Sin("C? 'tbC?rC? is no C"0n't!"01 l!ni't 0!!
'th~
r,:acll
h~,rdwar~
for
~
~y~+~l1
console it should be noted that this restriction applies to any
system console such as the 3138, 3148, and 3158.
This restriction also applies to SPOOL statements and combinations
of DEDICATE and SPOOL statements.
3.
When the real device is a 3330V, the action VM/310 takes in
processing the DEDICATE statement at logon time depends on the
combination of operands specified. Following are the allowable
combinations and the control program action for each:
DED cuu rdev
The real device must have the VIRTUAL feature (not SYSVIRT). The
real device will be dedicated to the virtual machine as virtual
device cuu, which is a 3330-1. All cylinder fault activity on the
rdev will be processed by VM/370, transparently to the virtual
machine.
DED cuu rdev 3330V
The real device must again be a VIRTUAL 3330V. All cylinder faults
and unsolicited interrups received by V"/310 on the rdev will be
passed to the virtual machine.
DED cuu volser
When processing this statement, the control program will allocate
an available SYSVIRT 3330V and dedicate that real device to the
virtual machine as virtual device cuu. The "SS volume having volser
will be mounted on the real device, and the virtual device will be
a 3330-1. This form of DEDICATE is used to dedicate volumes to
non-MSS operating systems,
such as CMS, since the control program
chooses the real device address and no cylinder fault interrupts
are passed to the virtual machine.
DED cuu rdev volser
The difference between this example and the one immediately
preceding is that in this case the real device address is
preselected and must have the VIRTUAL feature.
This format allows
the installation to control which real devices are dedicated to
virtual machines, rather than having the control program choose a
device address when the statement is processed.
212
IB" VK/370 Planning and System
Generat~on
Guide
Directory Program
DED cuu rdev volser 3330V
This format is the same as the preceding, except that the virtual
device becomes a 3330V, such that VM/370 does not intercept any
cylinder fault interrupts or the associated attention interrupts.
4.
There are considerations that must be made when dedicating real
3330Vs to a virtual machine that also has a dedicated MSC port and
is running an OS/VS operating system with ~SS support.
(See
"Appendix F: VM/370 Restrictions.")
5.
When dedicating a real CTCA, the CTCA should be on a separate real
channel from all other virtual devices because of a possible
lOCK-out problem.
The LINK control statement makes a device that belongs to another user
(userid) available to this virtual machine at logon time.
If you want
to make one volume available to several virtual machines:
•
Define the volume
statement.
for one
of the
virtual machines
•
Define a link to that volume, with the LINK statement
virtual machines that use the volume.
with an
~DISK
for all other
Then, if you later must move or change that volume, you need only update
the one ~DISK statement, the LINK statements need not be updated. The
format of the LINK control statement is:
r
I
Link
userid
ldev
[cuu (mode]]
L
userid
is the 1- to 8-character user identification of the user to be
linked tOe
ldev
is the virtual device address of the device owned by userid to
be linked to (3 hexadecimal digit~. This is the virtual
device address, assigned by userid, of the disk you wish to
link to.
cuu
is the virtual device address for the virtual machine being
defined. "cuu" defaults to the same address as the linked-to
device (3-hexadecimal digits). If your virtual machine has
the EC~ODE option, any address up to X'FFF' is valid;
otherwise, any address up to X'SFF' is valid.
mode
is the
primary access mode
requested for
the device
(read-only, write, or multiple-write), and the alternate
access (read-only or write) desired, if any, as follows:
R
specifies that read-only (R/O) access is requested. The
link is not given if any other user has the disk in
write status.
RR
specifies that read-only access is requested,
another user has the disk in write status.
even if
Part 2r Defining Your VM/370 System
213
Directory Program
W
specifies that write access is requested. The
not defined if any other user has the disk in
write status.
WR
specifies that write access is requested if no other
user has the disk in read or write status, but that an
alternate access of read-only is acceptable if others do
have a link to the disk.
M
specifies that multiple access is requested. This means
that a write link is to be given to the disk unless
another user already has write access to it,
in which
case no link is to be given.
MR
specifies that a write link is to be given to the disk
unless another user already has write access to it. In
this case, a read link is to be given to the user, and
the "DEV xxxx FORCED R/O" message is issued.
~w
~pecifies that a
in any case.
Yrite link is to be given
to
disk is
read or
~he
disk
!Qie: If the mode is not specified, the default is R.
It is the responsibility of the operating system executing in each
virtual machine to keep data from being destroyed or altered on shared
disks.
CMS supports multiply-accessed read-only disks in full. eMS does not
support write access to disks by multiple users. A disk accessed in
write mode by one CMS user is available to other CMS users in read-only
mode, but those files altered by the write-mode user cannot be read by
the other users.
CMS disks should never be linked in write mode to more than one user.
If two or more CMS users have write access to the same disk, all data on
the disk may be dedtroyed.
~PECIAt
Cont~Q!
Statement
The SPECIAL control statement specifies the I/O units available to the
user that need not have a real I/O unit available. Special devices are
program simulated devices that mayor may not be connected to real or
virtual devices after the user has logged off.
The format of the
SPECIAL control statement is:
r
I
SPEcial
cuu
devtype
[IBMITele]
L
cuu
214
is a 1- to 3-character virtual device address.
IBM VM/370 Planning and System Generation Guide
Directory Program
devtype
is the device type:
2701
2702
2703
3138
3148
3158
3270
CTCA
TIl!ER
IBM
TELE
(virtual 3138 console)
(virtual 3148 console)
(virtu al 3158 console)
(virtual 3270 only)
(channel-to-channel adapter)
(pseudo-timer device)
valid only if devtype is 2701, 2702, or 2703
For example, a virtual machine executing a multiple-access
system that supports four IBM Type 1 adapter lines, would have
four SPECIAL entries, one for each of those addresses. This
provides a virtual 270x line to allow a user to dial to this
multiple-access system rather than logging on as a separate
virtual machine.
No!e: The Integrated Communications Attachment (rCA) on
Models 135, 135-3, or 138 should be specified as a 2701.
the System/370
DIRECTORY ENTRIES FOR Cl!S/DOS
The DOS/VS system and private libraries are accessed in r7ad-o~ly mode
under Cl!S/DOS. If more than one CMS virtual machine 1S uS1ng the
Cl!S/DOS environment, you should update the V8/370 directory entries so
that the DOS/VS system residence volume and the DOS/VS private libraries
are shared by all the CMS/DOS users.
The VM/370 directory entry for one of the Cl!S virtual machines should
contain the MDISK statements defining the DOS/VS volumes.
The VM/370
directory entries for the other Cl!S/DOS users should contain LINK
statements.
For example, assume the DOS/VS system libraries are on cylinders
0-14Q of a 3330 volume labeled DOSRES. Also, assume the DOS/VS private
libraries are on cylinders 0-99 of a 2314 volume labeled DOSPRI. Then
one CMS machine (for example, DOSUSER1)
would have the MDISK statements
in its directory entry.
USER DOSUSER1 password 320K 2M G
MDISK 331 3330 0 150 DOSRES R rpass
MDISK 231 2314 0 100 DOSPRI R rpass
All the other
example
CMS/DOS
users would
have links
to
these disks.
For
LINK DOSUSER1 331 331 R rpass
LINK DOSUSER1 231 231 R rpass
For more information about directory entries for CMS/DOS virtual
machines, see the VM/~70 Ope£ating ~yst~ in ~ Virt~! Machin~.
Part 2. Defining Your VM/370 System
215
216
IBM VM/370 Planning and System Generation Guide
System Name Table File
Preparing the System Name Table File
(DMKSNT)
The system name table consists of entries that identify the name and
location of saved systems. Three macros generate entries for the system
name table:
•
The NU!ESYS macro creates an entry in the system name table
virtual machine operating system or saved segment.
for a
•
The NAMENCP macro creates an
3704/3705 control program.
system name table
for a
•
The NAME3800 macro
3800 named system.
the system name table
for a
entry in the
creates an entry in
A system name table is supplied for each starter system.
module supplied with the 2314 starter system is:
The DMKSNT
DKKS1f.rBL CSECT
CMS
NAMESYS SYSSIZE=256K,SYSNAME=CMS,
VSYSADR=190,SYSVOL=VMRELn 1 ,SYSCYL=035;SYSSTRT=(OOl,1),
SYSPGCT=33,SYSPGNM=(0-32),SYSHRSG=(1),VSYSRES=CPRnLOI
X
X
CMSSEG
NAMESYS SYSNAME=CMSSEG,SYSVOL=VMRELn,SYSCYL=,
SYSSTRT=(002,03),SYSPGCT=(16),SYSHRSG=(16),
SYSPGNM=(256-271) ,SYSSIZE=64K,VSYSRES=,VSYSADR=IGNORE
X
X
CMSVSAM
NAMESYS SYSNAME=CMSVSAM,SYSVOL=VMRELn,SYSPGNM=(272-367),
SYSSTRT=(002,20) ,SYSPGCT=96,SYSSIZE=384K,SYSCYL=,
SYSHRSG=(17,18,19,20,21),VSYSRES,VSYSADR=IGNORE
X
X
CMSAMS
NAMESYS SYSNAME=CMSAMS,SYSVOL=VMRELn,SYSPGNM=(368-495),
SYSSTRT=(005,21) ,SYSPGCT=128,SYSSlZE=448K,SYSCYL=,
SYSHRSG=(23,24,25,26,27,28) ,VSYSRES=,VSYSADR=IGNORE
X
X
CMSDOS
NAMESYS SYSNAME=CMSDOS,SYSVOL=VMRELn;SYSHRSG=(31),
SYSSTRT=(009,22) ,SYSPGCT=8,SYSSlZE=32K,SYSCYL=,
SYSPGNM=(496-503) ,VSYSRES=,VSYSADR=IGNORE
X
X
lNSTVSAM NAMESYS SYSNAME=INSTVSAM,SYSVOL=VMRELn,SYSCYL=,
SYSSTRT=(009,31),SYSPGCT=8,SYSSIZE=32K,SYSHRSG=(254),
SYSPGNK=(4064-4071),VSYSRES=,VSYSADR=lGNORE
END
X
X
The DMKSNT module supplied for the 3330 starter system is:
CMS
NAKESYS SYSSIZE=256K,SYSNAKE=CMS,
VSYSADR=190,SYSVOL=VMRELn,SYSCYL=030,SYSSTRT=(001,1) ,
SYSPGCT=33,SYSPGNM=(0-32),SYSHRSG=(1),VSYSRES=CPRnLO
X
X
CMSSEG
NAMESYS SYSNAME=CKSSEG,SYSVOL=VMRELn,SYSCYL=,
SYSSTRT=(OOl,35),SYSPGCT=16,SYSHRSG=(16),
SYSPGNK=(256-271) ,SYSSIZE=64K,VSYSRES=,VSYSADR=IGNORE
x
X
In may be 4, 5, 6 and so forth, depending on the Release level.
Part 2. Defining Your VM/370 System
217
System Name Table File
CMSVSAM
NAMESYS SYSNAME=CMSVSAM,SYSVOL=VMRELn,SYSPGNM=(272-367) ,
SYSSTRT=(OOl,52),SYSPGCT=96,SYSSIZE=384K,SYSCYL=,
SYSHRSG=(17,18,19,20,21),VSYSRES=,VSYSADR=IGNORE
X
CMSAMS
NAMESYS SYSNAME=CMSAMS,SYSVOL=VMRELn,SYSPGNM=(368-495),
SYSSTRT=(003,35) ,SYSPGCT=128,SYSSIZE=448K,SYSCYL=,
SYSHRSG=(23,24,25,26,27,28),VSYSRES=,VSYSADR=IGNORE
X
X
CMSDOS
NAMESYS SYSNAME=CKSDOS,SYSVOL=VMRELn,SYSHRSG=(31),
SYSSTRT=(005,50),SYSPGCT=8,SYSSIZE=32K,SYSCYL=,
SYSPGNM=(496-503) ,VSYSRES=,VSYSADR=IGNORE
X
X
INSTVSAM NAMESYS SYSNAME=INSTVSAM,SYSVOL=VMRELn,SYSCYL=,
SYSSTRT=(006,2),SYSPGCT=8,SYSSIZE=32K,SYSHRSG=(254),
SYSPGNM=(4064-4071) ,VSYSRES=,VSYSADR=IGNORE
END
X
X
X
The DMKSNT module supplied for the 3340 starter system is:
CM~
Na~ESYS
SYSSIZF=256KjSYSN!~!=C~S,
X
VSYSADR=190,SYSVOL=VMRELn,SYSCYL=040,SYSSTRT=(OOl,1),
SYSPGCT=33,SYSPGNM=(O-32),SYSHRSG=(1),VSYSRES=CPRnLO
X
CMSSEG
NAMESYS SYSNAME=CMSSEG,SYSVOL=VMRELn,SYSCYL=,
SYSSTRT=(002,11),SYSPGCT=16,SYSHRSG=(16),
SYSPGNM=(256-271) ,SYSSIZE=64K,VSYSRES=,VSYSADR=IGNORE
X
X
CMSVSAM
NAMESYS SYSNAKE=CKSVSAM,SYSVOL=VKRELn,SYSPGNM=(272-367),
SYSSTRT=(003,04),SYSPGCT=96,SYSSIZE=384K,SYSCYL=,
SYSHRSG=(17,18,19,20,21),VSYSRES=,VSYSADR=IGNORE
X
X
CKSAMS
NAMESYS SYSNAKE=CMSAMS,SYSVOL=VKRELn,SYSPGNM=(368-495),
SYSSTRT=(007,5),SYSPGCT=128,SYSSIZE=448K,SYSCYL=,
SYSHRSG=(23,24,25,26,27,28),VSYSRES=,VSYSADR=IGNORE
X
X
CMSDOS
NAMESYS SYSNAME=CMSDOS,SYSVOL=VMRELn,SYSHRSG=(31),
SYSSTRT=(012,14),SYSPGCT=8,SYSSIZE=32K,SYSCYL=,
SYSPGNM=(496-503),VSYSRES=,VSYSADR=IGNORE
X
X
INSTVSAM NA"ESYS SYSNAKE=INSTVSAM,SYSVOL=VMRELn,SYSCYL=,
SYSSTRT=(012,23},SYSPGCT=8,SYSSIZE=32K,SYSHRSG=(254),
SYSPGNM=(4064-4071},VSYSRES=,VSYSADR=IGNORE
END
X
X
The DKKSNT module supplied for the 3350 Starter System is:
DMKSNTBL CSECT
CMS
NAMESYS SYSSIZE=256K,SYSNAME=CMS,
VSYSADR=190,SYSVOL=VMRELn,SYSCYL=021,
SYSSTRT= (OOl,l) ,S YSPGCT=33, SYSPGNM= (0-32) , SYSHRSG= (lJ,
VSYSRES=CPRnLO
X
X
X
CKSSEG
NAMESYS SYSNAME=CMSSEG,SYSVOL=VMRELn,SYSCYL=,
SYSSTRT=(001,35),SYSPGCT=16,SYSHRSG=(16),
SYSPGNM=(256-271} ,SYSSIZE=64K,VSYSRES=,VSYSADR=IGNORE
X
X
CMSVSAM
NAMESYS SYSNAKE=CMSVSAM,SYSVOL=VMRELn,SYSPGNM=(272-367),
SYSSTRT=(OOl,52),SYSPGCT=96,SYSSIZE=384K,SYSCYL=,
SYSHRSG=(17,18,19,20,21},VSYSRES=,VSYSADR=IGNORE
X
X
CMSAMS
NAMESYS SYSNAME=CMSAMS,SYSVOL=VMRELn,SYSPGNM=(368-495),
SYSSTRT=(002,29),SYSPGCT=128,SYSSIZE=448K,SYSCYL=,
SYSHRSG=(23,24,25,26,27,28),VSYSRES=,VSYSADR=IGNORE
X
X
218
IBM V8/370 Planning and System Generation Guide
Pag€ of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
System Name Table File
CMSDOS
NAMESYS SYSNAME=CMSDOS,SYSVOL=VMRELn,SYSHRSG=(31),
SYSSTRT=(003,038) ,SYSPGCT=8,SYSSIZE=32K,SYSCYL=,
SYSPGNM=(496-503) ,VSYSRES=,VSYSADR=IGNORE
X
X
INSTVSAH
NAHESYS SYSNAME=INSTVSAM,SYSVOL=VMRELn,SYSCYL=,
SYSSTRT=(003,47),SYSPGCT=8,SYSSIZE=32K,SYSHRSG=(254),
SYSPGNM=(4064-4071) ,VSYSRES=,VSYSADR=IGNORE
END
X
X
The supplied DMKSNT modules each have six entries: entries for saving
copies of CMS, CMSSEG, CMSVSAM, CMSAMS, CMSDOS, and INSTVSAM, if you use
all the recommended labels and allocations and the starter system
supplied DMKSYS when you follow the system generation procedure.
(The
INSTVSAM segment is a CMSDOS segment that is used only during the
procedure for loading and saving CMSVSAM and CMSAMS segments.
For an
explanation of this procedure, see the section "Loading and Saving
Discontiguous Saved Segments" in Part 3.)
For an illustration of the storage layout resulting from this sample
configuration of discontiguous saved segments, see Figure 31.
The supplied DMKSNT assumes a DOS/VS Release 34 starter system is
being used.
If you are using a DOS/iS Release 33 starter system, or
earlier, to generate CMSVSAM, and/or CMSAMS, you must change the DMKSNT
file.
The CMSVSAM segment generated with these starter systems requires
five shared segments and one nonshared segment.
The CMSAMS segment
generated with these starter systems requires 6 shared segments and 2
nonshared segments.
If you wish to change or add to the system name table that is
supplied, you must code your own macro and create a DMKSNT file of your
own. Note that one entry can be created for each type of discontiguous
segment.
For example, in addition to a CMSSEG entry, you could code an
alternate entry, CMSSEG1, for testing purposes.
The system generation procedure tells you when to assemble your own
file.
If the supplied DMKSNT module meets your installation's needs~
you need not code or assemble the DMKSNT module.
If you do create your own version of the system name table, your file
must have a CSECT and END statement:
DMKSNTBL eSRCT
NAMESYS
macros (one for each virtual machine operating
system or segment you wish to save)
NAMENCP macros (one for each 3704/3705 control proqram
you create)
NAME3800 macros (one for each 3800 named system you create)
END
Note that the loader automatically inserts a PUNCH SPB
(Set Page
Boundary) card, to force this module to a 4K boundary when the CP system
is built.
Also, DMKSNT is a pageable module which should not exceed the
size 4K.
DMKSNT should be made resident if its size is greater than 4K.
Information about coding the NAMESYS and NAMENCP macros follows.
Part 2. Defining Your VM/370 System
219
Apr i l l , 198 1
NAMESYS Macro
Coding the NAMESYS Macro
The NAMESYS macro describes the name and location of the saved system or
discontiguous saved segment.
Shared segments may be specified, but they
must consist of reenterable code, with no alteration of its storage
space per mit ted.
The format of the NAMESYS macro is:
label
NAMESYS
SYSSIZE=nnnK,SYSNAME=name,(VSYSRES=cccccc,]
VSYSAtR=[CUU
],SYSVOL=CCCCCC,[SYSCYL=nnn,]
IGNORE
SYSSTRT=(cc,p) ,rSYSPGCT=pppp,]
SYSPGNM=(nn,nn,nn-nn, ••• ),
S YS HRS G= (s , s , ••• ) ,
PROTFC~={~iF}
label
is any desired user label.
SYSSIZE=nnnK
is up to 3 decimal digits representing the minimum amount of
storage you must have available in order to IPL the saved
system. K must be specified. Although you must code this
operand for discontiguous saved segments, it is not used for
them.
SYSNAME=name
given to the
is the name
(up to 8 alphameric characters)
system or segment to be used for identification by the SAVESYS
The name selected must not be one that
and/or IPL commands.
could be interpreted as a hexadecimal device address (for
example, A or E).
VSYSRES=cccccc
is the real volume serial
number (up to 6 alphameric
characters) of the DASD volume containing the minidisk that is
the system residence volume of the system to be saved. This
operand is ignored if VSYSADR=IGNORE,
but you must specify it
as null (VSYSRES=,).
VSYSADR=cuu
is the virtual address of the minidisk that
residence volume of the system to be saved.
is the
system
VSYSADR=IGNORE
indicates that the NAMESYS macro is describing a system or
segment that does not require a virtual system residence
volume.
Code
VSYSADR=IGNORE when
you are
defining a
discontiguous saved segment.
SYSVOL=cccccc
is the volume serial number (up to 6 alphameric characters)
the DASD volume designated to receive the saved system
segment. This must be a CP-owned volume.
220
IBM VM/370 Planning and System Generation Guide
of
or
April 1, 1981
NAl!ESYS Macro
SYSCYL=nnn
is the real starting cylinder of the minidisk (specified by
VSYSRES and VSYSADR) that is the system residence volume of
the system to
be saved.
This operand
is ignored if
VSYSADR=IGNORE, but you must specify it as null (SYSCYL=,).
SYSSTRT= (cc,p)
designates the starting cylinder (cc)
and page address (p) on
SYSVOL at which this named system is to be saved. During the
SAVESYS and IPL command processinq, this is used to generate
the "cylinder
page and device"
address for
the DASD
operations. These numbers are specified in decimal.
The number of pages written to this area is the total number
specified via the SYSPGNM operand, plus one information page.
SYSPGCT=pppp
is the total number of pages (pppp)
to be saved (that is, the
total number of pages you indicate via the SYSPGNM operand).
This is a decimal number, up to four digits.
The SYSPGCT
operand is optional; if you do not specify it,
the NAMESYS
macro will calculate the number of pages to be saved.
SYSPGNM=(nn,nn,nn-nn, ••• )
are the numbers of the pages to be saved. Pages may be
specified singly or in groups. For example: if pages 0, 4, and
10
through
13 are
to
be
saved, use
the
format:
SYSPGNM=(0,4,10-13). The total must be equal to the SVSPGCT
specification.
SYSHRSG=(s,s, ••• )
are the segment numbers designated as shared (numbered from
zero up, with the first segment, for example, specified as 0).
The pages in these segments are set up at IPL time to be used
by any user loading by this name.
All segments to be shared
must be reenterable.
The maximum number of shared segments
that can be defined is 78.
PROTECT= {g;F}
indicates that VM/370 is to run either with protected (ON) or
unprotected
(OFF) shared segments for the particular llQill~U
system. ON is the default.
If a named system is specified as
unprotected, any changes made to shared pages in the named
system will not be detected by the VM/370 control program; the
change will be seen by all users of the shared page.
The number of 4K pages available per DASD cylinder is:
pag~§L~yling~
24
32
57
120
Information on the
Guige:
12!SD !Y~
3340-35, 3340-70, 2305
2314, 2319
3330, 3333
3350 (in native mode)
following
subjects is
in
the
Y~LllQ
~!~~
prQ9£amm~r~§
•
•
•
•
•
•
Determining when to save a system
Using the SAVESYS command
saving the CMS system
Saved system restrictions for CMS
Saving os
Usinq discontiguous saved segments (CMSDOS, CMSSEG, CMSVSAM, CMSAMS)
Part 2. Defining Your VM/370 System
221
ra.y~
V.I..
\:J~~V-IUVI-IV
11;:)
Up\.la.I...~\.1
I1IJ.I....L..L
I,
I~OI
J..J]
J.l'1J..
\:Jl'f~~-VO~I
NA HENCP Macro
Coding the NAMENCP Macro
You must create an entry in the system name table (DMKSNT)
for each
unique 3704/3705 control program that you generate.
If you can foresee
generating several versions of the 3704/3705 control program, define
extra entries in the system name table when you generate VM/370. In
this way, you do not have to regenerate the VM/370 system just to update
the system name table.
Use the
NAHENCP macro to define 3704/3705 program
system name table. The format of the NAMENCP macro is:
entries in
the
r---------------------------------------------------------------------------~
I label
I
I
I
I
I
NAMENCP
CPSIZE=nnnK,
CPNAHE=ncpname,
CPTYPE= {EP J
SYSPGCT=pp,
SYSV01=volser,
SYSSTRT= (ccc, p)
L
label
is any desired user label.
CPSIZE=nnn K
is the storage size of the 3704/3705 specified during the
3704/3705 control program generation.
A maximum of 256K
can be specified.
CPNAME=ncpname is the name of the 3704/3705 control program image. This
name is used in the SAVENCP and NETWORK LOAD commands.
The name must be from one to eight alphameric characters.
CPTYPE={EP
is the 3704/3705 control program type.
SYSPGCT=pp
is the total number of pages (pp) to be saved.
This
decimal value may be equal to the number of pages implied
by the CPSIZE operand plus four pages for control
information, but it must not exceed that total.
SYSV01=volser
is the volume serial number (volser) of the DASD volume
designated to receive the control program image. That
volume must be a CP-owned volume.
SY SST RT= (ccc, p)
is the starting cylinder (ccc)
and page address (p) on
SYSV01 at which this image is to be saved. These numbers
must be specified in decimal.
222
IBM VM/370 Planning and system Generation Guide
page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
NArtE3800 rtacro
Coding the NAME3800 Macro
The NAME3800 macro describes the name and location of the named system
that will contain the 3800 character arrangement tables, graphic
modifications, FCBs, and copy modifications for the 3800 printers.
Multiple named systems may be specified. The 3800's RDEVBLOK contains a
pointer to the named system currently in use for that particular 3800.
The format of the NAME3800 macro is:
r-'----------------------------------------------------------------------~
I label
I
I
I
NAME3800
C P NAIi I= 1 i tn am e,
SYSPGCT=pp,
SYSVOL=volser,
SYSSTRT= (ccc ,p)
~---------------------------------------------------------------------------~
where:
label
is any desired user label.
CPNAME=libname is the name of the 3800 image library. This name is used
in the IMAGELIB command. The name must be from one to
eight alphameric characters.
SYSPGCT=pp
SYSVOL=volser
is the total number of pages (pp)
to be saved for the
image library. This value is a decimal number up to two
digits.
To determine the number of pages to be saved,
use the following steps:
1.
The image library contains
several core image
members. Find the size of each core image member
that was created by GENIMAGE;
bytes seven and eight
of the core image contain the member's size in
bytes. Add eight bytes to each member's size.
2.
Sum the sizes and add 16 bytes to the total.
3.
Divide the total by 4096 bytes to achieve the page
count (pp). Be sure to round up to the next whole
page.
is the volume serial number (volser) of the DASD volume
designated to receive the 3800 image library. The volume
must be a CP-owned volume.
SYSSTRT=(ccc,p)
is the starting cylinder (ccc)
and page address (p) on
SYSVOL at which this image library is to be saved. These
numbers must be specified in decimal.
Part 2. Defining Your Vrt/370 System
223
a
~J. ~~
I,
I
~
0
,
Forms Control Buffer Load
Altering the Forms Control Buffer Load
(DMKFCB)
The DMKFCB module is supplied with the starter system. This module
defines a 3211 forms control buffer image with 6 lines per inch, 66
lines per page and the following channel skip specifications:
Line
Rep£gsenl,gg
Channel
Skip
Speci fjcat ion
1
1
3
2
5
7
3
4
9
5
11
6
7
13
15
19
8
10
21
23
12
64
9
11
If you wish to alter the supplied
Guide for directions.
buffer load, see the
Progra~~£~§
224
IBM VM/370 Planning and System Generation Guide
!~L170
SYS1,gID
Part 3. Generating VM/370 (CP, CMS, RSCS,
and I PCS)
Part 3 describes the step-by-step generation procedures for CP, eMS,
RSCS, and IPCS; the Installation Verification Procedure (lVP) for CP and
CMS; and the procedures for loading and saving discontiguous saved
segments. It contains the following sections:
•
Introduction
•
Generating CP and CMS Using the. Starter Systems
•
Verifying CP and CMS Using the IVP
•
Loading and Saving Discontiguous Saved Segments
•
Generating and Installing RSCS
•
Generating and Installing IPCS
Part 3. Generating VM/370
(CP, CMS, RSCS, and IPCS)
225
226
IBM VM/370
Plannir.~
and System Generation Guide
Introduction
Before you start
available:
to install
V~/370,
be
sure you
have the
•
Two real disk drives
•
At least one real tape drive (the
simpler if you use two tape drives)
•
Two scratch disks (one is used for the starter system
is used for the new system residence volume)
•
The starter system tape
•
The system Program Update Tape (PUT)
•
At least one scratch tape
system
following
generation process
is
and the other
The system generation procedures described in this manual refer to
related publications. These publications are listed in the Preface.
The following procedures for installing CP and
•
•
•
•
2314
3330
3340
3350
starter
starter
starter
starter
C~S
are described:
system
system
system
system
From these starter systems you can generate a V~/370 system for
residence on a 2305, 2314, 3330,3340, or 3350.
(It is recommended,
however, that 2305 devices be used for paging rather than for system
residence; therefore the 2305 is not included in the system generation
procedures. )
An
~SS
3330V volume may not be used for system residence.
You can then load and save
installation may wish to usee
the
C~S
discontiguous saved segments your
Following the procedures for installing CP and CMS are the procedures
for installing the optional
RSCS
(Remote Spooling Communications
Subsystem) component of the V~/370 SCP.
In addition, the information you need to install the 3704/3705
control program is found in "Part 4. Generating the 3704/3705 Control
Program. "
Part 3. Generating
V~/370
(CP,
C~S,
RSCS, and IPCS)
227
General Information
General Information
CP and C"S have separate system residence disks which may be located on
the same or different physical disks. The following procedure tells you
how to generate the CP system residence disk or move the CMS system
residence disk.
Before you attempt to generate a VK/370 system, make
sure that the real I/O configuration file (DKKRIO), CP system control
file (DKKSYS), the VK/370 Directory file (DKKDIR), and, optionally, the
forms control buffer load
(DMKFCB) and the system name table file
(DKKSNT) are punched.
Information about preparing these files is in
"Part 2: Defining Your VM/370 System." If CMS is to be sa ved as a named
system, be sure that the NAKESYS macro is coded correctly in the DKKSNT
file.
The VK/370 starter system is distributed on a 9-track tape (1600 or
6250 bpi), that can be restored to direct access volumes.
You must
specify the device type (2314/2319, 3330, 3340, or 3350) when you order
VK/370. The 3340 starter system fits on a 35 megabyte disk, so it can
hp re~+orp~ to ~nv mn~pl of thp
33UO Qr 33UU~ft@~ the starter svstem
h~s b~~~-'~~st~r~d" t~· th; p~rti~ula~ type ~f devi~~ (2314, 3330; 3340, or
3350) it was ordered for, you can use it to generate a VK/370 system for
residence on any other type of device as well as for the type of device
for which it was ordered. You should also specify the tape density
required (1600 or 6250 bpi).
The layout of the starter system's minidisk areas are constrained by
the number of cylinders that may be dumped onto one volume of 1600 bpi
tape. Therefore, it is strongly recommended that KlINT's 190 (the CKS
system disk) and 194 (the CP area) be reproduced on larger minidisks for
ease of maintenance.
Also, "service staging areas" for CP/RSCS and
CKS/IPCS (294 and 193 respectively), must be created to receive the
auxiliary files and "update" files from the system PUT. This process is
detailed later in this publication under the heading "Updating Vft/370"
and in the Kemo-to-Users that is contained on the system PUT.
The VK/370 system tapes are as follows:
•
The V"/370 starter system contains the base level of both the CP and
CKS systems, the text decks with which to build these systems, and
the maclib and support procedures.
•
The SOURCE tape contains all source files, and macros of VK/370.
•
The system Program Update Tape (PUT)
contains all source updates,
text decks, modules, macros and macro libraries, and procedures
required to build the latest level of CP, CKS, RSCS, and IPCS.
•
The SOURCE tape and the system
the V"FPLC2 command.
PUT are created (and
restored)
with
text, modules,
and
Five optional sets of tapes can also be ordered:
•
The assembler tape containing source,
procedures for the assembler
•
CP
•
CP (AP) assembly listings (two tapes)
•
CKS assembly listings (two tapes)
•
IPCS and RSCS assembly listings (one tape)
228
(U~
macros,
assembly listings (three tapes)
IBK VK/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0831
General Information
Generating CP and CMS Using the Starter
Systems
Except where otherwise noted, you can sUbstitute other values in place
of the device addresses, volume labels, and allocations shown. Note
that if you use the sample DMKSNT and DMKSYS files provided with the
starter system, and the sample allocations shown in Steps 2 and 3, you
can save your CMS system at the end of the procedure.
It is g~rong1y recommended that you use the sample allocations given
in Step 2 and the label VMRELn for the new system residence volume, to
ensure that you have sufficient TEMP space to complete the system
generation.
(The TEMP space provided on the starter system volume may
not be sufficient for large systems.)
The examples of messages and responses assume that you are performing
the system generation at a typewriter terminal, such as a 3210, 2141, or
3767 (operating as a 2141). If you are using a
display device, such as
the 3277, when you type the response to a prompting message, that
response appears in the user input area. When you enter that response,
it is redisplayed in the output area on the line below the prompting
message. Also, if the standalone service programs (such as the DASD Dump
Restore program or Format/Allocate program)
send output to a terminal
display screen, the output is wrapped around immediately, when the
screen becomes full, to continue displaying.
While you are generating the system, you may see some extraneous
messages as the starter system is processing.
These are not shown in
the examples below.
Only those messages that you should take note of,
or respond to, are shown.
Step 1. load the Format Program from the Starter
System Tape
Mount the
CP starter system tape
and IPL the tape.
The CP
Format/Allocate service program is the first file on the tape; it is now
loaded.
Do not rewind the tape because the next file is needed later in
the system generation procedure (Step 4).
Step 2. Format, label, and Allocate the System
Residence Volume
Use the CP Format/Allocate program to format, label, and allocate space
on the new system residence volume.
This label must be VKRELn; where n
is the release level of the VM/370 System control program.
VMRELn is
used in the starter system's system control file - SYSOWN marco - to
allow the volume to be used for paging, spooling, and TDSK allocations.
First, identify the system console by pressing the Request key (or
equivalent); if the console address is either 009 or 01F, you do not
have to press the Request key. Then, to execute the Format/Allocate
service program, respond to the prompting messages.
Part 3. Generating VM/370 (CP, CMS, RSCS, and IPCS)
229
t'Clyt::
V.L
U\...L;V- lOV , - IV
A~
vpucn:t:!u
Apr~l.
I,
I!lO I
DY
TNL
l:jN~:>-Utj.,j
I
Starter Systems
In the followinq example, the responses (format, 131,
device type,
000, end cylinder, and VMRELn) format the real disk at address 131 and
label it VMRELn.
The label you specify must match what you specified in
the SYSVOL operand of the SYSRES macro statement when you defined the
system in your DMKSYS module.
In any case, do not use CPRnLO because
that is the label of the starter system disk.
The console output looks
like:
VM/370 FORMAT/ALLOCATE PROGRAM RELEASE n
ENTER FORMAT OR ALLOCATE:format
FORMAT FUNCTION SELECTED
ENTER DEVICE ADDRESS (CCU):131
ENTER DEVICE TYPE:device type 1
ENTER START CYLINDER (XXX) OR "LABEL":OOO
ENTER END CYLINDER (XXX) :end cylinder 1
ENTER DEVICE LABEL:VMRELn2
FORMAT STARTED
FORMAT DONE
000 NO. PAGE RECORDS WITH READ-CHECK ERRORS
Whe~
the
for~at
cperation completes, the prompting massage
ENTER FORMAT OR ALLOCATE:
is displayed.
Now that the system residence volume is formatted and
labeled, you must allocate the disk space.
Again, you must respond to
the promptinq messages.
In the following example, the space on the
various device types at address 131,
with the label VMRELn, are
indicated.
You can use the formulas given in the "Creating Your VM/370
Directory" section of Part 2 to ensure enough space is allocated for
your VH/370 directory.
If you do not allocate your DASD space as shown
in this example, you are responsible for ensuring that you have enough
TDSK space to perform the assemblies associated with VM/370 system
generation.
ENTER FORMAT OR ALLOCATE:allocate
ALLOCATE FUNCTION SELECTED
ENTER DEVICE ADDRESS (CCU):131
ENTER DEVICE TYPE:device type
ENTER DEVICE LABEL:VMRELn
ENTER ALLOCATION DATA FOR VOLUME VMRELn
TYPE CYL CYL
... ...
111!
perm 000
drct 020
temp 024
perm 101
temp 103
tdsk 181
perm3
end
019
023
100
102
180
202
33.JQ
000
013
017
202
203
390
403
012
016
201
202
389
402
807
3340
000 023
024 027
028 173
174 176
177 310
311 346
347 697
33~Q
000
009
013
277
278
400
008
012
276
277
399
554
1The specifiable device types and their respective "end cylinders" are:
2314 is 202, 2319 is 202, 3330 is 403, 3330-11 is 807, 3340-35 is 347,
3340-70 is 697, 3350 is 554, 2305-1 is 47 and 2305-2 is 95.
2VMRELn must be VMREL4,
VMREL5, or VMREL6, depending on the release
level of the VM/370 SCP.
3This line gives the required specifications for the 3330 Model 11 and
the 3340 Model 70.
230
IBM VM/370 Planning and System Generation Guide
starter Systems
ALLOCATION RESULTS
PERM
DRCT
TEMP
PERM
TEMP
TDSK
PERM
l.Jll
000
020
024
101
103
181
019
023
100
102
180
202
3330
000 012
013 016
011 201
202 202
203 389
390 402
403 807
J140
000 023
024 021
113
028
114 176
111 310
311 346
347 697
112Q
000
009
013
277
218
400
008
012
216
217
399__
554
DEVICE 131 VOLUME VMRELn ALLOCATION ENDED
ENTER FORMAT OR ALLOCATE:
Step 3. Label the Starter System Volume
Use the Format/Allocate program to label the scratch volume that is to
contain the CP starter system.
This label must be CPRnLO.
You can
format and label this volume, or just label it.
Formatting is
unnecessary (unless the pack has never been initialized before) because
you are going to restore the starter system to this volume.
If you get
an I/O error trying to label the pack, format only cylinder zero and
then try to label the pack again.
In the following example, the
responses (format, 130, device type, label, and CPRnLO) to the prompting
messages put the label CPRnLO on the real disk at address 130.
ENTER FORMAT OR ALLOCATE: format
FORMAT FUNCTION SELECTED
ENTER DEVICE ADDRESS (CCU):130
ENTER DEVICE TYPE:device type
ENTER START CYLINDER (XXX) OR "LABEL": label
ENTER DEVICE LABEL: CPRnLO
LABEL IS NOW CPRnLO
When the Format/Allocate program is complete, it responds:
ENTER FORMAT OR ALLOCATE:
You need not respond to this message.
to CP mode.
Press the PAl key twice to return
Now the starter system volume is available and ready for the data
that is to be placed on it by the DASD Dump Restore service program
(module DMKDDR). The DASD Dump Restore program is the second file on the
starter system tape.
Step 4. Load the DASD Dump Restore Program from
the Starter System Tape
IPL the starter system tape a second time to load the DASD Dump Restore
(DDR) program. It is the second file on the starter system tape.
Do
not rewind the tape, because the next file is needed in Step 5.
Step 5. Restore the Starter System to Disk
Respond to the DDR prompting messages to restore the starter system.
Part 3. Generating VM/370
(CP, CMS, RSCS, and IPCS)
231
starter Syste ms
In the following example, the starter system is restored from the
2400 series tape drive at address 280 to the real disk at address 130
(and with label CPRnLO). The console output is:
VM/370 DASD DUMP/RESTORE PROGRAM RELEASE n
ENTER CARD READER ADDRESS OR CONTROL STATEMENTS
ENTER: sysprint cuu (cuu=real printer address)
ENTER: input 280 2400
ENTER: output 130 device type CPRnLO
ENTER: restore all
RESTORING CPRnLO
END OF RESTORE
ENTER: (null line -- END key on 3215 o~ Enter key on 3277)
END OF JOB
The DDR program restores the third file on the starter system tape to
the disk labeled CPRnLO. The restored disk contains:
•
A 191 minidisk for the userid CPGEN, which contains a sample VM/370
directory (RELEASEn DIRECT), as well as sample source for DMKSYS,
DMKSNT, and DMKFCB
•
A VM/370 starter system nucleus
•
A complete CMS system residence volume
•
A complete CP system containing macro libraries and text files
continue with the system generation
When the disk is restored,
procedure. The format of the restored disk is shown in Figures 22, 23,
24, and 25.
r------------------------------------------------------------------------~,
I
Real
I Cylinder
I
I
0
1
I
Number of
Cylinders
contents
VM/370 directory
191 minidisk for the IVPM1 user
1----------------I
2
191 minidisk for the IVPM2 user
1-------------------------------------------------------------------CP nucleus
4
1
3-6
1
1
I
,
8-9
I
1
10
,
1
I
1
I
I
1
Warm start data
7
2
Spool file checkpoint
11-33
22
Spooling and paging space
191 minidisk for the CPGEN user
34
135
35-169
1
190 minidisk (the eMS system disk) for the
CMSSYS user
The nucleus occupies
cylinders of the minidisk.
!Qi~:
1
I
1------I
1
I/O Error Recording area
170-202
33
232
last
two
194 minidisk of the CPGEN user - it contains
the CP object modules (text decks)
L
Figure 22.
the
Format of a 2314 Restored Disk
IBM VM/370 Planning and System Generation Guide
Starter Systems
r
I
Real
I cylinder
,
,
Number of
Cylinders
0
Contents
VM/370 directory
I
I
I
,
I
I
3-5
3
CP nucleus
I
I
7-8
2
I/O Error Recording area
I
I
10-28
19
191 minidisk for the IVPM1 user
2
191 minidisk for the
IVP~2
user
1--------------------------------------------------------------------Warm start data
1
6
1---------------------------------------------------------------------,
9
Spool file checkpoint
Spooling and paging space
I------------------------------------------------------------~---------
I
I
,
I
I
,,
I
,I
I
,
191 minidisk for the CPGEN user
29
30-114
85
190 minidisk (the CMS system disk) for the
C~SSYS user
!Qte: The nucleus occupies
cylinder of the minidisk.
115-141
27
142-403
262
the
last
194 minidisk of the CPGEN user - it contains
the CP object modules (text decks)
Not used.
L
Figure 23.
Format of a 3330 Restored Disk
Part 3. Generating Vf!/370 (CP, CMS, RSCS, and IPCS)
233
Starter Systems
r
1
Real
I cylinder
1
I
0
Number of
Cylinders
contents
VM/310 directory
1------------·-----------------------------------------------------------191 minidisk for the IVPM1 user
2
1
1-2
1----------------------------------------------------------------------------------,
3-4
2
191 minidisk for the IVPM2 user
1
1
1
I
5-10
6
Warm start data
11
12-13
CP nucleus
2
I/O Error Recording area
Spool file recovery
14
15-45
31
46-47
2
Spooling and paging space
i91
~iuidiBk
fOi
Lh~
CPGEN
tiSei
48-281
240
190 minidisk (the CMS system disk) for the
CMSSYS user
No!~: The' nucleus
occupies the last two
cylinders of the minidisk.
28A-341
60
194 minidisk of the CPGEN user - it contains
the CP object modules (text deck~
I
1 !ote: Cylinders 348-695 are not used when the starter system is
1 restored to a 3340 Model 10.
L
Figure 24.
234
Format of a 3340 Restored Disk
IBM VM/310 Planning and System Generation Guide
Apr il 1, 1981
Starter Systems
r
Real
I
I Cylinder
I
0
I
I
1
I
Number of
Cylinders
contents
1
VM/370 directory
1
191 minidisk for the IVPK1 user
2
1
191 minidisk for the IVPM2 user
,
3-4
2
CP nucleus
I
I
I
I
5
1
Warm start data
6-7
2
I/O Error Recording area
8
1
Spool file checkpoint
,
I
I
I
,,
,
I
I
9-19
20
21-55
11
1
35
Spooling and paging space
191 minidisk for the CPGEN user
190 minidisk (the CMS system disk)
CMSSYS user
No!~:
The nucleus occupies
cylinder of the minidisk.
56-64
65-554
Fiqure 25.
9
490
for the
the
last
194 minidisk of the CPGEN user - it contains
the CP object modules (text deck~
Not used.
Format of a 3350 Restored Disk
CPGEN, CMSSYS, IVPM1, and IVPM2 are user identifications
certain minidisks on the starter system volume.
that own
CPGEN is the userid of the operator (that is, you use this userid to
control the real system and to build a version of CP tailored to your
installation) •
CMSSYS is a directory entry on the starter system volume
CMSSYS 190 (the eMS system disk). CPGEN has a read-only link
190 in order to use it to create the new system. Using this
CPGEN user can read from, but not write on, the 190 minidisk
to the CMSSYS user.
that owns
to CMSSYS
link, the
belonging
IVPM1 and IVPM2 are used with the Installation Verification Procedure
to test the new system.
Part 3. Generating VM/370 (CP, CMS, RSCS, and IPCS)
235
Starter Systems
Step 6. IPL the Starter System
Load (IPL) the starter system from the disk you restored it to. In our
example the address is 130.
At this point, only the device containing
the system residence volume, 130, is known to the starter system.
Remember, if you have control units that share more than 16 devices
and are also switchable to another processor,
the channel interface
enable switch from the other processor should be in the disable position
while you perform the system generation.
Step 7. Define the Devices Needed To Do the
System Generation
If your system console is at an address other than 009 or 01F, after you
load the starter system you must press the Request key (or equivalent
key) to enable the starter system to recognize the system console. If
the console is not recognized, the V~/370 starter systew enters a
disabled wait state with code X'27' in the PSi.
Note: Either an unrecoveratle I/O error occurred or the system input was
incorrect.
Determine the cause of the problem and correct it; then
reload the starter system.
At this point both the system residence volume and system console are
recoqnized by the starter system and you can define the other devices
you need.
The starter system supports up to
16 channels,
8 control
units, and 16 devices. The real control blocks for these devices are not
built in the
standard manner;
the starter
system builds them
dynamically.
The starter system program (D~KSSP) then prompts you to answer the
followinq guest ions until all the real control blocks necessary to
operate a m1n1mum machine configuration are created. The following
example assumes: a 1403 printer at address OOE, a 2540 card reader/punch
at addresses OOC (reader) and OOD (punch), tape drives at addresses 280
and 281,
and a DASD device appropriate for the new system residence
volume at address 131.
The messages you receive at this time are:
VM/370 STARiER SYSTEM RElEASE n
ENTER PRINTER ADDRESS (CUU):OOe
ENTER DEVICE TYPE (1403,1443,3203,3211,3800) :1403
ENTER PUNCH ADDRESS (CUU):OOd
ENTER DEVICE TYPE(2540P,3525):2540p
ENTER READER ADDRESS (CUU) :OOc
ENTER DEVICE TYPE (2501,2540R,3505) :2540r
ENTER ADDRESS WHERE PIn TAPE IS MOUNTED (CUU) :280
ENTER DEVICE TYPE (2401,2415,2420,3420) :2401
ENTER ADDRESS WHERE SCRATCH TAPE IS MOUNTED (CUU) :281
ENTER DEVICE TYPE (2401,2415,2420,3420) :2401
ENTER DEVICE ADDRESS WHERE SYSTEM RESIDENCE WILL BE BUILT (CUU) :131
ENTER DEVICE TYPE (2319,2314,3330,3340,3350,2305) :device type
***SYSTEM DEFINITION COMPIETED***
OOE
000
DOC
280
281
131
ARE
236
PRINTER
PUNCH
READER
PID TAPE
SCRATCH TAPE
NEW SYSTEM RESIDENCE
THE ABOVE ENTRIES CORRECT (YES, NO) :yes
IBM VM/370 Planning and System Generation Guide
starter Systems
V~/370
VERSION vv LEVEL 00 PLC 0000; mm/dd/yy hh:mm:ss
NOW 08:54:23 EDT FRIDAY mm/dd/yy
CHANGE TOD CLOCK (YESINO):yes
SET DATE ~M/DD/YY :mm/dd/yy
SET TIME HH:MM:SS :09:04:36
PRESS "TOD ENABLE SET" KEY AT DES:JGNATED INSTANT
The TOD clock referred to is the System/370 Time of Day clock. Enter
'th e actual date and time in response to the "SET DATE" and" S ET Tl~E"
messages, and press the TOD Enable Set switch on the system control
panel when the exact time specified agrees with the installation wall
clock.
NOW 09:04:36 EDT FRIDAY mm/dQlyy
CHANGE TOD CLOCK (YESINO):no
09: 04: 38 ST ART «COL DI WARM I CKPT I FORCE)
(ORAl N» (SHUTDOWN) : cold
Some DMKLNKl17E messages appear at this time.
09:04:42 AUTO LOGON
09:04:42
***
They can be ignored.
CPGEN USERS=OOl BY SYSTEM
The following message appears only if your system storage size is
different from that specified in the SYSCOR macrp in the DMKSYS module
supplied with the starter system:
DMKCPI9521 nnnnK SYSTEM STORAGE
The following informational message provides a storage allocation map
of CP:
D~KCPI9571
STOR sssssK, NUC nnnK, DIN dddddK, TRA tttK, FREE ffffK,
V=R vvvvvK
If you have not defined your system residence volume with a label of
VMRELn messages are issued indicating that the volume labeled VMRELn is
not mounted. If you have labeled it as VMRELn, some messages indicating
VMRELn conflicts are issued. These are caused by the MDISK statements
for the various supported system residence devices in the starter
system's directory. Iou can ignore them and the following message.
OQ:04:43 FILES:
NO RDR,
NO PRT,
NO PUN
Part 3. Generating VM/370
(CP, CMS, RSCS, and IPCS)
237
Starter Systems
Step 8. Set the Terminal Mode and Spool the
Console
If the system console you are us~ng is a display device, you should at
this point spool your console output so that you have a record of what
you do. To spool the console input and output, issue the command:
spool console start
to save a copy of the system generation.
Because the default terminal environment for the
operator is CP, you should also issue the command:
primary
system
terminal mode vm
The virtual machine terminal mode lets you remain in the CMS environment
when you enter data on the display device.
Step 9. Define or Attach the System Residence
Device
The CPGEN virtual machine assumes that the system residence volume is
labeled VMRELn, and that it is a device type like that of the starter
system volume and resides at virtual address 350.
Device types unlike
that of tbe starter system reside at virtual address 351, 352, and 353.
If you labeled your system residence volume VMRELn in Step 2, your
system residence device is already available; now you, as the operator
of CPGEN, must define it. Use Procedure 1 to define it.
To see which virtual
volume, issue:
device was
defined as
your system
residence
query virtual dasd
No1~ If
you are using a 3330 device for your new system residence
volume, it will appear to CPGEN to have 808 cylinders. Users of 3330
Model 1 devices can ignore this.
Users of 3330 Model 11 devices should
be aware that this permits them to use any part of the volume for system
residence.
If you did not label your system residence device VMRELn,
you must
now attach it to your virtual machine, CPGEN. Use Procedure 2 to attach
your system residence device.
For example, if you used the values shown in Step 7, you designated
the 131 drive, labeled VMRELn, as your system residence device. You
must ~efine your virtual device 350 so that it corresponds to the real
disk 131.
Use one of the following procedures to define or
residence volume:
•
attach your system
Procedure 1
If you are creating a system residence with label VMRELn,
see the
following table to determine which virtual device must be defined as
131.
238
IBM VM/370 Planning and System Generation Guide
Starter Systems
Enter the following command:
define nnn as 131
Where nnn is 350, 351, 352, or 353.
•
Starter
System
Device
Type
System Residence Device Type
2314
2314
3330
3340
3350
350
351
352
3.53
3330
351
350
352
353
33LJO
351
352
350
3~"l
J....,
3350
351
352
353
350
Procedure 2
If you did not label your system residence volume as VMRELn, you must
attach the volume to your virtual machine now. Enter:
attach 131 to cpgen as 131
Note: The first device address you specify in the ATTACH command is
for the real device; the second device address is for the virtual
device. The real 131 is the system residence volume you formatted in
Step 2. The virtual 131 is the system residence device you defined
in DftKSYS (using the SYSRES macro instruction). The system residence
device was also entered in response to the message:
ENTER DEVICE ADDRESS WHERE SYSTEM RESIDENCE WILL BE BUILT (CUU):
Step 10. Make Other Devices Available
You must attach your tape drives and designate the printer to receive
abnormal termination dumps if they occur. Use the explanation that
follows to decide how to do this. Press the Request key before entering
each command, for example:
attach 280 to cpgen as 181
attach 281 to cpgen as 182
set dump OOe
In the first command, the real tape drive (280) attached must be the
same real address you entered in Step 7 in response to the message:
ENTER ADDRESS WHERE STARTER SYSTEe TAPE IS
~OUNTED
(CUU):
This real device must be attached to CPGEN as 181, because
EXEC procedure (which is used later) expects it to be 181.
system PUT on this tape drive for Step 13.
the VMSERV
Mount your
Part 3. Generating V"/370 (CP, CftS, RSCS, and IPCS)
239
Starter Systems
In the second command, the real tape drive (281) attached must be the
same real address you entered in Step 1 in response to the message:
ENTER ADDRESS WHERE SCRATCH TAPE IS MOUNTED (CUU):
This real device must be attached to CPGEN as 182, because the GENERATE
EXEC procedure (which is used later) expects the scratch tape to be
mounted on 182.
If only one tape drive is available, enter
attach 280 to cpgen as 181
You can define
procedure.
your virtual 181 as
182 later in the
system generation
The address of the real printer, defined in Step
system dumps that occur are directed to that address.
If you vish, you can issue the CP
1, is
OOE.
Any
com~ana:
query virtual all
before and after performing Step 10, to see how
configuration chanqes.
your virtual machine's
Step 11. Load eMS
Load CftS from virtual address 190 by issuing the CP command:
ipl 190 parm seg=null
You are loading a CftS nucleus without a shared segment and can expect
an error message stating that the segment specified is invalid. After
CftS is loaded, a message is displayed on the system console indicating
that CftS has successfully loaded:
CMS VERSION n.n mm/dd/yy hh •••
Press the ENTER key (END key on a
minidisk is accessed as your A-disk.
3215)
so that
the CPGEN
191
Step 12. Define and Format A Temporary Minidisk
In Step 2 you allocated TDSK space on your system residence volume. In
order to be able to assemble files (DMKRIO, DMKSYS, DMKSNT, DMKFCB)
later, you have to define a temporary minidisk. Issue the command:
define txxxx 192 yy
wh ere:
xxxx is the device type of your system residence volume (2314,
3330, 3340, or 3350)
Y1 is:
240
20
11
25
5
if
if
if
if
xxxx
xxxx
xxxx
xxxx
is
is
is
is
2314
3330
3340
3350
IBM 'M/310 Planning and System Generation Guide
Starter Systems
A message displayed
defined:
on
the console,
indicates
the
192 minidisk
is
DEVICE 192 DEFINED
Before any new minidisk area can be used for CMS files, it must be
initialized with the CKS FORKAT command, which formats the area into
fixed-sized blocks. Issue the command:
format 192 d
The CKS FORKAT command prompts you with the following message:
FOR8AT WILL ERASE ALL FILES ON DISK ID(192)1.
DO YOU WISH TO CONTINUE? (YES/NO):
Respond "yes",
C~S
prompts you with:
ENTER DISK LABEL:
tmp192
Enter a one-to-six character
then issues:
alphameric label
for the
minidisk.
CMS
FOR8ATTING DISK D
Inn' {CYLINDERS} FORPIATTED ON ID (192) I
Obtain write access to your CPIS system disk:,
link cmssys 190 190 w write
Step 13. Apply the CP (Control Program) Service
The system PUT that was mounted in Step 10 is a system update service
that can include new functions as well as cumulative system changes for
VK/370.
The latest system PUT contains all new updates, as .ell as all
previous updates since the last VK/310 base release. PID automatically
ships the system PUT to the user location, and the user is responsible
for applying the updates to VPI/310 systems.
The system PUT supplied
with the starter system should be installed as part of the system
qeneration procedure.
Use the 192 TDSK created in Step 12 in place of the CPGEN 191 disk
for the remainder of this procedure (up to the point of loading your new
CP system via IPL).
Issue the following CPIS commands:
**
copy
a = = d
vmfplc2 load
d
**
Part 3. Generating V8/310 (CP, CMS, RSCS, and IPCS)
241
Starter Systems
The system issues the following messages:
LOADING •••••
D11
5749010 06pp3a
5749010
EXEC
D1
V"SERV
EXEC
D1
Vf!lFPLC2 "ODULE
D1
END-OF-FILE OR END-OF-TAPE
R;
Issue the following CftS commands:
access 192 c
release a
vmserv
The V"SERV EXEC maps the system PUT and requests permission to print
the "Memo to Users". Reply 'YES'. V"SERV will then print the memos and
remind you to read the memos prior to installing service. VftSERV exits
after the mewos a~e printed.
After reviewing the "Memo to Users" contained on the system PUT, and
contacting IBK concerning the latest service activity, you can begin the
installation of service to CP by issuing the CftS command:
vmserv nomemo noipl
You will be prompted for various information concerning your system
(including staging area addresses and the products for which you wish to
apply service). You should apply service for the SCP (5149-010). The
address of your CP base staging area is 194.
Reply "yes" to the
question:
IS THIS THE INITIAL SYSGEN OF THIS SYSTE8? (YESINO)
CKS is automatically loaded via ipl when the V8SERV EXEC completes.
The 192 TDSK should be accessed as the A disk with the command:
access 192 a
Step 14. Prepare the Service Programs
Use the GENERATE EXEC procedure to punch the service programs.
the command:
Issue
generate srvcpgm
These service programs are needed for standalone
externally identify the decks and keep them intact.
use;
The programs punched are:
•
•
•
•
DKKFKT
DMKDIR
DMKDDR
IBCDASDI
(a 3-card loader precedes the D8KF8T text deck)
(a 3-card loader precedes the D8KDIR text deck)
(a 3-card loader precedes the D8KDDR text deck)
(the IBCDASDI text deck is loadable)
lWhere pp is the PUT number.
242
IB" V"/370 Planning and System Generation Guide
you
should
starter Systems
The GENERATE EXEC issues the following message:
THE FOLLOWING STANDALONE SERVICE PROGRAMS ARE BEING PUNCHED
** FORMAT - DIRECT - DUMP/RESTORE - IBCDASDI **
PUNCHING
PUNCHING
PUNCHING
PUNCHING
I
•
•
•
IPL
IPL
IPL
IPL
FMT ' ******
DIR ' ******
DDR • ******
IBCDASDI I ******
Each program deck is preceded by a CP userid card and several
separator cards, all of which may be discarded. The format of these
cards is described in the V8L1IQ Operator's Guide. For more information
about the GENERATE EX EC procedure, see "Part 5. Updating V!/310."
Step 15. Print or Punch the Starter System Suppiied
Directory, DMKSNT, DMKSYS, and DMKFCB
After the service programs are punched, the GENERATE EXEC asks
whether you want a copy of the directory printed. Respond "yes."
you
PRINT COpy OF RELEASEn DIRECT? -- RESPOND (YES I NO) : yes
This prints a copy of the directory, as well as copies of the DMKSYS
ASSEMBLE (th~ CP system control file), D!KFCB ASSEMBLE (the forms
control buffer file), and DKKSNT ASSEMBLE (the system name table)
provided with the starter system.
The GENERATE EXEC procedure issues the following message:
A SAMPLE DIRECTORY IS BEING PRINTED TO AID YOU.
IT SHOWS WHERE THE VIRTUAL DISKS ARE LOCATED ON ICPRnLO'
YOU KAY USE THESE KINIDISKS FOR OTHER VIRTUAL MACHINES,
IN PARTICULAR THE CMS SYSTEM DISK (MAINT 190 ) AND
THE CP STAGING AREA DISK ( MAINT 194 )
INCLUDED IN THIS DIRECTORY IS THE USERID: !AINT
WHICH WILL BE USED FOR FUTURE SUPPORT OF THE SYSTEM.
THIS USERID SHOULD BE INCLUDED IN THE DIRECTORY
YOU BUILD FOR YOUR FLOOR USE.
**
CAUTION
**
IF YOU DESTROY USER MAINT'S AREAS, IT WILL BE
NECESSARY TO RE-BUILD THE ENTIRE SYSTEM.
A SAMPLE OF DMKSYS, DMKFCB, AND DMKSNT ASSEMBLE ARE ALSO BEING
PRINTED TO AID YOU. THIS SAMPLE DKKSNT IS BASED ON THE
INFORMATION INCLUDED IN THE SAMPLE DMKSYS AS WELL AS THE
EXAMPLE ALLOCATIONS FOR VMRELn PROVIDED IN THE SYSGEN GUIDE.
A COPY OF THIS DMKSNT MODULE HAS BEEN INCLUDED IN THE CP NUCLEUS,
SUCH THAT IF ONE USES THE INCLUDED DMKSYS AND THE
SAKPLE ALLOCATION PROVIDED IN THE SYSTEM GENERATION GUIDE,
HE WILL BE ABLE TO SAVE HIS CKS SYSTEM UPON COMPLETION
OF THE SYSTEM GENERATION PROCEDURE. A COpy OF DMKFCB HAS BEEN
INCLUDED IN THE NUCLEUS AND NEED NOT BE RE-ASSEMBLED FOR
SISTEPI GENERATION. IT HAS BEEN INCLUDED FOR THE USER WHO WOULD LIKE
TO MODIFY OR ADD TO THE EXISTING BUFFER L01D.
NOTE: IF THE USER WISHES TO MODIFY THE SAMPLE DMKSNT AND/OR DPIKFCB
HE !AY INCLUDE THE UPDATED SOURCE WITH THE SOURCE INCLUDED UNDER
THE OPTION 'GENERATE VK310', OF THE SYSTEM GENERATION PROCEDURE.
IF PRESENT, IT WILL AUTOMATICALLY BE ASSEMBLED AND INCLUDED IN THE
NEW CP NUCLEUS.
Part 3. Generating VK/310 (CP, CMS, RSCS, and IPCS)
243
Starter Systems
Aqain, the GENERATE EXEC procedure prompts you:
DO YOU WISH TO HAVE A COpy OF DKKSNT, DKKSYS, DKKFCB, AND
RELEASEn DIRECT PUNCHED TO CARDS? -- RESPOND (YEStNO):
Enter "yes" to have these decks punched since you need to read in
updated copies of these decks in Step 16. "Part 2. Defining Your V"/370
System" contains a listing of the directory and the DKKSNT, DKKSYS, and
DKKFCB modules supplied with the starter system. The following messages
are issued to indicate the files that are being punched:
PUNCHING
PUNCHING
PUNCHING
PUNCHING
R;
'
'
'
'
DKKSNT ASSEKBLE
DKKSYS ASSEKBLE
DKKFCB ASSEKBLE
RELEASEn DIRECT
'
'
'
'
******
******
******
******
Step 16. Build the VM/370 Directory and Assemble
the Files Defining the Real I/O and System Devices
Create or update the following card files describing your installation's
version of the VK/370 directory, real I/O configuration, and system
devices and place them in the reader and invoke the GENERATE EXEC
procedure to build the directory and assemble the files describing the
configuration. Kake sure your directory contains KDISK statements for
KAINT's 193 and 294.
Place the following cards in the card reader, in
the sequence shown:
ID CPGEN
:READ filename DIRECT
(Directory program control statements)
:READ DKKRIO ASSEKBLE
(Real I/O configuration macros)
:READ DKKSYS ASSEKBLE
(system control macro statements)
:READ DKKSNT ASSEKBLE
(system name table macro statements)
The Directory program control statements, real I/O configuration macros,
and system control macros are those you created according to the
instructions in Part 2. "Defining Your V8/370 System." You can code
your own system control macro statements or modify the sample files
supplied with the starter system.
New requirements demand that the user define space in the directory
for "Service Staging Areas". The minidisk addresses and suggested sizes
are described in the Kemo to Users for the SCP and later in this
publication under "Updating VK/370". These areas are used for the AUX
files and PTF files contained on the system PUT. The files are loaded
by the individual service installation EXECs.
Since the starter system's directory does not allocate space for the
minidisks, the "new user" service loaded in Step 13 did not attempt to
load these files.
They will be loaded, however, when the rest of the
service is loaded, later in this procedure (Step 23) •
244
IB" V"/370 Planning and System Generation Guide
starter Systems
Also, if you wish, you
module (DMKFCB) to conform
the printer forms control
step 15) and place it in
macro statements:
can change the printer forms control buffer
to local requirements. If you want to change
buffer, modify the file that was punched (in
the reader following the system name table
:READ DMKFCB ASSEMBLE
(forms control macros)
:READ DMKSNT ASSEMBLE
{system name table macros}
Noi~ Ensure that
the cylinders specified for the directory as well as
the DMKSYS and DMKSNT source programs do not overlap each other.
Instructions for creating new forms control
~Y2tem PrOQram!lll@S Guid~.
macro statements are in the
1&3 7 0
FORMAT OF THE READ CPNTROL STATEMENT
The READ control statements
shown in Figure 26.
must be
punched according
to the
format
r
t Number of I
I
!!eaning
I ColumnlCharacterslContentsl
I
,colon I : I Identifies card
I
Identifies card
4
IREAD
I 2-5
I
I
, blank
6-7
2
I
Filename of the
I fname
8
I 8-15
I
I
1blank
116
1
Filetype of the
i i7-24
8
iftype
1
1
56
1blank
125-80
I
,
,
,,
,
as a control card
as a READ control card
file punched
file punched
L
Figure 26. Format of READ Control Statement
SPECIAL PROCEDURE IF YOU ARE USING ONLY ONE TAPE DRIVE
If you are using only one tape drive, issue the command:
define 181 as 182
Now mount the scratch
device.
tape in place of the system
PUT and ready the
Part 3. Generating VM/370 (CP, CMS, RSCS, and IPCS)
245
starter Systems
INVOKE THE GENERATE EXEC PROCEDURE
When all the files are placed in the reader, invoke the
procedure by issuing the following command:
GENERATE EXEC
generate vm370
This procedure invokes the VM/370 directory program to build the
disk-resident VM/370 directory, then assembles the DMKRIO and DMKSYS
files that you placed in the real card reader. GENERATE prompts you for
the filename of your directory file with the message
ENTER DIRECTORY FILENAME
Enter the name you specified in the directory deck.
After the directory program execution completes, the DMKRIO and
DMKSYS files are assembled in preparation for building the new CP system
nucleus. G'P.NER.TF. +hen check!=; fnr D~KF("B and D~KSNT source files..
9.'her..
new versions of the DMKFCB and.DMKSNT modules are provided, GENERATE
assembles the new modules and replaces the corresponding starter system
supplied modules with the new modules.
If any errors occur while the
VM/370 directory is being built, the directory program issues error
messages and the GENERATE EXEC procedure issues the following message:
CORRECT THE DIRECTORY CARDS AND RELOAD THE CARD READER
RESPOND WITH: GENERATE DIRECT
Correct the errors in the directory program control statements, and
reload the card reader with only the ID card, the :READ statement, and
the directory program control statements. Then respond with:
generate direct
If errors are detected while the DMKRIO, DMKSYS, DMKFCB,
files are assembling, GENERATE issues a similar message:
or DMKSNT
CORRECT THE filename ASSEMBLE FILE AND RELOAD THE CARD READER
RESPOND WITH: GENERATE filename
Correct the errors in the indicated file, and reload the card reader
with only the ID card, the :READ statement, and the appropriate file.
Then, issue the GENERATE command with the appropriate option.
For
example:
generate dmksys
Step 17. Attached Processor Support and
Virtual= Real Machines
Once the directory is built and
EXEC asks:
the files are assembled,
the GENERATE
ARE YOU GENERATING AN AP SYSTEM?--(RESPOND YESINO)
followed by:
VIRTUAL=REAL OPTION REQUIRED (YES, NO) :
Your responses to these questions will determine the
loadlist EXEC necessary to correctly build your system.
246
IBM VM/370 Planning and System Generation Guide
CNTRL file
and
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
St arter Systems
If you respond "yes" to this question, you are prompted to enter the
amount of storage you wish to reserve in the CP nucleus for a
virtual=real machine.
(Part 1.
"Planning for System Generation"
contains formulas to help you determine how much storage you need to
reserve. )
To generate a V=R system of size !M (megabytes), specify!~ in the
format nnnnk. nnnnk must be a mUltiple of 1024K.
For example, to
indicate 3M you should specify 3072K.
The minimum size you can specify
is 32K. The maximum specifiable size is 15360K.
A "yes" response displays the following messa ges:
STORAGE SIZE OF VIRT=REAL (MINIMUM IS 32K):
100k
0100K STORAGE SIZE FOR VIRTUAL=REAI,
IS THE ABOVE ENTRY CORRECT (YES, NO) :
ves
If you respond "no" to this message, the following message is displayed:
FILE 'DMKSLC TEXT A1' NOT FOUND
You must have enough virtual storage available to generate the CP
nucleus with a virtual=real area.
If you do not have enough virtual
storage available, redefine stcrage for your virtual machine.
Step 18. Load the CP Nucleus
Once you respond to the virtual=real generation questions, the GENERATE
EXEC procedure builds and writes the CP nucleus on tape. To do this,
GENERATE first issues the the VMFLOAD command to punch the loader and CP
object modules to a virtual punch spool file. Then GENERATE transfers
this file to the virtual card reader file and writes the file on tape.
GENERATE issues the following messages during the processinq:
hh:mm:ss NO FILES PURGED
SYSTEM LOAD DECK COMPLETE
hh:mm:ss PUN FILE nnnn TO CPGEN COPY 01 NOHOLD
IPLABLE NUCLEUS NOW ON TAPE ****
No1~1 If any
errors are detected while the tape is being written, you
must recreate the CP nucleus. To do this, issue the command:
generate cp nucleus
The procedure restarts at Step 17 where you are asked if you want the
virtual=real option and support for the Attached Processor.
The
followinq message is issued:
THE NUCLEUS LOAD MAP MUST BE SAVED ON DISK FOR IPCS.
WHEN 'NUCLEUS LOADED ON XXXXXX' IS TYPED, ISSUE 'CLOSE PRT' AND IPL
CMS AND READ IN THE LOAD MAP. IT WOULD BE EXPEDIENT TO LOAD IT ON
AN AREA ACCESSIBLE TO THE IPCS VIRTUAL MACHINE.
FOLLOWING THIS, THE NEW SYSTEM MAY BE IPL'ED.
Part 3. Generating VM/370 (CP, CMS, RSCS, and IPCS)
247
Apr1l 1,
1~81
starter Systems
When the nucleus is written on your system residence volume, the
resultant load map is placed in your virtual reader by the CLOSE PRT
command. This load map should be read in as a uniquely named CMS file.
After the new system is operational, the disk-resident load map is
required for IPCS.
If you have limited space available on the starter
system minidisks, read the load map onto the CMS system disk (190).
Issue the following commands:
link cmssys 190 190 w write
access 190 a
read cpnuc loadmap
LOADING A CP NUCLEUS WITHOUT A VIRTUAL=REAL AREA
If you responded "no" when asked if you wanted the virtual=real area,
the GENERATE EXEC procedure builds the CP nucleus, writes it to tape,
and loads it from the tape.
When the nucleus is written on the system residence volume, the message
NUCLEUS LOADED ON volid
is issued, where volid is the volume serial number of your system
residence volume.
The volid is the serial number you specified on the
SYSRES macro when you prepared the CP system control file (DMKSYS). If
you followed the example in this manual, the serial number of your
system residence volume is VMRELn.
The CP load map is placed in the virtual reader of CPGEN.
This load
map should be read in as a uniquely named CMS file. After your new
system is operational, the disk resident load map is required for IPCS.
To save the load map, issue the following commands:
close prt
ipl 190 parm seg=null
access 194 a
read cpipcs map a
If you wish, edit or print the load map. The contents
map are described in Part 5. "Updating VM/370".
You may now drain
entering:
all spooling
devices and
shut down
of the load
the system
by
drain all
shutdown
If an error occurs, and you do not
volid" message, issue the commands
receive the "NUCLEUS
LOADED ON
cp spool prt off
close printer
to allow the error load map to be printed and examine the listing of the
load map_
A loader error may be indicated.
See the !~L~lQ ~~§~~E
Me§§ggg§ for a list of the loader wait state codes.
248
IB' VM/370 Planninq and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Starter Systems
A loader failure may occur as the result of an error in the real I/O
configuration (DHKFIO) file or the system control (DKKSYS) file. Check
that the assemblies of these files completed without error. Also check
that these files hqve CSECT cards and that macros are included in the
proper sequence. If an "OVERLAY ERROR" occurs, a common cause is
insufficient virtual storage for your virtual machine.
After correcting the error, you do not have to shut down the system,
but reinvoke the GENERATE EXEC at the point at which the error occurred.
(See step 16.)
LOADING A CP NUCLEUS THAT HAS A VIRTUAL=REAL AREA
If you responded "yes" when asked if you wanted the virtual=real area,
the GENERATE EXEC procedure issues the following message:
IF YOU HAVE ACCESS TO A DISK WITH THE SAME ADDRESS AS THE SYSRES
DEVICE, DETACH IT. IPL THE NUCLEUS JUST PLACED ON THE TAPE AND
THEN YOU WILL BE ABLE TO SAVE THE LOAD MAP AS DESCRIBED ABOVE.
YOU WILL RECEIVE AN ERROR MESSAGE BECAUSE YOU DO NOT HAVE ACCESS
TO THE SYSRES DEVICE, BUT THE LOAD MAP WILL HAVE BEEN CREATED.
TO LOAD THE CP NUCLEUS JUST CREATED, SHUTDOWN THE SYSTEM AND
THEN IFL THE TAPE. ONCE THE NUCLEUS HAS BEEN LOADED,
YOU MAY IPL YOUR NEW CP SYSTEM RESIDENCE VOLUME.
NOTE: THERE MUST BE ENOUGH STORAGE ON THE SYSTEM (VIRTUAL OR REAL), TO
CONTAIN THE VIRT=REAL AREA AND THE CP NUCLEUS.
Be sure that there is enough storaqe to load the CP nucleus with a
virtual=real area before you load it. The "Specifying a Virtual=Real
Machine" section of Part 1 tells you how to determine the amount of real
or virtual storage you need. You can load a CP nucleus that has a
virtual=real area in either a real or virtual machine.
You IPL the tape containing the CP nucleus. The CP nucleus is on the
tape at virtual address 182 for the CPGEN virtual machine.
EXAMINE THE CP LOAD MAP
Edit or print the load map if you wish. The contents of
are described in "Part 5. Updating VM/370,,"
the load map
Two external names may be listed as undefined on the load map. The
external name DMKSLC is undefined if the virtual=real option is not
specified. The external name DMKRNTBL is undefined if there is no entry
in the system name table for a 370Q/3705 control program (that is, if
you did· not code a NAMENCP macro for the DMKSNT file) •
Also, other
names may be listed as undefined if other modules were deleted as
described in the section "Reducing the Size of the CP Nucleus. 1I
Part 3. Generating VM/370 (CP, CMS, RSCS, and IPCS)
249
Apr 11 1, 1981
St art er Syste ms
Step 19. IPl the Newly Generated VM/370
If you plan to keep the CPRnLO volume as allocated when using the
various system directories, you should use the IPL FMT deck that you
punched in step 14 to reallocate the space on the volume.
Put the deck
in your card reader, set the load unit switches appropriately, and IPL
the reader.
Respond to the format/allocate messages as shown in the
following example:
VM/370 FORMAT/ALLOCATE PROGRAM RELEASE n
ENTER FORMA~ OR ALLOCATE:allocate
ALLOCATE FUNCTION SELECTED
ENTER DEVICE ADDRESS (CUU):130
ENTER DEVICE TYPE: device type 1
ENTER DEVICE LABEL:CPRnLO
ENTER ALLOCATION DATA FOR VOLUME CPRnLO
TYPE CYL CYL
23i4
drct 000-000
perm 001 202
perm2
end
3330
000000
001 403
404 807
33,+0
000000
001 348
349 697
jj~U
000-000
001 554
ALLOCATION RESULTS
DRCT 000 000
000 000
000 000
000 000
PERM 001 202
001 403
001 348
001 554
DEVICE 130 VOLUME CPEnLO ALLOCATION ENDED
ENTER FORMAT OR ALLOCATE:
IPL the newly created system residence volume by setting the load
unit address dials to the real address of the VMRELn system residence
volume and pressing the LOAD button.
The userid OPERATOR (or whatever
userid you specified as the system operator on the SYSOPER macro) is
logqed on when you IPL. The following messages are issued. Respond as
shown.
VM/370 VERSION vv LEVEL 00 PUT nnnn; mm/dd/yy hh:mm:ss
NOW hh:mm:ss EDT day mm/dd/yy
CHANGE TOD CLOCK (YESINO):no
hh: mm: ss START «(COLD IWARMI CKPT I FORCE) (DRAIN» I (SHUTDOWN) : cold
hh:mm:ss AUTO LOGON *** OPERATOR USERS=OOl BY SYSTEM
hh:mm:ss
D~KCPI952I nnnnK SYSTEM STORAGE
DMKCPI957I STOR sssssK, NUC nnnK, DYN dddddK, TRA tttK, FREE ffffK,
V=R vvvvvK
hh:mm:ss FILES:
NO RDR,
NO PRT,
NO PUN
hh:mm:ss FORMATTING EFROR RECORDING AREA
hh:mm:ss
lDevice types accepted by the Format/Allocate program are:
3330, 3330-11, 3340-35, 3340-70, 3350, 2305-1, and 2305-2.
2This line gives the required specifications for the 3330
the 3340 Model 70.
250
IBM VM/370 Planninq and System Generation Guide
2314, 2319,
~odel
11 and
starter Systems
At the time you IPL your newly generated V~/370,
your system
residence volume is formatted according to your specification on the
SYSRES macro.
Also, if you used the V~/370 directory supplied with the
starter system, your starter system volume (CPRnLO) is set up as shown
in Figures 21, 28, 29, and 30. Be careful not to modify the 190 and 194
minidisks for the ~ AINT user. These minidisks and the information they
contain are required for applying PUT
(Program Update Tape) services to
V~/ 370.
Real
Cylinder
Number of
Cylinders
o
Contents
Unused
191 min idisk for the IVPM 1 use r
191 minidisk for the IVPM2 user
2
3-7
5
191 minidisk for the RSCS user
8-14
7
191 minidisk for the OPERATOR user
I
I
,
15-18
4
191 minidisk for the CE user
I
19-28
10
29-33
5
1
I
I
I
191 minidisk for the KAINT user
191 minidisk for the
EC~ODE
199 minidisk for the MAINT user
34
1------------·----------------------------------------190 minidisk for the KAINT
135
I
35-169
I
I
I
user
No!~:
The nucleus occupies the last two
cylinders of the minidisk.
(Specify cylinder
133) •
,
I
I
I
user
170-202
33
194 minidisk for the MAINT user - it contains
the CP object modules (text decks)
L
Figure 27.
A~~ocat~on of the Va/370 starter System Volume (CPRnLO)
the 2314 Starter System Directory Is Used
Part 3. Generating
V~/310
(CP, CMS, RSCS, and IPCS)
when
251
starter Systems
r
Real
I
I Cylinder
I
0
I
Number of
Cylinders
Contents
Unused
191 minidisk for the IVPK 1 user
191 minidisk for the IVPK2 user
2
3-7
5
191 minidisk for the RSCS user
8-12
5
191 minidisk for the OPERATOR user
13-16
4
191 minidisk for the CE user
17-23
7
191 minidisk for the KAINT user
24-28
5
191 minidisk for the ECKODE user
199 minidisk for the !!AINT user
29
I
I
,
I
I
I
I
I
I
I
30-114
85
190 minidisk for the KAINT user
The
nucleus
occupies
the last
cylinder of the minidisk.
(Specify cylinder
84. )
No1~:
115-141
27
142-403
262
194 minidisk for the KlINT user
Not used.
L
Figure 28.
252
Allocation of the starter System Volume (CPRnLO)
3330 Starter System Directory Is Used
IBM VM/370 Planning and System Generation Guide
When the
starter Systems
r
Real
I
I Cylinder
Number of
Cylinders
Unused
0
I
I
1-2
2
191 minidisk for the IVPM1 user
3-4
2
191 minidisk for the IVPM2 user
5-10
6
191 minidisk for the RSCS user
11-20
10
21-25
5
26-40
.1:
IJ
41-45
5
191 minidisk for the ECMODE user
46-47
2
199 minidisk for the MAINT user
240
190 minidisk for the MAINT user
48-281
I
I
I
t
I
I
1
contents
191 minidisk for the OPERATOR user
191 minidisk for the CE user
191 minidisk
+-.
.. "-1..,...
.... v ....
\..U'C
l!AINT
user
i
The nucleus occupies the last two (
cylinders of the minidisk.
(Specify cylinder;
238.)
I
!ot~:
288-341
60
----------------------------------------------------1
194 minidisk for the KAINT user
I
--------------------------------------------------------------------------1
Cylinders 348-695 are not used for a 3340 Kodel 10 system
I
I!Ql~:
(residence volume.
I
L
Figure 29.
Allocation of the starter System Volume (CPRnLO)
3340 Starter System Directory Is Used
When the
Part 3. Generating VM/370 (CP, CKS, RSCS, and IPCS)
253
starter Systems
r
Real
Cylinder
Number of
Cylinder s
o
contents
Unused
191 minidisk for the IVP!!l user
2
191 minidisk for the IVP!!2 user
3
191 minidisk for the RSCS user
6-8
3
191 minidisk for the OPERATOR user
9-10
2
191 minidisk for the CE user
11-15
5
191 minidisk for the !!AINT user
16-19
4
191 minidisk for the EC!!ODE user
199 minidisk for the !!AINT user
20
21-56
35
190 minidisk for the !!AINT user
No!~: The, nucleus occupies the last cylinder
of the minidisk.
(Specify cylinder 34.)
57-64
65-554
9
490
194 minidisk for the !!AINT user
Not used.
L
Figure 30.
Allocation of the Starter System Volume (CPRnLO)
3350 Starter System Directory Is Used
When the
Step 20. Back Up the Newly Generated VM/370
At this time,
back up your new system residence volume. If your real
machine has at least 448K bytes of real storage, the tape created in
Step 1A is sufficient backup.
However, that tape is not sufficient
backup for real systems with less than 448K of real storage because that
tape cannot be loaded on such systems.
It may also be inadequate if you
have a large V=R area.
V!!/370 systems that run on a real machine with less than 448K bytes
of re~l storage should use the DASD Dump Restore
(DDm service program
to create a backup tape similar to the one created in step 18. The DASD
Dump Restore program is described in the !M/310 Qp~~ator~2 Guid~.
If
your system residence volume is at address 131 and you labeled it
V!!RELn, you could use the following DDR control statements to back it
up:
input 131 device type V!!RELn
output 181 device type (tape drive)
dump cpvol
The DUMP CPVOL statement causes cylinder 0 and those disk cylinders
allocated as PERM or DRCT in Step 2 to be dumped onto the tape.
254
IB!! VM/310 Planning and System Generation Guide
Starter Systems
If you do not wish to use the DDR program to backup your system, you
can load the tape produced in Step 18 in a virtual machine. If you load
the tape in a virtual machine that virtual machine must have (1) 512K of
storage and (2) write-access to the system residence volume, at the
address defined for system residence in the SYSRES macro of the CP
system control (DMKSYS) file.
When you use the DDR program to backup your system, you do not get a
load map when you restore the tape. You do get a load map if you load
the tape produced in Step 18.
Step 21. Format the Operator's Virtual 191 O-isk
Before any new minidisk area can be used for CMS files; it must be
initialized with the CMS FORMAT command, which formats the area into
BOO-byte blocks. Take care not to format areas which contain data
restored from the starter system (such as the 190 and 194 minidisks
belonging to the user MAINT). The CMS FORMAT command is described in
the VM/370 CM~ CommaDg ~nd MacrQ Reference.
Noi~~ After you complete
this step, a portion of the starter system is
overlaid by the operator's 191 minidisk. If for any reason you wish to
IPL the starter system again, you must start from Step 1.
At this time you are logged on
procedure to format your virtual
already loaded CMS, issue:
as the operator. Use
disk 191.
First, if
the following
you have not
ipl 190 parm seg=null CMS responds with:
CMS VERSION n.n - mm/dd/yy hh:mm
Next, enter the following command:
access (nodisk
The NODISK option prevents CMS from automatically accessing your virtual
disk 191. (Accessing 191 at this time would cause an error message to be
issued because 191 is not yet initialized, and therefore cannot be
used.)
After the Ready message is displayed, issue the command:
format 191 a
The CMS FORMAT command prompts you with the following message:
FORMAT WILL ERASE ALL FILES ON DISK 'A(191)'.
DO YOU WISH TO CONTINUE? (YESINO):
If you respond "yes", CMS prompts you with:
ENTER DISK LABEL:
opr1 Q 1
Enter the one-to-six character alphameric label of the virtual disk.
You can use whatever label you wish for this virtual disk.
In this
example, the label is OPR191. CMS then issues:
FORMATTING DISK 'A'.
Inn' CYLINDERS FORMATTED ON 'A(191) '.
and a Ready message.
Part 3. Generating VM/370 (CP, CMS, RSCS, and IPCS)
255
starter Systems
Step 22. Format the MAINT User's Virtual 191 Disk
Initialize the 191 disk belonging to "lINT, in the same way you
initialized the operator's virtual 191. Log off the system and log on
again as userid "lINT, using the password CPC"S. Define your virtual
storage to be larger than the location of any discontiguous saved
segments that C"S may try to use at this time.
(In this example, if you
used the D"KSNT provided with the starter system, define your virtual
storage as 2048K, or 2M). Then IPL C"S as follows:
define storage 2m
ipl 190 parm seg=null
When the CMS Ready message is displayed, issue:
access (nodisk
and continue to format M1INT's 191, using the same procedure you used to
format OPR191.
Step 23. Complete the Application of Service
Now that the M1INT 191 minidisk is formatted, you (as the "lINT user)
can complete the application of service with the changes supplied on the
system program Update Tape (PUT).
Mount the system PUT if it is not
already mounted. You must attach the real tape drive to your CMS virtual
machine ("AINT); for example:
attach 280 to maint as 181
and, with the 191 minidisk that
A-disk, rewind and load the tape:
belongs to
"AINT
accessed as
your
vmfplc2 rew
vmfplc2 load
CMS responds with the following message:
LO lDING ••.••
All
5749010 06pp38
5749010
EXEC
A1
VMSERV
EXEC
11
VMFPLC2 MODULE
A1
END-OF-FILE OR END-OF-TAPE
To resume the
commands:
application of
service started
in Step
access 191 c
vmserv restart 5749010 cp nomemo
lWhere pp is the PUT number.
256
IBM VM/370 Planning and System Generation Guide
13, issue
the
Starter Systems
VMSERV remaps the PUT because the 191 disk of MAINT is new and does not
contain the previously created map.
You are prompted for various
information concerning your system (including staging area addresses and
the service that you want applied). Respond 'NO' when asked if you want
service for RSCS.
Service for RSCS is applied when RSCS is installed.
The "Memo to Users" and the PUT document should be referenced concerning
the application of service with the VMSERV EXEC.
Any further SCP service not applied in Step 13 is applied at this
time (including service for CMS and IPCS).
VMSERV prompts you with:
DO YOU WISH TO CONTINUE APPLYING SERVICE? (YESINO)
Respond "No".
The following messages are displayed:
hh:mm:ss NO FILES PURGED
SYSTEM LOAD DECK COMPLETE
hh:mm:ss PUN FILE nnnn TO MAINT COpy 01 NOHOLD
hh:mm:ss REWIND COMPLETE
WHEN THE NEW CMS SYSTEM IS BUILT ISSUE:
I CLOSE PRT' ...... (PRINTS THE LOAD MAP)
At this point, the CMS nucleus is loaded via IPL from your virtual
card reader.
When the new CMS nucleus is loaded, control passes to
module DMSINI, which then prompts you to specify where to save the
nucleus, what your CMS system residence address is to be, and so forth.
In the following example, the 190 you enter is the 190 minidisk that
belongs to the user MAINT;
it is equivalent to the 190 minidisk that
belongs to CPGEN on the starter system. For instance, you specify
cylinder 108 as the nucleus cylinder address for a 2314 1 when responding
to message DMSINI609R.
The 19E you enter is the address of a user disk that may contain any
user-written programs that run under CMS.
If you enter a null line when prompted for version
installation heading, CMS uses its own defaults.
identification and
DMSINI606R SYSTEM DISK ADDRESS = 190
DMSINI615R Y-DISK ADDRESS = 1ge
DMSINI607R REWRITE THE NUCLEUS ? yes
DMSINI608R IPL DEVICE ADDRESS = 190
DMSINI609R NUCLEUS CYL ADDRESS = nucleus cylinder address 1
DMSINI610R ALSO IPL CYLINDER 0 ? yes
DMSINI611R VERSION IDENTIFICATION =
DMSINI612R INSTALLATION HEADING =
CMS V n.n - mm/dd/yy press ENTER
When the procedure completes its execution, the CMS system residence
volume is updated with the most current object modules (text decks) and
load modules, and the new CMS nucleus is written on the CMS system
residence volume.
If there are any updates for the system assembler on the PUT, the
procedure updates that program and creates the corresponding new
auxiliary directory.
1The nucleus will reside on the last cylinder(s) of the minidisk 190.
See the notes in the figures showing the allocation of the starter
system volumes when the starter system directory is used to determine
which nucleus cylinder address to specify.
Part 3. Generating VM/370
(CP, CMS, RSCS, and IPCS)
251
starter Systems
If there are any updates to the EREP package on the PUT, an updated
ERPTFLIB TXTLIB is loaded onto the CMS system disk. The CPEREP EXEC
supplied with the system contains a statement:
GLOBAL TXTLIB ERPTFLIB EREPLIB
which ensures that the ERPTFLIB is searched first and
level of each individual EREP module is used.
the most current
Step 24. Save eMS
If you used the sample DMKSNT and DMKSYS files supplied with the starter
system; and the sample allocations shown in Step 2, you can now save
your CMS system.
To save the CMS system, load it and then save it as soon after
loading as is possible. If you have ~ot defined your virtual machine as
2M before, issue the command:
define storage 2M
Then IPL CMS:
ipl 190 parm seg=null
and press the carriage return to complete the IPL.
GENERATING THE CMSSEG
SEGMENT
If you have defined a CMSSEG discontiguous saved segment in your
DMKSNT (or used the DMKSNT supplied with the starter system), access
your system disk as an extension and create one at this time by issuing:
access 190 B/A
cmsxgen 100000
where 100000 is the hexadecimal load address of the CMSSEG segment; this
location must correspond to the CMSSEG page number in your DMKSNT
entries.
Figure 31 shows where the CMS segment will be loaded.
The segment name defaults to CMSSEG, but you can load an alternate by
specifying the alternate's name (for example, cmsxgen 100000 cmsseg1).
There must be an entry in the system name table for the alternate.
CMSXGEN checks that the address specified is greater than or equal to
X'20000' and less than 16M. It also checks that only valid characters
are specified. If an error is detected, the message
DMSCMS095E
INVALID ADDRESS 'address'
is issued and command execution is terminated.
Next, CMSXGEN checks that a read/write A-disk is accessed.
If an
A-disk is not available it issues the following error messaqe and
command execution is terminated.
DMSCMS064E
258
NO READ/WRITE A-DISK ACCESSED
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
starter Systems
Then CMSXGEN loads all the text files needed to create the CMS shared
segment, starting at the address specified on the command line.
If
there are any unresolved external references,
the CMSXGEN command
terminates with the message:
DMSCMS111E
CMSXGEN FAILED DUE TO LOAD ERRORS
To ensure storaqe protection for the named segment, CMSXGEN assigns a
storage key
of X'D' (decimal 13)
to the segment. CMSXGEN invokes the
SETKEY command:
SETKEY 13 segmentname
If any errors occur during the SETKEY command execution, the message:
DMSCMS412S
CMSXGEN FAILED DUE TO SETKEY ERROR
If no errors have
is issued and CMSXGEN execution is terminated.
occurred during CMSXGEN processing, the segment is saved via the CP
If an error occurs at this point, the message:
SAVESYS command.
DMSCMS141S
CMSXGEN FAILED DUE TO SAVESYS ERRORS
is issued and CMSXGEN execution is terminated.
Otherwise, the segment
is successfully saved, the load map is printed, and the completion
message:
DMSCMS7151
CMSXGEN COMPLETE
is issued.
SAVING THE CMS SYSTEM
Now, you should redefine your virtual storage to 960K and IPL CMS:
define storage 960K
ipl 190
-or-
ipl 190 parm seg=segname
Where segname is the shared segment created here, if not named CMSSEG.
When the terminal
the command:
unlocks, do not press 'ENTER',
but immediately issue
savesys ems
I Then press 'ENTER'.
If CMS is successfully saved, the message
hh:mm:ss SYSTEM SAVED
CMS VERSION n.n - mm/dd/yy hh:mm
is displayed.
Your CMS system is now saved;
instead of 1PL 190, when you wish to run CMS.
you can
issue IPL
CMS
If you named your CMS system something other than CMS, such as CMS1,
the entry you made in the system name table would be for eMS1; you would
have to save CMS1 (SAVESYS CMS1) and then you could 1PL CMS1.
For more
information about how to save CMS,
see the VMLJ70 ~ystgm R~Qgramm~~~E
~~lg~ or the "Saved Systems" section of this manual.
At th is point, llse the Installation Verification Procedure (IVP) to
test the new system.
Log off the userid MAINT and log on aqain as the
userid OPERATOR, using the password OPERATOR.
The IVP is described
la ter in Part 3.
Part 3. Generating VM/370 (CP, CMS, RSCS, and IPCS)
259
11 fJ.L.1..1.
I,
I
~o
,
Starter systems
Step 25. Obtaining the MSS Communicator Program
If there is an MSS attached to your VM/370 system, and you plan to use
the DMKMSS program for communicating between the VM/370 control program
and the MSC, enabling VM/370 to dynamically mount and demount MSS
volumes,
you should obtain the file which will install the DMKMSS
program in a VS system.
The required file is distributed with the
VM/370 control program object code, which you previously restored to
MAINT's 1q4. The first step is to ensure that MAINT has access to its
194. Issue the CMS command:
access 194 d/a
Next, punch the file; this will install DMKMSS in your VS system.
your VS system is OS/VS1, issue the command:
If
punch mssvs 1 jcl
If your system is OS/VS2, issue the command:
punch mssvs2 jcl
The punched output you receive is a series of OS/VS jobs. This file
must be saved.
When you execute the jobs in your OS/VS system, they
will install the DMKMSS program and create a VS operator procedure
called DMKMSS, later used to start the program in the communicator
virtual machine.
OS/VS 1 JOBS
There are four OS/VS1 jobs.
They are:
•
LINKDMK This job link edits the object code for DMKMSS into the
SYS1.LINKLIB data set; the load module name is DMKMSS.
The DMKMSS
program must be located in SYS1.LINKLIB;
this is one of the
requirements of APF (Authorized Program Facility).
•
DUMPT This job prints two lists (named IEFSD161 and IEF161SD) in
the system program properties table. These lists are used in the
next job.
•
APFZAP This job, as distributed with VM/370, replaces the module
IEHATLAS and DMKMSS in the program properties table; this adds DMKMSS
as an authorized program and removes IEHATLAS. If your installation
wishes to retain IEHATLAS as an authorized program, examine the lists
produced in job DUMPT above. Change the control statement provided
in APFZAP to add DMKMSS rather than replace IEHATLAS.
•
LINKPROC This job adds the procedure DMKMSS to the SYS1.PROCLIB
data set.
You must place the communicator device address on the COMM
control statement before running this job.
After the job has
completed, the OS/VS1 system operator may start the DMKMSS program by
issuing the command' START DMKMSS. P*' where * is the number of the
partition in which DMKMSS is to run.
260
IBM VM/370 Planning and System Generation Guide
starter Systems
OS/VS2 JOBS
There are two OS/VS2 jobs.
They are:
•
LINKD~K This job link edits the object code for DMKMSS into the
SYS1.LINKLIB data set; the load module name is DMKMSS.
In OS/VS2,
this linkedit provides the necessary APF authorization •
•
LINKPROC - This job adds the procedure DMK~SS to the SYS1.PROCLIB
data set.
After this job completes, the OS/VS2 system operator may
invoke the D~K~SS program by issuing the OS/VS2 operator command
'START DMK~SS'.
Before you run job LINKPROC, you must place the
communicator device address on the COM~ control statement.
Part 3. Generating VM/370
(CP, eMS, RSCS, and IPCS)
261
262
IBM VM/370 Planning and System Generation Guide
Installation Verification Procedure
Verifying CP and CMS Using the IVP
The Installation Verification Procedure (IVP) for VM/370 exercises CP
and CMS to verify that they are working properly. The IVP is contained
in two files using the EXEC facility of CMS, and uses two virtual
machines in addition to the system operator's virtual machine.
The tests exercise the following areas of CP:
Multiple virtual machine support
I/O spooling
Transferring of spooled data to other virtual machines
Offline I/O operations
Sending of messages to the system operator
Paging operations
Task dispatching and scheduling
Disk I/O support
Automatic warm start following abnormal termination of VM/370
Verifying that the correct EC level is on machines with
Extended Control-program Support
The following facilities of CMS are exercised:
Normal CMS command processing
Disk formatting
Copying of files
Creation and modification of files via EDIT command
Assembly of executable programs
Execution of user programs
Creation and execution of user-written commands
Printing and punching of CMS files
Issuing of commands to CP
Use of multilevel nested EXEC procedures
Stacking and unstacking of command and data input from the terminal
Communication with user from EXEC procedures
Several other system facilities, incidental to the primary rvp tests,
are exercised. Certain system facilities such as preferred execution
options, virtual=real, as ISAM, and RSCS (Remote Spooling Communications
Subsystem) are not exercised by the IVP. The IVP requires operator
intervention only when an operational decision is to be made, or to
initiate the IVP tests themselves.
All file creation, erasure,
management, and logoff of the virtual machines (with the exception of
the system operator) at test completion is performed without operator or
user action.
The IVP tests use only the system-provided facilities. All unique
test programs are created, assembled, and subsequently erased by the
lVP.
Facilities Required for Each IVP Virtual Machine
All VM/370 configurations are supported. The lVP
control of CMS. The other facilities required are:
•
•
•
executes under
the
The assembler
One virtual read/write disk accessed as the A-disk (usually 191)
320K of virtual storage (16M for IVPM1)
Part 3. Generating VM/370 (CP, CMS, RSCS, and lPCS)
263
Installation Verification Procedure
Starting the IVP
The IVP must be executed to formally complete the initial installation.
(See "Variations of the IVP" for post installa tion testing.)
It
requires two virtual machines (IVPM1, IVPM2)
which must be described in
the VM/370 directory.
The directory entries for the IVP virtual machines, IVP1 and IVP2,
are included in the VM/370 directory supplied with the starter system;
these entries should be included in your own directory.
The spooling
classes for the reader and the punch must be the same.
You, as the system operator, execute
tests, enter the command:
the IVP.
To initiate
the IVP
ivp
and then answer "yes" or "no" to the following question:
ARE YOU THE SYSTEM OPERATOR? ENTER "YES" OR "NO":
If you enter the IVP command with no parameters specified and then
reply that you are not the system operator, the IVP tests default to the
single virtual machine verification procedure.
(See "Variations of the
IVP. ")
Prompting instructions are displayed
operation or issue a command.
whenever you
must perform
Log on the virtual machine (IVPM1), using the password
IPL eMS to continue the testing procedure:
an
IVPASS, and
logon ivpml
ENTER PASSWORD:
ivpass
LOGON AT 09:55:00 EST FRIDAY mm/dd/yy
define storage 16384k
STORAGE= 16384K
If you created a eMSSEG discontiguous saved segment in step 24
system generation procedure, IPL eMS by issuing:
of the
ipl 190
If you did not create a eMSSEG segment in step 24, IPL eMS by issuing:
ipl 190 parm seg=null
In either case, the system will respond:
eMS VERSION n.n mm/dd/yy hh.mm
Then you begin the IVP procedure by issuing:
ivp
264
IBM VM/370 Planning and System Generation Guide
Installation Verification Procedure
At this point, the tests begin on virtual machine 1. After the
disconnect message is displayed, follow the prompting messages that are
displayed. These messages tell you to log on the IVPM2 virtual machine
(this may be done on the same terminal), as shown:
logon ivpm2
ENTER PASSWORD:
ivpass
LOGON AT 09:58:30 EST FRIDAY mm/dd/yy
If you created a CMSSEGdiscontiguous saved segment in Step 24
system generation procedure, IPL CMS by issuing:
of the
ipl 190
If you did not create a CMSSEG segment in Step 24, IPL CMS by issuing:
ipl 190 parm seg=null
In either case the system will respond:
CMS VERSION n.n mm/dd/yy hh.mm
Then you begin the IVP procedure by issuing:
ivp 2
At this point, the remainder of the tests begin on virtual machine 2.
The final phase of the IVP tests consists of displaying, printing, and
punching a file which contains the messages generated by IVPK1 after it
is disconnected.
Upon completion of the tests, the IVP EXEC procedure logs off. The
system abnormal termination test, which consists of forcing an ABEND
dump of VK/370 and the subsequent warm start, is an option that you must
specify in response to messages that are displayed. For the purpose of
installation verification, you should select this option. You are
instructed to delay starting the spooling devices (reader, printer, and
punch) until after the warm start procedure.
Variations of the IVP
If you wish, you may run the IVP procedure
using anyone of the following methods:
•
•
•
after initial installation,
Executing the IVP without testing the system abnormal termination
Executing the IVP using virtual machines other than IVPK1 and IVPK2
Executing the IVP in a single virtual machine
When you execute the IVP in a single virtual machine, intermachine
functions, such as transferring data between virtual machines, are not
exercised.
To execute the IVP without testing system abnormal termination:
•
Retain the created virtual machines in your VM/370 directory.
•
Execute the IVP as described previously under "Starting the IVP," but
do not select the "system abnormal termination" option.
Part 3. Generating VM/370 (CP, CMS, RSCS, and IPCS)
265
Installation Verification Procedure
To execute the IVP with virtual machines other than IVP1 and IVP2:
•
Enter, in place of the command IVP 1:
IVP 1 userid1
•
Enter, in place of the command IVP 2:
IVP 2 userid2
where useridl and userid2 identify the two virtual machines in which the
EXEC procedures IVP 1 and IVP 2 (respectively) are to be executed.
To execute the IVP in a single virtual machine, enter
(from any logged-on virtual machine):
IVP
the command
*
This causes the IVP tests to be run in that single virtual machine.
Intermachine transfer of data is simulated by transferring virtual
punched output to the same virtual machine's virtual card reader.
Interpreting the Test Results
Messages at the end of the IVP test indicate successful completion. If
any errors are detected by the IVP, call IBM for software support,
because an error usually indicates a serious malfunction of the
generated system. The IVP procedure identifies each command being tested
just before the command is executed.
Error messages are displayed in a four-line format, for example:
*** IVP FAILURE HAS OCCURRED ***
*** COMMAND: STATE IVPTST *
***
***
EXPECTED RETURN CODE 28
RECEIVED RETURN CODE 0
These messages indicate that the CMS STATE
0, instead of the expected 28.
All information messages
by three asterisks (***).
command had a return code of
that originate within the
IVP are preceded
If any command fails, the IVP procedure terminates. Follow
instructions (if any are given) to log off the virtual machine.
the
Once the IVP procedure has executed successfully, continue the system
generation process by loading and saving discontiguous saved segments,
as described in the section that follows.
266
IBM VM/370 Planning and System Generation Guide
Loading and Saving Discontiguous Saved Segments
Loading and Saving Discontiguous Saved
Segments
After you have finished generating and testing your new system, you may
wish to load and save discontiguous saved segments.
The DMKSNT module
supplied with the starter system includes entries for saved segments
called CMS, CMSSEG, CMSVSAM, CMSAMS, CMSDOS, and INSTVSAM. You may also
create_ your own entries.
See the section "Preparing the System Name
Table File (DMKSN~" in Part 2.
Throughout the following discussion, it will be helpful for you to
refer to Figure 31, which shows how the CMS discontiguous saved segments
are loaded in virtual storage if you use the DMKSNT module supplied with
the starter system.
Before a discontiguous saved segment can be attached and detached by
name, it must be loaded and saved. The discontiguous saved segment must
be loaded at an address that is beyond the highest address of any
virtual machine that will attach it.
It is the system programmer's
responsibility to make sure the saved segment is loaded at an address
that does not overlay the defined virtual machine or any other saved
segment that may be attached at t-he same time. The load addresses are
determined by the entries you coded in your DMKSNT module.
The load address for the discontiguous saved segment should be just
beyond the largest virtual machine that uses it. If the load address is
unnecessarily high, real storage is wasted because CP must have segment
table entries for storage that is never used.
For example, assume you have five CMS virtual machines in your
installation.
Also assume that all five use the CMS support for DOS
program development and testing which is in a 32K segment named CMSDOS.
If each of your five CMS virtual machines has a machine size of 320K,
you should load the CMSDOS segment just beyond 320K but below 992K (so
as to contain it within 1M). Otherwise real storage would be wasted
because CP must maintain segment table entries for each 1024K of
storage.
Once the named segment is loaded at the correct address, you can save
it by issuing the CP SAVESYS command. To be sure that a discontiguous
saved
segment has
storage
protection, set
the
storage
key for
the
segment accordingly.
CMS has a new command, SETKEY, to do this. The
CMS SET KEY command is described in the 1M/310 Sys!~ ~rog£~!~ Guide.
CMS has EXEC procedures that help you load, set storage keys for, and
save the CMS discontiguous saved segments. The DOSGEN EXEC procedure
loads and saves DOS segments. The VSAMGEN EXEC procedure loads and
saves the CMS/VSAM and Access Method Services segments.
The CMSXGEN
EXEC procedure loads and saves CMSSEG, which contains the CMS Editor,
EXEC processor, and OS simulation routines. You used the CMSXGEN EXEC
procedure to save CMSSEG in Step 24 of the system generation procedure.
The DOSGEN and VMSAMGEN EXEC procedures are described later in this
section.
Note: These procedures for loading and saving discontiguous saved
segments and the associated text files are 'mode l' to reduce the amount
of storage needed for the master file directory in the user's virtual
machine.
The system disk must be accessed (any mode, A through G)
before loading any discontiguous saved segment.
Make sure that this is
done aft~ any intermediate IPL of CMS.
Part 3. Generating VM/310
(CP, CMS, RSCS, and IPCS)
261
Loading and Saving Discontiguous Saved Segments
Decimal
Load
Segment
!ddI.~~ Nam~
16320K
r----------------------------------------------------------~1
I
,
,
,INSTVSAM
16256K
Contains the CMS/DOS discontiguous saved
1
segment used to install VSAM and Access
I
Method Services.
,
4064(2)
254(3),
FEOOOO(1)
I
,
,
Storage unaddressable by the virtual machine. ,
210000
528
33
I
-------------END OF DEFINED VIRTUAL STORAGE------------I
I
Contains the CMS control blocks and free
storage used during installation of the
segments.
200000
512
32
2112K
,,,
,
-------------------------------------------------·-----------1
Contains DOS/VS Simulation Routines
2048K
1984K
1472K
1088K
1024K
,
CMSDOS
I
Contains CMS Access Method Services support
The area from 1472K to 1856K is shared;
I
the area from 1856K to 1984K is not.
I
, CMS AMS
170000
368
23
,--------------------------------------------------------Contains CMS VSAM support
The area from 1088K to 1408K is shared;
the area from 1408K to 1472K is not.
I CMSVSAM
110000
272
17
1
contains the Editor, EXEC, and OS Simulation
Routines
I
The entire segment is shared.
I
, CMSSEG
100000
256
16
,,
,
,
1----------------------------------------------------------,
I
I
OK
The area from 1984K to 2016K is shared.
The area from 2016K to 2048K is unused.
1FOOOO
496
31
CMS Virtual Machine's Area
000000
0
o
1----------------
,
1~1!12:
I
(1)
HEX LOAD
ADDRESS
(2) STARTING
PAGE
NUMBER
(3)
STARTING
SEGMENT
NUMBER
.J
Figure 31. Sample Layout of Storage for CMS Discontiguous Saved Segments
You may want to compare this storage layout with the sample DMKSNT
shown in the section "Preparing the Syst~m Name Table File (DMKSNT)" in
Part 2.
Note that as new releases of VSAM and AMS become available, the
number of segments required by these systems may be increased, thus
requiring all segment addresses above these segments to be increased
accordingly.
Noie: Refer to the latest Memo to Users for any possible changes to the
sample layout of storage for CMS discontiguous saved segments.
268
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Loading and Savinq Discontiguous Saved Segments
~~lation§h!B
of
Pag~
NumbersL
Addresses:
Since the NAMESYS macro requires you to specify page and segment
numbers, and the CMSXGEN, DOSGEN, and VSAMGEN procedures require you to
enter hexadecimal addresses, you may find the following reference
information useful.
1 Page = 4K = X'1000'
1 Segment = 64K = X'10000'
To convert a page number to a
16.
segment number, divide the page number by
since one segment is 10000 in hexadecimal, then 20000
100000 is segment 16, 1COOOO is segment 28, and so on.
The recommended procedure for loading and saving
saved segments as described in Figure 31 is:
is segment 2,
the discontiguous
1.
During the system generation procedure (Step 23), invoke the
CMSXGEN EXEC procedure to load and save the CMSSEG segment at
address 100000.
2.
Perform the Installation Verification Procedure.
3.
Redefine storage to 16M, IPL CMS and access the system disk again.
4.
Invoke the DOSGEN procedure to load and save
at address FEOOOO.
5.
Redefine
aqain.
6.
Define the system name
issuing the CMS command:
storage to
2112K, IPL
of the
CMS
the INSTVSAM segment
and access
CMS/DOS
segment
the system
to INSTVSAM
disk
by
set sysname cmsdos instvsam
7.
Invoke the VSAMGEN EXEC procedure to load and save the CMSVSAM and
CMSAMS segments at addresses iiOOOO and 170000, respectively.
8.
Invoke the DOSGEN EXEC procedure to save the CMSDOS segment at
address 1FOOOO.
The system name entry in the SYSNAMES table
defaults to CMSDOS.
9.
Text files must have a filetype of TEXT.
For example, after you
have updated an object module using VMFASM, the most recent object
file has a filetype such as TXTLOCAL.
To use that text file here,
you must rename it to a filetype of TEXT.
If there is currently a
text file on the system disk, you may want to rename it too, so
that your updated text file (which may reside on another disk) is
the one that is loaded.
loading and Saving the eMS/DOS Segment Called
INSTVSAM
Use the DOSGEN EXEC procedure to load and save the CMS/DOS segment
called INSTVSAM. This eMS/DOS segment is used only for the installation
of V5AM and Access Method Services.
Part 3. Generating VH/370 (CP, CMS, RSCS, and IPCS)
269
~age
or
bLLU-I~U'-'U
AS
upaa~ea
Apr1L
l~
lYijl by TNL GN25-0837
Loading and Saving Discontiguous Saved Segments
Before you invoke DOSGEN to load the INSTVSAM segment, IPL CMS in a
virtual machine with 16M (16384K) of storage. The INSTVSAM segment will
be loaded near the top of storage, at 16256K (hexadecimal address
FEOOOO).
You can increase your virtual machine storage size, up to the maximum
size defined for it in the VM/370 directory,
by entering the DEFINE
STORAGE command.
After the DEFINE STORAGE command executes,
you must
reload CMS.
define storage 16m
ipl 190
At this point, you
issuing the commands:
save the
C~S/DOS
segment
called INSTVSAM
by
dosgen feOOOO instvsam
Be sure the DOSGEN EXEC is formatted on a CMS minidisk in either 800 or
lK blocks. The format of the DOSGEN command is:
DOSGEN address [segmentnamel
address
is the virtual storage location where the CMS/DOS segment
is to
be loaded.
This
address is
specified in
hexadecimal digits.
segmentname
is the name of the segment to be loaded.
You must ha ve
previously assigned a name to the CMS/DOS segment with
the NAHESYS macro.
DOSGEN checks that the address
than X'20000', and less than 16M.
contains valid characters, is greater
If an error is detected, the message
DMSGEN095E INVALID ADDRESS 'address'
is issued and the command is terminated.
DOSGEN then checks for a read/write A-disk on which to write the C!S
loader work file;
if none is accessed, it issues an error message and
the command terminates.
DMSGEN006E NO READ/WRITE A-DISK ACCESSED
Next, DOSGEN loads all the text files needed for DOS simulation. The
text files are loaded starting at the address specified on the DOSGEN
command.
If there are any unresolved external references, OOSGEN
terminates with the message
DMSGENlllE DOSGEN FAILED DUE TO LOAD ERRORS
DOSGEN then assigns a storage key of X'D' to the segment
it. If an error is detected, one of the following messages
and DOSGEN terminates:
DMSGEN412S DOSGEN FAILED DUE TO SETKEY ERRORS
DHSGEN141S DOSGEN FAILED DUE TO SAVESYS ERRORS
270
IBM VM/370 Planning and System Generation Guide
and saves
is issued
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN2S-0831
Loading and Saving Discontiguous Saved Segments
Otherwise, the segment is successfully saved, the load
and the completion message:
map is printed,
DMSGEN715r DOSGEN COMPLETE
is issued.
No!e: In the DOSGEN EXEC procedure, the default settinq for E~SG is
TEXT.
with this default, error messages are displayed with the message
text only, unless the type code of the message is S or T.
To have all
messages displayed with both text and identifier, issue the command:
set emsg on
at the beginning of the procedure.
Part 3. Generating VM/370 (CP, CMS, RSCS, and IPCS)
210.1
n.!"'............ ., ,
270.2
:71..}
I
IBM VM/370 Planning and System Generation Guide
Loading and Saving Discontiguous Saved Segments
Loading and Saving the CMSVSAM and CMSAMS
Segments
When a VSAM routine is invoked, CMS attaches the discontiguous segments
that contain the VSAM simulation routines.
When an access method
services routine is invoked, CMS attaches the discontiguous segments
that contain the access method services routines.
The VSAMGEN installation EXEC procedure helps you load
VSAM and access method services segments.
The VSAMGEN
procedure can be used to:
•
•
•
•
and save the
installation
Install VSAM and access method services for DOS users
Install VSAM amd access method services for as users
Update VSAM amd access method services for DOS users
Update VSAM and access method services for as users
Before you invoke VSAMGEN, you must:
•
Restore a Release 31 (or later) DOS/VS starter tape to disk. The
disks supported by DOS/VS Release 31, 32, and 33 are: 2314/2319, 3330
Modell and 11, 3340, 3344, and 3350. In DOS/VS Release 34 the 3330
Model 11 and the 3350 (native mode) are also supported. For a
description of the procedure for restoring a starter tape, see the
publication ~OSL!~ System Ge~£ation.
•
Generate VM/370 and apply the latest level of PLC updates.
•
Install the CMS/DOS saved segment called INSTVSAM.
•
Define the size of your virtual machine so that it is large enough to
contain the six VSAM segments and the eight access method services
segments, plus at least two additional segments: one for the CMS
control blocks and free storage used during the generation process,
and one for the CMS/DOS segment called CMSDOS. However, your machine
must not be so large that it overlays the CMS/DOS segment called
INSTVSAM.
The CMSVSAM and CMSAMS segments must be loaded so that they do not
overlay each other, the virtual machine that is loading them, or ani
other discontiguous segment that will be loaded at the same time.
CMSVSAM and CMSAMS also must be loaded at addresses lower than the
CMS/DOS segment called INSTVSAM and beyond the area where you loaded
the CMSSEG segment. CMSSEG contains the CMS Editor, EXEC processor,
and as simulation routines.
If you follow the example shown in
machine storage size as 2112K.
•
Figure 31, define
your virtual
Access your A-disk in read/write mode. The VSAMGEN EXEC procedure
writes DOSLIB files, updated object modules, and (for the as user)
CMS text files created from VSAM and access method services object
modules to the A-disk. Before the VSAMGEN EXEC procedure completes,
it prompts you to specify whether you want to save the DOSLlBs
created; if not, it erases them.
If you are following the example
shown, answer "yes" to this prompting message. The amount of space
you need on your A-disk depends on (1) the device type of your A-disk
and (2) whether you are an OS or DOS user.
The amount of A-disk
space required is:
Part 3. Generating VM/370 (CP, CMS, RSCS, and IPCS)
271
Loading and Saving Discontiguous Saved Segments
Device
Number of Cylinders Required:
DOS User
Type
as User
2314
10
20
2319
10
20
3330 ~odel 1
6
12
33 30 ~odel 11
6
12
3340
15
30
3344
15
30
3350
3
6
Not~
DOS users can use the MlINT 191 supplied with the starter
system to generate VSAM and access method services without obtaining
additional minidisk space, but they must erase the DOSLIBs when
asked. as users should define sufficient A-disk space as indicated
in the table.
•
IPL a CMS system with sufficient
shown in Figure 31, 2 112K) :
virtual storage
(in the
example
define storage 2112K
ipl 190 parm seg=null
•
Since the CMS/DOS segment called INSTVSAM is used to install the
CMSVSAM and CMSAMS segments, you must define the system name of the
CMS/DOS segment. To do this, issue the command:
set sysname cmsdos instvsam
Then link to and access the restored DOS/VS starter system.
cp link dos 342 342 rr read
access 342 d
set dos on d
The S-disk must be accessed as a read-only extension of the A-disk.
access 190 b/a
Invoke the VSAMGEN EXEC procedure by entering:
vsamgen
VSAMGEN prompts you to enter INSTALL if you are installing VSAM and
access method services or UPDATE if you are updating the already
installed VSAM and access method services routines.
VSAMGEN also
requires that you indicate whether you are an as or DOS user.
The
prompting messages are:
DMSVGN360R ENTER 'INSTALL' 'UPDATE' OR 'RESTART'
DMSVGN361R ENTER EITHER 'DOS' OR 'OS'
Respond INSTALL and DOS or as.
If INSTALL is specified for an as user,
all system modules are transferred from the DOS relocatable library to
This allows the as installation to
the CMS disk in TEXT file format.
dispose of the DOS starter system. If you are both an OS and a DOS
user, reply as a DOS user.
VSAMGEN requires a read/write A-disk
available. If an A-disk is not available,
following error messages and terminates:
and checks that one is
VSAMGEN issues one of the
DMSVGN069E DISK 'A' NOT ACCESSED.
DMSVGN361E DISK 'A' IS NOT A CMS DISK.
272
IBM VM/370 Planning and System Generation Guide
Loading and Saving Discontiguous Saved Segments
You are prompted to enter
system you are using:
ENTER RELEASE
D~SVGN369R
Enter 34.
message
If
the release
NU~BER
level of the
OF THE DOS/VS STARTER SYSTE":
you enter an unsupported release number,
D~SVGN379E
DOS/VS starter
you receive the
INVALID - RELEASE 31 OR LATER REQUIRED
an d the VS AMGEN EXEC procedure is terminated.
You are now prompted to indicate whether you
access method services or both:
D"SVGN264R ENTER
'CMSVSA~'
want to install
VSA" or
OR 'CMSA"S' OR 'BOTH' FOR GENERATION OF
l1EW SY STEM (S)
If you receive the message:
D~SCPY002E
INPUT FILE 'VSA"33 DOSLNK
the probable cause is that the system
read-only extension of your A-disk.
Next, VSA5GEN issues a message asking
relocatable library:
DMSVGN362R ENTER "ODE OF DOS
SYSTE~
*'
NOT FOUND
disk
is
not accessed
as
a
you to identify the DOS system
RELOCATABLE LIBRARY DISK:
Respond with the filemode of the DOS/VS starter system disk, which you
linked to and accessed before invoking VSAMGEN.
If the filemode you
enter is not the filemode of a DOS disk, you receive an error message
and VSAMGEN processing is terminated.
D~SVGN361E
DISK 'fm' IS NOT A DOS DISK.
The System Name Table (D~KSNT) provided with the
was created assuming DOS/VS Release 34.
VM/370 Starter System
VSAAGEN checks that the files it requires are on an accessed disk;
these required files are shipped on the CMS system disk.
VSAftGEN next
invokes the C~S/DOS environment and makes the DOS/VS starter system disk
available as the DOS/VS system residence volume.
For as users only, VSA~GEN invokes the RSERV command and creates CftS
text files for all the required VSAft and access method services modules
in the DOS/VS relocatable library. The as users of VSAft and access
method services thus are not required to keep the DOS/VS starter system
disk. as users can update VSA~ and access method services directly on
the CMS A-disk. as users receive the following messages:
D~SVGN3611
CREATING
D~SVGN3601
C~S/VSAM
TEXT FILES •••
TEXT FILES CREATED ON DISK 'A'.
C~S
For both OS and DOS users, VSAMGEN then link-edits
and places them in a CMS phase library called C~SVSAM
time you receive the following information messages:
the VSAM modules
DOSLIB.
At this
DMSVGN3621 LINK-EDITING CMSVSAM •••
D~SVGN3631 C~SVSA~ DOSLIB CREATED ON DISK 'A'.
Part 3. Generating Vft/370
(CP,
C~S,
RSCS, and IPCS)
273
Loading and Saving Discontiguous Saved Segments
Note that DOS linkage editor messages
(if they occur) are written to
the virtual console as well as the linkage editor map during VSAMGEN
processing. Information messages
(I-level, return code = 4) may occur
due to C~S phase construction and will not cause the EXEC to terminate
execution.
Next you must respond to the VSAMGEN message:
DMSVGN370R ENTER 'GO' IF SAVED SYSTEM IS TO BE CREATED,
OTHERWISE 'QUIT'
At this time the DOSLIB has been created and if you do not require
the link-edit listing, enter 'GO'. However, if you desire to modify the
VSAM or AMS systems, enter 'QUIT'. This will preserve the DOSLIB on
your A-disk and you can wait until you have the link-edit listing before
continuing. If you responded 'BOTH' to message DMSVGN264R,
the EXEC
will then create the CMSAMS DOSLIB. When you are ready to continue,
invoke the VSAMGEN EXEC and reply RESTART to the message:
DMSVGN360R ENTER 'INSTALL', 'UPDATE' OR 'RESTART'
making sure that the required DOSLIBs are
the succeeding messages as before.
on your A-disk and
reply to
Next you must respond to a VSAMGEN message and enter the load address
for CMSVSAM. This address must be entered in hexadecimal characters; it
must be an address beyond the size of the virtual machines that will
attach it. The prompting message is:
DMSVGN363R ENTER LOCATION WHERE CMSVSAM WILL BE LOADED AND SAVED:
If your installation DMKSNT was defined to be identical to the example
shown in Figure 31 you would enter:
110000 (1088K). If you enter the
load address incorrectly, you receive the message:
DMSVGN360E INVALID RESPONSE 'location'.
VSAMGEN fetches the VSAM modules and
specified. You receive the message:
loads them at the
followed by messages from the FETCH command describing
of the modules being fetched. Now the message:
address you
the entry point
DMSVGN371R system IS LOADED, IF ZAPS ARE TO BE APPLIED
GO INTO 'Cpt MODE, ELSE 'NULL'
is issued. The system has been loaded into the location requested and
if no modifications are required press the ENTER key. If modifications
to the system are required, press the ATTENTION key to enter CP mode and
make the desired modifications; then enter BEGIN to return to CMS mode
and press the ENTER key.
Next you must respond to a VSAMGEN message
with the name of your installation's VSAM segment.
DMSVGN366R ENTER NAME OF SYSTEM TO BE SAVED:
In this example you respond:
cmsvsam
274
IBM VM/370 Planning and System Generation Guide
Loading and Saving Discontiguous Saved Segments
VSAMGEN assigns a storage protection key of X'F' to the first five
segments, the shared portion of VSAM, and a storage. protection key of
I'E' to the last segment, the nonshared portion of VSAM. Then VSAMGEN
saves VS AM.
VSAMGEN issues the following message, which indicates
discontiguous segments are saved.
that the VSAM
DMSVGN365I SYSTEM segmentname SAVED
VSAMGEN then issues the following message to ask you if
to erase the DOSLIB that it created:
you want it
DMSVGN368R ERASE CMSVSAM DOSLIB? ENTER "YES" OR "NO":
Answer "yes" unless
you are using a larger minidisk
than MAINT 191.
otherwise, there will not be enough disk space for C5SAnS construction.
If any errors occur during the VSAMGEN procedure, the
required to complete the procedure is as follows:
!Qi~
action
1.
If an error occurred before message DMKSVGN364R was issued you must
reinvoke the VSAMGEN EIEC.
2.
If an error occurred before any DOSLIBs were created, you can
reinvoke the VSAMGEN
EXEC and respond 'UPDATE'
to message
DMSVGN360R. The system will then prompt you for the systems to be
generated and ask if tape or cards are to be used for the PTF
application. Respond 'CARDS' and when a request for the module
name is presented, enter 'END'. The system will then start
creating DOSLIBs.
3.
If an error occurred after a DOSLIB was created you can reinvoke
the VSAMGEN EXEC and respond 'RESTART' to message DMSVGN360R.
4.
If an error occurred after the CMSVSAM DOSLIB was created and you
had entered iBOTHi to message DMSVGN264R, you can reinvoke the
VSAMGEN EXEC, respond 'CMSVSAM' to message DMSVGN264R and respond
'RESTART' to message DMSVGN360R.
Once the CMSVSAM segment is
saved, reinvoke the VSAMGEN EXEC, respond 'UPDATE' to message
DMKSVGN360R and proceed as in step 2 to create the CMSAMS segment.
VSAMGEN then continues by installing the access method services
segments. VSAMGEN link-edits the access method services modules and
places· them in a CMS phase library called CMSAMS DOSLIB.
You receive
the following messages:
DMSVGN365I LINK-EDITING CMSAMS •••
DMSVGN363I CMSAMS DOSLIB CREATED ON DISK 'A'.
Note: While VSAMGEN is installing access method services,
information messages and the linkage editor continues.
A
greater than 4 causes VSAMGEN to terminate.
you receive
return code
You are then prompted to enter the load address for the access method
services segments.
DMSVGN363R ENTER LOCATION WHERE CMSAMS WILL BE LOADED AND SAVED:
In this example, enter: 170000 (1472K).
Part 3. Generating VM/370
(CP, CMS, RSCS, and IPCS)
215
Loading and Saving Discontiguous Saved Segments
VSAKGEN fetches the access method service modules, loads the modules
at the designated address, assigns a storage protection key of X'F' to
the first six segments, and a key of X'E' to the last two segments.
Then VSAMGEN saves the access method services segments. You receive the
message
followed by messages from the FETCH command describing
of the modules being fetched.
VSA~GEN
then prompts
you for the name of the
the entry point
access method services
segments.
In this example, enter:
cmsams
Then VSAMGEN saves the access method services segments.
A message:
DKSVGN3651 SYSTEK segmentname SAVED
is issued to indicate that
successfully saved.
the
access method
services segments
VSAMGEN then issues the following message to ask you if
to erase the DOSLIB that it created:
are
you want it
DMSVGN368R ERASE CKSAMS DOSLIB? ENTER "YES" OR "NO":
Answer "yes" unless you are using a larger minidisk than MAINT 191.
Loading and Saving the CMS/DOS Segment Called
CMSDOS
To load and save the CKS/DOS segment called CMSnOS, use the same EXEC
procedure, DOSGEN, that you used to load and save the CKS/DOS segment
called INSTVS AM.
If you plan to load the 64K CMS/DOS segment called CMSDOS at 1984K
(lFOOOO), as in the example shown in Figure 31, your virtual machine
size must be at least 2112K. Access the CMS system disk as anything (A
through G) •
Save the CKS/DOS segment called CKSDOS by issuing the command:
dosgen lFOOOO cmsdos
DOSGEN checks that the address
than X'20000', and less than 16K.
contains valid characters, is greater
If an error is detected, the message
DMSGEN095E INVALID ADDRESS 'address'
is issued and the command is terminated.
DOSGEN then checks for a read/write A-disk on which to write the CKS
loader work file; if none is accessed, it issues an error message and
terminat es.
DMSGEN006E NO READ/WRITE A-DISK ACCESSED
216
IBK VK/310 Planning and System Generation Guide
Loading and Saving Discontiguous Saved Segments
Next, DOSGEN loads all the text files needed for DOS simulation. The
text files are loaded starting at the address specified on the DOSGEN
command.
If there are any unresolved external references, DOSGEN
terminates execution with the message
DMSGEN111E DOSGEN FAILED DUE TO LOAD ERRORS
DOSGEN then assigns a storage key of X'D' to the segment
it. If an error is detected, one of the following messages
and DOSGEN terminates execution:
and saves
is issued
DMSGEN412S DOSGEN FAILED DUE TO SETKEY ERRORS
DMSGEN141S DOSGEN FAILED DUE TO SAVESYS ERRORS
Otherwise, the segment is successfully saved,
printed, and the completion message:
the
load
map
is
DMSGEN715I DOSGEN COMPLETE
is issued.
The system name entry in the SYSNAMES table defaults to CMSDOS.
At this point you have completed the procedures for loading and
saving the discontiguous saved segments that are defined in the DMKSNT
module supplied with the starter system_ If you wish to load and save
other discontiguous saved segments, you must have created other DKKSNT
entries for them, and you now must repeat these procedures for those
entries.
You can now go on to generate and install the
VM/310 SCP, if you wish.
Part 3. Generating VM/370
RSCS component of the
(CP, CKS, RSCS, and IPCS)
277
278
IB~
V~/370
Planning and System Generation Guide
RSCS Generation Procedure
Generating and Installing RSCS
General Information
The data and control files required to generate and install RSCS are
contained in the starter system maintenance areas of the VM/310 system.
RSCS data, consists of the following. On MAINT 194:
File
DMTixx
TEXT
Contents
The--pre-assembled
nucleus modules
routines required to generate RSCS are:
DMTASY, DMTCMX, DMTCOM, DMTCRE, DMTDSP,
DMTINI, DMTIOM, DMTMAP, DMTMGX, DMTMSG,
DMTREX, DMTSIG, DMTSTO, DMTSVC, DMTVEC,
and supervisor
DMTAK E, DMTASK,
DMTEXT, DMTGIV,
DMTPST, DMTQRQ,
and DMTWAT.
DMTAXS TEXT
The spool file access method supervisor task.
DliTLAX TEXT
The communication line allocation supervisor task.
DMTNPT TEXT
The Nonprogrammable Terminal (NPT)
DMTSML TEXT
The Spool MULTI-LEAVING
DMTLOAD EXEC
The loadlist EXEC file.
This file is required
generate an RSCS nucleus on the RSCS system disk.
DMTSYS ASSEMBLE
The RSCS configuration table module.
This file must be
assembled with the COpy files you create to define your
RSCS
configuration
(the
AXSLINKS, LAXLINES,
and
TAGQUEUE COpy files).
DMT MAC MACLIB
The file containing all the macros needed
the RSCS source files.
DMTRno
The control file that is needed to assemble
configuration table via the VMFASM EXEC procedure.
DMTMAC
1
CNTRL
EXEC
(SML)
line driver module.
line driver module.
to
to assemble
the
An EXEC file used to generate the DMTMAC MACLIB.
On the VM/370 SOURCE tape:
DMTxxx ASSEMBLE
All the source files for RSCS. There is
file for each TEXT file previously listed.
Also, t he SOURCE tape contains all the
the DMT PI AC macro library.
an ASSEMBLE
macro and copy files included in
-----.---
ID~T
- - -----may
be DMTR 10, DMTR20,
releas e
level.
Rn 0
DMTR30 and
Part 3. Generating Vl1/310
so forth, depending
on the
(CP, CMS, RSCS, and IPCS)
279
RSCS Generation Procedure
The AXSLINKS COpy file is a list of 1 to 64 GENLINK macro statements.
The GENLINK macro defines the attributes of a link.
The first GENLINK
macro in the AXSLINKS file must contain the ID of the local RSCS
station. You must also code the TYPE=driverid operand with a valid
filename on this first GENLINK macro.
You should code additional
GENLINK macros, with no operands, for links you may want to define
temporarily during an operating session.
The format of the GENLINK macro is:
r-----------------------------I r
I
, GENLINK I I ID=linkid, TYPE=dri verid[
,
[
I
I
[
I
,
[
I
I L
,
,
,CLASS=c]
, KEEP=holdslot]
, LI NE=vaddr ]
,TASK=taskname]
I
1
I
I
J
L
ID=linkid is a 1- to 8-character alphameric location ID of the remote
location to be served by the link.
If this operand is not
specified, the ID defaults to "undefined."
TYPE=driverid
is a eMS filename of a file which is the TEXT file for the
line driver p~o9tam to be used to process files fo~ the link.
The appropriate line dr iver program to be specified depends on
the type of remote telecommunications facilities to be used.
The TYPE operand must b~ specified if ID~linkid is coded.
the TYPE operand is omitted, TYPE defaults to "undefined".
CLASS=c
If
is the spooling class (es) of the files which can be processed
by the active link. ,-You can specify up to four spooling
classes (single alphameric characters from A to Z and 0 to 9)
with no intervening blanks, or *, which means all spool file
classes may be processe~.
If the CLASS operand is not
specified, the default is "*".
KEEP=holdslot
is a decimal number from 0 to 16 which designates the number
of virtual storage file tag slots to be reserved for exclusive
use by the link.
If the KEEP operand is omitted, a default
"holdslot" value of 2 is assumed.
LINE=vaddr
designates the
virtual device
address of
a permanent
telecommunications line port, to bensed for processing files
on the' link.
If the LINE operand is omifteo.,
the defaul t 'is
"undefined".
TASK=taskname
is a 1- to 4-character alphameric identifier.
It specifies
the task name to be used by the line driver associated with
the link.
If the TASK operand is omitted, the default is
"undefined".
Part 3. Generating VM/370 (CP, eMS, RSCS, and IPCS)
281
RSCS Generation Procedure
CREATING THE LAXLINES COPY FILE
The LAXLINES COPY file defines the virtual device addresses of the
telecommunications line ports (attached to the RSCS virtual machine)
which may be shared among the various active links. Such line ports
must be switch able, and the links which are to use these line ports must
have switched line ports available at their remQte stations.
The LAXLINES COpy file consists of
a list of GENLINE macro
statements, one for each line port. The format of the GENLINE macro is
as follows:
r
,
I GENLINE I LINE=vaddr
,
L __________________- -_____________
LINE=vaddr
is the virtual device address of a switched telecommunications
line port available to RSCS.
CREATING THE TAGQUEUE COPY
FI~E
The TAG QUEUE COPY file specifies the total number of virtual storage tag
slots to be available to RSCS. The format of the GENTAGQ macro is:
r
I GENT AGQ
Nurr=totslots
L
NU"=totslots
is a decimal number from~32 to 512 that defines the total
number of . virtual storage"tag slots to'·be made available to
RSCS
for storing
inforntion
on
'f·iles enqueued
for
transmission or received froa! remote stat~ns.
Files which
cannot be enqueued for transm~ssion because 'no free virtual
storage tag slots aretavailabl>e are left pending, and are
automatically accepted ~? enqUea~d.. a. t a later time as virtual
storage tag slots becom~~vailable.
You must specify a numbet for totslots that is at least as
large as the sum of linkijtag slots ~efined or implied by the
KEEP=holdslot operand of all the GENLII~ macros.
Generation Procedure forRSCS
Before you perform
following:
the RSCS generation procedure, be sure
you have the
•
The V!/370 system PUT tape
•
A V"/370 directory entry for your RSCS virtual machine
•
A V"/370 directory entry for the software system support virtual
machine (for example, the MAINT entry supplied with the VM/370
starter system directory).
282
IB! VM/370 Planning and System Generation Guide
RSCS Generation Procedure
You can use a 2314, 3330, 3340, or 3350 disk as the RSCS system disk.
The RSCS nucleus occupies two cylinders on a 2314 or 3340, and one
cylinder on a 3330 or 3350 disk.
The following system generation procedure for RSCS assumes you have
the "AINT virtual machine supplied with the V8/370 starter system in
your VM/370 directory.
STEP 1. LOG ON AS MAINT AND IPL CMS
To build the RSCS nucleus, you must log on the
virtual machine (MAINT) and IPL the CMS system.
software system support
logon maint cpcms
ipl 190
STEP 2. APPLY THE RSCS UPDATES FROM THE VM/370 PROGRAM UPDATE TAPE
Press the carriage return to complete IPL.
Mount the system PUT and attach to MAINT as 181.
initiated by issuing the commands:
Service for RSCS is
access 191 c
vmserv restart 5749010 rscs noipl
The keyword "rscs" allows the procedure
(from the system PUT) for RSCS.
to load
wha t is
required
You are prompted for 'various information concerning your system
(including staging area addresses and the service that you want
applied).
Respond 'NO' when asked if you wish service for IPCS.
Service for IPCS has already been applied. The user memOs 'and the PUT
document should be referenced concerning the application of service with
the VMSERV EXEC.
After service has been applied, you will receive this message:
DO YOU WISH TO BUILD RSCS SYSTEM -- RESPOND (YESINO)
You must respond "no".
STEP 3. FORMAT THE RSCS SYSTEM DISK
You must link to the RSCS system disk and format it. If you used the
VM/370 directory entry for the RSCS virtual machine supplied with the
starter system, your LINK command is:
link to rscs 191 as 195 w pass= password
This makes the Rses system disk
(address 191 in the Rses virtual
machine) available at virtual address 195 in the MAINT virtual machine.
Remember the address you specify for MAINT. You must use this same
virtual address later in the RSCS generation procedure (you use 195 when
you invoke GENERATE again to build the RSCS nucleus in Step 7). Then,
format the RSCS system disk.
format 195 a
Part 3. Generating VM/370
(CP, CMS, RSCS, and IPCS)
283
RSCS Generation Procedure
Next, format the RSCS system disk again. You must use the recompute
function of the FORMAT command to make the last cylinders of the RSCS
system disk unavailable to the CMS file system.
The last one or two
cylinders contain the RSCS nucleus. If the RSCS system disk is a 2314
or 3340, the last two cylinders are needed for the nucleus. For a 3330
or 3350, only the last cylinder is needed.
The FORMAT command for a
2314 or 3340 RSCS system disk is:
format 195 a 3 (recomp
The FORMAT command for a 3330 or 3350 RSCS system disk is:
format 195 a 4 (recomp
STEP 4. CREATE THE COpy FILES THAT DEFINE YOUR RSCS SYSTEM
~s~ the
~~s Editor to
YOu need:
AXSLINKS, LAXLINES, and TAGQUEUE.
The macros you need to include in
these files are described in a preceding section, "Defining Your RSCS
System."
When you code the GENLINK macros for the AXSLINKS COpy file, you may
include GENLINK macros with no operands.
These macros reserve extra
link table entries which can be defined later with the RSCS DEFINE
command.
Also, the local linkid (local location ID)
must be specified
on the first GENLINK macro in the AXSLINKS file.
When you code the GENTAGQ macro for the TAGQUEUE COPY file, remember
that the total number of tag slots must be equal to or greater than the
number of holdslots defined either explicitly or implicitly in the
AXSLINKS COpy file.
The following example
and TAGQUEUE COPY files:
shows the creation of
the AXSLINKS, LAXLINES,
edit axslinks copy
NEW FILE:
EDIT:
input
INPUT:
*copy axslinks
genlink id=mylocid,type=dmtnpt
genlink id=newyork,class=a,keep=2,line=079,task=m1,type=dmtnpt
genlink id=sanfran,class=a,keep=2,line=07a,task=m2,type=dmtsml
genlink id=london,class=a,keep=4,line=07b,type=dmtsml
genlink
genlink
genlink
EDIT:
file
R;
284
IBM VM/370 Planning and System Generation Guide
RSCS Generation Procedure
On the TYPE operand, DMTNPT refers to the Nonprogrammable Terminal (NPT)
line driver program and DMTSML refers to the Spool MULTI-LEAVING (SML)
line driver program.
edit laxlines copy
NEW FILE:
EDIT:
input
INPUT:
*copy lax lines
genline line=079
genline line=07a
genline line=07b
genline line=07c
genline line=07d
genline line=07e
genline line=07f
EDIT:
file
R;
edit tagqueue copy
NEW FILE:
EDIT:
input
INPUT:
*copy tagqueue
gentagq num=32
EDIT:
file
R;
STEP 5. CREATE THE DMTLOC MACRO LIBRARY
Using the COpy files created in Step 4,
called DMTLOC MACLIB, as follows:
generate a CMS
macro library
maclib gen dmtloc axslinks laxlines tagqueue
If you must change your RSCS configuration at a later time, you have
to change the COpy file and then generate a new DMTLOC macro library.
STEP 6. ASSEMBLE THE CONFIGURATION TABLE (DMTSYS)
Before you assemble the configuration table module, access the staging
area disk (194) as an extension of the RSCS system disk.
access 194 b/a
DMSACC7231 B (194) RIO
NOw, assemble the RSCS configuration table module (DMTSYS)
using the
VMFASM EXEC procedure. Specify DMTRnO as the control file.
This
control file identifies DMTLOC as the macro library to be used during
the assembly. The DMTRnO control file is on the 194 minidisk. Invoke
VMFASM as follows:
VMFASM DMTSYS DMTRnO
Nol~ If an error occurs due to
macro and restart at Step 5.
an incorrectly coded macro, correct the
Part 3. Generating VM/370 (CP, CMS, RSCS, and IPCS)
285
RSCS Generation Procedure
STEP
7.
INVOKE GENERATE TO CREATE THE RSCS NUCLEUS
Invoke GENERATE to build the RSCS system nucleus as follows:
generate rscs build
GENERATE prompts you
system disk:
for the operands it
needs to link to
the RSCS
ENTER RSCS SYSTEM DISK LINK PARAMETERS:
USERID VADDRl VADDR2
If you are following the examples in this procedure, you enter
rscs 191 195
The value you enter for vaddr2 must be the same value you specified for
vaddr2 on the LINK command issued in Step 3; otherwise, the link is not
allo~ea.
The use~ia you specify is the use~id of you~ RSCS virtual
machine and the virtual address you specify for vaddr1 is the virtual
device address of the RSCS system disk in the RSCS virtual machine. You
will be prompted for the write password of the disk.
GENERATE then links to the RSCS system disk and copies four files
(DMTNPT, DKTSKL, DMTAXS, and DMTLAX) to it. You receive the following
message:
TRANSFERRING 'RSCS' DISK RESIDENT TEXT •••
Finally, GENERATE builds and loads the
following messages:
RSCS nucleus.
You
receive the
DMTINI406R SYSTEM DISK ADDRESS = 195
DKTINI407R REWRITE THE NUCLEUS ? yes
DKTINI409R NUCLEUS CYL ADDRESS = 003
(for a 2314 or 3340, or 004
for a 3330 or 3350)
DKTINI410R ALSO IPL CYLINDER 0 (YES I NO) ? yes
For this example, respond as shown. You respond with the address of the
RSCS system disk, in this case 195.
You always respond with the same
address you specified as vaddr2 when you were prompted for link
parameters. The nucleus cylinder address depends on the device type of
the RSCS system disk.
You receive the message
DKTAXS103E FILE 'spoo1id' REJECTED -- INVALID DESTINATION ADDRESS
This message
reader.
reflects the
purging of
the RSCS
nucleus from
At this time you have an RSCS system generated and written
RSCS system disk, as indicated by the message:
the card
to the
DMTREXOOOI RSCS (VER n, LEV n, mm/dd/yy) READY
You can now log on the RSCS virtual machine, IPL the
and start your RSCS operations. See the VM/37Q E~CS
information about using RSCS.
286
IBM VM/370 Planning and System Generation Guide
RSCS system disk
Quid~ for
~~~~
IPCS Generation Procedure
Generating and Installing IPCS
The V~/Interactive Problem Control System Extension (VM/IPCS Extension)
program product can be ordered separately. It is not to be confused
with the Interactive Problem Control System (IPCS) component of VM/370.
V~/IPCS Extension
provides installations with expanded facilities for
reporting and diagnosing software failure.
If you have installed this
program, see the VML170 l!!~er~£~i~ .frobl~.!!! C01!.!.Iol ~I§~em ~xten§io!l
Us~r's Quide ~ng ReI~~~nce, Order No. SC34-2020.
Generation Procedure for !PCS
The IPCS function exists on the Starter System S-disk and requires no
special installation procedure.
Should it become necessary to update
the IPCS function the following procedure may be used.
Before you perform
IPCS generation procedure, be sure
VM/370 directory entry for your IPCS virtual machine.
you have the
STEP 1. LOG ON AS MAINT AND IPl CMS
To load the IPCS command modules and EXEC procedures,
log on
software support virtual machine (MAINT) and IPL the CMS system.
as the
logon maint cpcms
ipl 190
STEP 2. FORMAT THE IPCS VIRTUAL
~ACHINE
191 DISK
If the IPCS virtual machine
(OPERATNS in our exa mple)
191 disk has
already been formatted, you may proceed directly to Step 3.
If it has
not, you must link to the IPCS virtual machine 191 disk and format it.
The LINK command you use is:
link to operatns 191 as 195 w password
where password is the WRITE password of the OPERATNS 191 disk.
This makes the IPCS virtual machine 191 disk available at virtual
address 195 to the MAINT virtual machine.
Next, format the IPCS virtual
machine 191 disk.
format 195 a
Reply 'YES' to the prompt "DO YOU
six-character label when requested.
WISH
Part 3. Generating VM/370
TO CONTINUE"
and
give
(CP, CMS, RSCS, and IPCS)
a
287
IPCS Generation Procedure
STEP 3. APPLY THE IPCS UPDATED FILES FROM THE PUT
The required service for IPCS
system is now ready for use.
288
has been applied
in Step 23.
IBM VM/370 Planning and System Generation Guide
The IPCS
Part 4. Generating the 3704/3705 Control
Program
If you do not want to support a 3704/3705 control
control, disregard Part 4.
program under VK/370
Part 4 describes the procedures you must follow to generate, test,
and run a 3704/3705 control program with VK/370.
It includes the
following information:
•
•
•
Introduction
Planning Considerations
Generating and Loading the 3704/3705 Control Program
You should generate a VM/370 system that supports the 3704/3705
first.
"Part 1. Planning for System Generation" contains a section,
"Generating a VK/370 System that Supports the 3704 and 3705," that tells
you what you must include in your VM/370 system. When you have a VM/370
system that supports the 3704/3705, use the information in this part to
generate and test a 3704/3705 control program that runs under VM/370
con trol.
Part 4. Generating the 3704/3705 Control Program
289
2QO
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
Introduction to the IBM 3704 and 3705
Communications Controllers
The IBM 3704 and 3705 Communications Controllers are programmable units.
The Emulation program can be generated to execute in 3704/3705 storage.
The Emulation program (EP) permits existing teleprocessing systems,
including VM/370,
that use the IBM 2701, 2702, or 2703 Transmission
Control Units, the 2703 Compatible Communications Adapter of the 4331
processor, or the Integrated Communications Adapter
(ICA)
of the
System/370 Models 135, 135-3, and 138 to execute without change on the
3704/3705.
In this publication, the term "3704/3705 control program" refers to
the EP control program.
VM/370 supports the:
•
•
•
IBM 3704 Communications Controller, Models 11-A4
IBM 3705-1 Communications Ccntroller, Models A1-D8
IBM 3705-11 Communications Controller, Models E1-H8
when attached to a VM/370 processor.
Three terminals are supported:
1050, 2741, and CPT-TWX 33/35. The 3767 terminal (operating as a 2741)
is supported by lines in EP mode, and the 3101 display terminals are
supported as CPT-TWX 33/35.
The minimum required by an EP control program is 16K.
Part 4. Generating the 3704/3705 Control Program
291
March 3, 1980
292
IBM VM/370 Planning and System Generation Guide
3704/3705 Control Program
Planning Considerations for the 3704/3705
Control Program
When planning for the installation of IBM 3704 and 3705 Communications
Controllers, be sure that you are familiar with device characteristics,
have the the appropriate publications and support package, and have a
VM/370 system that supports the 3704/3705.
Related Publications
The In.troductiQn to 1he 11.H1 lIQ.!!' and JIO 5 fQJ!!!1.!!ni~ tiQn.§ Con!rollek:§.L
Order No. GA27-3051, describes the general functions of the
3704 and
3705.
It is a prerequisite publications for generating a 3704/3705
control program under VM/370.
If you
are installing Version 4
37Q!
of the Network
Control Program/VS,
I~~
End 1105 Co~~~ication.§ Controller~ Ne1~k:~ Cont!Ql
g£Q.qramL~
Q~~rati2n Eng
!!tilities Quig~ ,gnd Refeg1!£~ Malli!~! 1f2k:
Q~LVS gnd
DO~L!~ 1fA~
USe!.§LL Order No. GC30-3007, is a corequisite
the
publication. If you are installing Version 4 of the Network Control
Program/VS, the IB~ 1104 Eng lIQ.~ Comm~nication.§ fQntXQ!ler~ Netw0k:~
£on!rol Prog£,g~VS g~neratiQn ang Utilitie.§.L Guig~ ,~g Referen£g Many~!
lfok: OSLVS ,gng DOSL!~ VT!~ US~§lL Order No. GC20-3008, is a corequisite
publication. You must refer to one of these publications in order to
code the 3704/3705 control program generation macros.
Throughout Part
4, these publications are referred to as the J1Q! gj!g lI05 Q~~!iQ.!l
gnd utiliti~ Guig~.
3704 and 3705 Support Package
Before you can generate a 3704/3705 control program, you must have
following OS/VS Network Control Program Support Package.
This is
only 3 7 04/3705 support package that contains the CMS file required
generating and loading the 3704/3705 control program under VM/370.
support package is:
•
the
the
for
The
IBM 3704/3705 Emulation Support and System Support Package
(EP/VS
SCP) for OS/VS (order No. 5744-AN1).
VM/370 supports this package in
emulation mode only.
This package contains the following basic material:
•
A Program Directory
•
IBM 3704 and 3705
~2~munication.§
Controller~
Ne1work Control
Pr0.9:k:.M1LVS genera1ion and Qtilities, Guide and ~~!er~!!ce ManMl (fok:
OS/VS gnd ~OSLVS 1~AM Use!~ Order No. GC30-3007
-- or
Part 4. Generating the 3704/3705 Control Program
293
3704/3 7 05 Control Program
170~
£ont£Q!
R~nel
•
IBM
Guide L Order No. GA27-3086.
•
1]] 1705 £ont£ol g~nel ~~ide, Order No. GA27-3087.
•
Magnetic tape containing the macros and modules of the
control program and the OS/VS system support programs.
3704/3705
VM/370 Support of the 3704 and 3705
The IBM 3704/3705 Communications Controllers can support:
~~eeu
~ldll-~tvp
•
Up to 352 low
•
Up to 60 medium speed synchronous lines
•
Line speeds from 45.2 baud to 56.0K baud
•
"odem capability within the 3704/3705
•
Limited-distance "hard-wire" capability
•
16K to 256K internal storage
•
Remote 3275, 3276, 3277 and 3278 terminals with optional 3284, 3286,
32 7 7, 3288 and 3279 printers (EP mode only)
•
Remote 2780 terminals (EP mode only)
1.
liu€s
Emulator Program (EP) Version 3.0.
V"/370's support of the 3704/3705 does not include:
•
Remote 3704/3705 Communications Controllers
E"ULATION PROGRA" (EP) WITH V"/370
The EP 3704/3705 control program under V"/370:
•
Emulates 2701, 2702, and 2703 operations
•
At~ches
•
Supports up to 255 start-stop
(33/35) terminals
•
Supports up
terminals
294
to a System/370 byte multiplexer channel
lines
for 1050,
to 50 medium-speed synchronous
2741, and
lines for 3270
IBM VM/370 Planning and System Generation Guide
CPT-TWX
and 2780
3704/3705 Control Program
This support is equivalent to that provided in Release 1 of Vft/370.
The CP DIAL command and the TERftINAL APL ON and APL OFF command lines
are supported. However, Release 2
and above of Vft/370 provides
additional support:
•
Service programs and special eMS commands allow you
generate the EP control program in a CMS virtual machine.
to
easily
•
The CP NETWORK command allows you to load or dump the 3704/3705 and
provides for automatic dumping and reloading if a fatal error occurs.
Part 4. Generating the 3704/3705 Control Program
295
296
IBM VM/370 Planning and System Generation Guide
3104/3105 Control Program
Generating and Loading the 3704/3705
Control Program
Several commands and EXEC procedures generate and load the 3104/3105
control program. These commands and EXEC procedures are executed in a
eMS virtual machine. The commands are a part of the VM/310 system and
are distributed with it.
A special version of the IBM 3104/3105 Network Control Program
Support Package for OS/VS, Order No.
5144-ANl EP/VS SCP is available
from PID for use under VM/310.
This version of the 3104/3705 package
contains two CMS EXEC procedures for generating and loading the
3704/3705 control programs.
This section describes the step by step procedure for generating and
loading the 3704/3105 control program.
Each EXEC procedure and command
is described as it is used.
The action required at each step is
summarized first and then explained in detail. The preceding "Planning
Considerations" section, lists all the documentation, physical devices,
programming, and other materials you need before starting to generate
the 37 04/3705 control program.
Step 1. Log On the VM/370 System
VM/370 supports the EP type of control program.
you load also must have been generated with:
The VM/370 system that
•
The IBM 3104 or 3105 Communications
RDEVICE system generation macro.
•
The NAMENCP macro coded to create an entry in the VM/310 system name
table (DMKSNT) for the 3104/3105 control program.
•
Space reserved on a CP-owned
3704/3105 control program.
volume
Controllers specified
to
contain
a copy
on
of
a
the
These VM/310 system generation requirements are described in Part 1.
Step 2. Set Up a eMS Virtual Machine
You must IPL a CMS virtual machine
devices are attached.
and
be sure
that the
necessary
The 3104/3105 control program is generated using commands and EXEC
procedures that execute in a CMS virtual machine.
The C8S virtual
machine must have the following resources:
•
At least 1024K of virtual storage.
•
One tape drive (9 track, 800 or 1600 bpi).
•
Space available on the C8S A-disk (120 cylinders of a 3330 disk, all
203 cylinders of a 2314 disk, 300 cylinders of a 3340 disk, or 60
cylinders of a 3350 disk.
Part 4. Generating the 3104/3105 Control Program
291
3704/3705 Control Program
If the CftS virtual machine does not have these resources, use the CP
DEFINE command to redefine the size of your virtual storage or send a
message to the operator requesting him to attach the tape or disk device
you .need.
Be sure that there are no files on the A-disk with a filetype of COpy
or TEXT. Use the CftS RENAftE command to temporarily change such
fi1etypes.
A naming conflict can terminate the installation procedure
for the distribution tape.
You need CP command privilege classes A, B, and G to install the
3704/3705 control program and,
if you use the NETWORK TRACE command
while testing the 3704/3705 control program, you need command privilege
class F.
Do not use class F unless you need it; for class F, I/O error
recording
is not
done automatically.
Check
wi th the
system
administrator to ensure that your Vft/370 directory entry has the
appropriate command privileges.
Step 3. Load the IBM 3704/3705 Control Program
Distribution Tape Files onto a eMS Disk
Use CMS commands to position the distribution tape at the proper file
and to create CftS disk files from the tape files.
The first file
created from the tap~ files is an EXEC procedure that processes the rest
of the tape files and creates the CftS disk files.
If you cannot mount the distribution tape yourself, send a message to
the operator and have him mount the correct tape. The distribution tape
contains ten files.
The tenth file contains the INSTEP and ARNGEND EXEC
procedures, which create the necessary CMS files from the other tape
files.
Use the CftS TAPE command to position the tape at the beginning of the
tenth file:
tape fsf 9
Then, use the CftS TAPPDS command to create
ARNGEND EXEC A1 files from the tenth file:
tappds
*
the INSTEP
EXEC A1
and
exec
If the files are successfully created, the responses
FILE
FILE
FILE
FILE
FILE
FILE
' ARNGEND
• DftS ARD
'DMSARX
'DMSGRN
'DMSTMA
'INSTEP
EXEC
EXEC
EXEC
EXEC
EXEC
EXEC
A1'
A1 '
A1'
A1'
Al'
Al'
COPIED
COPIED
COPIED
COPIED
COPIED
COPIED
appear on the terminal. Before you invoke the INSTEP EXEC procedure,
you should obtain access to mode 1 files on the CftS system disk. You
can do this by accessing it as an extension of your A-disk; for example,
if the S-disk is at virtual address 190, and you currently have a disk
accessed as mode C, you issue the command
access 190 cia
298
IBft VM/370 Planning and system Generation Guide
3704/3705 Control Program
Invoke the INSTEP EXEC procedure to
gen erat e the 3705 Assembler:
load all the necessary files and
instep
The INSTEP EXEC procedure generates the 3705 Assembler and creates
the macro and text libraries that are needed to generate a 3704/3705
control program.
The INSTEP EXEC procedure sends messages to the
terminal to indicate its progress.
INSTEP issues the message
BUILD STAGE ONE ~ACLIB
LOADING 'GEN3705 MACLIB'
and uses the third tape file to create the CMS
It issues the messages
file GEN3705 MACLIB Al.
BUILD STAGE TWO MACLIBS
LOADING 'MAC3705 ~ACLIB'
using the fifth tape file to create the C~S file MAC3705 MACLIB Al.
Using the sixth tape file, INSTEP creates the CMS file OBJ3705 MACLIB
Al, and issues the messages
BUILD STAGE TWO TXTLIB
LOADING 'OBJ3705 MACLIB'
RENAME OBJ3705 MACLIB Al OBJ3705 TXTLIB Al
Finally, INSTEP issues the message
LOAD 3705 ASSEMBLR FILES
and loads the assembler text files from tape via the TAPPDS command.
The files copied are listed off in messages in the form:
FILE 'fn EPTAPE Al' COPIED
The ARNGEND EXEC procedure is invoked
by INSTEP to generate
Assembler, after issuing the message
BUILD 3705 ASSEMBLR MODULES.
The ARNGEND
messages:
EXEC procedure displays
the following status
and error
ENTER TARGET DISK MODE FOR 3705 ASSEMBLR MODULES
DEFAULTS TO S-DISK IF NONE ENTERED
You enter the mode letter of the disk that will contain the 3705
assembler modules when the assembler is used. This may be a different
disk then the one on which the modules now reside. If you enter a mode
letter, ARNGEND uses that mode letter as the "target.ode" operand of the
GENDIRT command when it creates the auxiliary directory for the 3705
assembler. If you do not specify a mode letter, S is assumed by the
GENDIRT command.
Part 4. Generating the 3704/3705 Control Program
299
3704/3705 Control Program
If the 3705 assembler text files are not loaded successfully, or if
the assembler generation procedure fails, the following message appears.
ASM3705 GEND FAILED
When the last message
END OF EPTAPE INSTALL
appears on the terminal, the distribution tape is no longer needed.
At
this time, the 3705 Assembler program, the macro libraries for the Stage
1 and Stage 2 generation procedures, and the text library for the Stage
2 generation procedure all exist on the CMS A-disk.
Noie: You may find it helpful to dump the contents of the A-disk to tape
at this time. If you save the tape dump, you have the pre-Stage 1
files.
If errors are later encountered, you may need these files.
Step 4. Code the 3704/3705 Control Program Macro
Instructions
Code the 3704/3705 control program macro instructions and place them in
a CMS file.
Use the CMS Editor to create the file, which must have a
filetype of ASM3705.
VM/370 recommends that you assign the same
filename to this CMS file as was specified previously in the NAKENCP
macro. If the SAVE option is to be specified on the GEN3705 command,
the filename must be the same. This ASM3105 file is used as input to
Stage 1 of the 3704/3705 control program generation procedure.
Use the Jl04 g.nS 3705 genergtiQ!! g.ng Y.tiliti~ Guid~ to code the
macro instructions. Follow the macro instruction formats described in
that publication except where suggestions and requirements are indicated
in the following paragraphs.
BUILD MACRO INSTRUCTION
The BUILD macro must be the first macro in the CMS file.
Figure 32
lists the operands which VM/370 requires, recommends, or does not
support. For all other operands, refer to the JI04 g.n~ 1105 Generation
~nd Utilities Guid~.
300
IBM VK/370 Planning and System Generation Guide
3704/3705 Control Program
r
, Operand
I
, LOADLIB=dsname
IOBJLIB=dsname
!
I
{YES }
IJOBCARD= NO
comments
Required by the BUILD macro, but does not
apply to VM/370.
Specify a valid dsname.
IVM/370 recommends
I JOBCARD=YES for EP.
VM/370 requires that the value of NEWNAME be
the same as the name previously specified
in the NAMENCP macro and the name that
subsequently will be specified in the
SAVENCP command. Also, if the GEN3705
command is to be issued with the SAVE
option, the value of NEWNAKE must be the
same as the "fname" specified on the
GEN 3705 command.
NCP001}
NEWNAME= PEP001
{ symbol
QU
VM/370 requires the default value.
ALIFy={~~:~Ol}
SYSl
I
iUT1=dsname
I UT 2=dsname
I UT 3=dsname
VM/370 ignores these operands.
L
Figure 32.
BUILD Macro Operands for VM/370
CSB MACRO INSTRUCTION
The CSB macro instruction is required. See the J70! ~n~
and utiliti~ Guid~ for more information about coding
instruction.
GROUP AND LINE
MlIf"'On
u.Q""'.I.\V
1105 Generation
the CSB
macro
INSTRUCTIONS
These macros describe the physical and logical configuration of the
communications network accessed through the 3704/3705 control program.
Since VM/370 does not support either multi-drop lines or cluster control
units, the 3704/3705 configuration for VM/370 is generally simple, with
only one GROUP macro for each communications scanner. For VM/370, it is
often easiest to specify most of the operands of the LINE macro on the
GROUP macro. The l1Q! ~nd 1105 Generation and Uti!iti~ Guide describes
the GROUP and LINE macro instructions in detail and lists all the
operands of the configuration macros, telling you where each operand is
described and also where it may be coded.
VM/370 requires the DUPLEX and FEATURE operands. These operands
allow V"/370 to detect and respond to a terminal attention interrupt and
to recognize when a data set has been hung up. For the GROUP macro,
VM/370 requires the default value
for the REPLYTO operands and
recommends the default value for the TEXTTO operand.
Part 4. Generating the 3704/3705 Control Program
301
3704/3 7 05 Control Program
GENEND MACRO INSTRUCTION
The GENEND macro indicates the end of the 3704/3705 macro input file.
It must be the last macro in the CMS file you are building as input to
Stage 1.
SPECIAL MACRO CODING CONSIDERATIONS FOR THE EMULATION PROGRAM (EP)
There are no strict dependencies between the host access method and the
emulation program; consequently, few guidelines are necessary for an
emulation program generation.
However, be careful when configuring
emulator lines for CPT-TWX terminals. While VM/370 normally accepts
incoming calls from either 1050 or 2741 terminals on the same physical
line, that same line cannot be used for CPT-TWX terminals.
When
generating the VM/370 system, ensure that the hardware configuration
~r~~ifi~~
in
th~
~p
modul~
DMKPIO
mat~h~~
th~
configuration of
th~
Emulation Program for CPT-TWX lines; the exact configuration of 1050 and
2141 lines is not critical.
Nole: The base address of the 3704/3705 (the address used to load and/or
dump the control program)
can never be specified for use as a
telecommunications line. VM/370 treats the base address as a separate
entity for use only during the load and dump operation.
Step 5. Define the Macro and Text libraries
The macro and text libraries created from the distribution tape in Step
3 must be made available to CftS.
One macro library (GEN3705) is needed
for the Stage 1 generation procedure and one macro library (MAC3705) and
one text library (OBJ3705)
are needed for the Stage 2 generation
procedure. It is easiest to define all the libraries before starting
Stage 1. Use the CMS GLOBAL command:
global maclib gen3705 mac3705
global txt lib obj3705
302
IB~
VM/370 Planning and System Generation Guide
3704/3705 Control
n _____ _
C.LVY.La.w
Step 6. The Stage 1 Generation Procedure
The stage
step q as
1 generation procedure accepts the CMS file you created in
input and produces the stage 2 input file that is needed in
step 7.
The stage 1 generation procedure is performed by invoking the 3105
Assembler to process the 3104/3105 control program macro instructions.
It produces one file with the same filename as the input file and with a
filetype of TEXT.
This TEXT file contains 3105 Assembler source
statements and job control language (JCL) statements.
THE ASM3705 COMMAND
Use the CMS ASM3105 command to invoke the 3105 Assembler to assemble the
macro instruction file. The 3705 Assembler processing and output are
controlled by the options selected. The format of the ASM3705 command
is:
r
1 ASM3705
I
I
fn [ (options ••• [) ]]
i"
r
,
IXR]! ,
INOXREFI
L
.J
r
,
r
,
F
,
ILOAD I
I NOLOADI
I!!IS! I
INOLISTI
L
L
L
L
.J
.J
,
..J
r
.J
J
,
IPRINT I
I
IDISK
INOPRINTI
L
fn
'1
IDECK I
INODECKI
ILINECOUN nnl
ILINE£OUN 551
L
r
IRENT I
I NOR]NTI
J
specifies the filename of th€ source file to be assembled.
This source file contains the 3704/3105 control program macro
instructions. The file must have a filetype of ASK3105 and
fixed-length, SO-character records.
Part 4. Generating the 3104/3705 Control Program
303
370Q/3 7 05 Control Program
If duplicate or conflicting options are specified,
entered in the command line is the one in effect.
includes
file.
a cross-reference
symbol
table
in the
NOXREF
suppresses the cross-reference symbol table.
RENT
checks the source file to
requirements.
suppresses the
requirements.
DECK
for
one
LISTING
satisfies reentrancy
sa tisfact ion
of
reentrancy
spools the output object module, fn TEXT, to the punch.
suppresses the
TEXT, to the
spooling of
the output
object module,
fn
program that
was
pur.ch~
creates a TEXT
assembled.
NOLOAD
ch eck
see if it
the last
file
on disk
suppresses the creation of
program that was assembled.
for
a TEXT
the
file on
disk for
the
produces a LISTING file.
NOLIST
produces no LISTING file.
PRINT
spools the LISTING file to the printer.
puts the LISTING file on disk.
NOPRINT
produces no LISTING file.
LINECOUN nn
specifies the number of lines per output
default of 55 lines is assumed.
printer page.
A
Note: All of the options of the 3705 XF Assembler are supported and may
be used with the ASM3705 command, with the exception of ALIGN/NOALIGN
and TEST/NOTEST.
I~~POR!EI
WORKFI1]~
Three
files
are
temporarily
created
for
each
assembly:
fn SYSUTl
fn SYSUT2
fn SYSUT3
Any existing files with the same file identifiers are erased at the
beginning of the assembly.
These files are placed on the read/write
disk with the most available space.
Work space is automatically
allocated as needed during the assembly and returned to available status
when the assembly is complete.
Insufficient space causes abnormal
termination of the assembly.
304
IBM VM/370 Planning and System Generation Guide
3704/3705 Control Program
gERMAN~]I
FI1ES One
successful assembly:
or two
permanent files
may be
created during
a
fn TEXT
fn LISTING
The fn TEXT file contains the output object module if the LOAD option is
in effect. The fn LISTING file contains a listing of source statements,
assembled machine code, and other associated information based on the
options selected.
This file is created unless the NOPRINT or NOLIST
options are selected. The LISTING and TEXT files are placed on (1) the
disk from which the source file vas read, (2) its parent or (3) the
primary disk, unless you created a file definition for these files
placing them on a non-DASD device. Failure to obtain sufficient space
for these files results in abnormal termination of the assembly.
SPECIAL CONSIDERATIONS FOR THE STAGE 1 ASSEMBLY
The Stage 1 assembly can be very lengt~y.
The amount of time the
Assembler takes depends upon the macro options selected and th"e number
of users on the V"/370 system.
The LISTING file produced by the Stage 1 assembly is quite large. If
you let the ASM3705 command option default to DISK, much of the space on
your A-disk is used. Therefore, V"/370 recommends that you specify the
PRINT option when you issue the AS"3705 command.
Also,
there are many
macro expansions that make the LISTING file larger. V"/370 recommends
that you insert a 'PRINT NOGEN' assembler statement in front of the
first macro instruction in the input file to suppress the printing of
the macro expansions and reduce the size of the LISTING file.
You should examine the output of the Stage 1 assembly carefully and
produce a list of resource IDs, with their characteristics, for the
operations personnel.
The cross-reference list for operations should
include:
•
•
I ••
Resource ID
Type of resource (line or terminal)
Type of line (EP-mode or variable)
Location
Step 7. The Stage 2 Generation Procedure
During the Stage 2 generation procedure the TEXT file produced in Step 6
is scanned. That TEXT file contains several job steps of 3705 Assembler
source statements with embedded as JCt statements.
The Jet statements
are removed and a unique C"S 3705 Assembler source file is created for
each job step in the input file.
An EXEC procedure is also created to
assemble and link edit the source files.
When the EXEC procedure is
invoked, it produces the load module file (and, optionally, saves a copy
of the control program in page-format on a CP-owned volume).
Part 4. Generating the 3704/3705 Control Program
305
3704/3 7 05 Control Program
THE GEN3705 COMMAND
Use the CMS GEN3705 command to invoke the stage 2 service program.
Command options let you determine whether or not GEN3705 includes a
command in the EXEC procedure to save a copy of the load module on disk,
or if GEN3705 invokes the EXEC procedure automatically.
The format of
the GEN3705 command is:
r----------------------.--------------------------------------.----------------------------I GEN3105
fname fty pe [fmode] [ (options ••• [) ]]
I
I
I
I
options:
r
,
I
,
r
,
IRUN I
I NORUNI
I SAVE I
INOSAVEI
L
L
.I
.I
L-
fname
specifies the filename of the Stage 2 input stream produced by
the Stage 1 assembly.
The file must contain fixed-length,
SO-character records.
ftype
specifies the filetype of
filetype is normally TEXT.
fmode
specifies the filemode.
the stage
input stream.
2
If duplicate or conflicting options are specified, the
entered on the command line is in effect.
The
last option
RUN
causes the output EXEC file
to be
conclusion of the GEN3705 processing.
executed
NORUl!
suppresses the execution of the output EXEC file.
SAVE
includes a SAVENCP command
create a page-format copy of
on a VM/370 CP-owned volume.
at
the
in the output EXEC file to
the 3704/3705 control program
If you are generating a 3705 Emulator control program with
a Type 4 channel adapter, do not use the SAVE option; an
error message will result from the SAVENCP command.
In
this case, you must specify the SAVENCP command yourself,
specifying the CAMOD option.
does not
file.
include the
SAVENCP command
in the
output EXEC
Three types of permanent files are created when the GEN3705
successfully executes: ASK3705, TEXT, and EXEC files.
306
fnameOO
fnameO 1
ASK3705
ASM3705
fnam eLO
fnam eLO
TEXT
TEXT
fnamenn
ASM3705
fnam eLn
TEXT
IBM VM/370 Planning and System Generation Guide
fname EXEC
command
3704/3705 Control Program
A separate ASM3705 file is created for each assembly job step in the
stage 2 input file.
Each ASM3705 file created by GEN3705 is given a
unique filename of the form 'fnamenn'.
The first si~ characters of the
input filename are concatenated with a two-digit number.
For example,
if the input file is NCP320 TEXT, the output files are NCP32000 ASM3705,
NCP32001 ASM3705, ••• , NCP320nn ASM3705. These files are used as input
to the 3705 Assembler when it is invoked by the stage 2 EXEC procedure.
The GEN3705 program creates several TEXT files. These files contain
only linkage editor control statements, those statements necessary to
build the load module file for the 3704/3705 control program.
Each of
the TEXT files created is given a unique filename of the form 'fnameLn'.
The first six characters of the input filename are concatenated with the
letter L and a one~digit number. For example, if the input file is
NCP320 TEXT, the linkage editor output files are NCP320LO TEXT, NCP320Ll
TEXT~
~ NCP320Ln TEXT.
The filenames assigned to the linkage editor and assembler files must
be different.
If the filenames were the same, when the ASK3705 files
are later assembled, TEXT files would be produced which would have file
identifiers that conflict with the linkage editor files.
The EXEC macro file created contains the CKS commands necessary to
invoke the ASM3705 command for each of the ASK3105 files, and to
subsequently invoke the linkage editor for each of the Assembler TEXT
files.
If the SAVE option is specified, the EXEC file also contains the
SAVENCP command which loads the 3704/3705 control program image into
virtual storage and creates the page-format copy of it on a CP-owned
volume. The filename of the stage 2 input file is used as the 'ncpname'
operand for the SAVENCP command.
SPECIAL CONSIDERATIONS FOR THE STAGE 2 GENERATION PROCEDURE
VM/370 recommends that you specify the RUN option. When the RUN option
is specified, GEN3705 stacks a CKS command line to cause the EXEC file
to execute following the completion of the GEN3705 program.
This
technique minimizes the virtual storage overhead during the EXEC file
execution.
If you do not specify the SAVE option, you have to explicitly issue
the SAVENCP command.
If you do specify the SAVE option, be sure that
the input file has the same filename as the entry reserved in the system
name table. The system name table is created when a NAKENCP macro is
issued during a VM/310 system generation.
The NAKENCP macro is
described in "Part 2. Defining Your VK/370 System" and the building of
the system name table is described in "Part 3. Generating VM/370 (CP,
CMS, RSCS, and IPCS)."
Step 8. Invoke the EXEC Procedure Created in Step 7
If you specified RUN on the GEN3105 command, this step is executed for
you. If you did not specify RUN on the GEN3705 command, you must invoke
the EXEC procedure that the GEN3705 program created.
Part 4. Generating the 3704/3705 Control Program
307
310Q/3705 Control Program
The EXEC procedure is given the same filename as the GEN3105 input
file.
It is invoked by entering that filename at the terminal. For
example, if the input file is NCP320 TEXT, the EXEC file is named NCP320
EXEC, and can be invoked by issuing:
NCP320
at the terminal.
This EXEC procedure contains CMS commands that:
•
Assemble the 3705 source files
(ASM3705 commands).
•
Build the TXTLIB that the 3105 Assembler
•
Define all the necessary files; such as, the SYSLIB and SYSLKOD
files, load libraries, and text libraries (FILEDEF commands).
•
Link edit the 3705 text files creating a load module (LKED commands) •
n~eds
(TXTLIB commands).
You need not issue the ASM3705 and LKED commands that create the
310Q/3705 control program load module; the EXEC procedure does that for
you.
The ASK3705 command is described in Step 6.
The FILEDEF and
TXT LIB commands are described in the !M/31~ ~~~ COA!~nd ~n~ Ma£~Q
Re!~~.
THE LKED COMMAND
Use the CKS LKED command to create the 310Q/3105 control program load
module from the 3105 Assembler object files. The format of the LKED
command is:
r
I LKED
I
I
I
fname
[ (options ••• [) ]]
,
,
QEtions:
[NCAL] (LET] (ALIGN2] [NE] [OL] [RENT]
I
I
I
I
I
r
[REUS] [REFR] [OVLY] [XeAL]
I
I
[NAME membername] [LIBE libraryname]
,
IXREFI
,MAP I
I!I~!'
L
.J
r
I TERM
,
r
,
,NOTERK I
L
.J
,
,PRINT I
IDIg
,
INOPRINTI
L
.J
L
fname
specifies the filename of the object file to
The file must have a filetype of TEXT and
SO-character records.
be processed.
fixed-length,
If duplicate or conflicting linkage editor options are specified, the
resolution is performed by the linkage editor in accordance with its
normal procedures.
If duplicate or conflicting eMS-related options
are specified, the last one entered on the command line is in effect.
The eMS-related options are: TERM, NOTERM, PRINT, DISK,
NOPRINT,
NAME, and LIEE.
308
IBM VM/370 Planning and System Generation Guide
3704/3705 Control Program
NCAL
suppresses the automatic
linkage editor.
library call
function of
the
LET
suppresses marking of the load module "not executable" in
the event of some linkage editor error condition.
ALIGN2
indicates that boundary alignment
specified in the
linkage editor input file is to be performed on the basis
of 2048-byte boundaries.
If this option is omitted,
alignment is
performed on the basis
of 4096-byte
boundaries.
NE
marks the load module output as "not to be edited" such
that it cannot be processed again by the linkage editor.
OL
marks the load module output "only loadable".
RENT
marks the load module reenterable.
REUS
marks the load module reuseable.
REFR
marks the load module refreshable.
OVLY
processes an overlay structure.
XCAL
allows valid exclusive CALLs in the overlay structure.
NAME membername
is the member name to be used for the load module
created. The member name specified here overrides the
default name, but it cannot override a name specified via
the linkage editor NAME control statement.
LIBE libraryname
is the filename of a LOADLIB file where the output load
module is to be placed.
The LOADLIB file specified here
may also be used for auxiliary input to the linkage
editor via the INCLUDE statement.
XREF
produces an external symbol
modules being processed.
MAP
produces only a module map for the processed module(s).
includes only linkage
printed output file.
editor
displays any linkage editor
user terminal.
cross-reference
control
messages in
diagnostic messages
NOTER!!
suppresses the displaying of diagnostic messages.
PRINT
spools the linkage
printer.
editor printed
stores the linkage editor output in
a filetype of LKEDIT.
NOPRINT
for
output
the
the
at the
file to
the
a eMS disk file with
produces no output file.
Part 4. Generating the 3704/3705 Control Program
309
3704/3705 Control Program
Only a subset of the possible linkage editor control statements are
meaningful in C"S.
.Since the CMS interface program cannot examine the
input data for the LKED command, all of the control statements are
allowed, even though several of them result in the creation of a load
module file which cannot be used under CMS. For both command options
and control statements, see the publication Q~{VS 1inka~~ ~~itor sB£
l!oader.
!E"PORAR!
WORE!IL~
The LKED ,command produces one tempora ry file:
fname SYSUTl
This file is temporarily created for each link-edit steo: any existina
file with the same file identifier is erased at the beginning of the
link edit.
This file is placed on the read/write disk with the most
available space. Work space is automatically allocated as needed during
the link edit and returned to available status when the link edit is
complete. Insufficient space causes abnormal termination of the link
edit.
PER!!!EN!
FIL~~
The LKED command produces two permanent files:
fname LOADLIB
fname LKEDIT
The 'fname LOADLIB' file contains the load Bodule(~
created by the
linkage editor.
This file is in C"S simulated partitioned data set
format, as created by the CMS OS data management macros. The filename
of the input file becomes the filename of the LOADLIB file, unless the
LIBE option is specified. The filename of the input file also becomes
the member name of the output load module, unless either the NAME option
or a NAME control statement is used.
One or more load modules may be
created during a single LKED command execution if the NAME linkage
editor control statement is used in the input file.
When the NAME
control statement is used, that name becomes the member name in the
LOADLIB file. The replace option of the NAME statement determines
whether existing members with the same name are replaced or retained.
The 'fname LKEDIT' file contains the printed output listing produced
according to the IREF, MAP, or LIST options. This file is created on
disk unless the PRINT or NOPRINT option is specified.
The LOADLIB and
LKEDIT files are placed on (1) the disk from which the input file was
read, (2) the parent disk, or (3) the primary disk.
Failure to obtain
sufficient space for these files results in abnormal termination of the
linkage editor.
Step 9. Save the 3704/3705 Control Program Image
on Disk
If you specified SAVE on the GEN3705 command, this step is executed for
you. If you did not specify SAVE on the GEN3105 command, you must issue
the SAVENCP command yourself.
Not~~ The VM/370 command
the SAVENCP command.
310
privilege class A, B, or C
IBM VM/370 Planning and System Generation Guide
is required to use
3704/3705 Control Program
Use the CKS SAVENCP command to read a 3704/3705 control program load
module created by the LKED command, and to load it into virtual storage
in the CKS user area.
Once the load is performed, SAVENCP scans the
control program image and extracts the control information required by
CP. The control information is accumulated in one or more 4096-byte
pages in the CKS user area.
When all of the necessary control
information is extracted, SAVENCP builds the Communications Controllers
Parameter List
(CCPARK) and issues the DIAGNOSE X'50' instruction to
create the page-format copy of the control program on a CP-owned volume.
The format of the SAVENCP command is:
r----------------------------------------------------------------------~
,
SAVENCP
fname
(options.. [)]]
[
opt i.Q.B.§ :
r
,
,ENTRY symbol I
IgnNIT
I
.I
L
L
fname
r
,
r
,
,NAKE ncpnamel
,fname
,
ILIBE librarynamet
L
L
.I
Ifn~
.I
.I
is the filename of the LOADLIB file where the 3704/3705
control program load module resides; unless LIBE is specified,
in which case, it specifies the member name of the image
within the LOADLIB. This name is used as the ncpnaae for the
DIAGNOSE instruction,
unless the
NAKE option
is also
specified.
ENTRY symbol
is the external symbol of the entry point in the 3704/3705
control program load module.
(The standard entry for the
Emulation Program is CYAST1RT.)
If the SAVE option of the
GEN3705 command is specified, this symbol is set in the output
EXEC file according to the Stage 2 input file.
JAKE ncpname
is the ncpname to be used when the DIAGNOSE parameter list is
built.
The ncpname specified must match an entry in the
system name table. These entries are created with the NAKENCP
macro when VK/370 is generated.
LIBE libraryname
is the filename of a load module library file,
filetype
LOADLIB, which contains the control program image as member
• fname' •
CAJiliOD
{~}
must be specified if a Type 4 Channel Adapter is being used.
VK/370 supports only one Type 4 Channel Adapter at a time,
although two may be present.
Part 4. Generating the 3704/3705 Control Program
311
3704/3705 Control Proqram
CAftOn 0 corresponds to -0 following the subchannel address on
the ADDRESS operand of the tIRE macro in Stage 1 of the EP
system qeneration.
(0 may have been coded or defaulted on the
LINE macro; you must specify it on the CAKOD option.)
I
CAftOn 1 corresponds to -1 following the subchannel address on
the ~DDRESS operand of the LIRE macro in Stage 1 of the EP
system qeneration.
EXECUTION OF THE SAVENCP PROGRA"
The DIAGNOSE X'50' instruction invokes the CP module DKKSRC to:
•
Interpret the parameter list (CCPARM) built by SAVENCP.
•
Check the parameter specifications against
3104/3705 control proqram.
•
Write tbe paqe-format image
appropriate CP-owned volume.
The
parameter list
boundary.
for the
of
the
DIAGNOSE
the RAKERCP macro for the
control
proqram
instruction must
onto
the
start on
a
40~6-byte
When tbe DIAGNOSE X'50' instruction is executed, the module DKKSNC
searches the D"KSNT module for a NAftENCP macro of the same ncpname as
the one in the CCPARft parameter list.
The values specified in the
parameter list are compared to tbose specified in the NA!ENCP macro. If
any parameters conflict, an error message is displayed at the terminal.
If no error conditions are detected, DKKSNC starts to transfer the
control proqram image from CMS virtual storage to the CP-owned volume
specified in tbe NAMENCP macro. Successful completion of this process
completes the qeneration of a 3704/3705 control program for VK/370 use.
Step 10. Load the 3704/3705 Control Program
The
3704/3705 control proqram is automatically loaded each time the
is loaded, if the CPNAKE operand was specified on the
RDEVICE macro when VM/370 was generated and if the 3704/3705 is online.
If the CPNAftE operand was not coded, you must issue the CP NETWORK LOAD
command line to load a 3704/3705 control program into the 3704/3705
Communications Controllers' storage.
V"/370 system
THE NETWORK LOAD COMMAND LINE
Use the NETWORK LOAD command to initiate the loading of an EP control
proqram into a 3704/3705 Communications Controller. The format of the
NETWOPK LOAD command line is:
f"
L
~
, ________________________________________________________________________________
NE'rwork
LOAD raddr ncpname
312
IBM VM/370 Planning and System Generation Guide
March 3, 1980
3704/3705 Control Program
LOAD
initiates the control program load operation.
raddr
is the real address of the 3704/3705 to be loaded.
ncpname
is the name, defined by a
control program image to
specified by raddr.
NAMENCP macro, of the
be
loaded into the
3704/3705
3704/3705
EXECUTION OF THE NETWORK LOAD COMMAND
The NETWORK LOAD command accesses the control program image using the
information in the system name ~aDLe
(DMKSNT) entry created by the
NAMENCP macro.
If the 3704/3705 specified in the command is not in an
"IPL Required" state at the time the c0~mand is issued, the message:
DMKNET461R CTLR raddr IPL NOT REQUIRED; ENTER "YES" TO CONTINUE:
appears at the terminal.
If the reply to the message is other than
"yes", the command terminates without loading the 3704/3705. Otherwise,
the loader bootstrap routines are written to the 3704/3705 and loading
starts. 'K/370 does not execute the "bring-up" test routines as a part
of the load process. If these tests are to be made, they must be run
from a virtual machine with the 3704/3705 dedicated.
When the load of the centrol program image is complete, the command
processor verifies that the
3704/3705 configuration described by the
contrel program can be serviced by the VM/370 CP control blocks in
storage.
SPECIAL CONSIDERATIONS FOR LOADING THE EP 3704/3705 CONTROL PROGRAM
If a 3704/3705 Emulation Program is automatically reloaded after a
3704/3705 failure, the system may loop after the restart.
The message
DKKRNH463I CTLR raddr UNIT CHECK; RESTART IN PROGRESS
and two responses
CTLR raddr DUMP COMPLETE
CTLR raddr ncpname LOAD COMPLETE
indicate that the 3704/3705 has been reloaded.
If the system loops
after the second response, you must reset all emulator lines from the
3704/3705 control panel.
If the automatic dump feature is not enabled, one of the messages
DMKRNH462I CTLR raddr UNIT CHECK; IPL REQUIRED
-- or -DMKRNH4641 CTLR 'raddr' CC=3; DEPRESS 370X "LOAD" BUTTON
Part 4. Generating the 3704/3705 Control Proqram
313
Page of GC20-1801-10 As Updated March 3, 1980 by TNL GN25-0776
3704/3705 Contrel Program
indicates a 3704/3705 abnormal termination.
The 3704/3705 Emulation
Program must be reloaded via the NETWORK LOAD command. If the system
loops when an attempt is made to enable the lines, you must reset all
emulator lines from the 3704/3705 control panel.
The I~~ Jl~~ ~~g l1Q~ ~Qmm~~i£~1iQn§ ~Qn1£Q!!~I§ QE~I~~QI~§ guig~
describes the procedure for resetting emulator lines from the 3704/3705
control panel.
Step 11. Logging On through the 3704/3705
Because a 3704/3705 can support emulator-mode lines and can also support
a variety of terminals,
the procedure for logging on is sometimes
complicated.
Use the following procedure to log on to VM/370.
TURN THE POWER ON
First, turn the power on for your terminal and wait 15 to 30 seconds.
CHECK FOR AN ONLINE MESSAGE
Second, look for an online message at your terminal.
If one of the following messages appears at your terminal
xxxxxx xxxxxx
vm/370 online
or
xxxxxx xxxxxx
vm/370 online
your terminal is a 2741 connected to VM/370 via a 2701/2702/2703 line or
via a 3704/3705 line in emUlation mode.
You can proceed with the normal
logon procedure for your type of terminal, as described in the VMLll]
I~Im~n~! Q~I~§ Guig~·
If the message
vm/370 online
appears at your terminal,
I.
your terminal is:
A 1050, 3101, or CPT-TWX Model
EP mode.
33/35 terminal connected to VM/370 in
You can proceed with the normal logon procedure for your terminal type.
This procedure is described in the Y~L~l~ !g£~in~! y§gI~§ 2Yig~.
314
IBM VM/370 Planning and System Generation Guide
3704/3705 Control Program
Step 12. Applying PTFs to the 3704/3705 Load
Library
If necessary,
it is possible to
apply program Temporary Fixes (PTFs)
directly to the 3704/3705 load library. The CMS ZAP program applies the
PTF. See the !M/37Q ~~ratQr's Guide for information on using the ZAP
service program.
Testing the 3704/3705 Control Program
After you have generated a 3704/3705 control program, loaded it, and
logged on, you may want to test the 3704/3705 control program, Several
CP commands are provided to control the operation, check the status, and
dump the contents of the 3704/3705. The NETWORK command loads and dumps
any- 3704/3705 control program. The existing CP commands (ENABLE,
DISABLE, QUERY, DISPLAY, VARY, and HALT) also provide support for EP
3704/3705 control programs. The NCPDUKP command formats and prints a
dump of 3704/3705 storage.
Use these commands to test the 3704/3705
con trol progra m.
The NETWORK, ENABLE, DISABLE, NCPDUMP, QUERY, DISPLAY, VARY, and HALT
commands are described in the VM/~10 Ope~~tor's Guig~ and the !M/370 ~~
~ommand Refere.n~ fo!: General Us~£§.
Part 4. Generating the 3704/3705 Control Program
315
316
IBM VM/370 Planning and System Generation Guide
Part 5. Updating VM/370
Part 5 tells you how to apply Program Temporary Fixes (PTFs) and updates
to an installed VM/370 system. It contains information about the
following:
•
Introduction
•
A Virtual Machine for Updating VM/370
•
Files for System Updates
•
System Program Update Tape
•
Recommended Procedures for Updating VM/370
•
Building a New CP Nucleus
•
•
Updating CMS
•
•
Updating IPCS Modules
•
Updating the Loader Program
•
EXEC Procedure and Command Format Summaries
Updating RSCS
Updating Service programs
Part 5. Updating VM/370
317
318
IBM VM/370 Planning and System Generation Guide
Introduction
Introduction
VM/370 provides you with several procedures and techniques for updating
your VM/370 system.
Using a virtual machine, you can perform updating
and maintenance tasks concurrently with other production work.
The
framework provided by VM/370 gives you a maximum amount of flexibility
in maintaining your system. This framework includes:
•
A recommendation for a system support plan, with a userid KAINT
provided with access to minidisks containing files necessary for
system updating and maintenance.
•
A monthly system
Program Update Tape
(PUT)
is automatically
distributed to VK/370 users.
This tape contains updated TEXT and
MODULE files, as well as PTFs (Program Temporary Fixes)
that may be
applied to your VM/370 system.
•
The UPDATE command and two EXEC procedures, VKFASM and VMFMAC, which
allow multilevel updating capabilities with concomitant multilevel
backup.
•
Naming conventions for update files and control files.
•
Several EXEC procedures and programs that simplify
These programs are listed in Figure 33.
updating VM/370.
All of these techniques require the use of CKS; you should have a
thorough understanding of the CMS file system and disk search order, the
CMS EXEC processor, and the UPDATE command before you attempt to use any
of the procedures described here.
The !~370 ~~2 Us~~~§ Guig~ provides complete tutorial information on
CMS; for reference material on CMS commands and EXEC control statements,
see VML170 CM~ £Q!!.!!ang ang ~E:gQ Reference.
Decidin-g Which Procedure To Use
When you have a maintenance task, you want to accomplish
as possible without excessive delay or unnecessary steps.
types of maintenance, and each has one basic procedure.
it as quickly
There are two
Text level maintenance is available with the system PUT distributed
by IBM. When you use this type of maintenance, you do not have to worry
about which procedures to use.
The user memo always tells you what to
do.
Existing TEXT and TXTAP files for your VM/370 system are replaced,
on a one-for-one basis, by new files contained on the system PUT.
The second type of maintenance involves more work on your part.
If
you have updates that you want to apply to IBM modules (for example, if
you have written an accounting routine you want to include in the DMKACO
module), use the following procedures:
1.
If an update is being made to
to update the library.
a macro library, use the VMFKAC EXEC
Part 5. Updating VK/370
319
Introduction
r
I Program
I
VMSERV
,,
comments
Updates CP, CMS, RSCS, and IPCS from the system Program
Update Tape (PUT). Text decks supplied with the service
tape replace existing text decks.
VMFASM
Updates a source file using IBM updates and PTFs and user
updates, then assembles the updated source file.
VMFMAC
Updates macro libraries using IBM and user updates.
VMFLOAD
creates a new CP, CMS, or RSCS nucleus based on a control
file and a load list EXEC file.
GENERATE
Performs a variety of maintenance functions, including
directory and service program updates. May also be
used to invoke the VMFLOAD program to punch a new CP,
CMS, or RSCS nucleus.
CMSGEND
Creates a new CMS command module from updated TEXT files.
ASMGEND
Updates the VM/370 system assembler.
VSAMGEN
Updates and rebuilds the CMSVSAM and CMSAMS discontiguous
saved segments based on PTFs to VSAM code.
UPDATE
Applies single or multilevel updates to source programs.
L
Figure 33.
Programs for Updating VM/370
2.
Use the VMFASM EXEC procedure to reassemble the source module using
update files. These may be IBM PTFs or updates or your own. If
you are reassembling a module because of a MACLIB change, no update
files are necessary.
3.
Use the VMFLOAD program to punch a
incorporating existing TEXT files
VMFASM EXEC.
4.
Depending on whether you are creating a new CP, CMS, or
nucleus, you may next have to perform additional steps,
writing the new nucleus onto disk, and so on.
new CP, CMS, or RSCS nucleus,
and new ones created by the
RSCS
like
The various procedures and steps to take are summarized in Figure 34.
These procedures are described in detail in the remainder of Part 5.
Before you use any of the procedures, you should have established a
virtual machine userid for your maintenance tasks.
You must also be
acquainted with the CMS files that are used for updating and the naming
conventions used by IBM. These topics are discussed next.
320
IBM VM/370 Planning and System Generation Guide
Introduction
PLC
Update
VMSERV
(with
User Memo)
PTF or
Local Update
to CP
Yes
VMFMAC
No
VMFASM
Yes
VRSIZE
No
VMFLOAD
Yes
IPL
OOC
DDR or
MOVEFI LE
to Tape
I. . :. . . . .
S_R...V_C....__........,
See "Updating Service Programs"
See "Updating the Loader Program"
Figure 314.
Deciding Which Updating Procedures To Use (Part 1 of 2)
Part 5. Updating V8/370
321
Introduction
1.· .· :
·.C.:.·:.::
•.'.'M.··.·.'.:.·.·.'S.:'.:.:.:.:.··.:.·.·.·.:.;.·.1
~:.::. ::,~ ~:> ?::;:~
...::.
PTF or
Local Update
to CMS
VMFMAC
No
VMFASM
CMSGEND
(or
ASMGENDI
No
VMFLOAD
Yes
IPL
DOC
Yes
~
:: ~.:
...:.....:.•.:...:•..::.•.. ..:••••:...:..: ..•..:.•.::.;.:.:....:.•.
~
.........
PTF or
Local Update
to RSCS
CMSXGEN
SA'/ESYS
VMFMAC
No
VMFASM
Figure 3Q.
322
VMFLOAD
IPL
OOC
Deciding Which Updating Procedures To Use (Part 2 of 2)
IBM VM/370 Planning and System Generation Guide
A Virtual Machine for Updating VM/370
A Virtual Machine for Updating VM/370
The VM/370 directory distributed with each starter system contains an
entry for a userid, MAINT. You may want to use this userid for system
updating and maintenance. MAINT's virtual machine should have access to
all the disks required for system maintenance.
A suggested virtual machine configuration
for updating a 2314 system
is:
USER MAINT CPCMS 720K 16M BCEG
ACCOUNT (installation defined)
OPTION ECMODE REALTIMER
CONSOLE
009
3215
SPOOL
OOC
2540
READER A
SPOOL
OOD
2540
PUNCH A
OOE
1403
SPOOL
A
MDISK 190 2314 035 135 CPRnLOl MR READ
MDISK 191 2314 019 010 CPRnLO iR READ
MDISK 194 2314 110 033 CPRnLO MR READ
MDISK 199 2314 034 001 CPRnLO iR READ
MDISK 193 2314 001 050 USERDl lIR READ
MDISK 294 2314 051 050 USERD 1 MR READ
MDISK 393 2314 001 125 USERD2 MR READ
MDISK 394 2314 001 160 USERD3 MR READ
MDISK 390 2314 101 003 USERD 1 Mi READ
MDISK cuu 2314 000 203 yyyyyy Mi
where cuu and yyyyyy are the address
volume defined in the DMKSYS module.
and label of your system residence
A suggested virtual machine configuration
for updating a 3330 system
is:
USER MAINT CPCMS 720K 16M BCEG
ACCOUNT (installation defined)
OPTION EC~ODE REALTIKER
009
CONSOLE
3215
OOC
SPOOL
2540
READER A
SPOOL
OOD
2540
PUNCH A
OOE
1403
SPOOL
A
MDISK 190 3330 030 085 CPRnLO MR
MDISK 191 3330 016 007 CPRnLO iR
MDISK 194 3330 115 027 CPRnLO MR
MDISK 199 3330 029 001 CPRnLO iR
MDISK 193 3330 001 030 USERDl MR
MDISK 294 3330 031 030 USERD 1 MR
MDISK 393 3330 061 070 USERD 1 MR
MDISK 394 3330 141 090 USERD1 MR
MDISK 390 3330 231 002 USERD 1 MW
MDISK cuu 3330 000 404 yyyyyy Mi
READ
READ
READ
READ
READ
READ
READ
READ
READ
where cuu and IIYYII are the address and label of your system residence
volume defined in your DMKSYS module.
lCPRnLO may be CPR4LO, CPR5LO,
release level.
CPR6LO and
so forth, depending
Part 5. Updating VM/370
on the
323
A Virtual Machine for Updating VM/370
A suggested virtual machine configuration
for updating a 3340 system
is:
USER PlAINT CPCMS 720K 16M BCEG
ACCOUNT (installation defined)
OPTION ECMODE REALTIMER
CONSOLE
009
3215
SPOOL
OOC
2540
READER
SPOOL
OOD
2540
PUNCH
SPOOL
OOE
1403
A
MDISK 190 3340 048 240 CPRnLO
MDISK 191 3340 026 015 CPRnLO
MDISK 194 3340 288 060 CPRnLO
MDISK 199 3340 046 002 CPRnLO
MDISK 193 3340 001 075 USERD 1
MDISK 294 3340 076 075 USERD1
MDISK 393 3340 151 185 USERD 1
MDISK 394 3340 001 250 USERD2
MDISK 390 3340 221 003 USERD2
MDISK cuu 3340 000 348 VVVVVV
A
A
MR
WR
MR
WR
MR
MR
MR
MR
MW
MW
READ
READ
READ
READ
READ
READ
READ
READ
READ
where cuu and yyyyyy are the device address and disk
system residence volume defined in the DMKSYS module.
label of
your
The entries in the preceding VM/370 directory, with the exception of
the 193, 294, 393, 394, and 390 virtual disks, are included in the 2314,
3330, and 3340 VM/370 directories supplied with the starter system, and
should be included in your VM/310 directory, as they are used by IBM for
support.
The contents of the preceding virtual disks are:
nis,!
190
191
194
1q9
1q3
294
393
394
390
cuu
Conten1.§
Current CMS system disk
Work area
CP, RSCS, and IPCS text retention
CPGEN's 191 minidisk (work area)
CMS PTFs, updates, and
updated text decks (object
modules)
CP, RSCS, and IPCS PTFs, updates, and updated text decks
(object modules)
CMS source and macros
CP, RSCS, and IPCS source, macros, and copy files
CMS test nucleus area
CP system residence device, or a replica of it, for test
purposes
These virtual disks are shown in Figure 35.
Source code for the CMS system is included on the CMS2 tape. Source
code for CP is included on the CP2 tape. Source code for RSCS and IPCS
is included on the RSCS/IPCS tape. These tapes are distributed by the
'" Program Information Department (PID).
324
IBM VM/370 Planning and System Generation Guide
A Virtual
~achine
for Updating VM/370
WORK
AREA
CMS
SOURCE
AND
MACROS
CPGEN'S
191
CIV\S
TEST
NUCLEUS
('
195
'-
1....... --.",·
RSCS
I
I SYSTEM DISK I
CP
SYSTEM
RESIDENCE
Figure 35.
-- .....
I
I
l
(RSCS 191
LINKED
AS 195)
....... ---'
(
J
195
'-
1...... --..",-
1
1
I I
I
-----..,.
I
l
IPCS
SYSTEM
(IPCS 191
LINKED
AS 195)
...... _-..".
I
I
I
I
,)
System Support Plan
Part 5. Updating
V~/370
325
A Virtual Machine for Updating VM/370
Accessing Disks
When you are using the VM/370 procedures to apply updates to system
modules, update file identifiers may be duplicated on more than one
disk; there may be updates that are located in several different places.
You should always be sure that you have the correct disks accessed, and
that you have accessed them with an appropriate search order.
You may find it convenient to create EXEC
links and accesses necessary to perform
example to update a CP module, from files
294, your EXEC procedure might look like the
procedures that perform the
a particular update.
For
located on MAINT's 191 and
following:
ACCESS 191 A
ACCESS 294 B/A
ACCESS 394 CIA
This search
fil~ ~ith
tha
order ensures that if
~~=c
filcn~=c
c:i~tc
a control file or
~~
b~th
the
191 ~~~
auxiliary control
?QU i
+h~
nn~
on
the 191 is used.
When updates are made to RSCS the 191 disks provided for these
virtual machines can be linked to and accessed in read/write status, for
example
link rscs 191 195 w wpass
access 195 a
326
IBM VM/370 Planning and System Generation Guide
Upda te Files
Files for System Updates
Each of the components of Ve/370 has a unique character module
identifier, which is used to name the component's modules.
These
component identifiers are also used to name the files used to update the
components. The identifiers are:
£om£Q1l~1!1
!1~dule .lg~ifier
CP
CMS
RSCS
IPCS
DMK
Df!S
DMT
DMM
The default CMS filetypes are used to identify the source, object
code, module files and libraries associated with each component. These
filetypes are:
lil~~~
ASSEMBLE
TEXT
TXTAP
MODULE
PIACLIB
!y~
of lil~
Source File
Object deck (relocatable)
Object deck with Attached Processor Support
(relocatable)
Nonrelocatable object code
Macro or copy library
Two of the update procedures, VPIFPIAC and VMFASM, use the CMS UPDATE
command to update macro libraries and source files.
Since the updates
that are applied are multilevel updates, there are control files (with a
filetype of CNTRl)
and auxiliary control files,
(with filetypes of
AUXxxxxx)
as well as the actual update files
(consisting of UPDATE
control statements and new source records).
These files may have the
following generic filetypes:
CNTRL
AUXxxxxx
UPDTxxxx
anything
lile ~Qntents
Control file
Auxiliary control file
local update (listed in a CNTRl file)
local update (listed in an AUX file)
IBf! uses file identifiers as listed
VM/370.
QMKEnO~
CNT]1~
is used
for CP
below for distributed updates to
source, copy,
and macro
updates.
Its
contents are:
TEXT PIACS DMKMAC CMSlIB OSMACRO
TEXT AUXRnO
QMKEnA CNTR1~ is used for CP source, copy, and macro updates
support for the !ttached Processor. Its contents are:
with
TEXT MACS DMKAMAC DMKMAC CMSLIB OSMACRO
AP
UPDTAP
AP
AUXRnO
1n may be 1, 2, 3 and so forth depending on the release level.
Part 5. Updating VM/370
327
Update Files
g~~]nO
~NT]1~
is used for CMS source updates.
Its contents are:
TEXT MACS CMSLIB OSMACRO
TEXT AUXRnO
R~~ftnQ £NT]1~
is used for CMS copy and macro updates.
Its contents are:
TEXT MACS
TEXT AUXftnO
DM!~nO
~NTR1~
is used for
RSCS source,
copy, and macro
updates.
Its
IPCS source,
copy, and macro
updates.
Its
contents are:
TEXT MACS DMTLOC DMTMAC
TEXT AUXRnO
QftMRnO ~NTRL~
contents are:
'fI1i!I'fl
is used for
'U("~
("M~T,T'R
n~MU"RO
nMMMM:~
nMKMAC
TEXT AUXRnO
!CP~nO
~NTRL~
is
used for assembling the NCPDUMP
source.
Its contents
are:
TEXT MACS OSftACRO DMKMAC CMSLIB
TEXT AUXRnO
All auxiliary control files distributed by IBM have the filetype
AUXRNO (or AUXMnO for CMS MACLIB changes). When an update is issued for
a module, an auxiliary control file is also distributed.
For example,
if an update is sent for DMKCFM then the file DMKCFM AUXRnO is also
distributed. This file, DMKCFM AUXRnO, lists the updates to be applied
to the CP module DMKCFM.
All of the the update files
filetypes as follows:
distributed
by
VM/370 are
assigned
nnnnnxx
Z
indicates a Release 5 update.
M
indicates a CMS macro update.
R
indicates a Release 6 update.
nnnnn
is an APAR or PTF number.
xx
is the 2-character component identifier (DK, DS, DT, or DM).
For example, the code and updates to answer APAR VM12765 against the
Release 6 level of CP module DMKCFft are contained in the file DMKCFM
R12765DK. The file DMKCFM AUXRnO contains the entry:
R12765DK - COMMENT DESCRIBING FIX
328
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Update Files
When you create files for local updates of VM/370 modules, you should
create a local control file, consistinq of the appropriate VK/370 CNTRL
file with an entry for your local MACLIB and AUX file. For example, the
file CPLCL CNTRL may contain:
TEXT ~ACS LCLLIB DHKMAC CMSLIB OSMACRO
LeL AUXLCL
TEXT AUXRnO
The AUXRnO control file should be last in the control file, so that the
IBM updates are applied first.
(Remember that the UPDATE command, when
applying multilevel updates, reads from the bottom of the control file.)
Text files must have a filetype of TEXT. For example, after you have
updated an object module using VMFASM, the most recent object file has a
filetype such as TXTLOCAL. To use that text file here, you must rename
it to a filetype of TEXT. If there is currently a text file on the
system disk, you may wan~ ~o rename it too, so that your updated text
file (which may reside on another disk) is the one that is loaded.
Part 5. Updatinq
V~/370
329
A pr
330
~ J..
I,
-, 'oj t:j: 1
IBM VM/370 Planning and System Generation Guide
PUT Updates
System Program Update Tape (PUT)
IBM regularly distributes a system Program Update Tape (PUT) containing
updates to V~/370c
The system PUT updates are cumulative, and contain:
•
Updated text decks, for a one-to-one
decks on MAINT's 194 disk.
replacement of
existing text
•
Update files with UPDATE control statements, and auxiliary control
files to control the application of these updates to the source files
on KAINT's 394 disk. The PTF's and AUX files may be loaded on
~AINT's 294,
if you want to apply the updates in conjunction with
local updates.
The second file on the system PUT contains the Memo to Users, which
describe in detail all of the updates that are currently available. The
Memo to Users also provides step-by-step instructions on how to apply
updates. These files can be loaded on your A-disk and printed, using
the VMSERV EXEC.
Program level change service updates involve the use of the VMSERV
EXEC, which is the same procedure that you used to install VM/310 during
system generation. The VMSERV EXEC is always provided in the first tape
file of the system PUT, along with the VMFPLC2 module, which is used to
read the tape.
If you have no local updates to apply to any VM/310 modules w you
should follow the instructions in the Memo to Users; this memo always
contains up-to-date documentation on how to use the VMSERV EXEC. The
Memo to Users also tells you when you must perform additional steps
before invoking VMSERV.
For example, if a macro library has been
updated and your system definition files (DMKRIO,
DMKSYS, and so on)
must be reassembled, the user memo tells you to use the VMFASM EXEC to
reassemble the source files.
The VMSERV EXEC builds a new CP, CMS, or RSCS nucleus from the
replacement text decks on the system PUT.
If you have local updates to
some system modules, you may not want to use VMSERV.
For example, if you have written a local accounting routine and
assembled it into the module DMKACO, and the Memo to Users indicates a
you may want to reassemble the source
PTF is to be applied to DMKACO,
module to create a text deck that contains your modification, as well as
the PTF. In this case, you have to load the DMKACO AUXRnO file and the
PTF
(DMKACO RnnnnnDK)
file from the system PUT.
The Memo to Users
indicates the location of these files on the tape; remember to use the
VMFPLC2 module to load the files, rather than the CMS TAPE command.
VMFPLC2 uses a blocking factor of 50:1 thereby better utilizing the
system PUT and insuring maintenance will be contained on one tape.
The procedures that you use next are the same procedures you would
use to apply a local update without the system PUT: you would use VMFASM
to assemble the source files for all modules you wish to update, and
VMFLOAD to punch a ney CP nucleus.
Before you use V~FLOAD, however, you
want to make sure that you have loaded, from the system PUT, the updated
text files for those modules you are not reassembling.
The procedures for applying updates to VM/310 are described next.
Part 5. Updating VM/310
331
332
IB~
VM/370 Planning and System Generation Guide
Recommended Procedures for Updating
VM/370
The procedures that you can use to apply local updates are similar for
CP, CMS, RSCS, and IPCS.
The examples in the following pages use CP
modules and control files to illustrate the use of:
•
•
•
The VMFASM EXEC Procedure
The VMFMAC EXEC Procedure
The VMFLOAD Program
You should keep in mind that the procedures for updating source files
and macro libraries are the same for all VM/370 components, and that the
procedure for punching a new eMS or RSCS nucleus is basically the same
as the procedure for punching a CP nucleus.
For specific details and special considerations for loading and
testing a new CP, CMS, or RSCS nucleus, or for generating new IPCS
modules, see:
•
•
•
•
"Building
"Updating
"Updating
"Updating
a New CP Nucleus"
CMS"
RSCS"
IPCS Modules"
The minidisk areas used in the examples in all of these discussions
use the MAINT virtual machine described under "A Virtual Machine For
Updating VM/370" and illustrated in Figure 35. Note tha t
the virtual
machine configuration consists of the MAINT entry in the IBM-supplied
VM/370 directory, with the addition of MDISK statements for virtual
disks (193, 294, 393, 394, and 390).
Figure 35 shows the virtual disks
described by
the resultant MAINT
entry.
This
virtual machine
configuration should provide you with all the areas you need to update
and test VM/370.
'/1\1I/370In+enri+y
;; ;v./
•
• ••• ~ • ••
In order to preserve the integrity of VM/370 source and text files, you
should keep updates and PTFs on a separate minidisk (not on the same
disk as the original source and text files). This minidisk (usually
MAl NT's 294) should contain the required IBM PTF updates from the latest
system PUT, updates that you make (such as expanding the accounting
routines or adding a command to CP), and the resultant text files
containing the updates.
You also need access to the current CP text files and macro
libraries. This is MAINT's 194. This is the disk used by VMSERV when
it loads replacement text files from the System PUT.
The assembler language source files are on the 394 minidisk. You
should not change these files, unless directed to do so by the Memo to
Users.
When you use the CMS UPDATE command and the VMFASM and/or VMFMAC
EXEC procedures with the suggested virtual machine configuration shown
in Figure 35 and the access s€arch order shown in the following
examples,
modified files are written onto your A-disk.
Also, you
should not change the IBM-supplied
auxiliary files nor the PTF
(XnnnnDMK) files as these are controlled by the PUT procedure.
Part 5. Updating VM/370
333
Recommended Procedures
If you want to update a VM/370 component, you should create your own
control file.
This file should contain entries for your own updates as
well as for the IBM-supplied updates.
Control File Preparation
Control files are used by the CMS UPDATE command. Both the VMFMAC and
VMFASM update procedures invoke UPDATE with the CTL option to modify
source files.
For VMFMAC and VMFASM, the control file must have a
filetype of CNTRL. In addition, the VMFLOAD program also uses a control
file: this is usually the same control file used by the VMFASM EXEC.
For an understanding of how the update procedures work,
you should
have a thorough understanding of the elements in a control file.
Control files are described extensively in the !~L170 CM~ Us~~!§ Guid~
and the VM/J70 ~~~ ~~ng
and Mac~Q Ref~~£~.
The following
discussion summarizes how VMFMAC, VMFASM, and VMFLOAD use the control
-F~'
_~_e.
l*THIS IS A SAMPLE CNTRL FILE FOR LOCAL CP UPDATES
TEXT MACS2 LOCALIB DMKMAC CMSLIB OSMACRO
UP3 UPDTFIX 1.
PTF5 FIXTEST
LCL AUXLCL6
TEXT AUXRn0 7
N°1~
IThis is a comment record.
2VMFASM uses the library list from the MACS record to issue a GLOBAL
command before assembling the updated source file.
The libraries are
searched in the order specified. DMKAMAC should precede DMKMAC if AP
support is required.
3VMFASM and VMFLOAD use the update level identifier to identify the text
deck.
VMFASM uses the update level identifier of the most recent
update that was found and applied to name the text deck produced by the
assembly. VMFLOAD uses update level identifiers to locate text decks
when punching a new CP, CMS, or RSCS nucleus.
The update level identifier on the MACS record is used
name an assembled update text deck when no update files
is also used by VMFLOAD when it fails to locate a text
update level identifiers associated with update files
control files .
by VMFASM to
are found; it
file based on
or auxiliary
• The characters UPDT identify the filetype of a single update file,
UPDTFIX 1 in this example.
(The characters "UPDT" maybe omi tted.)
5The characters PTF in the update level identifier field identify this
file as a PTF file.
FIXTEST is the filetype of the update file.
6The characters AUX identify an auxiliary control file that lists
additional updates to be applied, local modifications in this example.
7AUXRnO is
the VM/370 auxiliary
control file,
listing updates
distributed by IBM.
This file is listed at the bottom of the control
file so that these updates are applied first.
334
IBM VM/370 Planning and System Generation Guide
Recommended Procedures
A control file can have
any number of update identification
(UPDTxxxx)
records, AUX file identification (AUXxxxxx) records, and
comments, but can have only one MACS record.
Example of a CP Update
Let's assume that you want to update CP, and then load a new CP nucleus.
The updates you are going to make consist of the following:
1.
You want to add a command to CP.
It has already been assembled
into the file DMKCMD TEXT.
The CP module DMKCFC must be updated to
recognize the new command name, so you have updates to apply to
DMKCFC.
2.
You have a local update to apply to the CP module DMKSCN.
3.
You want to change two members of DM·KMAC MACLIB; you have updates
to apply to ACCTON COpy (for accounting routines) and to RDEVICE
MACRO. Since the ACCTON COpy is modified, you have to reassemble
DMKACO; changes to the RDEVICE macro require you to reassemble
DMKRIO.
The procedures that you would use to perform these updates are
described next. Remember that the same procedures can be used when you
apply updates to any of the VM/370 components.
Using VMFASM To Update Source Files
If you are going to update a VM/370 module, you should always use the
VMFASM EXEC procedure, since it allows you to incorporate IBM-supplied
updates with your own.
The files used in the following example are shown in Figure 36. In
addition to the 194, 294, and 191 minidisks, you should also have access
to the CP assembler language source files on MAINT 394, and the eMS
system disk. The search order is:
191
294
194
394
190
A
R/W
B/A
CIA
D/A
S
RIO
RIO
RIO
RIO
This search order ensures that when the command
vmfasm dmkcfc yourown
is issued, the DMKCFC AUXLCL file from the 191 is used, not the copy on
the 294 disK.
(The copy on the 191 contains an additional entry for the
second local update file, DMKCFC LOCAL02).
The VMFASM EXEC prodecure invokes the UPDATE command with the CTL,
STK, and PRINT options. In this example, UPDATE uses the file YOUROWN
CNTRL to determine the order in which to apply the updates.
Since the
IBM auxiliary control file is the last item in YOUROWN CNTRL, updates
named in the file DMKCFC AUXRnO are applied first; then the entries
named in DMKCFC AUXLCL A are applied. Because no file named D~KCFC
UPDTLCL exists, no update is applied for that entry in the control file.
Part 5. Updating VM/370
335
Recommended Procedures
,
r
---,
lile1. YOURQWN CNTR1
~
File: DK!.EnO £!fI.E1
~
TEXT !!ACS D!!KKAC CKSLIB OSKACRO
LOC2 UPDTLCL
LCL.AUXLCL
TEXT AUXRnO i
TEXT KACS DMKMAC CKSLIB OSMACRO
TEXT AUXRnO
LOCALO 2
LOCALO 1
·R 1257 6DK
LOCALO 1
DMKCFC R12516DK B
DMKCFC LOCAL01 B
DMKCFC LOCAL02 A
D~!{SC!~
Qutput
DMKCFC
DMKCFC
DMKSCN
I
I
I
I
I
I
,
~
File§
TXTLCL A contains updates R12576DK, LOCALO' , and LOCAL02
TXTLCL B contains updates R12516DK and LOCAL01
TXTLOC2 A contains update DMKSCN UPDTLCL
294 (B-disk)
r
UPDTLCL
191 (A-disk)
I
DMKRnO
YOUROWN
DMKCFC
DPlKCFC
DMKCFC
DMKCFC
DKKCFC
,
L
,
I
L
194 (C-disk)
,,
,
TEIT
, DPlKPlAC
MACLIB
,
394 (D-disk)
r----------------~
, DMKCFC
I
I DMKSCN
r-
I DMKCFC AUXLCL
I D!!KCFC LOCAL02
I DPlKCFC TITLCL
DMKSCN UPDTLCL
I DMKSCN TITLOC2
I
I
CNTRL
I
CNTRL
AUXRnO I
R12576DK I
AUILCL I
TXTLCL I
LOCALOl
I
DMKCFC
TEXT
L________________
DMKCFC
ASSEMBLE,
I
I
I
ASSEMBLE,
I
I
~
Figure 36. Files for VPlFASM
lAUXRnO may be AUXR40, AUXR50,
release level.
336
AUXR60 and
so forth, depending
IBM VM/370 Planning and System Generation Guide
on the
Paqe of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Recommended Procedures
When all the updates have been applied, VMFASM calls the assembler to
assemble the updated source file, which has a temporary name of $DMKCFC.
When the assembly is complete, VMFASM uses the update level identifier
of the most recent update that was found and applied by the UPDATE
command to rename the text file produced by the assembly: in this
example, the output file is named DMKCFC TXTLCL.
The updated source file created by the UPDATE command is erased.
The UPDATES file produced by a multilevel update is concatenated into
the output text deck so that when this object code is
loaded,
information pertaining to its creation is contained in the load map.
Next, issue the VMFASM command to assemble DMKSCN ASSEMBLE:
vmfasm dmkscn your own
The UPDATE command searches for files named DMKSCN AUXRnO and DMKSCN
AUXLCL.
Neither of these files exists;
however, DMKSCN UPDTLCL (the
local update you created) does exist.
This update is applied,
the
source file is reassembled, and the output file is named DMKSCN TXTLOC2.
The updated source file creat~d by the UPDATE command is erased.
The
produced by a multilevel update is concatenated into the
output text deck, so that when this object code
is loaded, information
pertaininq to its creation is contained in the load map.
UPDATES file
Note: V~FASM creates (or replaces, if it already exists)
a temporary
workfile with a fileid of 'assemble-filename control-filename A1'.
This
file is erased when VMFASM is finished with it.
If the user already has
a file with this name it should be renamed using the CMS RENAME command,
to prevent its loss.
For example, if you enter
vmfasm dmkrcf yourown
the work file is named DMKRCF YOUROWN A1.
Not~.;. If the object modules created have a filetype of "TXTxxxx" and are
to be used with one of the GEN EXECs (CMSGEND,
DOSGEN, VSAMGEN, etc.),
they must be renamed with a filetype of "TEXT".
Using VMFMAC To Update iViacro Libraries
The VMFMAC EXEC procedure is similar
except that it is specifically designed
must provide:
•
•
•
to the VMFASM EXEC procedure,
to update macro libraries.
You
Update files, with UPDATE control statements to modify the macro
library members.
You must also have available any IBM PTFs that have
been distributed for the macro library.
A control file that lists update files or auxiliary control files to
be updated.
An EXEC file listing the names of the members to be included in the
macro lil-rary.
The files to be used for updatinq RDEVICE and ACCTON COpy are shown
in Fiqure 37.
In addition to these disKs, you should have access to the
source COpy and MACRO files on MAINT's 394 and the CMS system disk.
The
search order should be:
194 A
'R/W
191 BIA
RIO
294 CIA
RIO
394 D/A
190 S
RIO
RIO
Part 5. Updating VM/370
337
.n.t' ....
~~
I,
lJU
1
Recommended procedures
r---
'!QURQ!H! CNT]1
lCCTON AUXRn.Q
TEXT MACS DHKMAC CMSLIB OSMACRO
LOC2 UPDTLCI
LCL AUXLCL
TEXT AUXRnO
R12567DK
R12263DK
&1 &2 ABEND
&1 &2 ACCTOFF
&1 &2 ACCTON
MACRO
COPY
COPY
&1 &2 RDEVICE
MACRO
FIXPTF
194 (A-disk)
R12024DK
!f.:CTON
R12575D~
ACCTON
ACCTON
RDEVICE
R12263DK
UPDTLCL
FIXPTF
191 (B-disk)
DMKMAC EXEC
RDEVICE AUXLCL
ACCTON UPDTLCL
DMKMAC l"IACLIB
DMKMAC COpy
294 (C-disk)
394 (D-disk)
r----------------~
YOUROWN
DMKRnO
ACCTON
ACCTON
ACCTON
RDEVICE
RDEVICE
RDEVICE
CNTRL
CNTRL
ATJXFnO I
R12576DK I
R12263DKI
AIJXRnO I
R12024DKI
FIXPTF I
COpy
ACCTON
ACCTOFF COpy
ACCTON UPDTLCL
'---------
Figure 37. Files for VMFMAC
338
IB~
Vr/370 Planninq and System Generation Guide
Recommended Procedures
You must have the 194 in read/write status because VMFMAC renames the
existing MACLIB and writes a new one.
When you issue the command:
vmfmac dmkmac yourown
the V~F~AC EXEC procedure uses the DMK~AC EXEC to rebuild DMK~AC MACLIB.
VMPMAC calls the UPDATE command to update each of the macro and copy
files named in the EXEC.
In this
follows:
example, ACCTON
COpy
is
updated
with YOUROWN
1.
The IBM updates named in ACCTON
applied, in that order.
2.
Since no ACCTON AOXLCL file exists, the next entry
file results in no update.
3.
The update file ACCTON OPDTLCL is applied.
CNTRL
as
AUXRnO, R12263DK and R12576DK, are
in the control
For each entry in DMK~AC EXEC, VMF~AC checks to see if there are any
updates; if not, then the existing MACRO or COpy file is included in the
new MACLIB without any changes.
When the entry for RDEVICE is
YOOROWN CNTRL as follows:
reached, RDEVICE MACRO is updated with
1.
The IBM update named in RDEVICE AOXRnO, R1202QDK, is applied.
2.
The update named in RDEVICE AOXLCL, RDEVICE FIXPTF, is applied.
3.
Since no RDEVICE OPDTLCL file exists, the last entry in the control
file results in no update being applied.
After all the entries in the list DMKMAC EXEC are processed, V"F"AC
erases the existing D~KMAC MACLIB and creates a new D!KMAC MACLIB with
the updated members.
An additional file, D8KMAC COPY, is produced; this
file contains a record of the updates that were applied. DKKKAC COpy is
also added to DMK~AC MACLIB, to provide you with a record of changes.
NOW, since macro and copy changes affect CP modules, you must
reassemble DMKACO and DMKRIO using the new DMKMAC MACLIB.
If you have
no local updates for these assembler source files, you can use the
DMKRnO CNTRL file to update them:
VMFAS~
D~KACO
VMPASM
DMKRIO
You must be sure
are available on
DMKRnO (or DMKRnA)
DMKRnO
that all the current PTFs and
29Q.
auxiliary control files
~AINT's
The text decks produced by these assemblies are not uniquely named,
since the update level identifier in DKKRnO is always TEXT.
However,
the update log produced by VMFASM does indicate the macro libraries used
in the assembly, so you have a record of update activity.
Part 5. Updating V"/370
339
Recommended Procedures
VARIATIONS: If you do not want to use VMFMAC to update all of DMKMlC
"ACLIB
(it is very large, and V"FKAC is not practical if you are
updating only one or two members), you may want to consider manually
updating the macro and copy files using the UPDlTE command and then
using the "lCLIB REP command to update D"KMAC MACLIB. Or, you may want
to use V"FMAC to create a local macro library containing your changes,
and use this library, in addition to DMKMAC "lCLlB, when you reassemble
CP modules.
Consider the files:
goto label25
goto label25
RDEVlCE MACRO
ACCTON COpy
IQU ROW N CNT RL
TEXT MACS LCLMAC DKKMAC C"SLIB OSMACRO
toe 2 TJPDTtCL
LCL AUXLCL
TEXT AUXRnO
When you issue the command:
vmfmac lclmac yourown
the macro library LCLMAC KACLlB is created, containing only the members
RDEVICE and ACCTON. When you use YOUROWN CNTRL with the V"FASH EXEC
procedure, LCL"AC KACLIB is searched before DMKMAC MACLIB for the
assembly, so your macros are found first.
Using VMFLOAD To Punch a New Nucleus
After you have reassembled all the modules that require updating, you
may build a new CP nucleus that contains the updated text decks.
In our
example, you also want to include your new module, DMKCMD, in the CP
nucleus.
To punch a new nucleus, you use the V"FLOAD program, which requires:
•
A loadlist file, which must have a filetype of EXEC. It contains the
filenames of the object modules in the order in which they are to
reside in the nucleus.
•
A control file, from which VMFLOAD can determine the filetypes of the
latest level text decks, so it can punch them.
The files to be used for creating a new CP nucleus are shown in
Figure 38. This nucleus incorporates the updates described in the
preceding pages. The search order is:
3QO
191
A
R/W
29q
19q
B/A
CIA
RIO
RIO
190
S
R/O
IBM VM/370 Planning and System Generation Guide
Recommended Procedures
r
IQUROW! CN!.B1
DKKR 30 CNTRL
TEXT
LOC2
LeL
TEXT
TEXT MACS DKKKAC CMSLIB OSKACRO
TEXT AUXRnO
KACS DMKMAC CMSLIB OSKACRO
UPDTLCL
AUXLCL
AUXRnO
CPLOAD EXEC
&CONT ROL OFF
&1 &2 &3 DKKLDOOE LOADER
&1 &2 &3 DKKPSA
&1 &2 &3 DKKMCH
&CONTROL
&1 &2 &3
&1 &2 &3
&1 &2 &3
&1
&1
&1
&1
&1 &2 &3 DKKCFC
&1 &2 &3 DKKACO
&1 &2' &3 DMKRIO
&2
&2
&2
&2
&3
&3
&3
&3
DKKCFC
DKK ACO
DKKRIO
DKKCMD
&1 &2 &3
OFF
DKKLDOOE LOADER
DKKPSA
DKKKCH
LDT Dl'lKSAVNC
&1 &2 &3 LDT DKKSAVNC
194 (C-disk)
r
DMKLDOOE LOADER
DMKPSA
TEXT
DMKCFC
DMKACO
DMKRIO
DMKSCN
TEXT
TEXT
TEXT
TEXT
CPLOAD
EXEC
294
.-
YOUROWN
DMKRnO
DMKCFC
DKKCKD
191 (A-disk)
(B-disk)
CNTRL
CNTRL
TXTLCL
TEXT
r--
YOURLOAD
DMKCFC
DMKACO
DKKRIO
DMKSCN
EXEC
TXTLCL
TEXT
TEXT
TXTLOC2
Figure 38. Files for VKFLOAD
Part 5. Updating VM/370
341
Recommended Procedures
Since the VMFLO~D program uses your virtual card reader and virtual
punch, you must be sure there are no files in either of these devices
before you begin. You can issue the commands:
close
purge
close
purge
punch
punch all
reader
reader all
and you must
reader:
be sure
spool punch
to spool
your virtual
punch to
your own
card
*
When you issue the command
vmfload yourload yourown
V~!iTO~P
',!S~~
YOTJFI.nln F.Y'F.r +0 ;'p+prm;np
wh;~h
f;lp~
+.0
plln~h.
Tn onr
example, YOURLO~D EXEC is identical to the distributed CPLO~D EXEC file,
except that you have added an entry for your module DMKCMD.
VMFLO~D uses the loadlist to establish the filenames of modules to be
punched, and it punches them in the order they appear in the loadlist.
Thus, DMKLDOOE LOADER is punched first.
If a filename and a filetype
are specified in the loadlist, VMFLOAD punches the file.
When a filetype is not specified
(as is usually the case), VMFLOAD
uses the update level identifier field in the control file to determine
the filetype.
Since control files are structured so that the most
recent update is named at the top of the file, VMFLOAD begins reading at
the top of the file.
Since the next entry in the loadlist, DMKPSA, does not provide a
filetype, VMFLOAD looks at the control file.
In our example, since the
update level identifier for the first update record is LOC2, VMFLOAD
searches for the file DMKPSA TXTLOC2. Since this file does not exist,
VMFLOAD looks at the next lowest identifier: LCL.
It searches for
DMKPSA TXTLCL. Since this file does not exist, it reads the next lowest
identifier, TEXT.
DMKPSA TEXT exists on the 194, so it is punched.
Then VMFLOAD returns to the loadlist EXEC and repeats the same procedure
for the next entry.
You can see that when VMFLOAD reaches the entry for DMKCFC in the
loadlist, it locates the file DMKCFC TXTLCL, the DMKCFC module that
contains your updates. Notice that although there are copies of DMKCFC
TXTLCL on both the A-disk and the B-disk, V"FLOAD punches the one on the
A-disk, since it uses the standard CMS order of search.
The loading process continues
loadlist EXEC file.
When all of
receive the messages
in this way until the end of the
the modules have been punched, you
SYSTEM LOAD DECK COMPLETE
PUN FILE 0821 TO MAINT COpy 01 NOHOLD
342
IBM VM/370 Planning and System Generation Guide
Recommended Procedures
These messages indicate that a copy of the new
card reader.
This CP nucleus contains all the
disk, except that the files:
CP n uc Ie us is
text decks on
in your
the 19q
DMKCFC TXTLCL
DMKSCN TXTLOC2
have been punched instead of their TEXT counterparts; the files
DMKACO TEXT A
DMKRIO TEXT A
have been punched instead of their counterparts on the C-disk; and your
new command module, DMKCMD, is included.
Once the new nucleus has been punched into your card reader, you can
load it and test it.
considerations for loading and testing each of the
VM/37Q components are discussed separately in the following pages.
Part 5. Updating VM/370
3q3
344
IBM VM/370 Planning and System Generation Guide
Updating CP
Building a New CP Nucleus
If you are going to use the MAINT userid to load and test a
nucleus, you should be sure that MAINT's virtual machine has:
new CP
•
A minimum 512K of virtual storage.
The loader requires 512K to
execute. In general, MAINT's virtual machine should have as much
virtual storage as the real machine storage size.
•
The ECMODE option specified in the VM/370 directory (or has used the
CP SET ECMODE ON command) •
ECMODE is required for testing the CP
system in your virtual machine.
•
write access to the CP system residence volume, or a minidisk that is
a replica of the system residence volume. The minidisk must be
defined in your virtual machine at the same address as the real
address of the system residence volume.
The minidisk must have been
formatted with the CP Format/Allocate program, such that it resembles
the CP system residence; nonexistent cylinders beyond the extent of
the minidisk must be allocated as permanent space (PERM).
When you prepare to load a new CP nucleus, you should be sure that
you have the disks containing object modules accessed in the proper
order to ensure that the correct files are punched. Then you issue the
following series of commands:
close punch
purge punch all
close reader
purge reader all
spool punch
vmfload yourload yourown
*
where YOURLOAD
file.
is the
loadlist EXEC
file and
YOUROWN is
the control
When the VMFLCAD program completes, you receive the messages:
SYSTEM LOAD DECK COMPLETE
PUN FILE 0821 TO MAINT COpy 01 NOHOLD
At this point the standalone loader (DMKLDOOE LOADER) is in your card
reader, followed by all of the text decks necessary to construct a CP
nucleus. There are several ways to handle this reader file.
First, you can use the CMS MOVEFILE command to place the entire file
on tape, thus creating a CP nucleus load tape. Later you can IPL the
tape drive on the real machine when you want to update the CP system.
Remember, however, that the loader requires 512K of storage.
The second way to handle the CP nucleus reader file is to IPL the
loader from the tape.
If you have access to the real system residence
device in your virtual machine, the nucleus is written on the real
system residence volume. If you have a minidisk defined at a virtual
address corresponding to the real address of the CP system residence
disk, the nucleus is written on that disk~
A third way is to IPL the nucleus directly from the card reader; this
method is shown in the example that follows.
However,
it does not
provide you a backup copy that you can IPL.
Part 5. Updating VM/370
3q5
Updating CP
For example, if MAINT's virtual machine has entries for the real
system residence volume at address 330, and for a minidisk replica at
address 331, you may detach the real system residence volume and define
the minidisk at that address:
detach 330
define 331 as 330
Now you can IPL the CP nucleus, specifying the address of your
virtual card reader.
When the load operation completes, the message
"NUCLEUS LOADED ON SYSRES" is
displayed, followed by a message
indicating a disabled wait state PSW, the normal termination of the
standalone loader program.
ipl OOc
NUCLEUS LOADED ON SYSRES
DMKDSP450W CP ENTERED; DISABLED WAIT PSW
CP
When you IPL the nucleus, the load map is spooled to your virtual
printer. You must issue the CLOSE command to close the spool file.
If
you want to retain a copy of the load map as a CMS disk file, you first
issue the command:
spool printer to
*
so that the load map is routed to your card reader and you can later use
the CMS READCARD command to write the load map on disk.
Now, define your console address to be the same as defined in the
RIOGEN macro in DMKRIO. Then you can IPL the system residence device,
which is the virtual disk with an address of 330.
def 009 as cuu
CONS cuu DEFINED
ipl 330
The following example shows the IPL of the nucleus. The two error
messages
(both DMKLNK108E)
occur because UDISKl and UDISK2 are not
defined in MAINT's virtual machine configuration.
VM/370 VERSION n LEVEL 0
NOW 14:53:07 EST THURSDAY 03/28/74
CHANGE TOD CLOCK (YESINO) :no
14:53:50 DMKLNK108E CMSSYS 190 NOT LINKED; VOLID UDISK2 NOT MOUNTED
RRRR •.•• RING •••• GGGG
14:53:50 DMKLNK108E OPERATOR 191 NOT LINKED; VaLID UDISKl NOT MOUNTED
RRRR •••• RING •••• GGGG
14:53:50 START «COLDIWARMICKPTIFORCE) (DRAINISHUTDOWN) : shutdown
14:53:50 AUTO LOGON
OPERATOR USERS = 001 BY SYSTEM
***
DMKCPI960W SYSTEM WARM START DATA SAVED
DMKCPI961W SYSTEM SHUTDOWN COMPLETE
DMKDSP450W CP ENTERED; DISABLED WAIT PSi
CP
After you check the new CP, you may redefine your console and IPL the
eMS system
(CMS accepts only 009 and 01F as valid console addresses) •
After you IPL CMS, you can use the DDR command to create a backup copy
of the CP nucleus
(which can then be restored to the real system).
346
IBM VM/370 Planning and System Generation Guide
Updating CP
Define your input unit as the address of your system residence device.
Your output unit is the tape (181)
that is attached to your virtual
machine. When you enter the DUMP statement with the NUCLEUS operand,
DDR creates a copy of the nucleus that was just loaded.
The sequence of commands and responses is:
def cuu as 009
CONS 009 DEFINED
ipl cms
CMS ••• mm/dd/yy
ddr
ENTER: in 330 3330 sysres
ENTER: out 181 2400
ENTER: dump nuc
DUMPING SYSRES
END OF DUMP
ENTER:
END OF JOB
R; T=0.21/2.63 15:04:04
You created a backup copy of the CP nucleus. This copy may later be
restored using the standalone version of the DDR program on the real
machine.
Part 5. Updating
V~/370
347
348
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Updating CMS
Updating eMS
The procedures for updating C~s source files and macro libraries are the
same as for updating CPa The order of search for CMS updates is:
191 A
R/i
193 BIA RIO
190 CIA RIO
393 D/A PIO
where 193 con tains PTFS, control files, and user updated TEXT decks and
393 contains the eMS source files~ 190 contains the current eMS system,
including text decks, command modules, and the CMS nucleus.
You might use the following steps when you update CMS:
1.
Format the minidisk you
if any.
are going to use to test
the CMS nucleus,
2~
Use the VMFLOAD program to punch the updated eMS object modules.
3.
Regenerate any disk-resident modules that have been updated.
4.
Load the new CMS nucleus.
5.
Save the CMSSEG discontiguous shared segment and the new C~S
operating system.
eMS should be resaved whenever the S-disk is
updated. This will insure that the saved CMS system reflects the
physical system.
The exact steps that you take depend on whether you are testing the
CMS nucleus before you load it onto the system disk, whether you are
using shared segments, and so on.
Disks for Updating eMS
If you want to keep eMS source files on disk, the minidisk you use must
be at least 145 cylinders for a 2314
(or 2319), 80 cylinders for a 3330
disk, 190 cylinders for a 3340 disk, or 40 cylinders for a 3350 disk.
Then, you should have the eMS source tape mounted and attached to the
virtual machine, and issue the following commands to load the source
programs onto the eMS disk:
vmfplc2 fsf
vmfplc2 load (eof 2)
If you want to test the new eMS nucleus in a virtual machine before
you update the real eMS system, you should have a disk available for a
copy of the nucleus.
The configuration shown for MAINT in "A Virtual
Machine for Updating VM/370" shows a 6-cylinder minidisk at virtual
address 390 for testing the eMS nucleus.
You can test updated disk-resident CMS
moving them to the eMS system disk (190).
modules on your A-disk before
Part 5. Updating VM/370
349
Updatinq
eMS
FORMATTING A DISK TO TEST THE CMS NUCLEUS
Before you can use the minidisk you have available for testing CMS, it
must be formatted with the CMS FORMAT command.
For example, to format
the 390 minidisk, you might issue:
format 390 g.
NOw, you must reissue the FORMAT command with the RECOMP option, so that
the number of cylinders on the disk is recomputed to reserve space for
the C~S nucleus at the end of the disk.
To do this, format the disk
with one or two cylinders fewer than it actually has (one cylinder on a
3330 or 3350, two cylinders on a 2314 or 3340).
For example, if the 390 minidisk is a 3-cylinder 3330, enter
format 390 g 2 (recomp
The 390 disk is now ready for use as the CMS test nucleus.
You should not have
time you update CMS.
to reformat the disk again; you
can use it each
CONSIDERATIONS FOR CREATING A NEW CMS SYSTEM DISK
If you want to create a new CMS system disk that contains all the CMS
text and MODULE files as well as the CMS nucleus, do the following:
•
If you are goinq to save this CMS system, be sure that the operands
VSYSADR, SYSCYL, and VSYSBES in the NAMESYS macro corresponding to
this system are correct.
•
After
copying all the existing files with filetypes of TEXT and
onto the new disk, regenerate any modules that use auxiliary
directories (such as the ASSEMBLE command).
Auxiliary directories
are described in the VM/37Q ~yst~~ PrQg£~£~ QYig~.
You can use
the CMSGEND EXEC procedure to regenerate the assembler.
Some IBM
Program Products may also use auxiliary directories.
~ODULE
Punching the eMS Nucleus
When you prepare to build a new CMS nucleus, be sure that you have
access to the text decks on the system disk, as well as any updated
decks that you may have created. Since the CMS text decks are on the
CMS system disk (usually 190), you should access it so that you have
these text decks available for the VMFLOAD program:
access 190 a
Be sure that your virtual card punch and reader do not have any files in
them and that your virtual punch is spooled to your virtual reader:
close
purge
close
purge
spool
350
punch
punch all
reader
reader all
pu nch to *
IBM VM/370 Planning and System Generation Guide
Upda ting CMS
Then you can issue the VMFLOAD command specifying the
EXEC filename and the control file filename:
CMS loadlist
VMFLOAD CMSLOAD DMSRnO
In this example: the system-supplied CMSLOAD EXEC and DMSRnO CNTRL files
are used to punch a new CMS nucleus.
When you receive the messages
SYSTEM LOAD DECK COMPLETE
PUN FILE 0353 TO MAINT COpy 01 NOHOLD
a new copy of the CMS nucleus is available in your card reader.
Before
you go on to load the new nucleus, you may want to regenerate any CMS
MODULE files that have been updated. This procedure is described next.
To determine whether an update requires module regeneration see
"Appendix C: CP/CMS Regeneration Requirement." If you do not need to
regenerate any modules, see "Loading a CMS Nucleus."
Creating CMS Disk-Resident Modules
The CMSGEND EXEC procedure creates CMS disk-resident command modules
from CMS text files.
CMSGEND is invoked by specifying the filename of
the module to be generated. For example, if there is a change to the
text file DMSACF, you must generate a new ACCESS MODULE.
cmsgend access
CMSGEND will rename any existing file from 'ACCESS MODULE A2' to
'ACCESS MODOLD Al'.
After an existing file of 'ACCESS MODOLD All is
erased CMSGEND then loads the text files that comprise the ACCESS
command module and generates a new ACCESS module A2.
When you use CMSGEND, you must access the S-disk as your read/write
A-disk, and have all pertinent text files available: The text files
must have a filetype of TEXT; thus, if you have updated an object module
using VMFASM,
and the most recent object file has a filetype such as
TXTLOCAL, you must rename it to a filetype of TEXT.
(Note that if there
is currently a text file on the system disk, you may want to rename it
also, so that your updated text file, on some other disk, is the one
tha t is loaded.)
CMSGEND displays status messages as it executes.
For example:
cmsgend access
***
CURRENT STATUS:
FILE' ACCESS MODULE A21 DOES NOT EXIST
FILE I ACCESS MODOLD Al' DOES NOT EXIST
***
LOADING:
INVALID CARD INVALID CARD INVALID CARD ACCESS
SD OOEOOO
INVALID CARD READFST SD OOEBCO
DMSACM
SD 00EF10
READMFD
00EF10
*
**
*
Cl1SL IB
l1ACLIB
A2 RnM190 12/04/75
DOSMACRO MAC LIB
A2 RnM190 10/16/75
D!!SACC
ASSEMBLE Al RnM303 12/03/75
04:20
23: 19
04:02
CMSLIB
23: 19
MACLIB
A2 RnM196 10/16/75
Part 5. Updating VM/370
351
Updating CMS
INVALID CARD - *
INVALID CARD - *
DMSAlU
SD 00F4A8
RELUFD
00F4 A8
SORTFST
00F716
END$RELU
00FF38
OSMACRO MACLIB
OSMACR01 MACLIB
S2 RnM290 10/16/75
S2 RnM290 10/16/75
22:47
22:49
***
RESULTS:
, ACCESS MODULE A2' CREATED FROM TEXT DECK ( S ) DMSACC DMSACF
DMSACM DMSALU WITH ATTRIBUTES TRANS SYSTEM NOMAP
Since CMSGEND renames the existing module, users who are currently
using the CMS system disk are unaffected by the regeneration procedure.
This is because the SSTAT (system status table) of the CMS system disk
is still pointing to the old
(renamed)
module.
Whenever 190 is
subsequently IPLed, the SSTAT points to the updated modules, so that the
old module can be erased.
Loading a CiviS Nucieus
When you are ready to load the
two si tuat ions.
CMS nucleus, you should
plan ahead for
If you are going to test the CMS nucleus on a minidisk other than 190
(we are using 390 in this example), you may want to save the nucleus
reader file so that you do not have to repeat the VMFlOAD procedure if
the nucleus tests out all right.
To do this, issue the command:
spool reader hold
You may also want to issue the command
spool printer to
*
so that the nucleus load map is routed to your
the virtual printer.
card reader, instead of
If your CMS system uses the CMSSEG discontiguous saved segment, you
should anticipate that it may not be compatible with the new CMS
nucleus.
Later, you will want to use the CMSXGEN procedure to save the
segment, but for testing purposes, you do not need it.
Therefore, to
prevent CMS from attempting to attach CMSSEG after IPL,
you can define
your virtual storage to 2M:
define storage 2m
Now you can issue the IPL command to load the CMS nucleus:
ipl
~Oc
clear
During the 1PL sequence, you must respond to the following messages.
DMSINI606R SYSTEM DISK ADDRESS = cuu
Enter the device address (cuu) of the system disk (S-disk). This
is usually 190.
On this disk CMS expects to find all CMS system
information and programs not contained within the CMS nucleus, such
as the disk-resident command modules. If the eMS nucleus is written
on this disk, then cuu is also the IPL device address.
352
IBM VM/370 Planning and System Generation Guide
April 1, 1981
Updating
C~S
If you enter an invalid device address, the message
DMSINI079E INVALID DEVICE ADDRESS - REENTER
is issued. Message DMSINI606R is reissued so that you
valid device address.
can enter a
If you press the carrier return without entering a device address,
X'190' is assumed to be th~ system disk address.
DMSINI615R Y-DISK ADDRESS = cuu
Enter the device address
(cuu) of the system disk extension
(Y-disk). On this disk CMS expects to find all C~S system
information and programs not contained within the CMS nucleus and
not on the ~-disk. If the CMS nucleus is written on the Y-disk,
then cuu is also the IPL device address.
If you enter an invalid device address, the message:
DMSINI079E INVALID DEVICE ADDRESS - REENTER
is issued: Message DMSINI615R is reissued so that you
valid device address.
can enter a
If you press the carrier return without entering a device address,
X'19E' is assumed to be the address of the system disk extension.
Notgl If you do not want to have a Y-disk, do not attach the device
that was specified (or defaulted to) as the Y-disk address.
DMSINI607R REWRITE THE NUCLEUS?
(YES'N~
If you enter "yes", a copy of the CMS nucleus is written onto the
disk indicated in the response to messageDMSINI608R.
If you enter
"no", the eMS nucleus is not written to disk.
If you enter neither "yes" nor "no," the message
DHSINI081E INVALID REPLY - ANSWER "YES" OR "NO"
is issued. Message
valid response.
DMSINI607R is reissued so that you
can enter a
If you enter "no", the remalnlng messages in generating a new CMS
nucleus are skipped and control is passed to the CMS initialization
routine.
DMSINI608F IPL DEVICE ADDRESS
= cuu
Enter the address of the device (cuu) on which the CMS nucleus is
to be written.
If you are using 390 to test the CMS nucleus, you
enter: 390. If the system disk and the IPL device are to be the
same, you need only press the carrier return.
If you enter an invalid device address, the message
D~SINI079E
INVALID DEVICE ADDRESS - REENTER
is issued. Message DMSINI608R is reissued so that you
valid device address.
can enter a
Part 5. Updating VM/310
353
Updating CMS
If the IPL device you designated is not currently defined, is not
in read/write status, or is an unsupported device type, the message
DMSIN1082E IPL DEVICE ERROR - REENTER
is issued. Message DMSINI608R is then reissued. At this time, you
may enter CP mode by pressing the Attention key (or equivalent) ,
then determine the status of the device you designated by entering
the CP command
QUERY VIRTUAL cuu
and take the corrective action necessary to define the device for
your virtual machine or to access it in read/write status. You may
reenter CMS by issuing the CP command
BEGIN
Then you must reenter the device address. Once
is accepted, message DMSINI609R is issued.
the device address
DMS1NI609R NUCLEUS CYL ADDRESS = nnn
Enter the 1- to 3-digit cylinder number (nnn), for the device
entered in response to message DMSINI608R, where the CMS nucleus is
to be written. The number (nnn) must be between 1 and m-1 (where m
equals the number of cylinders on the disk). The number nnn must
be entered in decimal. This is the cylinder you reserved when you
formatted the disk with the RECOMP option. In our example, since
the nucleus is written on the last cylinder of MIINT's 390, you
enter: 2
If you do not enter a valid decimal cylinder number, the message
D~S1NI080E
INVALID CYLINDER NUMBER - REENTER
is issued.
Message DMSIN1609R
valid cylinder number.
is reissued
and you
may enter
a
If the cylinder specified is not greater than the number of
cylinders already in use on the device (as indicated in the master
file directory, then the message
DMSINI083E NUCLEUS WILL OVERLAY FILES - RECOMPUTE
is issued. You may respond with a larger cylinder number, or IPL
CMS and format the specified IPL device with the RECOMP option.
DMS1N1610R ALSO 1PL CYLINDER 01 (YESfNO)
The initial IPL text is always written on the same cylinder as the
CMS nucleus
(the cylinder designated in response to message
DMS1NI609F). The initial IPL text is a bootstrap program which
reads the nucleus from the designated cylinder. If it is not also
written on cylinder 0, then you must enter the cylinder number when
subsequent IPL commands are issued for the system being generated.
See the IPL command description in the y~70 CP ~Q~mgng ~efereD£~
iQt Qgneral Q§~~§. Your response has the following meaning:
354
yes
Initial 1PL text is written on cylinder 0 as well as
cylinder designated in response to message DMSINI609R.
no
Initial 1PL text is written only on the cylinder designated in
response to message DMSINI609R.
IBM VM/370 Planning and System Generation Guide
on the
April 1, 1981
Updating CMS
If you do not enter "yes" or "no," the message
DMSINI081E INVALID REPLY - ANSWER "YES" OR "NO"
is issued. Message DMSINI610R is
enter a valid response.
reissued so
that you
can
If your response is valid, message DMSINI611R is issued.
DMSINI611R
VERSION IDENTIFICATION =
Enter up to 32 bytes
of information,
including blanks, to
specifically identify
the version and· level of
CMS; this
information is printed each time you IPL the crtSsystem now being
generated.
The default identification (specified by a carrier
return) is:
CMS VERSION n.n - mm/dd/yy
where n.n is the version and level of CMS, and mm/dd/yy
month, day and year the CMS nucleus was created.
DMSINI612R
is the
INSTALLATION HEADING =
Enter up to 64 bytes of information, including blanks, to serve as
an installation standard beading at the beginning of each output
file.
The default heading (specified by a carrier return) is:
CONVERSATIONAL MONITOR SYSTEM
The nucleus is then written on the specified disk cylirider and the
version identification is displayed, indicating that the CMS system is
loaded successfully and is ready to accept CMS commands.
You can use this copy of CMS to test updates and changes, including
changes to CMS modules that you may have made with the CMSGEND EXEC.
Before you test the CMS system, you can create a
CMS nucleus and the nucleus load map:
disk file from the
spool rdr nohold
close prt
close rdr
PRT FILE 0342 TO MAINT COpy 01 NOROLD
Now you can read a copy of the CMS nucleus onto disk:
read cmsnuc nucleus a1
and read a copy of the CMS load map:
read cmsnuc loadmap a1
RECORD LENGTH IS '132' BYTES.
You now have two CMS files on your 191 disk: CMSNUC NUCLEUS, which
contains the eMS nucleus created above, and CMSNUC LOADMAP, the load map
for this nucleus.
After you test the new eMS nucleus on 390, and you are satisfied that
it is all right, you can use the disk file to create the new nucleus on
the system disk (190).
Part 5. Updating VM/370
355
Updating CMS
To regenerate a nucleus which exists as a disk file (CMSNUC NUCLEUS,
for example), issue the following commands:
*
spool pun to
punch cmsnuc nucleus a1
ipl OOc
(noheader)
You may then answer the IPL messages previously described.
This
time, you specify the IPL address as 190 instead of 390, and enter the
correct cylinder for your system disk. Now you can go on to save the
CMSSEG and the eMS saved system, if you wish.
Noi~ If a named saved system has
been built from this CMS system disk,
it must be resaved because the SSTAT is recreated only when the disk is
loaded (for example 190). Appendix C details what must be regenerated
for changes in any CMS text file.
Saving CMSSEG and the CMS System
If your system has entries in the system name table (DMKSNTBL)
for a
CMSSEG discontiguous segment and a named CMS, you should now save these
system names.
To do this, first be sure that you have defined virtual
machine storage to a value above the location of CMSSEG and the loader
tables, for example 2M.
Then, you can IPL
CHSSEG segment:
CMS and
issue the
CMSXGEN command
to save
the
ipl 190 parm seg=null
(null line)
Y (19E) RIO
R;
access 190 b/a
R;
cmsxgen 100000
where 100000 is the hexadecimal address where the segment is loaded.
This number must correspond to the starting page number specified in the
NAMESYS macro for the CMSSEG saved system name.
CMSXGEND generates a
LOAD MAP on OOE which will appear in your reader and is required by
IPCS.
When the CMSXGEN procedure is completed, you should IPL the CMS
system disk again, and issue the CP SAVESYS command immediately, before
pressinq a carriage return to complete the IPL:
ipl 190
savesys cms
In this example, CMS is the name of the saved CMS system.
If you have
specified another name for the saved CMS system, you should specify that
name when you issue the SAVESYS command.
SAVESYS is a CP privilege
class E command; it allows you to write on the CP system residence
volume.
NOw, the saved portion of CMS may be shared among many users, who can
load CMS by referrinq to its saved name, for example
ipl ems
When you IPt a saved CMS system, CMS operates as if an IPL of a
specific device had occurred, with the single exception that the
directory for the system disk is part of the nucleus.
356
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Updating CMS
Update Procedures for CMS/VSAM and Access
Method Services
You are responsible for ordering and applying all updates to DOS/VS that
affect the VSAM and access method services routines and the DOS logical
transients
($$BOMSG1,
$$BOMSG2, $$BOMSG7,
and $$BENDQ)
that CMS
distributes.
You can order these updates in card form or on tape.
If you order the updates on cards,
you must remove all of the DOS/VS
job control statements from each PTF
(program temporary fix)
deck and
place a CP ID ~ard at the beginning of the deck. The CP ID card must
contain the userid of the CMS virtual machine that is being
used to
update VSA~ and access method services.
For example,
if you vant to apply an update
MAINT virtual machine, your ID card is:
to a module
using the
ID MAI}1T
If you installed VSAM and access method services under eMS as an OS
user,
VSAMGEN created eMS text files for all the required DOS/VS
relocatable library modules.
Now you need not have a DOS/VS relocatable
library for updating.
CMS creates text files from the updates and
replaces the old text files on your A-disk with the new text files.
Text files must have a filetype of TEXTe
For example, after you have
updated an object module using VMFASM, the most recent object file has a
filetype such as TXTLOCAL.
To use that text file here, you must rename
it to a filetype of TEXT.
If there is currently a text file on the
systeID disk, you may want to rename it too, so that your updated text
file (which may reside on another disk) is the one that is loaded.
VSAMGEN UPDATE CONSIDERATIONS
Applying DOS/VS PTFs to either the CMSVSAM or the CMSAMS discontiguous
saved segments may result in the generated segment exceeding the space
defined for it in the system name table (see the NAMESYS macro of the
DMKSNT module).
You may want to anticipate this problem by defining in
the system name table
an additional shared and nonshared segment for
each of the discontiquous saved seqments
(CMSVSAM and CMSAMS).
This is
one way of providinq for additional growth~
Alternatively, upon completion of the VSAMGEN update procedure, you
can check whether the updated segments have exceeded their definitions
and correct that situation as follows:
1.
Determine the new size of the changed VSAM and/or access method
services shared and nonshared segments by subtracting the phase
LOCORE address from the BICORE address indicated on the linkage
editor map.
The phase names are:
•
•
•
•
•
2.
Dr-:[ SVVS -
Dl'lSVV}1
DMSVAS
DMSVAN
DMSV33
-
VSAM shared
VSAM nonshared
access method services shared
access method services non shared
VSAM shared (DOS/VS Release 33 or 34)
Compare the new
sizes of these segments with the sizes of the
correspondinq shared or nonshared segments as defined in your
DMKSNT NAMESYS macro.
Part 5. Updating VM/370
357
.t'a.y~
Ul.
b~~U- lOV 1- IV
AB
Upad~ea
Apr~.L
I,
''::I~'
DY
,,!'NL
GNL!)-Utsj I
Updating CKS
3.
If the new size exceeds your defined size, recode the NAMESYS
macros to include an additional segment. Refer to the phase names
listed in step 1 to determine whether the segment is shared or
nonshared. To add one segment:
•
•
•
•
•
4.
Increase the SYSPGCT operand by 16
Increase the SYSPGNM operand by 16
Increase the SYSHRSG operand by 1, if the segment is shared
Increase the SYSSIZE operand by 64K
Change the SYSSTRT operand of this or other segments,
increase in this segment causes any segments to overlap
Reassemble the DMKSNT module, build a
reexecute theVSAMGEN procedure.
new CP
if the
nucleus, and
then
If a PTF .contains a new VSAM or access method services module, it is
nat included in CMSVS1~ or C~SlMS during VSAMGEN llnl~ss you have CtiLL~nt
level of installation files.
If you want to use a new release level of DOS/VS, you must regenerate
the CMSVSAM and CMSAMS segments using the starter system supplied by
DOS/VS.
VM/370 al$~ provides new installation EXECs and DOSLNK files,
which vou must
use to install the new
release properly.
The
installation procedure is described in Part 3.
No.t~l It
is not necessary to regenerate existing Cl!SVSAM and CMSAMS
segments using the Release 34 starter system. If you do so, however,
you must be sure that the space allocation for the CMSVSAM segment in
the system name table (D!'!KSNT) file is increased to five shared segments
and one nonshared segment, and the space allocation for the CMSAMS
segment is increased to 6 shared segments and 2 nonshared segments.
Note that the segment addresses above these segments must be increased
accordingly.
USING VSAMGEN TO UPDATE Cl!S VSAM AND ACCESS METHOD SERVICES
Before you invoke VSAMGEN, do the following:
•
Access a C~S read/write disk as your A-disk. This disk must be the
same disk that you used as your A-disk when you installed VSAM and
access method services.
•
If you are a DOS user, link to and access the DOS/VS system disk.
•
If you are applying PTFs from tape, a tape drive must be attached at
virtual address 181 and the PTF tape must be mounted and positioned
at the first tape file you want processed. VSAMGEN assumes that the
PTF tape is unlabeled and contains 3440-byte blocks of records.
Use the VSAMGEN EXEC procedure to update VSAM
Services support in CMS.
Invoke VSAMGEN as follows:
vsamqen
358
IBM VM/370 Planning and System Generation Guide
and Access
Method
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Updating CMS
VSAMGEN prompts you to enter what type of user you are and whether you
plan to install or update VSAM and access method services. You receive
the following messages:
DMSVGN360R ENTER EITHER 'INSTALL' OR 'UPDATE':
DMSVGN361R ENTER EITHER 'DOS' OR 'OS':
At this time, you should respond: UPDATE and either DOS
are both, respond liDOS."
Part 5. Updatinq
or OS.
If you
V~/370
358.1
Ii pI"
358.2
~
J.
I ,
I ':1 0 I
IBM VM/370 Planning and System Generation Guide
Upda tin; eMS
VSAMGEN requires a read/write A-disk
available. If an A-disk is not available,
following messages and terminates:
and checks that one is
VSAMGEN issues one of the
DMSVGN069E DISK 'A' NOT ACCESSED
DMSVGN361E DISK 'A' IS NOT A CMS DISK
You are prompted to enter
system you are using:
the release
level of the
DOS/VS starter
DMSVGN369R ENTER RELEASE NUMBER OF THE DOS/VS STARTER SYSTEM:
You should enter 31,
receive the message
32, or 33 or 3q.
If you
enter anything else, you
DKSVGN369E INVALID - RELEASE 31 OR LATER REQUIRED
and the VSAMGEN EXEC procedure terminates.
If you are a DOS user, you
relocatable library by filemode.
are
asked to
identify
the
DOS/VS
DMSVGN362R ENTER MODE OF DOS SYSTEM RELOCATABLE LIBRARY DISK:
Next, VSAMGEN checks that the files it requires are on an accessed
disk and invokes the CMS/DOS environment.
You are now prompted to
indicate whether you want to update VSAM or access method services or
both.
DMSVGN36QR ENTER 'CMSVSAM' OR 'CMSAMS' OR 'BOTH' FOR GENERATION
OF NEW SYSTEM (S).
Now, you must indicate whether the updates you are applying
card format or on tape. Respond to the message:
are in
DMSVGN380R ENTER 'TAPE' OR 'CARDS' FOR PTF APPLICATION:
The following two sections describe the procedure
and tape PTFs to CMS VSAM and access method services.
f or a ppl jing
If you reply CARDS, you must already have placed each PTF deck, with a
CP ID card as the first card in the PTF deck, in a real card reader and
must h~ve read the decks into the virtual card reader.
VSA8GEN
indicates it is reading the PTF decks by issuing the message:
DMSVGN366I STARTING TO READ PTF DECKS FROM READER •••
You must now indicate what module you
message:
want updated by responding to the
DMSVGN365R ENTER MODULE NAME (8 CHARS OR LESS) OR 'END':
The order of the names you give in response to this message must be the
same as the order in which you placed the decks in the reader.
Part 5. Updating VM/370
359
Updating Ct1S
Each time you respond to this message, VSAt1GEN checks that a module
with that name already exists on the A-disk, erases any old text file
with that name, renames the current text file to fn TEXTOLD, and reads
the new text file in and writes it on the CMS A-disk. When the new text
file replaces the old, you receive the message:
DMSVGN367I 'fn TEXTc WRITTEN ON DISK 'A'.
You will receive message DMSVGN365R again; either enter the name of the
next text file you want to update, or enter END.
When all the hew text files are
receive the status message:
written
to the
CMS A-disk,
you
DMSVGN368I nn NEW PTF DECKS WILL BE APPLIED
From this point on, the procedure for updating VSAt1 and access method
services is identical to the installation procedure for fetching,
link-editing. loadinq and savinq them.
You receive the following
messages:
DMSVGN362I LINK-EDITING {Ct1SVSAM} •••
CMSAMS
DMSVGN363I {Ct1SVSAM} DOSLIB CREATED ON DISK 'A'
Ct1SAMS
DMSVGN363R ENTER LOCATION WHERE {CMSVSAt1} WILL BE LOADED AND SAVED:
CMSAMS
DMSVGN366R ENTER NAt1E OF SYSTEt1 TO BE SAVED:
VSAt1GEN fetches the modules, loads them at the designated address,
assigns storage protection keys, and saves the segments.
You receive
the completion message:
Dt1SVGN365I SYSTEt1 segmentname SAVED.
Finally, you must indicate whether or not you wish to erase the
DOS LIB created during link-edit. You receive the following message:
Dt1SVGN368R ERASE {CMSVSAt1} DOSLIB? ••• ENTER YES OR NO:
Ct1SAt1S
If you replied TAPE to the DMSVGN380R message, you must now indicate
whether you want to apply all the PTFs or just a selected number of
PTFs. Reply to the message:
ENTER 'SELECT' OR 'ALL' FOR TAPE PTF APPLICATION:
You must also indicate how many PTF
respond to the message:
tape files are now to be processed;
Dt1SVGN382R ENTER NUt1BER OF TAPE FILES TO BE PROCESSED:
360
IBt1 VM/370 Planning and System Generation Guide
Updating C!!S
If you entered ALL, the installation procedure applies all the text
files that affect the CMS VSAM and access method services support. If
you entered SELECT, the installation procedure sends you a message each
time it finds a text file that is used by CMS to support VSAM and access
method services. You must reply to these messages:
DMSVPD383R APPLY 'filename'? ••• ENTER 'NO' OR EOB:
Before VSAMGEN writes a new text to the A-disk, it checks that a
module with that name already exists on the A-disk, erases any old text
file with that name, renames the current text file to fn TEXTOLD, and
writes the new text file on the CMS A-disk. When the new text file
replaces the old, you receive the message:
DMSVPD367I 'fn TEXT' WRITTEN ON DISK 'A'.
When all the new text files are
receive the status message:
written
to the
CMS A-disk#
you
DMSVPD3681 nn NEW PTF DECKS WILL BE A·PPLIED
From this point on, the procedure for updating VSAM and access method
services is identical to the installation procedure for fetching,
link-editing, loading, and saving them.
You receive the following
messages:
DMSVGN3621 LINK-EDITING {CMSVSAM} •••
CMSAPIS
DMSVGN3631 {CPISVSAft} DOSLIB CREATED ON DISK 'A'
CMSAMS
DMSVGN363R ENTER LOCATION WHERE {CMSVSAM} WILL BE LOADED AND SAVED:
CMSAMS
DMSVGN366R ENTER NAME OF SYSTEM TO BE SAVED:
VSAMGEN fetches the modules, loads them at the designated address,
assigns storage protection keys, and saves the segments.
You receive
the completion message:
DMSVGN3651 SYSTEM segmentname SAVED.
Finally, you must indicate whether or not you wish to erase the
DOStIB created during link-edit. You receive the following message:
DMSVGN368R ERASE {CPISVSAM} DOSLIB? ••• ENTER YES OR NO:
CMSAPIS
Updating Considerations for CMS/DOS
CPIS/DOS has no ~ffect on the update procedures for DOS/VS, DOS/VS COBOL,
or DOS PL/I. You should follow the normal update procedure for applying
IBM-supplied coding changes to them.
Part 5. Updating VM/370
361
362
IBM VM/370 Planning and System Generation Guide
Updating RSCS
Updating RSCS
The same procedure used to update CP and CMS can be used to update RSCS.
However, unlike CP and CKS, RSCS can test the system that is built; it
does not need to test a duplicate copy of the system that is built.
Again, the KAINT virtual machine can be used to do the updating. You
should link to the RSCS virtual machine's 191 minidisk as your 195 and
access it as your A-disk.
The order of search for updating is:
195
194
190
A
R/i
B/A RIO
S
R/O
To build a new RSCS nucleus, you must create a
and generate a new RSCS nucleus.
new RSCS system disk
Creating an RSCS System Disk
Use the following procedure to create a new RSCS system disk:
1.
tog on as KAINT.
2.
IPt 190.
3.
tink to the mini disk that you want to contain the new RSCS nucleus
as lq5 in write status and access it as your A-disk.
4.
Issue the CMS FORKAT command to format that minidisk.
5.
Issue the eMS FOR~!T command with the RECOMP option to format the
same minidisk with one or two cylinders less than the total number
of cylinders on the disk (one less on a 3330 or 3350, two less on a
2314 or 3340).
The last cylinders are used for the RSCS nucleus.
6.
If you wish to change the RSCS configuration, re-create the
AXSLINKS, tAXLINES, and TAGQUEUE COpy files and create a new DKTLOC
macro library. See "Part 3. Generating VM/370 (CP, CMS, RSCS and
IPCS) .n
1.
Generate a new RSCS
following section.
nucleus using the
commands described
in the
Generating the RSCS Nucleus
1.
Load the RSCS files onto the CP system disk (the 194
belonging to KAINT) if they are not already there.
minidisk
2.
Access the KAINT 194 disk as an extension of the RSCS system disk.
access 194 b/a
Part 5. Updating VM/370
363
Updating RSCS
Noi~~
If you want to apply your own updates, they should be on the
294 disk. Then disk access should be:
access 294 b/a
access 194 cia
3.
Assemble the RSCS configuration table module, DMTSYS, using the
VMFASM EXEC procedure. The control file DMTRnO CNTRL identifies
DMTLOC as the macro library.
VMFASM DMTSYS DMTRnOl
If an error occurs due to an incorrectly coded macro, correct the
macro and restart by generating a new DMTLOC macro library.
Noi~~ If
you do not have enough
additional T-disk space.
4.
disk space to
assemble, acquire
Close and clear the punch and reader. Spool the punch to your
virtual card reader.
Use the VMFLOAD EXEC procedure to punch the
RSCS nucleus. The loadlist EXEC, DMTLOAD, contains the filenames
of all the RSCS TEXT modules.
close pun
close rdr
purge rdr all
purge pun all
spool pu n to *
vmfload dmtload DMTRnO
SYSTEM LOAD DECK COMPLETE
PUN FILE spoolid TO userid
5.
Copy the RSCS supervisor text decks, DMTAXS and DMTLAX,
MAINT 194 disk to your RSCS system disk.
from the
copyfile dmtaxs text b1 = = a1 (replace olddate
copyfile dmtlax text b1 = = a1 (replace olddate
6.
Copy the required line driver TEXT decks, DMTNPT
from the MAINT 194 disk to the RSCS system disk.
disk can now be released and detached.
copyfile dmtnpt text b1
copyfile dmtsml text b1
release 194
detach 194
DEV 194 DETACHED
7.
= = a1
= = a1
and/or DMTSML,
The MAINT 194
(replace olddate
(replace olddate
IPL your card reader which contains the RSCS nucleus A series of
prompting messages requests information relative to the physical
location and disk address of the RSCS nucleus.
Answer them as
shown.
ipl c
DMTINI406R SYSTEM DISK ADDRESS = 195
DMTINI407R REWRITE THE NUCLEUS ? yes
DMTINI409R NUCLEUS CYL ADDRESS = 003 (for 2314 or 3340, or 004
for 3330 or 3350)
DMTINI410R ALSO IPL CYLINDER 0 ? yes
IDMTRnO may be DMTR40, DMTR50,
release leve 1.
364
DMTR60 and
so forth, depending
IBM VM/370 Planning and System Generation Guide
on the
Upda ting RSCS
The message
D~TAXS103E
FILE 'spoolid' REJECTED -- INVALID DESTINATION
ADDRESS
is issued. It indicates that the Rses nucleus file was purged from
the card reader.
8.
The message shown in line 1 of the following example indicates
completion of the writing of the Rses nucleus on the specified
disk. IPL the specified disk and start your RSCS operations as
described in the !M{31Q Remote ~EQolj~g £~mmunicatiQQ§ Subsystem
JRSeS) !!§er~§ Guig~.
DMTREXOOOI RSCS (VER n, LEV n, mm/dd/Yi) READY
ep
logoff
logon rscs
ipl 191
DMTREXOOOI RSCS (VER n, LEV n, mm/dd/yy) READY
start newyork
installation Rses operation
Not~~ If
you are logged on as ~AINT, you IPt 195, but if
logged on as RSeS, you IPt 191 to IPL the Rses system disk.
you are
Part 5. Updating VM/370
365
366
IBM VM/370 Planning and System Generation Guide
Upd. a ting IPCS
Updating I pes Modules
You can use the same procedures used to update VM/310 CP, CKS, or RSCS
modules to update IPCS modules. Since there is no nucleus associated
with the IPCS component, the procedure is simplified.
If you have the IPCS source files on MAINT's 394, and the PTFs and
update files on 294, then, to reassemble an IPCS module, you might have
the search order as
1q 1
A
294
394
,......BIA
,,.,....
390
S
R/W
RIO
,. .,
1)
",
Ja~'
RIO
you could then use the VMFASM EXEC to assemble the module, for example:
vmfasm dmmpro DMMRnO
To generate the new IPCS commands, you should use the LOAD and GENMOD
commands to generate the new command modules from updated text files on
MAINT's 191, and nonupdated text files from the 194. Once the new IPCS
module has been generated, copy it to the CMS S-disk (MAINT's 190). For
example, you issue the commands:
access 195 a
access 191 b/a
access 194 cia
The command names, and the CMS commands you need to issue to generate
them, are shown in Figure 39.
r
-------------------------------------------------------------,
I IPCS Command Name
I
CMS Commands to Generate
FROB
load dmmpro
genmod prob
DUMPSCAN
load dmmdsc
genmod dumpscan
VMFDUMP
load dmmedm
genmod vmfdump (to dmmext
genmod vmfdump2 (from dmmext
STAT
load dmmsta
genmod stat
SUMMARY
load dmmsum
genmod summary
L
Figure 39. IPCS Command Names
Part 5. Updating VM/310
361
368
IB~ V~/370
Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Updating Service Programs
Updating Service Programs
Service programs are CP modules that are not a part of the CP nucleus.
They may execute either standalone from a card reader (the real system
card reader or your virtual card reader)
or in some cases, as a C~S
command.
The service programs are:
•
•
•
•
•
DASD Dump/Restore (module D~KDDR)
Directory program (module DMKDIR)
Format/Allocate program (module DMKFMT)
IBCDASDI, the virtual disk initialization program (module 1BCDASD1)
NCPDUMP, the 3704/3705 dump program (module DMKRND)
If you apply a PTF to a service program, you may use the GENERATE
EXEC to create a new 1PLable copy of the service program that can be
loaded via IPL or the CMSGEND EXEC to create a
new CMS command module,
or both.
For example, the Directory program exists as the CP module DMKDIR.
To apply PTFs to the source file, you would use the VMFASK EXEC
procedure, as follows:
vmfasm dmkdir DMKRnO
where DMKRnO is
CNT BL) •
the
filename of
the control
file
(the filetype
is
The Directory program can be used in three ways: (1) as a standalone
program that you IPL from the real system card reader (2)
as a
standalone program that you can 1PL from virtual card reader, and (3) as
a CMS command, DIRECT.
To create a new
GENERATE EXEC:
standalone copy for loading by IPL,
you can use the
generate ipldeck
you are prompted to enter the name of the program with the message
ENTER THOSE DECKS TO BE GENERATED ( DDR , DIR I FMT I ALL )
you enter:
dir
Then the GENERATE EXEC prompts you
(where the deck will reside) :
to enter
the target
disk address
ENTER TARGET DISK ADDRESS.
If you want the program on the system disk, you respond
190
You must have this disk accessed as your read/write A-disk.
GENERATE EXEC is finished, it issues the message
When the
'IPL DIR A1' CREATED
Part 5. Updating VM/370
369
Updating Service Programs
Next, to generate
procedure:
the
CMS DIRECT
command,
use
the C!SGEND
EXEC
cmsgend direct
If you want to punch a real card deck, to keep available for
standalone operations in the machine room, you can punch the file IPL
DIR A1 (wit h the NOHEADER option), or use the GENERATE EXEC with the
SRVCPGM operand:
generate srvcpgm
While you issue the above command,
programs are punched onto cards.
all
Fiqure qO lists the services programs
procedures you can use for each.
r-
Program
Update
CP module
name (use
VMFASM to
update)
CMS command
name (use
CMSGEND to
Generate
of the
I
iDump/
IFormatl I
I
,Restore fDirectorYIAllocatet IBCDASDI
DDR
DMKD1R
DMKFMT
IBCDASDI
CMS dis k file I
I
I
(use GENERATEI
I
I
IPLDECK to I 1PL DDRi 1PL DIR IIPL FMT
crea tel
I
I
I
1PL
IBCDASDI
Figure 40. Updating Service Programs
370
I
I
INCPDUMP
I
I Dl'1KRND
I
I
I
I
I NCPDUl'1P
I
DIRECT
Standalone
I
j
card deck
I
I
(use GENERATEI 1PT.. DDF! 1PL DIR IIPL FMT
SRVCPGM to
!
I
I
pun ch)
!
I
service
and indicates the programs and
I DASD
DMKDDR
standalone
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Updating the Loader Program
Updating the Loader Program
The loader (DMKLDOOE) is a service program that loads a CP; eMS; or RSCS
nucleus, and produces a load map. The loader loads the object modules
(text files) supplied with it, resolves CCW addresses, and resolves
address constants.
If an overlay error occurs while the loader is executing,
larger virtual machine and reload the system.
define a
The loader is distributed with the following default I/O addresses:
Console=009
Printer=OOE
If there is no printer at address OOE, the load map is printed at the
first printer that causes an interrupt (not-ready to ready sequence).
Note: The loader does not support display mode consoles. If an IPL is
attempted, wait state code 'FFF' is entered if the printer address is
not OOE. To circumvent this occurrence, reconfigure the console to
printer-keyboard mode or use the following procedure to correct the
printer address.
You can override these addresses by placing a control card between
the last card of the loader and the first card of the text decks. The
format of the control card is:
Colu1!.ll
1
2-4
5
6-13
14
15-22
23-72
contents
12-2-9-multipunch (X'02')
DEV
blank
PRNT=cuu (cuu is the printer address)
blank or comma
TYPW=cuu(cuu is the console address)
blank
The other loader control statements are the same as the loader
control statements described with the CMS LOAD command in the VM/370 ~MS
Command ~nd KacrQ Reference.
The loader is self-relocating, that is, it is initially loaded at
address 2000 (hexadecimal); it then relocates itself at the top of
storage. (For example, if the size of the loader is 10K, and the real
storage size of the CPU is 512K, the loader occupies the area of storage
between 502K and 512K.)
As the loader needs free storage to perform its
operations, it extends downward through storage.
The object modules being loaded must not overlay either the loader or
any address between 0 and 100 (hexadecimal). The object modules are
loaded into storage in a positive direction (that is, upward through
storage). Before the loader actually loads an object module, it checks
that the module does not overlay the loader's free storage. If an object
module would overlay the loader, the loader terminates. You must close
the printer to get the load map printed.
The last line of the load map
indicates the overlay area, if there was one.
Part 5. Updating VM/370
371
.-
~
.... - .. -
-r----- ... t"'- ..........
• ,
• J'-'.
UJ
.LJ.''''''
U.L'I:.J--- VV.J'
Updating the Loader Program
If the loader terminates the operation, a wait condition is indicated
in the instruction counter.
If the instruction counter contains
X'gggggg', indicating an SVC wait state, the interruption code (the
third and fourth bytes of the supervisor old PSW) indicate the error
condition.
For a detailed explanation of the error conditions and
interruption codes, see VM/370 System Messages.
The Load Map
The load map (the output of the loader) indicates:
•
The size of each object module and
For example:
DMKMCH AT 00E68
•
the address where it
is loaded.
MODULE SIZE IS OOOCOO
The end of the resident nucleus with the message:
***
END OF VM/370 RESIDENT NUCLEUS
***
***
***
The CP modules that precede this message in the load map are not
pageable; the CP modules that follow this message are pageable.
•
When a
module
before
loaded
do not
Set Page Boundary (SPB) card has been inserted.
If an object
cannot fit on the same page as the object module(s) loaded
it, the loader inserts an SPB card to force the modules to be
at a page boundary. This procedure ensures that object modules
cross page boundaries.
•
Two external names may be listed as undefined on the load map. If
the virtual=real option is not specified, the external name DMKSLC is
listed as undefined.
If a 3704/3705 control program entry is not
defined in the system name table (via the NAMENCP macro), the
DMKRNTBL external name is undefined.
Generating a New Loader
The loader service program, in its executable form, has a filetype of
LOADER.
Whenever you assemble a new copy of DMKLDOOE, you must convert
the resulting text file to a loader file.
If there is a virtual punch
at address OOD and a virtual reader at address OOC, the procedure for
generating a new loader is:
372
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Updating the Loader Program
Update and assemble DMKLDOOE.
TEXT.
The output from this assembly is DMKLDOOE
Spool the punch continuously and punch a copy of the old loader.
spool OOd * cont
punch dmkldOOe loader (nob
Part 5. Updating V8/370
372.1
Aprl.l. 1,.
372.2
lYtJl
IBM VM/370 Planning and System Generation Guide
Updating the Loader Program
Punch a copy of the newly assembled loader, then close the punch. When
the punch is closed the two files (DMKLDOOE LOADER and DMKLDOOE TEXT)
are sent to your reader. The commands to punch the new loader text file
and close the punch file are:
punch dmkldOOe text (noh
spool ODd * nocont close
IPL your virtual reader to read the
LOADER) into your virtual machin e.
loader text file into your virtual
file.
old version of the loader {D~KLDOOE
Then the old loader reads the new
machine and creates the new loader
ipl OOc clear
When the IPL is complete, the message
DMKDSP450W CP ENTERED; DISABLED WAIT PSi
is issued.
X'404040'.
The
instruction
address in
the
disabled
wait
PSW
is
Close the punch to punch a copy of the new loader, which was created in
step 4. Also close the reader and printer.
close OOd
close OOc
close ODe
IPL eMS, access a read/write disk as your A-disk, and read the file you
punched in Step 5. Name this file DMKLDOOE LOADER; this replaces the
original DMKLDOOE LOADER file with the new one.
ipl cms
access 191 a
read dmkldOOe loader
!Qi~
Save a copy of the original D"KLDOOE
replace it with the updated loader.
LOADER
file before
Part 5. Updating VM/370
you
373
374
IBM VM/370 Planning and System Generation Guide
Apr i 1 1, 19 8 1
EXEC Procedures and Command Format
Summaries
The command formats, options, and operands for each of the updating EXEC
and command procedures are described next, in alphabetical order.
Part 5. Updating V8/370
375
page ot
GC~O-1~U1-1U
As updated
Apr1~
1,
1~81
by TNL GN25-0837
ASMGEND
ASMGEND
Use the ASMGEND EXEC procedure to build the system assembler and to
create the associated auxiliary directory. ASMGEND loads the text decks
for the assembler in the correct overlay structure and produces a load
map. The format of the ASMGEND com.and is:
r-----IL----____________________________________________________________
ASMGEND
~
Responses
The ASMGEND EXEC
messages:
procedure
displays the
following
status and
error
ENTER TARGET DISK MODE FOR ASSEMBLE MODULES
DEFAULTS TO S-DISK IF NONE ENTERED
You enter the mode letter of the disk containing the modules
referred to from the auxiliary directory. If you enter a mode
letter, ASMGEND uses that mode letter as the II targetmode" operand
of the GENDIRT command when it creates the auxiliary directory. If
you do not specify a mode letter, S is used.
ASMGEND XF GEND COMPLETE
This message indicates that the system assembler and its associated
auxiliary directory are generated successfully.
ASMGEND XF GEND FAILED
This message indicates that the
not loaded successfully.
system assembler text
ASMGEND creates an assem1::le module on the A-disk.
376
IBM VM/370 Planning and System Generation Guide
files were
April 1, 1981
CMSGEND
CMSGEND
Use the CMSGEND EXEC procedure to generate a new CMS module from a text
file and place the new eMS module on the A-disk.
The format of the CMSGEND EXEC command is:
r
I
I CMSGEND
I
I
I
I
I
fn
fn I
I
I
I
I
L
,
,
r
CTLCMS
CTLALL
NOCLEAR
MAP
NOINV
I
I
I
I
I
J
is the filename of the CMS module that is to be generated by
the CMSGEND EXEC.
Only one filename may be specified in the
CMSGEND command line.
The filenames that may be specified in the CMSGEND command are
any disk-resident CMS commands and service proqrams.
!Qig~
You can also use the CMSGEND EXEC to regenerate the
ASSEMBLE command when you move the CMS system disk.
When you
specify ASSEMBLE, CMSGEND prompts you to enter a disk mode
letter so it can refresh the assembler's auxiliary directory.
Use the ASMGEND EXEC procedure if you are updating the
assembler.
CTLCMS
displays each CMS command as it is executed in the CMSGEND
EXEC procedure. This is equivalent to the EXEC statement
&CONTROL CMS.
CTLALL
displays every executable
CMSGEND EXEC procedure.
statement &CONTROL ALL=
NOCLEAR
specifies that the CLEAR option
CMSGEND invokes the LOAD command.
is
not to
be issued
when
MAP
specifies that the NOMAP option is
CMSGEND invokes the GENMOD command.
not to
be issued
when
NOINV
issues the NOINV option when CMSGEND invokes the LOAD command;
this suppresses the displaying of invalid cards at the
terminal.
If the text deck was created with the VMFASM EXEC,
it may contain update listing information; these records are
displayed during the loading process unless you specify NOINV.
statement as it is executed in the
This is equivalent to the EXEC
CMSGEND keeps a list of the eMS disk-resident modules, the filenames of
the text files used to create them, and any special attributes required
to qenerate them. For example, the RELEASE command must be generated
Part 5. Updating VM/370
377
Ii p.L..L.L
I,
I :7 0
,
CMSGEND
with the ORIGIN TRANS and the SYSTEM options.
It is composed of the
text files DMSARE and DMSALU.
To generate a new RELEASE module, you
issue:
cmsgend release
you may receive messages such as the following:
***
CURRENT STATUS:
FILE ' RELEASE MODULE A2' EXISTS
FILE' RELEASE MODOLD A1' DOES NOT EXIST
***
LOADING:
INVALID CARD - X9999DMS -
DMSARE
DMSALU
RELUFD
(PTF description)
SD OOEOOO
SD OOE3B8
OOE3B8
S0R'!'FS'!'
00EE 25
END$RELU
OOEE48
***
RESULTS:
FILE' RELEASE MODULE A2' RENAMED TO ' RELEASE MODOLD A1'
, RELEASE MODULE A2' CREATED FROM TEXT DECK ( S ) DMSARE DMSALU
WITH ATTRIBUTES TRANS SYSTEM NOMAP
The CMSGEND EXEC procedure displays status and error messages.
***
CURRENT STATUS:
r
,
I 'fn MODULE A2' EXISTS
I
I 'fn MODULE A2' DOES NOT EXISTI
L
.J
r
,
I'fn MODOLD A1' EXISTS
I
I 'fn MODOLD A1' DOES NOT EXISTI
L
.J
This message indicates whether a generated module already exists.
***
LOADING:
This message indicates that CMSGEND is loading the text decks.
***
***
(UNDEF. NAMES NORMAL FOR EDINIT)
NOW WE HAVE A SECOND PASS FOR EDINIT MODULE.
These messages indicate that the EDIT command
to resolve undefined names.
378
IBM VM/370 Planning and System Generation Guide
requires two passes
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
CflSGEND
***
RESULTS:
['fn MODOLD A1' WAS ERASED]
('fn MODULE A2' RENAMED TO 'fn MODOLD A1']
'fn MODULE A2' CREATED FROM TEXT DECK(S) •••
WITH ATTRIBUTES •••
These messages indicate which existing modules were erased and
renamed, which text files were used to create the new module, and
the attributes used to create the module.
ENTER GENDIRT TARGET DISK MODE LETTER
( NULL LINE DEFAULTS TO'S' DISK)
This message is issued when you specify ASSEfiBLE. You should enter
the mode letter of the disk that contains the system assembler.
This letter is used as the target disk mode address for the GENDIRT
command.
ERROR OCCURRED. CMSGEND STOPS.
This message indicates
terminated.
that an error occurred and
that CMSGEND is
INVALID ARGUMENT fn
This message indicates an
command line.
invalid filename
was specified
on the
Note: Text files must have a filetype of TEXT.
For example, after you
have updated an object module using VMFASM, the most recent object file
has a filetype such as TXTLOCAL. To use that text file here, you must
rename it to a filetype of TEXT. If there is currently a text file on
the system disk, you may want to rename it too, so that your updated
text file (which may reside on another disk) is the one that is loaded.
Part 5. Updating VK/370
379
~age
OI GCLU-ltlUl-l0
As Updated April 1, 1981 by TNL GN25-0837
GENERATE
GENERATE
GENERATE is a multipurpose EXEC used to generate VK/370.
use it to perform updating and maintenance of
•
•
You may also
CP, eMS, and RSCS
VM/370 service programs
You may also use it to regenerate your VK/370 operand after updating
•
•
•
•
•
The
The
The
The
The
directory
real I/O configuration (DHKRIO)
system control file (DHKSYS)
forms control buffer load (DKKFCB)
system name table (DHKSNT)
Instructions for coding the control statements and macros that define
your VM/370 directory, and DHKRIO, DMKSYS, and DKKSNT files are in "Part
2. De[iniug Your VM/370 ~ystem." Instructions for coding a new DKKFCB
module are in the VHlJ70 ~ystem programmer-s Guid~.
The GENERATE EXEC procedure assumes the following:
Virtual
Virtual
virtual
virtual
Virtual
RSCS/IPCS tape address = 181
CP nucleus tape address = 182
address of CMS build area = 190
address of CP and RSCS build area = 194
card reader = OOC
The format of the GENERATE EXEC command is:
r-------------------------------------------------------------------------~
GENERATE
VM370
DIRECT (ONLY]
DMKRIO [ONL I]
DMKSYS [ONL I]
DMKFCB [ONLY]
DMKSNT [ONLI]
IPLDECK
SRVCPGM
r
,
ICP I NUCLEUS [NOLOAD]
ICMSI
L
.J
FSCS [BUILD]
VM370
builds a new VM/370 directory, assembles DMKRIO and DKKSIS
(also assembles DMKFCB and DMKSNT, if they are supplied),
writes the CP nucleus to tape and optionally loads it.
You must have the appropriate files in your virtual
reader at address OOC.
place the following in your
reader, in the order shown:
: READ fn DIRECT
{Directory program control
:READ DMKRIO ASSEMBLE
380
statement~
IBM VM/370 Planning and System Generation Guide
card
card
GENERATE
(real I/O configuration macros)
:READ DMKSYS ASSEMBLE
(CP system control macros)
where fn is the filename of your VM/370 directory.
GENERATE
prompts you for the filename of your directory. OptionallYr
you can place new versions of DMKFCB and/or DMKSNT in your
card reader following the DMKSYS macros:
:READ DMKFCB ASSEMBLE
(forms control buffer load macros)
:READ DMKSNT ASSEMBLE
(system name table macros)
GENERATE reads the files in the reader. It invokes the
Directory program to build the VM/370 directory and invokes
the VMFASM EXEC procedure to assemble all the ASSEMBLE files
in the reader. VMFASM is invoked with the current IBM-supplied
control file to ensure that the proper macro libraries are
available when the modules are assembled and to assign the
correct filetype. Then, GENERATE invokes the VMFLOAD EXEC
procedure to place all the CP object modules on tape in the
correct order.
If an error is detected during any of these
processing steps, GENERATE terminates at the end of that step.
For a CP nucleus without a virtual=real area,
GENERATE
loads the tape, thus loading the newly generated CP nucleus.
For a CP nucleus with a virtual=real area, GENERATE writes the
nucleus to tape and exits. You are instructed to shutdown the
system. Then you can IPL the tape on a real machine or on a
virtual machine
that has enough virtual
storage.
The
"Specifying a Virtual=Real Machine" section of Part 1 tells
you how much virtual storage you need.
DIRECT (ONLY]
builds a new VM/370 directory.
If you do not specify ONLY, GENERATE executes exactly
you specified GENERATE VM370.
as if
If you specify ONLY, only the VM/370 directory is built. You
must place the Directory program control statements in your
virtual card reader at address OOC, as follows:
:READ fn DIRECT
(Directory program control statements)
where fn is the filename of your VM/370 directory.
prompts you for the filename of your directory file.
DMKRIO (ONLY]
assembles the real I/O configuration file
VMFASM.
(DMKRIO)
GENERATE
by invoking
If you do not specify ONLY, the GENERATE EXEC procedure
executes just as if you specified GENERATE VM370 (except that
it does not build a new VM/370 directory). Consequently, you
should follow the directions for issuing GENERATE VM370,
except do not place the Directory program control statement
(nor the corresponding :READ statement) in your card reader.
If you do
specify ONLY, only the DMKRIO
module is assembled.
Part 5. Updating VM/370
381
GENERATE
You must place the real I/O configuration
virtual card reader at OOC, as follows:
macros in
your
:READ DMKRIO ASSEMBLE
(real I/O configuration macros)
DMKSYS [ONLY]
assembles
VMFASM.
the CP
system control
file
(DMKSYS)
by
invoking
If you do not specify ONLY, the GENERATE EXEC procedure
executes just as if you specified GENERATE VM370 (except that
it does not build a new VM/370 directory and does not assemble
a new DMKRIO). Consequently, you should follow the directions
for issuing GENERATE VM370, except do not place the Directory
program control statements or real I/O configuration macros
(nor their corresponding :READ statements)
in your card
reader.
If you do specify ONLY, only the DMKSYS module is assembled.
You must place the CP system control macros in your virtual
card reader at OOC, as follows:
:READ DMKSYS ASSEMBLE
(CP system control macros)
DMKS NT [ONLY]
assembles the system name table (DMKSNT) by invoking VMFASM.
If you do not specify ONLY, the GENERATE EXEC procedure goes
on to invoke'the VMFLOAD EXEC procedure to place all the CP
object modules on tape. If no error occurs, and if the CP
nucleus does not have a virtual=real area, GENERATE then loads
the tape, thus loading the CP nucleus (with the new version of
DMKSNT) •
If you do specify ONLY, the DMKSNT module is assembled, but
the CP nucleus is not written to tape and is not loaded.
To assemble DMKSNT, you
macros in your virtual
follows:
must place the system name table
card reader, at address OOC, as
:READ DMKSNT ASSEMBLE
(system name table macros)
DMKFCB [ONLY]
assembles the forms
VMF ASM.
control buffer load (DMKFCB)
by invoking
If you do not specify ONLY, the GENERATE EXEC procedure
executes just as if you specified GENERATE VM370
(except it
does not build a new VM/370 directory and does not assemble
new DMKRIO or DMKSYS modules. Consequently, you should follow
the directions for issuing GENERATE VM370; except do not place
the Directory control statements, real I/O configuration
macros, or CP system control macros (nor their corresponding
:READ statements) in your card reader.
382
IBM VM/370 Planning and System Generation Guide
GENERATE
If you want to add or replace the IBM supplied FCB image, you
must place your FCB macro in the IBM supplied DMKFCB assemble
file; after label DMKFCBLD.
If you specify ONLY, only the DMKFCB module is assembled. You
must place the forms control buffer load macros in your
virtual card reader at OOC, as follows:
:READ DMKFCB ASSEMBLE
(forms control buffer load
macro~
IPLDECK
creates the standalone service programs on disk from their
associated object modules (text decks). These files must be
on the eMS system disk (S-disk).
You are prompted to enter
the names of the service programs you wish to generate. You
can respond ALL, DDE, DIE, or F~T_ If you respond ALL, the
DASD Dump Restore, Directory, and Format/Allocate standalone
programs are built on disk. ~
SRVCPGM
punches all the standalone service programs
DMKFMT, and IBCDASDI).
r
(DMKDIR, DMKDDR,
,
rCp I NUCLEUS [NOLOAD]
ICMS!
generates the CP
or CMS nucleus.
If you
L
J
NUCLEUS, the CP nucleus is loaded onto tape.
specify
CP
For a CP nucleus without a virtual=real area, GENERATE loads
the tape, thus loading the newly generated CP nucleus. For a
CP nucleus with a virtual=real area, GENERATE writes the
nucleus to tape and exits. You are instructed to shutdown the
system. Then you can IPL the tape on a real machine or on a
virtual machine
that has enough virtual
storage.
The
"Specifying a Virtual=Real Machine" section of Part 1 tells
you how much virtual storage you need.
Attached Processor support will be included in the nucleus, if
desired.
If you specify CP NUCLEUS NOLOAD, the tape is
created with the new nucleus but the disk is not loaded.
If you specify CMS NUCLEUS, a card-image deck is created and
placed ~n the virtual card
reader.
GENERATE issues a
prompting message to see if you want a card-image copy of the
CMS nucleus put on disk. If you respond "yes," GENERATE
writes a copy of the CMS nucleus on disk, and loads the
nucleus. The card-image copy of the CMS nucleus is a file
(CMSNUC NUCLEUS) that can later be loaded to create a CMS
nucleus. If you specify CMS NUCLEUS NOLOAD, the new nucleus
remains in the virtual card reader.
RSCS [BUILD]
Prepares the RSCS build area
nucleus, as
described in
Installing RSCS."
and, optionally, builds the RSCS
the section
"Generating and
The GENERATE EXEC procedure issues many descriptive responses, most of
which are shown in the system generation procedures in Part 3.
Generating VM/370 (CP, CMS, RSCS, and IPCS).
Part 5. Updating VM/370
383
Vl'IFASl'I
VMFASM
Use the Vl'IFASM EXEC procedure to update a specified source file
according to entries in a control file, and to assemble the updated
source file. VMFASM invokes the Cl'IS UPDATE command. The format of the
Vl'IF~SM command is:
r
I VMFASl'I
I
I
fn ct lfile ( (options ••• ( ) ]]
,
Q£iion.§:
r
,
r
,
r
,
,DISK I ITERM I ILI~! I
IREI!! I IBQTERl'I1 INOLISTI
I
I
I
I
I
L
r
,DECK
1
L
J
,
I I RENT
'wnn~r~'
• .:..:..;:...:::...::..;..:..; l
L
J
L
J
r
J
,
, (EXP] (XREF]
'wn~~w~1
• ~~~.
L
J
L
fn
is the filename of the source file
have a filetype of ASSEMBLE.
ctlfile
is the filename of the control file.
have a filetype of eNTRL.
to be upda ted.
The control
It must
file must
Vl'IFASM only accepts the nondefaulted options.
All
assembler options entered are ignored and the defaults are used.
Q~iion'§l
DISK
other
places the listing file on a virtual disk.
writes the listing file to the printer.
TERM
writes the diagnostic information on the SYSTERM data set. The
diagnostic information consists of the diagnosed statement
followed by the error message issued.
NOIERM
suppresses the TERM option.
l!I~!
produces an assembler listing.
NOLIST
does not produce an assembler listing.
DECK
writes an object module on the device specified on the FILEDEF
statement for PUNCH.
!Q:QECK
suppresses the DECK option.
RENT
checks the program for a possible violation of program
reenterability. Code that makes the program nonreenterable is
identified by an error message.
suppresses the RENT option.
EXP
384
expands printing of certain macros which check for the SUP
parameter issued via the SYSPARM option of the ASSEl'IBLE
command. The default is SUP.
IBM Vl'I/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
VMFASM
XREF
causes the XREF(FULL) option to be invoked when VMFASM invokes
the assembler. The default for VMFASM is XREF(SHORT) •
The steps taken by the VMFASM EXEC are summarized below.
1.
The VMFASM EXEC calls the
PRINT options.
UPDATE command
with the CTL,
STK, and
UPDATE uses the control file (ctlfile CNTRL) to update
assembler language source file.
The ne w file is named
ASSEMBLE.
UPDATE stacks information from the
stack, and prints the update log file.
in the
file
the
$fn
console
2.
Using the library list from the MACS record in the
VMFASM issues a GLOBAL MACLIB command.
control file,
3.
The" updated source file, $fn ASSEMBLE, is
options indicated on the VMFASM command line.
4.
The output text deck from the assembly, $fn TEXT, is concatenated
with the UPDATES file so that the text deck contains a history of
update activity.
5.
Using the update level identifier from the control file (the
identifier of the most recent update that was found and applied is
stacked by the UPDATE command), VMFASM determines how to rename $fn
TEXT.
assembled using
the
If the update level identifier is TEXT, the text deck is renamed fn
TEXT.
If the update level identifier is anything other than TEXT, the
text deck is renamed fn TXTxxxxx, where xxxxx is the one- to
five-character update level identifier and fn TEXT is erased from
the A-disk.
6.
Temporary
erased.
files ($fn
ASSEMBLE, fn
UPDATES, and
fn ctlfile)
are
The input and output files used by VMFASM are summarized below.
fn ASSEMBLE
ctlfile CNTRL
Assembler Language source
control file
MACLIBS, auxiliary
update files.
control files
(AUXxxxxx),
and
miscellaneous
DI SK OUTPU1 FILE.a.l
fn {TEXT
}
TXTxxxxx
object deck, named according to
the update level identifier in the
control file
This file also contains data from the UPDATES
date and time information.
file, together with
Part 5. Updating VM/370
385
VMFASM
$fn LISTING
Assembler listing (if
PRINT option is in effect)
This file also contains data from the update log file (fn UPDLOG),
describing the updates applied to the source file.
Note: If the object modules created have a filetype of "TXTxxxx" and are
to be used with one of the GEN EXECs (CMSGEND, DOSGEN, VSAMGEN, etc.),
they must be renamed with a filetype of "TEXT".
The UPDATE command issues the message DMSUPD178I to indicate each of the
update files being applied.
ASMBLING fn
indicates that the assembly is going to begin. If you specified
any assembler option on the VMFASM command line, the options used
are also displayed.
fn {TEXT
} CREATED
TXTxxxxx
indicates the filename and filetype of the text deck.
***
fn ASSEMBLE NOT FOUND ***
The source file could not be located.
***
ctlfile CNTRL NOT FOUND ***
The control file could not be located.
***
ERROR UPDATING fn ***
An error occurred during UPDATE command processing.
***
ERROR ASMBLING fn ***
An assembler error occurred.
***
NO TEXT FOR'fn ***
No TEXT file was produced, because of assembler errors.
386
IBM VM/370 Planning and System Generation Guide
VMFLOAD
VMFLOAD
Use the VMFLOAD EXEC procedure to generate a new CP, CMS, or RSCS
nucleus. The VMFLOAD program uses two files,
a loadlist EXEC file and a
control file, to produce a punch file that has several object modules.
VMFLOAD requires a virtual machine with 320K.
The format of the VMFLOAD command is:
r
I VMFLOAD I loadlist ctlfile
L
loadlist
is the filename of an EXEC file that contains the names of
object modules in the order in which they are to reside in the
complete load file for the nucleus. For example:
&CONTROL OFF
&1 &2 fn [ft]
& 1 &2 fn [ft]
where fn and optionally ft, are the filename and filetype of
an object module to be punched.
The object modules are
punched in the order specified, beginning at the.top of the
loadlist EXEC. If a filetype is specified, VMFLOAD searches
for that specific file, and, if it finds it, punches it
without a header card.
If the file type is not specified in the loadlist, VMFLOAD uses
the control file to determine which object module is the
~ighest level
object module available. VMFLOAD searches the
control file from
top to bottom.
When
it finds the
appropriate object module, VMFLOAD punches it.
ctlfile
is the filename of the control file. This is usually the same
control file used to apply updates to modules via the V!FAS!
or UPDATE commands. This file identifies the highest level
object module available, if the filetype is not specified in
the loadlist.
1.
Before the the files specified in the loadlist are punched, VMFLOAD
issues a SPOOL PCH CONT command to ensure that the punched files
appear as one deck. You may wish to specify SPOOL PCH TO userid
before you invoke VMFLOAD to transfer the punched output as a file
to your own (or another) virtual machine as a reader file. If you
want to perform any additional controls, you should write an EXEC
procedure to perform the control and invoke VMFlOAD from that EXEC
procedure.
2.
For each entry in the loadlist that does not specify a filetype
VMFlOAD searches the control file to determine the filetype of the
object module.
Part 5. Updating VM/370
387
VMFLOAD
The filetypes are based on the update level identifiers in the
control file.
These are the identifiers used by the VMFASM to
assign filetypes to object decks. Remember that updates applied to
source files are applied from the bottom of the file towards the
top. Therefore,
VMPLOAD searches the control file from the top
towards the bottom to locate the most recent update level.
For example,
if a control file contains
file, you would issue:
the records
and control
TEXT MACS DMKMAC
LOCAL FIXl
SPEC AUX 11 1 1
PTF
R12765DK
IBMl
AUXRnO
Then for each entry in the loadlist, the VMFLOAD search order is:
•
fn TXTLOCAL
•
fn 'f'X'f'51'EC
•
fn TXTIBM 1
As soon as VMFLOAD locates a file, it punches it,
then continues
processing the next entry in the loadlist. If none of the above
filetypes exist for the loadlist entry, VMFLOAD searches for
filename TEXT.
If there is no TEXT file,
VMFLOAD displays a
message and continues processing with the next entry in the
loadlist.
Noi~ VMFLOAD ignores records that
have an update level identifier
of PTF, and so searches for the next lowest level identifier when
determining the filetypes of object modules to punch.
3.
When all
commands
the
object
modules are
punched,
issues
VMFLOAD
the
SPOOL PUNCH NOCONT
CLOSE PUNCH
If you issued the command
spool punch to
*
prior to invoking VMFLOAD,
your virtual card reader.
the completed load
deck is
placed in
loadlist EXEC
contains the filenames, and optionally filetypes,
of the object modules to be punched.
DMKLDOOE LOADER
the loader, which
loadlist EXEC
should be the 1st
entry in the
object modules with filetypes of TEXT or TXTxxxxx,
where xxxxx is
the update level identifier in a control file, used by VMFASM to
name the object module.
load deck
38R
punched to your virtual machine
IBM V"/370 Planning and System Generation Guide
VMFLOAD
1.
The distributed system uses the following loadlists:
Lo.sdlist
APLOAD
APVRLOAD
CPLOAD EXEC
VRLOAD EXEC
CMSLO AD EXEC
DMTLOAD EXEC
For example,
loadlist
Us.ag~
CP nucleus without V=R for the attached processor
CP nucleus with V=R for the attached processor
CP nucleus without V=R for uniprocessor
CP nucleus with V=R for uniprocessor
CMS nucleus
RSCS nucleus
to punch
a
new
CP
nucleus with
the
distributed
vmfload cpload DKKRnO
The GENERATE EXEC and the VMSERV
new CP nucleus.
2.
EXEC uses VMFLOAD to
generate a
After you have punched a new nucleus with VMFLOAD, you can either
move the nucleus to tape, using the MOVEFILE command, or, if the
nucleus is in your virtual card reader, you can IPL it:
ipl OOc
When you IPL the virtual card reader, the loade r is read first, and
it loads the rest of the object modules.
If the loader is
successful, the nucleus is written on disk, and the load map is
spooled to the virtual printer.
If you want to preserve a disk
copy of the load map, you should spool your printer to your virtual
card reader, then read the file onto disk.
SYSTEM LOAD DECK COMPLETE
This message is displayed
punched.
when all the files in the
loadlist have been
INSUFFICIENT OR INVALID ARGUMENTS
The command line was incorrectly entered.
NO CONT ROL FIL E
The control file could not be located.
ERROR IN CONTROL FILE
The control file contains an invalid record.
NO LOAD LIST
The loadlist could not be located.
ERROR IN LOAD LIST
The loadlist contains an invalid record.
fn ft NOT FOUN D
No text file was found.
ERROR ON PUNCH
An error occurred punching a file.
Part 5. Updating V8/370
389
VMFLOAD
CP LOADLIST REQUIREMENTS
The CPLOAD loadlist EXEC contains a list of CP modules that is used by
the VMFLOAD procedures to punch the text decks for the CP system. All
modules following DMKCPE in the list are pageable CP modules. Each 4K
page in this area may contain one or more modules. Pageable modules must
not span the 4K page boundaries. The module grouping is governed by SPB
(Set Page Boundary) cards. An SPBcard is a loader control card that
forces the loader to start this module at the next higher 4K boundary.
If more than one module is to be contained in a 4K page, only the first
is preceded by an SPB card.
The loader inserts SPB cards automatically where they are needed; you
need not insert SPB cards.
The position of two modules in the loadlist is critical. All modules
following DMKCPE must
be reenter able and must not contain any address
constants referring to anything in the pageable CP area. DKKCKP must be
the l~st ~0~Ql~ in th~ loa~list.
390
IBM VM/370 Planning and System Generation Guide
VMFMAC
VMFMAC
Use the VMFMAC EXEC procedure to update macro libraries. It invokes the
CMS UPDATE command to update specified copy or macro files, according to
entries in a control file, and then builds a new macro library from the
resulting new versions of those files.
The format of the VMFMAC command is:
r
,VMFMAC
,libname ctlfile
L
libname
is the filename of the macro library to be updated, and of the
EXEC file that contains the names of the library members. The
entries in libname EXEC must be in the following format:
&1 &2 fn1
&1 &2 fn2
where fnl, fn2, and so on, are filenames of macro or copy
files to be updated and included in the macro librarYr which
must have a filetype of MACLIB.
ctlfile
is the filename of a control file to be used to apply the
updates. The filetype must be CNTRL. The filenames used by
VM/370 are DMKRnO, DMSRnO, DMSMnO, DMTRnO, and DMMRnO.
The steps taken by VMFMAC are summarized below.
1.
VMFMAC locates libname EXEC and the control file.
It also erases
any _existing files named NEWMAC MACLIB and NEWMAC COPY.
Then
VMFMAC begins reading the macro or copy filenames from the EXEC,
beginning at the bottom.
2.
For each entry in the libname EXEC, VMFMAC:
Invokes the UPDATE command with the CTL
updates specified in the control file.
option to
Adds the updated macro or copy file ($filename
$filename COPY) to the macro library NEWMAC MACLIB.
!dds the UPDATES file created by
NEWMAC COPY.
apply the
MACRO
or
the UPDATE command to the file
Erases $filename MACRO or $filename COPY, and filename UPDATES.
3.
If there are no update files for a macro or copy file specified in
libname EXEC, the macro or copy file is added to NEWMAC ftACLIB in
its current form. NEWMAC COPY, containing a history of updates
applied by VMFMAC, is added to NEWMAC MACLIB.
Part 5. Updating VM/370
391
4. If no errors occur during the procedure, then when all the macros
have been added to NEWMAC MACLIB, NEW MAC MACLIB is renamed libname
MACLIB.
libname MACLIB, if it exists, is erased.
If errors occur during the VMFMAC EXEC procedure (for example, if a
MACRO or a COpy file is not found) libname MACLIB is not erased,
and the updated macro library retains the name NEWMAC MACLIB.
libname EXEC
contains a list of macro a copy file to be updated
and/or included in libname MACLIB.
ct1fi1e CNTRL
is the control file used by the UPDATE command.
MACRO and COpy files to be updated and/or included in the macro
plus miscellaneous auxiliary control files and update
library,
files.
libname MACLIB
is the updated macro library.
1ibname COpy
contains the UPDATES files
command processing.
produced
The printer is spooled with the CONT option, so that
completes, the printer file contains:
1.
by
when VMFMAC
•
A copy of the control files
•
For each updated macro or copy
produced by the UPDATE command.
•
A copy of each macro or copy file is the macro library
•
The libname COpy file, which contains the
files created by the UPDATE command.
file,
UPDATE
the update
log
file
accumulated UPDATES
When files with MACRO
fi1etypes are added to a MACLIB,
the
membername is taken from macro prototype statement.
When files
with COpy fi1etypes are added to a MACLIB, the membername is taken
from the filename of the COpy file,
(which will be $fi1ename if
updates were found, otherwise filename)
unless you include a *COPY
statement as the first record in the file, in the format:
*COPY membername
Then, the MACLIB directory uses membername to name the copy file.
2.
392
If errors occur during VMFMAC processing, consult the 1ibname COpy
file printed by VMFMAC.
If you can correct the errors involving
one or two macro or copy files, you can add these members to NEWMAC
MACLIB using the MACLIB command, then rename NEWMAC MACLIB to
1ibname MACLIB after erasing the current libname MACLIB.
IBM VM/370 Planning and System Generation Guide
VMFMAC
The UPDATE command issues the message DMSUPD178I to inform you of the
updates being applied to each macro or copy file. If no updates are
found, message DMSUPD181E is issued.
fname {COpy -} ADDED.
MACRO
indicates that the
the macro library.
specified macro or copy file has
libname COpy ADDED.
indicates that libname COPY, containing
MACLIB, has been added.
***
TYPE 'VMFMAC LIBNAME CTL'
libname EXEC NOT FOUND
VMFMAC could
library.
***
the update history, of the
***
This message indicates
operands.
***
been added to
that the
command
line did
not have
two
***
not locate
ctlfile CNTRL NOT FOUND
the EXEC file
associated with
the macro
***
VMFMAC could not locate the control file.
***
fn COpy or MACRO NOT FOUND
***
A library member named in libname EXEC could not be located.
***
ERRORS UPDATING fn {COpy } ***
COpy }
MACRO
{
fnameMACRO
NOT INCLUDED IN MACLIB
This message indicates an UPDATE command error occurred
member, and the file was not written into the MACLIB.
for the
DUE TO PREVIOUS ERRORS, THE RESULT OF THIS MACLIB BUILD
IS CALLED 'NEWMAC MACLIB', libname MACLIB HAS
NOT BEEN REPLACED
One or more errors were encountered,
create the MACLIB yourself.
and you must correct them and
Part 5. Updating VM/370
393
VMSERV
VMSERV
VMSEEV is an EXEC procedure that is included on the System Program
Update Tape (PUT)
to assist you in the application of IBM service
updates to the VM/370 system.
VMSERV directs the installation of
maintenance and service updates to the components and program products
that form your system.
It is recommended that VMSERV be allowed to
apply service sequentially.
The individual service EXECs contained on
the PUT are designed to apply service in the prescribed order.
The format of the VMSERV EXEC command is:
,
r
I
-------------------------------------------------------,I
Ir
,r,r,r,
I
I VMSERV I IRESTART (PROGID] I ISIPOE I I NOIPLI INOMEMO I
I IBUILD
(PROGID] I INORESPI IEXIT I ISIPOMEMI
I
I L
J
L
J
L
J
L
J
I
I
I
(COM P ]
I
f
I
I
,
L
RESTART
returns control to VMSERV after an IPL of a nucleus
other event that causes V"SERV not to regain control.
BUILD
creates a new nucleus. This option assumes you
all service from the system PUT.
PROGID
specifies the program number of the product you are servicing.
SIPOE
suppresses prompting messages related to specific
applications and staging area disk addresses.
NORESP
suppresses prompting messages' for staging area disk addresses.
You will receive prompts to offer service to each component
and any applicable program products.
NOIPL
loads the service from the system PUT but does not create and
(IPL) a nucleus for any component that is serviced.
Because
'"SERV does not normally lose control with this option, all of
the service on the PUT is loaded at one time. You may then
BUILD the desired nucleus after applying corrective PTF's or
any user modifications.
EXIT
installs service sequentially up to the point where a nucleus
would be created and loaded via IPL. 'MSERV exits at this
point.
NOMEMO
suppresses printing of the Memo-to-Users.
SIPOMEM
prints the SIPO/E user memos.
COMP
specifies the component that is intended to receive service.
If BUILD is also specified, COMP is the nucleus of the
component that you are building. The default is CPa
You can
also specify CMS, IPCS, or RSCS.
394
IBM VM/370 Planning and System Generation Guide
or any
have loaded
service
VMSERV
1.
PROGID is a positional parameter which is valid only if you specify
RESTART or BUILD.
2.
The parameters
that are
separated vertically
are mutually
exclusive.
They cannot be specified at the same time.
For
example, specifying BUILD and NOIPL is not allowed.
3.
If you are using SIPO
(System Installation Productivity Option),
refer to the VM System IPO Extended Planning Guide, Order No.
GC20-1874.
HOW VMSERV WORKS
The PUT is composed of two or more virtual tapes stacked sequentially.
Each virtual tape contains the service for ~~ product. The first
virtual tape on the PUT contains the service for the VM/370 System
Control Program
(SCP). The VMSERV EXEC is included in file one along
with the SCP service installation EXEC (5749010) and the program level
file.
Assuming you need a new map of the PUT, certain housekeeping
functions are performed.
VMSERV erases work EXECS PTFLVL and PTFMEMO,
and issues a CP REWIND and VMFPLC2 FSF in an attempt to insure this is
the correct tape. VMSERV then initializes the EXECs necessary to print
the Memo-to-Users and user memos. The tape is rewound and VMFPLC2 looks
for space on an A-disk on which a TAPE MAP can be written.
A TAPE MAP
is created for files one and two.
Any selective-load EXECs that may
have remained from the last PUT are erased and the new service EXECs are
created.
A line of data is printed to the console to indicate where you
are in the procedure and the remaining virtual tapes are skipped.
VMSERV offers to print the PUT DOCUMENT and the Memo-to-Users, reminding
you to review the memos prior to installing service.
You are also
reminded of the NOIPL option of VMSERV, and since you probably have not
reviewed the memos at this point, VKSERV exits.
Specify RESTART to
apply service to this product. VMSERV invokes the service (progid) EXEC
with the applicable parameters that you entered when you invoked VMSERV.
After the service for all the desired products is installed, VKSERV
types the SERVICE DISKMAP to the console to show the service status of
all the products on the tape.
I INITIALIZATION MESSAGES
Several messages may be issued to you during the application of service.
The messages both normal and error that VMSERV issues are documented
here.
VKSERV MUST BE RUNNING FROM YOUR 'C' DISK.
PLEASE REVIEW
INSTALLATION INSTRUCTIONS CONTAINED IN THE PLC'S COVER LETTER.
THE
Return code: 4
Issued if the VKSERV EXEC is not running from the 'C' disk.
Part 5. Updating VM/370
395
VMSERV
OPTION CONFLICT EXISTS.
PLEASE RE-ENTER
Return code: 4
Issued for conflicting parameters issued on the command line: Such
as 'BUILD' and 'NOIPL'.
You should review the PUT DOCUMENT and
re-enter the command properly.
UNKNOWN OR INCOMPLETE OPTION SPECIFIED. PLEASE RE-ENTER
Return code:
4
You have invoked VMSERV with misspelled or
You must re-enter the command correctly.
incorrect parameters.
THE SECOND PARAMETER ENTERED MUST BE THE PROGRAM NUMBER AT WHICH
YOU WISH SERVICE INSTALLATION TO 'RESTART'. ENTER: VMSERV RESTART
prog
Return code:
4
You have requested a 'RESTART' but have not indicated which service
EXEC you wish to restart.
ENTER THE PROGRAM NUMBER YOU WISH TO BUILD OR 'EXIT'.
Return code:
none - no exit
You have requested 'BUILD' but specified no progid to invoke. You
should respond with the program number you wish to 'BUILD', or you
may enter 'EXIT' to terminate VMSERV.
progid EXEC NOT FOUND. RE-ENTER IF
IF YOU NEED TO RE-START.
Return code:
TYPING ERROR.
OR ENTER 'EXIT'
none - no exit
You have incorrectly specified the progid to 'BUILD'.
re-enter the progid or enter 'EXIT' to terminate VMSERV.
VMSERV WILL NOW MAP THE PUT.
Return code:
You
may
PROCESS WILL TAKE A FEW MINUTES
none - informational
Followed by the typing of the first line of the 'program level'
files as they are read from the PUT.
This file contains the
official name of that particular (program) product.
YOU SHOULD REVIEW THE KEMOS-TO-USERS PRIOR TO INSTALLING SERVICE
WOULD YOU LIKE THE 'MEMO (S)-TO-USERS' PRINTED? ( -YES- , NO )
Return code:
396
none - procedural question
IBM VM/370 Planning and System Generation Guide
VMSERV
Issued if the PUT was just mapped.
It may be the initial
invocation of VMSERV, or a 'RESTART' where no 'SERVICE DISKMAP'
file was found on the 'C' disk.
INSURE (VIA THE MEMO-TO-USERS) THAT NO CHANGES HAVE OCCURRED TO THE
MACROS AFFECTING DMKRIO, DMKSNT, and DMKSYS. IF THESE, OR ANY
MODULE(S) NEED TO BE RE-ASSEMBLED FOR MACRO OR OTHER CHANGES, OR IF
YOU WISH TO RECEIVE CONTROL AFTER THE MACLIBS AND OTHER SERVICE IS
LOADED, USE THE 'NOIPL' OPTION WHEN YOU RE-INVOKE VMSERV TO
INITIATE THE APPLICATION OF SERVICE.
THE MEMO-TO-USERS SHOULD BE REVIEWED PRIOR TO INSTALLING SERVICE
WHEN YOU HAVE REVIEWED THE MEMOS AND ARE READY TO APPLY SERVICE,
ENTER...
VMSERV NOMEMO (USE THE 'NOIPL' OPTION IF NECESSARY)
Return code:
0 - normal termination
Issued a fter the printing of the MEPIOs (if requested) to remind you
about the 'NOIPL' option and to let you know that VPISERV is about
to terminate and how you may restart.
SERVICE APPLICATION MESSAGES
YOU WILL BE
REQUIRED TO REPLY TO
QUESTIONS REGARDING THE
APPLICATION OF SERVICE. THE ACCEPTABLE RESPONSES WILL BE SHOWN IN
PARENTHESES.
A RESPONSE SHOWN WITHIN DASHES: -yes-, IS THE
DEFAULT, AND MAY BE SELECTED WITH A NULL RESPONSE.
Return code:
none - informational message
MOUNT THE VPI/370 SYSTEM PUT ON 181 AND RE-ISSUE VMSERV
Return code:
q
A 'CP REW 181' has resulted in
not attached.
Perhaps the
tape is is
THE TAPE ON YOUR VIRTUAL 181 IS NOT THE CORRECT TAPE.
VM/370 SYSTEM PUT ON 181 AND RE-ISSUE VMSERV
MOUNT THE
Return code:
an error.
q
The initial 'VMFPLC2' command has resulted
probably the wrong tape was mounted.
in
a
tape
error.
THIS SERVICE PROCEDURE NEEDS AN 'AI DISK TEMPORARILY ON WHICH TO
WRITE 2 SMALL FILES.
ENTER THE 'CUU' OF A DISK THAT MAY BE
ACCESSED BY THE PROCEDURE.
(-194- I CUU )
Return code:
none - procedural question
Enter an address of a minidisk to which you now have write access.
If there is a problem, the message will be reissued.
Part 5. Updating VM/370
397
V~SERV
***** *COREQ* *** *COREQ* *** *COREQ* *** *COREQ* *****
Return code:
none - informational
Issued if the service about to be installed has indicated that a
corequisite condition should be indicated to you.
Normally, the
~emo-to-Users
will detail exactly what corequisite conditions
exist.
DO YOU WISH TO CONTINUE APPLYING SERVICE? ( -YES- 1 NO )
Return code:
none - procedural question
Issued at the end of the application of service for the product
requested by 'RESTART'. If you respond 'YES' (the default), the
'RESTART' indicator is turned off, and the application of service
continues as if 'RESTART' was never specified.
Return code:
0 - Normal termination
A 'NO' response will cause
V~SERV
to terminate.
progid HAD TROUBLE.
YOU ftUST RESTART VftSERV
FINISHED WITH THE INSTALLATION OF SERVICE.
YOU ARE
NOT
Return code: 16 - error, tape position unknown
Issued when a service EXEC (progid) returns with a return code of
16 and 'EXIT' was not specified.
This indicated the position of
the tape is unknown and VftSERV must be restarted. Other errors may
have been indicated to you such as a tape error or disk full
condition.
, RETURN CODES FROft SERVICE EXECS
o
Service complete.
4
Service loaded. System PUT is no longer required for any activity.
a 'BUILD' may be required, depending on the product's packaging.
8
Service aborted. Some (or no) service was loaded from the tape. A
'RESTART' is required to apply service. The position of the tape
is known and correct.
12
Unknown error. Unexpected error occurred. A 'RESTART' will have
to be done. Service status and tape position are unknown.
16
SIPOE EXIT. The service EXEC proceeded to the point that a nucleus
coy1d have been created and then terminated. VftSERV will then EXIT
(with a return code of 0).
XX
Unknown. This is any unexpected return code from a service exec.
Since the return code would have been '12' if the tape position was
unknown, service installation will proceed.
3QS
All load and 'BUILD' functions accomplished
IBM VM/370 Planning and System Generation Guide
Appendixes
A.
Program Products, Installed
Programs, and Emulators
B.
Configuration Aid
c.
CP/CMS
D.
Compatible Devices
E.
Compatibility of VM/370 with CP-67/CKS
F.
VM/370 Restrictions
G.
A Sample EXEC Procedure for
MACLIB
Nucleus,~odule/Segment
User Programs,
Field Developed
Regeneration
Copying DOS/iS Macros into a eMS
Appendixes
399
400
IBM VM/370 Planning and System Generation Guide
April 1, 1981
Appendix A. Program Products, Installed User
Programs, Field Developed Programs, and
Emulators
VM/370 Assembler
i!/310 Assembler is distributed as a part of the i"/310 system and is
required for installation and further support of the system.
111
necessary installation and support macros are provided in C8S libraries.
The conversational
"onitor System (eMSj, the
Remote Spooling
Communications Subsystem (RSCS), the Control Program (CP), and the
Interactive problem Control System (IPCS) are components of i"/370 and
are distributed with it.
Certain other facilities mentioned in this
publication are not part of V"/310, but can be separately ordered from
IB". These include: IB! System/360 and System/310 operating systems, IB!
language processors and other program products, IB! Installed User
Programs, and IBK Field Developed Programs. For more information,
contact your IB! representative.
Program Products
The following is a list of IBK program products and their respective
program numbers that VK/370 users have found useful. For installation
and storage information, consult the publications that support these
products.
DOS/VS Advanced Functions (Linkage Enha nceme nts)
5746-XE2
DOS PL/I Optimizing Compiler
5136-PL1
DOS PL/I Resident Library
5136-L!4
DOS PL/I Transient Library
5736-L!5
DOS PL/I Optimizing Compiler and Libraries
5736-PL3
DOS/iS COBOL Compiler and Library
5746-CB1
DOS/iS COBOL Object Library
5746-L84
OS Code and Go FORTRAN
5734-F01
OS FORTRAN IV (G1)
5134-F02
OS FORTRAN IV Library (Kod I)
5734-L81
OS FORTRAN Ii (ft) Extended
5134-F03
OS FORTRAN Library (Kod II)
5134-L83
FORTRAN Interactive Debug
5134-F05
as/iS COBOL Compiler and Library
5740-CB1
OS/iS COBOL Library Only
5140-L81
Appendix A. PPs, IUPs, FOPs & Emulators
401
OS Full American National Standard
COBOL Version 4 Compiler and Library
5734-CB2
OS Full American National Standard
COBOL Version 4 Library
5734-1.K2
OS COBOL Interactive Debug
5734-CB4
OS PL/I Optimizing Compiler
5734-PL1
OS PL/I Resident Library
5734-LK4
OS PL/I Transient Library
5734-L"5
OS PL/I Optimizing Compiler and Libraries
5734-PL3
OS PL/I Checkout Compiler
5734-PL2
VK Installation productivity Option
5750-A13
V~
402
BASIC Processor
5748-111
VS APL
5748-AP1
VM/pass-Through Facility
5748-RC1
Interactive Instructional System
5748-XX6
VM/370 Basic System Extensions
5748-XX8
VM/370 System Extensions
5748-XE1
VK/370 Remote spooling communications Subsystem
Networking
5748-XP 1
Data Languag~I Disk Operating System/Virtual
Storage (DL/I DOS/VS)
5746-XX1
VM/Interactive Problem Control System Extension
(VM/IPCS Extension)
5748-SA 1
Document Composition Facility (Script/VS)
5748-XX9
VM/System Product (VM/SP)
5664-167
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0831
Installed User Programs
The following is a list of the Installed User Programs (IUPS) and their
respective program numbers that VM/310 users have found useful. For
installation and storage information, consult the pUblications that
support these proqrams.
SCRIPT/310 Version 3
5196-PHL
McGill University System for Interactive
, Computing
5196-AJC
VS/REPACK
5194-PDZ
VM/310 System for Online Tape and
Disk Libraries
5194-AGN
VS/310 Graphics Monitor
5194-PDT
VM/SGP statistics Generating Package
5194-PDD
Assembler H/CMS Interface
5196-PEJ
APL Function Editor
5796-PGY
Display Editing System for CMS
5196-PJP
eMS EXEC Language Extensions
5196-FJA
FORTRAN Interactive Subroutine Library
5196-PHT
APL GPSS
5196-PJG
APL Data Interface
5196-PKA
APL statistical Library
5796-PHW
APL Econometric Planning Language
5196-PDW
Improved Economic Decision-Making
5196-ANJ
Departmental Reporting System
5196-PEH
General Cross-Assembler Generator
5196-PKD
Field Developed Programs
The following is a list of IBM Field Developed Programs (FDPs) and their
respective program numbers that VM/310 users have found useful. For
installation and storage information, consult the publications that
support these programs.
VM/370 Performance Monitor Analysis Program
5198-CPX
Financial Planning System
5198-CQT
APL/CMS Interactive Financial Analysis
5798-CFX
Appendix A. PPs, IUPs, FDPs & Emulators
403
I\pI:~.J..
I,
1'.10 I
Integrated Emulators
Emulator-dependent programs (except for DOS emulation under OS or OS/VS)
that execute on a particular System/370 equipped with the appropriate
compatibility features can execute on that System/370 in DOS or as
virtual machines under VM/370.
Figure 41 shows, by System/370 model number, which integrated
emulators can execute under VM/370 and the compatibility feature numbers
(#xxxx) that are required.
No changes are required to the emulators, to DOS or OS, or to VM/370
to allow emulator-dependent programs to execute in virtual machines.
On the System/370 Model 158 only, the virtual machine assist feature
cannot operate concurrently with the 7070/7074 compatibility feature
(17117) •
In an Attached Processor (AP) system, a virtual machine can use the
SET AFFINITY com!'C.and. to make use of an emuldtol. lustalleci on only one ot
the processors. The Directory option for Affinity may be used instead,
with similar results.
System/370
Model
135, 1 35- 3, 138
145,145-3,148
155 11,158
165 II
168
4331
S/360
Model
20
1401
1440
1460
.7520
.4457
.4457
1401
1440
1460
1410
7010
#4458
#3950
7070
7074
17117
#7117
17127
7080
.7118
17128
13950
Figure 41. Integrated Emulators that Execute under VM/370
404
IBM VM/370 Planning and System Generation Guide
709
7090
7094
709411
17119
#7129
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0831
Appendix B. Configuration Aid
Appendix B shows the devices and control units that can be specified in
a V8/310 system generation; they are grouped by use.
It lists the
control units, notes the aaximum number that can be specified in the
FEATURE= operand of the RCTLUNIT macro, and tells whether or not the
control units can operate on a shared subchannel.
It shows the devices that can be attached to each control unit, and
lists the operands that can be specified for each device in the RDEVICE
macro.
The control units and devices are placed in subgroups according to
the ways they can be configured. Fer e:ample, the chart of tape devices
indicates that a 2401, 2402, or 2420 can be attached to a 2803 or 2804
control unit.
I
I
I
I Type of
I Device
RDEVICE
ISharedl
I Sub- 1 - - - - - - - - - - - - - - - - I
I Maximum I chan-I
I
Other Operands
ICUTYPE=I FEATURE= I nel IDEVTYPE=I
RCTLUNIT
I
I
1--------------------------------------------------------------Systell
I 1052
1052
Consoles
1---------------------------------------------------------I 3210
3210
3215
3215
2150
2150
3066
3066
3138
3138
I.
3148
3158
Transmission
Control
Units
3036
3036
2101
2101
IA",DAPTER=BSCA, IB!1, or
I TELE2
2102
I ADAPTER=BSCA, IB!1, or
I TELE2
I SETADDR=O, 1, 2, or 3
2103
IADAPTER=BSCA, IB!1, or
I TELE2
2102
32-DEVICEI
I
I
2103
I 116-DEVICEI
I
I
Appendix B: Configuration Aid
405
Type of
Device
Trans. mission
Control
Units
(cont. )
RDEVICE
RCTLUNIT
ISharedl
1
1------------------1 Sub- 1--------------------------------1
I Maximum 1 chan-I
I
Other Operands
1CUTYPE=I FEATURE= I nel IDEVTYPE=I
3704
3705
I
1
ICA
3704
3705
I 16-DEVICEI
1256- DEVICE I
I
1
I
,
1
I
I
I
I
I
I 16-DEVICEI
I
ICA
1
2955
1
Display
28LJ8
32-DEVICEI yes
2260
"""
r-:",
I \J.J~
yes
28LJ5
2250
3272 1
32-DEVICEI yes
I
1
2701
2265
2250
1
Remote
3270
Display
Devices
I TYPE3, or TYPE4
I MODEL=A 1 through H8
ISETADDR=O, 1, 2, or 3
ICPTYPE=EP
ICPNAME=ncpname
IBASEADD=cuu
1ADAPTER=BSCA, IBM1,
1 TELE2, or SDLC
2955
D~vict:?s
(Local
Attach. )
IADAPTER=BSCA, IBM1,
1 TELE2, TYPE1, TYPE2,
3277
3284
3286
3288
I FE ATUR E=OPR DR
2101
1AD DRES S=cuu (line
1 address)
1
1
1
IADAPTER=BSCA
1CL USTER=label
2703
2703
1ADDRESS=cuu (line
1 address)
IADAPTER=BSCA or SDLC
I CL USTER=label
1Specify a 3274 Control Unit Model 1B as a 3272. The following are
the valid DEVTYPE operands for a 327LJ:
Devi9L1Y~
DEVTYP!
3277
3277
3278
3277
3284
3284
3286
3286
3287
3284 or 3286
3289
3288
3289
3288
If a 3287 is attached to a 3272, the 3287 is specified as a 3288~
406
IBM VM/370 Planning and System Generation Guide
April 1, 1981
,
I
Type of
Device
Remote
3270
Display
Devices
(cont)
RCTLUN1i'
I Sharedl
SubI
I Maximum I chan-I
I
ICUTYPE=I FEATURE= I nel IDEVTYPE=I
1------------------1
1--------------------------------ICA
ICA
3704
3705
2841
2314
2319
IFA
3830 2
3830 2
yes
2311
2321
2303
I yes
2314
2319
I
Other Operands
I ADDRESS=cuu (line
3330
3330
3345
ISC
32-DEVICEI
64-DEVICEI
I
16-DEVICEI
64-DEV1CE I
3830 2
3345
ISC
IFA1
3830 2
ISC
IFA1
64-DEVICEI
16-DEV1CEI
64-DEV1CE I
16-DEV1CEI
64-DEV1CEI
64-DFV1CE I
16-DEV1CEI
3340
2835
2803
2804
IADDRESS=cuu (line
I address)
IADAPTER=BSCA
I CPTYPE=EP
IBASEADD=cuu
1CL USTER=label
16-DEVICEI
3333
IHODEL=1, 2, or 11
IFEATURE=SYSV1RT,
I FEATURE=V1RTUAL
IMODEL=1 or 11
I
3350
2301
yes
2820
i
I
I
I
I
ITape
I Devices
I
I
I address)
I ADAPTER=BSCA
I CL USTER=label
3704
3705
Direct
Access
Storage
Devices
RDEVICE
2305
16-DEV1CEI
!
I
I
I
16-DEV1CEI yes
16-DEV1CEI
I
1
I
I
I
I
I HODEL=1 or 2
I
,
I
1
I
I
I·
1
I
1
,
I
2401
IHODEL=1, 2, 3, 4,5,6,
1 or 8
1FEATURE=7-TRACK,
1
1 DUALDENS
1
I
2402 IHODEL=1, 2, 3, 4, 5 or 61
I
I FEATURE=7-TRACK, CONV, 1
,
I DUALDENS
I
I
2420 I MODEL=5 or 7
I
I
I
IlIf using IFA with 3344 or 3350 devices with more than 16 logical
,
1 units, specify CUTYPE=3830 with either FEATURE=32-DEVICE or 64-DEVICEI
12specify a 3880 Hodel 1 as a 3830. The 3880 Modell attaches to the I
I following processors:
System 370 Models 145, 145-3, 148, 155-11,
1
I 158, 158-3, 165-11, 168, 168-3, 3031, 3032, 3033, 4341.
I
L----------------------------------------------------------------------~
Appendix B: Configuration Aid
407
_ _
_ _ _ _
r
Type of
Device
Tape
Devices
(cont)
. _ _.
• _
... t' ............. '"
n. tJ'.L. . . .
I ,
I
;I
0
I
1)
J
b 11 L. ::>- V 0" I
~. 11 .L
1 RCTLUNIT
ISharedl
RDEVICE
1------------------1
Sub- 1--------------------------------I
1 Maximum I chan-I
I
ICUTYPE=t FEATURE= I nel
IDEVTYPE=I
Other Operands
3411
yes
3410
3411
IMODEL=1, 2, or 3
IFEATURE=7-TRACK,
I DUALDENS
3803
116-DEVICE 1 1 yes
3420
I~ODEL=3, 4, 5, 6, 7 or 8
IFEATURE=7-TRACK,
I DUALDENS
I
I
unit
Record
Output
Devices
~ ....
I
I
2821
I CLASS= (class[ ,class••• ])
IFEATURE=UNVCHSET
2540P I CL ASS= (class( , class ••• ])
1442
1443
1442P I
1443 ICLASS=(class[ ,class ••.• ])
3811
3211
2826
1018
2520
2520P
ICLASS=(class,[class.~~])
3203
3203
I~ODEL=4 or 5
IFEATURE=UNVCHSET
3505
3525
I CL ASS= (class,[ class. e .• ])
3800
3800
IFEATURE=4WCG~S,
1403
ICLASS= (class( ,class.. e.e])
I I ~AGE=illagelib,
I CHARS=ffff,FCB=lpi,
I DP~SIZE=n
unit
Record
Input
Devices
Special
Devices
2821
2540R
2520
2520R
3505
3505
1442
1442R
2495
eTCA
7443
yes
2495
CTCA
7443
IFEATURE=16-DEVICE should be specified for 3808 when the communicator
feature is used, allowing access to a second tape control unit and
eight more tape drives.
L-__________________________________________________________________
~
408
IBM VM/370 Planning and System Generation Guide
April 1, 1981
Appendix C. CP/CMS
Nucleus/Module/Segment Regeneration
Requirements
Whenever a PTF is applied to eMS source code, the eMS nucleus, one of
the segments, and/or some CMS modules, must be regenerated.
The
following table shows which must be regenerated in each case.
(If a
source name does not appear in the table, either the file is contained
within the CMS nucleus, or it is loaded by another file, for example,
DMSBTB loads DMSBTP.)
Change in
Source
DMSACC
DMSACF
DMSACM
DMSALU
DMSAMS
DMSARE
DMSASD
DMSASM
DMSASN
DMSBAB
DMSBOP
DMSBTB
DMSCLS
DMSCMP
DMSCPY
DMSDLB
DMSDLK
DMSDOS
DMSDSK
DMSDSL
DMSDSV
DMSEDC
DMSEDF
DMSEPI
DMSEDX
DMSEXT
DMSFCH
DMSFLD
DMSFOR
DMSGIO
DMSGLB
DMSGND
DMSHDI
DMSHDS
DMSIFC
DMSLBM
DMSLBT
DMSLDS
DMSLGT
DMSLIB
DMSLLU
DMSLSB
DMSLST
DMSLSY
DMSM33
DMSMDP
Requires Regeneration
of Module/Nucleus/Segment
ACCESS, Nucleus
ACCESS, Nucleus
ACCESS, Nucleus
ACCESS, FORMAT, RELEASE, Nucleus
AMSERV
RELEASE
ASSEMBLE
ASSEMBLE
ASSGN
Segment
Segment
CMSBATCH
Segment
COMPARE
COPYFILE
DLBL
DOSLKED
Seqment
DISK
DOSLIB
DSERV
EDIT (see Note) ,Segment
EDIT (see Note) ,Segment
EDIT (see Note) ,Segment
EDIT (see Note) ,Segment
DMSEXT, Segment
segment
FILEDEF
FORMAT
EDIT (see Note), Segment
GLOBAL
GENDIRT
HNDINT
HNDSVC
CPEREP, Nucleus
MACLIB
TXTLIB
LISTDS
Segment
Segment
LISTIO
Segment
LISTFILE
Segment
Segment
MODMAP
EXEC Procedure
To Use
CMSGEND
CMSGEND
CMSGEND
CMSGEND
CMSGEND
CMSGEND
CMSGEND
CMSGEND
CMSGEND
DOSGEN
DOSGEN
CtiSG END
DOSGEN
CMSGEND
Cl'1SGEND
CMSGEND
Cl'1SGEND
EOSGEN
Cl'1SG END
CMSGEND
CMSGEND
CMSG END, CM SXG EN
Cl'1SGEND, CMSXGEN
Cl'1SGEND, CMSXGEN
Cl'1SGEND, CMSXGEN
CMSGEND
DOSGEN
CMSGEND
Cl'1SGEND
CMSGEND, Cl'1SXGEN
Cl'1SG END
Cl'1SGEND
CMSGEND
CMSGEND
CMSGEND
CMSGEND
CMSGEND
CMSGEND
CMSXGEN
CMSXGEN
CMSGEND
Cl'1SXGEN
CMSGEND
CMSXGEN
VSAM GEN (AM S)
CMSGEND
Appendix C: CP/CMS Regeneration Requirements
409
1\ pL .1..1.
I,
I
~O
I
.------------------------I Change in
Requires
I Source
DMSMVE
DMSOLD
DMSOP1
DMSOPT
DMSOR1
DMSOR2
DMSOR3
DMSOVR
DMSOVS
DMSPDP
DMS PRT
DMS PRY
DMS PUN
DMS QRY
DMSRDC
DMS RNE
!) MS RNM
DMSFRV
DMSS33
DMSSAB
DMSSBD
DMSSBS
DMSSCR
DMSSCT
DMSSEB
DMSSEG
DMSSET
DMSSLN
DMSSMN
DMSSOP
DMSSQS
DMSSRT
DMSSRV
DMSSSK
DMSSVN
DMSSVT
DMSSYN
DMSTMA
DMSTPD
DMSTPE
DMSTYP
DMSUPD
DMSV33
DMSVAN
DMSVAS
DMSVIP
DMSVPD
DMSVVN
DMSVVS
DMSXCP
DMS ZAP
DMSZIT
Regeneration
of Module/Nucleus/Segment
EXEC Procedure
To Use
MOVEFILE
Segment
Segment
OPTION
Segment
Segment
segment
SVCTRACE
DMSOVS
Segment
PRINT
PSERV
PUNCH
QUERY
READCARD
RENUM
CMSGEND
CMSXGEN
DOSGEN
CMSGEND
DOSGEN
DOSGEN
DOSGEN
CMSGEND
CMSGEND
DOSGEN
CMSGEND
CMSGEND
CMSGEND
CMSGEND
CMSGEND
CMSGEND
RSERV
segment
Segment
Segment
Segment
EDIT (see Note) ,
Segment
Segment
Segment
SET
Segment
Segment
Segment
Segment
SORT
SSERV
SETKEY
Segment
Segment
SYNONYM
TAPEMAC
TAPPDS
TAPE
TYPE
UPDATE
Segment
Segment
Segment
Segment
DMSVPD
Segment
Segment
Segment
ZAP
EDIT (see Note)
CMSGEND
VSAMGEN
CMSXGEN
CMSXGEN
CMSXGEN
CMSGEND,
CMSXGEN
CMSXGEN
CMSXGEN
CMSGEND
CMSXGEN
CMSXGEN
CMSXGEN
CMSXGEN
CMSGEND
CMSGEND
CMSGEND
CMSXGEN
CMSXGEN
CMSGEND
CMSGEND
CMSGEND
CMSGEND
CMSGEND
CMSGEND
VSAMGEN
VSAMGEN
VSAMGEN
VSAMGEN
CMSGEND
VSAMGEN
VSAMGEN
DOSGEN
CMSGEND
CMSGEND
,..ur""1':!'T""
.... u ... \;J
Segment
..... ~.~
(AMS)
CMSXGEN
(VSAM)
(AMS)
(AMS)
(VSAM)
(VSAM)
(VSAM)
No!e: When
the CMSGEND EXEC ~rocedure
is invoked for EDIT,
i t creates
the EDIT module,
and then automaticallY reinvokes itself
to create the
EDMAIN module.
410
IBM
VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
If you must regenerate the CMS nucleus, see "Updating CMS" in Part 5.
"Updating YM/370." If you must regenerate the DOS segment, see "Loading
and Saving the CMS/DOS Segment called CMS/DOS" in Part 3, "Gen~rating
YM/310";
all the other EXEC procedures for generating segments are
described in part 5 "Updating VM/370".
CMS should be resaved whenever the CMS nucleus, CMSSEG,
or system
S-disk directory is updated. This will insure that the saved CMS system
adequately reflects the physical system.
If a CMS module must be regenerated, see "Creating CMS Disk-Resident
Modules" in "part 5. Updating VM/310~" The CMSGEND EXEC is described in
"EXEC Procedure and Command Format Summaries", also in Part 5.
If you apply a PTF to certain CP source programs, the corresponding
CMS modules must be regenerated also to run properly. The source name,
module name, and procedures used for regenerating the module are shown
in the following table.
r------------------------------------------------------------Change inl Regenerate Module
Source
Name Required
EXEC Procedures to Use
DMKDDR
DDR
I GENERATE, CMSGEND
DMKDIR
DIR
I GENERATE, CaSGEND
DMKFMT· INo module name--does I GENERATE
Inot execute under CMSI
DMKRND I
NCPDUMP
i CMSGEND
DMSARD I
INSTEP
ASM370S
INSTEP
ASM3705
DMSARX I
INSTEP
ASM3705
DMSARN I
DMSGRN I
CMSGEND
GEN3705
CMSGEND
DMSNCP I
SAVENCP
L----______________________________________________________
~
THE DOSGEN
The INSTEP EXEC procedure is described in Part 4. "Generating ~ne
3104/3105 Control Program"; all the other EXEC procedures are described
in Part 5. "Updating VH/370."
Appendix C: CP/CMS Regeneration Requirements
411
a pI:" .LJ.
412
I,
I
~o
I
IBM VM/370 Planning and System Generation Guide
Appendix 0: Compatible Devices
The devices listed below are functionally equivalent to the 2770
Communication System operating on a VK/310 Remote Spooling Communication
Subsystem. Details on the feature requirements for VM/370 RSCS use and
operational control of such devices are not contained in VM/310
publications but in the programming and operating publications that
support these devices.
.
•
Programming Guide for Communicating
printer, Form No. G544-1001
•
IBM 6640 Document
S544-0507
•
IBM 6640 Document Printer
Form No. S544-0506
•
Programming Guide for Communicating with the IBM
Information Processors, Form No. G544-1003
•
IBM 6/450, 6/440, and 6/430 Information Processors - Communicating
User's Guide, Form No. S544-0521
•
IBK 6/450, 6/440, and 6/430 Information Processors - Communicating
Operating Instructions, Form No. S544-0522
with the
IBK 6640
Printer - Communicating User's
I~!! !!gg ~grd
11 !I.E~ri t~£
!I£~ii~£ - ~Q~~i£ating
Document
Guide, Form No.
- Communicating Operating Instructions,
-
£~icat.i.ruI
S!.ns. IBM
Office System 6
£240
11~
Car£.
•
Programming Guide for Com municat ing with the IBM Mag Card II
Typewriter and the IBM 6240 Kag Card Typewriter, Form No.
G544-1005
•
IBK Mag Card II Typewriter - Communicating and IBM 6240 Mag Card
Typewriter
Communicating Reference Guide, Form No. S544-0549
•
IBM Mag Card
Typewriter
S544-1005
-
II Typewriter - Communicating and IBM 6240 Mag Card
Communicating Operating
Instructions, Form No.
Appendix D. Compatible Devices
413
414
IBM VM/370 Planning and System Generation Guide
Appendix E: Compatibility of VM/370 with
CP-67/CMS
V~/370
and
its components,
the control
program (CP)
and the
Conversational ~onitor System (CMS), are based on the CP-61/C~S system,
and are designed especially for the IBM System/310.
The Dynamic
Translation Facility on the System/310 provides the same facilities as
did Dynamic Address Translation (DAT) on the System/360 ~odel 61, but
differs in
hardware design details and
software implementation.
Consequently, the CP-61/C~S system does not run on a System/310, and the
VM/370 system does not run on the System/360 Model 67. The internal
control block structure differs between the two systems, and user
modifications to the CP-61/CMS system may no longer be necessary,
desirable~ or usable in the new system without some redesign effort.
Certain commands familiar to CP-61 users are not supported in V~/310.
The functions available under CP-61 do, however, have equivalents in
V~/370 where appropriate.
The following is a list of all CP-61 console
functions, with operand variations, showing the incompatibilities with
VM/3 7 0. Functions listed under CP-67 Version 3.1 and not under V~/310
indicate that the syntax and function are identical.
There are, of
course, additional functions available with the VM/370 commands. The CP
and CMS commands are described in the VM/310 £~ £Qm!~ng Ref~~~~ fo~
fi~~ra! Use!:§ and the VM/310 CPI§. Command ~Q Mac!:Q !t~f~~£~.
In Figure 42,
meanings:
the
letter in
the "status"
column
A
indicates CP-67 syntax accepted in VM/310
R
indicates CP-61 syntax not accepted but
supported by a different VPI/370 command
N
indicates CP-61 syntax not accepted
supported in VM/310.
has the
the
following
function
and the function
is
is not
Whenever an R appears in the "status" column, the VM/310 command that
provides the same function as a former CP-61 command is shown in the
"V~/370 Equivalent" column.
Appendix E: Compatibility of VM/310 with CP-67/CMS
415
r
IStatus, CP-67 Command
VM/370 Equivalent
1------1
R
1
,
A
,
I
I
,
1
,
I
I
I
,
1
ACNT ALL
I ACNT
I
IATTACH cuu TO {SYST~M} AS {VOlid}
user1d
vaddr
I
I
A
A
A
A
A
A
R
I
I
A
N
N
I BEGIN
IBEGIN hexloc
I
hexloc1[-hexloc2]
IDCP Lhexlocl[-hexloc2]
IDCP Thexlocl[-hexloc2]
iDCP
,
I DETACH vaddr
IDETACH raddr
I
I
I D! ~.l system
I
IDIRECT LOCK
IDIRECT UNLOCK
1
A
A
I DISABLE line
IDISABLE ALL
I
A
R
IDISCONN
IDISCONN xxx
I
A
R
A
I DISPLAY
IDISPLAY
I DISPLAY
I
I
R
A
I DISPLAY
IDISPLAY
I
I
I
R
A
I DISPLAY
IDISPLAY
A
I DISPLAY
I DISPLAY
I
I
T(-hexloc2]
Thexlocl(-hexloc2]
K[-hexloc2]
Khexlocl[-hexloc2]
DISPLAY
DISPLAY
Y(-reg2]
Yreg(-reg2]
A
A
DISPLAY
DISPLAY
X[-reg2]
Xreg(-reg2]
A
DISPLAY PSW
A
R
A
DMCP
DMCP
DMCP
hexlocl[-hexloc2]
L[ -hexloc2 ]
Lhexlocl[-hexloc2]
r
,
DISPLAY LOI-hexloc21
I-END
I
L
.J
r
,
DISPLAY TOI-hexloc21
I-END
I
L
.J
r
,
DISPLAY K01-hexloc21
I-END
I
.J
r
,
DMCP LOl-hexloc21
I-END
,
L
L
Figure 42. VM/370 Compatibility with CP-67 (Part 1 of 4)
416
{SYSTEM}
{userid}
DISCONN HOLD
G[-reg2]
Greg(-reg2]
A
A
I
I
I
I
I
I
I
I
FRO~
L
I
I
A
hexlocl [-hexloc2]
L[-hexloc2]
Lhexlocl[-hexloc2]
DETACH raddr
IBM VM/370 Planning and System Generation Guide
.J
r
I VM/370 Equivalent
IStatus, CP-67 Command
,
,
A
A
DRAIN
N
DUMP
A
A
ENABLE line
ENABLE ALL
A
EXTERNAL
A
A
IPL CMS
IPL devadd
R
IPLSAVE CCW
IPL vaddr NOCLEAR
R
KILL userid
KILL
FORCE userid
N
T[-hexloc2]
Thexlocl[-hexloc2]
r
DMCP
DMCP
R
IDMCP TOI-hexloc21
I-END
,
I
L
.J
I
I
I
I
,
I
I
r ,
A
LINK userid xxx yyy IWI[PASS=pwd]
,
IRI
L
:.J
r ,
R
LINK userid xxx yyy I WI
I RI
L :.J
R
LOCK userid fpage lpage
LOGIN userid
LOGIN userid xxx
A
R
LOGOUT
LOGOUT xxx
A
A
A
R
A
R
A
A
A
R
R
A
A
MSG userid line
MSG CP line
IMSG ALL line
,
,I PSWREST ART
I PURGE
I PURGE
I PURGE
I
IQUERY
I QUERY
I QUERY
I QUERY
(NOPASS)
I
I
I
I
r ,
I
ILINK userid xxx yyy IWI
IR I
I
L .J
I
I
,
LOGON userid MASK
LOGOFF HOLD
MSG OPERATOR line
SYSTEM RESTART
READER
PRINTER
PUNCH
DEVICE ALL
DEVICE xxx
DUMP
FILES
QUERY ALL
QUERY xxx
L
Figure 42. VM/370 Compatibility with CP-67 (Part 2 of 4)
Appendix E: Compatibility of VM/370 with CP-67/CMS
417
r
,Status, CP-67 Command
I
,
A
,
N
,,,
,
I
I
,
A
n
R
N
R
A
R
A
A
A
A
A
A
I QUERY LOGMSG
I QUERY MAX
, QUERY
, QUERY
I QUERY
I QUERY
I QUERY
, QUERY
I QUERY
, QUERY
, QUERY
, QUERY
QUERY
QUERY
QUERY
NAMES
PORTS
PORTS ALL
PORTS FREE
PORTS xxx
PRIORITY userid
Q2
TI~E
userid
USERS
VIRTUAL xxx
VIRTUAL CORE
VIRTUAL ALL
V~/370
Equivalent
,,
,
I
I QUERY LINES
,
'QUERY xxx
1
I QUERY PAGING
,
,
,,
I
1
1QUERY VIRTUAL STORAGE
,
r.
P.E ~.!)y xxx
A
REPEAT xxx Y
R
RESET
SYSTE~
R
R
SET ADSTOP xxxxxx
SET ADSTOP OFF
ADSTOP xxxxxx
ADSTOP OFF
R
SET APLBALL {ON }
OFF
TER~INAL
APL {ON }
OFF
TER~INAL
ATTN {ON }
OFF
R
R
A
A
SET ATTN {ON }
OFF
1
,
,,SET CARDSAVE
I
!SET DUMP xxx
,
{~~F}
RESET
SPOOL READER { HOLD}
NOHOLD
,
!SET {LINEDIT}
{g;F}
RUN
A
A
A
SET LOGMSG
SET LOGMSG NULL
SET LOGMSG n
N
SET MAX
A
SET MSG
R
R
R
R
SET
SET
SET
SET
A
SET WNG {ON }
OFF
A
SHUTDOWN
A
SLEEP
{g~F}
Q2 nn
TRACE devtype
TRACE OFF
TRACE END
SET PAGING nn
TRACE type dev
TRACE type OFF
TRACE END
L
Figure 42.
418
V~/370
Compatibility with CP-67 (Part 3 of 4)
IBM VM/37Q Planning and System Generation Guide
r
IStatusl CP-67 Command
A
SPACE xxx
R
A
R
SPOOL xxx ON YIY
S POOL xxx CON T
SPOOL xxx OFF
A
START xxx
A
A
STCP hexloc
STCP Shexloc
A
,
,
A
A
A
STORE
STORE
STORE
STORE
STORE
STORE
I
I
R
TERM xxx
A
UNLOCK userid fpage lpage
A
A
WNG userid text
WNG ALL text
A
A
I
,,
I
I
I
I VM/370 Equivalent
SPOOL yyy CLASS x
SPOOL xxx NOCONT
Lhexloc hexinfo •••
Shexloc hexstring
Greg hexinfo •••
Yreg hexinfo •••
Xreg hexinfo •••
PSi [hexinfo1] hexinfo2
FLUSH xxx
f
I
I
I
R
I
I
XFER xxx {TO use rid}
OFF
SPOOL xxx {TO USerid}
OFF
L
Figure 42. VM/370 Compatibility with CP-67 (Part 4 of 4)
Appendix E: Compatibility of VM/370 with CP-67/CMS
419
Although the CMS in VM/370 is built upon CMS Version 3.1 in CP-67/CMS,
there are five types of modifications that were made to 3.1 that affect
the relationship between versions:
1.
~n£hang~g:
2.
!dditio~al
3.
~~~Ang NaID~
4.
Some commands and system functions
therefore, complete compatibility exists.
remain unchanged;
iYD£!ionA! Capability:
Functional and syntactical
enhancements are effected; but, in some cases, old keywords and
functions are supported.
All~~~tiQn§: Commands have name changes, but a SYNONYM
file may be included during nucleus system generation.
KeY~Q£g
~hang~§:
Some
keywords within
a
command are
modified,
deleted or added.
5.
MajQr ~Qgi!ic~tiQD§: Improvements to commands and system functions
caused complete incompatibilities in the following areas:
is significantly larger, all MODULES
their object (TEXT)
files using the
•
Because the CMS nucleus
must be recreated from
GENMOD command.
•
Because you may now have up to 10 disks,
the logical directory
identifications (filemode letters) are changed to reflect a more
natural, easy-to-remember, search order: P, T,
A, B, S, C
becomes A, B, C, D, E, F, G, S, Y, Z -- with the system disk
being the S-disk, and the primary disk becoming the A-disk.
•
The following global changes of filetypes must be made:
SYSIN to ASSEMBLE
ASP360 to MACRO
•
For language processors, the DECK and NODECK options have a new
meaning, they route the object (TEXT) file to the spooled card
punch; the LOAD and NOLOAD options now invoke the function
formerly performed by DECK and NODECK, and the writing of the
TEXT file onto a CMS disk.
•
No 2311 disk support is provided for CP or CMS files.
•
In Version 1.0 the tape designations are as follows:
TAP1 is for 181
TAP2 is for 182
The default for tape commands is TAP1.
420
IBM VM/310 Planning and System Generation Guide
•
CMS does not function on a real CPU without the control program.
•
TXTlIB files must be recreated.
•
Because many fields
are changed in the
CMS nucleus or
rearranged, many of your programs that refer to these fields
have to be reassembled with the new CMS macro libraries.
•
Modules that refer to fields containing sizes,
limits, and
quantities within the CMS nucleus may have to be reassembled and
then regenerated.
•
SYSlIB MACLIB is renamed to CMSLIB MACLIB.
•
All EXEC files should be checked for command name and operand
changes, filemode usage, and so on, and changed to conform to
VM/370 CMS. Major changes are:
&TYPEOUT to &CONTROL
&PRINT
to &TYPE
&INDEXO to &RETCODE
•
The options specified for a LOAD command do not remain in effect
for subsequent INCLUDE commands; options are reset to default
settings unless the SAME option is specified.
•
Filenames and filetypes must be
characters.
•
If the CMS Version 1.0 system does not recognize
the command line is automatically passed to CP.
and QUERY commands do not recognize an operand
command line is passed to CP. This is not true
the CP command must be explicitly stated. The
negated by entering the command:
composed entirely of alphameric
a command name,
If the CMS SET
or option, th e
for EXEC files;
feature may be
SET IMPCP OFF
VM/370 CMS Support of CP-67/CMS Commands
Command name changed to RENAME.
Components of the new file identifier may not be specified
as asterisk ~).
An equal sign
(=)
performs the same
function.
NOUP option keyword changed to NOUPDIRT; NOUP is the
abbreviation.
Default options added: NOTYPE, UPDIRT.
Only one file may be assembled per ASSEMBLE command.
Q.Eii.Qns_~hlm~g:
NODECK is the default
]IAgINODIAG changed to !~E~INOTERM
LTAPn not supported
LDISK option name changed to DISK
Q.E1ion~_!gdeg:
1QADINOLOAD, !LG!INOALGN
Q~IDOS, TEST'!OT~~!, LINECT nn122,
NU~'NONUM,
STMTI!~STMI
Appendix E: Compatibility of VM/370 with CP-61/CMS
421
~unctionally
supported by SET BLIP.
BR!!IN
Not implemented.
£~QIT
Functionally supported by EDIT.
£HARD~l
Functionally supported by CP TERMINAL CHARDEF command.
£1Q~IO
Functionally supported by the CP commands, SPOOL and CLOSE.
£1.!iOVE,E
Functionally supported by SVCTRACE OFF command.
CN!I26
Functionally
option.
£Ql1BI.N~
Functionally supported by COPYFILE.
£Qr!PA1!~
Filemode required.
NOSEQ option functionally supported by COL option.
supported
by
COPYFILE
command
with
EBCDIC
Command name changed to CP.
NOMSG option not supported.,
£!II!
Functionally supported by COPYFILE.
!!~!H!Q
No change.
422
BREAK
No change.
CAW
No change.
CSW
No change.
DEF
Subcommand name changed to DEFINE;
truncation; no change in format.
DUMP
No change.
GO
No change.
GPR
No change.
IPL
Not supported from DEBUG.
KX
Supported by CMS command HX.
ORIGIN
No change.
PSi
No change.
RESTART
Not supported.
RETURN
No change.
SET
No change.
STORE
No change.
TIN
Not supported.
x
If symbol specified, length of field defaults to
u.
IBM VM/370 Planning and System Generation Guide
DEF minimum
No change.
Functionally supported by DDR command.
Functionally supported by TYPE command with HEX option.
Functionally supported by DDR command.
Functionally supported by CP command ECHO.
Filename must be specified.
Filemode may be specified.
lRECl may be specified for a new file.
BACKSPACE
Functionally
supported
by
CMS
command,
SET
INPUT.
BLANK
Functionally supported by OVERLAY.
BOTTOM
No change.
BRIEF
Function accomplished by VERIFY OFF request.
CHANGE
No change.
DELETE
/string/ is not valid as an operand.
(DELETE * may be used to delete
file. )
to end
of
FILE
Filetype and filemode may be specified.
FIND
No change.
INPUT
No change.
INSERT
Functionally supported by INPUT request.
LOCATE
No change.
NEXT
No change.
OVERLAY
No change.
PRINT
Request name changed to TYPE.
may be specified to indicate that
(TYPE
typing is to continue until EOF.)
Instead of 1 in second field,
is specified.
*
*
QUIT
No change.
REPEAT
Valid only for subsequent OVERLAY subcommand.
(REPEAT
may be specified to indicate that the
OVERLAY subcommand is to be repeated for the
remainder of the file.)
*
Appendix E: Compatibility of VM/370 with CP-67/CMS
423
RETYPE
Request name changed to REPLACE.
SAVE
Filetype and filemode may be specified.
SERIAL
First operand changed to
{OFF I 'seq' (same as ID), ON, ALL} •
TABDEF
Functionally supported by CMS command SET INPUT.
TABSET
No change.
TOP
No change.
UP
No change.
VERIFY
Operand format changed; function added.
x
No change.
Y
No change.
ZONE
No change.
Default option added; old format accepted.
* * * Not supported.
No change.
&ERROR
Action does not default to &CONTINUE.
&IF
No change.
&EXIT
No change.
&QUIT
Functionally supported by &EXIT O.
&SKIP
No change.
&GOTO
EXIT not supported as operand.
Line-number now a valid operand.
&LOOP
No change.
&CONTINUE
No change.
&TYPEOUT
Functionally supported by &CONTROL control word;
ON, ROEXEC, RESUME, KILL not valid.
CMS oper and added.
r
&TIME
L
424
,
r
,
,ON , I RESET I
Operands changed to IQFFI , TYPE!.
.J
L
&SPACE
No change.
&PRINT
Functionally supported by &TYPE.
IBM VM/370 Planning and System Generation Guide
.J
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
&UPRINT
Functionally supported by &BEGTIPE.
&PUNCH
No change.
&UPUNCH
Functionally supported by &BEGPUNCH.
&COMMENT
No change. Function duplicated by
&ARGS
No change.
&READ
VARS operand added.
&STACK
No change.
&BEGS~ACK
ALL operand added ..
&ENDSTACK
Functionally supported by &END.
&SET
Not implemented.
Device names changed:
CON
DSK -DSK-nn
DUMMY
PRT
PUN
RDR
TAPEn
BAT
*
card.
TERMINAL
DISK
not supported
no change
PRINTER
PUNCH
READER
unchanged
not supported
Not supported from terminal ..
FORMAT
All functions supported; all operands changed.
This command is
FORTHX, GOFORT,
Products.
now supported by the commands
and CONVERT which invoke IBH
GENDIRT
Target mode parameter is added ..
GENMOD
Incompatible; positional parameters and
equivalent function performed ..
options
FORTG1,
Program
changed;
PRINT function removed; others compatible.
Not explicitly supported in CMS; however, the command may be
issued and is passed to the control program for processing.
Either a device address or system name must be specified.
Cyl-no may be specified ..
Options Added: CLEARI NOCLEAR.
No functional equivalent.
Command nalle changed to
HO.
Command name changed to HT.
KX
Command name changed to HX.
LINEND
Functionally supported by the CP command TERMINAL LINEND.
Appendix E: Compatibility of VM/370 with CP-67/CMS
425
apr1.l.
I,
I~ti
I
Command name changed to LISTFILE; LISTF accepted.
option Chang~.§:
SORTOption not implemented.
ITEMOption not implemented; ALLOC option
both logical records and blocks.
NAMEoption name changed to FNAME.
TYPEoption name changed to FTYPE.
MODEOption name changed to FMODE.
RECSupported by ALLOC option.
DATEproduces mm/dd/yy hh:mm.
YEARNot implemented; functionally supported
by DATE option.
TIMENot implemented; functionally supported
by DATE option.
LABEL and FORMAT options added.
APPEND option added.
HEADERINOHEADER option added.
produces
/""'1... _ _ _ _ _ •
!.o~,g
""'"' . . .;
....... 1"'\
~VJi,'"
""'.I. ..
Yo.&.4 ~ ,,;;;..,;) •
SLCxxxxxxSLC12000SINVPINVSREPPREPSLIBBSAUTGXEQNOXEQ-
option changed to ORIGIN xxxxxx.
default changed to first available location.
option name changed to NOINV.
option name changed to INV.
option name changed to NOREP.
option name changed to REP ..
option name changed to NOLIBE.
option name changed to NOAUTO.
option name changed to START.
option not supported.
Options Added: RESET.
TXTLIB files may
but must have
command.
no longer be specified in a LOAD command,
been previously specified by a GLOBAL
Filetype must be specified if filemode is given.
Functionally supported by LOGON and ACCESS commands.
Comma between mode and extdisk replaced with slash
extdisk optional •
.Qpti.Q~:
NOPROF-option supported.
NOTYPE-option not supported.
NO-UFo-option name changed to ERASE.
LOGOU1
Functionally supported by CP command LOGOFF.
MAPPR1
Functionally supported by CMS commands TYPE or PRINT.
MOQMAP
No change.
OFFLINE READ
Functionally supported by READCARD command.
OFFLI NE PRINT
Functionally supported by PRINT command.
426
IBM VM/370 Planning and System Generation Guide
(/l;
QrrLINE PRINTCC
Funct ionally supported by PRINT command.
QFF1INE PRINTUPC Functionally supported by PRINT comma nd.
QFFLIN~
PUNCH
Functionally supported by PUNCH command.
QEELIN~
PUNCHCC
Functionally supported by PUNCH comma nd.
QErLIN~
PUNCHDT
Functionally supported by PUNCH command.
Command name Changed to TAPPDS.
This command is nov supported by the command
invokes an IBM Program Product.
PLIOPT which
Command name changed to TYPE.
Filemode may be specified.
n3 functionally supported by COL option.
QEiions-Agdeg: HEX, MEMBER.
Command name changed to INCLUDE.
Option differences are the same as for LOAD.
TXTLIB files may no longer be specified in the command; but
must have been previously specified by a GLOBAL command.
No change.
Files may be processed by
program.
SCRIPT/370, an IBM user-installed
§.ETERR
Functionally supported "by SVCTRACE ON.
~ETOV~.R
Functionally supported by SVCTRACE ON.
Not implemented.
Filemode must be specified for both input and output files.
Functionally supported by COPYFILE command.
CNO) operand not valid.
Functionally supported by QUERY command.
No change.
Appendix E: Compatibility of VM/370 with CP-67/CMS
427
Command name changed to SYNONYM; SYN minimum truncation.
Filetype must be SYNONYM.
Qnio.ll.§:
SYNONYM command with P and PUSER options is functionally
supported by QUERY SYNONYM.
TAPn may also be specified by a virtual address.
"n" options after SCAN, SKIP, SLOAD, replaced by 'EOF nl.
X~£iio.n.§_Adde£:
!!R~
DUMP
!!R~
tOAD
MODESET, BSF, BSR, ERG, FSF, FSR, RUN, REi.
Functionally supported by TAPE LOAD EOFn.
File identifiers may be specified.
Q~iion.§_!££~£:
NOPRINT'PRINT'!ER~IDISK,
EOFnIEOTIEOX1·
!!g~
SCAN
Filename and filetype may be specified.
Functionally supported by TAPE SCAN (EOF n).
QE1ion.§~££~£: NOPRINTIPRINTIIER~IDISK,
EOFnIEOTI~Ql1·
!!g~
SKIP
Comments same as for TAPE SCAN.
!!g~
StOAD
Fu nct ionally supported by TAPE LOAD fn ft.
Fi lemode may be speci fied.
!APEIQ
Functionally supported by TAPE.
I.!gPD~
Default filename is TAPPDS for NOPDS option.
Default filetype is CMSUT 1.
Q~1iQ.ll-£h~lliI~'§:
NPDS
NCOLI
TAPx
NEND
NMAXTEN
option name changed
option name changed
default is TAP1.
option name changed
option name changed
to NOPDS.
to NOCOLl.
to NOEND.
to NOMAXTEN.
Functionally supported by MOVEFILE command.
Functionally supported by MOVEFlLE command.
PRINT and LIST functions supported by MAP function.
Q~1iQn~h~.ng~.§:
P - option name changed to REP.
Default options added NOREP, NOSEQ8, NOlNC.
Functionally supported by INCLUDE command with the
option. See discussion of REUSE compatibility.
428
IBM VM/370 Planning and System Generation Guide
SAME
Command name changed to SET.
lunct1:.Ql!§:
BLIP
CHARDEF
IMPEX
LDRTBL S
LINEND
RDYMSG
REDTYPE
RELPAGE
ON may be specified to return to default
Functionally supported by CP
command TERMINALI {CHARDELtLINEDELtESCAPE}
No change.
No change.
Functionally supported by CP command TERMINAL
LIN END.
Q!IOFF changed to LMSGI~~~~.
No change.
No change.
IYl!£iiol!§_addeg: INPUT, OUTPUT, ABBREV, IMPCP.
Functionally supported by TAPE command or MOVEFILE command.
!
Command name changed to RUN.
Filetype and filemode may be specified.
Files may also have filetypes in addition to EXEC, MODULE,
and TEXT of those used by the language processors for
input.
CP-67/CMS Macros and Functions and
Corresponding CMS Macros
The list below shows VM/370 CMS macros that correspond to CP-67/CMS
macros and functions. The CP-67/CMS functions have no structural
equivalent in VM/370 CMS, but in most cases the function is available
via a VM/370 CMS macro. If you need information on how to build a
parameter list that can be scanned properly by VM/370 CMS, refer to the
Y1U3 7 0 ~Y§~em .f!:ogr.§:.mJ!!,g!:~.§ Guid~ or VM/37Q. CPIS !!§~~§ Guidg.
CP-67/CPIS
VM/370
~ac1:Q§
~Y1:Y.§:l~l!!
CKEOF
CMSREG
CPIS YS REF
ERASE
FCB
FINIS
FSTB
RDBUF
SETUP
STATE
TYPE
TYPIN
WRBUF
ATTN
CARDIO
CLOSIO
CONWAIT
CPFUNCTN
Not Available
REGEQU
Not Available
FSERASE
No Change
FSCLOSE
No Change
FSREAD
FSOPEN
FSSTATE
WRTERM
RDTERM
FSWRITE
No Change
PUNCH,RDCARD
1
WAITT
1
CP-67
Fun£tions
DEBDUPIP
ERASE
FILEDEF
FINIS
HNDINT
HNDSVC
POINT
Not Availa.ble
FSERASEl
1
FSCLOSE
HNDINTl
HNDSVCl
FSCB, FSREAD, FSWRITE,
FSOPEN
PRINTL
FSREAD
FSSTATE
No Change
RDTAPE, WRTAPE, TAPECTLl
HNDEXT
WRTERlP
WRTERM
WAITD
RDTERM
FSWRITE
PRINTR
RDBUF
STATE
STRINIT
TAPEIO
TRAP
TYPE
TYPLIN
WAIT
WAITRD
WRBUF
lSee the Y~LJ1Q ~§i~J!! Rrog!:.§:~~~~
a command from a program.
VPI/370 Macros
~gy i va.l~1!!
Guig~
for information on how to call
Appendix E: Compatibility of VM/370 with CP-67/CMS
429
430
IBM VM/370 Planning and System Generation Guide
April 1, 1981
Appendix F. VM/370 Restrictions
A virtual machine created by VM/370 is capable of running an IBM
System/360 or system/370 operating system as long as certain VM/370
restrictions are not violated. Virtual machine restrictions and certain
execution characteristics are stated in this appendix.
Dynamically Modified Channel Programs
In general, virtual machines may not execute channel programs that are
dynamically modified (that is, channel programs that are changed between
the time the START I/O
(SIO) is issued and the time the input/output
ends, either by the channel program itself or by the processor) •
Exceptions
(that is, dynamically
special consideration by CP) are:
modified
channel programs
Access
Method
given
•
Those generated by the Indexed Sequential
running under as/pcP, OS/MFT, and as/MVT
(ISAM)
•
Those generated by ISAM running in an OS/VS virtual=real partition
•
Those generated by the as/vs Telecommunications Access Method (TeAM)
Level 5, with the VM/370 option
•
Those containing polling sequences
The self-modifying channel programs that ISAM generates for some of
its operations receive special handling if the virtual machine using
ISAM has that option speci fied in its VM/370 directory entry. There is
no such restriction for DOS ISAM, or for ISAM if it is running in an
as/vs virtual=virtual partition. If ISAM is to run in an OS/VS
virtual=real partition, you must specify the ISAM option in the VH/370
directory entry for the as/vs virtual machine.
virtual machines using OS/VS TCAM (Level 5, generated or invoked with
the VM/370 option) issue a DIAGNOSE instruction when the channel program
is modified.
This instruction causes CP to reflect the change in the
virtual CCi string to the real CCW string being executed by the channel.
CP is then able to execute the dynamically modified channel program
properly.
When a virtual machine starts a channel program containing a polling
sequence, the ccw translation sets a PC! bit in the real CCW string.
Each time the
real CCW string is executed,
the resulting PC!
interruption causes CP to examine the corresponding virtual CCi string
for changes. Any changes to the virtual CCW string are also made to the
real CCW string while it is executing.
The restriction against dynamically modified channel programs does
not apply if the virtual machine has the virtual=real performance option
and the NaTRANS option has been set on.
Appendix F: VM/370 Restrictions
431
l"dge or:
bC"U-I~UI--IU
AS
upaated April 1, 1981 by TNL GN25-0837
Minidisk Restrictions
The following restrictions exist for minidisks:
1.
In the case of read home address with the skip bit off, VM/370
modifies the home address data in user storage at the completion of
the channel program because the addresses must be converted for
minidisks; therefore, the data buffer area may not be dynamically
modified during the input/output operation.
2.
On a minidisk, if a ccw
string uses multitrack search on
input/output operations, subsequent operations to that disk must
have preceding seeks or continue to use multitrack operations.
There is no restriction for dedicated disks.
3.
as/pcP, MFT, and MVT ISAM or OS/VS ISAM running virtual=real may be
used with a minidisk only if the minidisk is located at the
beginning of the physical disk (that is, at cylinder 0). There is
no such
restriction for
DOS ISAM
or OS/VS
151M running
v iJ: t udl..;..y 1.1. t ual.
Notg~ Because the VS1 system does
no paging, any ISAM programs run
under VS1 are treated by VM/370 as though they are running in an
ADDRSPC=REAL partition.
4.
VM/370 does not return an end-of-cylinder condition to
machine that has a virtual 2311 mapped to the top half
tracks 0 throuqh 9) of 2314 or 2319 cylinders.
5.
If the user's channel program for a minidisk does not perform a
seek operation, then to prevent accidental accessing, VM/370
inserts a positioning seek operation into the user's channel
program. Thus, certain channel programs may generate a condition
code (CC) of 0 on a SIO instead of an expected CC of 1, which is
reflected to the virtual machine. The final status is reflected to
the virtual machine as an interrupt.
6.
A DASD channel program directed to a 3330, 3340, or 3350 device may
give results on dedicated drives which differ from results on
minidisks having non-zero relocation factors if the channel program
includes multiple-track operations and depends on a search 10 high
or a search 10 equal or high to terminate the program.
This is
because the record 0 count fields on the 3330, 3340, and 3350 must
contain the real cylinder number of the track on which they reside,.
Therefore, a search ID high, for example, based on a low virtual
cylinder number may terminate prematurely if a real record 0 is
encountered.
1.
7.
432
a virtual
(that is,
Minidisks with non-zero relocation factors on 3330, 3340, and
3350 devices are not usable under OS and OS/VS systems when
the minidisk contains a VTOC of more than one track.
The
locate catalog management function employs a search 10 equal
or high CCW to find the end of the VTOC. Since VM/370 does
not permit the guest to write RO,
the VTOC search ends
prematurely.
On a 3330, 3340, or 3350, an OS/VS, or OS minidisk must start at
real cylinder 0 unless the VTOC is limited to one track.
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0831
8.
The IBCDASDI program cannot
3340, or 3350 minidisk.
assign alternate
tracks for
9.
If the DASD channel programs directed to 3330/3340/3350 devices
include a write record R(O), results differ depending on whether
the 3330/3340/3350 is dedicated (this includes a mini disk defined
Appendix F: V8/310 Restrictions
a 3330,
Ap.L.L.L
432.2
I,
1!f0 I
IBM VM/370 Planning and System Generation Guide
as the
entire
3330/3340/3350, a
that the track
3330/3340/3350 to
write record R(O)
flag is set on.
due to an invalid
10.
device)
or nondedicated.
For a
dedicated
write R(O) is allowed, but the user must be aware
descriptor record may not be valid from one
another.
For a nondedicated 3330/3340/3350, a
is replaced by a read record R(O) and the skip
This could result in a command reject condition
command sequence.
When performing DASD I/O, if the record field of a search ID
argument is zero when a virtual Start I/O is issued, but the search
ID argument is dynamically read by the channel program before the
search ID CCW is executed, then the real search ID uses. the
relocated search argument instead of the argument that was read
dynamically. To avoid this problem, the record field of a search
ID argument should not be set to binary zero if the search argument
1S ~o
be dynamically read or if a search ID on record 0 is not
intended.
Timing Dependencies
Timing dependencies in input/output devices
function consistently under VM/370:
1.
or
programming
do
not
The following telecommunication access methods (or the designated
option)
violate the restriction on timing dependency by using
program-controlled interrupt techniques and/or the restriction on
dynamically modified channel programs:
•
as Basic Telecommunications
dynamic buffering option.
•
as
•
DOS Queued Telecommunications Access Method (QT!M).
•
as
•
OS/VS Telecommunications Access Method
(TCAM)
earlier, and Level 5 if TCAM is not generated or
the VM/370 option.
Access
Method
(BTAM)
with
the
Queued Telecommunications Access Method (QTAM).
Telecommunications Access Method (TCAM).
Level 4 or
invoked with
These access methods may run in a virtual=real machine with CCW
translation suppressed by the SET NOTRANS ON command.
Even if SET
NOTRANS ON is issued, CCW translation will take place if one of the
following conditions is in effect:
•
The channel program is directed at a nondedicated device (such
as a spooled unit record device, a virtual CTC!, a minidisk, or
a console).
•
The channel program starts with a SENSE operation code.
•
The channel program is for a dialed terminal invoked by the DIAL
command.
•
START I/O tracing is in effect.
•
The CAW is
area.
in page zero or
beyond the end of
the virtual=real
Appendix F: VM/370 Restrictions
433
(OS BTAM can be generated without dynamic buffering, in which case
no virtual machine execution violations occur. However,
the BTAM
reset poll macro will not execute under VM/370 if issued from third
level storage. For example, a reset poll macro has a NOP effect if
executed from a virtual=virtual storage under VS1 which is running
under VM/370.)
2.
Programming that makes use of the PCI channel interrupt for channel
program modification or processor signalling must be written so
that processing can continue normally if the PCI is not recognized
until I/O completion or if the modifications performed are not
executed by the channel.
3.
Devices that expect a response to an interrupt within a fixed
period of time may not function correctly because of execution
delays caused by normal VM/370 system processing. An example of
such a device is the IBM 1419 Magnetic Character Reader.
4.
The
operation of
nAn~"n~~+_
virtual
are not
devices
Sensing
~nr
a virtual
thi~
re~~0~i
block multiplexer
th~
~hannel
channel is
timing
appears available
to the
machine operating system, and channel available interrupts
observed. However, operations on virtual block-multiplexing
should use the available features like Rotational Position
to enhance utilization of the real channels.
Processor Model-Dependent Functions
On the System/370 Model 158 only, the virtual machine assist feature
cannot operate concurrently with the 7070/7074 compatibility feature
(17117) •
Programs written for
execute properly in the
points should be noted:
processor model-dependent functions may not
virtual machine under VM/370.
The following
1.
Programs written to examine the machine logout area do not have
meaningful data since VM/370 does not reflect the machine logout
data to a virtual machine.
2.
Programs written to obtain processor identification (via the Store
CPUID instruction, STIDP) receive the real machine value.
When the
STIDP instruction is issued by a virtual machine, the version code
contains the value 255 in hexadecimal ("FF") to represent a virtual
machine.
3.
No simulation of other processor models is attempted by VK/370.
4.
Since an operating system's channel error recovery procedures may
be processor model- and channel model-dependent, operating systems
that will run in a virtual machine may have to be generated for the
same model of processor that VM/370 will be running on.
Channel Model-Dependent Functions
Channel checks (channel data check, channel control check and interface
control check)
no longer cause the virtual machine to be reset. They
are reflected to the virtual machine as other I/O errors are. This
provides the operating system or other programs in the virtual machine
with the opportunity to attempt recovery or close out its operation in
an orderly manner.
To take full advantage of this the virtual machine
should comply with the following requirement:
434
IBM VM/370 Planning and System Generation Guide
Each virtual channel should map to real channels of a single type.
In other words, the virtual devices on a virtual channel should all
map to real devices on real channels of a single type and model.
These real channels should all be the same as each other, but not
necessarily the same as the virtual channel.
If the I/O configuration of a virtual machine does not meet the above
requirement, no warning message is issued and the virtual machine will
run successfully until a channel check occurs.
In this case, when a
channel check occurs, there is a possibility that the channel extended
logout data may be inconsistent with the data provided by the store
channel id (STIDC) instruction.
Noi~~ Virtual
machines running CMS do not need to comply with these
requirements.
Here, only unit record spooling and diagnose 110 are
performed; For unit record spooling there are no channel checks and for
diagnose I/O, CP attempts to perform the error recovery itself.
When the store channel id instruction
(STIDC)
is executed in a
virtual machine, it returns information from an arbitrary channel, one
of several the specified virtual channel may map to.
The type, model,
and logout length data returned by the STIDC are the same as the real
channel except that when a real channel is a block multiplexer and the
virtual channel is a selector, the type field returned by STIDC
indicates a selector channel.
Since the STIDC returns identifying data from
channel model-dependent error recovery procedures
identify the channel.
the real channel,
can use STIDC to
Channel extended logouts are reflected to the virtual machine in a
manner that is processor modeland channel model-dependent and
consistent with the
data returned by STIDC
(provided that the
virtual-to-real channel mapping complies with the requirement stated
previously) .
A deviation in the handling of channel extended logouts occurs if the
virtual machine uses the bit in control register 14 to mask out channel
extended lcgcuts.
In a virtual machine, any channel extended logouts
that are masked out by control register 14 are lost rather than kept
pending, and the logout pending bit (bit 5) in the CSi is never set.
However, channel extended logouts will not be lost when they are kept
pending along with their associated 1/0 interrupts by the channel masks
in control register 2 and the PSi. Regardless of whether or not the
setting of the virtual machine's control register 14 causes it to lose
the channel extended logout, CP will still successfully record the
logout in its own error recording cylinders.
Virtual Machine Characteristics
other characteristics that exist for a
as follows:
1.
virtual machine under
V~/310
are
If the virtual=real option is selected for a virtual machine,
input/output operations specifying data transfer into or out of the
virtual machine's page zero, or into or out of storage locations
whose addresses are greater than the storage allocated by the
virtual=real option, must not occur.
The storage-protect-key
mechanism of the IBM System/370 proce~sor and channels operates in
Appendix F: VM/370 Restrictions
435
these situations but is unable to provide predictable protection to
other virtual machines.
In addition, violation of this restriction
may compromise the integrity of the system. The results are
unpredictable.
2.
A two-channel switch can be used between the IBM System/370 running
a virtual machine under VM/370 and another processor.
3.
The DIAGNOSE instruction cannot be issued by the virtual machine
for its normal function.
VM/370 uses this instruction to allow the
virtual machine to communicate system services requests.
The
Diagnose interface requires the operand storage addresses passed to
it to be real to the virtual machine issuing the DIAGNOSE
instruction. For more information about the DIAGNOSE instruction in
a virtual machine, see the !M/370 ~Y§te~ Progf~~~~ Guid~.
4.
A control unit normally never appears busy to a virtual machine.
An exception exists when a forward space file or backward space
file command is executed for a tape drive.
Subsequent I/O
operations to the same 7irtual cor.trol unit result in a control
unit busy condition until the forward space file or backward space
file command completes. If the real tape control unit is shared by
more than one virtual machine, a control unit busy condition is
reflected only to the virtual machine executing the forward space
file or backward space file command.
When a virtual machine
attempts an I/O operation to a device for which its real control
unit is busy,
the virtual machine is placed
in I/O wait
(nondispatchable) until the real control unit is available. If the
virtual machine executed a SIOF instruction (rather than SIO) and
was enabled for block-multiplexing, it is not placed in I/O wait
for the above condition.
5.
The CP IPL command cannot simulate self-modifying IPL sequences off
dedicated unit record devices
or certain self-modifying IPL
sequences off tape devices.
6.
The VM/370 spooling facilities do not support punch-feed-read,
stacker selection, or column binary operations.
Detection of
carriage control channels is supported for a virtual 3211 only.
7.
VM/370 does not support
operator's console.
8.
Programs that use the integrated emulators function only if the
real computing system has the appropriate compatibility feature.
VM/370 does not attempt simulation. The DOS emulator running under
OS or OS/VS is not supported under VM/370.
9.
The READ DIRECT and WRITE DIRECT instructions are not supported for
a virtual machine.
10.
The System/370 SET CLOCK instruction cannot be simulated and,
hence, is ignored if issued by a virtual machine. The System/370
STORE CLOCK instruction is a nonprivileged instruction and cannot
be trapped by VM/370; it provides the true TOD clock value from the
real processor.
11.
The 1050/1052 Model 2 Data Communication System is supported only
as a keyboard operator's console.
Card reading, paper tape I/O,
and other modes of operation are not recognized as unique, and
hence may not work properly.
This restriction applies only when
the 1050 system is used as a virtual machine operator's console.
It does not apply when the 1050 system is attached to a virtual
machine via a virtual 2701, 2702, or 2703 line.
436
count
control
on
IBM VM/370 Planning and System Generation Guide
the
virtual
1052
12.
The pseudo-timer
(usually device address OFF, device type TIMER)
does not return an interrupt from a start I/O; therefore, do not
use EXCP to read this device.
13.
A virtual machine device 1PL with the NOCLEAR option overlays one
page of virtual machine storage. The 1PL simulator uses one page
of the virtual machine to initiate the 1PL function. The starting
address of the overlaid page is either the result of the following
formula:
virtual machine size
-------------------- =
starting address of the overlayed page
2
or the hexadecimal value 20000, whichever is smaller.
14.
To maintain system integrity, data transfer sequences to and from a
virtual system console are limited to a maximum of 2032 bytes.
Channel programs containing data transfer sequences that violate
this restriction are terminated with an interrupt whose CSW status
indicates incorrect length and a channel program check.
1.
A data transfer sequence is defined as one or more read or
write CCws connected via chain data.
The introduction of
command chaining defines the start of a new data transfer
sequence. Data chain seek CCWs with counts of less than four
are inconsistent with data security of VM/370 and therefore
will give an inconsitent error.
2.
Data chained seek CCWs with counts of less than four are
inconsistent with the data security of VM/370 and therefore
will give an inconsistent error when attempting to use.
15.
When an I/O error occurs on a device, the System/370 hardware
maintains a contingent connection for that device until a SENSE
channel command is executed and sense data is recorded. That is, no
other I/O activity can occur on the device during this time. Under
VM/370, the contingent connection is maintained until the SENSE
command is executed, but 110 activity frOm other virtual machines
can begin on the device while the sense data is being reflected to
the virtual machine. Therefore, the user should be aware that on a
shared disk, the access mechanism may have moved during this time.
16.
The mode setting for 7-track tape devices is maintained by the
control unit.
Therefore, when a virtual machine issues the SET
MODE channel command to a 7-track tape device, it changes the mode
setting of all 7-track tape devices attached to that control unit.
This has no effect on virtual machines (such as OS or DOS) that
issue SET MODE each time a CCW string is to be executed.
However,
it can cause a problem if a virtual machine fails to issue a SET
MODE with each CCW string executed.
Another virtual machine may
change the mode setting for another device on the same control
unit, thereby changing the mode setting of all 7-track tape devices
attached to that control unit.
17.
OS/VS2 is supported in uniprocessor mode only.
1A •
A shared system or one that uses discontiquous saved segments
cannot be loaded (via IPL) into a virtual machine running in the
virtual=real area.
Appendix F: VM/370 Restrictions
437
1Q.
The DUMMY feature for VSAM data sets is not supported and should
not be used at program execution time. Specifying this option on
the DLBL command will cause an execution-time OPEN error
20.
The 3066 is supported as a 3215. It is not supported as a graphics
editor; therefore, it is recommended that the NODISP option of the
EDIT command be used when editing in a 3066.
21.
The Program Controlled Interruption
(PCI) FETCH option for
module retrieval is not supported for OS/MFT or VS1.
load
MSS Restrictions
1.
There are two os/vs system data sets associated with Mass Storage
System: The mass storage volume inventory and the mass storage
volume control journal. There is one copy of each data set per
Mass storage System, not necessarily one per opera ting system. If
more than one
oS/vs
syste~
~~nning
on either native
~o1~
or in a
virtual machine) is connected to a common Mass Storage System, then
the OS/VS systems must share a common inventory and journal.
2.
When a real 3330V device is dedicated to a virtual machine as a
virtual 3330V, the prbgramming support in the virtual machine must
recognize and access the virtual device as a 3330V.
3.
The following must be compatible; the definition of 3330V addresses
in the MCS tables; the DMKRIO module; and the IOGEN for any as/vs
system running in a virtual machine with a dedicated MSC port. The
reason for this, and the way to ensure it, is explained in the
!~L37Q ~y§!~}! g~.QgfM!me£~ ~yid~.
4.
Fach active volume in the MSS must have a unique volume number.
If
you wish to have two or more user volumes having the same volume
serial (such as different versions of an OS/VS2 system residence
volume both having a volume serial of VS2037), then create two MSS
volumes having different volume serials and allocate the user
volumes as minidisks.
5.
Mass Storage System volumes may not be used
paging, spooling, or temporary disk space.
6.
You must not change the volume of a real 3330V volume (the volume
serial as known by the MSC) except by using the OS/VS access method
services utilities.
If, for example, cylinder 0 of a 3330V is
dedicated to a virtual machine and that virtual machine alters the
volume serial using DDR, then the volume cannot be mounted.
for VM/370 residence,
eMS Restrictions
The following restrictions apply to CMS, the conversational subsystem of
VMI 37 0:
1.
438
eMS executes only on a virtual IBM System/370 provided by VM/370.
IBM VM/370 Planning and System Generation Guide
2.
The maximum sizes (in cylinders) of CMS minidisks are as follows:
~is~
2314/2319
3330 Model 1
3330 Model 11
3340 Model 35
3340 Model 70/3344
3350 Series
~A!i~gm £Ilinde~§
CM~S!~
203
246
492
349
682
115
200
404
808
349
698
555
3.
CMS employs the spooling facilities of VM/370 to perform unit
record I/O. However, a program running under CMS can issue its own
SIOs to attached dedicated unit record devices.
4.
Only those as and DOS facilities that are simulated by CMS can be
used to execute as and DOS programs produced by language processors
under eMS.
5.
Many types of object programs produced by CMS (and OS) languages
can be executed under eMS using CMS's simulation of as supervisory
functions.
Although supported in as and .DOS virtual machines under
VM/370, the writing and updating of non-VSAM OS data sets and DOS
files are not supported under eMS.
6.
CMS can read sequential and partitioned as data sets and sequential
DOS files, by simulating certain as macros.
The following restrictions
reside on as disks:
apply when CMS reads
as
data sets that
•
Read-password-protected data sets
VSAM data sets.
•
BDAM and ISAM data sets are not read.
•
Multivolume data sets are read as single-volume data sets.
End-of-volume is treated as end-of-file
and there is no
end-of-volume switching.
•
Keys in data sets with
read, except for VSAM.
•
User labels in user-labeled data sets are bypassed.
The following restrictions
reside on DOS disks:
are not read unless
keys are ignored
apply when
and only the
eMS reads
they are
data is
DOS files
that
•
Only DOS sequential files can be read. CMS options and operands
that do not apply to as sequential data sets (such as the MEMBER
and CONCAT options of FILEDEF and the PDS option of MOVEFILE)
also do not apply to DOS sequential files.
•
The following types of DOS files cannot be read:
--DOS DAM and ISAM files.
--Files with the input security indicator on.
--DOS files that contain more than 16 extents. 1!Qte: User
labels occupy the first extent; therefore, the file can hold
only 15 additional data extents.}
Appendix F: V8/370 Restrictions
439
7.
•
Multivolume
files
are
End-of-volume
is treated
end-of-volume switching.
•
User labels in user-labeled files are bypassed.
•
Since DOS files do not contain BLKSIZE, RECFM, or LRECL
parameters, these parameters must be specified via FILEDEF or
DCB parameters; otherwise, defaults of BLOCKSIZE=32760 and
RECF~=U are assigned. LRECL is not used for RECFM=U files.
•
CMS does not support the use of OS/VS DUMMY VSAM data sets at
program execution time, since the CMS/DOS implementation of the
DUMMY statement corresponds to
the DOS/VS implementation.
Specifying the DUMMY option with the DLBL command will cause an
execution-time error.
Assembler program usage
(lIP) is not supported.
read
as
of VSAM
as
single-volume
end-of-file.
There
and the
ISAM Interface
files.
is
no
Program
Miscellaneous Restrictions
1.
If you intend to run VM/370 Release 1 and pre-PLC 9 Release 2
systems alternately, apply Release 1 PLC 14 or higher (APAR Vl179)
to your Release 1 system, to provide compatibility and to prevent
loss of spool files in case of a warm start. Changes to the spool
file format in PLC 9 of Release 2 require a cold start when
switching between pre-Release 2 PLC 9 and post-Release 2 PLC 9
systems.
2.
The number of pages used for input/output must not exceed the total
number of user pages available in real storage. Violation of this
restriction causes the real computing system to be put into an
enabled wait state.
3.
If you intend to define more than 64 virtual devices for a single
virtual machine, be aware that any single request for free storage
in excess of 512 doublewords
(a full page) can cause an error
message to be issued if storage cannot be obtained.
Tables for
virtual devices for a virtual machine must reside in contiguous
storage. Therefore, two contiguous pages of free storage must be
available in order to log on a virtual machine with more than 64
virtual devices, (three contiguous pages for a virtual machine with
more than 128 virtual devices, etc.).
Contiguous pages of free
storage are sure to be available only immediately after IPL, before
other virtual machines have logged on.
Therefore, a virtual
machine with more than 64 devices should be the first to log on
after IPL. The larger the real machine size, the lesser the
possibility of this occurring.
4.
For remote 3270s,
VM/370 supports a maximum
of 16 binary
synchronous lines, minus the number of 3704/3705 Communications
Controllers in NCP mode minus one (if there are any 3704/3705
Communications Controllers in emulation mode).
5.
If an I/O device (such as a disk or tape drive) drops ready status
while it is processing virtual I/O activity, any virtual machine
users performing I/O on that device are unable to continue
processing or to log off.
Also, the LOGOFF and FORCE commands are
not effective because they do not complete until all outstanding
I/O is finished. The system operator should determine which IIO
device is involved and make that device ready once more.
440
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
6.
Any modifications to local OPTIONS COPIFILE, unless
specified in existing documentation, is not supported.
otherwise
7.
If an installation is using an IBM 3031, 3032, or 3033 processor,
it must dedicate the service record file (SRF) device to VK/370.
Thus, the channel on which the SRF is located cannot be dedicated
to any virtual machine.
8.
When using the SPOOL, DEDICATE, and SPECIAL directory control
statements to define virtual devices,
specify virtual addresses
that do not conflict or content with the virtual control unit
interface. This conflict or contention occurs because devices can
require special I/O interface protocol from control units such as
shared and nonshared subchannel operations. Putting devices that
require different real control units on the same virtual control
unit can result in a hung or busy condition.
To avoid this
problem, users must define (and separate) devices within their own
control unit range. For example, if the directory entry specifies:
SPOOL 102 3211
SPECIAL 103 3270
The control unit 0 on channel 1 controls both a nonshared device
(the 3211 printer) and a shared device (the 3270 display unit).
Processing of channel programs involving these two devices can
result in a hung or busy condition.
9.
The number of virtual devices for a virtual machine cannot exceed
the value determined by (7FFF/VDEVSIZE), where VDEVSIZE is the size
of the VDEVBLOK.
If a greater number of virtual devices is
specified, results may be undesirable.
10.
programs developed using CMS/DOS may not be transferable directly
to a DOS machine. The following considerations should be kept in
mind:
•
The CMS/DOS linkage editor is designed to linkedit DOS programs
for execution under eMS/DOS only. Programs transferred to a DOS
machine should be re-link edited under DOS.
•
Programs assembled using CMS assembler may have incorrect ESDs.
This is because the CMS assembler is not compatible with the DOS
assembler.
Programs transferred to
a DOS machine should
therefore be re-assembled under DOS.
Appendix F: VM/370 Restrictions
441
Ii
442
1:''''
.L.L
I,
1:7 0
I
IBM VM/370 Planning and System Generation Guide
Appendix G: A Sample EXEC Procedure for
Copying DOS/VS Macros into a CMS MACLI B
You may wish to create the following EXEC procedure, DOSMAC, which will
aid you in creating a DOS macro library under CMS.
No1~~
This procedure has not been formally
presented here for your convenience only.
tested
by IBM;
it
is
To execute the following EXEC procedure, you must be in CMS/DOS mode.
If a private source statement library is to be used, the appropriate
ACCESS, ASSGN, and DLBL commands must be issued, specifying the DOS/VS
disk on which that library resides.
The procedure creates a DSERV
listing on your CMS disk and uses the source statement directory listing
to create an EXEC file that issues a separate ESERV command for each
DOS/VS macro. You then can use the CMS Editor to delete all the ESERV
commands for macros you do not wish to move at this time. The procedure
then creates a CMS macro library with a MACLIB filename specified by
you. If you do not specify a filename, the default is DOSMAC.
!Q1e: If you have too many DOS/VS macros to move to your eMS disk, the
MACLIB build process may exceed one of the CMS file system limitations
and abnormally terminate.
All macros prior to the one that caused the
error message probably were cataloged correctly.
Reinvoke the EXEC
procedure and then use the CMS Editor to delete the ESERV commands for
all the macros previously cataloged. You must also specify some other
filename (such as DOSMAC2) for this new macro library.
Alternatively, if you want to avoid the abnormal termination of the
MAC LIB build process,
you may want to delete some or all of the ESERV
commands for the following DOS/VS macros the first time you invoke this
EXEC procedure:
BTMOD
CDMOD
DAMOD
DAMODV
FOPT
IOINTER
IOTAB
ISMOD
MCRAS
MTMOD
SDMODFI
SDMODFO
SDMODVO
SDMODVU
SDMODW
SGCCWT
SGEND
SGPMAIN
SGPSUB
SGSVC
COBBG
COBF2
!Q1~~
Check a DSERV listing and delete the ESERV commands for the
largest DOS macros first.
Then manually create a second set of ESERV
commands, specifying those macros not included in the first CMS MACLIB.
Appendix G: Sample EXEC Procedure for Copying DOS/VS Macros
443
Creating the DOSMAC EXEC Procedure
Issue the
EXEC:
following command
to create a
EXEC procedure
called DOSMAC
EDIT DOSMAC EXEC
Enter the INPUT subcommand to get into input mode and key in the
following lines.
No1~~ Do not key in the numbers along the left side of
the following example.
The numbers refer to notes of explanation that
follow the example.
&C ONT ROL OFF
&GENSWT = 0
CP PURGE RDR ALL
CP S~ 9
CLASS A
STYPE ENTER THE ADDRESS OF YOUR SYSRES VOLUME
&READ ARGS
*
P.T~
1.
2.
3.
~!YDEY
( DEFAULT = 350 )
EQ 0 ACCESS 350 Z
&IF &INDEX NE 0 ACCESS &1 Z
SET DOS ON Z (VSAM
&TYPE IF YOU WISH TO ASSGN AND DLBL A PRIVATE SOURCE STATEMNT LIBRARY
&TYPE NOW IS THE TIME ( ENTER YOUR ASSGN ). IF YOU DO NOT ENTER A NULL LI
&READ
&TYPE A DLBL IS ALSO REQUIRED FOR SSL
&READ
-MACGEN &CONTINUE
&TYPE ENTER THE NAME OF THE MACLIB TO BE CREATED THE DEFAULT IS DOSMAC
&READ ARGS
&IF tINDEX EQ 0 &LIB = DOSMAC
&IF &INDEX NE 0 &LIB = &1
CP SPOOL CONS START NOTERM
DSERV SD ( TERM
CP SPOOL CONS STOP TERM
CP CLOSE 9
READ $ESER EXEC
COPYFILE $ESER EXEC A $ESERV EXEC A ( LRECL 80 REPLACE
&BEGSTACK
DEL Q
F CP
DEL 5
TOP
C / /&1 &2/*
FILE
&END
EDIT $ESERV EXEC
ERASE $ESER EXEC
-STACKER &CONTINUE
&BEGTYPE
IF YOU WISH TO ALTER THE LIST OF MACROS NOW IS THE TIME TO DO SO
YOU MAY BYPASS ALTERATION BY ENTERING A NULL LINE
OR ELSE ENTER A NON-BLANK CHARACTER TO BEGIN ALTERATION
ALTERATION IS ACCOMPLISHED VIA EDIT'ING THE EXEC FILE CONTAINING THE KACR(
YOU MUST ISSUE THE EDIT SUBCOMMAND FILE TO RE-ENTER THIS EXEC AND CONTINUl
&END
&READ ARGS
&IF &INDEX NE 0 EDIT $ESERV EXEC
&CONTROL ALL
UUU
IBM VM/37Q Planning and System Generation Guide
4.
EXEC $ESERV SSTACK SPACE
ASSGN SYSIN A
ASSGN SYSLST PRINTER
ASSGN SYSPCH PUNCH
CP SPOOL D TO *
&CONTROL ALL
5.
6.
7.
8.
9.
-GETNEXT SCONTINUE
SREAD ARGS
&IF S2 NE E SGOTO -STAKTST
SSTACK LIFO FILE
SSTACK LIFO C 1$1 1 4
SSTACK LIFO TOP
&STACK LIFO I $DSPCH &3
EDIT &3 ESERV
EXEC ESERV &3
ERASE S3 ESERV
READ &3 MACRO
SSTACK LIFO FILE
SST ACK LIFO DEL
SST ACK LIFO BO
SSTACK LIFO DEL
SSTACK LIFO L ICATALS/
EDIT S3 MACRO
SIF &GENSWT NE 0 &GOTO -KACADD
SGENSWT = 1
MACLIB GEN SLIB S3
ERASE S3 MACRO
&GOTO -STAKTST
-MACADD &CONTINUE
MACLIB ADD SLIB &3
ERASE &3 MACRO
SIF &READFLAG EQ STACK &GOTO -GETNEXT
-FINALE &CONTINUE
&STACK QUIT
SBEGTYPE
THE MACLIB &LIB HAS BEEN CREATED AND THE FOLLOWING IS A MAP OF THE LIBRARY
SEND
&STACK MACLIB MAP &LIB ( TERM
&EXIT
-STAKTST &CONTINUE
&IF &READFLAG EQ STACK &GOTO -GETNEXT
&GOTO -FIN ALE
The following notes refer to the sample EXEC procedure shown above.
1.
The output of the DSERV command is
reader and is read in as $ESER EXEC.
spooled to your
virtual card
2.
The $ESER EXEC file is copied, edited, and formatted as a CMS EXEC
file.
All DSERV header and trailer lines are deleted.
3.
If you wish to delete any of the generated ESERV commands, enter
any nonblank character. If you do not wish to delete any ESERV
commands (or after you have deleted them), enter a null line.
4.
Stack the remaining lines of the $ESERV EXEC in the console stack.
5.
Read a line from the console stack and check that the first letter
begins with E (for ESERV). If not an E, ignore the line and read
the next one.
6.
If it is an E, create a DSPCH fn for this macro.
DSPLY may be substituted for DSPCH.
Note.;,. PUNCH or
Appendix G: Sample EXEC Procedure for Copying DOS/VS Macros
445
7.
Execute the ESERV command.
virtual card reader.
8.
Read the macro
statement.
9.
Add the macro to the indicated CMS macro library.
file
onto
The de-edited
the
CMS
macro is spooled to your
disk.
For a large macro library, the ESERV process may
length of time, up to several hours.
Delete
the
CATALS
take a substantial
For a detailed description of the ESERV command, refer to the VML31Q
CMS Command and Macro Reference. For more information on how to use the
ESERv--Command:
"Appendix D: Sample Terminal Session for DOS
Programs" in the !M/31Q ~MS Q~!:"!'§ Guid~.
-See-
For a detailed description of the DOS/VS ESERV control state~e~tE,
refer to the ~uide !Q th~ DO~L!~ Assembler, Order No. GC33-4024.
446
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 AS.Updated April 1, 1981 by TNL GN25-0831
Index
The entries in this Index are accumulative. They list additions
the following YH/310 System Control program products:
•
•
to this publication by
VM/310 Basic system Extensions, Program Number 5148-XX8
YM/310 system Extensions, Program Number 5148-XE1
However, the text within the publication is not accumulative; it relates only to the SCP
or program product that is installed on your system. Therefore, there may be topics and
references listed in this Index that are not contained in the body of this publication.
A
ABEND test, Installation 'erification
Procedure 265-266
ACCESS, command (CMS), use in file sharing
26
access
modes
defining for ainidisks 208-209
of CMS files 26
of CHS disks 25-26
Access Method Services
installing (514~-XX8)
273-276
installing (~748-XE1)
273-276
loading and savinq CMSAMS 271-216
requirements (2148-IX~)
273
requirements (2748-1]1)
273
storage requirements 92
update procedures 357-361
ACCOUNT, directory control statement
202-203
accountinq, number, defining in 'M/310
directory 202-203
ACCT option, defining in 'M/310 directory
204
ADAPTER operand, of RDEYICE macro 148
address
assigned to system residence volume
during system generation procedure
(5148-!X~)
236.1
assigned to system residence volume
during system generation procedure
(5148-X}:1)
236.1
assigning to sysres volume during system
generation 236
defining virtual device addresses for
RSCS 282
ADDRESS operand
of RCHANNEL macro 155
of RCTLUNIT macro 152
of RDEVICE macro 143
A-disk 21
advanced control program support feature
101
AFFINITY option, defining in 'M/310
directory 205-206
allocating
DASD space for the YM/370 directory 196
DASD space on CP-owned volumes 166
DASD space on CP-owned volumes
(5748-XX~)
165
DASD space on CP-owned volumes
(5748-XE1)
165
starter system volume
FB-512 devices (5748-11~)
254.1
FB-512 devices (~748-XE1)
254.1
the system residence volume 231
ALTCH operand, of RCTLUNIT macro 153
ALTCONS operand, of RIOGEN macro 156
ALTCU operand, of RDE'ICE macro 149
alternate blocks
FB-512 disks (2148-IX8)
100
FB-512 disks (~1!~-XE1)
100
alternate console, defining in RIOGEN macro
156
alternate control unit specification, real
I/O control block structure 68
alternate path support
brief description 45
features 68
in a Mass Storage System 68
logic 45
restrictions 18
alternate tracks
minidisks
98
system residence devices 99
AMS
(~-Access Method Services)
AP operand, of SYSCOR macro 174
APFZAP, using to replace IEHATLAS and
DMKMSS in program properties table 260
APL, support for text processing 118-119
ARNGEND EXEC procedure, invoking for
3104/4103 control program 298-300
ASMGEND EXEC procedure
generating the assembler 316
responses 316
when to use 410
ASM3105 command 303-304
files created by 304
assembler
building the 3705 assembler 299
for YM/310 401
optional tape for system generation 228
optional tape for system generation
(5148-XX~)
228.1
optional tape for system generation
(5148-XE..1)
228.1
use with eMS 22-23
using ASMGEND to generate 316
Index
447
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
assembling
the forms control buffer 245-246
the real I/O configuration file 246
the RSCS configuration table 363
the system control file (DMKSYS)
246
3704/3705 macros 303-304
attached processor system 85
entries in the load list 85
environment 7
modules 85
specifying at system generation 246-247
specifying at system generation
(.2148- !X!!>
246.1-247
specifying at system generation
(.2748-!~1)
246.1-247
support modules (574a-XX8)
101
support modules (57!~-lE1)
101
System/370 Extended Feature (57~~-X~)
8.1
usinq shared segments 81
~tiliz~tion
~easure~€nt
S
AUTO operand, SYSMON macro 178
AUX files
(~gg auxiliary files)
AUXBnO file (.2148-XX8)
328
auxiliary
control files, updating TM/370 328
directories, creating for the assembler
376
files
definition 334
identification records 334-335
storage, required by CMS 19-20
AUXRnO file 328
AUXSnO file (~148-XE11
328
available real storage, Formula 1 12
AXSLINKS COPY
creating 280,284
GENLINK macro 281
RSCS file
280,281
B
backing up
the newly generated VM/370 system
254-255
the newly generated VM/370 system
(.21~~-!X~)
254.1-255
the newly generated VM/370 system
(.21~.§-Xi;1)
254.1-255
BASEADD operand, of RDEVICE macro 149
Basic system Extensions Program Product
installation, an alternate method
(57~.§-!!~)
446-446.26
installation (.2148-11~)
227
service updates (57~~-lX8)
317
starter system, loading (574~-lX8)
236.1
batch facility
(§,g,g CMS Batch Facility)
blocks
FB-512
alternate (,274~-Xl~)
100
alternate (,2748-1~1)
100
BMX option, defining in VM/370 directory
204-205
BSEGEND EXEC procedure
format (~1~~-11~)
377
format (~1~~-XE1)
377
448
functioning (514~-XX8)
377-378
functioning (,274a-XE1)
377-378
generating a eMS module (~74a-!X8)
351-352
generating a CMS module (.274~-lE1)
351- 3 52
responses (.2148-1X8)
378-379
responses (.2148-1E1)
378-379
updating TM/370 (5748-!X8)
320
updating TM/370 (5748-!E1)
320
when to use (.214~-XX8)
370
when to use (.214~-1!1)
370
BUFFS operand, SYSMON macro 179
BUILD macro, 3704/3705 control program
300- 301
building
a new RSCS nucleus 363-364
disks needed 364
an RSCS system disk 363
VM/370 directory during system
g~heL~Llull
244-245
VM/370 directory during
generation (57!~-XXa)
TM/370 directory during
generation (514~-XE1)
3705 assembler 299
system
244
system
244
C
calculating
available real storage 12
DASD space
for saved systems (.2148-1!~)
17
for saved systems (.214a-!~1)
17
maximum size of virtual=real area 13
card
punch 28
punch (574~-!Xa)
28.1
punch (574~-!E1)
28.1
reader 28
reader (.214a-XXa)
28-28.1
reader (.21~~-!E1)
28-28.1
cardless system
changing named system modules (5748-X!§:
244
changing named system modules (.2148-1~1:
244
changing the printer buffer load
246-246.1
( 5748-XX~)
changing the printer buffer load
246-246.1
( 5748-XE1)
directory
copying (.2148-XX8)
242-242.1
copying (.214a-XE1)
242-242.1
creating (574~-XX8)
246-246.1
creating (.274~-XE1)
246-246.1
updating (574~-XX8)
246-246.1
updating (.214~-XE1)
246-246.1
required devices (5748-XX~)
103
required devices (574a-XE1)
103
service programs
accessing from tape (.2148-X!~)
242-242.1
accessing from tape (.2148-!~1)
242-242.1
preparing {514a-XXa}
242-242.1
preparing (.2148-1~)
242-242.1
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
242-242.1
required (~1~~-~1~)
242-242.1
required (~148-XE1)
virtual punch
246- 246.1
spoolinq (~148-11~)
246- 246.1
spoolinq (2748-1~1)
v irt ual reader
loadinq (~74~-XX~)
246
loading (~74~-1]1)
246
ccw translation, reserve/release 48.1-48.2
channel index table, generating 156
Channel Indirect Data Addressing feature
107
channel interface
Mass storage Control 72
positions for the Staging Adapter 72
channel model-dependent functions 434-435
channel model-dependent functions
(21~~-XX~)
434.1
channel model-dependent functions
(5748-XE1)
434.1
Channel switch feature, of alternate path
logic 68
channel sw itching 42-45
between two processors 43
for tape 44-45
on one processor 44
system generation requirements 43-44
CHAR operand, of RDEVICE macro 150
checkpoint cylinder, number of cylinders
required by device type 169-170
checkpoint start
data
calculating the number of cylinders
needed 169-170
DASD storage requirements 91
defining cy~inders for 169-170
CHTYPE operand, of RCHANNEL macro 155
CLASS operand
of GENLINK macro 281
of RDEVICE macro 146-147
182
of SYSACNT macro (5748-XX~)
182
of SYSACNT macro (57!~-XE1)
SYSMON macro 178
CLUSTER macro 135-136
CUTYPE operand 135
DIAL operand 136
examples 136
for 3270s 54
format 135-136
GPOLL operand 135-136
label 135
LINE operand 136
CLUSTER operand, of RDEVICE macro 149
CMS (Conversational Monitor System)
A-disk 21
auxiliary storage requirements 19-20
BSEGEND EXEC (~148-~X8)
351-352
BSEGEND EXEC (~148-XE1)
351-352
capacity of virtual disks 27
CMS Batch Facility
(see CMS Batch
Facility)
CMSSYS, obtaining write access 241
CMSXGEN EXEC procedure 356
command language 22-23
communication intents for CMS 22-23
compatibility with CP-67/CMS 415-429
creating disk-resident modules 351-352
default device addresses 20-21
devices supported 20
devices supported (5748-XX8)
20-20.1
devices supported (~748-XE1)
20-20.1
DIRECT command 198-199
disk and file management
CMS 25-26
OS/DOS 25
'SAM 25
disks
access 25-26
capacity 27
formatting 26
labels 26
linking 26
DOS/'S COBOL execution restrictions 24
ed iting files 29
executable program products 401-402
FB-512 blocks (~748-XX8)
26.1
FB-512 blocks (2748-XE1)
26.1
file directory (~748-XX8)
26.1
file directory (~748-!E1)
26.1
files
access modes 26
format 26
identification 27
maximum number 27
sharing 26
formatted disks volume label contents
(5748-XX8)
26.1
formatted disks volume label contents
(~748-XE1)
26.1
functions exercised by the ITP 263
generating a module 377-379
introduction 3
invoking the Directory program 197-198
libraries 21-22
limited support of OS and DOS 24
loading during system generation 240
macros, equivalent to CP-67/CMS macros
429
master file directory 26
messages issued while nucleus is being
generated 352-356
minidisk labels 100-101
minimum configurations 104
modules, when to regenerate 409-410
nucleus, when it must be regenerated
411
optional tape containing assembly
listings 228
optional tape containing assembly
listings (~748-XX8)
228.1
optional tape containing assembly
listings (5748-111)
228.1
OS/TS COBOL execution restrictions 23
partitioned data sets 21,24
planning considerations 19-30
PL/I execution restrictions 23-24
printing files 29
program languages available with CMS 23
punching card files 28
punching card files (5748-!X8)
28.1
punching card files (57~-XE1)
28.1
reading card files 28
records, maximum number per file 27
requirements to regenerate 409-411
Index
449
Page of GC20-1801-10 As Updated April 1, 1981 by TNt GN25-0837
resources required to generate 3704/3105
control program 297-298
restrictions 438-440
sample VM/370 directory entry 21
saving during system generation 258-259
saving the CMS system 30
sharing the system residence volume 40
source file identifier, DMSRnO CNTRt
328
support of Dt/I 25
symbolic names for devices 20
system disk 21
creatinq 350
user identification 235
system disk user identification
(5748-!!.§)
236
system disk user identification
(5148-!E1)
236
system libraries
macro 22
tex"t
22
tape support 21-28
text processinq 24
unit record support 21,28
unit record support (514]-XX8)
28.1
unit record support (2748-XE1)
28.1
updating
IPt sequence 352-356
loading new nucleus 352-356
saving CMSSEG 356
system support plan 324
updating procedures 256-258,349-361
usinq tape label processing (~748-XX8)
83-84
usinq tape label processinq (~748-X~1)
83- 84
verifyinq 263-266
virtual storage requirements 19
VMFDOS
creating CMS files (5748-XX8)
386.1-386.4
creating CMS files (5748-XE1)
386.1-386.4
VM/370 support of CP-67/CMS commands
421-429
CMS Batch Facility 29-30
adding routines 29
EXEC procedures for 30
VM/370 directory entries 29
CMSAMS segment
.
entry in DMKSNT
2314 starter system 211
3330 starter system 218
3340 starter system 218
3350 system 218
loading and saving 271-276
CMSBAM seqment
applying PTFs (2148-!1.§)
358
applying PTFs (2148-1]1)
358
entry in DMKSNT
FB-512 starter system (5148-1X8)
219
FB-512 starter system (514'§-X]1)
219
2314 starter system (~748-XX8) 211
2314 starter system (~148-!]1)
217
3330 starter system (~148-XX])
217-218
3330 starter system (~148-1]1)
217-218
450
3340 starter system (5148-X!~) 218
3340 starter system (5148-!!1) 218
3350 starter system (5148-!X8)
218-219
3350 starter system (5148-X]1)
218-219
installing (~148-XX8)
274-216
installing (2148-XE1)
274-216
updating (514~!X8) 215
updating (5148-1E1) 275
when to generate (5148-XX8)
35
when to generate (5748-XE1)
35
CMS/DOS
directory entries for 215
DOS/'S system generation considerations
35
DOS/'SE system generation considerations
(5148-XX~)
35-36
DOS/VSE system generation considerations
(5148-XE1)
35-36
pldhuluy COUS1Qera~10ns 35-37
standard label cylinder 36-37
standard label cylinder (5148-1X8)
31
standard label cylinder (5148-XE1) 31
storage requirements 92
tape handling 36
tape handling (5748-XX8)
37
tape handling (~148-XE1)
37
updating considerations 361
when DOS/TS system must be online 35-36
when DOS/TSE system must be online
(5748-XX~)
36
when DOS/TSE system must be online
(5748-XE1)
36
CMSDOS segment
entry in DMKSNT
2314 starter system 211
3330 starter system 218
3340 starter system 218
3350 system 219
loading and saving 276-277
system name table entry 277
CMSGEND EXEC procedure
access requirements 351-352
creating CMS disk-resident modules
351-352
format 377
functioning 377-378
generating a CMS module 377-379
responses 378-379
update procedure 320,351-352
when to use 410
CMSSEG seglllent
discontiguous saved segment
compatibility 352
special considerations 84
entry in DMKSNT
2314 starter system 217
3330 starter system 217
3340 starter system 218
3350 system 218
generating during system generation
258-259
generating during system generation
(5148-XX8)
258-258.1
generating during system generation
(5148-XE1)
258- 258.1
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
sugqested DMKSNT
FB-512 starter system (5748-XX8)
220.2
FB-512 starter system (574]-XE1)
220.2
2314 starter system <.~748-!!~) 220
2314 starter system (2748-XE1) 220
3330 starter system (12 748-XX.§)
220-220.1
3330 starter system ( 5748-XE1)
220-220.1
3340 starter system (2748-XX.§) 220.1
3340 starter system (~748-XE1) 220.1
3350 starter system (5748-XX8)
220.i-220.2
3350 starter system (~748-!E1)
220 .. 1-220 .. 2
updating CMS 356
CMSSYS
CMS system disk identification 235
CMS system disk identification
(5748-!X8)
236
CMS system disk identification
(57!.§-I~1)
236
CMSVSAM segment
entry in DMKSNT
2314 starter system 217
3330 starter system 218
3340 starter system 218
3350 system 218
installing (2748-XX8)
273-276
installing (2148-XE1)
273-276
loading and saving 271-276
requirements (2748-!X8)
273
requirements (2748-~E1)
273
CMSXGEN EXEC procedure 258-259
discontiguous saved segment 81,267
CMSXGEN EXEC procedure (2148-XX8)
258-258.1
CMSXGEN EXEC procedure (5748-XE1)
258-258.1
CMSZER segment
generating (274.§-XX~)
258.1-258.2
generating (274.§-~E1)
258.1-258.2
loading and saving (2748-XX8)
267
loading and saving (5748-XE1) 267
saving (21!.§-XX])
356-356.1
saving (2148-XE1)
356-356.1
special considerations (2748-XX8)
84- 84. 1
special considerations (2748-XE1)
84- 84.1
suggested DMKSNT
FB-512 starter system (5748-XX8)
220.2
FB-512 starter system 12148-!E1)
220.2
2314 starter system (2748-XX8) 220
2314 starter system (2748-XE1)
220
3330 starter system (2748-XX8)
220-220.1
3330 starter system (2748-XE1)
220-220.1
3340 starter system (~148-xx.§) 220.1
3340 starter system (~148-XE1) 220.1
3350 starter system (2148-!!.§)
220.1-220.2
3350 starter system (2748-!E1)
220.1-220.2
CMSZGEN EXEC procedure
discontiguous saved segment support
(5748-XX.!H
81
discontiguous saved segment support
(5748-XE1)
81
generating CMSZER segment (274~-!!~)
258.1-258.2
generating CMSZER segment (21!.§-XE1)
258.1-258.2
loading and saving discontiguous saved
segments (2748-XX8) 267
loading and saving discontiguous saved
seaments C5748-XE1} 267
saving CMSZER-C274~XX~) 356-356.1
saving CMSZER (2148-XE1)
356-356.1
COBOL (§~~ Full American National Standard
COBOL)
column binary 436
cOllmands
equivalent lM/370 and CP-67 commands
416-419
names, generating for IPCS 367
syntax, comparison of lM/370 and CP-67
416-419
communication facility
virtual machine
function 48.3-49
function (57!]-XX8)
48.4-49
function (574]-XE1) 48.4-49
compatibility, of lM/370 and CP-67/CMS
415-429
compilers, supported for CMS lSAM 32
conditional swapping feature (#1051) 107
confi gura tions
aid 405-408
macros for 3704/3705 301
other considerations for planning
126-127
remote spooling 123-125
supported by lM/370 103-127
table
assembling for RSCS 285,363
TCUs
Integrated Communications Attachment
122
3704/3705 required features 123
terminals, devices not supported 119
CONS operand, of RIOGEN macro 156
considerations for creating a new CMS
system disk 350
console
alternate, defining in RIOGEN macro 156
defining the real system console
156-157
those supported by TM/370 112-120
CONSOLE directory control statement
206- 207
control files
auxiliary file identification records
334-335
for RSCS 279
for system updates 319
Index
451
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
MACS record 334-335
supplied by IBM 327-329
AUXBnO (~748-1X8)
328
AUXRnO CNTRL 328
AUXSnO (~148-XE1)
328
DMKBnA (~l!~-XX~)
327
DMKBnO (~148-XX8)
327
DMKRnO CNTRL 327
DMKSnA (~148-XE1)
327
DMKSnO (~74§-XE1)
327
DMMBnO (~148-XX8)
328
DMMRnO CNTRL 328
DMMSnO (~148-~]1)
328
DMSBnO (~148-XX~)
328
DMSMnO CNTRL 328
DMSRnO CNTRL 328
DMSSnO (~148-~E1)
328
DMTRnO CNTRL 328
NCPRnO CNTRL 328
update identification records 334-335
update level identifier 334
control program (CP)
(see ~lso VM/370
(Virtual Machine Facility/370»
control program (CP) (~~~ CP (Control
program) )
control units
error messages for the RDETICE macro
150.1
magnetic tape control units supported by
VM/370 110
unit record control units supported by
VH/370 111
copying 3330-1 volumes to 3330' volumes 76
CORTABLE, defining in DMKSYS 173
count-key-data devices
characteristics (57!~-XX8)
90
characteristics (57!~-1~)
90
CMS block (~748-XX8)
26.1
CMS block (~748-XE1)
26.1
C~ (Control proqram)
checkpoint start data, DASD storage
requirements 91
commands equivalent to CP-67 commands
416- 419
compatibility with CP-67 415-429
DASD storage requirements 90-93
disk access 26
enabled wait state 436
error recording, DASD storage
requirements 91
free storage requirements 87
functions exercised by the ITP 263
introduct ion 3
load map 249
address 371-372
obtaining 249
minimum configurations 103-105
nucleus
DASD space requirements (~74~-XX~)
90.1-90.2
DASD space requirements (5748-XE1)
90.1-90.2
DASD storage requirements 90,91
DASD storage requirements (~748-!!~)
90- 90.1
DASD storage requirements C2748-XE1)
90-90.1
452
loading 247-248
loading nucleus with virtual=real
area 249
loading nucleus without virtual=real
area 248-249
reducing its size 89
optional tape containing assembly
listings 228
optional tape containing assembly
listings (~748-!X8)
228.1
optional tape containing assembly
listings (~146-XE1)
228.1
paging, DASD reqUirements 88
real control blocks storage requirements
87
real storage requirements 87-89
example 87
regeneration requirements 409-411
resident nucleus· storage requirements
87-88
restrictions 431-441
sa ved systems, DASD requirements 88
source file identifier, DMKRnO CNTRL
327
Special Message Facility 49
spooling, DASD requirements 88
trace table storage requirements 81
updating
building a new nucleus 345-341
during system generation 241-242
obtaining the load map 345-346
Program Update Tape 241-242
system support plan 324
TMSERT EXEC procedure 242,394-398
verifying 263-266
TM/370 directory, DASD storage
requirements 91
warm start data, DASD storage
requirements 91
CP assist, description 18
CPGEN
operator identification 235
operator identification {5748-!!~}
236
operator identification (5748-XE1) 236
CPN AM E operand
of NAMENCP macro 222
of NAME3800 macro 223
of RDEVICE macro 149
CPSIZE operand
of NAMENCP macro 222
of NAME3800 macro 223
CPT-TWX, sign-on procedure 314
CPTYP E operand
of NAMENCP macro 222
of RDETICE macro 148
CPUID option, defining in TM/370 directory
205
CP-61, commands equivalent in TM/370
416- 419
CP-61/CMS
compatibility with TM/370 415-429
macros equivalent in TM/370 429
'M/370 command support 421-429
CSB macro, 3704/3105 control program 301
CTCA, coding the RDETICE macro 144
IBM VM/310 Planning and System Generation Guide
T'\ _ _ _
ra.~~
of GC20-1801-10 As Updated ..! nr;
r----1 "
CUTYPE operand
of CLUSTER macro 135
of RCTLUNIT macro 152
coding for Integrated Printer Adapter
152
cylinder assiqnments, on 3340 devices 99
D
DASD (Direct Access Storage Device)
configuration aid for
407
control units supported by VM/370 108
CP nucleus
storage requirements (574S-!XS)
90- 90. 2
storage requirements (57~]-XE1)
90-90.2
error recording space requirements 88
restrictions 108-109
sharing 46-48
reserve/release support 47-48
s?ace
allocating for the VM/370 directory
196
allocating on FB-512 volumes
(.21~'§- !X~)
90
allocating on FB-512 volumes
(~1~~- X];l)
90
calculatinq fer saved systems
(57~'§-XX.!H
17
calculatinq for saved systems
(57~~- X];l)
17
formattinq for the YM/370 directory
196
needed by CMS 20
required by CP nucleus (5748-XX8)
90.1-90.2
required by CP nucleus (.21~.§-X]1)
90.1-90.2
reserving for 3704/3705 control
proqram imaqe 68
storage
for CMS minidisks 93
required by CP 90-93
required by CP nucleus 87
required for Access Method Services
92
required for CMS VSAM 92
required for CMS/DOS
92
supported by VM/370 108-109
SYSOWN macro, allocating on CP-owned
volumes
166
SYSRES macro
calculating cylinders for checkpoint
start data 170
calculating cylinders needed for warm
start data
170
DASD Dum? Restore (DDR) program
loading from the starter system tape
231-232
updating 369-370
usinq to
back u? the newly generated VM/370
254-255
back u? the newly generated lM/370
(57~~-!X~)
254.1-255
1981 by TNt GN25-0837
back up the newly generated VM/370
(.2748-X]1)
254.1-255
restore starter system to disk
231-232
DASTAP, data collection class 178-179
da ta buffer area
for FB-512 devices (57!.§-!X8)
432-433
for FB-512 devices (57!~-!El)
432-433
data collection, defining in SYSMON macro
177-179
data set compatibility, CMS and lSAM 32
data transfer
logical device facility (~748-X!.§)
48.3- 48.4
logical device facility (51~~-!El)
48.3- 48. 4
data transmission, paths, defining for RSCS
281-282
DDR program
(§~~ DASD Dump Restore (DDR)
program)
DEDICATE
directory control statement 211-213
example 212
defective tracks, handling for 2314/2319
disks 100
DEFINE, command (CP), use in file sharing
and access 26
defining minidisks
95-97,201-210
defining your system 129-224
introduction 131
device support
for starter system {574.§-!!~}
236.1
for starter system (57~~-XE1)
236.1
device type, virtual addresses 238
devices
addresses, changing for the loader 371
channel switching 42-45
coding the RDElICE macro
for system console 144
for unsupported devices 147
compatible with RSCS 413
configuration aid for
405-408
DASD supported by YM/370 108-109
default addresses for CMS 20
de fining
for starter system (~748-!!~)
236.1
for starter system (~748-!El)
236.1
for system generation 236
hardware, supported by CMS VSAM 31-32
linking at logon 213-214
magnetic tape supported by lM/310 110
making available during system
generation procedure 239-240
needed for system generation 227
processors supported by lM/370 106-107
real device types supported by VM/370
105
remote spooling devices supported by
VM/370
123
required for cardless system (.21~]-!X~)
103
required for cardless system (.2148-XE1)
103
sample configuration 158-159
simulated by programming 214-215
Index
453
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
subclass, defining for unsupported
devices 147
support for starter system 236
supported by CMS 20
supported by CMS (~748-11])
20-20.1
supported by CMS (~74.§-1]j)
20-20.1
terminals sUpported by TM/370 112-120
unit record devices supported by TM/370
111
unsupported devices dedicated to virtual
machines 126
DEVTYPE operand, of RDEVICE macro 143-144
DIAGNOSE instruction
invoking, logical device facility
(574'§-!~1)
48.3-48.4
invoking logical device facility
(57~.§-!X~)
48.3-48.4
restrictions 436
X'50', usage with SAVENCP command 312
DIAL operand, of CLUSTER macro 136
direct access storage device (~DASD
(Direct Access Storage Device»
DIRECT command 198-199
format 199
DIRECT operand
of GENERATE command 381
of GENERBSE command (5748-XX8)
381
of GENERSEP command (~748-XE1)
381
directory
(se~·al§Q VM/370 directory)
CMS file directory (~148-XX8)
26.1
CMS file directory (5748-XE1)
26.1
DIRECTORY, directory control statement 200
directory entry
example
maintenance virtual machine, hardware
187
operating systems in a virtual
machine, system dump 186
operating systems in a virtual
machine, VM/370 virtual machine 186
Directory program 197-215
ACCOUNT control statement 202-203
CONSOLE control statement 206-207
control statements 200-215
DEDICATE control statement 211-213
DIRECTORY control statement 200
invoking under CMS 197-198
IPL control statement 206
LINK control statement 213-214
MDISK control statement 207-210
OPTION control statement 203-206
running standalone 199
SPECIAL control statement 214-215
SPOOL control statement 210
updating 369-370
USER control statement 200-202
discontiguous saved segments 81-84
C MSS EG 258-259
associated overhead 84
compatibility 352
CMSSEG (~l~]-XX'§)
258-258.1
CMSSEG (2I~~-XE1) 258-258.1
CMSZER (~l~]-XX]) 84-84.1
CMSZER (21~~-XE1)
84-84.1
DMKSNT entry
CMSAMS, 2314 system 217
CMSAMS, 3330 system 218
CMSAMS, 3340 system 218
454
CMSAMS, 3350 system 218
CMSBAM, FB-512 system (~148-XX8)
21~
CMSBAM, FB-512 system (5748-XE1)
21~
CMSBAM, 2314 system (5748-!!~) 217
CMSBAM, 2314 system (5748-!El) 217
CMSBAM, 3330 system (~748-!!~)
217-218
CMSBAM, 3330 system ~748-!El)
217-218
CMSBAM, 3340 system (5748-!!.§) 218
CMSBAM, 3340 system (5748-!~1)
218
CMSBAM, 3350 system (5748-!X8)
218-219
CMSBAM, 3350 system (5748-!El)
218-219
CMSDOS, 2314 system 217
CMSDOS, 3330 system 218
CMSDOS, 3340 system 218
CMSDOS, 3350 system 219
?17
CMSSEG~ 2314 systBm
CMSSEG, 3330 system 217
CMSSEG, 3340 system 218
CMSSEG, 3350 system 218
CMS'SAM 2314 system 217
CMSTSAM 3330 system 218
CMSTSAM 3340 system 218
CMS'SAM 3350 system 218
INST'SAM, 2314 system 217
INSTTSAM, 3330 system 218
INSTTSAM, 3340 system 218
INSTTSAM, 3350 system 219
EXEC procedures 81,267
load addresses 267
loading and saving 267-270
CMSZGEN (~748-XX8)
267
CMSZGEN (~748-XE1)
267
procedure for 267
sample layout of storage 268
special considerations 82-83
for using the Editor 83
for using the EXEC processor 83
for using the OS simu la tion routi nes
83
usage requirements 82-83
disk-resident modules
CMS, creating 351-352
creating
BSEGEND EXEC procedure ~1~.§-!X8)
351-352
BSEGEND EXEC pLocedure (21~'§-!~)
351- 352
disks
(~~l§~-DASD (Direct Access
Storage Device»
CMS, access 25-26
formatting for CMS 26
labels, CMS 26
management
CMS 25-26
OS/DOS 25
TSAM 25
display devices, configuration aid for
405- 408
distribution code, defining in the 'M/370
directory 202-203
DL/I, support in CMS/DOS environment 25
DMKBnA CNTRL (2148-XX8)
327
DMKBnO CNTRL (~148-XX8)
327
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April
DMKCPI, function with two-or-four channel
switch 43
DMKDIR, Directory program, invoking under
CMS 198
DMKFCB C2~~ forms control buffer)
DMKFCB operand
of GENERATE command' 382-383
of GENERBSE command (574~-XX8)
382-383
of GENERSEP command (5748-XE1)
382-383
DMKMSS program, installing 260-261
DMKRIO
example of a VM/370 system 158-159
preparing for system generation 133-136
RCHANNEL macro 155
RCTLUNIT macro
151-154
RDEVICE macro 142-150
RIOGEN macro 156-157
sample file 161-162
sequence of macros 133
TERMINAL macro 137-141
3270, example assemble file 58
DKKRI 0 operand
of GENERATE command 381-382
of GENERBSE command (574]-XX8)
381-382
of GENERSEP command (5748-XE1)
381-382
DMKRnO CNTRL 327
DMKSnA CNTRL (2748-XEj)
327
DMKSNT (2eealso system name table)
NAMENCP macro 222
NAMESYS macro 220-221
NAME3800 macro 223
system name table, preparing 217-219
DMKSNT operand
of GENERATE command 382
of GENERBSE command (5748-XX])
382
of GENERSEP command (5748-XEj)
382
DMKSnO CNTRL (2748-XEj) 327
DMKSSP
starter system proqram 236
starter system program t2748-XX~) 236. 1
starter system program (2748-XEj) 236.1
DMKSYS
control file macro
performance considerations (5748-1X8)
165
performance considerations (5748-XE1)
165
performance considerations for coding
164-165
preparing the system control file
163-165
supplied with the starter system
163-164
SYSCOR macro 173-174
SYSJRL macro 180-181
SYSLOCS macro 182
SYSMON macro 177-179
SYSOPR macro 172
SYSOWN macro 166
SYSRES macro 168-171
SYSTIME macro 175-176
DKKSYS operand
of GENERATE command 382
of GENERBSE command (2748-XX])
382
of GENERSEP command (57!~-XE1)
382
1~
1981 by TNL GN25-0831
DMMBnO CNTRL (~148-XX8) 328
DMMRnO CNTRL 328
DMMSnO CNTRL (~148-1!1) 328
DMSBnO CNTRL (5748-1X8) 328
DMSMnO CNTRL 328
DMSRnO eNTRL 328
DMSSnO CNTRL (5748-1E1) 328
DMTLOC macro library 280
creating 285
DMTRnO CNTRL 328
DOS (Disk Operating System)
Initialize Disk utility program,
alternate tracks 100
initializing minidisks for 97
macro libraries for efts 22
programs, assembling 22
support under CMS 24
TPlFDOS
creating CMS files (5748-1X8)
38 6. 1- 386 • 4
creating CMS files (5748-1]1)
38 6. 1- 386 • 4
DOSGEN EXEC procedure
discontiguous saved segments 81,261
for loading and saving
CMSDOS 276-277
INST'SAM 269
DOSMAC EXEC
a sample EXEC for copying DOS/'S macros
into a CMS MACLIB 444-446
a sample EXEC 'for copying DOS/'SE macros
into a eMS MACLIB (514]-XX8) 444-446
a sample EXEC for copying DOS/'SE macros
into a CMS MACLIB (5748-XE1) 444-446
DOS/'S
COBOL, executing under eMS 24
macro libraries for CMS 22
sample EXEC, copying DOS/'S macros into
a CMS MACLIB 443
DOS/'SE
sample EXEC
copying DOS/'SE macros into a CMS
MAC1IB (2748-118; ~~~
copying DOS/'SE macros into a CMS
MACLIB (~748-XE1) 443
system generation considerations
(5148-XX~)
35-36
system generation considerations
(5748-XE1)
35-36
when system must be online (2148-XX~)
36
when system must be online (2148-XEj)
36
DPMSIZE operand, of RDE'ICE macro 150
dumps
analysis of, via IPCS 3
directory entry, example 186
routing 186
DUMPS CAN, generating command name for IPCS
367
DUMPT, using to print lists in system
program properties table 260
Dynamic Address Translation (DAT) Facility
415
dynamically modified program restrictions
431
Index
455
page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
E
ECMODE option, defining in VM/370 directory
203-204
editor 29
discontiguous saved segments, special
considerations 83
editing CMS files 29
Emula tion Proqr am (EP)
(s e,g al~ 3704/3705
con trol program)
Emulation program (EP)
291
how to code the RDEVICE macro 66
macro coding considerations 302
special considerations for loading
313-314
support under VM/370 294-295
emulators
DOS 436
integrated, restrictions 436
integrated emulators under lM/370 404
ENABLE operand, SYSMON macro 178
EnE?, updatEs O~ Lhe PUT 258
error recordinq
cylinders, defining 169
DASD storage reguirements 91
error recovery, for 3340 and 3344 disks 99
ESERV command, sample EXEC using to create
the DOSMAC EXEC 444-446
example
of CLUSTER macro 136
operatinq systems in a virtual machine,
system dump directory entry 186
remote 3270 addressing 141
TERMINAL macro 139
EXEC procedures
ASMGEND 376
BSEGEND (~148-~X8)
377-379
BSEGEND (~748-1]j)
377-379
CMSGEND 377
CMSXGEN 258- 259
258-258.1
CMSXGEN (~148-!X8)
258-258.1
CMSXGEN (2148-1]1)
258.1-258.2
CMSZGEN (~1~~-!1~)
258.1-258.2
CMSZGEN (~1~~-1]1)
DOSGEN
for loading and saving CMSDOS
276-277
for loading and saving INSTVSAM 269
format summaries 375-393
GENERATE 380-383
GENERBSE (~148-XX8)
380-383
380-383
GENERSEP (~74~-XE1)
384-384.2
PRELOAD (~148-~X8)
384-384.2
PRELOAD (~148-1]1)
used to regenerate CMS 409-410
VMSERV 394-398
VSAM GEN 2 71- 276,358- 36 1
EXEC processor, discontiguous saved
segments, special considerations 83
executing, SEBLD during system generation
procedure (~l~~-l]j)
239
expanded virtual machine assist 18
Extended Control-proqram Support 8-9,107
brief description 18
compatibility with System Extensions
(57~~-X]1)
8.1
extended floating-point feature 107
456
extents
CMS files per disk (574~-!X8)
CMS files per disk (574~-XE1)
external names, undefined 249
27
27
F
FB-512
allocating DASD space (5748-!!~)
allocating DASD space (5748-1]1)
alternate blocks for minidisks
(5748-XX~)
100
alternate blocks for minidisks
(5748-1]1)
100
CMS block (2748-IX8)
26.1
CMS block (~748-XE1)
26.1
DASD space requirements for CP
(5748-XX8)
90.1-90.2
DASD space requirements for CP
(~/q8-XE1)
90
90
90.1-90.2
DASD space requirements for CP nucleus
(5748-XXJH
80
DASD space requirements for CP nucleus
(5748-XE1)
80
disks (5748-!!~)
100
disks (574~-!]1)
100
format defective block procedure
(5748-XX.1H
100
format defective block procedure
(~748- XE1)'
100
minidisk space allocation (21~~-XX8)
97
minidisk space allocation (~74~-1]1)
97
restrictions (5748-XX8)
432-433
restrictions (5748-XE1)
432-433
FB-512 starter system
CMSBAM entry in system name table
(5748-XX~)
219
CMSBAM entry in system name table
(5748- XE1)
219
DMKSYS file supplied (~748-XX~)
164
DMKSYS file supplied (~748-1~1)
164
format of restored disk (5748-1X~)
236
format of restored disk (5748-X]1) 236
introduction (~148-XX8)
4
.
introduction (5748-XE1)
4
sample Format/Allocate entries
(5748-XX8)
230-231
sample Format/Allocate entries
(~748-XE1)
230-231
TM/370 directory supplied (57~~-XX8)
196-196.1
'"/370 directory supplied (21~~-XE1)
196-196.1
FB-512 starter system (574]-XX8)
227
FB-512 starter system (574~-XE1)
227
FCB operand, of RDE'ICE macro 150
FEATURE operand
of RCTLUNIT macro 153
of RDEYICE macro 145-146
of TERMINAL macro 139
features
processor
Channel Indirect Data Addressing 107
extended floating-point 107
floating-point 106
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
system timing facility 106
virtual machine assist 107
Word Buffer 107
RSCS 123
Two-channel switch 126
VM/VS Handshakinq 39-40
files
CMS
. editing 29
filemodes 26
maximum number of records 27
printing 29
punching 28
p'unc hing (5748- ~X8)
28.1
punching (5?~~-XE1)
28~'
reading 28
sharing 26
directory 26
management
CMS 25-26
OS/DOS 25
VSAM 25
files per disk limits (~74~-XX8)
27
files per disk limits (~74~-XE1)
27
floating-point feature 106
FORMAT
command (CMS)
usage 26
use in formatting operator's virtual
disk 255
format defective block procedure
FB-512 disks (~148-!X8)
100
FB-512 disks (~1~!!-!E1)
100
format of restored FB-512 disk (57~~-XX8)
236
format of restored FB-512 disk (57~~-XE1)
236
Format/Allocate program
loading from starter system tape
229-230
updating 369-370
usage with CMS minidisks 98
use in flagging defective tracks 100
formatting
CMS disks 26
the IPCS system disk 287
the RSCS system disk 283-284
the system residence volume 229-230
forms control buffer
assembling during system generation
245- 246
printing and punching the starter system
supplied copy 243
supplied with starter system 224
Formula 1 (calculating available real
storage)
12
Formula 2 (calculating maximum size of
virtual=real area)
13
FORT~AN IV, use with eMS
23
FREE operand, of SYSCOR macro 173
free storage, permanently allocated for CP
87
Full American National Standard COBOL
execution restrictions under CMS 23
use with CMS 23
G
general polling characters 135-136
figure 140
GENERATE
building RSCS nucleus 286
DIRECT operand 381
DKKFCB operand 382~383
DKKRIO operand 381-382
DKKSNT operand 382
DKKSYS operand 382
executing during system generation 246
format 380
IPLDECK operand 383
NUCLEUS op~rand 383
RSCS operand 382
SRlCPGK operand 383
update procedure 320
using
during system generation 242-243
to load CP nucleus 247
using to install RSCS 283
virtual addresses assumed during
processing 380
VM 370 operand 380-381
when to use 411
generating
a new loader 372-373
a new RSCS nucleus 363-364
assembling the configuration table
364
IPCS
applying updates from PUT 355
formatting the IPCS system disk 287
general information 287-288
RSCS
assembling the configuration table
285
building the RSCS nucleus 286
creating the COpy files that define
your RSCS system 284-285
creating the DMTLOC macro library
285
loading 286
3704/3705 control program 289-320
ARNGEND EXEC file 298-300
ASM370S command 303-304
assembling the 3705 source files 308
building the text library 307
building the 3705 assembler 299
coding the BUILD macro 300-301
coding the CSB ~acro 301
coding the macros 300
defining the macro and text libraries
302
GEN3705 command 305-306
GROUP macro 301
INSTEP EXEC file 298-300,365
link editing the 3705 text files
308-310
LKED command 308
loading it 311-312
loading the program from tape
298-300
logging on 297,314
physical and logical configuration
macros 301
Index
457
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0831
required macro libraries 299
required text libraries 299
SAVENCP command 311-312
saving it 310
setting up the CMS virtual machine
297-298
Stage 1 302-305
Stage 2 305-310
GENERBSE
DIRECT operand (5748-XX])
381
DMKFCB operand (574~-XX])
382-383
DMKRIO operand (5748-XX8)
381-382
DMKSNT operand (57~~-11~)
382
DMKSYS operand (574~-11])
382
executing during system generation
( 514 8- !X~ ) 2 4 6- 24 6 • 1
format (~1~~-11~) 380
IPLDECK operand (5148-1X8)
383
NUCLEUS operand (51!~-!X8)
383
RSCS operand (~748-!X8)
383
SRVCPGM operand (?748-XX8\
~A~
updatinq VM/370 (~74]-!X8)
320
using
during system generation (57!~-!!~)
242-243
to load CP nucleus (5748-!X8)
247
virtual addresses assumed during
processinq (5748-1!~)
380
VM310 operand (5748-!X8)
380-381
GENERSEP
DIRECT operand (5748-1]1)
381
DMKFCB operand (5748-XE1)
382-383
DMKRIO operand (574~-XE1)
381-382
DMKSNT operand (57!~-XE1)
382
DMKSYS operand (574~-XE1)
382
executing during system generation
(5748-XE1)
246-246.1
format (~1!~-XE1) 380
IPLDECK operand (51!~-lE1)
383
NUCLEUS operand (5148-XE1)
383
RSCS operand (~148-!]1)
383
SRVCPGM operand (~748-1~)
383
updating VM/370 (~74~-!]1)
320
using
during system generation (57~~-!~1)
242-243
to load CP nucleus (5748-!]1)
247
virtual addresses assumed during
processing (5748-XE1)
380
VM370 operand (~148-!]1)
380-381
GENLINE macro
format 282
LINE operand 282
GENLINK macro
CLASS operand 281
format 281
I D operand 281
KEEP operand 281
LINE operand 281
requirements for coding 281
TASK operand 281
TYPE operand 281
use with RSCS 42
GENTAGQ macro
format 282
NUM operand 282
458
GEN 3705 command
files created 306
3704/3105 control program 305-306
GEN3705 macro library 299
GPOLL operand, of CLUSTER macro 135-136
graphic devices, eliminating support for
89
GROUP, macro, 3104/3705 301
H
Handshaking feature, 'M/'S 39-40
hardware
local, 3270 support 60-62
Mass Storage System support 71-14.1
remote, supported configurations 52
support, virtual machines 184-185
hardware assist
(§~ also-virtual machine
assist)
h.~r1~arc
:;:,!:;::i::t
(§..§.§ - I:A.Lli::llU1"
example 209-210
Memo to Users
location on PUT 331
position on PUT 6
printing 242
messages
extraneous during system generation 229
issued while CMS nucleus is being
generated 352-356
PRELOAD utility program (57~]-XX8)
384.2
PRELOAD utility program {574~-XE1}
384.2
RCTLUNIT macro, channel errors 154
RDEVICE macro
control unit errors 150.1
un it r e c or d err 0 r s
1 50
minidisks
(~gg also virtual disks)
minidisks 95-102
access modes for sharing 102
allocating for VTOC 97
alternate tracks
2314/231 9 1 00
3330/3350 98
3340 98
£.V'-~IV
defective tracks, 2314/2319 100
de fining 95- 97
in YM/370 directory 207-210
in YM/370 directory, examples
209-210
primary access mode 208-209
defining and formatting for system
generation 240-241
error recovery support 99
example of use and definition 96
initializing, for os and DOS 97
la beling 100-101
linking to 101-102
MDISK control statement 101-102
on 3340 disks 99
on 3344 disks 99
overlapping extents 183
permanent 95
restrictions 432-433
sharing among virtual machines 101-102
sharing via passwords 101-102
te mporary 95
track characteristics 98
minimum
configurations
for CMS 104
for RSCS 104
for VM/370 103-105
miscellaneous restrictions 440-441
model
dependencies
restrictions (5748-!XS)
434-434.1
restrictions (574~-!!1)
434-434.1
MODEL operand
of RDETICE macro 145
of TERMINAL macro 138
models, 3704/3705 communications
cont rollers 66
modules
CP, address where loaded 372
generating a CMS module 377-379
generating a CMS module (~l~]-XX~)
351-352
generating a CMS module (574~-!!1)
351- 352
identifiers, updating TM/370 327
updating, IPCS 367
updating with VMFASM 384-386
updating with TMFASM (~74]-!X8)
384.3- 386
updating with VMFASM (~74S-!!1)
384.3-386
when to regenerate for CMS 409-410
MONI~OR command, using to control
collection of performance data 7
MSS (~ Mass Storage System)
multilevel updates 327
multiple, write access of minidisks 102
multiple service record files, 3033AP 127
multiple virtual machines, using the same
operating system 40
mUlti-write access of minidisks 102
MUSIC (McGill University System for
Interactive Computing)
403
Index
461
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
MVS/System Extensions Support
requirements (.2148-1~1)
18.1
System/370 Extended Facility, processors
supported (274~-XE1)
8.1
System/370 Extended Feature, processors
supported (274~-XE1)
8.1
N
named system, creating, for 3800 printing
subsystem 223
named system modules
changing for cardless system (2748-!X8)
244
changing for cardless system (.21~~-!~)
244
NAMENCP macro
CPNAME operand 222
CPSIZE operand 222
CPTYPE operand 222
format 222
SYSPGCT operand 222
SYSSTRT operand 222
SYSVOL operand 222
NAMENCP macro (.274~-XX~)
222.1
NAMENCP macro (.274§-X~1)
222.1
NAMESYS macro
format 220
PROTECT operand 221
RCVRID operand (.21~§-!X~)
222
RCVRID operand (5748-X~1)
222
SAVESEQ operand (5748-XX8)
222
SAVESEQ operand (.2748-X~1)
222
SYSBLOK operand (.2748-!X~)
221
SYSBLOK operand (5748-XE1)
221
SYSCYL operand 221
SYSHRSG operand 221
SYSNAME operand 220
SYSPGCT operand 221
SYSPGNM operand 221
SYSSIZE operand 220
SYSSTRT operand 221
SYSVOL operand 220
SYSVOL operand (274~-XX~)
220.5
SYSVOL operand (574§-X~1)
220.5
USERID operand (5748-XX])
221
USERID operand (.2748-XEj)
221
VSYSADR operand 220
VSYSRES operand 220
NAMESYS macro (.21~~-XX8)
220.4-222
NAMESYS macro (274~-XE1)
220.4-222
NAME3800 macro
CPNAME operand 223
CPSIZE operand 223
format 223
SYSPGCT operand 223
SYSSTRT operand 223
SYSVOL operand 223
NCPDUMP
source file identifier, NCPRnO 328
updatinq 369-370
NCPRnO CNTRL 328
NETWORK
LOAD command 312-313
execution of 313
462
nucleus
building with 'MSERT EXEC 331
CMS
building a new nucleus 349-361
loading 352-356
when it must be regenerated 411
CMS storage requirements 19
CP
DASD requirements 88
loading 247-248
real storage requirements 87-88
reducing its size 89
updating, building a new CP nucleus
345-347
updating, creating a backup copy 347
updating, obtaining load map 345-346
end of resident nucleus address 372
reducing the size for CP (5748-!X8)
90.1-90.2
reducing the size for CP (5748-XE1)
~HL1-90.2
RSCS
building 363-364
building the nucleus 286
generating 363-364
NUCLEUS operand
of GENERATE command 383
of GENERBSE command (5748-XX~)
383
of GENERSEP command (5748-!!1)
383
NUM operand, of GENTAGQ m~cro 282
numbers, of IBM program products 401-402
o
object modules, page boundaries 372
OBJ3705 text library 299
obtaining, MSS communicator program
260- 261
online message, logging on 3704/3705 lines
314
operating systems
performance guidelines 7-8
planning considerations 39-49
saving core-image copies on disk 79
sharing the system residence volume 40
that execute under TM/370 3-4
using reserve/release 46-48.3
virtual machine assist 17-18
operating systems in a virtual machine
example
hardware maintenance directory entry
187
system dump directory entry 186
TM/370 virtual machine directory
entry 186
operator, console, count control 436
operator directory entry, example 185
OPTION, directory control statement
203- 206
OS (Operating System)
initializing minidisks for 97
macro libraries for CMS 21-22
simulation routines, discontiguous saved
segments special considerations 83-84
support under CMS 24
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0831
output, spooling classes, defining with the
BDEVICE macro 146-147
OUTPUT operand
of SYSACNT macro (5148-XI~) 182
of SYSACNT macro (5148-XEj) 182
overlapping extents on minidisks 183
P
page boundaries, object modules 312
PAGE operand, of SYSOWN macro 161
page zero, restrictions 435-436
paging
DASD requirements
88
performance considerations 164
performance considerations (5148-XX~)
165
performance considerations (5148-XE1)
165
V~/VS Handshaking feature
39-40
partitioned data sets, C~S supported 21
password, use in sharing minidisks 101-102
password suppression facility, SYSJRL macro
181
PERFORM, data collection class 118-119
performance
data collection, SYSMON macro 111-119
Extended Control-program Support 8-9
Extended Control-Program Support
(.2ill-!l!j) 18-18.1
guidelines 1-8
for heavy I/O production 164
for heavy I/O production (5148-XX~)
165
for heavy I/O production ( 51.!H~-Xl!1)
165
for installation with large number of
CMS users 165
for installation with large number of
CMS users ( 5148-XX~) 165
for installation with large number of
ens users (5748~XE1) 165
for read-only minidisks 165
for read-only minidisks (~l~~-XX~)
165
for read-only minidisks (514~-XE1)
165
using automatic monitoring facilities
165
using automatic monitoring facilities
(.21~~-!X8)
165
using automatic monitoring facilities
(5148-XEjl
165
using fixed head devices for paging
165
using fixed head devices for paging
(51 ~.§- !!.§) 165
using fixed head devices for paging
(51!~-!l!1)
165
virtual machine assist 11-18
when coding the DMKSYS macros
164-165
measurement and analysis 7-8
measuring with MONITOB command 1
MiS/System Extensions Support,
processors supported (5148-XE1) 8.1
MTS/System Extensions Support (~148-!]1)
18.1
op tions 8-10
Small CP Option (5748-1X8) 84.2
virtual machine assist 8-9
virtual machine assist ~748-XE1) 8.1
performance guidelines
when coding the DMKSYS macros (5148-!!~)
165
when coding the DMKSYS macros (5148-!~1)
165
phase names, TSAM and Access Method
Services 357
physical record, CMS 26
planning considerations
CMS/DOS
standard label cylinder (.21!~-XX~)
.......
;'f
standard label cylinder (574~-XE1)
31
tape handling (5748-XX8) 37
tape handling (5748-XE1) 31
for a virtual=real machine 9-11
for Access Method Services 31-33
for CMS 19-30
for CMS lSAM 31-33
data set compatibility 32
distribution of TSAM and CMS 33
hardware devices supported 31-32
ISAM Interface Program (lIP) 32
languages supported 32
user requirements 33
for CMS/DOS 35-31
DOS/TS system generation 35
standard label cylinder 36-37
tape handling 36
when DOS/TS system must be online
35-36
for installing lSAM under CMS (5748-!!~)
33
for installing lSAM under CMS (5148-!~1)
33
for support of communication facility
48.3-49
for support of communication facility
(5748-XX~)
48.4-49
for support of communication facility
(5148-XEj) 48.4-49
for supporting 3104/3105 63-68
for supporting 3800 image library 69-10
for system generation 1
for the 3104/3105 control program
293-295
for 3210s 51-62
remote attachments 51-52
remote hardware configuration
supported 52
system generation requirements 53-58
operating systems other than CMS 39-49
reserve/release 46-48.3
BSCS 41-42
PL/I
execution restrictions under CMS 23-24
use with CMS 23
PBELOAD
utility program
MAP file (.2148-1X8) 384.1
MAP file (514.!!-XE 1) 384.1
Index
463
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
messaqes (5748-XX~)
384.2
messaqes (5748-XE1)
384.2
reformattinq text files (5748-!!~)
384-384.2
TEXT file (.2148-XX~)
384.1
TEXT file (.2148-X1;1)
384.1
utility proqram (274~-lE1)
384-384.2
printer buffer load
changing for cardless system (2148-!!~)
244.2
changing for cardless system (2148-!!1)
244.2
printing, files in CMS 29
PROB, generatinq command name for IPCS 367
problem analysis, via IPCS 3
processor
desirable features 107
model-dependent functions 434
required features 106-107
for RSCS 125
S"Ppo~tp~ by VM/3 7 0
105-107
program languages
supported by CMS 23
supported for CMS VSAM 32
program level change service updates, PUT
updates 331
Proqram Update Tape
(~ee PUT (Program
Update Tape»
proqrammable remote stations, required
features for RSCS 125
PROTECT operand, of NAMESYS macro 221
protection, discontiquous saved segments
267
PSUPRS operand, of SYSJRL macro 181
PTFs
applying to CMSBAM shared segment
(21~~- !!~)
358
applying to CMSBAM shared segment
(57.!!.§-XE1)
358
applying to VSAM shared segment
(57.!!~-XX.§)
358
applying to VSAM shared segment
(.2148-XE1)
358
nucleus regeneration requirements
409-411
PTFs ~rogram temporary fixes)
applying to the 3704/3705 control
program 315
applying to VM/370 319
PUNCH, command (CMS), usage 28
punch-feed-read 436
punching
card files in CMS 28
card files in CMS (5748-~X8)
28.1
card files in CMS (2748-~E1)
28.1
service programs durinq system
generation 242-243
the starter system supplied
forms control buffer 243
system control file
243
system name table 243
VM/370 directory 243
PUT (Program Update Tape)
applying CP service 241-242
completing the application of service
256-258
EREP updates 258
for system generation 5
464
general information 331
Memo to Users 5,331
mounting during system generation
obtaining RSCS 282-283
usage with update procedures 319
VMSERV EXEC 394-398
return codes 398
239
R
RCHANNEL macro
ADDRESS operand . 155
CHTYPE operand 155
example 155
format 155
RCHBLOK
(see ~!§Q·real control blocks)
creating 155
generated label 155
RCTLUNIT macro
aDDRESS operand
i5~
ALTCH operand 153
channel errors 154
configuration aid for 405-408
CUTYPE operand 152
example 153
FEATURE=xxx-DETICE operand 151
FEATURE operand 153
format 152
using to define alternate paths 45
RCUBLOK
(~~ ~!so-real control blocks)
addressing 151
creating 151
label generated 152
RCTRI D operand
of NAMESYS macro (.2748-XX8)
222
o~ NAMESYS macro (5748-XE1)
222
RDETBLOK
(~~·~lsQ-real control blocks)
creating 142-150
label generated 142
RDEVI CE macro
ADAPTER operand 148
ADDRESS operand 143
ALTCU operand 149
BASEADD operand 149
CHAR operand 150
CLASS operand 146-147
CLUSTER operand 149
coding
considerations for 3101 display
terminal 144
example 150
for system console 144
for the CTC! 144
for the EP 3704/3705 control program
66
for the ICA 144
for TWX terminals 148
for 3270s 54-56
summary of considerations for
3704/3705 control program 67
to support the 3704/3705 control
program 63-67
to support 3800 image library 69-70
configuration aid for 405-408
control unit error messages 150.1
CPNAME operand 149
CPTYPE operand 148
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNt GN25-0837
DEVTYPE operand 143-144
DPMSIZE operand 150
examples, 3704/3705 67
FCB operand 150
FEATURE operand 145-146
format 143
IMAGE operand 150
MODEL operand 145
output spooling classes, defining
146-147
SETADDR operand 148
subclass, defining for unsupported
devices 147
unit record error messages 150
using to define alternate paths 45
3704/3705 error messages 150.1
READ control statement, format of 245
READCARD, command (CMS), usage, usage 28
reader, card files in CMS 28
read-only, access of minidisks 102
read/write, access of minidisks 102
real control blocks
defining 133-136
real storage requirements 87
real control units
DASD control units supported by VM/370
108
magnetic tape control units supported by
VM/370 110
unit record control units supported by
VM/370 111
real devices
coding the RDEVICE macro
for the system console 144
for unsupported devices 147
configurinq 405-408
DASD supported by VM/370 108-109
dedicating to virtual machines 211-213
magnetic tape supported by VM/370 120
needed for system generation 227
processors supported by VM/370 106-107
remote spooling devices supported by
VM/370 123
sample configuration 161-162
supported by VM/370 105
supported only in virtual machines 126
terminals supported by lM/370 112-120
unit record devices supported by VM/370
111
real I/O configuration file
assembling during system generation 246
CLUSTER macro 135-136
coding for 3270s 134-135
coding sample 161-162
example of VM/370 system 158-159
preparing 133-136
RCHANNEL macro 164
RCTLUNIT macro 151-154
RDEVICE macro 142-150
RIOGEN macro 156-157
sequence of macros 133
TERMINAL macro 137-141
real I/O control block structure
for alternate channel specification 78
for alternate control unit specification
68,77
real stor age
calculating maximum size virtual=real
area 13
DASD requirements (~748-XX~)
10
requirements for CP 87-89
requirements for TM/370 87-93
REAtTIMER option, defining in lM/370
directory 203
records, maximum number per CMS file 27
reducing the size of the CP nucleus, lM/370
storage requirements 89
regenerating
CMS modules 409-410
service programs 411
remote attachments, 3270s, planning
considerations 51
remote hardware, supported configurations
3270s 52
remote spooling devices, supported by
lM/370 123
remote 3270s
control unit and device addressing 140
examples of addressing 141
requirements
for changing the TK/370 directory 198
for CP loadlists 390
RSCS, to run multiple concurrent RSCS
virtual machines 343
to regenerate CP and CMS 409-411
reserve/release
dynamic determination of support 43
handling reserve CCW 48.1-48.2
hardware support 43
restrictions 48.3
device sharing between real
processors 48.3
device/minidisk sharing 48.3
shared DASD 47-48
summary of support 48.2
using with operating systems 46-48.3
virtual machine simulation 46-48
resident nucleus, ending address 372
resource identification codes
for 3270s 56-57
sample list 59
recording at end of stage 1 305
restoring, starter system to disk 231-232
restr ictions
backward space file command 436
channel model-dependent (5748-!!~)
434.1
channel model-dependent (5748-!E1)
434.1
channel model-dependent functions
434-435
CMS 438-440
column binary 436
count control 436
CP 431-441
CP IPL command 436
DIAGNOSE instruction 436
DOS, emulator 436
dynamically modified proqram 431
forward space file command 436
integrated emulators 436
IPL command, with NOCLEAR option 437
Index
465
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
minidisk 432-433
miscellaneous 440-441
model dependencies (~748-XX8)
434-434.1
model dependencies (~748-XE1)
434-434.1
MSS 438
on FB-512 diagnostic commands (5148-!X8)
433
on FB-512 diagnostic commands (5148-XE1)
433
on use of DASD channel programs for
certain devices 432
on use of FB-512 devices (57~§-!X8)
432-433
on use of FB-512 devices (574.§-lE1)
432-433
on use of IBCDASDI 432
on use of IBCDASDI (574.§-XX8)
433
on use of IBCDASDI (~14.§-XE1)
433
on use of search arguments in performing
DASD I/O 432
pa ge zero 43,)- U 1fi
processor model-dependent functions
434
pseudo-timer 436
punch-feed-read 436
READ DIRECT and WRITE DIRECT 436
reserve/release
device sharing between real
processors 48.3
device/minidisk sharing 48.3
SET CLOCK command 436
stacker selection 436
STORE CLOCK command 436
timing dependency 433-434
two-channel switch 436
1050/1052 Model 2 Data Communication
System 436
8809 tape drives (~748-XX.§)
434
8809 tape drives (~748-XE1)
434
return codes, VMSERV EXEC 398
RIOGEN macro
ALTCONS operand 156
CONS operand 156
example 157
format 156
SRF operand 157
RMSIZE operand, of SYSCOR macro 173
RSCS (Remote Spooling Communications
Subsystem)
applying RSCS updates 283
assembling the configuration table
285,364
building a new nucleus 363-364
compatible devices 413
configuration table 280
creating the COpy files that define it
284-285
defining
all data transmission paths 281-282
an RSCS virtual machine 280
links 280
more than one RSCS virtual machine
41
the RSCS system 280
total number of tag slots 282
virtual device addresses 282
disks needed to build a new nucleus 364
example of use 41
general information 279
466
generating and installing 279-288,343
generating the macro library 280
generation procedure 282-288
assembling the configuration table
285
creating the DMTLOC macro library
285
defining your system 280
formatting the RSCS system disk
283-284
loading CMS 283
loading Rses 286
introduction 3
link, defining 281-282
minimum configuration 104
nucleus
building 286
generating 363-364
optional tape containing assembly
listings 228
pl~~~ing
cO~5ia~~ati0~£
41-42
processor required features 125
programmable terminals required featurel
125
required features 123
source file identifier, DMTRnO CNTRL
328
suggested system disk 283
system disk
copying line drivers to 364
copying supervisor files to 364
creating 363
updating 363-365
System support plan 324
using 'MSER' 283
virtual machine requirements 282-283
what you need before you generate RSCS
282
2770 required features 123-124
2780 required features 124
3110 required features 124
3780 required features 124
RSCS (Remote Spooling Communications
System)
optional tape containing assembly
listings (~748-IX8)
228.1
optional tape containing assembly
listings (~148-XE1)
228.1
RSCS operand
of GENERATE command 382
of GENERBSE command (5748-IX!)
383
of GENERSEP command (5748-XE1)
383
S
sample EXEC procedure for copying DOS/TS
macros into a CMS MlCLIB 443
sample EXEC procedure for copying DOS/VSE
macros into a CMS MlCLIB (2748-!!.§)
443
sample EXEC procedure for copying DOS/TSE
macros into a CMS MAC LIB (5748-!!1)
443
sa ved segments
discontiguous 81-84
CMSAMS 271-276
CMS DOS 276- 2 77
CMSSEG, associated overhead 84
CMSTSAM 271-276
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
CMSZER (~1.!H!-XX8)
84-84.1
CMSZER (5748-XE1)
84-84.1
INSTVSAM 269-270
load addresses 267
loading and saving 267-270
saved systems 79
calculating DASD space (~1!~-XE1)
17
CMS 30
CMSSEG 258-259
356
DASD requirements 88
defining 220-221
naming 220-221
saving CMS during system generation 259
3704/3705 control program ~10
SAVENCP command (CMS), 3704/3705 control
program 311-312
SAVESEQ operand
of NAMESYS macro (5748-XX~)
222
of NAMESYS macro (5748-.1].1)
222
SCRIPT/370 403
CMS text processinq 24
SELECT operand, of TERMINAL macro 138
service programs
cardless system
accessing from tape (~748-XX~)
242-242.1
accessing from tape (~148-XEj)
242-242.1
preparing (~148-1.l~)
242-242.1
preparing C2148-];].1)
242-242.1
Directory program 197-215
loader 371-373
generatinq 372-373
preparing during system generation
(~74~-XX~)
242-243
preparing during system generation
(5748-X~)
242-243
punching during system generation
242-243
updating 319-320,369-370
control files to use 369
EXEC procedures to use ~/V
when they must be regenerated 411
service record file, capability 126-127
service staging areas
defining 244
requirements (~148-!1§J
244.1-244.2
requirements (~148-XE1)
244.1-244.2
SET CLOCK command, restrictions 436
set page boundary (SPB) control cards 372
SETADDR operand, of RDEVICE macro 148
SETKEY command, CMS, usage with
discontiguous saved segments 267
shared DASD, reserve/release support 47-48
shared segments, in attached processor mode
81
Small CP option
invoking during system generation
(5748-!X~)
246.1
support modules deleted (574]-XX~)
84.2,246.1
Small CP Option (~148-!1~)
84.2
SMSG command, (C~ I use with 'MCF 49
software support, virtual machines 185
SPECIAL, directory control statement
214-215
special considerations
for loading the 3704/3705 control
program 313-314
for user with only one tape drive 245
Special Message Facility 49
SPOOL, directory control statement 210
spooling
accounting records
SYSACNT macro (5748-XX8)
182
SYSACNT macro (5748-XE1)
182
DASD requirements 88
defining virtual devices for 210
devices, supported by VM/370 111
output classes, defining with the
R DEVICE macro
146-147
performance considerations 164
performance considerations (~748-!!~)
165
performance considerations (5748-1]1)
165
SRF mode 126-127
SRF operand, of RIOGEN macro 157
SRVCP GM operand
of GENERATE command 383
of GENERBSE command (5748-!XE)
383
of GENERSEP command (~748-1]1)
383
stacker selection 436
Stage 1 generation procedure for 3704/3705
302-305
recording resource ID~ at end 305
special considerations ~or assembly 305
Stage 2 generation procedure for 3704/3705
305- 310
special considerations 380
Staging Adapter, channel interface
positions 72
standard label cylinder
CMS/DOS 36-37
restrictions 37
starter system volume
contents of restored disk 232
device support 236
FB=512
allocation for (5748-XX8)
254.1
allocation for (5748-XE1)
254.1
format after system generation 251
format of restored disks 232-235
IPL of 236
IPL of (574~-!X])
236.1
IPL of (~1~~-1~1)
236.1
labeling 231
starter systems
defining devices for (5748-!!~)
236.1
defining devices for (~748-!~1)
236.1
defining or attaching the system
residence volume 238-239
DMKSYS file supplied
printing and punching 243
printing and punching (5748-!!~)
236.1
printing and punching (5748-XE1)
236.1
forms control buffer supplied, printing
and punching 243
loading
Basic System Extensions Program
Product (574]-XX8)
236.1
CMS 240
Index
467
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN2S-0837
DASD Dump Restore program 231-232
Format/Allocate program 229-230
System Extensions Program Product
(~l~~-X]l)
236.1
making devices available 239-240
mounting system PUT 239
preparing
the starter system volume 231
the system residence volume 229-230
restoring to disk 231-232
setting the terminal mode 238
system generation procedure 229-261
system name table sUpplied, printing and
punching 243
VM/370 directory supplied, printing and
punching 243
STAT, generating command name for IPCS 367
storage
for each model of the 3704/370S 66
protection, for discontiguous saved
___ ""_ ......... _ "t:""'"
..,j.;.,;.;."1w.~"' ...
\"...::::l
~v
I
sample layout for discontiguous saved
segments 268
storage protection key assignment, VSAMGEN
27S
STORE command, CLOCK operand 436
STQUEBY operand, of SYSJRL macro 181
SUMMARY, generating command name for IPCS
367
summary, VMCF functions SO
support packages, for 3704/370S control
program 293-294
SVCOFF option, defining in VM/370 directory
204
symbolic names for CMS devices 20
SYSACNT macro
CLASS operand (S748-11~)
182
CLASS operand (~748-1]1)
182
LIMIT operand (S748-XX~)
182
LIMIT operand (~148-1]1)
182
OUTPUT operand (S7~~-11~)
182
OUTPUT operand (S74~-1]1)
182
spooling accountinq records (~74~-!!~)
182
spooling accountinq records (S7~~-!]1)
182
USERID operand (S7~~-11~)
182
USERID operand (S7~~-1]1)
182
S YSBLOK operand
of NAMESYS macro (274~-]1~)
221
of NAMESYS macro (S748-XE1)
221
SYSCKP operand
of SYSRES macro 169-170
of SYSRES macro (~1~~-11~)
170
of SYSRES macro (S7~~-lE1)
170
S YSCOR macro
APop er and 1 74
example 174
format 173
FREE operand 173
RMSIZE operand 173
TRACE operand 174
SYSCYL operand, of NAMESYS macro 221
SYSDUMP operand, of SYSOPR macro 172
SYSERR operand, of SYSRES macro 169
SYSHRSG operand, of NAMESYS macro 221
468
SYSJRL macro
format 180
JOURNAL operand 180
LNKLMT operand 181
LNKUID operand 181
LOGLMT operand 181
LOGUID operand 180
PSUPRS operand 181
STQUER Y operand 180
SY SLO CS macro
example 182
format 182
182.1
SYSLOCS macro (~l~~-XX~)
SISLOCS macro (~14~-XE1)
182.1
SYSMO N macro
AUTO operand 178
BUFFS operand 179
CL ASS operand 178
EN ABLE operand 178
example 179
format i 77
LIMIT operand 178-179
TIME operand 178
USERID operand 177
SYSNAME operand, of NAMESYS macro 220
SYSNUC operand, of SYSRES macro 169
SYSOP ER operand, of SYSOPR macro 172
SYSOPR macro
example 172
format 172
SYSDUMP operand 172
SYSOPER operand 172
SYSOWN macro
example 167
format 166
PAGE operand 167
TEMP operand 167
volid operand 167
SYSPGCT operand
of NAMENCP macro 222
of NAMESYS macro 221
of NAME3800 macro 223
SYSPGNM operand, of NAMESYS macro 221
SYSRES macro
example 171
format 168
special coding considerations 168
SYSCKP operand 169-170
SYSCKP operand (S748-XX~)
170
SYSCKP operand (S748-!~l)
170
SYSERR operand 169
SYSNUC operand 169
SYSRES operand 169
SYSTYPE operand 169
SYSVOL operand 169
SYSWRM operand 170
SYSWRM operand (~748-XX~)
170-170.1
SYSWRM operand (S748-!!l)
170-170.1
SISRES operand, of SYSRES macro 169
SYSSIZE operand, of NAMESYS macro 220
SYSSTRT operand
of NAMENCP macro 222
of NAMESYS macro 221
of NAME3800 macro 223
system
abnormal termination, testing with the
ITP 26S-266
timing facility 106
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
system console
coding the RDEVICE macro for 144
configuration aid for 405
defining 156-157
system control file
assembling during system generation 246
performance considerations 164-165
performance considerations (5748-XX8)
165
performance considerations (574~-XE1)
16'5
preparing 163-165
printing and punching the starter system
supplied copy 243
supplied with the starter system
163-164
SYSCOR macro 173-174
SYSLOCS macro 182
SYSOPR macro 172
SYSOWN macro 165
SYSOWN macro (2748-!1~)
165
SYSOWN macro (2148-.l~1)
165
SYSRES macro 168-171
SYSTIME macro 175-176
system control program (SCP)
(Eee alsQ
VM/370 (Virtual Machine Facility/370»)
system control program (SCP)
(g~ CP
(Control program»
system disk
CMS 21
creating for CMS 350
creating for RSCS 363
system dump directory entry, operating
systems in a virtual machine, example 186
System Extensions Program Product
installation (2148-X]J)
227
MVS/System Extensions support (2148-!E1)
18. 1
service updates (274~-1]J) 317
starter system, loading (574]-X~J)
236.1
system generation (§ee also VM/370
(Virtual Machine Facility/370»
system generation 225-288
assembling
the forms control buffer 245-246
the real I/O configuration file 246
the system control file (DMKSYS)
246
backing up the newly generated TM/370
254-255
basic tapes 228
building the VM/370 directory 244-245
building the VM/370 directory (5748-1X8)
244
building the VM/370 directory (2748-!]1)
244
changing printer buffer load 245
CMSZER segment
generating (~74]-!1.§)
258.1-258.2
qenerat inq (~748- .l~1)
258.1- 258.2
completing the application of service
256-258
considerations for DOS/VSE (5748-XX~)
35-36
considerations for DOS/'SE (57~~-XE1)
35-36
defining
a temporary minidisk 240-241
devices 236
devices, example 236-237
your system 129-224
defining devices for
example (274B-XX8)
236.1-236.2
example (274B-XE1)
236.1-236.2
DMKRIO, preparation 133-136
extraneous messages 229
formatting
a temporary minidisk 240-241
MAINT user's virtual disk 256
the operator's virtual disk 255
general information 228
GENERATE, executing 246
generating and installing RSCS 279-288
generating lM/370, GENERATE EXEC
380-383
GENERBSE, executing (5748-XX~)
246- 246.1
GENERSEP, executing (57~~-XE1)
246-246.1
including attached processor support
246-247
including attached processor support
(574~XX~)
246.1-247
including attached processor support
(5748-XEj)
246.1-247
including virtual=real machines 246-247
including virtual=real machines
(5748-XX~)
246.1-247
including virtual=real machines
(5748- XE1)
246. 1-247
introduction 4-6,131
invoking Small CP Option (5748-!!~)
246.1
loading and saving discontiguous saved
segments 267-277
messages received 236-237
messages received (5748-XX8)
236.1-236.2
messages received (~748=XE1)
236.1-236.2
nucleus regeneration requirements
409-411
optional tapes 228
optional tapes (574B-XX~) 228.1
optional tapes (5748-XE1) 228.1
options
to improve performance 8-10
virtual=real 9-17
planning considerations 4-6
planning information 1
preparing the service programs
(5748-XX~)
242-243
preparing the service programs
(5748-XE1)
242-243
printing Memo to Users 242
Program Update Tape (PUT)
241-242
pUblications to have available 5
punching the service programs 242-243
RDETICE macro, coding considerations for
3704/3705 66
reallocating the system residence volume
249
Index
469
Page of GC20-1801-10 As Updated April 1, 1981 by TN1 GN25-0837
requirements
for locally supported display systems
62
for remotely-attached display systems
53-58
to support channel switching between
two processors 43-44
to support channel switching on one
processor 44
RSCS installation, planning
considerations 41-42
service staging areas 244
setting t he terminal mode 238
special considerations for users with
only one tape drive 245
special procedure for generating a
virtual=real area 246-247
special procedure for generating a
virtual=real area (2748-XX~)
246.1-247
special procedure for generating a
virtl1dl=rf';'I1 ~.rP;::! (c:;7~~-!El)
246.1-2'!7
starter systems 4,229-261
storage allocation map information 237
storage allocation map supplied
{5748-!X!H
236.1
storage allocation map supplied
(21~~-X]1)
236.1
updating the control program 241-242
VMSERV EXEC procedure 394-398
volume format after system generation
251
3704/3705 requirements 63-68
3800 image libr~y requirements 69-70
system name table
creating an entry for 3704/3705 68
creating your version (2748-XX8)
220.3
creating your version (2148-XE1)
220.3
entry for saving CMS on a 2314 system
217
for saved systems 79
NAMENCP macro 222
NAMESYS macro 220-221
preparing 217-219
printing and punching the starter system
supplied copy 243
supplied with starter systems 217-219
system operator, defining in SYSOPR macro
172
system residence devices, alternate tracks
on 99
system residence volume
allocating 231
assigning address for system generation
procedure 236
assigning address for system generation
procedure (274'§-XX8)
236.1
assigning address for system generation
procedure (274'§-X!1)
236.1
backing it up 254-255
backing it up (2748-Xl~)
247
backing it up (2748-X]1)
247
defining or attaching for system
generation procedure 238-239
formatting 229-230
labeling 231
470
loading the newly qenerated TM/370 250
reallocating 249
sharing among the same operating system
40
system support
update plan 324
virtual machines 184-185
system text libraries, for CMS 22
System/370 Extended Facility
functions (2148-X]1)
18.1
processors supported (2748-XE1)
8.1
System/370 Extended Feature
attached processor restriction
(2748-XE1)
8.1
processors supported (a748-XE1)
8.1
System/370 Time of Day clock 237
SYSTIME macro
example 176
format 175
ID operand 176
T
n r- """.,....
" .,... .... rl
vl:'~""~ •• ""'"
_ v ""'"
'1"'\
1 .., c:
• I...J
ZONE operand 175
SYSTYPE operand, of SYSRES macro 169
SYSV01 operand
of NAMENCP macro 222
of NAMESYS macro 220
of NAMESYS macro (5748-XX8)
220.5
of NAMESYS macro (5748-XE1)
220.5
of NAME3800 macro 223
of SYSRES macro 169
SYSWRM operand
of SYSRES macro 170
of SYSRES macro (5748-!!~)
170-170.1
of SYSRES macro (5748-XE1)
170-170.1
T
tag slots
defining the total number 282
specifying the total number 282
TAGQUEUE COpy 282
creating 282,285
GENTAGQ macro 282
RSCS file 280
creating 282
tape
devices supported by YM/370 110
label process~ng
special considerations for using
(5748-!X8)
83- 84
special considerations for using
(5748- X£:1)
83- 84
tape map, produced by fMSERV 395
tapes
basic tapes for system generation 228
channel switching 44-45
CMS restrictions 27-28
configuration aid for 407-408
control units supported by fM/370 110
handling
CMS/DOS 36
CMS/DOS (2748-XX8)
37
CMS/DOS (2748-XE1)
37
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1# 1981 by TNL GN25-0837
loading 3704/3705 control program from
the distribution tape 298-300
optional tapes for system generation
228
optional tapes for system generation
(5748-!X!) 228.1
optional tapes for system generation
(5748-I~1)
228.1
special considerations for users with
only one tape drive 245
starter system
loading the DASD Dump Restore program
232
loading the Format/Allocate program
229-230
support for CMS 27-28
TASK operand~ of GENLINK macro 281
TCU
~ee transmission control units
(TCUs»
TDSKs, defining 95
TEMP operand, of SYSOWN macro 167
TERM operand, of TERMINAL macro 138
TERMINAL macro
codina 137-139
control unit and device addressing 140
examples 139
remote 3270 addressing 141
FEATURE operand 139
for 3270s 54
format 137
MODEL operand 138
SELECT operand 138
TERM operand 138
terminal mode, setting during system
generation procedure 23a
terminals
devices not supported 119
required features and special
considerations 113-120
supported as virtual system consoles
112-113
supported by VM/370 112-120
supported by 3104/3705 control program
under VM/370 291
system generation restrictions 112-120
3270s
required features 61
security and usability features
61-62
TEXT file
PRELOAD utility program (574~-!!~)
384.1
PRELOAD utility program (5748-XE1)
384.1
text files
reformatting
PRELOAD utility (~748-XX8)
384-384.2
PRELOAD utility program (5748-XEj)
384-30~.2
text libraries
CMS 22
defining for 3704/3705 system generation
302
OBJ3705 299
text processing under CMS 24
TIME operand, SYSMON macro 178
Time-of-Day (TOD) clock
defining in SYSTIME macro 175-176
setting 237
timing restrictions 433-434
TOD clock (§~~-Time-of-Day (TOD) clock)
TRACE operand, of SYSCOR macro 174
trace table, CP real storage requirements
87
tracks
alternate
for 3330/3350 98
for 3340 98
for 3340, cylinder assignments 99
characteristics for minidisks 98
transmission control units (TCUs)
configuration aid for 405-406
supported by TM/370 120-123
2702 required features 121
2703 features 121-122
3704/3705 features 123
TSO, macro libraries for CMS 22
Two-channel Switch feature 126
TWX terminals, coding the RDE'ICE macro
144,148
TYPE operand, of GENLINK macro 281
u
uniprocessor, system environment 7
unit record
control units supported by '"/370 111
devices
configuration aid for 405-408
support for CMS 21
supported by VM/370 111
error messages for the RDEVICE macro
150
support for CMS 28
support for CMS (5748-1X8) 28.1
support for CMS (5748-!E1) 28.1
unit record table, generating 156
unsupported devices i45
defining the subclass for 147
update
file identifiers, updating 'M/370 326
identification records 334
level identifier 334
procedures, for modules 319-320
UPDATE, update procedure 320
updating
a module 319-320
a 3800 named system 70
Access Method Services 357-361
CMS 349-361
disks required 349
modules, BSEGEND EXEC (5748-!X8~
377-379
modules, BSEGEND EXEC (5748-1]1)
377-379
modules, CMSGEND EXEC 377-379
punching the CMS nucleus 350-351
testing the CMS nucleus 350
CMS 'SAM 357-361
CMS/DOS 361
macro libraries, 'MFMAC 391-393
Index
471
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
modules with VMFASM 384-386
modules with VMFASM (5748-XX~)
384.3-386
modules with VMFASM (57~~-XEj)
384.3-386
system files, VM/370 327-329
the assembler 376
VM/370 317-393
auxiliary files 334-335
CMSGEND 320
control files 319
GENERATE 320
introduction 319-322
requirements to regenerate CP and CMS
409- 411
suggested virtual machine 323-324
system Program Update Tape (PUT)
319
the service programs 319-320
UPDATE command 320
VMFASM 320
vlU'LUAU
3LU
VMFMAC 320
when to regenerate the service
programs 411
USER
data collection class 178-179
directory control statement 200-202
user program area, CMS storage requirements
19
tJSERID operand
of NAMESYS macro (~748-XX~)
221
of NAMESYS macro (2748-1]2)
221
of SYSACNT macro (~1!~-X1~)
182
of SYSACNT macro (57!~-XEj)
182
SYSMON macro 177
v
verification procedure, starting the I'P
264-265
verifyinq CP and CMS 263-266
VIRT=REAL option, defining in TM/370
directory 204
virtual, system console, supported by
VM/370 112-113
virtual=real
area
creating (~148-X!~)
246. 1-247
creating (5748-XE1)
246. 1-247
specifying the size (2748-XX~)
246.1
specifying the size (2148-XE1)
246.1
calculating maximum size of area 13
examples 14-17
creating an area 246-247
determining the size of the virtual=real
area 11
external names undefined 249
function 9-10
generating CP to support 10
generation procedure 246-247
loading a CP nucleus that has an area
249
releasing the area 9
restrictions 9
specifying for a virtual machine 9-17
~72
specifying the size 247
system generation procedure (~148-!!~)
246.1-247
system generation procedure (~148-!~1)
246.1-247
use with multiport teleprocessing syster
10
virtual storage requirements 11
virtual addresses, for devices 238
virtual devices, addresses, defining for
RSCS 282
virtual disks
(§~·minidisks)
capacity under CMS 27
CMS, maximum number of files 27
defining in TM/370 directory 207
virtual interval timer assist, description
18
virtual machine assist 8-9,107
expanded 18
general information 17-18
restrictions 11
support 17-18
virtual machine assist (5748-!!1)
17-18.1
Virtual Machine Facility/370
(~~ VM/370
(Virtual Machine Facility/370»
virtual machines
automatic system loading at user logon
206
characteristics 435-436
48.3-49
communication facility ('MCF)
communication facility (TMCF) (~1!~- XX!!)
48.4- 49
communication facility ('MCF) (~148-X]1)
48.4-49
dedicating real devices to 211-213
defining 183-196
for use with RSCS 280
in the 'M/370 directory 200-202
spooling devices 210
the virtual console in the 'M/370
directory 206-207
example, RSCS 42
generation procedure for virtual=real
246-247
hardware support 184-185
linking devices at logon 213-214
maintenance, MAINT 333
naming systems 220-221
operating systems 3-4
saving copies of operating system 79
sharing minidisks 101-102
software support 185
system generation procedure for
virtual=real (~148-XX8)
246.1-247
system generation procedure for
virtual=real (~748-XE1)
246.1-247
system support 184-185
using reserve/release 46-48
VMSA'E option (~748-XX8)
206
'MSATE option (~748-XE1)
206
virtual punch
spooling for cardless system (~74~-XX!!)
246-246.1
spooling for cardless system (~148-X~1)
246-246.1
IBM VM/370 Planning and System Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
virtual reader
loading for cardless system (5748-!X~)
246
loading for cardless system (5748-1]j)
246
virtual storage, required by CMS 19
Virtual storage Access Method
(§~~ VSAM
(virtual storage Access Method»
VMCF (Virtual Machine Communication
Facility), summary of functions 50
VMFA SM
disk input files
385
disk output files 385
error messages 386
format 384
format (274~-XX~)
384.3
format (2?4~-1]1)
384~3
functions
385
printer output files
386
responses
386
update procedure 320
files used
335-336
updating source files 335-337
updating modules 319-320
updating VM/370 331
using to assemble RSCS configuration
table 364
using to update modules 384-386
using to update modules (57~]-!X8)
384.3- 386
using to update modules (57~~-X]j)
384.3-386
VMFDOS
creating CMS files (~148-XX~)
.386.1-386.4
creating CMS files (~1~~-1].1)
386.1-386.4
error messages (574~-XX])
386.4
error messages (~l~~-l]j)
386.4
examples (21.!!~-XX8)
386.2-386.3
examples C21.!!~-XE1)
386.2-386.3
format (~1~~-11~)
386.1
format (21.!!~-XE1)
386.1
usage notes (57.!!~-!X~)
386.3-386.4
usaqe notes (57 .!!~- XEj)
386.3- 386.4
VMFDUMP, generating command name for IPCS
367
VMFLOAD
disk input files
388
error messages 389
files used 387
format 387
functions
387-388
loadlists used
389
proqram
files used 341
punching the nucleus 340-343
requirements to use
340
restrictions 342
punch output files 388
responses
389
update procedure 320
updating VM/370 331
using to generate a new nucleus 387-390
VMFMAC
disk input files
392
disk output files 392
error messages 392
format 391
function 391-392
printer output files 392
responses 393
update procedure 320
r1Les used 337-336
updating macro libraries 337-340
updating macro libraries 391-393
VMFPLC2
blocking factor 331
updating VM/370 331
use in application of service 256
VMSAVE option
defining in TM/370 directory (~148-!!~)
206
defining in TM/370 directory (2748-X]1)
206
VMSERT
completing the application of service
256-258
EXEC procedure 394-398
how VMSERV works 395
initialization messages 395-396
return codes 398
service application messages 397-398
tape map 395
printing Memo to Users 242
usage with RSCS 283
use in applying CP service 242,394-398
using with Program Update Tape (PUT)
331
VM/SGP IUP 403
VM/VS Handshaking feature 39-40
VM/370 (Virtual Machine Facility/370)
(EP) Emulation Program support 294-295
assembler 401
channel switching 42-45
CMS support of CP-67/CMS commands
421- 429
commands equivalent to CP-67 commands
416-419
compatibility with CP-67/CMS 415-429
components of 3
DASD storage requirements for TM/370
directory 91
defining your system 129-224
direct access storage devices supported
108-109
Extended-Control Program support
(5748-XE1)
18-18.1
Installed User Programs (IUPs)
403
integrity, preserving during updating
333-334
introduction 3-6
to system generation 3-6
macros equivalent to CP-67/CMS macros
429
minimum configurations 103-105
operating systems that execute under
TM/370 3-4
paging, DASD requirements 88
real devices supported 105
real storage requirements 87-93
for CP
87-89
reducing size of the CP nucleus 89
recommended updating procedures 333-343
spooling, DASD requirements 88
devices supported 111
Index
473
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
support of 3704/3705 control program
294-295
system definition
forms control buffer load 224
real I/O configuration file 133-136
system control file
163-165
system name table 217-219
VM/370 directory 183-196
terminals supported 112-120
transmission control units supported
120-123
Two-channel switch feature 126
unsupported devices in virtual machines
126
update procedures 319-320
CMSGEND 320,351-352
CP example 335
deciding which procedure to use
319-322
GENERATE 320
UPDATE command 320
using VMFASM to update source files
335-337
using VMFLOAD to punch a new nucleus
340-343
using VMFMAC to update macro
libraries 337-340
VMFASM 320
VMFLOAD 320
VMFMAC 320
VMSERV 320
updating 317-393
accessing disks 326
auxiliary files 334-335
control files 319
files for system updates 327-329
module identifiers 327
multilevel updates 327
suggested virtual machine
configuration 323-324
system support plan 324
the service programs 319-320
update file identifiers 326
VSAM and Access Method Services
requirements 92
VM/370 directory
ACCT option 204
AFFINITY option 205-206
allocating DASD space for 196
BMX option 204-205
building
during system generation 244-245
durinq system generation (57~~-!X8)
244
during system generation (~148-!!1)
244
CMS Batch requirements 29
considerations for preparing entries
183-184
control statements for creating 200-215
CPUID option 205
DASD storage requirements 91
defining accounting number 202-203
defining distribution code 202-203
defining volume to contain 200
Directory program 197-215
ECMODE option 203-204
entries for CMS/DOS 215
474
example, a virtual machine for updating
'MSYS 186-187
formatting DASD space for 196
hardware support 184-185
ISAM option 204
MDISK statements 101-102
operator directory entry, example 185
other system virtual machines 186
printing and punching the starter system
supplied copy 243
REALTIMER option 203
requirements, for changing 198
RSCS requirements 41
sa mple entries
CMS 21
updating 2314 system 323
updating 3330 system 323
updating 3340 system 324
software support 185
supplied with FB-512 starter system
(5748-XX8)
196-196.1
supplied with FB-512 starter system
(5748-XE1)
196-196.1
starter system supplied 187-195
supplied with 2314 starter system
188-189
supplied with 3330 starter system
190-191
supplied with 3340 starter system
192-193
supplied with 3350 starter system
194-195
S'COFF option 204
system support virtual machines 184-185
VIRT=REAL option 204
VM 370 operand
GENERATE command 380-381
GENERBSE command (5748-XX8)
380-381
GENERSEP command (~748-XE1)
380-381
volid operand, of SYSOWN macro 167
volume label contents
CMS formatted disks (5148-XX8)
26.1
CMS formatted disks (5748-XE1)
26.1
Volume Table of Contents ('TOC), minidisk
allocation 97
'S APL, use withCMS 23
VSAM (Virtual Storage Access Method)
applying PTFs (~748-XX8)
358
applying PTFs (~748-XE1)
358
CMS support for DOS users 24
data set compatibility with CMS 32
distribution of 33
hardware devices supported 31-32
installing under CMS (~748-!X8)
33
installing under CMS (5148-IE1)
33
ISAM Interface Program 32
loading and saving CMSVSAM 271-276
programming languages supported 32
storage requirements 92
under CMS, update procedures 357-361
user requirements 33
VSAMGEN EXEC procedure
A-disk space required 271-272
applying updates from cards 359-360
applying updates from tape 360-361
discontiguous saved segments 81,267
error recovery 275
for loading and saving CMS'S!M and
IBM VM/370 Planning and system Generation Guide
Page of GC20-1801-10 As Updated April 1, 1981 by TNt GN25-0837
CMSAMS 271-276
OS application 273
storage protection key assignment 275
update considerations 357-358
updatinq Access Method Services 358-361
updating CMS VSAM 358-361
VSAMPP EXEC procedure
discontiguous saved segment support
(5748-!X~)
81
discontiguous saved segment support
(5748-X1H)
81
generating CMSBAM (57!~-~X8)
35
generating CMSBAM (~748-~E1)
35
loading and saving
Access Method Services (57!§-XX8)
275-276
Access Method Services
(57~~-XE1j
275-276
VSAM (~748-!X8)
275-276
VSAM (~748-1]1)
275-276
requirements (~748-1!~)
273
requirements (~748-1!1)
273
update considerations (~148-!X8)
357
update considerations (S748-XE1)
357
updating
access method services (~1~~-XX8)
357-358
access method services (574~-XE1)
357- 358
CMSBAM (2748-XX~)
357-358
CMSBAM (~I48-XE1)
357-358
CMS/VSAM (5748-!1~)
357-358
CMS/VSAM (~148-XE1)
357-358
VSYSADR operand, of NAMESYS macro 220
VSYSRES operand, of NAMESYS macro 220
VTOC
(§~~ Volume Table of Contents (VTOC))
w
wait state
CP enabled 436
loader 371
warm start data
calculatinq number of cylinders needed
170
DASD storage requirements 91
defining cylinders for 170
Word Buffer, processor feature 107
X
xxx-DEVICE feature of the RCTLONIT macro
151
Z
ZONE operand, of SYSTIME macro
175
1
1050, control units, models and features
114
2
2305
allocating DASD space for VM/370
directory 196
DASD space requirements for
checkpoint start data 90
CP nucleus 90
error recording 90
paging and spooling 90
saved systems 90
VM/370 directory 90
warm start data 90
DASD space requirements for CP
(5748-XX§)
90.2
DASD space requirements for CP
(5748-XE1)
90.2
DASD storage requirements for CP 90
supported models 108
2314
allocating DASD space for lM/370
directory 196
allocation of starter system volume 250
alternate tracks for minidisks 100
capacity for CMS minidisks 93
DASD space requirements for
checkpoint start data 90
CP nucleus 90
error recording 90
paging and spool~ng 90
saved systems 90
VM/370 directory 90
warm start data 90
DASD space requirements for CP
(5748-XX§)
90.2
DASD space requirements for CP
(5748-XE1)
90.2
DASD storage requirements for CP 90
format of restored disk 232
suggested virtual machine for updating
2314 system 323
supported models 108
2314 starter svstem
CMSAMS entry in system name table 217
CMSBAM entry in system name table
{5748-XX.§}
217
CMSBAM entry in system name table
(5748-XE1)
217
CMSDOS entry in system name table 217
CMSSEG entry in system name table 217
CMSlSAM entry in system name table 217
DMKSYS file supplied 163
forms control buffer supplied 224
INSTVSAM entry in system name table 217
introduction 4
system name table supplied 217
VM/370 directory supplied 188-189
2319
allocatinq DASD soace for VM/370
directory 196 alternate tracks for minidisks 100
DASD space requirements for CP
(5748-XX~)
90.2
DASD space requirements for CP
(5748- XE1)
90.2
supported models 108
2701, required features 120-121
2702, required features 121
2770, required features for RSCS 123-124
Index
475
Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
2780, required features for RSCS
2835, supported models 108
2844, supported models 108
124
3
3033, multiple service record files 127
3101
RDEVICE macro
coding considerations 144
specifying an adapter 148
required features 120,121,122
supported models 112
use with 3704/3705 controllers 291,314
3262
forms control buffer
alterinq (5748-!!~)
224
alterinq (5748-XE1)
224
RCTLUNIT macro
specifications (~1!.§-XX8)
408
specifications (574.§-1]1)
408
RDEVICE macro
specifications (~1!.§-lX8)
408
specifications (~148-1]1)
408
specifyinq DEVTYPE operand (~748-XX8)
144
specifying DEVTYPE operand (5748-XE1)
144
specifying MODEL operand (~l~'§-X!'§)
145
specifying MODEL operand (~148-!~1)
145
VM/370 unit record device (~148-XX8)
111
VM/370 unit record device (~148-XE1)
111
3270
coding CLUSTER macro 54
coding RDEVICE macro 54-56
coding TERMINAL macro 54
coding the real IIO configuration file134-135
components, control units, models and
features
114-118
determining line code 57
devices not supported by Text Feature
119
example of configuration 58
generation requirements for
locally-supported display systems 62
hardware configuration supported 52
local attachments 59-60
planning considerations 51-62
RDEVICE macro, coding considerations
146
remote
(~gg remote 3270s)
resource identification codes 56-57
sample list 59
support for local hardware
configurations 60-62
support for text processing 119
support on binary synchronous lines 52
system generation requirements 53-58
TERMINAL macro, control unit and device
addressinq 140
476
terminals
required features 61
security and usability feat ures
61-62
3271, coding real I/O configuration macros
for 134
3275, coding real I/O configuration macros
for 134
3310
capacity for CMS minidisks (57!.§-!!~)
93
capacity for eMS minidisks (5748-XE1)
93
3310 (see alsQFB-512) (5748-XX8)
3310 (~ alsQ FB-512) (5748-XE1)
3330
allocating DASD space for VM/370
directory 196
allocation of starter system volume 252
alternate tracks for minidisks 98
capacity for CMS minidisks 93
DASD space requirements for
checkpoint start data 90
CP nucleus
90
error recording 90
paging and spooling 90
saved systems 90
VM/370 directory 90
warm start data 90
DASD space requirements for CP
(5748-XX~)
90.2
DASD space requirements for CP
(5748-XE1)
90.2
DASD storage requirements for CP 90
format of restored disk 233
suggested virtual machine for updating
3330 system 323
supported models 108
3330 starter system
CMSAMS entry in system name table 218
CMSBAM entry in system name table
(5748-XX8)
217-218
CMSBAM entry in system name table
(5748-XEj)
217-218
CMSDOS entry in system name table 218
CMSSEG entry in system name table 217
CMSVSAM entry in system name table 218
DMKSYS file supplied 164
forms control buffer supplied 224
INSTVSAM entry in system name table 218
introduction 4
system name table supplied 217-218
VM/370 directory supplied 190-191
3330V volumes
coding RDEVICE macro for 76-78
copying 3330-1 volumes to 76
demounting 73
mounting 73
used as lM/370 system volumes 73
using for VS system residence 76
3330-1 volumes, copying to 3330' volumes
76
3333, supported models 108
3340
allocating DASD space for lM/370
directory 196
allocation of starter system volume 253
alternate tracks for minidisks 98
IBM VM/370 Planning and System Generation Guide
Page
-~
V.L
GC20~1801=10
capacity for CMS minidisks 93
cylinder assignments on 99
DASD space requirements for
checkpoint start data 90
CP nucleus 90
error recording 90
paging and spooling 90
saved systems 90
VM/370 directory 90
warm start data 90
DASD space reguirements for CP
C21~'§- XX.§ )
90 • 2
DASD space requirements for CP
(21~'§- X]l )
90 • 2
DASD storage requirements for CP 90
error recovery 99
format of restored disk 234
minidisks on 99
suggested virtual machine for updating
3340 system 324
supported models 108
3340 starter system
CMSAMS entry in system name table 218
CMSBAM entry in system name table
(27 4.§- XX.§)
218
CMSBAM entry in system name table
(57~'§-X!!1)
218
CMSDOS entry in system name table 218
CMSSEG entry in system name table 218
CMSVSAM entry in system name table 218
DMKSYS file supplied
164
forms control buffer supplied 224
INSTVSAM entry in system name table 218
introduct ion 4
system name table supplied 218
VM/370 directory supplied 192-193
3344
error recovery 99
minidisks on 99
3345, supported models 108
3350
allocating D~SD space for VM/370
directory 196
allocation of starter system volume 254
alternate tracks for minidisks 98
capacity for CMS minidisks 93
DASD space requirements for
checkpoint start data 90
CP nucleus
90
error recording 90
paging and spooling 90
saved systems 90
VM/370 directory 90
warm start data 90
DASD space requirements for CP
(57~.§- XX~)
90.2
DASD space requirements for CP
(21~'§- !!!11
90 .2
DASD storage requirements for CP 90
DMKSYS file that could be used with 3350
system 164
format of restored disk
235
supported models 108
3350 starter system
CMSAMS entry in system name table 218
CMSBAM entry in system name table
(2148-!X.§)
218-219
As
" ...... ...:1_ ..... ""...:1
ut'ua. .... 'Cu
1, 1981 by TNL GN25-0837
CMSBAM entry in system name table
(5748-XE1)
218-219
CMSDOS entry in system name table 219
CMSSEG entry in system name table 218
CMSlSAM entry in system name table 218
DMKSYS file supplied 164
INSTVSAM entry in system name table 219
introduction 4
system name table entries for 218-219
VM/370 directory supplied 194-195
3370
capacity for CMS minidisks (21~]-XX'§)
93
capacity for CMS minidisks (214B-XE1)
93
3370 (~ee al§Q FB-512) (5748-XX.§)
3370 (see al§Q FB-512) (5748-XE1)
3704/3705
coding considerations for RDEVICE macro
66
creating an entry in the system name
table 68
eliminating CP support for 89
error messages for the RDElICE macro
150.1
examples of RDElICE macro 67
features not supported 123
models supported 66
naming the control program 222
RDEVICE macro, summary of coding
considerations 67
reducing size of the CP nucleus 89
reserving DASD space for image of
control program 68
storage sizes 66
support packages
documentation supplied 293-294
machine readable material 294
supported models 123
3704/3705 control program
(EP) Emulation Program 293
applying program temporary fixes (PTFs)
315
generating 289-320
lM/370 to support it 63-68
generation procedure 297-315
ARNGEND EXEC file 298-300
ASM3705 command 303-304
assembling the 3705 source files 308
building the text library 307
building the 3705 assembler 299
coding the BUILD macro 300-301
coding the CSB macro 301
coding the macros 300
coding the RDElICE macro 63-67
defining the macro and text libraries
302
GENEND macro 302
GEN3705 command 305-306
GROUP macro 301
INSTEP EXEC file 298-300
link editing the 3705 text files
308-310
LKED command 308
loading 311-312
loading the program from tape
298-300
logging on 314
Index
477
Paqe of GC20-1801-10 As
U~dated
April 1, 1981 by TNL GN25-0837
logqinq on VM/370 297
physical and logical configuration
macros 301
recording the resource IDs 305
required macro libraries 299
required text library 299
SAVENCP command 311-312
saving it 310
special considerations for stage 1
assembly 305
staqe 1 302-305
Staqe 2 305-310
introduction 291
macros
assemblinq 303-304
BUILD 300-301
CSB 301
GENEND 302
GROUP 301
LINE 301
special coding considerations for EP
302
minimum storage required 291
NETWORK LOAD command 312-313
planning considerations 293-295
related publications 293
settinq up a CMS virtual machine
297-298
special considerations for loading the
EP 313-314
support under VM/370 294-295
478
terminals supported 291
3705 assembler
bu ilding 299
invoking 304
3767, features 120
3770, required features for RSCS 124
3780, required features for RSCS 124
3800
hardware supported 70
image library
coding the RDEVICE macro to support
69-70
generating VM/370 to support 69-70
named system
creating 70,223
updating 70
related publications 70
3830, supported models 108
3850
Mass Storage System (MSS\ 71-79
coding the RDETICE macro 76-78
copying 3330-1 volumes to 3330V
volumes 76
creating MSS volumes 75-76
defining the MSS communication device
74.1
mass storage control tables 74
'S1/VS2 central server virtual
machine 74
3851, Mass storage Facility 71
3880, supported models 108
IBM VM/370 Planning and System Generation Guide
-------- --- ------------_.-
Technical Newsletter
This Newsletter No.
Date
Base Publication No.
File No.
Prerequisite Newsletters!
Supplements
IBM Virtual Machine Facility/370:
Planning and System Generation Guide
© Copyright IBM Corp. 1972. 1973. 1974, 1975, 1976,
GN25-0837
April 1, 1981
GC20-1801-10
S370-34 (VM!370
Release 6 PLC 17)
GN25-0776
1977, 1979, 1980, 1981
This Technical Newsletter contains replacement pages for VML11~ £lann!~~
~en~iion Guide
to support Release 6 Ptc 17 of the IBM
g~g ~~~gm
virtual Machine Facility/370e
Before inserting any of the attached pages into the !M/370 Plann!~ ~n~
Guide read £are!ully the instructions on this cover.
They indicate when and how you should insert pages.
~Y§igm Gen~£gtio~
pages to
be Removed
Titi~Edition Notice
Preface iii-iv
contents vii-xiv
summary of Amendments xvii-xx
53-54
73-74
85-90
103-104
107-108
111-112.2
143-146
150.1-152
155-158
167-168
183-184
219-224
229-230
235-236
247-250
259- 260
269-270
329-330
337-338
349- 350
353-358
369- 372
375-380
385-386
401-"12
425- 426
431-432
441-442
Index 447-478
Reader's Comment Forms
Attached Pages
to be Inserted*
Title, Edition Notice
preface iii-iv
contents vii-xiv
Summary of Amendments xvii-xx
53-54
73-74.2
85-90.2
103-104
107-108
111-112.2
143-146
150.1-152
155-158
167-168
183-184
219-224
229-230
235-236
247-250
259-260
269-270.2
329-330
337-338
349-350
353-358.2
369-372.2
375-380
385- 386
401-412
425-426
431-432.2
441-442
Index 447-478
Reader's Comment Forms
*If you are
insertinq pages from different Newsletters/Supplements and
jdenticg! page numbers are involved,
always use the
pages with the
latest date (shown in the slug at the top of the page).
The page with
the latest date contains the most complete information.
IBM Corporation, Programming Publications, Department G60,
PO Box 6, Endicott, New York 13760
@
Copyright IBM Corp. 1981
Printed in U.S.A.
RSCS Generation Procedure
The AXSLINKS COPY file is a list of 1 to 64 GENLINK macro statements.
The GENLINK macro defines the attributes of a link.
The first GENLINK
macro in the AXSLINKS file must contain the ID of the local RSCS
station. You must also code the TYPE=driverid operand with a valid
filename on this first GENLINK macro.
You should code additional
GENLINK macros, with no operands, for links you may want to define
temporarily during an operating session.
The format of the GENLINK macro is:
,
r-----------------------------r
, GENLINK
,
, ID=linkid,TYPE=driverid[,CLASS=c]
,
i
[,KEEP=holdslot]
,
[ , LINE=vaddr]
I
[,TASK=taskname]
I L
J
L
ID=linkid is a 1- to 8-character alphameric location ID of the remote
location to be served by the link.
If this operand is not
specified, the ID defaults to "undefined."
TYPE=dri ver id
is a ens filename of a file which is the TEXT file for the
line driver program to be used to process files for the link.
The appropriate line driver program to be specified depends on
the type of remote telecommunications facilities to be used.
The TYPE operand must be specified if ID=linkid is coded.
oper-ana1s-om-tt-e-e-ct,- TYPE defaults to uund-efined".
If
----tn----e-T-Y-P~
CLASS=c
is the spooling class (es) of the files which can be processed
by the active link.
You can specify up to four spooling
classes (single alphameric characters from A to Z and 0 to 9)
with no intervening blanks, or *, which means all spool file
classes may be processed.
If the CLASS operand is not
specified r the default is "*~.
KEEP=holdslot
is a decimal number from 0 to 16 which designates the number
of virtual storage file tag slots to be reserved for exclusive
use by the link.
If the KEEP operand is omitted, a default
"holdslot" value of 2 is assumed.
LINE=vaddr
designates the
virtual device
address of
a permanent
telecommunications line port to be used for processing files
on th~ link.
If the LINE operand is omi~te~, the default is
"undefined".
TASK=taskname
is a 1- to 4-character alphameric identifier.
It specifies
the task name to be used by the line driver associated with
the link.
If the TASK operand is omitted, the default is
"undefined".
Part 3. Generating VM/370 (CP, eMS, RSCS, and IPCS)
281
Changes or additions to the text and illustrations are indicated
vertical line to the left of the change.
by a
Summary of Amendments
This Technical Newsletter
chan ges •
incorporates minor
]Qig: please file this cover letter at
provide a record of changes.
technical and
the back of the
editorial
publication to
------- --- ------------_.-
Technical Newsletter
This Newsletter No.
Date
Supplement No.
Base Publication No.
File No.
Prerequisite Newslettersl
Supplements
GN25-0776
March 3, 1980
GC20-1801-10
S370-34 (VM/370
Relea~e 6 PLC 9)
None
IBM Virtual Machine Facility/370:
Planning and System Generation Guide
©
Copyright IBM Corp. 1972,1973,1974,1975, 1976,1977,1979,1980
This Technical Newsletter contains replacement pages for !~JIQ flgBning
gnd Sys!~ ~~n~~g!ion Qui~g to support Release 6 PLe 9 of IBM Virtual
Machine Facility/370.
Before inserting any of the attached pages into the !~LJIQ f!g~iBg gnd
Sys1~! Q~~atiQn Gui~g, read £g~full~
the instructions on this cover.
They indicate when and how you should insert pages.
Pages to
be Removed
Title;-Edition Notice
Preface iii-vi
contents vii-xiv
Summary of Amendments xv-xviii
Attached Pages
to be Inserted*
Title,-Edition-Notice
Preface iii-vi
contents vii-xvi
Summary of Amendments xvii-xx
41-48
111-112
119-124
143-144
147- 150
153-154
209- 210
291-292
313-314
Index 447-478
41-48.4
111-112.2
119-124
143-144
147-150.2
153-154
209- 210
291- 292
313- 314
Index 447-478
*If you are inserting pages from different Newsletters/Supplements and
iden1d£gl page numbers are involved, always use the pages with the
latest date (shown in the slug at the top of the page). The page with
the latest date contains the most complete information.
Changes or additions to the text and illustrations are indicated
vertical line to the left of the change.
by a
Summary of Amendments
This Technical Newsletter incorporates changes
updated information in support of the following:
•
reflecting
new
and
IBM 3101 Display Terminal and miscellaneous maintenance updates.
Note: Please file this cover letter at
publica tion to pr ovide a record of changes.
the
back
of
the
base
IBM Corporation, Publications Development, Department 058, Building 706-2,
PO Box 390, Poughkeepsie, New York 12602
Printed in U.S.A.
IBM Virtual Machine Facility/370:
Planning and System Generation Guide
GC20-1801-10
READER'S
COMMENT
FORM
This manual is part of a library that serves as a reference source for systems analysts,
programmers, and operators of IBM systems. This form may be used to communicate
your views about this publication. They will be sent to the author's department for
whatever review and action, if any, is deemed appropriate. Comments may be written
in your own language; use of English is not required.
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.
IBM
Note: Copies of IBM publications are not stocked at the location to which this form is
addressed. Please direct any requests for copies of publications, or for assistance in using
your IBM system, to your IBM representative or to the IBM branch office serving your
locality.
Yes
No
D
D
D
D
D
Well illustrated?
o
D
D
D
Written for your technical level?
D
D
•
Does the publication meet your needs?
•
Did you find the materiai:
Easy to read and understand?
Organized for convenient use?
Complete?
•
What is your occupation?
•
How do you use this publication:
As an introduction to the subject?
For advanced knowledge of the subject?
To learn about operating procedures?
o
D
D
D
As an instructor in class?
As a student in class?
As a reference manual?
D
D
D
Your comments:
If you would like a reply, please supply your name and address on the reverse side of this
form.
Thank you for your cooperation. No postage stamp necessary if mailed in the U.S.A.
(Elsewhere, an IBM office or representative will be happy to forward your comments.)
GC20-1801·10
Reader's Comment Form
Fold and Tape
Please Do Not Staple
Fold and Tape
I
.................................................................................................................................................................. ·································1
111111
NO POSTAGE
NECESSARY
IF MAILED
IN THE
UNITED STATES
BUSINESS REPLY MAIL
FIRST CLASS
PERMIT NO. 40
ARMONK, N.Y.
POSTAGE WILL BE PAID BY ADDRESSEE:
I nternational Business Machines Corporation
Department G60
P. O. Box 6
Endicott, New York 13760
Fold
Fold
If you would like a reply, please print:
Your Name ___________- - - - - - - - - - - - - - - - - _
Company Name ________________ Department ______
Street Address _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
City ___________________________________________
State _ _ _ _ _ _ _ _ _ _ _ _ _ Zip Code _ _ _ _ _ __
--- .-----
IBM Branch Office serving you ___________________________________
- - - -------------_
...
®
International Business Machines Corporation
Data ProceSSing Division
1133 Westchester Avenue, White Plains, N. Y. 10604
IBM World Trade Americas/Far East Corporation
Town of Mount Pleasant, Route 9, North Tarrytown, N. Y., U. S. A. 10591
IBM World Trade Europe/Middle East/Africa Corporation
360 Hamilton Avenue, White Plains, N. Y., U. S. A. 10601
--ct:. =
;'::i:YM.
,,~=a_._ '
,
"
'
11
'JnternationaIB~ ~""'~n
f)a~ ftr0cesSin; Dh,risitln
1133 iNestchfiterAV6iiil6, \"'ite Prams, N.V: 106tM
U!M¥!erktT~'A",~~f.'£a.t: Ctlt'pcfatio~,
,'c,_,_
,:",'",' "
,
Town of Mount P....l'tt. Route 9. North Tanytown~ N.Y., U.s.A. 1059'
tBM World Trade Europe/Middie East/Africa Corpo,ration
360 H~mllton Avenue, White Plains, N.Y .• U.s.A. 1060t
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:01:04 16:56:53-08:00 Modify Date : 2009:09:09 16:10:48-07:00 Metadata Date : 2009:09:09 16:10:48-07:00 Producer : Adobe Acrobat 9.13 Paper Capture Plug-in Format : application/pdf Document ID : uuid:5df495c5-d2ff-4996-991c-2ce4ef1cde7c Instance ID : uuid:f2dfd1c5-d5ea-495d-b3f7-a72e152ab9b3 Page Layout : SinglePage Page Mode : UseOutlines Page Count : 522EXIF Metadata provided by EXIF.tools