--.------ ----------------.,-
Virtual Machine/
System Product
Planning Guide and
Reference
Release 3
Fourth Edition (September 1983)
This edition, SCI9-6201-3 is a major revision of SCI9-6201-2, and applies to Release 3
Virtual Machine/System Product (VM/SP), program number 5664-167, unless otherwise
indicated in new editions or Technical Newsletters. Changes are made periodically to the
information herein; before using this publication in connection with the operation of mM
systems, consult the latest IBM System/370 and 4300 Processors Bibliography,
GC20-0001, for the editions that are applicable and current.
Changes or additions to the text and examples are indicated by a vertical line to the left of
the change.
Summary of Changes
For a detailed list of changes, see page iii.
References in this publication to mM products, programs, or services do not imply that
mM intends to make these available in all countries where mM operates. Any reference
to an mM program product in this publication is not intended to state or imply that only
mM's program product may be used. Any functionally equivalent program may be used
instead.
Publications are not stocked at the address given below. Requests for mM publications
should be made to your mM representative or to the mM branch office serving your locality.
A form for reader's comments is supplied at the back of this publication. H the form has
been removed, comments may be addressed to mM Corporation, Programming Publications, Dept. G60, P.O. Box 6, Endicott, NY, U.S.A. 13760. mM may use or distribute
whatever information you supply in any way it believes appropriate without incurring any
obligation to you.
© Copyright International Business Machines Corporation 1980, 1981, 1982, 1983
Summary of Changes
Summary of Changes
for SC19-6201-3
for VM/SP Release 3
•
The title of this book used to be VM / SP: Planning and System Generation
Guide, SC19-6201. While the order number (SC19-620l) still applies, the title
has been changed to the VM/SP: Planning Guide and Reference. This title
change is the result of moving the following sections to the new VM/SP:
Installation Guide, SC24-5237:
"Part 3. Generating VM/SP (CP and CMS)"
"Part 4. Generating the 3704/3705 Control Program"
"Part 5. Updating VM/SP"
"Appendix C. CP/CMS Nucleus/Module Regeneration Requirements"
"Appendix F. A Sample EXEC Procedure for Copying VSE Macros into a
CMSMACLm"
"Appendix G. Generating VM/SP Without a VM/SP Starter System or the
Merged Product Tapes"
The list of DMKSYS, Directory, and DMKSNT files supplied with the
Product Tape
•
CMS now supports the 512-byte block size for minidisks.
•
The CMSSEG Saved Segment has been removed. Code from CMSSEG has
been incorporated into the CMS Nucleus.
•
The CMSXGEN Procedure that formerly generated CMSSEG has been
deleted.
•
The Small CP option has been updated to remove support modules for the
3066,3800 printers, and the Missing Interrupt Handler.
•
The VSE/VSAM macros and their options and a subset of the OS/VSAM
macros are now supported for use in CMS.
•
Support has been added for the following hardware devices:
The mM 3088 Multisystem Communication Unit interconnects multiple
systems using block multiplexer channels. The 3088 uses an unshared subchannel for each unique address and is fully compatible with existing channel-to-channel adapter protocol.
The mM 3262 printer Model 5.
The mM 3430 Tape Unit and Control.
The mM 3800 printer Models 3 and 8.
Summary of Changes
iii
The IBM 4245 Printer.
The IBM 4250 Printer.
•
iv
VM/SJ;' Planning Guide and Reference
GAM/SP Release 2 is now supported under VM/SP. This support is provided
for High Function Graphics Devices (HFGD).
Preface
This publication is intended for system programmers and those responsible for
planning a VM/SP system.
You should have a general understanding of data processing methods and be familiar with teleprocessing techniques.
This publication has two parts, plus appendixes.
"Part 1. Planning for System Generation" describes the components, features, and
options of VM/SP, and tells you what you must do during system generation to
support them. Part 1 includes information about CMS 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, attached processor and
multiprocessor systems, storage requirements, and minidisks; Part 1 also lists the
devices supported by VM/SP.
"Part 2. Defining Your VM/SP System" tells you how to create the files that
define your system; the real I/O configuration (DMKRIO), CP system control
(DMKSYS), VM/SP directory (DMKDIR), system name table (DMKSNT), forms
control buffer load (DMKFCB) files, and the macros and control statements
needed to create them.
The appendixes include information about:
•
Licensed Programs and Integrated Emulators
•
Configuring VM/SP
•
Compatible devices
•
VM/SP restrictions
Preface
v
In this publication, the following terms have extended meanings:
•
The term "3330 series" refers to the IBM 3330 Disk Storage Models 1,2, and
11; and the IBM 3333 Disk Storage and Control, Models 1 and 11.
•
The term "2305 series" refers to the IBM 2305 Disk Storage, Models 1 and 2.
I.
vi
The term "3262" refers to the IBM 3262 Printer, Models 1, 3, 5, 11, and 13.
•
The term "3289-4" refers to the IBM 3289, Model 4 Printer.
•
The term "3340 series" refers to the IBM 3340 Disk Storage, Models A2, Bl
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 "3375" refers to the IBM 3375 Direct Access Storage Device.
•
The term "3380" refers to the IBM 3380 Direct Access Storage Device.
•
The term "FB-512" refers to the Fixed Block Architecture of the IBM 3310
and 3370 Direct Access Storage Devices.
•
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/SP supported
virtual machine display consoles unless otherwise noted. A specific device type
is used only when a distinction is requ~ed between device types.
•
Information about display terminal use 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
the IBM 3287, 3288, and 3289 printers, 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, Modell or 2, operating 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/SP 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. The equivalent key on the 1050
terminal is the RESET LINE key; on the 3276, 3277, 3278, and 3279
terminal, the Enter key. Each of the terminals that can be used with the
VM/SP system has a key that is the equivalent of the Attention key on the
2741 (with which you can signal an attention interrupt).
VM/SP Planning Guide and Reference
•
Unless otherwise noted, the term VSE refers to the combination of the
DOS/VSE system control program and the VSE/ Advanced Functions program
product.
In certain cases, the term DOS is still used as a generic term. For example, disk
packs prepared for use with VSE or any predecessor DOS or DOS/VS system
may be referred to as DOS disks.
The DOS-like simulation environment provided under the eMS component of
the VM/System Product continues to be referred to as eMS/DOS.
•
eMS/DOS is part of the eMS system and is not a separate system. The term
"eMS/DOS" is used in this publication as a concise way of stating that the
VSE simulation mode of eMS is now active; that is, that the eMS command
set dos on
has been previously invoked.
•
The phrase "the eMS file system" refers to disk files that are in eMS's 512,
800, 1K, 2K, or 4K fixed physical block format; eMS's VSAM data sets are
not included.
•
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, it 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.
•
If you have an IBM 3850 Mass Storage System attached to your processor,
references to 3330 can be thought of as meaning 3330Vs unless the reference
is to VM/SP system residence, paging or spooling devices.
Preface
vii
Corequisile Publications
Virtual Machine/System Product:
General Information, GC20-1838
Introduction, GC 19-6200
Release 3 Guide, SC24-5240
CMS Command and Macro Reference, SC19-6209
CMS User's Guide, SC19-6210
CP Command Reference for General Users, SC 19-6211
Command Summary (General User), SX20-4401
Command Summary (Other than General User), SX20-4402
Quick Guide for Users, SX20-4400
System Programmer's Guide, SC19-6203
Installation Guide, SC24-5237
System Messages and Codes, SC 19-6204
OLTSEP and Error Recording Guide, SC19-6204
Terminal Reference, GC 19-6206
Library Guide and Master Index. GC19-6207
Operating Systems in a Virtual Machine, GC 19-6212
Operator's Guide, SC 19-6202
EXEC 2 Reference, SC24-5219
EXEC 2 Language Reference Summary, SX24-5124
System Product Editor User's Guide, SC24-5220
System Product Editor Command and Macro Reference, SC24-5221
System Product Editor Command Language Reference Summary, SX24-5122
System Product Interpreter User's Guide, SC24-5238
System Product Interpreter Reference, SC24-5239
System Product Interpreter Reference Summary, SX24-5126
Data Areas and Control Block Logic, Volume 1 (CP), L Y24-5220
viii
VM/SP Planning Guide and Reference
Data Areas and Control Block Logic, Volume 2 (CMS), LY24-5221
Service Routines Program Logic, L Y20-0890
System Logic and Problem Determination Guide Volume 1 (CP), LY20-0892
System Logic and Problem Determination Guide Volume 2 (CMS), L Y20-0893
Device Support Facilities User's Guide and Reference, GC35-0033
Remote Spooling Communications Subsystem Networking General Information,
GH24-5004
Remote Spooling Communications Subsystem Networking Program Reference
and Operations Manual, SH24-5005
Remote Spooling Communications Subsystem Networking Reference Summary,
SX24-5119
Remote Spooling Communications Subsystem Networking Logic, L Y24-5203
Non- VM / SP Titles:
3270 Information Display System Library User's Guide, GA23-0058
IBM 3850 Mass Storage System (MSS) Principles of Operation: Theory,
GA32-0035
IBM 3850 Mass Storage System (MSS) Principles of Operation: Reference,
GA32-0036
IBM 3850 Mass Storage System (MSS) Introduction and Preinstallation Planning, GA23-0038
IBM 3850 Mass Storage System (MSS) Installation Planning and Table Create,
GC35-0028
Introduction to the IBM 3704 and 3705 Communications Controllers,
GA27-3051
IBM 3704 and 3705 Control Program Generation and Utilities Guide and Reference Manual (OS/VS TCAM Levels 5 and 6 in VS1; VS2 Rei 1.6, 1.7, 2,
SCP 5744-BA1, GC30-3007
IBM 3704 and 3705 Control Program Generation and Utilities Guide and Reference Manual (TCAM 10 SVS - 5742-017) SCP 5742, 5744-AN1/BA2,
5747-AG1/AJ2, GC30-3008
IBM 3704 Control Panel Guide, GA27-3086
IBM 3705 Control Panel Guide, GA27 -3087
IBM OS/VS Linkage Editor and Loader, GC26-3813
VM/VTAM Communication Network Application General Information Manual,
GC27-0501
Preface
ix
Virtual Machine /VTAM Communication Network Application: Installation,
Operation, and Terminal Use, SC27 -0502
Virtual Machine /VTAM Communication Network Application Messages,
GC27-0510
Virtual Machine/VTAM Communication Network Application Logic,
LY38-3033
Environmental Recording, Editing, and Printing (EREP) Program, GC28-1178
EREP Messages, GC28-1179
IPCS Extension User's Guide and Reference, SC34-2020
References in the text to titles of prerequisite and corequisite VM/SP publications
are given in abbreviated form.
Figure 1 on page xii is an overview of the VM/SP library, with the publications
grouped according to their probable users.
x
VM/SP Planning Guide and Reference
Preface
xi
The VM/SP Library
LIBRARY
GUIDE AND
MASTER
INDEX
Evaluation
GC19-6207
GENERAL
INFORMATION
INTRODUCTION
GC20-1838
GC19-6200
Planning
PLANNING
GUIDE AND
REFERENCE
OPERATING
SYSTEMS IN
A VIRTUAL
MACHINE
DISTRIBUTED
DATA
PROCESSING
GUIDE
SC19-6201
GC19-6212
SC24-5241
Installation
Administration Operation
INSTALLATION
GUIDE
SYSTEM
PROGRAMMER'S
GUIDE
OPERATOR'S
GUIDE
SC24-5237
SC19-6203
SC19-6202
End Use
TERMINAL
REFERENCE
CMS
PRIMER
CMS
USER'S GUIDE
CMS
COMMAND
AND MACRO
REFERENCE
GC19-6206
SC24-5236
SC19-6210
SC19-6209
SP EDITOR
USER'S GUIDE
SP EDitOR
COMMAND
AND MACRO
REFERENCE
CP
COMMAND
REFERENCE
SC24-5220
SC24-5221
SC19-6211
SP
INTERPRETER
USER'S GUIDE
SP
INTERPRETER
REFERENCE
EXEC2
REFERENCE
SC24-5238
SC24-5239
SC24-5219
Reference Summaries
r---------I
I
I
I
I
I
I
I
I
QUICK
GUIDE
FOR USERS
I
I
I
SX20-4400
I
L ___ _
I
-----
Figure 1 (Part 1 of 2). Virtual Machine/System Product Ubrary
xii
To order all the Reference Summaries, use order number SBOF 3820.
-----------------------------1
VM/SP Planning Guide and Reference
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ JI
Program Service
SYSTEM
MESSAGES
AND CODES
OLTSEP
AND ERROR
RECORDING
GUIDE
SERVICE
ROUTINES
PROGRAM
LOGIC
SC19-6204
SC19-620S
LY20-0890
PROBLEM
DETERMINATION
VOL. 1 (CP)
DATA AREAS
AND CONTROL BLOCKS
VOL. 1 (CP)
PROBLEM
DETERMINATION
VOL. 2 (CMS)
DATA AREAS
AND CONTROL BLOCKS
VOL. 2 (CMS)
LY20-0892
LY24-S220
LY20-0893
LY24-S221
Auxiliary Service Support
DEVICE
SUPPORT
FACILITIES
t
I~
IPCS
EXTENSION
USER'S GUIDE
AND
REFERENCE
GC3S-0033
t
SC34-2020
EREP
MESSAGES
EREP
PROGRAM
GC28-1179
GC28-1178
Device Support Facilities
IPCS Extension 5748-SA 1
Environmental Recording
Editing and Printing
(EREP)
Auxiliary Communication Support
RSCS
NETWORKING
GENERAL
INFORMATION
GH24-S004
ASCS
NETWORKING
~~~~~:~CE
RSCS
NETWORKING
LOGIC
[[:i:
~~~RATIONS i~
SH24-S00S
LY24-S203
k
I
RSCS
NETWORKING
REFERENCE
SUMMARY
RSCS Networking
5748-XP1
iJ
VCNA
GENERAL
INFORMATION
VCNA
INSTALLATION
OPERATION
AND
TERMINAL USE
VCNA
MESSAGES
VCNA
LOGIC
GC27-0S01
SC27-0502
SC27-0S10
LY38-3033
VT AM Communications
Networking Application
(VCNA) 5735- RC5
FIgure 1 (Part 2 of 2). Virtual Machine/System Product Library
Preface
xiii
xiv
VM/SP Planning Guide and Reference
Contents
Part 1. Planning for System Generation
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •• 1
Chapter t. Introduction to PlannIng •••••••••••••••••••••••••••••••••••••••••••••••••••• 3
Virtual Machine Operating Systems ................................................... 4
Introduction to VM/SP System Generation ............................................. 4
Chapter 2. Configurations ••••••••••••.••••••••••.••..•••••••••••••••••••••••••••••••• 7
VM/SP Minimum Configuration ..................................................... 7
Configurations Supported by CMS .................................................... 8
Devices Supported by VM/SP ....................................................... 8
Processors ....................................................................... 9
Direct Access Storage Devices ...................................................... 11
Magnetic Tapes ..........•....................................................... 14
Unit Record Devices .............................................................. 14
Terminals ...................................................................... 15
Transmission Control Units ............................................... '......... 24
Other Considerations for Planning Your Configuration ................................... 27
Service Record File ............................................................... 28
Chapter 3. Estimating VM/SP Storage Requirements •••••••••••••••••••••••••••••••••••••
Real Storage Requirements for CP ...................................................
Reducing the CP Nucleus Size .......................................................
Direct Access Storage Requirements for CP ............................................
Estimating DASD Storage Requirements for CMS Minidisks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
31
33
36
43
Chapter 4. Planning for CMS •••••••••••••••••••••••••.•••.••••••••••••••••••••••••••
CMS Storage Requirements ........................................................
Device Support ................................... '. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CMS Libraries ..................................................................
System Macro Libraries ...........................................................
System Text Libraries .............................................................
Other Libraries ..................................................................
CMS Command Language .........................................................
CMS Program Language Facilities ...................................................
Limited Support of OS and VSE in CMS .............. ; ...............................
CMS Disk and File Management ....................................................
CMS Tape Support ...............................................................
CMS Unit Record Support .........................."...............................
Saving CMS ....................................................................
45
45
46
48
48
49
49
49
50
50
51
55
56
56
Chapter 5. Minidisks ••••••••••••••••••••••••••••••••••••••••••••••.••••••••••••••••
Defining Minidisks .............................................................. '.
Minidisk Space Allocation ..........................................................
Minidisk Initialization .............................................................
Alternate Tracks/Blocks ............................................................
Labels .........................................................................
Sharing Minidisks .................................................................
57
57
58
60
60
63
64
Chapter 6. Planning for CMS VSAM and Access Method Semces ••••••••••••••••••••••••••••
Hardware Devices Supported by VSE .................................................
Data Set Compatibility Considerations ................................................
Planning Considerations for Installing VSAM Under CMS; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
66
66
67
Chapter 7. Planning for CMS/DOS •.•••••••••••••••••••••••••••••••••••••••••••••••••
VSE System Generation Considerations ...............................................
When the VSE System Must Be Online ...............................................
CMS/DOS Tape Handling .........................................................
CMS/DOS Disk Label Information Area ..............................................
69
69
70
70
71
Chapter 8. Planning for Virtual Machine Operating Systems (Other than CMS) •••••••••••••••••• 73
The VM/VS Handshaking Feature ................................................... 73
Multiple Virtual Machines Using the Same Operating System .............................. 74
VM/SP Using Channel Switching .................................................... 74
Alternate Path Support ............................................................ 77
Contents
xv
Channel-Set Switching Facility ......................................................
Monitoring and Service Support Facility ...............................................
Input/Output Configuration Program .................................................
VM/SP Input/Output Configuration Program ..........................................
Missing Interruption Handler .......................................................
Operating Systems Using Reserve/Release .............................................
Logical Device Support Facility .....................................................
Inter-User Communication Vehicle ..................................................
Virtual Machine Communication Facility ..............................................
80
81
82
83
84
84
90
91
92
Chapter 9. Saved Systems and Discontiguous Segments •••••••••••••••••••••••••••••••••••• 93
Chapter 10. Performance GuideUnes ••••••••••••••••••••••••••••••••••••••••••••• • • • • • 97
Performance Measurement and Analysis .............................................. 98
Using Performance Options ........................................................ 98
Specifying a Virtual=Real Machine ................................................. 100
Virtual Machine Assist ........................................................... 109
Chapter 11. Attached Processor and Multiprocessor Systems •••••••••••••••••••••••••••••••
DMKSPAMACLm .............................................................
Modules Providing AP Support .....................................................
DMKSPM MACLm .............................................................
Modules Providing MP Support ....................................................
113
113
113
114
114
Chapter 11. Planning for 31705 ••••••••••••••••••••••••••••••••••••••••••••••••••••• 115
Remote Attachments ............................................................ 115
Local Hardware Configurations Supported ............................................ 119
Chapter 13. Planning for the 3704/3705 Control Program ••••••••••••••••••••••••••••••••• Ul
The mM 3704 and 3705 Communications Controllers .................................. 121
Planning Considerations .......................................................... 122
Chapter 14. Planning for SNA Console Communication Services •••••••••••••••••••••••••••• U5
Structure of the SNA Environment .................................................. 125
Chapter 15. Planning for the 3800 Image Ubrary •••••••••••••••••••••••••••••••••••••••• 119
Creating and Updating a 3800 Named System ......................................... 129
Related Publications ............................................................. 130
Chapter 16. Planning for the 3850 Mass Storage System •••••••••••••••••••••••••••••••••• 131
Generating a VM/SP System that Supports a 3850 ..................................... 131
Part 2. Denning Your VM/SP System ••••••••••••.•••••••••••••••••••••••••• 141
Chapter 17. Introduction to System Definition •••••••••••••••••••••••••••••••••••••••••• 143
System Integrity ................................................................ 143
Chapter 18. Creating Your VM/SP Directory ••••••••••••••••••••••••••••••••••••••••••
Considerations for Preparing the Directory Control Statements ............................
Sample Directory Entries ................................................•........
The Directory Program ...........................................................
DIRECTORY Control Statement ...................................................
USER Control Statement ........................................................ ;
ACCOUNT Control Statement ....................................................
OPTION Control Statement .......................................................
IUCV Control Statement .........................................................
IPL Control Statement ...........................................................
SCREEN Control Statement .........................................•............
CONSOLE Control Statement .....................................................
MDISK Control Statement ........................................................
SPOOL Control Statement ........................................................
DEDICATE Control Statement ....................................................
LINK Control Statement .........................................................
SPECIAL Control Statement ......................................................
147
148
150
153
157
158
161
162
166
168
169
171
172
177
180
183
186
Chapter 19. Preparing the Real I/O Configuration FOe (DMKRIO) •••••••••••••••••••••••••• 189
Coding the Real I/O Configuration Macros for Remote 3270s ............................ 191
xvi
VM/SP Planning Guide and Reference
CLUSTER Macro ............................................................... 192
TERMINAL Macro ............................................................. 194
RDEVICE Macro ............................................................... '200
RCTLUNIT Macro ................................................ '" ........... 215
RCHANNEL Macro ............................................................. 220
RIOGEN Macro ................................................................ 221
Example of Coding the Real I/O Configuration File (DMKRIO) .......................... 223
Considerations for Coding the Input/Output Configuration Source File ..................... 226
Example: Coding the Input/Output Configuration Source File ............................ 227
Cbapter 20. Preparing the System Name Table FOe (DMKSNT) ••••••••••••••••••••••••••••
Coding the NAMESYS Macro .....................................................
Coding the NAMENCP Macro .....................................................
Coding the NAME3800 Macro ....................................................
229
230
233
234
Cbapter 21. Preparing the CP System Control FOe (DMKSYS) ••••••••••••••••••••••••••••• 235
Performance Considerations for Coding the DMKSYS File Macros ......................... 236
SYSOWN Macro ............................................................... 237
SYSRES Macro ................................................................. 239
SYSOPR Macro ................................................................ 246
SYSCOR Macro ................................................................ 247
SYSTIME Macro ............................................................... 249
SYSMON Macro ................................................................ 251
SYSJRL Macro ................................................................. 254
SYSACNT Macro ............................................................... 256
SYSFORM Macro ............................................................... 257
SYSPCLAS Macro .............................................................. 259
SYSID Macro .................................................................. 261
SYSORD Macro ................................................................ 263
SYSMIH Macro ................................................................ 267
SYSLOCS Macro ............................................................... 270
Chapter 22. Additional System Definition FOes •••••••••••••••••••••••••••••••••••••••••• 271
The Forms Control Buffer Load (DMKFCB) .......................................... 271
The Universal Character Set and Font Offset Buffer .................................... 272
Appendixes
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 273
Appendix A. Licensed Programs and Integrated Emulators •••••••••••••••••••••••••••••••••
VM/370 Assembler .............................................................
Licensed Programs ..............................................................
Integrated Emulators ............. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
275
275
275
280
Appendix B. Configuration Aid ••••••••••••••••••••••••••••••••••••••••••••••••••••• 281
Appendix C. Compatible Devices •••••••••••••••••••••••••••••••••••••••••••••••••••• 187
Appendix D. VM/SP Restrictions •••••••••••••••••••••••••••••••••••••••••••••••••••
VM/SP .......................................................................
Restrictions - Channel Program ....................................................
Dynamically Modified Channel Programs .............................................
Minidisk Restrictions ............................................................
Timing Dependencies ............................................................
Processor Model-Dependent Functions ..............................................
Channel Model-Dependent Functions ...............................................
Virtual Machine Characteristics ....................................................
MSS Restrictions ................................................................
CMS Restrictions ...............................................................
Miscellaneous Restrictions ........................................................
289
289
289
289
291
293
294
295
296
299
300
302
Index ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 305
Contents
xvii
Figures
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.
xviii
VM/SP Planning Guide and Reference
Virtual Machine/System Product Library .......................................... xii
Real Storage Requirements for CP ............................................... 31
DASD Space Requirements by DASD Type ........................................ 38
Devices Supported by a CMS Virtual Machine ...................................... 46
Volume Label Contents for CMS Formatted Disks ................................... 53
CMS Disk File Statistics for 800-byte CMS Blocks ................................... 54
Use and Definition of Minidisks .................................................. 58
Channel Switching between Two Processors ........................................ 75
Channel Switching on One Processor ............................................. 76
Real I/O Control Block Structure for Alternate Control Unit Specification ................ 78
Real I/O Control Block Structure for Alternate Channel Specification .................... 79
Summary of VM/SP Reserve/Release Support ...................................... 88
Logical Device Support Facility Subfunctions ....................................... 90
Example of Determining Line Code for Remote 3270 Resource Identification Codes ........ 117
Sample List of Resource Identification Codes for Operations .......................... 119
Available Form Width Codes ................................................... 179
Remote 3270 Control Unit and Device Addressing .................................. 198
Examples of Remote 3270 Addressing ........................................... 199
mM 3704/3705 Models ...................................................... 211
Example of a Real Configuration ................................................ 224
RealI! 0 Configuration File ............................................. ~ . . . . . 225
IOCP Source File ............................................................ 227
Dynamic Checkpoint Start Area Calculations ...................................... 243
Warm Start Area Calculations .................................................. 245
Integrated Emulators that Run under VM/SP ...................................... 280
Part 1. Planning for System Generation
Part 1 contains planning information. It describes the various components, options,
and features of VM/SP and tells you what you must do to install them. Part 1 contains the following sections:
•
Introduction to Planning
•
Configurations
•
Estimating VM/SP Storage Requirements
•
Planning for CMS
•
Minidisks
•
Planning for CMS VSAM and Access Method Services
•
Planning for CMS/DOS
•
Planning for Virtual Machine Operating Systems (Other than CMS)
•
Saved Systems and Discontiguous Segments
•
Performance Guidelines
•
Attached Processor and Multiprocessor Systems
•
Planning for 3270s
•
Planning for the 3704/3705 Control Program
•
Planning for SNA Console Communications Services
•
Planning for the 3800 Image Library
•
Planning for the 3850 Mass Storage System
Part 1. Planning for System Generation
2
VM/SP Planning Guide and Reference
Chapter 1. Introduction to Planning
The IBM VM/System Product is a program product that manages a real system so
that all its resources -- main (IPL) processor, attached (non-IPL) processor, storage, and input/output devices -- are available to many users at the same time.
Each user has at their disposal the functional equivalent of a real, dedicated system.
Because this functional equivalent is simulated by VM/SP and does not really exist,
it is called a "virtual" machine.
VM/SP has two components:
•
The control program (CP), which controls the resources of the real processor
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 run problem programs.
When you install VM/SP in conjunction with the VM/370 Release 6 System Control Program, it becomes a functional operating system that provides extended features to the System Control Program and Conversational Monitor System
components of VM/370 Release 6.
The processors that VM/SP supports are listed under the heading "Processors" in
Chapter 2. The real processor must have the Dynamic Address Translation
feature; a hardware facility that translates virtual storage addresses to real storage
addresses, and the System Timing facility. Also, it must operate in extended control mode; a mode in which all the features of a processor, including dynamic
address translation, are operational.
Chapter 1. Introduction to Planning
3
Virtual Machine Operating Systems
While the control program of VM/SP manages the concurrent execution of virtual
machines, it is also necessary to have an operating system managing the work flow
within each virtual machine. Because each virtual machine runs independently of
other virtual machines, each one may use a different operating system, or different
releases of the same operating system.
The operating systems that can run in virtual machines are:
Batch or
Single User Interactive
DOS
DOS/VS
VSE
OS/ASP
OS/PCP
OS/MFT
OS/MVT
OS/VSl
OS/VS2
RSCS
Multiple-Access
VM/370
VM/SP
Time Sharing
Option of OS
MVS/SP
Conversational
CMS
CP provides each of these with virtual device support and virtual storage. The
operating systems themselves run as though they are controlling real devices and
real storage, but they must not violate any of the restrictions listed in "Appendix D.
VM/SP Restrictions."
Introduction to VM/SP System Generation
The reason for the system generation is to create a VM/SP system that meets your
particular needs.
The first step in the system generation procedure is to restore the starter system, a
small working copy of a basic vM:/SP system. Using the starter system, you tailor
aVM/SP 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 VM/SP starter system can be ordered:
•
3330 Starter System
•
3340 Starter System
•
3350 Starter System
•
3375 Starter System
•
3380 Starter System
•
FB-512 Starter System
All starter systems must be restored to a corresponding disk (that is, 3330 starter
system to a 3330 disk), but all starter systems can then be used to build any supported system residence volume type (3330, 3340, 3350, 3375, 3380, or FB-512).
4
VM/SP Planning Guide and Reference
Before you begin the system generation procedure, you should:
•
Know which devices to include in your VM/SP 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/SP, you
must coordinate the real I/O configuration with the Mass Storage Control
tables.
•
Decide how many virtual machines to define.
•
Create the VM/SP directory control statement file describing the virtual
machines.
•
Decide which volumes are to be owned and used by CP (for system residence,
paging, spooling, and so on), the amount of real storage available to VM/SP,
and the user identification of the real system operator.
•
Create the CP system control (DMKSYS) file describing CP-owned volumes,
the real storage size, and so on.
•
Create the system name table (DMKSNT) describing the name and location of
saved systems.
•
If you wish, you can create your own forms control buffer (module
DMKFCB). This module is supplied with the product tape.
Once you have defined your VM/SP 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 macro statements that define your system. The VM/ SP
Installation Guide describes the generation procedure step-by-step.
Chapter 1. Introduction to Planning
5
6
VM/SP Planning Guide and Reference
Chapter 2. Configurations
Before you begin the system generation procedure, make sure you have the minimum configuration supported by VM/SP and the features and facilities required by
VM/SP.
VM/SP Minimum Configuration
The minimum configuration supported by VM/SP is:
One
One
One
One
One
Two
One
One
One
Processor (524,288 bytes of storage)
System console device
Printer
Card reader l
Card punch1
Spindles of direct access storage2
Nine-track magnetic tape unit
Multiplexer channel
Selector or Block mUltiplexer channel
To determine the amount of real storage and direct access storage necessary for a
configuration, see "Chapter 3. Estimating VM/SP Storage Requirements."
A representative VM/SP configuration is:
IBM 4341 2Mb/4Mb Storage
IBM 3278 Display Console Mode12A
IBM 3203 Printer ModelS -- Two
IBM 3350 Direct Access Storage Model A2 or 3370 Direct Access
Storage -- Four drives attached to a 3880
Storage Control Model 1
IBM 3350 Direct Access Storage Model A2F -- Fixed-head feature
IBM 3420 Magnetic Tape Units -- Two
IBM 3705 Communications Controller
IBM 3278 Display Stations (as needed) with the 3274 Control Unit
(local or remote attachment).
IBM 3279 Display Stations (as needed) with the 3274 Control Unit
(local or remote attachment).
1
12
This device is not needed for a cardless system.
Three spindles are required if you are using 3310 or 3340-70 DASDs.
Chapter 2. Configurations
7
Configurations Supported by CMS
CMS supports:
Virtual storage size: minimum of 256K bytes, up to 16 million bytes in multiples of 4K.
•
Virtual console: any terminal supported by VM/SP as a virtual machine operator's console.
•
The same unit record devices (card readers, punches, and printers) supported
by VM/SP as spooling devices, except the 2520 Punch. See "Unit Record
Devices" later in this chapter.
•
Up to twenty-six logical 2314, 2319, 3340, 3330 Modell, 2, or 11,3333
Modell or 11, 3350, 3375, 3380, or FB-512 direct access storage devices.
The maximum size of a CMS minidisk is:
CMS/VSAM
CMS 800-byte
Format
CMS 512, lK, 2K,
or4K Format
200 cyls.
126,016 blocks
404 cyls.
808 cyls.
404 cyls.
808 cyls.
348 cyls.
696 cyls.
555 cy~s.
558,000 blocks
959 cyls.
885 cyls.
203 cyls.
not supported
246 cyls.
246 cyls.
246 cyls.
246 cyls.
348 cyls.
682 cyls.
115 cyls.
not supported
182 cyls.
121 cyls.
203 cyls.
126,016 blocks
404 cyls.
808 cyls.
404 cyls.
808 cyls.
348 cyls.
696 cyls.
555 cyls.
558,000 blocks
959 cyls.
885 cyls.
Device
Type
2314/2319
3310
3330
3330
3333
3333
3340
3340
3350
3370
3375
3380
Model{s)
lor 2
11
1
11
35
70
native mode
Up to four 2400, 2415, 2420, 3410 (9 track only), 3420, 3430, or 8809 (7 or
9 track) Magnetic Tape Units.
Devices Supported by VM/SP
The following devices are supported by VM/SP 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
Other devices
This section does not include SNA supported devices. For information concerning
supported SNA devices, refer to the VM/VTAM Communications Network Application (VM/VCNA) publications listed in the Preface.
8
VM/SP Planning Guide and Reference
Processors
VM/SP supports the following processors:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
IBM System/370 Model 135 Submodel3
IBM System/370 Model 138
IBM System/370 Model 145
IBM System/370 Model 145 Submodel3
IBM System/370 Model 148
IBM System/370 Model 155 II
IBM System/370 Model 158 UP/ AP/MP
IBM System/370 Model 158 Submodel3
IBM System/370 Model 165 II
IBM System/370 Model 168 UP / AP /MP
IBM System/370 Model 168 Submodel3
IBM 4321
IBM 4331 All models
IBM 4341 All models
IBM 3031 UP/AP
IBM 3032 UP
IBM 3033 UP / AP /MP
IBM 3042 AP Model 2
IBM 3033 Model Group N
IBM 3033 Model Group S
IBM 3081 Model D 16
Processor Required Features and Facilities
Processor features and facilities required by VM/SP are listed below. Only features and facilities that are not standard on a particular processor are described.
For example, the Word Buffer feature is standard only on the Model 148;
therefore, the feature number and requirements are described only for the Models
145 and 145-3.
•
The System Timing facility (#2001), which includes the clock comparator and
the processor timer, on the Models 135 and 145.
The clock comparator and processor timer (#2001) on the
•
ModeI14~-3.
The Floating-point feature
Model 135, feature #3900
Model 145, feature #3910
•
The Extended Precision Floating feature (#3840) on the Model 135-3.
•
The Channel Indirect Data Addressing feature on each of the 2860, 2870, and
2880 stand-alone I/O channels on the Model 165 II or 168.
2860, features #1861, 1862, and 1863
2870, feature #1861
2880, features #1861 and 1862
Chapter 2. Configurations
9
Note: The stand-alone channels that attach to the System/370 Models 165 II
and 168 require that the Channel Indirect Data Addressing feature be ordered
as a separate feature for proper operation of the input/output channels in a
Dynamic Address Translation environment.
•
The Word Buffer feature (#8810) is required on Sysrem/370 Model 145-3. It
is also required on Model 145 if:
A 2305 Model 2 Fixed Head Storage device is attached.
A 3340, 3344, or 3350 Direct Access Storage Facility is attached.
A 3330 configuration includes an integrated file adapter and two selector
channels, or three or more selector channels.
Note: This feature is recommended for selector channels if 2314, 3330,
3340, or 3350 devices are attached.
Desirable Features
The following processor features are desirable for VM/SP:
•
Virtual machine assist improves performance of VM/SP systems that run virtual storage operating systems in virtual machines. The manner in which virtual machine assist and VM/370:ECPS (see below) are supported on the various
VM/SP processors is detailed under "Using Performance Options',' in Chapter
10.
•
Extended Control Program Support improves performance of VM/SP through
CP assist and expanded virtual machine assist capabilities.
•
The Extended Floating Point feature i'11proves exec"::tion of programs that use
Extended Floating Point instructions under VM/~P on Models 135, 155 II,
and 158.
For Model 135, feature #3840
For Model 155 II, feature #3700
For Model 158, feature #3700
•
The APL Assist feature provides performance assistance when used with the
VS APL program product. It is available as hardware feature #1005 on
System/370 Models 135 and 145.
•
The Conditional Swapping feature provides additional instructions required for
execution of VTAM programs. It is available as feature #1051 on System/370
Models 135 and 145.
•
The Advanced Control Program Support feature is available only on
System/370 Model 145 as feature #1001. It provides additional instructions
required for the execution of MVS (OS/VS2 Release 2 and above) and/or
VTAM.
Note: The Conditional Swapping feature and the Advanced Control Program
Support feature are mutually exclusive.
10
VM/SP Planning Guide and Reference
•
The ECPS Expansion Feature (#1601) is available on the mM 4341 Processor
Model Group 2 and 12. It increases performance when the MVS/System
Product is run in conjunction with the VM/System Product. It allows concurrent operation of ECPS:MVS and ECPS:VM/370 and includes the functions
of the Shadow Table Bypass Assist.
•
Channel-to-channel Adapter (#1850) interconnects two channels (either
S/360, S/370, or 4341 processorr Only one of the processors requires this
feature.
•
The mM 3088 Multisystem Communication Unit is an input/output (I/O)
device used to interconnect as many as eight processors using block multiplexer
channels. The 4341, 303x, 3042 Attached Processor Model 2, and 308x
processors will support the 3088.
•
Data Streaming (#4850) is available on the 303x and 3042 AP-2 processors.
This feature modifies the first two block multiplexer channels of a channel
group to permit each to operate at a higher data rate. This feature is standard
on the 3081 and 4341 processors. Please refer to the appropriate processor
manual to determine which channels support data streaming.
Direct Access Storage Devices
The direct access storage devices supported by VM/SP are:
•
IBM 2305 Fixed Head Storage, Models 1 and 2
•
IBM 2314 Direct Access Storage Facility
•
IBM 2319 Disk Storage
•
IBM 3310 Direct Access Storage
•
IBM 3330 Disk Storage, Models 1, 2, and 11
•
IBM 3333 Disk Storage and Control, Models 1 and 11 for 3330 Models 1,2,
and 11
•
IBM 3340 Direct Access Storage Facility, Models A2, Bl, and B2; the 3348
Data Modules, Models 35, 70, and 70F; and the 3344 Direct Access Storage,
Model B2
•
IBM 3350 Direct Access Storage, Models A2 and B2
•
IBM 3370 Direct Access Storage
•
IBM 3375 Direct Access Storage
•
IBM 3380 Direct Access Storage.
All of these direct access devices are supported as VM/SP 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 eMS.
Chapter 2. Configurations
11
The following direct access control units are supported by VM/SP:
•
mM 3345 Storage and Control Frame Models 3, 4, and 5 on the Models 145,
145-3, and 148 with the standard ISC for:
-
•
mM 2835 Storage Control Models 1 and 2 for 2305 Models 1 and 2.
•
mM 2844 Auxiliary Storage Control for 2314 and 2319.
•
IBM 3830 Storage Control Modell for 3330 Models 1 and 2 only.
•
mM 3830 Storage Control Model 2 for 3333 Models 1 and 11,3340 Model
A2, and 3350 Model A2.
•
IBM 3830 Storage Control Model 3 for 3330 Models 1 and 11, and 3333
Models 1 and 11.
•
IBM 3880 Storage Control Modell for 3330 Models 1, 2, and 11, 3333 Models 1 and 11, 3340 Model A2, 3350 Models A2 and A2F, 3370 and 3375.
•
IBM 3880 Storage Control Model 2 for 3330 Models 1, 2, and 11, 3333 Models 1 and 11, 3340 Model A2, 3350 Models A2 and A2F, 3370, 3375, and
3380s on the 303x processor with the Data Streaming Feature (#4850).
•
IBM 3880 Storage Control Model 3 for 3380s on the 303x processor with the
Data Streaming Feature (#4850).
•
IBM Integrated File Adapter (#4650) on System/370 Models 135 and 145 for
2319s.
•
IBM Integrated File Adapter (#4655) on the System/370 Models 135, 135-3,
and 138 or the IBM Integrated Storage Control #4660) on the System/370
Model 145, 145-3, and 148 for:
-
•
•
3330 Models 1 and 2
3333 Models 1 and 11
3340 Model A2 and 3344 Model B2
3350 Model A2
IBM Integrated Storage Control on the System/370 Model 168 for:
-
VM/SP Planning Guide and Reference
3330 Models 1 and 2
3333 Models 1 and 11
3340 Model A2 and 3344 Model B2
3350 Model A2
IBM Integrated Storage Control on the System/370 Model 158 for:
-
12
3330 Models 1 and 2
3333 Models 1 and 11
3340 Model A2 and 3344 Model B2
3350 Model A2
3330 Models 1 and 2
3333 Models 1 and 11
3340 Model A2 and 3344 Model B2
-
3350 Model A2
Special Features Required with the 3350
Expanded Control Store special feature (#2151) provides additional control storage
for microprogramming use. It 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 Store Extension feature (#2150) is a prerequisite for feature #2151.
Notes:
1. 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.
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. As
noted earlier, this feature is standard on the Model 148.
Desirable Features
3880 Storage Control Unit Buffer Features:
•
Feature #6550 for 3380 DASDs attached to 3880 Models 2 and 3
•
Feature #6560 for 3375 DASDs attached to 3880 Models 1 and 2
The speed matching buffer feature (Feature #6550) for the 3380 supports the
use of extended count-key-data channel programs.
If the 3380 attached to the 3880 Controller Model 3 with Speed Matching
Buffer (Feature #6550) is part of your installation, CP will permit execution of
extended count-key-data channel programs.
These features modify the direct access data transfer path by adding a buffer feature between the DASD device and the multiplexer channel. When the 3880 control unit is equipped with the respective buffer feature, 3380 or 3375 devices can
be attached to channels that operate at data rates slower than that of the DASD
device.
The respective buffer features allow attachment of 3380 or 3375 devices to the following types of channels:
•
1.5 megabyte block multiplexer channels on S/370 Models 145, 148, 155-11,
158, 153-3, 165-11, 168, 168-3, 3031, 3032, 3033, and 3042 Model 2
•
2.0 megabyte block multiplexer channels on the 4341 Processor and high speed
block multiplexer channels on the 4331 Model Group 2 Processor
•
3.0 megabyte block multiplexer channels on 3031,3032,3033, and 3042
Model 2 when these processors are equipped with the Data Streaming Feature
(#4850)
•
3.0 megabyte block multiplexer channels on 4341,3081, and 3083 Processors
Chapter 2. Configurations
13
The speed matching operation for writing records to the 3375 DASD over a 1.5
megabyte block multiplexer channel requires that the data transfer across the channel and into the buffer begin in advance of the data transfer from the buffer to the
3375. To accomplish this with minimum loss of disk revolutions, special channel
commands provide write-prenotification whenever possible.
Magnetic Tapes
The magnetic tape devices supported by VM/SP are:
•
•
•
•
•
•
I:
•
IBM 2401, 2402, 2403, and 2404 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
IBM 3410/3411 Magnetic Tape Unit, Models 1, 2, and 3
IBM 3411 Magnetic Tape Unit and Control, Models 1, 2, and 3
IBM 3420 Magnetic Tape Units, Models 3, 4, 5, 6, 7, and 8
IBM 3430 Magnetic Tape Unit
IBM 3430 Magnetic Tape Unit and Control
IBM 8809 Magnetic Tape Unit
The magnetic tape control units supported by VM/SP are:
•
•
•
I.
•
IBM 2803 Tape Control
IBM 2804 Tape Control
IBM 3411 Magnetic Tape Unit and Control
IBM 3430 Magnetic Tape Unit and Control
IBM 3803 Tape Control
Unit Record Devices
VM/SP supports the following printers:
•
IBM 1403 Printer Models 2, 3, 7, and N1
•
IBM 1443 Printer Model N1 (with 144 print positions)
•
IBM 3203 Printer Model 4 (available on processor Models 138 and 148 only)
and ModelS
•
mM 3211 Printer (Right Indexing only)
•
mM 3213 Printer (in 3215 Emulator Mode)
IBM 3262 Printer Models 1,3,5 (in 3262 Modell Emulator Mode), 11, and
13
14
•
IBM 3287 Printer Models 1, 1C, 2, and 2C
•
IBM 3289 Model 4 Printer
•
IBM 3800 Printer Model 1
•
IBM 3800 Printer Models 3 and 8 (dedicated only)
•
IBM 4245 Printer
VM/SP 'Planning Guide and Reference
I.
mM 4250 Printer (dedicated only).
VM/SP supports the following readers/punches:
•
•
•
•
•
mM 2501 Card Reader Models Bl and B2
mM 2520 Card Punch Models B2 and B3
mM 2540 Card Read Punch Modell
mM 3505 Card Reader Models Bland B2
mM 3525 Card Punch Models PI, P2, and P3.
VM/SP supports the following unit record control units:
•
IBM 2821 Control Unit
•
mM 3811 Printer Control Unit
•
mM Integrated Printer Adapter (IPA) on the System/370 Model 135
•
IBM Integrated Printer Adapter Basic Control (#4670), and one of the following on the models 135-3 and 138:
1403 Printer Models 2 or Nl 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.
Terminals
The following system consoles are supported by VM/SP as virtual machine consoles (3215 emulation mode.only):
•
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 Modell
•
IBM System Console for the System/370 Models 138 and 148 in
printer-keyboard mode (3286 printer required)
•
IBM System Console for the System/370 Model 158 in printer-keyboard mode
(with the 3213 Printer Modell required)
•
IBM 7412 Console (via RPQ AA2846) with 3215 Console Printer-Keyboard
Modell.
The following system consoles are supported by VM/SP as virtual machine consoles (in 3215 emulation mode or in 3270 mode):
•
IBM System Console for the System/370 Models 138 and 148 in display mode
•
IBM System Console for the System/370 Model 158 in display mode
Chapter 2. Configurations
15
•
mM 3036 Console with the 3031, 3032 or 3033 processor
•
IBM 3278 Model2A Console (in display mode) with the 4300 and 3081
processors (3287 printer optional)
•
mM 3279 Model2C Console (in display mode) with the 4300 processors
(3287 printer optional).
Note: During system initialization only, the primary system operator's console
cannot be connected to the system via a teleprocessing line.
The following terminals are supported by VM/SP as virtual machine consoles (in
3215 emulation mode only):
•
IBM 2741 Communication Terminal
•
IBM 1050 Data Communication System
•
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 3101 Display Terminal, Models 10, 12, 13,20,22, and 23 (supported as
teletype Model ASR 33/35 teletypewriter)
•
mM 3232 Keyboard-Printer Terminal Model 51
•
mM 3275 Display Station, Model 2 with integral control unit (remote attachment only)
•
IBM 3276 Control Unit Display Station Models 2, 3, and 4 with integral control unit.
The following terminals are supported by VM/SP as virtual machine consoles (in
3215 emulation mode or in 3270 mode):
•
IBM 3277 Display Station, Model 2, via 3272 Control Unit, Model 2 (local
attachment only)
•
IBM 3277 Display Station, Model 2, via 3271 Control Unit, Model 2 (remote
attachment only)
•
IBM 3277 Display Station Model 2 via 3274 Control Unit Models IB and 1D
(local attachment)
•
IBM 3278 Display Station Models 2, 3, and 4 via 3274 Control Unit Model1B
(local attachment)
•
IBM 3278 Display Station Models 2, 3, 4, and 5 via 3274 Control Unit Model
1D (local attachment)
IBM 3278 Display Station Models 2, 3,4, and 5 via 3274 Control Unit Models
1C and 51C
•
16
VM/SP Planning Guide and Reference
IBM 3278 Display Station Models 2, 3, and 4 via 3276 Control Unit Models 2,
3, and 4
•
IBM 3279 Color Display Station Models 2A, 2B, 3A, and 3B via 3274 Control
Unit Models IB and ID (local attachment)
•
IBM 3279 Color Display Station Models 2A, 2B, 3A, and 3B via 3274 Control
Unit Models 1C and 51 C
•
IBM 3279 Color Display Station Models 2A and 2B via 3276 Control Unit
Models 2, 3, and 4
•
IBM 3279 Color Display Station Models 3A and 3B via 3276 Control Unit
Models 3 and 4
•
IBM 3767 Communications Terminal Models 1 and 2 (operating as a 2741).
The following system consoles are supported by VM/SP as virtual system consoles
(supported as 3270 consoles):
•
IBM System Console for the System/370 Models 138 and 148 in display mode
•
IBM System Console for the System/370 Model 158 in display mode
•
IBM 3036 Console with the 3031,3032, or 3033 processor
•
IBM 3278 Model2A Console (in display mode) with the 4300 processors.
The following terminals are supported by VM/SP as virtual system consoles (supported as 3270 consoles):
•
IBM 3277 Display Station, Model 2, via 3272 Control Unit, Model 2 (local
attachment only)
.0
IBM 3277 Display Station, Model 2, 3, and 4 via 3274 Control Unit ModellB
(local attachment)
•
mM 3278 Display Station Models 2,3,4, and 5 via 3274 Control Unit Model
ID (local attachment)
•
IBM 3279 Color Display Station Models 2A, 2B, 3A, and 3B via 3274 Control
Unit Models IB and ID (local attachment).
Notes:
1. Any local non-SNA system console or terminal that defaults to being defined
to the system as a 3277/3278 will work with directory entry "CONSOLE cuu
3270."
2.
3215 console simulation for graphics devices excludes processing multiple output channel programs that contain CCWs without carriage returns (X'OI'
CCW op code) on one line of the screen. These channel programs are treated
separately and VM/SP uses a new line for each one.
Chapter 2. Configurations
17
Special Considerations and Required Felltures
Terminals that are equivalent to those explicitly supported may also function satisfactorily. You are responsible for establishing equivalency. IBM 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 IBM branch office for ordering information concerning the
RPQs mentioned in this book.
2741 Features: Required and Desirable Features
The IBM 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:
•
PTTC/EBCD (#9571, Part #1167963) or standard Correspondence (#9812,
Part #1167043) print elements
•
Transmit Interrupt (#7900) or Transmit Interrupt Control RPQ #E40681
•
Receive Interrupt (#4708)
•
For switched lines, the Data Set Attachment (#9114) and Dialup feature
(#3255) are required.
•
For point-to-point nonswitched lines, one of the following features is required:
Data Set Attachment (#9115 duplexed for facility Dl)
Data Set Attachment (#9116 duplexed for facility B2)
Data Set Attachment (#9120 duplexed for facility Bl or D1)
IBM Line Adapter (#4635 for 4-wire limited distance line)
IBM Line Adapter (#4691-4694 for 4-wire shared nonswitched line)
IBM Line Adapter (#4647 for 4-wire nonswitched line).
The following features, although not required, heighten the convenience and usability of the terminal:
18
•
Print Inhibit (#5501)
•
Red Ribbon Control RPQ #868019 (supported for PTTC/EBCD keyboard
only)
•
Typamatic Keys (#8341)
•
Pin Feed Platen (#9509).
VM/SP Planning Guide and Reference
1050 Control Units, Models, and Features: Supported, Required, and Desirable Features
The IBM 1050 Data Communication System is supported on either switched or
point-to-point nonswitched lines with these features:
•
mM 1051 Control Unit, (Model 1 or 2) with these features:
Transmit Interrupt (#7900) or Transmit Interrupt Control RPQ #E26903
Re(,.~ive
Interrupt (#6100) or Receive Interrupt Control RPQ #E27428
rext Time-Out Suppression (#9698)
First Printer Attachment (#4408). This feature is required to attach a
1052 Printer-Keyboard to the 1051.
•
IBM 1052 Printer-Keyboard (Modell or 2) with the PTTC/EBCD print element (#9571, Part #1167963)
•
For switched lines, the Data Set Attachment (#9114) is required.
•
For point-to-point nonswitched lines, one of the following is required:
Data Set Attachment (#9115 for facility Dl)
-orData Set Attachment (#9116 for facility B2)
-orData Set Attachment (#9120 for facility Bl or D1)
-orIBM Line Adapter (#4691-4694 for 4-wire shared nonswitched line)
-orIBM Line Adapter (#4647 for 4-wire nonswitched line)
The following features, although not required, heighten the convenience and usability of the terminal:
•
•
Automatic Ribbon Shift and Line Feed Select (#1295)
Automatic EOB on Carrier Return RPQ #E28235.
Chapter 2. Configurations
19
3270 Information Display System Terminals: Required Features
The 3271/3272 and 3274 Control Units are terminal control units that can attach
up to 32 displays, serial matrix printers and/or line printers. These terminals are
grouped into two categories. The Category A terminals are displays and printers
that were developed for attachment to the 3274 Control Unit, while the Category
B terminals were designed for attachment to the 3271/3272 Control Units. The
3274 Control Unit was also designed to attach the Category B terminals with certain limitations. A maximum of 16 of the 32 attachable terminals on a 3274 can be
Category B terminals.
A1TACHABLE TERMINALS
Category A Terminals
3262 Line Printer Models 3, 13
3278 Display Station Models 1, 2, 3, 4, 5
3279 Color Display Station Models 2A, 2B, 3A, 3B
3287 Printer Models 1, 2, lC, 2C
3289 Line Printer Models 1, 2
4250 Printer
Category B Terminals
3277 Display Station Models 1,2
3284 Printer Models 1,2
3286 Printer Models 1,2
3288 Line Printer Model 2
The basic 3271/3272 Control Unit permits attachment of up to 4 devices. Up to
32 devices may be attached in sets of four devices by adding up to seven Device
Adapters (#3250).
The basic 3274 Control Unit permits attachment of up to 8 Category A terminals.
Two categories of terminal adapters can be featured in various combinations to
provide the maximum terminal configuration of 32 terminals. A maximum of 16 of
the 32 terminals can be Category B units and at least one Category A Display Station with keyboard is needed for diagnostic purposes.
TERMINAL ADAPTER TYPE Al THROUGH A3 (#6901, #6902, #6903): One of
each of these adapters can be installed on a 3274 Control Unit. Each adapter provides for the attachment of an additional 8 Category A terminals. These terminal
adapters must be installed in sequence:
Terminal Adapter Type Al - Category A terminals 9-16
Terminal Adapter Type A2 - Category A terminals 17-24
Terminal Adapter Type A3 - Category A terminals 25-32
20
VM/SP Planning Guide and Reference
TERMINAL ADAPTERS TYPE Bl THROUGH B4 (#7802, #7803, #7804, #7805):
Terminal Adapter Type B 1 permits the attachment of four Category B terminals to
a 3274 Control Unit, and provides for the installation of Terminal Adapters Type
B2, B3 and B4 when additional Category B terminals are desired. Terminal
Adapters Type B2 through B4 permit the attachment of four additional Category B
terminals each. A maximum of one each of the B 1, B2, B3 and B4 adapters can be
installed for a combined-total of sixteen Category B terminals on a 3274 Control
Unit. These terminal adapters must be installed in sequence:
Terminal Adapter Type B 1 Terminal Adapter Type B2 Terminal Adapter Type B3 Terminal Adapter Type B4 -
Category B
Category B
Category B
Category B
terminals
terminals
terminals
terminals
1-4
5-8
9-12
13-16
The TERMINAL macro in the real I/O file requires that terminals on a Type A
adapter must come before terminals on a Type B adapter.
For additional information on 3270 Information Display Terminals, see the 3270
Information Display System Library User's Guide.
Local Configurations Supported
CONTROL UNITS: The following control units can be locally attached on a byte
multiplexer, block multiplexer, or selector channel to support 3270 devices:
IBM 3272 Controll)nit Modell and 2 for attachment of up to 32 Category B
terminals.
These 3272 configurations require:
•
Device Adapter feature (#3250) 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 (#8330) to attach each 3287 Printer.
IBM 3274 Control Units Model1B, 1D, 21B, 21D, 31D for the attachment of
up to 32 display stations and printers. All of the 32 devices can be Category A
Terminals. The 3278 Display station Model 5 is not supported with the 3274
Control Unit Model lB. A maximum of 16 of the 32 devices can be Category
B terminals.
Chapter 2. Configurations
21
Remote Configurations Supported
CONTROL UNITS: The following control units can be remotely attached to leased
lines via a:
•
•
•
•
2701 Data Adapter Unit
2703 Transmission Control Unit
3704/3705 Communications Controller in emulation mode
Integrated Communication Adapter (lCA) :
IBM 3271 Control Unit Model 2 for attachment of up to 32 Category B
terminals.
This configuration requires:
Device Adapter feature (#3250) if more than four devices are attached
to the 3271. Up to four additional devices can be attached with each
device adapter.
A 3271/3272 Attachment (#8330) is required to attach each 3287
Printer Model 1 or 2.
Copy feature (#1550) is required to use the full screen copy function.
Transmission Speed feature (#7820 or #7821).
IBM 3271 Control Unit Model 11 and 12 for attachment of up to 32 Category B terminals.
IBM 3274 Control Unit Model1C, 21C, 31C for the attachment of up to
32 display stations and printers. All of the 32 devices can be Category A
terminals. A maximum of 16 of the 32 devices can be Category B terminals.
IBM 3274 Control Unit Model51C for the attachment of up to 12 display
stations and printers. Eight of the twelve devices can be Category A terminals. Up to four Category B terminals can be attached via Terminal
Adapter Type B 1.
IBM 3276 Control Unit Display Station Models 2,3, and 4 for attachment
of up to 7 additional:
3278 Display Stations Models 2,3, and 4. 3278 Model 3 cannot be
attached to a 3276 Model 2. 3278 Model 4 cannot be attached to a
3276 Model 2 or 3.
3279 Color Display Stations Models 2A, 2B, 3A, 3B. 3279 Models 3A
and 3B cannot be attached to 3276 Model 2.
3287 Printers Models 1, 1C, 2, 2C.
Note: Extended color printing, highlighting, and programmed symbols
are not supported for the 3276.
3289 Printer Models 1 and 2.
22
VM/SP Planning Guide and Reference
To support this configuration, the following is required:
The basic 3276 Control Unit Display Station contains 1 integral display
station, and permits attachment of one of the following:
3278 Display Station Model 2, 3, or 4
3279 Model 2A, 2B, 3A, or 3B. 3279 Models 3A and 3B cannot
be attached to a 3276 Model 2.
3287 Printer Models 1 or 2
A 3274/3276 Attachment (#8331) is required for each 3287 Printer
Modell or 2.
Each 3276 requires one of the Communications features (#6301 or
#6302) and either the External Modem Interface (#3701) or the 1200
BPS Integrated Modem feature (#550Q).
Color Display Attachment (#1950) permits attachment of 3279 Color
Display Terminal Models 2A, 2B, 3A, and 3B. This feature is not
available for the 3276 Models 1 and 2. The 3276 does not support
programmable symbol sets, extended color, or extended highlighting.
3279 Models 2B and 3B are supported on the 3276 for base color.
Extended Function Base (#1068) is prerequisite.
The following control unit is remotely attached to either leased or switched lines via
a:
•
2701 Data Adapter Unit
•
2703 Transmission Control Unit
•
3704/3705 Communications Controller in emulation mode
•
Integrated Communication Adapter (lCA):
IBM 3275 Display Station Model 2 stand-alone control unit and display
station. A 3284 Printer Model 3 or 3286 Printer Model 3 can be attached.
To support this configuration, the following are required:
For the 3275 to be used on a switched line, Dial feature (#3440) is
required. The 3275 Dial feature does not support full screen
read/write.
Transmission Speed feature (#7820 or #7821)
A Printer Adapter feature (#5550), to attach a 3284 Printer Model 3
RPQ MB4317 is required to attach a 3286 Printer Model 3
Chapter 2. Configurations
23
3767 Features: Required and Desirable Features
The mM 3767 Communication Terminal, Models 1 and 2, is supported when it
operates as an mM 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 (#7113)
•
EBCDIC (#9391) or Correspondence (#9381) keyboard
•
Duplexed, switched or nonswitched line (#9404) for connecting to a Western
Electric 103A2 (or equivalent data set)
•
One of the following:
EIA Interface with Clock (#3719) at 300 bps
1200 bps Integrated Modem/Interrupt (#5505 or #5500 or #5506).
The following features, although not required, heighten the convenience and usability of the terminal:
•
Alternate Character Set (#1291), plus a defined character subset for the keyboard:
If the primary character set is Correspondence (#9381), the alternate character set can be APL (#9383) or EBCDIC (#9382).
If the primary character set is EBCDIC (#9391), the alternate character set
can be APL (#9393) or Correspondence (#9392).
Note: Line control is PTTC/EBCD with this feature.
•
Acoustic Coupler (#1110) at 300 bps.
Transmission Control Units
VM/SP supports the following transmission control units:
•
•
•
•
•
24
VM/SP Planning Guide and Reference
IBM 2701 Data Adapter Unit
IBM 2702 Transmission Control
IBM 2703 Transmission Control
mM Integrated Communications Attachment (ICA), (#4640)
IBM 3704,3705-1, and 3705-11 Communications Controllers.
2701 Required Features
•
For line control of CPT-TWX (Model 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 terminals, the following are required:
Synchronous Data Adapter Type 11(#7698)
EBCDIC code (#9060)
EBCDIC transparency (#8029)
•
For 1050 and 2741 terminals, the following are required:
IBM Terminal Adapter Type I, Model II (#4640)
Selective Speed, 134.5 bps (#9581)
2741 Break Feature RPQ #M53193, and Break Command RPQ #858492
•
The Expanded Capability feature (#3815) is required if there are:
More than two low speed adapters (either IBM Type I Model II, or Telegraph Type II), or
More than one high speed adapter (Synchronous Data Adapter Type II), or
One high speed and at least one low speed adapter attached to the same
2701.
•
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 1(#4615)
Selective Speed, 134.5 bps (#9684)
Type I Terminal Interrupt (#8200)
Data Set Line Adapter (#3233) or IBM Line Adapter (#4635), 4-wire IBM
Terminal Control Type 1(#4615).
•
For line control of CPT-TWX (Model 33/35) terminals and the 3101 display
terminals, the following are required:
Terminal Control Base for Telegraph Terminal Control (#9697)
Telegraph Terminal Control Type II (#7912)
Pluggable End Characters (return key generates an interrupt) RPQ
#E62920, optional
Data Set Line Adapter (#3233)
Chapter 2. Configurations
25
-
•
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 Feotures
•
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 Terminal Control Type I (#4696)
Line Speed Option, 134.5 bps (#4878)
Type I Terminal Interrupt (#8200)
Data Line Set (#3205) and/or IBM Line Set IB (#4687).
For line control of CPT-TWX (Model 33/35) terminals and 3101 display terminals, the following are required:
-
Telegraph Terminal Control Base (#7905)
-
Telegraph Terminal Control Type II (#7912)
-
Line Speed Option, 110 bps (#4877)
-
Data Line Set (#3205), and Data Line Set Expander (#3206)
Pluggable End Characters (return key generates an interrupt) RPQ
#E66707, optional.
•
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 Attachment (ICA) Required and Optional Feotures
The ICA (#4640) is available on the System/370 Models 135, 135-3, and 138.
Additional lines (#4722-4728) are supported.
•
For 1050, 2741, and 3767 (as a 2741) terminals, the following are required:
-
Terminal Adapter TYICe I Model 11(#9721-9728)
Switched Network Facility (#9625-9632), optional
Write Interrupt (#9745-9752)
Read Interrupt (#9737-9744)
Unit Exception Suppression (#9729-9730), optional
26
VM/SP Planning Guide and Reference
For the 3767 only, as a 2741, 200 bps (#2711-2718) or 300 bps
(#9593-9600).
•
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 (#9649-9656)
Half-Duplex Facility (#9617-9624)
EBCDIC Transparency (#9673-9680).
•
For line control of CPT-TWX (Model 33/35) terminals and 3101 display terminals, the following are required:
Telegraph Adapter Type II (#9785-9792)
Switched Network Facility (#9625-9632).
3704/3705 Required Features
IBM 3704 and 3705 Communications Controllers are supported in 2701, 2702,
2703 Emulation Program mode.
Note: VM/SP supports the CPT-TWX (Model 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.
VM/SP supports all models of 3704 and 3705 Communications Controllers. The
features required on a communications controller do not depend on VM/SP. Other 3704/3705 features depend on the planned use of the communications controller and the type of 3704/3705 control program (emulation) to be run.
VM/SP does not support the following 3704/3705 features:
•
•
•
Line Set Type 2A (#4721)
Line Set Type 3A (#4731)
Line Set Type 4B (#4742).
Other Considerations for Planning Your Configuration
Two-Channel Switch
If any I/O devices controlled by VM/SP for its exclusive use are attached to con-
trol units with two-channel switches, the processor or virtual machine controlling
the other channel interface must vary the CP-owned devices offline.
See "VM/SP Using Channel Switching" in Chapter 8 for more information about
using the two-channel switch.
IMultisystem Communication Unit
The IBM Multisystem Communication Unit is an input/output (I/O) device that
interconnects multiple systems by means of channels attached to a block
multiplexer channel. The 3088 is designed to be fully compatible with existing
channel-to-channel adapters (CTCAs). The 3088 may be used to form a loosely
coupled multiprocessing system connecting as many as eight processors.
Chapter 2. Configurations
27
In configurations using the 3088, the device must be defined using the ADDRESS
and DEVTYPE operands of the RDEVICE macro, and the ADDRESS, CUTYPE,
and FEATURE=xxx-DEVICE operands of the RCTLUNIT macro.
DniQ5 Used Only by IlII Operating System in II Yil1ulll MlIChine tlIId Not by YM/SP
Any input/output device that can be attached to the processor can be used by a
virtual machine under VM/SP 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
•
No violations of the other restrictions outlined in "Appendix D. VM/SP
Restrictions. "
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 machine's configuration require real
device equivalents, except for:
•
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 FOe
On 3031,3032, and 3033 processors, each console station of the 3036 system console has a 7443 diskette attached to it, which is usable 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.
When one console station serves as both operator and service console, there is no
SRF capability. 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.
Multiple Service Record Files
In a 3033 attached processor or multiprocessor system, there are two 3036 consoles. This configuration has four service record file devices (one console per station).
3033 attached processor and multiprocessor systems support more than one service
record file device. For VM/SP systems operating on a 3033AP or 3033MP, specify more than one SRF device 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.
28
VM/SP Planning Guide and Reference
In 3033 AP or MP systems with I/O configured asymmetrically to one processor, a
channel path must be available from the I/O processor to both SRF devices in
order to access the SRF devices in both 3036 consoles.
If an SRF device specified on the RIOGEN macro statement is found to be inac-
cessible during initialization of the error recording cylinders, an error message is
sent to the system operator. Processing continues without frames from that SRF
device in place on the error recording cylinders.
The RIOGEN macro statement produces an MNOTE warning message if you specify more than 32 SRF devices.
Pl'OCeSSor Controller
The 3081 Processor Complex uses a processor unit and a processor controller to
control system operations. The processor controller is a service processor that
defines the I/O configuration to the processor complex. To accomplish this, the
processor controller requires information about the real system configuration. You
define this information to the controller by running the Input/Output Configuration Program. For more information about the Input/Output Configuration Program, see "Input/ Output Configuration Program" in Chapter 8 and
"Considerations for Coding the Input/Output Configuration Source File" in Chapter 19.
Chapter 2. Configurations
29
30
VM/SP .Planning Guide and Reference
Chapter 3. Estimating VM/SP Storage Requirements
This section contains information about:
•
•
•
•
•
Estimating real storage requirements for VM/SP
Reducing the size of the CP nucleus
Estimating direct access storage requirements
Estimating storage requirements for CMS minidisks
Estimating storage requirements for the VM/SP directory
"Specifying a Virtual=Real Machine" in Chapter 10, includes information about
estimating real storage requirements for a virtual=real machine.
Real Storage Requirements for CP
Figure 2 lists various CP requirements and the amount of real storage required for
each.
CP Requirement
Real Storage Allocated
Resident nucleus
Approximately 235.5K3
Internal trace table
Conventionally, 4K of storage is allocated for each 256K of
real storage. This storage is set aside at IPL time. See the
"SYSCOR Macro" in Chapter 21 for details of how to increase
the size of the internal trace table.
Real control blocks
There is a control block for each real device, control unit, and
channel:
•
•
•
•
Permanently allocated free
storage (virtual control
blocks and tables). For
installation control of free
storage, use the SYSCOR
macro. For the format of
the SYSCOR macro see
Chapter 21.
104 bytes/real device
80 bytes/real control unit
96 bytes/real channel
40 bytes for each remote 3270 or real 3704/3705
The default value is a minimum of 12K, plus an additional 4K
for each 64K of real storage above 256K4. 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.
F'lgUI'e 2 (Part 1 of 2). Real Storage Requirements for CP
3
4
An additional 40K of real storage is allocated in AP or MP mode.
An additional 25 % of free storage is allocated in AP or MP mode.
Chapter 3. Estimating VM/SP Storage Requirements
31
CP Requirement
Real Storage AUocated
The storage required is:
•
•
•
•
•
•
•
568 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
72 bytes/virtual device
40 bytes/virtual control unit
48 bytes/virtual channel
Figure 1 (Part 1 of 1). Real Storage Requirements for CP
For example, if you have:
1M of real storage
29 real devices
6 real control units
3 real channels
and 12 virtual machines defined, each with:
1 virtual reader
1 virtual printer
1 virtual punch
3 virtual disks
3 virtual channels
1 virtual machine console
3 virtual control units
512K of virtual storage
you would estimate CP real storage requirements as follows:
235.5K
16K
4K
for the CP resident nucleus
for the CP internal trace table (see the SYSCOR macro in
Chapter 21)
for the real control blocks, calculated as follows:
104 X 29
= 3016 bytes for the real devices
80 X 6 = 480 bytes for the real control units
96 X 3 = 288 bytes for the real channels
the sum is: 3016 + 480 + 288 = 3784 bytes
(approximately 4K)
32
60K
for permanently allocated free storage (default value)
315.5K
real storage required
VM/SP Planning Guide and Reference
Also, as each of the 12 (512K) virtual machines defined logs on, approximately
3.0K of real storage is allocated to each from the permanently allocated free storage. A breakdown of this 3.0K of real storage is:
568
64
320
1088
72
72
72
216
144
72
120
bytes for a VMBLOK
bytes for the SEGTABLE
bytes for the PAGTABLE
bytes for the SWPTABLE
bytes for a virtual reader
bytes for a virtual printer
bytes for a virtual punch
bytes for three virtual disks
bytes for three virtual channels
bytes for a virtual machine console
bytes for three virtual control units
2808 bytes for each of the logged-on users defined
See "Specifying the Amount of Virtual=Real Space" in Chapter 10, for an example of estimating storage requirements and determining the maximum virtual = real
area size.
Reducing the CP Nucleus Size
You can use the small CP option to reduce the size of the CP nucleus. A response
of "YES" to the GENERATE EXEC question:
DO YOU WANT THE SMALL CP OPTION?--RESPOND (YESINO)
during the system generation process, causes CPLOADSM EXEC to be used in
place of the CPLOAD EXEC. The CPLOADSM EXEC removes V =R support,
AP /MP support, and support for the following:
Support
Number
of Bytes·
Missing interrupts
MVS Guest
SNA(CCS)
1,700
7,200
14,100
TTY terminal support
3066
Remote 3270
300
1,500
14,600
3340 Alternate Track
3375/3380
3704/3705
3850MSS
3800 printers
1,800
4,700
6,300
3,800
1,400
Modules Removed
DMKDID
DMKFPS, DMKQVM, DMKVSCs
DMKVCP, DMKVCR, DMKVCT,
DMKVCV, DMKVCX
DMKTTZ
DMKGRH
DMKRGA, DMKRGB, DMKRGC,
DMKRGD
DMKTRK
DMKDAD
DMKRNH
DMKSSS, DMKSSU
DMKVSV
*Approximate
S
Removal of module DMKVSC also removes V -R support.
Chapter 3. Estimating VM/SP Storage Requirements
33
Removal of the support listed in the preceding table reduces the CP resident nucleIf you need any of the support listed in the
table, reply "NO" when asked:
I us by approximately 57,400 bytes.
DO YOU WANT THE SMALL CP OPTION?--RESPOND (YESINO)
Note: The GENERATE and VMFLOAD commands, and the CPLOAD and
CPLOADSM loadlists are described in the VM/SP Installation Guide. If you want
a smaller CP nucleus, but require some of the function removed by using the small
CP option, you can tailor the loadlist to your own specifications. Edit the
CPLOAD loadlist to remove only modules that are associated with functions (refer
to the small CP option table above) that you do not require. The CP nucleus will
be reduced by the amounts shown in the Small CP option table.
The graphic device support for locally attached terminals is handled by the module
DMKGRF. Removal of local graphics support is not a part of the Small CP option.
If you do not require local graphics support, you may remove the module
DMKGRF and reduce the CP resident nucleus by approximately 10,300 bytes.
Caution should be exercised before removing the modules from the loadlist. If you
generate a system that includes a device in the 110 configuration, you cannot
remove the modules associated with that device from the loadlist. If you do remove
those modules, unpredictable results may occur.
The following names are undefined during the VMFLOAD procedure if DMKTRK
is removed from the loadlist:
DMKTRKIN
DMKTRKFP
DMKTRKVA
The following names are undefined during the VMFLOAD procedure if DMKRNH
is removed from the loadlist:
DMKRNHIC
DMKRNHND
DMKRNHTR
DMKRNHIN
DMKRNH
The following names are undefined during the VMFLOAD procedure if
DMKRGA, DMKRGB, DMKRGC, and DMKRGD are removed from the loadllst:
DMKRGADH
DMKRGAIN
DMKRGBEN
DMKRGBFM
DMKRGBIC
DMKRGC
DMKRGDOB
DMKRGDOI
The following names are undefined during the VMFLOAD procedure if DMKSSS
and DMKSSU are removed from the loadlist:
DMKSSSAS
DMKSSSCA
DMKSSSCV
DMKSSSDE
DMKSSSEN
34
VM/SP Planning Guide and Reference
DMKSSSHR
DMKSSSL1
DMKSSSL2
DMKSSSL3
DMKSSSLN
DMKSSSMQ
DMKSSSNS
DMKSSSNV
DMKSSSRL
DMKSSSVA
DMKSSSVM
DMKSSUCF
DMKSSUI1
DMKSSUI2
DMKSSULO
The following names are undefined during the VMFLOAD procedure if modules
DMKFPS, DMKVSC and DMKQVM are not on the loadlist:
DMKQVMRT
DMKFPS
DMKQVMEP
DMKVSC
DMKVSCVR
DMKQVMTS
DMKQVMCU
The following names are undefined during the VMFLOAD procedure if
DMKVCP, DMKVCR, DMKVCT, DMKVCV, and DMKVCX are removed from
the loadlist:
DMKVCPIL
DMKVCRNR
DMKVCRRD
DMKVCVER
DMKVCRWT
DMKVCTLO
DMKVCTCH
DMKVCTER
DMKVCTEN
DMKVCTDA
DMKVCTCN
DMKVCTSV
DMKVCTQS
DMKVCTRM
DMKVCXIO
DMKVCRMT
The following name is undefined during the VMFLOAD procedure if DMKDAD is
removed from the loadlist:
DMKDADER
The following name is undefined during the VMFLOAD procedure if DMKTTZ is
removed from the loadlist:
DMKTTZLF
The following name is undefined during the VMFLOAD procedure if DMKVSV is
removed from the loadlist:
DMKVSVLD
The following names are undefined during the VMFLOAD procedure if DMKGRF
is removed from the loadlist:
DMKGRFIN
DMKGRFMT
DMKGRFIC
DMKGRFEN
DMKGRF
The following name is undefined during the VMFLOAD procedure if DMKGRH is
removed from the loadlist:
DMKGRHIN
If you do not use the NAMENCP macro statement, label DMKSNTRN is undefined during the VMFLOAD procedure.
If you do not use the NAME3800 macro statement, label DMKSNTQN is undefined during the VMFLOAD procedure.
The following names ar~ undefined during the VMFLOAD procedure when you
remove DMKDID from the load list:
DMKDIDDA
DMKDIDGR
DMKDIDTA
DMKDIDUR
DMKDIDMS
DMKDIDEP
DMKDIDTR
Chapter 3. Estimating VM/SP Storage Requirements
35
Direct Access Storage Requirements for CP
In the following paragraphs and in "Part 2. Defining Your VM/SP System," there
are many references to "DASD space." With the support of fixed block DASD
architecture, it is important to understand the fundamentals of "DASD space" to
avoid confusion when dealing with various DASD types.
It is helpful to understand CP's requirements for DASD space in general. It is also
helpful to understand the differences a~d similarities between CP's view of
count-key-data (CKD) DASD and fixed block (FB-512) devices.
eKD - (2314, 2319, 3330, 2305, 3340, 3350, 3375, and 3380)
FB-512 - (3310 and 3370)
CP's reference to DASD space is always done in units called DASD pages. A
DASD page is 4096 bytes of contiguous DASD storage. This means that CP
requires that all its DASD space (nucleus, error recording, warm start data, checkpoint data, directory, saved systems, dump space, paging, and spooling space) be
formatted as 4096 byte records (pages). CP also requires that you identify what
specific pages on DASD are allocated to each type of CP reference. For example,
you must identify pages for the nucleus, for paging, for the directory, and so forth.
CP provides the Format/Allocate service program (DMKFMT) to perform these
formatting and allocating functions. A DASD volume containing any of the types
of space listed above is called a CP volume and must be processed by the
Format/ Allocate service program. Space not used by CP on CP-owned volumes is
available to you. Typically, although not necessarily, this space is used for user
minidisks. CP has no format requirements for this space, but does require that it be
allocated.
CKD Dnice Geometry
CP views CKD devices by their geometric characteristics, ego as a certain number
of cylinders. Each cylinder has a fixed page capacity, meaning that a fixed number
of 4K records "fit" on a cylinder. This number varies for each CKD DASD type.
CP references its data by a cylinder number and a page number on that cylinder.
For CP space you must format and allocate pages in groups of cylinders. In
"Chapter 21. Preparing the CP System Control File (DMKSYS)," you are asked to
figure your particular DASD requirements as a number of records or pages, then
convert this number to an equivalent number of cylinders. This means dividing the
page requirement by the number of pages per cylinder for your particular device
type. Allocating space for minidisks on CP-owned volumes is also done in units of
cylinders. Use of space within this allocation is also done in units of cylinders via
the MDISK directory control statement. This is convenient in that no conversion is
required in this case.
36
VM/SP' Planning Guide and Reference
FB-512 Device Geometry
I
FB-512 devices appear as a linear address space of 512-byte blocks. The blocks
are consecutively numbered from 0 to n, where n is the highest block number on
the volume. CP groups 8 consecutive blocks to form a CP page. CP then views
the volume as a collection of pages numbered from 0 to (n-8)/8. For example,
blocks 0-7 make up page O. There is no concept of cylinder boundaries in this
structure.
You must allocate space on FB-512 volumes in units of pages (contrasted to the
unit of cylinder on CKD). When you figure your DASD space requirements as a
number of pages, you can use these numbers directly in the system generation
macros and in the Format/Allocate service program. No conversion to other units
is required.
Although convenient for CP DASD space, this causes an inconvenience when
assigning minidisks because of the difference in the unit of input between the Format/ Allocate service program (pages) and the MDISK control statement (blocks).
When assigning minidisk space, you must know the extents of your available space
in block numbers. Be careful that you provide input to Format/Allocate in page
numbers and assign minidisks by block number.
To obtain the corresponding block number, take the allocation results, which show
page numbers, and multiply the page number by 8. For example, in the sample
layout for a 3310 shown below, pages 2000 through 9999 were allocated as PERM
space for use as minidisks. The allocation results would show:
PERM
2000
9999
This corresponds to block numbers 16000 through 79999 by doing the following:
For the beginning block number:
Multiply 2000 (1st page) X 8 (8 blocks per page) =
16000 (beginning block Number)
For the ending block number:
Multiply 9999 X 8 = 79992, which is the 1st block of
the last page.
Add 79992 + 7 (remaining blocks in last page) =
79999 (last block in last page)
Chapter 3. Estimating VM/SP Storage Requirements
37
The block numbers must be used on the MDISK statement.
BLOCK
I
I
IIl
126015
99 1100
15751
I
PAGE
Pages 0 and 1 are reserved (see the VM/SP Operator's Guide for details)
Pages 2-99 for directory (DRCT)
Pages 100-1999 for nucleus and error recording (PERM)
Pages 2000-9999 for minidisks (PERM)
Pages 10000-15751 for paging and spooling (TEMP)
The following is an example of defining three minidisks within the range of PERM
space:
MDISK 191 FB-512 16000 2000 LABEL
MDISK 19F FB-512 18000 5000 LABEL
MDISK 296 FB-512 23000 7000 LABEL
DASD Space Requirements
Figure 3 shows minimum CP DASD space requirements by DASD type. The following paragraphs describe in detail how you determine the DASD space CP
requires for the nucleus, error recording, warm start data, checkpoint data, directory, saved systems data, paging, and spooling space.
CP Nucleus
Error Recording6
Warm Start
Checkpoint Start
Directory
Saved Systems
Paging Space
Spooling Space
Total System7
3330
2305
3340
3350
3375/
3380
FB-512
varies
2
1
1
4
varies
18
30
varies
2
1
3
2
varies
40
varies
2
1
3
10
varies
40
70
varies
2
1
1
2
varies
10
15
varies
2
1
1
4/2
varies
10/11
15/20
varies
114
57
57
228
varies
1000
1700
33/37 cyl
3156 pgs
56cyl
48 cyl
126 cyl
31 cyl
Figure 3. DASD Space Requirements by DASD Type
CP Nucleus DASD Requirements
The CP nucleus (without a virtual=real area) requires about 220 pages of disk
space for resident and pageable functions.
6
7
38
VM/SP ! Planning Guide and Reference
The default is 2 cylinders but up to 9 cylinders may be specified via the SYSERR operand of the
SYSRES macro.
These figures do not include space for the nucleus or saved systems.
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. When you have a system with a V=R area,
you should subtract the page numbers of the V =R area from the last module page
number to find the size of CP in pages.
For example, if the last module entry in the load map ends at page DC
(hexadecimal), 220 pages of disk space are required for CP nucleus residence, since
hex DC converts to decimal 220. 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:
10 cylinders on a 2305 or 3340
4 cylinders on a 3330 or 3333
2 cylinders on a 3350
3 cylinders on a 3375
2 cylinders on a 3380
The amount of space required on FB-512 devices is equal to the number of pages
as computed above.
E17'Or Recording DASD Requirements
Error recording space varies from 2 to 9 cylinders and is established by the
SYSERR operand of the SYSRES macro instruction as described in Chapter 21.
Warm Start Data DASD Requirements
Formulas for calculating the warm start space needed are under the discussion of
the SYSWRM operand of the SYSRES macro in Chapter 21.
Cheekpoint Start Data DASD Requirements
The space required for dynamic checkpointing of the VM/SP spool file system is
discussed under the description of the SYSRES macro in Chapter 21.
Dump Space DASD Requirements
This space is optional. If you want to use the dump area for CP, format the area
and allocate it as DUMP using the Format/Allocate program. The size should
normally be large enough to contain an entire dump of CPo If no DUMP space is
allocated, spooling space (TEMP) will be used for dumps.
The following formula may be used to approximate the amount of DASD dump
space needed:
Number of pages (FBA)
number of pages real memory + 5
Number of cylinders (CKD)
number of pages real memory + 5
number of pages/cylinder
Chapter 3. Estimating VM/SP Storage Requirements
39
The number of pages per cylinder for the various CKD DASD devices is listed
under the heading "Paging and Spooling DASD Requirements" later in this
chapter.
Allocating DASD Space for the YM/SP Directory
The VM/SP directory normally requires two cylinders so that it can be rewritten
without disturbing the active directory and swapped after a successful update.
Before you create a VM/SP 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 space to be used for the
VM/SP directory. The space must be allocated DRCT. To calculate the total
space required, first calculate the total number of records used:
NR
=
((NU + NM) x 2) + all other control statements
NU
+
170
169
where:
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) required:
•
For 2314,2319: NC = NR/32
•
For 2305,3340: NC = NR/24
•
For 3330: NC
•
For 3350: NC = NR/120
•
For 3375: NC
= NR/96
•
For 3380: NC
= NR/150
•
For FB-512: the space required is equal to NR
= NR/57
Note: You should initially format and allocate enough space for two VM/SP 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/SP directory is written to a count-key-data DASD, space is allocated from
the available cylinders on a cylinder-by-cylinder basis, and a minimum of two cylinders is used as DRCT space.
When a directory is written to an FB-512 DASD, the space allocation proceeds as
follows:
40
VM/SP Planning Guide and Reference
•
If there are already two DRCT extents (one in use and the other available for
use) the new directory is written to the available extent. The available extent is
flagged as in use, and the previously in use extent is flagged as available (the
directories are swapped).
•
If there is only one DRCT extent (it must be available), an attempt is made to
divide it into two DRCT extents, allowing succeeding directories to be
swapped. This is done as follows:
1. If insufficient space is specified for the current directory, it is not written to
the DASD volume.
2. If sufficient space exists, the directory program attempts to divide it into
two equally sized DRCT extents (one to hold the current directory and one
to be available for future swapping of directories).
3. If there is not enough space to create two equally sized DRCT extents, the
current directory is built and the remaining space is reserved as available
DRCTspace.
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.
Saved System DASD Requirt!lllents
Saved systems require one page for each page saved, plus an additional information
page. However, a 3704/3705 may require up to four additional information pages.
Saving one copy of the CMS system requires:
5 cylinders on a 2314 or 2319
3 cylinders on a 3330 or 3333
6 cylinders on a 3340
2 cylinders on a 3350
2 cylinders on a 3375
1 cylinder on a 3380
138 pages on an FB-512
Paging and Spooling DASD Requirements
Paging and spooling space requirements are installation dependent. (Values shown
in Figure 3 on page 38 are examples.)
Paging space is allocated at a rate of:
24 pages/cylinder on a 2305 or 3340
32 pages/cylinder on a 2314 or 2319
57 pages/cylinder on a 3330 or 3333
120 pages/cylinder on a 3350 in native mode
96 pages/cylinder on a 3375
150 pages/cylinder on a 3380
(The 2305 is normally used for paging only.)
Chapter 3. Estimating VM/SP Storage Requirements
41
Paging space is dependent on the number and size of logged-on virtual machines,
processor storage size, and workload. In general, the following calculation will
yield adequate paging space.
number of logged-on users x average virtual machine size
(in 4k pages) = number of pages needed.
Thus, aIM processor with 10 logged-on users having an average virtual machine
size of 500K would require 994 pages of DASD space for paging [(10 x 125) - 256
= 994]. This would take 7 cylinders of a 3380 (994/150 = 6.6). Spooling data is
placed in a 4K buffer with the necessary channel programs required for each
record. Data capacity of spooling cylinders thus varies with the data and CCWs
used.
The examples in Figure 3 on page 38 assumed a maximum of 200 spool files of 8-9
blocks each. If separate DUMP space is not allocated, spooling space (TEMP) will
be used for dumps.
The primary system operator is warned when the paging/spooling space becomes
90% full. VM/SP System Messages and Codes tells the operator what to do if this
warning occurs.
Facilities exist to dump spool files to tape when the spool space is full or nearly full.
When spool space is again available, the system operator can restore the dumped
spool files to the system for processing.
VSAM and Acceu Method Services Requirements
VSAM and Access Method Services support in CMS requires both DASD space
and virtual storage.
The DASD space needed is listed under "Loading and Saving Discontiguous Segments" in the VM/SP Installation Guide.
VSAM and Access Method Services support adds approximately 2K to the size of
the CMS nucleus. In addition, this support uses free storage to run the VSE logical
transients, and for buffers and work areas. VSAM issues a GETVIS macro to
request free storage.
If CMS/DOS is entered with the VSAM option
SET DOS ON (VSAM
part of the CMS/DOS virtual storage is set aside for VSAM use.
42
VM/SP Planning Guide and Reference
Estimating DASD Storage Requirements for eMS Minidisks
The following information is provided to help you allocate enough direct access
storage space for CMS minidisks.
Device Type
2314
3310
3330
3340
3350
3370
3375
3380
Approximate
80-byte lists
1300 per cylinder
6.4 per 512-byte block
2300 per cylinder
960 per cylinder
5000 per cylinder
6.4 per 512-byte block
3200 per cylinder
6250 per cylinder
Each physical disk contains file control information as well as your data. Data
requires more file control information if put into many small files instead of a few
large files.
For an average CMS user, the following minidisk space should be sufficient:
Device Type
2314
3310
3330
3340
3350
3370
3375
3380
Space Required
7 cylinders
1700 512-byte blocks
4 cylinders
11 cylinders
2 cylinders
1700 512-byte blocks
3 cylinders
2 cylinders
Chapter 3. Estimating VM!SP Storage Requirements
43
44
VM/SP Planning Guide and Reference
Chapter 4. Planning for CMS
The Conversational Monitor System (CMS) provides conversational facilities for
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.
eMS Storage Requirements
CMS requires virtual storage and auxiliary storage. A minimum of 1 megabyte of
virtual storage is recommended for a CMS virtual machine. This virtual storage is
distributed as follows:
CMS buffers, pointers, and control blocks (DMSNUC)
- 20K
•
Loader tables
8K (for virtual machines with up to 384K of virtual storage)
12K (for virtual machines with more than 384K of virtual storage)
•
User area
120K (for application programs or CMS disk-resident commands)
•
CMS free storage
lOOK
•
Transient area
- 8K (CMS disk-resident commands)
Auxiliary Storage
The CMS auxiliary storage requirements are:
•
System residence for CMS (190 minidisk) 100 cylinders on a 3330 or 3333,
236 cylinders on a 3340 Model 35 or Model 70,
49 cylinders on a 3350 in native mode,
74 cylinders on a 3375,
45 cylinders on a 3380,
45,568 blocks on an FB-512.
Note: The CMS system and the CMS and CMSL nuclei reside on the 190
minidisk.
•
Resident disk space for application programs (CMS commands, user programs,
IBM program products) - the space needed is program-dependent, and must
be assigned by you.
•
Work space for application programs (CMS commands, user programs, mM
program products) - the space needed is program-dependent, and must be
assigned by you.
Chapter 4. Planning for CMS
45
Device Support
CMS supports the virtual machine devices shown in Figure 4.
Virtual IBM
Device Type
Virtual
Addressl
SymboUc
Name Default
Device Use
3210, 3215, 1052,
3066,3270
cuu2
CONI
System console
2314,2319,3310,
3330, 3340, 3350,
3370,3375,3380
190
191 3
cuu
cuu
192
cuu
cuu
cuu
19E
cuu
cuu
cuu
cuu
cuu
cuu
cuu
cuu
cuu
cuu
cuu
cuu
cuu
cuu
cuu
cuu
cuu
DSK8
DSKI
DSK2
DSK3
DSK4
DSK5
DSK6
DSK7
DSK9
DSKO
DSKH
DSKI
DSKJ
DSKK
DSKL
DSKM
DSKN
DSKO
DSKP
DSKQ
DSKR
DSKT
DSKU
DSKV
DSKW
DSKX
CMS System disk (read-only)
Primary disk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user· files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
Minidisk (user files)
2540,2501,3505
OOC
RDRI
Virtual reader
2540,3525
OOD
PCHI
Virtual punch
1403, 1443, 3203,
3211,3262,3800,
4245, 3289-4
OOE
PRNI
Line printer
2401, 2402, 2403,
2415,2420,3410,
3411, 3420, 3430,
8809
181-4
TAPI-TAP4
Tape drives
Figure 4. Devices Supported by a eMS Virtual Machine
lThe device addresses shown are those that are preassembled into the CMS resident device table. These need only be modified and a new device table made resident to change the addresses.
2The virtual address of the system console may be any valid multiplexer address.
3191 is the default user-accessed A-disk unless it is dynamically changed by an
ACCESS at CMS initial program load (IPL).
46
VM/Sp· Planning Guide and Reference
Under CP, unit record devices and the system console may be simulated and
mapped to addresses and devices other than the real ones. For instance, CMS
expects a 3215, 3210, 1052, or 3270 type of operator's console, but some terminals are 2741 s. Regardless of the real device type, the virtual system console is a
3215. The control program (CP) of VM/SP handles all channel program modifications necessary for this simulation. CMS virtual disk addresses are mapped by CP
to different real device addresses.
CMSDisks
The read-only CMS system disk (S-disk), normally located at virtual address 190,
contains the CMS nucleus functions and disk-resident CMS command modules.
The CMS nucleus is loaded into virtual storage when you issue the CP IPL command. CMS remains resident until you enter another IPL command or until you
log off. The disk-resident modules are loaded into virtual storage only when their
services are needed.
In addition to the system disk (S-disk) and primary disk (A-disk), each CMS user
can have up to 24 additional disks. The read/write A-disk is the primary user 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. For more information
about CMS disks and their use, see the VM/SP eMS User's Guide.
Chapter 4. Planning for CMS
47
eMS Libraries
CMS supports simulated partitioned data sets that contain:
•
CMS and OS macro/copy files to be used at compilation or assembly time
(source/macro libraries). The CMS filetype for these files is MACLIB.
•
Object routines to be referred to at load and/or execution time (text libraries).
The CMS filetype for these files is TXTLIB.
•
Executable routines that are loaded by OS SVCs that CMS simulates. The
CMS filetype for these files is LOADLIB.
•
Executable routines that are fetched by DOS SVCs that CMS simulates. The
CMS filetype for thses files is DOSLIB.
System Macro Libraries
The system macro libraries, located on the CMS system disk, are:
Library
Contents
DMSSP MACLIB
CMS and DOS macros versioned by VM/SP
CMSLIB MACLIB
CMS macros not versioned by VM/SP
OSMACRO MACLIB
The selected OS macros from SYS 1.MACLIB that
are supported under CMS
OSMACROI MACLIB
The remaining distributed OS macros from
SYSl.MACLIB
. OSVSAM MACLIB
A subset of OS/VS VSAM macros that are supported under CMS
TSOMAC MACLIB
The OS macros distributed in SYS1.TSOMAC
DOSMACRO MACLIB
Internal macros used by CMS/DOS support routines
If you have previously created a CMS macro library and called it DOSMACRO
MACLIB, you should rename it so that it does not conflict with the DOSMACRO
MACLIB supplied with the system.
If you plan to assemble VSE programs containing VSE macros in CMS/DOS, you
must first create a CMS macro library that contains all the VSE macros you need.
The VM / SP Installation Guide contains a procedure for copying an entire macro
library. The procedure for copying individual macros is described in the VM/SP
eMS User's Guide.
If you plan to assemble VSE programs containing VSE/VSAM macros, you must
first create a CMS MACLIB containing the VSE/VSAM macros. An EXEC
named VSEVSAM is distributed with VM/SP that can be used in conjunction with
the VSE/VSAM optional source distribution tape to create such a library. See the
VM / SP Installation Guide for additional information on the VSEVSAM EXEC.
48
VM/SP Planning Guide and Reference
System Text Libraries
The system text libraries, located on the CMS system disk, are:
Library
Contents
CMSLIB TXTLIB
The CMS system text library
TSOLIB TXTLIB
Selected TSO routines necessary to support certain
features of the language program products
Other Libraries
Also located on the CMS system disk is the CMSBAM DOSLIB, used to build the
CMSBAM discontiguous saved segment used with CMS/DOS, and the PROPLIB
. LOADLIB, which supports the Programmable Operator Facility.
I
Execution-time libraries are available with the program product language processors.
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.
CMS Command Language
The CMS command language lets you converse with CMS. With this command
language, you can use:
•
•
•
•
•
•
•
Language compilers
An assembler
CMS file management system
Context editing and line editing
Execution control
Debugging capability
Generalized HELP facility
Additionally, you can use the CP commands available to all virtual machines under
VM/SP directly from CMS. Using these CP commands, you can send messages to
the operator or to other users, change your virtual machine's configuration, and use
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 VM / SP CMS Command and Macro Reference and the
VM/ SP CMS User's Guide.
Chapter 4. Planning for CMS
49
CMS Program Language Facilities
The languages available under CMS include:
S/370 Assembler
VS BASIC
PL/I
OS FORTRAN IV
OS/VS COBOL
DOS PL/I Optimizer
DOS/VS COBOL
VSAPL
DOS/VS RPG II
The assembler is distributed with VM/SP. The language compilers that are program products must be ordered separately. For a complete list of language
processors that can be run under CMS, see "Appendix A. Licensed Programs and
Integrated Emulators."
CMS runs the compilers via interface modules. Users should always recompile
their programs and compiler interfaces under the system they are running on to
insure any interface changes are incorporated (i.e., control block changes). CMS
commands are provided to use the compilers within the conversational environment
of CMS.
Limited Support of OS and VSE in CMS
Object programs (TEXT files) produced under CMS or OS can be executed under
CMS if they do not use certain OS functions not simulated by CMS. 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 OS disks can be read by OS programs running under CMS. Also, certain CMS commands can be used to process
data sets on OS disks.
CMS simulates the control blocks, supervisor and I/O macros, linkage editor and
fetch routines necessary to compile, test, and run VSE programs under CMS. The
support for the VSE user is comparable to that for the OS user.
CMS supports VSAM and Access Method Services for VSE and OS users. Refer
to the VM / SP CMS Command and Macro Reference for the restrictions on using
VSE/VSAM and Access Method Services in CMS.
CMS supports the VSE/VSAM macros and their options and a subset of the
OS/VSAM macros.
CMS/DOS support of VSAM is based on the VSE/VSAM program product.
Application programmers who normally use CMS to interactively create, modify,
and test programs may require facilities not supported in CMS (for example, an OS
program using ISAM). They can alternately run CMS and another operating system in the same virtual machine.
50
VM/SP Planning Guide and Reference
A description of the actual processes for reading OS or VSE files is in the VM/SP
CMS User's Guide. A description of alternating operating systems is in VM/ SP
Operating Systems in a Virtual Machine.
DL/I in the eMS/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
RPGII
Assembler language
You can run any data base description generation and program specification block
generation. The data base recovery and reorganization utilities must be run in a
VSE virtual machine.
For more information, see the VM/SP CMS User's Guide, and DL/I DOS/VS
General Information, GH20-1246.
eMS Disk and File Management
CMS can manage up to twenty-six virtual disks for each user. These disks may be
minidisks or full packs. Moreover, they may be in:
•
•
•
CMS format
OS or VSE format
VSAM format
When VM/SP MSS support is installed, and the VM/SP processor is attached to
an MSS, any CMS virtual disk can be located on an MSS 3330V volume.
CMS 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 written using
other operating systems.
OS and DOS disks or minidisks may be used in CMS. OS or VSE programs running in CMS may read data sets or files on OS or DOS disks, but may not write or
update them. OS and DOS minidisks can be formatted with the Device Support
Facility, or with an appropriate OS/VS or VSE disk initialization program, if the
disk is a full pack.
Minidisks for use with VSAM must be formatted with DSF. Full disks must be initialized using the appropriate OS/VS, DSF, or VSE disk initialization program.
Disk Acceu
Disks can be accessed so that files can only be read (read-only), or so that files can
be read and written (read/write).
Both CP and CMS can control read/write access. If a disk is designated
read/write by CP, then CMS determines if the access is read or write. If a disk is
designated read-only by CP, then it can only be read by CMS.
Chapter 4. Planning for CMS
51
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 VM/SP directory entry, or it can be acquired
with the CP LINK or DEFINE commands.
•
Identify the disk to CMS by assigning it a filemode letter. You do this using
the ACCESS command in CMS.
You may have many virtual disks known to CP in your virtual machine configuration at one time. CMS allows a maximum of twenty-six to be accessed, with
filemode letters A through Z. The S-disk (usually at virtual address 190) is the
CMS system disk. The A-disk (usually at virtual address 191) is your primary
read/write work disk. Disks may be 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 CMS
disks be used with multiple-write access.
eMS Disk File Format
All 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.
A disk can be formatted into one of five disk block sizes:
512, 800, 1024, 2048, or 4096 bytes.
Count-key-data devices use an 800 byte format to provide compatibility with earlier releases. The volume label is written on record 3 of cylinder 0, track 0 for
count-key-data devices, and on block one (origin zero) for FB-512 devices. The
volume label contents depends on the formatting block size as detailed in Figure 5.
52
VM/SP' Planning Guide and Reference
Byte
Displacement
Length
Field
Description
Contents by
Disk Block Size
(800 byte)
,Contents by
Disk Block Size
(512, lK, 2K, 4K byte)
Label identifier
0,4
C'CMS='
C'CMS1'
Volid
4,6
user label
user label
Version identifier
10,2
X'OOOO'
X'OOOO'
Disk block size
12,4
not used, zeros
F'512', F'1024',
F'2048', or F'4096'
Disk origin pointer
16,4
not used, zeros
F'4' or F'5'
Number of usable cylinders/blocks
20,4
not used, zeros
F'n'
Maximum number of formatted
cylinders/blocks
24,4
not used, zeros
F'n'
Disk size in CMS blocks
28,4
not used, zeros
F'n'
Number of CMS blocks in use
32,4
not used, zeros
F'n'
FST size in bytes
36,4
not used, zeros
F'n'
Number of FSTs per CMS block
40,4
not used, zeros
F'n'
Disk FORMAT date
44,6
not used, zeros
X'yymmddhhnunss'
Reserved for IBM use
50,2
not used, zeros
not used, zeros
Disk offset when reserved
52,4
not used, zeros
F'n'
Reserved for IBM use
56,24
not used, zeros
not used, zeros
Figure 5. Volume Label Contents for CMS Formatted Disks
On count-key-data devices, each 512-,800-, lK-, 2K-, or 4K-byte block (called
CMS block in the following discussion) represents one physical record of that size
on disk. For FB-512 devices, each CMS block consists of the appropriate number
of contiguous FB-512 (512-byte) blocks, logically concatenated to form the correct
number of data bytes for that CMS block. The 800-byte disk format is not supported for FB-512 devices.
I
Files placed on CMS disks can have logical records that are fixed or variable
length. In either case, the CMS file system places these file records contiguously
into fixed length CMS blocks, spanning blocks where necessary. As a file grows or
contracts, its space is expanded or reduced as needed.
Files on a CMS disk are identified by means of a file directory. The file directory is
updated when a command is issued that changes the status of the file on the disk.
I For a minidisk formatted in 512-, 1024-,2048-, or 4096-byte CMS blocks, a single
CMS file can contain up to approximately (231 -1)-132,000 disk blocks of data,
grouped into as many as 231-1 logical records, all of which must be on the same
Chapter 4. Planning for CMS
53
minidisk. The maximum number of data blocks available in a variable format file
on a 512-byte blocksize minidisk is about 15 times less than 231_1. This number is
the maximum number of data blocks that can be accessed by the CMS file system
due to its 5-level tree structure.
To ensure that the saved copy of the S-STAT or Y-STAT is current, a validity
check is performed when a saved system is IPLed. This check is performed only
for S-DISKs and Y-DISKs formatted in 512-, 1024-,2048-, or 4096-byte CMS
blocks. For 800-byte block disks, the saved copy of the S-STAT or Y-STAT is
used. The validity checking consists of comparing the date when the saved directory was last updated with the date when the current disk was last updated. If the
dates for the S-STAT are different, then the S-STAT is built in user storage. If the
dates for the Y-STAT are different, then the Y-disk is accessed using the CMS
ACCESS command: ACCESS 19E Y/S * * Y28• This means that even when the
S- and Y-disks are accessed in read/write mode and then RELEASED, the message DMSINS100W S-STAT and/or Y-STAT NOT AVAILABLE will result.
OTHER RESTRICTIONS:
Maximum number of files
per mini disk
(exceptions - 2314,2319)
3400
(3500)
Maximum number of logical records
per file
65,535
Maximum number of data bytes per
file
12,848,000 bytes
or 16,060 CMS blocks
Maximum number of 800-byte CMS
blocks per minidisk.
65,535
Minidisk allocated
on device type
2314/2319
3330
3340 model 35
3340 model 70
3350
3375
3380
Number of 800-byte
blocks per cylinder
150
266
96
96
570
360
540
Maximum usable minidisk
size in cylinders
203
246
348
682
115
182
121
Figure 6. CMS Disk Fde Statistics for 800-byte CMS Blocks
There are more restrictions for a minidisk formatted in 800-byte physical blocks.
A minidisk cannot contain more than 3500 files if it is allocated on a 2314/2319,
and not more than 3400 files for all the other DASDs supported by CMS. A single
file can contain up to 12,848,000 bytes of data only, grouped into as many as
65,535 logical records. The number of 800-byte CMS blocks is limited to 65,535
per minidisk. This results in a maximum usable minidisk size in terms of cylinders
depending on the DASD type. Figure 6 compares the disk devices supported by
CMS in the case of 800-byte CMS blocks.
I'
54
VM/SP Planning Guide and Reference
The DASD address of the Y-DISK will be whatever was specified when eMS was generated. For
the standard system this will be 19E.
Identifying Disk Files
CMS commands can list the identifications of files on CMS and non-CMS formatted disks and minidisks. The LISTFILE and FILELIST commands list the entries
in the master file directory f~r CMS disks. The LISTDS command lists the entries
in the VTOC (volume table of contents) for OS and DOS disks, or 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,
13420, 3430, or 8809 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
only, the tape recording technique (odd or eyen parity, converter on or off, and
translator on or off).
If you do not specify the mode set for a 7-track tape, CMS issues a mode set 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, the featured
density (800, 1600,6250 bpi) is assumed.
As an alternative to specifying mode in each command that uses the tape, ego
FILEDEF, you can issue a CMS TAPE MODESET command.
For example:
TAPE MODESET (181 9TRACK DEN 6250
TAPE MODESET sets the mode for the tape, which stays in effect until the command is reissued. You must do this if one of your programs is to use tapes in other
than the default mode.
.
Read the section "Tape Labels in CMS" in the VM/ SP eMS User's Guide carefully before using labeled tapes in eMS. The CMS tape label processing features
described there allow you to specify tape files with IBM standard or non-standard
labels, or to bypass label processing for non-labeled tapes.
Multivolume tape files are not supported by CMS.
Note: These restrictions only apply when you run CMS. VSE and OS systems
running in virtual machines can continue to read and write tapes with standard
labels, non-standard labels, or no labels on single and multi-reel tape files.
The VM/SP operator must attach tape drives to your CMS virtual machine before
any tape operation can take place.
For information about tape handling in the CMS/DOS environment, see "Chapter
7. Planning for CMS/DOS."
Chapter 4. Planning for CMS
55
CMS Unit Record Support
CMS supportS:
•
•
•
one virtual card reader at virtual address OOC
one virtual card punch at virtual address OOD
one virtual printer at virtual address OOE
Under VM/SP, these devices are spooled. CMS does not support real or dedicated
unit record devices, nor does it support a virtual 2520 Card Punch. Figure 4 on
page 46 lists the devices supported as virtual devices by CMS.
SavingCMS
CMS is designed to be used as a shared system. The default DMKSNT entry
places the CMS nucleus from location X'190000' to X'200000'. It is intended that
the CMS nucleus is shared at a location above the average virtual machine size for
your installation. If a user's virtual machine size extends beyond the start location
of the CMS nucleus, then the CMS nucleus will exist in the user's virtual storage,
and the FREELOWE pointer (DMSFREE low-extended pointer) will be located at
the start of the CMS nucleus. This may prevent the user from acquiring a large
contiguous GETMAIN area. This requirement indicates that the CMS nucleus
should be generated at a higher virtual address, or that an alternate saved CMS system should be generated for such users. The default DMKSNT file supplied with
your system includes an entry for such a system (CMSL), and a load list
(CMSLOADL EXEC) is supplied with which you can generate a CMS nucleus at
storage location X'FOOOOO'.
I
The location of your saved CMS nucleus used by the majority of your users should
not be excessively high, since CP will construct a segment table that has entries for
all segments in the user's virtual machine, whether the segments exist or not. For
example, if a user has a 512K virtual machine size and IPLs a CMS system located
from X'190000' to X'200000', the user's segment table will have entries for all
segments from X'O' to X'200000'. These segment tables are built in real storage
by CPo An excessively high nucleus location will cause real storage to be wasted in
the construction of these segment tables. Therefore, you may wish to relocate the
CMS nucleus, based upon your requirements, to a higher or lower address than the
default. To do this, you should modify the load list for CMS, CMSLOAD EXEC,
and modify the SLC entry in the list that immediately precedes DMSALP, and the
entry preceding DMSOME to the address that you want for your CMS nucleus.
You should then create SLC files, which will be included in the CMS nucleus load
deck, to change the loader location counter when the nucleus is loaded via IPL
from your reader. These addresses should be chosen based upon your needs. For
more information abou~ relocating the CMS nucleus, see the VM / SP Installation
Guide.
For more information about saved systems, see "Chapter 9. Saved Systems and
Discontiguous Segments," and see the VM / SP System Programmer's Guide.
56
VM/SP Planning Guide and Reference
Chapter 5. Minidisks
External storage requirements of multiple virtual machines running at the same
time 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 or blocks (starting with 0,
1,2, and so on), and a VTOC (volume table of contents or disk label identifier).
Each minidisk is preallocated the number of contiguous full cylinders or blocks
specified in the VM/SP MDISK directory record. That space is considered to be a
complete virtual disk device.
Minidisks are controlled and managed by CP. If a system is to be run on both a
virtual and a real machine, minidisks for that system must start at real cylinder or
block zero. For a detailed list of minidisk restrictions, see "Appendix D. VM/SP
Restrictions. "
The remainder of this section describes minidisk:
•
•
•
•
•
Definition
Space allocation
Initialization
Alternate tracks/blocks
Labels
Defining Minidisks
Permanent minidisks are defined in the VM/SP directory entry for a virtual
machine. A minidisk defined in the directory via an MDISK statement is a permanent part of the virtual machine configuration. Data on the minidisk is available to
you whenever you are logged on.
If any virtual machine has a temporary requirement for direct access space it 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 stand-alone 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
toCP.
It is up to you to allocate minidisks on VM/SP disks in a manner that minimizes
arm contention and physical overlap. Information about minimizing arm contention is found in "Chapter 21. Preparing the CP System Control File
(DMKSYS). "
Note: The VM/SP directory function neither checks nor flags overlapped or duplicate minidisk extents. Nor does the function provide DASD space records for
unused or used space.
Figure 7 illustrates the use and definition of minidisks. The disk labeled OSDOS 1
contains several minidisks, some formatted to OS requirements and others to VSE
requirements. OSDOSI is a 2314 volume. The directory entry for userid ABC (an
OS user) describes virtual device 230 as a 50-cylinder area, and virtual device 231
Chapter 5. Minidisks
57
as a 20-cylinder area on real volume OSDOSI. The directory entry for userid XYZ
(a VSE user) describes virtual device 130 as a 50-cylinder disk area on a real volume OSDOSI.
Real
Cylinder
Number
000
050051
MFTSUB
060
061
t
SYSCATLG
202
etc.
052
VM/SP User Directory Entry for user ABC (An OS user)
512K
USER
ABC
123
ACCOUNT 985
CONSOLE 009 3215
MDISK
230 2314 000 050 OSDOS1W
MDISK
231
2314 100 020 050051 W
MDISK
232 2314 031 030 CPVOL 1 W
SPOOL
OOC 2540 READER A
000 2540 PUNCH A
SPOOL
SPOOL
OOE 1403 A
VM/SP User Directory for user XYZ (A VSE user)
USER XYZ PASSWORD
ACCOUNT NUMBER BIN14
CONSOLE 01F 3215
SPOOL
C
2540 READER
SPOOL
0
2540 PUNCH
SPOOL
E
1403
MDISK
130 2314 050 050 050051 W
MDISK
131
2314 001 020 CPVOL 1 W
Note: VM/SP 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 7. Use and Def"mition of Minidisks
Real volume CPVOLI also contains disk areas assigned to userid ABC (virtual
device address 232) and userid XYZ (virtual device address 131).
Note: On a 3330, 3340, 3350, 3375, or 3380, an OS/VS, or OS minidisk must
start at real cylinder 0 unless the VTOC is limited to one track. See the list of
restrictions in "Appendix D. VM/SP Restrictions" for more information and an
explanation of minidisk restrictions.
Minidisk Space Allocation
A minidisk always begins at virtual cylinder or block zero. For count-key data, it's
minimum size is one cylinder unless it is on a 2314 or 2319 disk and is formatted
by the Device Support Facility service program. In that case, the minimum number
58
VM/SP Planning Guide and Reference
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. For example, a virtual3340 minidisk must reside on a real 3340. An FB-512 minidisk can be any
number of blocks up to the maximum of the volume, in increments of one block.
A DASD volume containing multiple minidisks contains some tracks in which the
cylinder address in the count fields of records RO and R 1 do not agree with each
other. If an attempt is made to read this volume by IEHDASDR, you may get messages IEH8131 or IEH869I. To prevent this, initialize the disk with the FORMAT
function of IEHDASDR before using it. This function rewrites RO and Rl on each
track so that the count fields agree with each other.
VM/SP 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) I/O error to the virtual
machine.
Note: If the cylinder or block addresses in the MDISK statements overlap each
other, the integrity of data in the overlapped cylinders or blocks may be compromised with no error indicated.
os Minidisks
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 remaining disk space on the real disk
appears to OS to be permanently dedicated, and not assignable by OS space
accounting routines. The Device Support Facility service program should be used
to format minidisks for use by OS or VSE.
VSE Minidisks
VSE 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 the Device
Support Facility is always reserved for use as an alternate track cylinder.
Therefore, a VSE minidisk on a 2314 or 2319, must have at least 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, the Device Support Facility 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.
MSS Minidisks
When MSS minidisks are defined on MSS 3330V volumes, minidisks are virtual
3330-1 disks. The presence of MSS and 3330V system volumes is transparent to a
virtual machine accessing minidisks.
Chapter 5. Minidisks
59
Minidisk InitiaIization
Like real disks, minidisks must be formatted for use by the appropriate service program. A minidisk is initialized for use by running one of the following service programs in a virtual machine:
•
For CMS disks other than CMS/VSAM, the CMS FORMAT command formats the specified tracks into 512-byte, 800-byte, 1024-byte, 2048-byte, or
4096-byte blocks or physical records.
•
For CP disks, the stand-alone CP Format/Allocate program must be used to
format specified tracks into 4096-byte blocks.
•
For OS, VSE, and CMS/VSAM minidisks on count-key-data devices, the
Device Support Facility writes read-only track descriptor records for each
track, and sets 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). For count-key-data, any disk initialization program that supports the operating system's use of the DASD type may
be used if you are initializing full disks.
Minidisks defined in the VM/SP directory are initialized only once. Temporary
minidisks must be initialized each time they are used.
Alternate Tracks/Blocks
3330/3350 Disks
Alternate tracks assigned at the point of manufacture or by the Device Support
Facility in the field are automatically handled on the 3330 or 3350 by the control
unit. Minidisks on the 3330 Modell 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 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. When an alternate track is
required, it can be assigned by the Device Support Facility (stand-alone) 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 the Device Support Facility 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
two restrictions:
•
60
VM/SP Planning Guide and Reference
A minidisk should not be located where its track 0, cylinder 0 falls on a defective track because it will be impossible for the CP IPL command to function
for that minidisk.
•
Any operating system doing SIO to this disk must be capable of doing normal
alternate track error recovery.
Note: CMS qualifies here because it uses DIAGNOSE in place of SIO.
Error Recovery Support
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 switching to an alternate track. For CP I/O and for DIAGNOSE I/O issued from a virtual machine,
switching is fully automatic and the issuer of 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 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 VM/SP 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.
3340 Cylinder Assignments
On 3340-35 devices, the primary data area is cylinder 0-347. Cylinder 348 is
reserved for alternate tracks. On 3340-70 or 3344 devices, the primary data area is
cylinder 0-695. Cylinders 696-697 are reserved for alternate tracks.
Allocation Conversion
Previously, "alternate track" cylinders of 3340/3344 devices were often used as
primary data cylinders. 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 space allocation and minidisk
layouts on any 3340/3344 disk where "alternate track" cylinders had been used as
a primary data area.
System Residence Devices: If the system residence device contains "alternate track"
cylinders that have been used as the primary data area, 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. Following this revision, the specification of the
SYSRES, NAMESYS, and NAMENCP macros should be reviewed.
Minidisk Devices: If any minidisks on a 3340/3344 extend into the alternate track
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 next 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 track cylinders have
been used as a primary data area, make sure that you specify the cylinder range
exactly. For example, enter:
DUMP 0 TO 697
Chapter 5. Minidisks
61
rather than specifying ALL. This no longer dumps anything from the final cylinders except tracks that have been assigned as alternates. Then you can run the
Device Support Facility program to assign alternate tracks to the defective tracks so
that all cylinders become usable. Then 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 most current versions of the DDR, DIR, and FMT utilities should be used
with 3340/3344 devices after alternate tracks have been assigned.
Starter System Considerations: The starter system reserves 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
the Device Support Facility).
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. VSE, OS, and
CMS/VSAM minidisks, however, do recognize and support alternate tracks on
these types of DASD. The Device Support Facility 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 minidisk area becomes defective, you can:
•
Run the stand-alone 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/SP directory.
•
If the minidisk is used by either VSE, OS, or CMS/VSAM, reformat the minidisk (including the defective track) with the Device Support Facility program.
An alternate track is assigned at the end of the minidisk.
•
Set up the entire volume containing the defective track as an OS, VSE, or
CMS/VSAM volume. Format it with either the Device Support Facility or
IEHDASDR for OS or CMS/VSAM disks, or with the VSE Initialize Disk utility program (INTDK) for DOS disks. Alternate tracks are assigned in the
standard manner.
3375/3380 Disks
The control unit automatically handles defective tracks encountered on 3375/3380
DASD volumes. The control unit provides necessary hardware recovery for handling defective tracks. If a defective track is encountered, the hardware switches to
an alternate track. When the end of the alternate track is reached, the hardware
switches back to the first track following the defective track.
62
VM/SP Planning Guide and Reference
FB-512 Disks
Alternate blocks flagged at the point of manufacture are automatically handled on
the FB-512 devices. Alternate blocks are assigned in the field by using the Format
Defective Block procedure on the LOCATE CCW. The defective block number is
provided and the hardware assigns an alternate and sets up the appropriate
pointers.
Labels
All disks to be handled by CP (as a whole or as a combination of logical disks)
must have a label on real cylinder 0, track 0, record 3 for count-key-data devices or
on block 1 for FB-512 devices. This label identifies the physical volume to VM/SP
and must be in the form:
VOL1xxxxxx -orCMS=xxxxxx (for disks using an 800-byte format) -orCMS1=xxxxxx (for disks using a 512, 1K, 2K, or 4K format)
where xxxxxx is a 6-character volume label.
In addition, all virtual machine minidisks should have a label at virtual cylinder 0,
track 0, record 3 for count-key-data devices or on block 1 for FB-512 devices.
Labels created by the Device Support Facility, IEHDASDR, or INTDK are in the
form
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 or block O. CP recognizes the physical volume if the first minidisk has a valid label.
In Figure 7 on page 58, the volume indicated as OSDOS 1 has its real cylinder 0
allocated to a minidisk that is formatted for use by OS. The volume 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 or block 0 to a user as a data area, because if
that user has read/write access to the disk, the label can be destroyed.
Additionally, you must not assign user minidisks to begin on real cylinder or block
o 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, VSE, and CMS/VSAM minidisks write over and destroy
this necessary control information if the space is assigned to a user minidisk. This
causes CP system failures.
Chapter 5. Minidisks
63
Sharing Minidisks
A minidisk can be shared by multiple virtual machines. One virtual machine is designated as the owner of the minidisk (it has an MDISK control statement in its
VM/SP directory entry describing the minidisk). Other virtual machines can link
to the minidisk either by a LINK control statement in their own VM/SP directory
entry or by issuing a CP LINK command with the proper password during a terminal session.
For example, assume a virtual machine called USERA owns a minidisk at address
150. The VM/SP directory entry for USERA contains:
MDISK 150 3380 050 010 SYS003 W READPASS
USERA's virtual disk is on the volume labeled SYS003 and occupies real cylinders
050-059.
Any other virtual machine that issues the CP LINK command with the proper
password, or has the following LINK statement in its VM/SP directory entry, can
read the 150 minidisk belonging to USERA:
LINK USERA 150 cuu RR
Where 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/SP directory entry:
LINK USERA 150 151 RR
USERB can read data from USERA's 150 virtual disk whenever it issues a read for
data on its own 151 virtual disk.
You can link to any minidisk defined in the VM/SP directory if both of the following conditions are met:
1. The minidisk being linked to has a password specified in the MDISK directory
control statement corresponding to the type of link requested.
-AND2. The type of access requested (R, RR, W, etc.) is feasible at the time of the link.
Three primary types of sharing may exist for a minidisk and, correspondingly, three
passwords may be specified on the MDISK statement (read-only, write, and multiple).
Note: See the description of the CP LINK command in the VM / SP CP Command
Reference for General Users for more information about linking to minidisks.
64
VM/SP Planning Guide and Reference
Chapter 6. Planning for CMS VSAM and Access Method Services
eMS supports interactive program development for OS and VSE programs using
VSAM.
eMS supports VSAM macros for use in eMS programs. All of the VSE/VSAM
macros and their options and a subset of the OS/VSAM macros are supported by
eMS.
eMS also supports access method services to manipulate OS, VSE VSAM, and
SAM data sets, and VSAM for use with DOS/VS SORT/MERGE.
Under eMS, VSAM data sets can span up to 25 DASD volumes. eMS does not
support VSAM data set sharing. However, eMS does support 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.
VSAM data sets created in eMS are not in the eMS file format. Therefore, eMS
commands currently used to manipulate eMS files cannot be used for VSAM data
sets that are read or written in eMS.
Because VSAM data sets in eMS 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 running under eMS,
instead of with the eMS file system commands. Also, all VSAM minidisks and full
packs used in eMS must be initialized with the Device Support Facility or an
appropriate VSE 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.
Chapter 6. Planning for CMS VSAM and Access Method Servic~s
65
Hardware Devices Supported by VSE
CMS support of VSAM data sets is based on VSE/VSAM. With the exception of
the 3380, only disks supported by VSE/VSAM can be used for VSAM data sets in
CMS. These disks are:
•
IBM 2314 Direct Access Storage Facility
•
IBM 2319 Disk Storage
•
IBM 3310 Direct Access 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
•
IBM 3350 Direct Access Storage
•
IBM 3370 Direct Access Storage
•
IBM 3375 Direct Access Storage
•
IBM 3380 Direct Access Storage (OS VSAM enivornment of CMS only)
When the VM/SP processor is attached to an MSS, the CMS disk may be defined
as a 3330 Modell that is mapped by VM/SP to all or part of a 3330V volume.
CMS disk files used as input to or output from Access Method Services may reside
on any disk supported by CMS.
Data Set Compatibility Considerations
CMS can read and update VSAM data sets created under VSE/VSAM or OS/VS.
VSAM data sets with physical record sizes .5K, lK, 2K, or 4K created under CMS
can be read and updated by OS/VS VSAM. For complete information regarding
VSE/VSAM and OS/VS VSAM, consult the VSE/VSAM General Information
Manual.
If you perform allocation on a minidisk in CMS, you cannot use that minidisk in an
OS virtual machine in any manner that causes further allocation. VSE/VSAM
(and thus CMS) ignores the format-5, free space DSCB on VSAM disks when it
allocates extents. If allocation later occurs in an OS 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 data sets are
defined, and space is released whenever data spaces, catalogs, and data sets are
erased.
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.
66
VM/SP Planning Guide and Reference
1\
\ \
There is one exception to this restriction. If you have (1) OS PL/I programs that
have files declared as ENV(INDEXED) 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.
Planning Considerations for Installing VSAM Under CMS
CMS support of VSAM and Access Method Services is based on the VSE/VSAM
program product. You must order the supported level of the VSE/VSAM program
and use the VSAMGEN EXEC to install VSAM under CMS.
Support of VSAM under CMS also requires that the CMSDOS and CMSBAM discontiguous saved segments be generated. For complete information on the installation of VSAM under CMS, see the VM/SP Installation Guide.
Chapter 6. Planning for eMS VSAM and Access Method Services
67
68
VM/SP Planning Guide and Reference
Chapter 7. Planning for CMS/DOS
Those of you who use CMS/DOS must, in certain cases, have available a VSE
SYSRES. If you wish to use either the DOS/VS COBOL or PL/I compilers under
CMS/DOS you must first order and install a VSE system (most current level) and
install the compilers on this system.
If you plan to use CMS/DOS, you must also generate the CMSDOS and
CMSBAM discontiguous saved segments. These segments contain simulated VSE
services that are necessary for running VSAM and other VSE programs under
CMS. Running VSAM under CMS is dependent on the generation of CMSDOS
andCMSBAM.
For complete details on installing of the CMSDOS and CMSBAM discontiguous
saved segments, see the VM/ SP Installation Guide.
VSE System Generation Considerations
CMS/DOS support in CMS uses a real VSE system disk in read-only mode.
CMS/DOS provides the necessary interface, and then fetches VSE logical transients and system routines directly from the VSE system libraries. Also,
CMS/DOS fetches the DOS/VS COBOL and DOS PL/I compilers directly from
the VSE system or private core image libraries.
It is your responsibility to order the most current VSE system and then generate it.
Also, if you plan to use VSE compilers, you must order the DOS/VS COBOL and
DOS PL/I optimizing compilers and install them on this VSE system.
When you install the compilers on the VSE system, you must link-edit all the compiler relocatable modules using the linkage editor control statement:
ACTION REL
You can place link-edited phases in either the system or the private core image
library.
When you later invoke compilers from CMS/DOS, the library (system or private)
containing the compiler phases must be identified to CMS. You identify all system
libraries to CMS using the filemode letter that corresponds to that VSE system
disk. Do this by specifying the filemode letter 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 VSE 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 VSE, DOS/VS COBOL,
DOS/VS RPG II, or DOS PL/I. You should follow the normal update procedure
for applying IBM-distributed coding changes to them.
Chapter 7. Planning for CMS/DOS
69
When the VSE System Must Be Online
Much of what you do in the CMS/DOS environment requires that the VSE system
pack and/or the VSE private libraries be available to CMS/DOS. In general, you
need these VSE volumes whenever:
•
You use the DOS/VS COBOL or DOS PL/I compilers. These compilers are
run from the system or private core image libraries.
•
Your DOS/VS COBOL or DOS PL/I source programs contain COPY,
LIBRARY, %INCLUDE, or CBL statements. These statements copy code
from your system or private source library. This function requires that the
CMSBAM shared segment be generated and available to CMS/DOS.
•
You invoke one of the librarian programs: DSERV, RSERV, SSERV, PSERV,
or ESERV.
•
You link-edit VSE programs that use non-disk LIOCS modules. CMS/DOS
link-edits LIOCS routines with the VSE program from VSE system or private
relocatable libraries.
•
You run VSE programs that fetch phases directly from VSE system or private
core-image libraries.
A VSE system pack is usable when it is:
•
•
•
Defined for your virtual machine
Accessed
Specified, by mode letter, on the SET DOS ON command
A VSE private library is usable when it is:
•
•
•
Defined for your virtual machine
Accessed
Identified via ASSGN and DLBL commands
The VSE system pack and private libraries may reside on full packs or minidisks.
eMS/DOS Tape Handling
You can use the CMS tape label processing features described in the VM / SP CMS
User's Guide to process tapes defined with a DTFMT. The features described there
allow you to define input and output tapes that have standard or non-standard
labels or are non-labeled tapes. They also allow you to specify your own exits for
processing user standard or non-standard labels. Before CMS prepares your tape
files for processing, it returns control to the tape label processing routines.
The CMS LABELDEF command, which is described in the VM / SP CMS User's
Guide, is equivalent to the VSE TLB control statement for standard label tapes.
When a tape is defined as a work file, it is treated as non-labeled and any labels
encountered on the tape are written over.
Tape labels are not supported on tape files defined with DTFCP or DTFDI. Existing mM standard header labels are bypassed on such tapes when they are used for
input and any existing labels are written over when the tapes are used for output.
70
VM/SP Planning Guide and Reference
eMS/DOS DisktLabel Information Area
CMS/DOS does not support a disk label information area. If the real VSE system
pack used by CMS/DOS has a label information area, it is not used.
In CMS/DOS, ASSGN and DLBL commands provide functions similar to those
provided by the VSE ASSGN, DLBL, and EXTENT control statements. In VSE
those control statements are in effect only for one job. Thus, it is convenient to
place often used DLBL and EXTENT control statements on the label information
area.
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 ASSGN or DLBL command. Also, in CMS, you can
place all the commands you need to compile and run a program in an EXEC file
and invoke that EXEC file by its filename.
Chapter 7. Planning for CMS/DOS
71
72
VM/SP Planning Guide and Reference
Chapter 8. Planning for Virtual Machine Operating Systems (Other than CMS)
This section contains information about:
•
•
•
•
•
The VM/VS Handshaking Feature
Multiple Virtual Machines Using the Same Operating System
VM/SP Using Channel Switching
Alternate Path Support
Operating Systems Using Reserve/Release
The VM/VS Handshaking Feature
The VM/VS Handshaking feature is a communication path between VM/SP and
certain other system control programs (such as OS/VSl) that makes each system
control program aware of certain capabilities and requirements of the other. The
VM/VSHandshaking feature consists of:
•
•
•
Closing VM/SP spool files when the system control program's output writer
operation is complete
Providing an optional nonpaging mode for operating systems running under the
control of VM/SP
Providing miscellaneous aids for an operating system's virtual machine running
under the control of VM/SP
Since no paging is done by the operating system using VM/VS handshaking, ISAM
programs are treated by VM/SP as if they are being run from fixed storage
locations. Therefore, in order to run ISAM programs 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 issuing the CP CLOSE command when a task
or job has completed. Once these spool files are closed, they can be processed by
VM/SP without operator interruption.
Operating systems using VM/VS handshaking can run in nonpaging mode. Nonpaging mode exists when (1) the handshaking feature is active, and (2) the operating system's virtual storage size equals the virtual storage size of the VM/SP virtual
machine. When the guest operating system runs in nonpaging mode, fewer privileged instructions are executed and duplicate pagirig is eliminated. Such a virtual
machine may have a larger working set when it is in nonpaging mode rather than
when it is in paging mode.
Also, there are some other aids for guest systems using VM/VS handshaking while
running under the control of VM/SP. With the handshaking feature, the guest system avoids some of the instructions and procedures that would be inefficient under
VM/SP.
When the VM/VS Handshaking feature is active, the operation of a system control
program closely resembles the stand-alone operation because much repetition of
function between VM/SP and the operating system is eliminated.
Refer to VM / SP Operating Systems in a Virtual Machine for more details on handshaking.
Chapter 8. Planning for Virtual Machine Operating Systems (Other than CMS)
73
Multiple Virtual Machines Using the Same Operating System
In general, an operating system that 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 a negative effect) in a virtual machine.
For example, seek separation, which improves performance on the real machine, is
not needed in a virtual machine. CP itself issues a stand alone seek for all
count-key-data disk I/O.
Sharing the system residence volume makes it unnecessary to keep more than one
copy of the operating system online. The shared system residence volume should
be read-only so it can be shared among virtual machines. CMS discontiguous
saved segments can also be shared among all virtual machines since they are outside the virtual storage of each of the sharing virtual machines. CMS/DOS simulates VSE/ AF supervisor and input/output functions, thus allowing the running 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
VM/SP System Programmer's Guide for more details.
VM/SP Using Channel Switching
The two- or four-channel switch can be used in the following cases:
•
Two processors; one running VM/SP, the other running an operating system
that supports channel switching.
•
Two virtual machines running under VM/SP; each virtual machine operating
system must support the channel switch feature (CMS does not).
•
A single virtual machine running under VM/SP; the virtual machine operating
system must support the channel switch feature.
•
A processor running VM/SP and managing more than one path to devices
through VM/SP 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/SP and the other
could be running OS, as shown in Figure 8.
74
VM/SP Planning Guide and Reference
PROCt
os
290-297
390-397
2
Channel
Switch
PROC2
VM/SP
Figure 8. Channel Switching between Two Processors
VM/SP requires the following RDEVICE and RCTLUNIT macros to support this
configuration:
RDEVICE
RDEVICE
RCTLUNIT
RCTLUNIT
ADDRESS=(290,8) ,DEVTYPE=3330
ADDRESS=(390,8) ,DEVTYPE=3330
ADDRESS=290,CUTYPE=3830
ADDRESS=390,CUTYPE=3830
These macros make it possible for you to run VM/SP on PRGCl or PROC2. If
you are always going to run VM/SP on PROC2, you can eliminate one path (eliminate one set of RDEVICE and RCTLUNIT macros).
If any I/O devices controlled by VM/'SP for its own exclusive use are attached to a
control unit by 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 configuration above 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/SP. For example, one processor could be running
VM/SP with OS running in a VM/SP virtual machine as shown in Figure 9. In this
case, the virtual machine operating system supports channel switching.
Chapter 8. Planning for Virtual Machine Operating Systems (Other than CMS)
75
I
290-297
390-397
2Channel
Switch
PROC1
VM/SP
I I I I los
I
Figure 9. Channel Switching on One Processor
VM/SP requires the following RDEVICE and RCTLUNIT macros to support this
configuration:
RDEVICE
RDEVICE
RCTLUNIT
RCTLUNIT
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 devices associated with one path offline when
you load VM/SP. Otherwise, the following message is displayed:
DMKCPI954E DASD raddr VOLID volid NOT MOUNTED,
DUPLICATE OF DASD raddr
The 3880 Storage Control Unit contains two director modules. Each director
module acts as a control unit providing input/output operations to a string of
devices. Since each director module is separately addressable, one RCTLUNIT
macro statement is required for each module. The optional ALTCH operand of the
RCTLUNIT macro allows specification of up to three alternate channel interfaces
to a single director module. The two- or four-channel switch feature allows up to
four channels to have access to a director module. VM/SP supports a maximum of
four channel paths to a single director module.
DASD devices can be used by OS 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/SP directory. 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:
76
•
Generate the virtual machine operating system for the appropriate hardware
(in this case a 2816 Switching Unit on channels 5 and 6).
•
Generate CP as though 580 and 680 are different devices (with different control units and channels).
VM/SP Planning Guide and Reference
•
Issue the CP ATTACH command for both device addresses (580 and 680)
whenever the real device is to be attached to the virtual machine.
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 the virtual machine as dedicated devices (attached, or
defined with a DEDICATE statement in the VM/SP directory).
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
VM/SP. This support allows up to four channels on one control unit to be
attached to VM/SP and/or one device to be attached to two logical control units.
This provides the control program up to eight paths to one device when the maximum number of alternate channels and alternate control units are specified. When
an I/O request is received for a device, VM/SP 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 started 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 more than one
busy / scheduled path. 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
random choice of queuing based on number of IOBLOKs already queued, primary path, last busy scheduled path encountered, etc.
2. No user is affected more than any other user.
3. The first in, first out (FIFO) principle is abided by.
The goal of alternate path support is to define alternate paths to a device on the
VM/SP processor. The virtual operating system does not define alternate paths.
Instead, VM/SP defines alternate paths to the device with RCTLUNIT and
RDEVICE macros. VM/SP then performs the alternate path I/O scheduling. If
you wanted VM/SP, rather than the virtual operating system, to perform alternate
path I/O scheduling, the following RDEVICE and RCTLUNIT macros would be
required:
RDEVICE ADDRESS=(290,8) ,DEVTYPE=2314
RCTLUNIT ADDRESS=290,CUTYPE=IFA,ALTCH=(3)
RCHANNEL ADDRESS=3
RCHANNEL ADDRESS=2
Chapter 8. Planning for Virtual Machine Operating Systems (Other than CMS)
77
To specify an alternate control unit on the RDEVICE macro, code:
RDEVICE ADDRESS=cUu,DEVTYPE=nnnn,MODEL=n,ALTCU=cuu
Example:
RDEVICE ADDRESS=(340,32),DEVTYPE=3330,MODEL=1,ALTCU=250
RCTLUNIT ADDRESS=340,CUTYPE=3830,FEATURE=32-DEVICE
RCTLUNIT ADDRESS=250,CUTYPE=3830,FEATURE=32-DEVICE
RCU340
RCU348
~>O<
r-->
RCU350
RCU358
~>O<
RDV340-34F
'---
RCU250
RCU258
RCU260
RCU268
>0
r--
RDV350-35F
RCU340 RDEVCUA
RCU340 RDEVCUA
RCU250 RDEVCUB
RDEVCUB RCU250
FtgUre 10. Real I/O Control Block Structure for Alternate Control Unit Specification
Figure 10 shows how the real 110 control block structure is coded and logically
appears when an alternate control unit is specified.
78
VM/SP Planning Guide and Reference
To specify alternate channel addresses on the RCTLUNIT macro, code:
RCTLUNIT ADDRESS=cuu,CUTYPE=nnnn,FEATURE=xxx-DEVICE,
ALTCH=(1,2,4)
Example:
RCTLUNIT
RCHANNEL
RCHANNEL
RCHANNEL
RCHANNEL
RCHAHI
~>o
>
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
RCHAN2
~O
>
RCHAH3
~·O
RCHAH4
>0
,.---
RCU350
RCU358
RCU340
RCU348
RCHAN3
RCUCHA
RCHAH3
RCHANI
RCUCHB
RCHAHI
----- RCHAN2
RCUCHC
RCHAH2
RCHAN4
RCUCHD
RCHAH4
Figure 11. Real I/O Control Block Structure for Alternate Channel Specification
Figure 11 shows how the real 110 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 in
line with the CP block structure.
Restrictions
The following restrictions apply directly to Alternate Path processing:
•
VM/SP does not support alternate paths for devices that issue attention interrupts to cause 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.
•
Only one alternate channel can be specified for MP systems.
Chapter 8. Planning for Virtual Machine Operating Systems (Other than CMS)
79
Channel-Set Switching Facility
The channel-set switching facility is available on the 3033 attached processor and
multiprocessor systems and the 3081 processor complex. This feature permits a set
of channels to be switched from one processor to another in a multiprocessor or
attached processor system. A channel-set. is the collection of channels that are
switched as a group. On a 3033 attached processor system, all online channels
make up the channel-set.
VM/SP, when generated for AP operation, uses the channel-set switching facility.
The switching operation 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 and 3081 attached processor systems, 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 OFFLINE PROCESSOR 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, the automatic
processor recovery routine determines if channel-set switching capability exists. If
there is no channel-set switching capability in the system, CP enters the wait state
with a code of X'OOOI'. If the error is TOO clock damage or a malfunction alert on
the main (I/O) processor and the processor is in problem state, the failing processor is taken offline provided the attached processor is equipped with the channel-set
switching facility. The channel-set switching facility is used to disconnect the
channel-set from the failing processor and to reconnect the channel-set to the
attached processor. Processing continues on the attached processor in uniprocessor
mode issuing:
DMKCPU6231 } { DMKMCT623I
80
VM/SP Planning Guide and Reference
CHANNEL-SET CONNECTED TO PROCESSOR nn
Monitoring and Service Support Facility
The 3081 Processor Complex uses the 3082 Processor Controller, a service
processor that handles central communications for the processor complex. The
processor controller performs the following functions automatically:
•
Validates storage during system initialization
•
Configures channel groups
•
Detects and corrects recoverable channel errors
•
Monitors power and coolant levels
The monitoring and service support facility (MSSF) is a hardware component of
the processor controller. MSSF provides I/O configuration and storage information for the 3081 processor complex. Virtual machine operating systems that are
able to communicate with the MSSF can use the MSSF command word SCPINFO
to obtain information about the processor's configuration and storage allocation.
If an MVS virtual machine operating in V = V mode issues the MSSF command
word SCPINFO, VM/SP simulates the MSSF response by returning preformatted
data to the virtual machine. If the MVS virtual machine operating in V =R mode
issues the MSSF command word SCPINFO, VM/SP returns the unaltered information to the virtual machine.
MSSF also processes VARY PROCESSOR commands. When you issue the CP
command VARY PROC ONLINE or VARY PROC OFFLINE VPHY on a 3081
processor, VM/SP generates an MSSFCALL instruction to the MSSF. MSSF then
brings the processor online or takes the processor offline. When the request finishes, MSSF returns a completion status code.
VM/SP uses the MSSFCALL diagnose instruction and MSSF command words to
communicate with the MSSF. The MSSFCALL diagnose (function code X'80')
command words and completion status codes are described in the VM / SP System
Programmer's Guide. The VM/SP System Logic and Problem Determination Guide
Vol.} - CP describes the response codes that VM/SP simulates for a V = V virtual
machine.
MSSF does not require system generation macro definitions; however, you must
define your real I/O configuration to the processor controller using the
Input/Output Configuration Program. General information about the
Input/Output Configuration Program follows.
Chapter 8. Planning for Virtual Machine Operating Systems (Other than CMS)
81
Input/ Output Configuration Program
The processor controller contains the I/O configuration definition for the 3081
processor complex. You supply this information to the controller by running the
Input/ Output Configuration Program.
The Input/Output Configuration Program (IOCP) processes 10CP macro definitions that contain I/O configuration information for the 3081 Processor
Complex. Using 10CP macro definitions, 10CP records the information in an
input/ output configuration data set. The input/output configuration data set
(IOCDS), which is stored in the processor controller, supplies the information that
defines the I/O configuration for the processor complex. The 10CDS contains
information that describes:
Channel paths to the processor
•
Control units assigned to the channel paths
•
I/O devices assigned to the control units
Note: The device addresses (channel, control unit and device) you define in
IOCDS should match the addresses you define in the real I/O configuration file
(DMKRIO).
There are three versions of 10CP:
Stand-Alone Version Input/Output Configuration Program
VM/SP Input/Output Configuration Program
MVS/SP Input/Output Configuration Program
You should run the appropriate version of 10CP as determined by the following
descriptions.
Stand-Alone Version Input/Output Configuration Program
If you are installing a 3081 processor for the first time, it may be necessary to run
the stand-alone version IOCP. The stand-alone version of IOCP defines your initial I/O configuration to the processor complex. Using the 3081 service support
console or the system console, you can run the stand-alone version of 10CP to:
•
Read the input/output data set (IOCDS) from the processor controller
•
Display, add, alter, and remove I/O configuration data from the 10CDS
•
Obtain I/O configuration reports
•
Write a new or updated 10CDS
The stand-alone version 10CP is shipped with the 3081 processor. For your convenience, a starter input/output configuration data set (IOCDS) is also shipped in
level 0 of the processor controller. You should examine the starter IOCDS to
determine whether a sufficient configuration of I/O devices, control units, and
82
VM/SP Planning Guide and Reference
channels are defined and whether they match your system configuration. A listing
of the starter IOCnS appears in the OS/VS2 MVS, VM/SP and Stand-Alone Versions Input/Output Configuration Program User's Guide and Reference.
If there are sufficient entries in the starter IOCnS for you to generate VM/SP, it is
not necessary to run the stand-alone version IOCP. Simply power-on reset the
processor controller and generate your VM/SP system. The processor controller
uses the starter IOCnS defined in the level 0 IOCnS of the processor controller.
After VM/SP is generated, and CMS is operating, use the VM/SP Input/Output
Configuration Program to fully define your configuration to the processor controller.
If the starter IOCnS does not meet your needs, run the stand-alone version of
IOCP.
VM/SP Input/Output Configuration Program
VM/SP IOCP runs under the VM/System Product version of CMS. Using the
CMS command IOCP with the necessary options, you can generate new I/O configuration data or obtain I/O configuration reports. If you have an operating
VM/SP system (that is, you have defined a sufficient configuration to the processor controller in order to generate VM/SP) you can use the IOCP command to
define your entire system configuration.
.
The IOCP command writes the new input/output configuration source file to the
level 1 IOCnS in the processor controller. To test the new IOCnS:
1. Shutdown the VM/SP system
2. Power-on reset the processor controller using the level 1 IOCnS
3.
Start VM/SP
MVS/SP Input/Output Configuration Program
The MVS version of IOCP runs as a job under control of the OS/VS2 MVS system
control program with the OS/VS2 MVS/System Product. You use JCL statements
to run IOCP. By coding options on the PARM= parameter of the EXEC statement, you can generate a new input/output configuration data set (IOCnS) or
produce I/O configuration reports from the IOenS in storage.
You can run the MVS version of IOCP in a virtual machine operating under
VM/SP; however, you cannot run IOCP in an MVS virtual machine if your system
is operating in single processor mode.
References
For more information about IOCP source file and matching real I/O configuration
file, refer to "Chapter 19. Preparing the Real I/O Configuration File (nMKRIO)."
For details concerning IOCP macro definitions, the CMS IOCP command, and the
starter IOCnS, refer to the OS /VS2 MVS, VM/ SP and Stand-Alone Versions
Input/Output Configuration Program User's Guide and Reference.
Chapter 8. Planning for Virtual Machine Operating Systems (Other than CMS)
83
J
Missing Interruption Handler
Hardware errors, timing conditions, or software errors may prevent I/O interruptions from being passed to the control program. The missing interruption handler monitors system activity to detect ,interruptions not occurring within specified
time intervals. In order for CP to monitor I/O, module DMKDID must be present
in the system. If MIH is set on and a missing interrupt is detected, CP attempts to
correct the condition. CP sends an informational message to the operator and
writes a record of the missing interruptions to the system error recording area
regardless of whether the action is successful or not.
The default for the Missing Interrupt Handler is that MIH is set off; the interrupt is
detected and a message is written to the operator, but no corrective action is taken.
MIH can be turned on by a directory option or by issuing the SET command.
Interruption timing varies among devices. Certain devices are more critical than
others. In order to allow you greater flexibility for monitoring I/O activity, CP
allows you to specify a different time interval for each class of device. The time
interval is set using the IBM-supplied defaults (provided in file DMKSYS) or as
determined by you. You may change the default intervals by coding the SYSMIH
macro statement and reassembling DMKSYS.
The SET MITIME command changes the time intervals specified in DMKSYS.
Time intervals used in the SET MITIME command remain in effect until you issue
another SET MITIME command, or until you reload the system. A description of
the SET MITIME command is in the VM/SP Operator's Guide. See "Chapter 21.
Preparing the CP System Control File (DMKSYS)" for a description of the
SYSMIH macro statement.
You can use the missing interrupt handler with all I/O devices supported by CP,
except terminal devices (CLASTERM), System Network Architecture devices,
pass-thtough virtual machine (logical) devices, and special devices (CLASSPEC).
The missing interruption handler supports Mass Storage System devices generated
with a 3851 Mass Storage Controller (CLASSPE TYP3851) and 3330V DASD
(CLASDASD FEATURE=VIRTUAL or FEATURE=SYSVIRT).
Operating Systems Using Resene/Release
Shared DASD describes the capability of accessing direct access devices from two
or more systems. The systems can be in virtual machines on the same or different
real processors. Device access by the sharing systems is sequential.
Sharing of DASD volumes can occur when:
•
A two- or four-channel switch attaches a device's control unit to two or four
channels.
String switching is used and the control units to which they are switched are on
channels of two different systems.
With Shared DASD, an I/O operation may be started to a shared device from any
of the systems able to access the device using the switch. Each sharing system
waits 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 neutral, any other system, or the same
one, may select the shared device and have the switch set to its interface.
84
\
VM/SP Planning Guide and Reference
4
'
It is important to note that none of the sharing systems is aware of what the other
is doing with data on the shared devices. Data integrity is the responsibility of the
using program. For this reason, a program may issue the RESERVE hardware
command to retain exclusive use of a shared device while a critical update to data is
being performed. Device RELEASE is issued to end exclusive reservation. If a
shared device has been reserved for exclusive use, the system channel through
which RESERVE was issued will lock out any other channel, on the same or different system, from accessing the device.
There are several reasons why you would elect to share devices between systems:
•
Scheduling of jobs is simplified, and operator action is reduced. 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.
•
Updating of data is lessened. One update to a shared data set is needed,
instead of the many updates required if each of several systems had its own
copy of the data set.
•
Backup and switchover in the event of hardware failure is eased in a
multi-system environment if the needed data is available to surviving systems
without moving it.
•
Direct access storage space may be saved because only one copy of the data is
required instead of many copies.
Two assembler language macros, RESERVE and DEQ, are available for reserving
and releasing of a device. Data integrity of shared devices can be maintained by
application program use of the RESERVE macro, or by operating system components that 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, eMS does not support these macros in OS simulation or CMS/DOS simulation packages. The SHAREOPTIONS operand 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. Use of shared DASD
by virtual machines should be limited to guest operating systems that will maintain
the integrity of shared data, such as catalogs, VTOCS, program libraries, etc..
These guest operating systems should also support the use of the RESERVE and
DEQ macros used by application programs running under these systems. The only
other option is the use of hardware reserve or release CCWs by an application program running under CMS. In this case, the application program issues hardware
reserve and release CCWs in a SIO or DIAGNOSE operation to the shared device.
VM/SP reserve/release support can be addressed in two forms:
•
•
Shared DASD
Virtual Reserve/Release
Shared DASD refers to the use of reserve/release CCW strings by virtual machine
or processor operating systems to preserve data integrity. Data integrity 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.
Chapter 8. Planning for Virtual Machine Operating Systems (Other than CMS)
85
Virtual reserve/release is software simulation of reserve/release CCWs for minidisks. Virtual devices associated with a minidisk all map to the same real channel
interface to the device; hardware protection is lost, and a software locking structure
is required to maintain data integrity during reserve/release sequences.
CP and CMS do not issue reserve CCWs. The use of reserve/release is the
responsibility of the virtual machine operating system. The VM/SP initialization
routine issues a release CCW to tape and DASD volumes to determine if the twoor four-channel switch feature is installed.
SharedDASD
Operating systems that support shared DASD use reserve/release CCWs to preserve data integrity in the following cases:
•
Two virtual machines running under VM/SP 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/SP control program CCW
translation routine and are executed by the hardware to preserve data integrity.
In this case 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.
•
A virtual machine runs under VM/SP 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/SP, in which case the virtual machine operating system
uses reserve/release CCWs to maintain data integrity. Or it can be a
non-VM/SP operating system with reserve/release capability.
To support this environment, the device should be dedicated to the VM/SP virtual machine by means of the ATTACH command or DEDICATE control
statement in the VM/SP directory.
In the above shared DASD environments, the use of reserve/release by virtual
machine operating systems and VM/SP alternate path support are mutually
exclusive. CP changes a reserve CCW to a sense CCW when an alternate path
is defined for the device. The protection offered by hardware reserve is lost.
A single path should be defined in VM/SP for devices that will be dedicated to
virtual machines, and then shared between other virtual machines or
processors.
The device can be defiJ1ed as a minidisk, on the VM/SP 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/SP system I/O requests to the same device.
The performance of virtual machine operating systems may be degraded when
sharing DASD. If not running single processor mode, I/O requests may be
queued and the virtual machine left in I/O wait when a device is being used by
86
VM/SP Planning Guide and Reference
another virtual machine or system. (A virtual machine is not left in I/O wait if
a "SIO FAST" has been issued.) If in single processor mode, a device busy is
reflected to the V=R guest when a device is in use and a device-end interrupt
is reflected when an interruption occurs. Depending on conflict for the device,
the V =R guest may get multiple device busy and device ends before the device
is available to it.
Note: Defining a DASD as a minidisk gives many users the capability of linking to the volume. However, extended 10WAITS can occur when another
processor has already issued a reserve to the pack because the busy condition
will not be reflected to the guest operating system. The other possibility is for
the disk to be attached or dedicated. This allows only one path to the device
for each guest operating system, but the busy condition will be reflected to the
guest operating system and prevent long lOWAITS.
Virtual Reserve/Release
Reserve/release software simulation in VM/SP provides reserve/release protection
at the minidisk level, including full volume minidisks. Virtual reserve/release is
intended for use by virtual machines that support shared DASD (not CMS) running
on the VM/SP processor. Virtual reserve/release simulation is requested by
appending a character "V" to the mode operand on the MDISK directory statement. All future 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/SP control program then examines virtual machine channel
programs and manages reserve/release CCWs presented by sharing virtual
machines. CP simulates 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 "device end" interrupt is
reflected to all virtual machine 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
reissued.
VM/SP Control Program Handling of a Reserve CCW
VM/SP reserve/release support and VM/SP alternate path support are mutually
exclusive. The VM/SP CCW translation routine changes a reserve CCW to a
sense CCW when alternate paths have been defined to the device from the VM/SP
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/SP
processor, VM/SP still changes a reserve CCW to a sense CCW when alternate
paths are defined to the real device. However, since hardware reserve/release is
simulated when virtual reserve/release is being used, data integrity is preserved
when alternate paths are defined. Figure 12 on page 88 below identifies those
cases when CP changes a reserve CCW to a sense CCW.
Chapter 8. Planning for Virtual Machine Operating Systems (Other than eMS)
87
Type
of
Device
CCW Comnd
Reserve/Release Virtual Reserve
Executes in the Release Requested sent by
VM/SP to
(V Added to
Hardware (2-4
Device
Note
Channel Switch) Mode in MDISK)
Alternate
Path
Support
Dedicated Hot defined
DASD or
Tape
Defined
Minidisk
Hot applicable
Hot applicable
Reserve
1
Hot applicable
Hot applicable
Sense
2
Hot defined
Yes
No
Reserve
1
Not defined
Yes
Yes
Reserve
1
Hot defined
Ho
No
Reserve
3
Not defined
No
YES
Sense
4
Not applicable
Sense
5
Defined
lNormal Operation.
Not applicable
The command is passed unchanged to the hardware.
ZWhen the VM/SP system has been generated with alternate path support
for those devices, it prevents the devices from being reserved.
This
action causes VM/SP to avoid a possible channel lockout.
VM/SP
does not return any indication that the device was not reserved to
the operating system issuing the CCW command.
3Without the two-channel switch special feature, VM/SP sends the
reserve/release CCW command unchanged to the hardware.
However, the
hardware rejects the command and does not reserve the device.
4Before sending the command to the hardware, VM/SP 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/SP system from accessing the mini disk. 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/SP processor.
This path allows VM/SP
virtual reserve/release processing to send a SENSE CCW to the device,
although the reserve CCW command is 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), VM/SP changes reserve/release CCW
commands to SENSE CCW commands to prevent a possible channel lockout.
Figure t 2. Summary of VM/SP Reserve/Release Support
Restrictions: Device Sharing Between Real Processors
•
When a device is shared between processors and at least one of the processors
is running VM/SP, the shared volume cannot contain more than one minidisk.
The single minidisk may include the entire volume or a small portion of the
volume. The remainder of the volume must not be referenced by CP for use as
paging, spooling, etc., or by any virtual machine.
Note: This restriction only pertains when using real reserve/release in addition
to virtual reserve/release. Assume that two virtual machines are using separate
minidisks on the same real volume and that both minidisks are defined for virtual reserve/release:
88
VM/SP Planning Guide and Reference
1. Virtual machine A issues a reserve to minidisk A, resulting in a RESERVE
CCW to the real volume.
2. Virtual machine B issues a release to minidisk B, resulting in a RELEASE
CCW to the real volume.
3. Another real machine can now write to that volume, including the minidisk
A area.
•
Devices shared between processors must not be generated in DMKRIO as having alternate paths. If there is more than one path from the VM/ SP processor
to the shared devices, as well as a path from the same devices to another
processor, the paths from the VM/SP processor cannot be generated in
DMKRIO as alternate paths via the ALTCH or ALTCU macro operands. This
means that the definition of alternate paths in DMKRIO and the use of real
reserve/release are mutually exclusive.
Restrictiom: DeviCt!/Minidisk Sharing on a Single Processor
•
If more than one 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 data integrity. In this
case, integrity is preserved by the hardware, not by the software
reserve/release support. Again, the definition of alternate paths in DMKRIO
and the use of real reserve/release are mutually exclusive.
•
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 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 is still changed to a sense CCW, but data
integrity is preserved by the virtual reserve/release code.
Chapter 8. Planning for Virtual Machine Operating Systems (Other than CMS)
89
Logical Device Support Facility
The Logical Device Support Facility allows an application running in a virtual
machine to communicate with CP as if it were a real terminal supported by CP. An
example of such an application is the VM/Pass-Through Facility. The application
manages data flow to and from CP. This function is implemented through the creation of logical devices by the facility in the host system.
The Logical Device Support Facility is made up of two data transfer subfunctions,
three control subfunctions, a special external interrupt code (X'2402') to
asynchronously alert a virtual machine of pending logical device status, and an
external control word for passing control information with the external interrupt.
The facility is invoked by issuing the DIAGNOSE (7C) instruction. Operands on
the DIAGNOSE instruction are used to specify:
•
The register containing the logical device identification (Rx)
•
The register identifying the subfunction to be performed (Ry)
•
The DIAGNOSE function code (7C)
The data buffer address and the data buffer length are in registers Rx and Rx + 1
respectively when DIAGNOSE (7C) is issued for an ACCEPT or PRESENT function.
I
The user virtual machine is signaled asynchronously by CP via the external interrupt code X'2402'. When the virtual machine receives the external interrupt, a full
word of data is stored at location 128 (decimal) in virtual storage. This data gives
the reason for the interrupt and the associated logical device address. Control register 0, mask bit 22, must be on to receive this external interrupt.
Subfunctions that may be requested via DIAGNOSE (7C) are summarized in
Figure 13. More complete descriptions of these subfunctions are in the VM / SP
System Programmer's Guide.
Subfunction
Description
INITIATE
Initiate CP /host application communications.
ACCEPT
Transfer data written to logical device from virtual
machine storage.
PRESENT
Transfer data from virtual machine to CP as input
from logical device.
TERMINATE
Drop a specific logical device.
TERMINATE ALL
Drop all logical devices created for this virtual
machine.
Figure 13. Logical Device Support Facility Subfunctions
90
VM/SP Planning Guide and Reference
Logical device support is not designed to simulate all aspects of real device support.
Some instances are:
•
Logical device support always passes channel end and device end to the virtual
machine together.
•
The PCI bit in the CCW is not handled by logical device support.
•
Ending status on 110 only is passed back to the virtual machine (not initial).
Programming for Logical Device Support Facility is contained primarily in the
pageable CP modules, DMKHPS and DMKHPT. If an application program does
not call the Logical Device Support Facility, then modules DMKHPS and
DMKHPT need not be assembled.
Inter-User Communication Vehicle
lUCY provides a communication capability between virtual machines. The facility
also supports communication within the same virtual machine and between a virtual
machine and CP.
lUCY communication takes place between two communicators. Every communication has a source communicator and a target communicator. A communication
occurs over a predefined linkage called a path. Messages are created, transmitted
over the path, and then eliminated by lUCY. lUCY functions include the following:
•
Communication paths and messages are begun by either CP or a virtual
machine.
A communicator can selectively start and stop communication paths.
•
Two communicators can establish more than one communication path between
them.
•
More than one message can be transmitted in either direction at the same time
using the same path.
•
All lUCY functions are privileged.
•
All lUCY functions are invoked with the lUCY macro.
•
Directory authorizations allow you to control the establishment of lUCY communication paths between virtual machines and CP system services.
For a detailed description of lUCY functions and the lUCY macro instruction,
refer to the VMI SP System Programmer's Guide.
The lUCY directory control statement defines authorizations for establishment of
lUCY communication paths. The MAXCONN keyword of the OPTION directory
control statement defines the maximum number of lUCY connections allowed for a
virtual machine. For more information, see the "Directory Program" in
Chapter 18.
Chapter 8. Planning for Virtual Machine Operating Systems (Other than CMS)
91
Although IUCV is similar to the Virtual Machine Communication Facility, IUCV
does not replace VMCF. Both IUCVand VMCF are available and can be used.
IUCV should be considered for new applications requiring inter-user communication. IUCV is used for communication between SNA CCS and VCNA.
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/SP system. The VMCF external interrupt masking is controlled by
PSW bit 7 and CRO bit 31. It is to your 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.
Messages 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 storage sizes of
the respective virtual machines.
Use of real storage is small. Only one real storage page need be locked during data
transfer. A special interrupt is used to notify one virtual machine of a waiting
transfer of data. This interrupt is also used to synchronize sending and receiving of
data.
Under the Special Message Facility, CP acts as a virtual machine in behalf of a virtual machine that issues SMSG. The receiving virtual machine, properly programmed to accept and process special messages, authorizes itself to CPo Data
(message) transfer is from CP, via the message and VMCF modules.
92VM/SP Planning Guide and Reference
Chapter 9. Saved Systems and Discontiguous Segments
Saved systems are described in detail in the VM/SP System Programmer's Guide.
If you plan to save core-image copies of virtual machine operating systems you
should do the following when you generate VM/SP:
•
Create an entry in the system name table for each system you wish to save.
•
Reserve space on a CP-owned volume for each system you wish to save.
You create entries in the system name table by coding NAMESYS and NAMENCP
macros and assembling the system name table (DMKSNT) file during system generation. You allocate DASD space as permanent (PERM) by running the
Format/ Allocate program. This program is run during system generation, but it is
a stand-alone program that can be run at any time. 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
VM/SP, you must code appropriate NAMESYS or NAMENCP macros, reassemble the system name table file (DMKSNT), 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 file (DMKSYS), and reload
the CP nucleus. Use the GENERATE EXEC procedure to reassemble DMKSNT
and/ or DMKSYS and to reload the CP nucleus. GENERATE is described in the
VM / SP Installation GUide.
VM/SP supports discontiguous saved segments and provides shared segment protection.
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 (AP) or multiprocessor mode (MP), all protected
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 AP or MP mode.
The SHRTABLE SHRPAGE pointer points to the page and swap tables for the
main (IPL) processor. The page and swap tables for the attached (non-IPL)
processor will be at a fixed offset from the page and swap tables for the IPL
processor. DMKCFG initializes both sets of page and swap tables. At first, the
swap tables for the IPL processor and non-IPL processor will point at the DASD
locations specified in DMKSNT. However, as 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 VM / SP System Programmer's Guide for a
description of shared segments.
Chapter 9. Saved Systems and Discontiguous Segments
93
Segments to be saved in this manner must be loaded at an address within your virtual machine and then saved. To do this in CMS (following CMS 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.
•
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.
The segment following your CMS nucleus cannot be used for a shared segment.
This segment contains vital free storage pointers that would be overlaid with the
text decks for the segment as a shared segment. An alternate CMS nucleus can be
built at a different storage location, and this CMS nucleus can be used during the
creation and saving of the shared segment that follows your normal CMS nucleus.
CMS has EXEC procedures to help you place portions of CMS in discontiguous
saved segments:
•
DOSGEN, which loads and sayes CMS/DOS support
•
SAMGEN, which loads and saves CMSBAM support
•
VSAMGEN, which loads and saves CMS/VSAM and Access Method Services
support (CMSAMS)
See the VM / SP Installation Guide for descriptions of how these EXEC procedures
are used.
CP checks to see if 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 unavailable and the virtual machine's execution is stopped by placing it into console function mode.
94
VM/SP' Planning Guide and Reference
Saved systems must be named and may be shared. Discontiguous saved segment
support is similar to saved system support. Therefore, you should understand saved
systems before you read this section. See the VM / SP System Programmer's 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 nonshared mode for testing
and debugging.
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 dis contiguous 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 running in the virtual=real area. An
example of discontiguous saved segments are the segments of CMS that support
VSE program development and testing under CMS. These segments are reentrant
and are named CMSDOS and CMSBAM. The starter system includes EXEC procedures (DOSGEN and SAMGEN), which help you load and save these segments.
CMS contains all the necessary linkage to load the CMSDOS and CMSBAM segments when they are needed.
The main advantage of placing the CMS support for VSE in discontiguous saved
segments is that it uses less real storage. Not all CMS users need the VSE 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 placing the VSE support in discontiguous saved segments (called CMSDOS and CMSBAM), less real nonpageable storage is used.
Your segment table has entries for theCMSDOS and CMSBAM segments (and all
segments up to it) only when these segments are attached to your virtual machine.
Chapter 9. Saved Systems and Discontiguous Segments
95
To use discontiguous saved segments you must:
•
Allocate permanent space on a CP-owned volume to contain the saved segment.
•
Assign a name to the segment and specify where it is to be stored on disk. To
do this, define an entry in the syst~m name table (DMKSNT) with the
NAMESYS macro. See "Coding the NAMESYS Macro" in Chapter 20, for
the suggested layout of DMKSNT.
•
Load and save the segment, using the appropriate EXEC procedure
(DOSGEN, SAMGEN, or VSAMGEN).
•
Be sure that the proper linkage for attaching and detaching discontiguous saved
segments is in the operating system that needs the segment. eMS contains the
linkage necessary to attach and detach the discontiguous saved segments it
supports.
You can load and save a discontiguolls saved segment any time after system generation.
96
VM/SP Planning Guide and Reference
Chapter 10. Performance Guidelines
The performance characteristics of an operating system when it is run in a virtual
machine are difficult to predict. This unpredictability is a result of:
•
The processor model.
•
The system type (uniprocessor, attached processor, or multiprocessor).
•
The total number of virtual machines running.
•
The type of work being done by each virtual machine.
•
The speed, capacity, and nuniber of the paging devices.
•
The use of fixed-head cylinders for preferred paging.
•
The amount of real storage available.
•
The degree of channel and control unit contention, as well as arm contention,
affecting the paging device.
•
The type and number of VM/SP performance options in use by one or more
virtual machines.
•
The existence of hardware assist.
•
The favored priority and V =R options in effect.
Also, the virtual machine's channel mode, block multiplexer or selector, has an
effect on the virtual machine's performance.
Note: The performance of an MSS being used by the operating system and shared
with other systems depends on the total MSS usage and contention.
Chapter 10. Performance Guidelines
97
Performance Measurement and Analysis
The VM/SP control program has two commands that measure system performance
to help you identify problem areas.
The MONITOR command controls the collection of performance data and the writing of it to system spool files or tapes. Both summary and trace data can be collected. You may specify classes of data to be collected using either the operands of
the MONITOR command or the SYSMON macro instruction. Classes selected
depend on the nature of the analysis to be performed. mM Field Developed Program (FDP) VM/370: Performance/Monitor Analysis Program can be used to
reduce the data collected. Guidelines for using this program provide you with
information that will aid in determining the overall load and performance profile of
your system. The VM/370 Performance/Monitor Analysis Program should enable
you to analyze usage of and contention for major system resources such as the
processor, storage, and I/O paging subsystems.
The INDICATE command displays, at a terminal, key information about the system, showing current performance indicators. Entering INDICATE displays system conditions existing at the time the command is issued. This includes attached
processor (AP) and multiprocessor (MP) usage measurement when operating an
AP or MP system. If, after using the INDICATE command, you want more extensive data collection and reduction, use the MONITOR command.
Specify automatic data collection with the SYSMON macro in DMKSYS. Coding
considerations are in "Chapter 21. Preparing the CP System Control File
(DMKSYS)." See the VM/SP System Programmer's Guide for:
•
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.
•
Details of the INDICATE command options.
Note: The VM Real Time Monitor (SMART), listed in Appendix A, is another
program designed specifically to help you monitor and tune your system.
I
Using Performance Options
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
virtual = real
queue drop elimination
Performance of a VM/SP 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 and MVS/System Extensions Support are supported by
various VM/SP processors is detailed on the following page.
98
VM/SP Planning Guide and Reference
Virtual Machine Assist
Standard
RPQ
135
135-3
138
145
145-3
148
158 1
158-3 1
158Apl
158Mpl
3031UP
3031AP
4321
4331 4
4331-2 4
4341
3081-D16
168
168-3
168AP
168MP
3032
3033UP
3033AP
3033MP
Not
Available
155
155 II
165
165-3
MYS/System Extensions
and MVS/SP Support
Extended ControlProgram Support J
System/370 System/370
Extended
Extended
Facility
Feature
Not
Standard z Available
3031UP
3031AP
3032
3033UP
3033AP
3033MP
3081
ECPS~
4341
MYS5
158 1
158-3 1
158Apl
158Mpl
168
168-3
168AP
168MP
135-3
138
145-3
148
3031UP
3031AP
4321
4331 4
4331-2 4
4341
135
145
155
155 II
158
158-3
158AP
158MP
165
165-3
168
168-3
168MP
3032
3033UP
3033AP
3033MP
3081
lYirtual machine assist and the System/370 Extended Feature are
mutually exclusive on a Model 158 processor except for Model 3 with
RPQ #MK3272 installed.
However, in a Model 158 attached processor
complex, virtual machine assist can be installed on one processor
while the System/370 Extended Feature is installed on the other, or
both may be installed on the attached processor (not the I/O
processor).
zUsers running VM/SP on a 135-3, 138, 145-3, or 148 with
ECPS:VM/370 may not realize the full benefit of ECPS:VM/370
because shadow table maintenance algorithms may be used in
preference to some ECPS:VM/370 algorithms.
JCompatibility must be established when using the functions contained
in VM/SP on systems with ECPS:VM/370.
To establish
compatibility, make sure that the service level is compatible with
the latest functional update to the hardware.
If compatibility is
not established, an error message is issued and ECPS:VM/370 is
nullified.
4No charge special feature if ordered with the processor.
5ECPS:MYS and ECPS:VM/370 are mutually exclusive on the 4341
processors.
On the 4341-2 and 4341-12 processors, ECPS:MVS and
ECPS:VM/370 may be used concurrently if the ECPS Expansion Feature
is installed.
Additional planning is needed to support the virtual=real option and virtual
machine assist, as well as ECPS:VM/370. All of these performance options are
described in detail in the VM/ SP System Programmer's Guide.
Chapter 10. Performance Guidelines
99
Specifying a Virtual==Real Machine
Although the virtual=real option eIiminates paging for the affected virtual machine,
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 '0. Virtual page 0 does not exist as real page 0; it
is relocated to the first real page after the virtual=real area. Because of the relocation of page 0, CCW translation must remain on if the virtual machine performs
I/O to page O.
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 they do
not use this area for input/output. However, violation of this restriction may cause
damage to the entire VM/SP 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 run 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 VM/SP initial program load (IPL). 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/SP. The virtual=real area must be released in total, that is, unused pages of the area cannot be
selected for release.
Each virtual machine logged on by CP requires some of CP's fixed free storage. If
a very large virtual=real area is released after VM/SP initialization, system performance degradation may occur as more and more users logon and use the
released space. The reason for this is that the number of pages allocated for CP
fixed free storage during VM/SP 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.
100
VM/SP Planning Guide and Reference
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 "Chapter 21. Preparing the CP System Control
File (DMKSYS)." The examples used in the following discussions assume that you
are allowing VM/SP to determine the number of free storage pages to allocate.
To use the virtual = real option effectively on a multipoint teleprocessing system
with no CCW translation (SET NOTRANS ON), lines must be dedicated to that
system via the ATTACH command or by VM/SP directory assignment. Conversely, on a multipoint teleprocessing virtual=real operation, virtual 2701/2702/2703
lines, (that is, lines assigned and used by CP's DEFINE and DIAL commands)
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.
You cannot run programs with dynamic or self-modifying channel programs in a
virtual=real area if you also use the DIAL command. Also, you cannot load (IPL)
a shared system into a virtual 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 nonshared system.
To generate CP so that it properly supports a virtual=real area, do the following:
•
Specify VIRT=REAL in the VM/SP directory for all virtual machines that you
plan to run in the virtual = real area.
•
Reserve enough DASD space for the CP nucleus.
•
Reserve enough real storage space to contain the CP nucleus, virtual=real
area, and other virtual machine requirements. Real storage space considerations are critical. If storage space requirements for the nucleus and
virtual=real area exceed the size of real storage, the real IPL operation on a
VM/SP system supporting virtual storage preservation will result in a hardware
load error.
•
Specify the amount of storage you want reserved for a virtual=real area.
"Chapter 18. Creating Your VM/SP Directory" describes the Directory program,
including information about the VIRT=REAL operand of the OPTION control
statement.
Note: With VM/SP extra DASD space is not required for a virtual=real system.
Chapter 10. Performance Guidelines
101
Real Storage Validation
VM/SP automatically validates real storage on the 3081 processor using the 3081
hardware instruction (TEST BLOCK). TEST BLOCK (TB) is an RRE format
instruction (four bytes long) that has an operation code of X'B22C'. When
VM/SP is loaded or initialized on a 3081 processor, VM/SP issues TB instructions
to validate 4 K blocks of real storage. This ensures that all page frames to be occupied by system modules are valid.
3081 real storage is not necessarily contiguous. One or more storage frames is
used as a hardware system area to contain channel microcode, control blocks, and
usage information. Since the hardware system area (HSA) is not addressable by
the control program, an attempt to access the HSA causes an addressing exception.
Thus, VM/SP uses TB on the 3081 processor to detect non-contiguous blocks of
real storage and recognize unusable storage frames.
At VM/ SP load, the loader uses the TB instruction as it relocates itself to the
high-end of storage and while loading the system modules into storage. The
VM/SP nucleus must reside in contiguous storage. If an unusable or
non-addressable frame is detected within the area reserved for the nucleus, the system load is stopped with a disabled wait state code X'AAAAAA'. There is one
exception. Non-addressable frames and frames having errors encountered in the
virtual=real area do not cause a disabled wait state at VM/SP load. Instead,
informational messages are sent to the system operator and the load continues. For
this reason, virtual machine operating systems that run in the V =R area on a real
3081 should use the TB instruction to validate their storage. When the V=R area
is unlocked, VM/SP automatically validates the area using TEST BLOCK.
When VM/SP is initialized on a 3081 processor, those modules involved in the:;J:PL
process issue TB instructions to determine the status of every frame of real storage.
If a non-addressable frame or a frame containing errors is detected within the area
reserved for the nucleus (excluding the V=R area), system initialization is stopped
with a disabled wait state code X'14'. Storage frames reserved for the V=R area
are not validated at VM/SP initialization. V =R frames are validated only at
VM/SP load time as described earlier. In both cases, VM/SP load and VM/SP
initialization, non-addressable or invalid frames encountered outside the nucleus
area are identified to the system operator by a series of informational messages.
VM/SP simulates TB for any virtual machine with EC mode capability regardless
of real processor type. However, VM/SP and MVS/SP are the only operating systems that may issue TB. When a virtual machine is running V = V on a 3081, or on
any other processor regardless of virtual machine mode, CP simulates all requested
TB instructions by setting the storage block and storage key to zero and returning a
condition code zero. For a V=R virtual machine running on a real 3081, CP performs a real TEST BLOCK and reflects the result to the virtual machine. If the
storage block is usable, the storage block and storage key are set to zero and condition code zero is returned. If the storage block is unusable, the storage block and
storage key remain unchanged. A condition code one is returned. A protection
exception is reflected to a virtual machine that attempts to issue a TB instruction to
a shared page.
102
VM/SP' Planning Guide and Reference
Virlual Storag~ Requirements
When generating VM/SP you have three limitations 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 machine you are using has
enough virtual storage to contain:
•
•
the loader
the CP nucleus (including the virtual=real area)
loader
+ nucleus being loaded + V=R area = total storage requirement
You must have an area larger than this total storage requirement to use the loader.
If your virtual machine does not have enough virtual 'storage, redefine storage and
IPL again before continuing.
Specifying the Amount of Virlual=Real Space
If you are generating a VM/SP system to include a virtual=real machine, during
the system generation procedure you respond "yes" to the system message:
VIRTUAL=REAL OPTION REQUIRED (YES,NO):
You are then prompted to enter the size of the virtual=real machine size:
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 of virtual = real storage available on your processor
as follows:
•
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 maximum virtual=real size (VRS) for any real
machine size. If VRS is negative or zero, a virtual=real area is not supported.
Chapter 10. Performance Guidelines
103
Calculating Available Real Storage (Formula 1)
Calculate available real storage (ARS) by subtracting the amount of storage
required by CP from the real machine size. Formula 1 is:
RM-
ARS
[
I + T + 12K + 4K
'[RM64K
- 256K]].
wherfJ:
RM
is the real machine storage size.
I
is the 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 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:
If the calculation RM/256K results in a fraction, the result should be
rounded upward to the next higher integer.
12K
is the fixed free storage allocated for the first 256K of real storage.
4K [RM - 256K ]
64K
is the 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 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.
104
VM/SP Planning Guide and Reference
CaicuiatiDg the Maximum Size of the Virtual=Real Area (Formula 2)
Calculate the maximum size of the virtual=real area for a particular real machine
size by recalculating the real storage required by CP and subtracting that value
from the real machine size. When you calculate the 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 - [I
+
T + 12K
+
4K [_RM_-_2_:_:_:_-_A_R_S ]
+
16K]
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 same calculation results in a
fractional number, disregard the fraction (see Examples 1 and 2). 16K is the storage needed at IPL time for the dynamic paging area. After VM/SP is loaded (via
IPL), the size of the dynamic paging area is the number of pages from DMKCPE
to DMKSAV plus 16K.
The following table shows the maximum size virtual=real area you can specify for
some real machine sizes.
Real Machine Size
Maximum VIRT=REAL Size
512K
768K
1M
2M
80K
332K
580K
1582K
The values in this table assume the value of I is equivalent to 388K9.
9
Since the amount of storage required to IPL VM/SP varies with the inclusion of optional features
and the number of devices in OMKRIO, this figure is used in the following examples for illustrative purposes only.
Chapter 10. Performance Guidelines
105
Example 1
Determine the maximum size of the virtual=real area for a real machine with 768K
of storage running in a VM/SP system that requires 388K to IPL.
Formula 1
~88K
ARS
768K -
ARS
768K -
ARS
768K - 444K
ARS
324K
256K
+ 4K [
:::: }
12K
+ 4K [ 768K 6:K
]
]
[388K + 12K + 12K + 32K]
Formula 2
12K + 12K + 4K t_6_8_K_-_2_:_:_:_-_3_24_J+ 16K ]
VRS
768K
VRS
768K
VRS
768K -
VR~
332K
[412K + 4K[2] + 16K
Note that the fraction (188/64) resulting from the
RM - 256K - ARS
64K
calculation in Formula 2 is rounded to the next lower integer, two.
106
VM/SP Planning Guide and Reference
Example 2
Determine the maximum size virtual=real area for a real machine with 2048K of
real storage. The VM/SP system requires 388K to IPL.
Formula 1
ARS
2048K -
~BBK
+ 4 { 204BK ]
+ 12K + 4K [ 204BK : 256K
256K
J]
6 K
ARS
2048K - [388K + 4K[8] + 12K + 4K[28]]
ARS
2048K - [388K + 32K + 12K + 112K]
ARS
2048K - [544K]
ARS
1504K
Formula 2
32K + 12K + 4K t_O_4_8_K_-_2_:_:_:_-_'_5_04_j
VRS
2048K
VRS
2048K -
VRS
2048K - [464K]
VRS
'584K
~
16K]
Note that the fraction (288/64) resulting from the
RM - 256K - ARS
64K
calculation in Formula 2 is rounded to the lower integer, four.
Chapter 10. Performance Guidelines
107
Example 3
Determine the maximum size virtual=real area for a real machine with 400K of
real storage. The VM/SP system requires 388K to IPL.
Formula 1
ARS
388K + 4K [
400K [
400K ] + 12K + 4K [ 400K-256K] ]
256K
ARS
400K - [388K + 4K[2] + 12K + 4K[2]]
ARS
400K - [416K]
ARS
-16K
64K
Since ARS is a negative number, CP cannot IPL and the following error message
informs you of this condition:
DMKCPI955W INSUFFICIENT STORAGE FOR VM/SP
Calculating DASD Space
To evaluate the relationship of DASD requirements to real storage space for saved
systems on DASD, use the following formulas:
(program size/4)/32
= number of 2314/2319 cylinders
(program size/4)/57
= number of 3330/3333 cylinders
(program size/4)/24
= number of 2305/3340/3344 cylinders
(program size/4)/120 = number of 3350 cylinders
(program size/4)/96
= number of 3375 cylinders
(program size/4)/150 = number of 3380 cylinders
(program size / 4 )
= number of FB-512 pages
Program size is the real storage size (in K bytes). K represents 1024 bytes.
108
VM/SP Planning Guide and Reference
Virtual Machine Assist
Virtual machine assist is a combination of a processor feature and VM/SP programming. It improves the performance of VM/SP. Virtual storage operating systems that run in problem state under control of VM/SP use many privileged
instructions and SVCs that cause interrupts that VM/SP must handle. When virtual machine assist is used, many of these interrupts are intercepted and handled by
the processor. Consequently, VM/SP performance is improved. The manner in
which virtual machine assist and Extended Control-Program Support
(ECPS:VM/370) are supported by the various VM/SP processors is detailed
under "Using Performance Options" earlier in this chapter.
Certain interrupts must be handled by VM/SP. Consequently, virtual machine
assist is not available if it:
•
•
Has an instruction address stop set
Traces SVC and program interrupts
Since an address stop is recognized by an SVC interrupt, VM/SP must handle SVC
interrupts while address stops are set. Whenever you issue the ADSTOP command,
VM/SP 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 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 tracing is completed.
If virtual machine assist is available on a processor, the operator, using the CP SET
command, can tum the function off, and on again, for the entire VM/SP system.
Also, if the function is available to VM/SP, each virtual machine operator can tum
the function off, and on again, for their own virtual machine. When you create
your VM/SP 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.
Chapter 10. Performance Guidelines
109
VM/370 Extended Control-Program Support
VM/370 Extended Control-Program Support (ECPS:VM/370) is a hardware
assist function that provides support over and above that provided by the virtual
machine assist feature described previously, and consequently reduces VM/SP's
real supervisor state time needed to support virtual machines. ECPS:VM/370 provides the following functions:
•
•
•
Expanded virtual machine assist
CP assist
Virtual interval timer assist
Whenever VM/SP 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 extensive emulation of the SSM,
LPSW, STNSM, 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
The appropriate CP software routine is used if:
•
•
•
CP assist is turned off
Hardware assist does not support the specific service required
An error condition occurs
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 an accurate and repeatable interval timer value for virtual machines.
Both virtual machine assist and expanded virtual machine assist are automatically
turned off if you start certain TRACE functions. In addition, virtual interval timer
assist is turned off if external interrupts are traced. When the tracing function is
stopped, CP automatically restarts these hardware assist functions.
For more details on VM/370 Extended Control-Program Support, refer to the
VM/SP System Programmer's Guide.
110
VM/SP Planning Guide and Reference
Queue Drop Eli1lfination
VM/SP attempts to optimize system throughput by monitoring the execution status
of virtual machines. When a virtual machine becomes idle, VM/SP drops it from
the active queue, invalidating the virtual machine's resident page and segment
tables. In certain special cases, a virtual machine is determined to be idle and is
dropped from the queue. However, the virtual machine becomes active again
sooner than expected. If this cycle of queue dropping and reactivation is run
repeatedly, the overhead involved in invalidating and revalidating the virtual
machine's pages may result in system degradation.
CP SET QDROP allows you to control this situation. See the VM / SP System Programmer's Guide and the VM/ SP Operator's Guide for details.
MVS / System Product and MVS / System Extensions Support
VM/SP enables an MVS system, running in a virtual machine, to use the
MVS/System Product or MVS/System Extensions program product. "Using Performance Options," earlier in this chapter, details VM/SP processors that have this
support available.
The following conditions are necessary to use the MVS/System Product or
MVS/System Extensions support on your virtual machine:
•
Hardware is available on the real machine
•
The operator has entered a SET S370E ON for your VM/SP system
•
370E appears on the directory OPTION statement for your virtual machine, or
you have entered the SET 370E ON command for your virtual machine
Note: The SET S370E command is invalid when running a VM under VM system.
Therefore, if you are attempting to run MVS on a VM under VM system, do not
set S370E on.
When this support is enabled, an operating system running in your virtual machine
can use these functions of System/370 Extended Facility:
•
•
•
•
•
Low address protection
Common segment support
Invalidate page table entry (IPTE) instruction
Test protection (TPROT) instruction
Virtual-machine extended-facility assist
Chapter 10. Performance Guidelines
111
112
VM/SP Planning Guide and Reference
Chapter 11. Attached Processor and Multiprocessor Systems
To generate an attached processor system it is necessary to reply" AP" when the
GENERATE or service EXEC (5664167) asks:
ARE YOU GENERATING AN "AP" or "MP" SYSTEM?--RESPOND (NOIAPIMP)
A response of "AP" causes DMKSPA CNTRL andAPLOAD (or AVLOAD for a
system with a virtual=real area) to be used in place of DMKSP CNTRL and
CPLOAD (or VRLOAD) EXECs.
DMKSPA MACLm
The OPTIONS COPY member of DMKSPA MACLIB is identical to OPTIONS
COPy in DMKSP MACLffi, except that the variable "&AP" is set to 1, causing
AP support to be included in the module you are assembling. DMKSPA CNTRL
uses this MACLIB to create a TXTAP rather than the usual TEXT, if the module
is affected by attached processor support.
Modules Providing AP Support
I
Seven modules exist exclusively for.AP and MP support. Nucleus-resident modules
are DMKLOK and DMKMCT. Pageable modules are DMKAPI, DMKCLK,
DMKCPO, DMKCPP, and DMKCPU. These modules have only an 'AP' text file
and their names are contained only in the AP and MP loadlists (APLOAD and
AVLOAD).
The modules that have TXTAP decks and are versioned for AP support can be
found using the following steps:
1. List all the TXTAP decks off the VM/SP base tape.
2. List all the TXTAP decks off the latest VM/SP PUT tape.
3.
Combining the two lists should produce a complete list of all TXTAP decks (all
AP versioned modules).
Chapter 11. Attached Processor and Multiprocessor Systems
113
To generate a multiprocessor system it is necessary to reply "MP" when the GENERATE or service EXEC (5664167) asks:
ARE YOU GENERATING AN "AP" or "MP" SYSTEM?--RESPOND (NOIAPIMP)
A response of "MP" causes DMKSPM CNTRL and APLOAD (or A VLOAD for a
system with a virtual=real area) to be used in place of DMKSP CNTRL and
CPLOAD (or VRLOAD) EXECs.
DMKSPM MACLm
The OPTIONS COPY member of DMKSPM MACLm is identical to OPTIONS
COpy in DMKMAC MACLm except that the variable" &MP" is set to 1, causing
MP support to be included in the module you are assembling. DMKSPM CNTRL
uses this MACLm to create a TXTMP rather than the usual TEXT, if the module
is affected by multiprocessor support.
Modules Providing MP Support
DMKIOS is the one module used in MP support that is different from AP.
DMKSPM MACLm contains OPTIONS COpy with the "&MP" variable set on.
The DMKRIO sample supplied with the VM/SP starter system contains a COPY
OPTIONS statement following the CSECT. If you are using your own version of
DMKRIO, be sure to include the COpy OPTIONS statement prior to assembly.
DMKRIO must be assembled using the DMKSPM control file, which will pick up
the .DMKSPM MACLm. To assemble, use the command:
I
VMFASM DMKRIO DMKSPM
114
VM/SP Planning Guide and Reference
Chapter 12. Plaiming for 3270s
VM/SP attachments can be either local or remote. Local attachments do not
require telecommunication lines. However, many devices supported for local
attachment are also supported for remote attachment. Remote attachments are
attached to binary synchronous lines. Such configurations usually include:
•
•
•
A designated channel.
A designated communication controller or transmission control unit.
The device or control unit (for terminal attachment and/or RJE systems).
Planning considerations for VTAM supported terminals attached to a VTAM service machine can be found in "Chapter 14. Planning for SNA Console Communications Services."
Remote Attachments
3270 support includes remote cluster and stand-alone configurations. This support
includes:
•
Nonswitched point-to-point binary synchronous transmission.
•
Switched binary synchronous transmission for 3275 terminals equipped 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 Decimal Interchange Code) transmission
code only.
•
327 Os supported as virtual machine operator consoles.
•
CP commands allowing the operator to start and stop the teleprocessing lines,
display stations and printers.
•
CMS Editor and System Product Editor (XEDIT) support.
•
The recording of MDR (Miscellaneous Data Recorder) records and OBR
(Outboard Recording) records on the VM/SP 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.
3270 copy support allows you 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 ~o the same control unit. If the printer is busy or
otherwise not available when the copy function is requested, you receive a NOT
ACCEPTED message on the screen.
The following restrictions apply to VM/SP's support of remote 3270s:
•
Remote 3270 terminals cannot be used as primary or alternate VM/SP system
consoles.
Chapter 12. Planning for 32708
115
•
The number of binary synchronous lines supported by VM/SP for 3270 use is
256 minus the number of 3704/3705 Communication Controllers.
•
Connections with multipoint clusters are not supported.
3270 Support on Billll1'Y Synchronous Li,.
Supported display devices on binary synchronous lines have the same flexibility and
usefulness as locally attached 3270 devices, except for the following limitations:
•
Display Information Inquiry and Retrieval Speed -- Because the 3270 remote
stations are subject to slow teleprocessing transmission speeds, the mechanics
of polling operations, screen display, and data entry are not as rapid for remote
3270 devices as they are for locally attached 3270s.
•
Hard Copy of 3270 Screen Image -- Just as users of locally attached 3270 display devices can spool their virtual console input and -output to the system
printer, so can users of remote 3270 display devices. However, for remote
3270 users, and local 3270 users whose terminals may be distant from the system printer, VM/SP provides a limited hard-copy function at the local and
remote locations. The RSCS Networking program product provides support
for printing spooled output.
•
TEST REQUEST and SYSTEM REQUEST Keys -- 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 REQUEST key.
Remote Hardware Configurations Supported
VM/SP'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. Transmission control
units supporting remote 3270s on binary synchronous lines, and cluster and
stand-alone control units supporting remote 3270s, are described in "Chapter 2.
Configurations. "
System Generation Requirements for Remotely Attached Display Systems
When generating VM/SP you must code appropriate CLUSTER, TERMINAL,
and RDEVICE macros and assemble them as part of the DMKRIO (real I/O configuration) file to support 3270s for CP use as virtual machine consoles. After
DMKRIO assembles successfully, you should make a list of resource identification
codes of all the remote 3270 lines and terminals. Give the list to your operations
group. The members of that group need this information when they issue CP
commands that control operation of remote 3270 lines and devices.
I
The RDEVICE macros must be coded in the same order as the CLUSTER macros.
(Refer to the example of a remote 3270 configuration, following.)
,
For a description of the CLUSTER, TERMINAL, and RDEVICE macros refer to
"Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)."
116
VM/SP Planning Guide and Reference
The Resource Identification Codes
The resource identification code is a four-digit hexadecimal code. The low-order
two digits of the resource identification code is the resource address. The
high-order two digits is the line code. The resource address is generated by
VM/SP. The order in which TERMINAL macros appear in DMKRIO determines
the resource addresses of the terminals defined. Each CLUSTER macro defines a
3270 control unit with a resource address of X'OO' through X'FF'. The device
defined by the first TERMINAL macro after the CLUSTER macro (in DMKRIO)
has a resource address of X'OI', the second has a resource address of X'02', up to
the maximum of X'20' (since X'20' represents the decimal maximum of 32 devices
on one control unit). This resource address is the low-order two digits of the
resource identification code.
The line code is also generated by VM/SP. Refer to the assembly listing for
DMKRIO to determine the line code (the high-order two digits of the resource
identific~tion code). Locate the label DMKRIORN near the end of the DMKRIO
assembly listing. This label identifies a list of all lines used by remote 3270s and by
3704/3705 Communications Controllers in EP mode. The high-order two digits is
the line code that is assigned in the order that 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/SP supports a
maximum of 256 binary synchronous lines for use by remote 3270s. Thus, the
maximum value of the two high-order digits is F. Figure 14 shows you a sample
DMKRIO assembly listing and the corresponding line codes. By looking at
DMKRIORN in this example you can see that four lines have been generated. This
simply means that the line codes for these four lines will be 00 - 03. If eight lines
had been generated the line codes would have been 00 - 07.
Line Code (in
hexadecimal)
Sample of DMKRIO Assembly Listing
DMKRIORN DC
DC
DC
DC
DC
DC
DC
DC
DC
F'4'
AL2«RDV07S-DMKRIODV)/S)
XL2'07S'
AL2«RDV07 A-DMKRIODV)/S)
XL2'07A'
AL2«RDV079-DMKRIODV)/S)
XL2'079'
AL2«RDV07B-DMKRIODV)/S)
XL2'07B'
00
01
02
03
Figure 14. Example of Determining Line Code for Remote 3270 Resource Identification Codes
Once you determine the resource identification codes for devices in your remote
3270 configuration, generate a list for operations. The list should include:
•
•
•
•
•
•
Line address
Line code
Resource address
Label of plug on control unit panel
Resource Identification code
Device type
Chapter 12. Planning for 32708
117
Note: The plug panels of the 3271 control unit and 3274 control unit ModellC
have up to 32 ports where terminals and printers can be attached. The 3276 has up
to 8 ports where the 3276 integrated display is attached and where up to 7 additional terminals or printers can be attached.
An Example of a Remote 3270 Configuration
The example below shows the contents of DMKRIO to define:
•
•
A clustered 3271 control unit with eight ports.
A stand-alone 3275 display station.
A second clustered 3271 control unit with eight ports.
Macros are coded so that the 3271 clustered control unit can sq.pport eight display
devices, or six display devices and two printers. To define such a configuration,
you must code 2 CLUSTER, 16 TERMINAL, and 2 RDEVICE macros defining
the 2 separate clusters. A 3275 stand-alone 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.
The real I/O configuration file for this example is:
DMKRIO
I CLUST078
CLUST07A
I CLUST079
CSECT
CLUSTER
TERMINAL
TERMINAL
TERMINAL
TERMINAL
TERMINAL
TERMINAL
TERMINAL
TERMINAL
CLUSTER
TERMINAL
CLUSTER
TERMINAL
TERMINAL
TERMINAL
TERMINAL
TERMINAL
TERMINAL
TERMINAL
TERMINAL
RDEVICE
RDEVICE
RDEVICE
CUTYPE=3271,GPOLL=407F,LINE=078,DIAL=NO
TERM=3277,SELECT=6040,FEATURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C1,FEATURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C2,FEATURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C3,FEATURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C4,FEATURE=OPRDR,MODEL=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,MODEL=3
CUTYPE=3271,GPOLL=407F,LINE=079,DIAL=NO
TERM=3277,SELECT=6040,FEATURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C1,FEATURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C2,FEATURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C3,FEATURE=OPRDR,MODEL=2
TERM=3277,SELECT=60C4,FEATURE=OPRDR,MODEL=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,ADAPTER=BSCA,
X
BASEADD=OBO,CLUSTER=CLUST078
ADDRESS=07A,DEVTYPE=3705,ADAPTER=BSCA,
X
BASEADD=OBO,CLUSTER=CLUST07A
X
ADDRESS=079,DEVTYPE=3705,ADAPTER=BSCA,
BASEADD=OBO,CLUSTER=CLUST079
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 assigned to display devices, and printers
can be interchanged among resource addresses assigned to printers. A printer cannot be attached at an address defined for a display device, and vice versa.
118
VM/SP Planning Guide and Reference
Note: CLUSTER macros need not be coded in ascending numerical order. However, the RDEVICE macros must be coded in the same sequence as their corresponding CLUSTER macros. As in the example above, CLUST078 is coded, then
CLUST07 A, followed by CLUST079. The RDEVICE macros follow the same
sequence; RDEVICE 078, RDEVICE 07 A, RDEVICE 079.
Line
Address
Line
Code
Resource
Address
078
00
00
01
02
03
04
05
06
07
08
079
07A
02
01
00
01
02
03
04
05
06
07
08
00
01
02
Label of
Plug in
Control
Unit
Panel
-0
1
2
3
4
5
6
7
-0
1
2
3
4
5
6
7
--
---
Resource
Identification
Code
Type
0000
0001
0002
0003
0004
0005
0006
0007
0008
cluster
display
display
display
display
display
display
printer
printer
0200
0201
0202
0203
0204
0205
0206
0207
0208
cluster
display
display
display
display
display
display
display
display
0100
0101
0102
cluster
display
printer
Device
Figure 15. Sample List of Resource Identification Codes for Operations
Note: The line code is determined by referring to Figure 14; it corresponds to this
example.
Local Hardware Configurations Supported
Control units attached directly to the processor channels, and the display stations
and printers that attach directly to them, are described in "Chapter 2. Configurations."
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 supported DASD or unit record
devices. The channel, control unit, and devices are handled by their respective
RCHANNEL, RCTLUNIT, and RDEVICE macros. See "Chapter 19. Preparing
the Real I/O Configuration File (DMKRIO)" for further details.
Chapter 12. Planning for 3270s
119
120
VM/SP: Planning Guide and Reference
Chapter 13. Planning for the 3704/3705 Control Program
The IBM 3704 and 3705 Communications Controllers
The IBM 3704/3705 Communications Controllers can support:
•
Up to 352 low speed start-stop lines.
•
Up to 60 medium speed synchronous lines.
•
Line speeds from 45.2 baud to 56.0K baud.
•
Modem capability within the 3704/3705.
•
Limited-distance "hard-wire" capability.
•
16K to 256K internal storage.
•
Remote 3275, 3276, 3277, 3278, and 3279 terminals with optional 3284,
3286, 3287, 3288 and 3289 printers (EP mode only).
•
Remote 2780 terminals (EP mode only).
•
Emulator Program (EP) Version 3.0.
VM/SP's support of the 3704/3705 does not include:
•
Remote 3704/3705 Communications Controllers.
Related Publications
The Introduction to the IBM 3704 and 3705 Communications Controllers, Order
No. GA27-3051, describes the general functions of the 3704 and 3705. It is an
essential publication for generating a 3704/3705 control program under VM/SP.
Additional 3704/3705 publications are listed in the Preface.
3704 and 3705 Support Package
Before you can generate a 3704/3705 control program, you must have the following OS/VS Emulation Program Support Package. This is the only 3704/3705 support package that contains the eMS files required for generating and loading the
3704/3705 control program under VM/SP. The support package is:
•
IBM 3704/3705 Emulation Support and System Support Package (EP/VS
SCP) for OS/VS (order No. 5744-AN1). VM/SP supports this package in
emulation mode only.
This package contains the following basic material:
•
A Program Directory
•
Related 3704/3705 publications
Chapter 13. Planning for the 3704/3705 Control Program
121
•
A magnetic tape containing the macros and modules of the 3704/3705 control
program and the OS/VS system support programs.
VM/SP Support of the 3704 and 3705
VM/SP supports all models of 3704 and 3705 Communications Controllers. Three
terminals are supported on start-stop lines: 1050,2741, and CPT-TWX 33/35.
The 3767 terminal (operating as a 2741) is supported by lines in EP mode. The
3101 and 3232 display terminals are supported as CPT-TWX 33/35.
The minimum internal storage required by an EP control program is 16K.
When planning for the installation of IBM 3704 and 3705 Communications Controllers, be sure that you are familiar with device characteristics, have the appropriate publications and support package, and have a VM/SP system that supports the
3704/3705.
Emulation Program (EP) with VM/SP
The IBM 3704 and 3705 Communications Controllers are programmable units.
The Emulation Program (EP) can be generated to run in 3704/3705 storage.
The Emulation Program permits existing teleprocessing systems, including VM/SP,
which use the IBM 2701,2702, or 2703 Transmission Control Units, the 2703
Compatible Communications Adapter of the 4331 processor, or the Integrated
Communications Adapter (lCA) of the System/370 Models 135, 135-3, and 138
to run without change on the 3704/3705.
In this publication, the term "3704/3705 control program" refers to the EP control
program.
The EP 3704/3705 control program under VM/SP:
•
Emulates 2701, 2702, and 2703 operations.
•
Attaches to a byte multiplexer channel.
•
Supports up to 255 start-stop lines for 1050,2741, and CPT-TWX (33/35)
terminals.
•
Supports up to 50 medium-speed synchronous lines for 3270 and 2780 terminals.
•
Supports service programs and special CMS commands that allow you to generate the EP control program in a CMS virtual machine.
•
Supports the CP NETWORK command that allows you to load or dump the
3704/3705 and provides for automatic dumping and reloading if a fatal error
occurs.
Planning Considerations
The generation of a 3704 or 3705 Communications Controller control program
that runs under VM/SP is normally done after VM/SP system generation is complete. However, when a 3704 or 3705 is to be generated, the following preparations must be made:
122
VM/SP PI
ning Guide and Reference
•
An RDEVICE macro instruction for the 3704 or 3705 must be included in the
real I/O configuration (DMKRIO) file.
•
3704/3705 control programs to be used by VM/SP must be stored on a
CP-owned volume in the page format currently used for saved virtual machine
systems (that is, those created by the SAVESYS command). Each 3704/3705
control image to be saved must be defined by a NAMENCP macro instruction
in the system name table (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.
Note: The alternate console for VM/SP must not be on a telecommunication line
on a real 3704/3705, unless the 3704/3705 is loaded by another operating system
'(OS/VSl, OS/VS2, or DOS/VS) before VM/SP is loaded.
The VM / SP Installation Guide contains a complete discussion on generating a
3704 or 3705 control program. It describes 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
I
The RDEVICE macro is described in "Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)."
Creating an Entry in the System Name Table
You must create an entry in the system name table (DMKSNT) for each different
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/SP. In this way, you need not regenerate
the VM/SP system just to update the system name table. If you should have to
regenerate the VM/SP system to add a new entry to the system name table, see the
discussion about the GENERATE EXEC procedure in the VM / SP Installation
Guide.
The NAMENCP macro is described in "Chapter 20. Preparing the System Name
Table File (DMKSNT)."
Reserving DASD Space for the 3704/3705 Control Progrom 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 enough to contain the
number of pages specified in the SYSPGCT operand of the NAMENCP macro,
plus one or more for system use.
If CPTYPE=EP, allow only one extra page.
These additional pages are used to store reference table information provided by
the SAVENCP program.
Chapter 13. Planning for the 3704/3705 Control Program
123
124
VM/SP Planning Guide and Reference
Chapter 14. Planning for SNA Console Communication Services
The Systems Network Architecture Console Communications Services (SNA CCS)
provides a total data communication structure for transmitting information via a
communications network. SNA communication products perform functions traditionally handled by the main processor. For example, management of communications lines, device dependent characteristics and control, and data formatting).
SNA CCS provides full VM/SP console capabilities to operators on SNA
terminals. You can use SNA terminals as virtual machine consoles. The specific
communication services and facilities used in exchanging information are transparent. If you are planning to use SNA CCS processing, you must consider the following topics.
Structure of the SNA Environment
Three major components contribute to SNA console support:
•
•
•
SNA Console Communications Services (SNA CCS)
Inter-User Communication Vehicle (lUCV)
VTAM Communications Network Application Program Product (VCNA)
IUCV and SNA CCS are part of VM/SP.
SNA virtual console support is provided through a virtual machine. The VTAM
service machine (VSM) is the virtual machine that acts as an interface between
SNA CCS and the SNA network. The VTAM service machine consists of:
•
Virtual Telecommunication Access Method (VTAM). This can be either
ACF/VTAM or ACF/VTAME.
•
VTAM Communications Network Application Program Product (VCNA) and
one of the following operating systems with External Interrupt Support (EIS):
VSE/ Advanced Functions (most current level)
OS/VSl with Basic Programming Extensions Program Product
Chapter 14. Planning for SNA Console Communication Services
125
NCP and PEP Sharing "
CP supports version 2.1 of the Network Control Program only. VTAM loads
ACF/NCP. You must prevent CP from loading a back level of the NCP at initialization or restart. This can be accomplished in several ways. All methods depend
on your procedures.
One method is to initialize CP, but not enable lines until the VTAM service
machine (VSM) has been initialized. A similar technique could be used when you
wish to load the NCP prior to initializing the VSM. You can initialize CP without
enabling lines. Load the NCP using your own CMS EXEC and then enable the
lines. When the VSM is initialized, neither CP nor VTAM reloads.
Another method is to alter your system generation slightly by not specifying
CPNAME= in the RDEVICE macro statement for the 370x device. This prevents
automatic loading of the 370x at initialization via IPL. The VTAM service
machine would then load the ACF/NCP.
In all cases, the 370x must be dedicated to the VSM. Loading and reloading of the
370x is controlled by the VSM.
The Partitioned Emulation Program (PEP) is shared by CP and the VTAM service
machine. The 370x must be dedicated to the VSM. PEP is loaded by VTAM.
Once the load is complete, EP lines are disabled. The lines can then be enabled for
use by CPo If the 370x is reloaded under control of the VSM, EP lines must be
enabled for CP users.
Tracing for SNA Console Communications Services
SNA CCS places a trace entry in the CP trace table for each inbound and outbound work transaction. The trace entry identifies the type of IU CV transmission,
the SNA user, and the important characteristics of the transaction. The transaction
can be tracked throughout the system by use of the SNA CCS work element block,
WEBLOK (passed to VCNA), the SNA CCS and VCNA path id's, and the IUCV
message id. These fields can be matched with corresponding or similar fields in the
IUCV trace elements in CP and VCNA trace elements in VTAM.
Normal Trace
SNA CCS creates trace table entries in the CP trace table, leaving an audit trail of
its activities. This trace is started automatically. If you want to turn it off, set
TRACE(9) to (0) in the LOCAL COpy control statement and reassemble the
SNA modules.
126
VM/SP Planning Guide and Reference
Error Trace
In addition to the normal trace function described above, SNA CCS includes an
error trace function. You can include the error trace independent of the normal
trace. For error trace processing, SNA CCS places an entry in the CP trace table
for logical errors and unexpected return codes from IUCV transmissions. If the
WEBLOK that is passed between SNA CCS and VCNA is invalid, data in the
trace element pertains to the invalid WEBLOK.
The error trace function is started automatically. If you don't want to use it, set the
SNA CCS error trace bit off (X'40') in the CP trace flags, TRACFLG3, of the
PSA (hex location 402).
Excluding SNA CCS Modules
If you do not want to use support provided by SNA CCS, you can eliminate the
SNA CCS modules to save storage. You should· delete the five SNA CCS modules
(DMKVCP, DMKVCR, DMKVCT, DMKVCV, and DMKVCX) by excluding
them from the loadlist. See "Chapter 3. Estimating VM/SP Storage
Requirements" for more information on excluding SNA CCS support modules.
The size of the CP nucleus can be decreased further by eliminating the SNA routines in modules DMKQCN and DMKCPV. To eliminate the SNA routines in
modules DMKQCN and DMKCPV, reassemble them with the LOCAL COpy
control statement for SNA set off.
The format of the LOCAL COpy control statement to exclude SNA CCS processing is:
&SNAVCS SETB 0
Chapter 14. Planning for SNA Console Communication Services
127
128
VM/SP Planning Guide and Reference
Chapter IS. Planning for the 3800 Image Library
The generation of a 3800 image library that runs under VM/SP is normally done
after the VM/SPsystem 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 to be used by VM/SP must be stored on a CP-owned
volume in the page format currently used for saved virtual machine systems
(those created by the SAVESYS command). All 3800 image libraries are in
the system name table (DMKSNT), and are saved with IMAGELm or
IMAGEMOD commands.
•
Enough space to contain the 3800 image library must be allocated on the
CP-owned volume specified in the NAME3800 macro instruction.
•
Decide which character sets, form control buffers (FCBs), and copy modifications will be used. The specification of these elements is done through
IEBIMAGE control cards as described in the VM/SP Operator's Guide.
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 named system is used
to contain 3800 character arrangement tables, copy modifications, graphic modifications, and FCBs. They can then be referenced by name and 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 "Chapter 20. Preparing the System Name Table File (DMKSNT)."
Programs exist to enable you to dynamically change:
•
•
•
•
Character arrangement tables
Graphic modifications
Copy modifications
FCBs available
With these programs (GENIMAGE, IMAGELm, and IMAGEMOD), and the
named system support discussed above, you can make these changes dynamically,
without a VM/SP system load. GENIMAGE, IMAGELm, and IMAGEMOD are
described in detail in the VM/SP Operator's Guide.
Chapter 15. Planning for the 3800 Image Library
129
Coding the RDEVICE Ma~ro
The RDEVICE macro is described in "Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)."
As a VM/SP real spooling device, the following hardware features of the 3800 are
supported:
•
Automatic loading of character arrangement tables and graphic modifications
•
Full support of the additional storage character generation feature
•
Forms overlay feature (flashing)
•
Copy modifications
The use of multiple character arrangement tables for printing use within one spool
file (TRC support) is not supported. However, this feature is supported through
use of a virtual 3800.
Related Publications
The Concepts of the IBM 3800 Printing Subsystem manual, GC20-1775, is a first
reader for users of printers who wish to take a quick look at the non-impact IBM
3800 Printing Subsystem, its basic concepts, and how these concepts lead to new
functions that may offer different options in planning and operations.
The Reference Manual/or the IBM 3800 Printing Subsystem, GA26-1635, provides
information on 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 listed for copy modification and control and
graphic character modification.
The IBM 3800 Printing Subsystem Programmer's Guide, GC26-3846, provides
planning information for the IBM 3800 Printing Subsystem and information on
how to use the 3800.
130
VM/SP .Planning Guide and Reference
Chapter 16. Planning for the 3850 Mass Storage System
Generating a VM/SP System that Supports a 3850
The 3850 Mass Storage System (MSS) supplies large amounts of online data under
system control. Up to 472 billion bytes of data space is available, allowing you to
place significant amounts of tape and DASD shelf data under direct system control.
Up to four virtual machines concurrently running OS/VSl, MVS, or SVS operating
systems with MSS support can each control an interface to a common 3850 Mass
Storage System.
Hardware Supported
Support for the 3850 is available on the following processors supported by
VM/SP:
System/370 Models 145, 145-3, 148, 15511, 158UP/AP/MP,
16511, 168UP/AP/MP, 3031UP/AP, 3032, 3033UP/AP/MP,
3033-N, 3033-S, 3042AP-2, 3081 and the 4300 processors.
Major hardware components of MSS are:
•
The 3851 Mass Storage Facility (MSF)
•
The 3830 Model 3 Storage Control for System/370 Models 145, 145-3, 148,
15511, 158, 16511, and 16& or the Integrated Storage Control for the
System/370 Models 158 and 168
•
The 3333 Disk Storage and Control (Models 1 or 11)
•
3330 Disk Storage Drives (Models 1, 2, or 11)
•
3350 Disk Storage Drives (Real Only)
Mass Storage Control (MSC) is a microprogrammed processor that provides operational control for components of Mass Storage System. It is housed in the 3851
Mass Storage Facility. MSC may have four 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 the byte multiplexer channel or block multiplexer channel operating in
burst mode. The MSC channel interface is used for transfer of orders, commands,
control information, and status messages between the host system and MSC. It
does not carry user application data.
Up to four operating systems containing MSS support (OS/VSl, SVS, or MVS)
may be connected to MSC. These operating systems may be running in a virtual
machine under VM/SP, or in a real processor, connected to the same MSC as
VM/SP. 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 MSS.
Chapter 16. Planning for the 3850 Mass Storage System
131
The MSS uses the 3333 control unit and the 3330 Modell, 2, or 11 for staging
data and for holding tables it requires for its operation. These units connect to tbe
Mass Storage Facility and to the processor through a staging adapter. Several
models of the 3330 may be mixed on the staging adapter. 3330 disk drives can be
one of the following:
•
•
•
Real
Staging
Convertible
Real DASD drives are not available to the MSS for any activity. They are 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 MSS. Staging drives are used to hold
data staged from mass storage volumes to be available for processing. 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 drives are
logically divided into 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 staging drives; a logical drive being the equivalent of one 3330 Modell. One 3330 Model 11 counts
as two logical staging drives.
Convertible drives can be real or staging drives, but not both at the same time. If
the drive is to be 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.
Note: Information describing MSS hardware can be found in Introduction to the
IBM 3850 Mass Storage System (MSS).
On a 3850 Mass Storage System the Mass Storage Control can contain at most
four channel interfaces to a single processor. 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 ahemate channels.
132
VM/SP Planning Guide and Reference
For each of the three remaining (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 MSC. Transfer of data between the staging space and the Mass Storage Facility, is also under control of MSC, which 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/SP system, the addresses known to VM/SP
are the MSC's channel interfaces and the device addresses to the channel interface
positions on the Staging Adapter. MSC is supported in VM/SP only as a dedicated
device. For a virtual machine to access MSC, at least one of the MSC channel
interfaces must be dedicated to the virtual machine.
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 represent 3330-1 volumes. With the proper programming
support, they may be used for all purposes that a 3330-1 volume is used except
VM/SP system residence, paging, and spooling.
3330V devices may be used in three ways in VM/SP:
•
Mounted and us~d as VM/SP system volumes (excluding system residence,
paging and spooling) under the control of CP.
•
Dedicated to a virtual machine as a 3330-1 and accessed from the virtual
machine using standard 3330-1 support.
•
Dedicated to a virtual machine as a 3330V, in which case the virtual machine
must contain MSS support.
A 3330V device address is not manually available to the VM/SP 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 MSC. MSC is supported as a dedicated device under VM/SP, and
full MSC support is in OS/VSl and MVS. Therefore, to mount and demount
3330V volumes for VM/SP use, CP communicates with an OS/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. CMS users may access CMS minidisks on MSS volumes. One MSS 3330V volume may contain 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/SP system volumes
is accomplished by CP communicating with an OS/VS system in a virtual machine.
There is an MSS communication program named DMKMSS that is part of the
VM/SP system, but runs in problem program state in an OS/VSl or MVS system.
This DMKMSS program is the interface between CP and MSC support in OS/VS.
Chapter 16. Planning for the 3850 Mass Storage System
133
Obtaining the MSS C,mmunicator Program
When there is a Mass Storage System (MSS) attached to your VM/SP system, you
can use the DMKMSS program to communicate between the VM/SP control program and the MSC. This enables VM/SP to dynamically mount and demount MSS
volumes. In this case, you should obtain the file that will install the DMKMSS program in a VS system. The required file is distributed with the VM/SP control program object code, which resides on userid MAINT's 194 minidisk. The first step is
to ensure that MAINT has access to its 194. Logon the MAINT virtual machine
and issue the CMS command:
access 194 d/a
For a cardless system, prior to punching any files, spool the virtual punch to yourself:
sp pu
*
Next, punch the file; this will install DMKMSS in your VS system. If your VS system is OS/VS1, issue the command:
punch mssvs1 jcl
If your VS 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 run the jobs in your OS/VS system, they will install the DMKMSS program and create a VS operator procedure called DMKMSS. This procedure is later
used to s~art the program in the communicator virtual machine.
OS/VSl Jobs
There are four OS/VSl jobs. They are:
134
•
LINKDMK - This job linkedits the object code for DMKMSS into the
SYSl.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 IEFI61SD) in the
system program properties table. These lists are used in the next job.
•
APFZAP - This job, as distributed with VM/SP, replaces the module
IEHATLAS with DMKMSS in the program properties table; this adds
DMKMSS as an authorized program and removes IEHATLAS. If you wish 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 SYS I.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/VS 1 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.
VM/SP Planning Guide and Reference
OS/VS1Jobs
There are two OS/VS2 jobs. They are:
•
LINKDMK - This job linkedits the object code for DMKMSS into the
SYSl.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 DMKMSS to the SYS 1.PROCLIB
data set. After this job completes, the OS/VS2 system operator may start the
DMKMSS program by issuing the OS/VS2 operator command 'START
DMKMSS'. Before you run job LINKPROC, you must place the communicator device address on the COMM control statement.
It is not necessary to generate a VS operating system specifically for the virtual
machine environment. Any OS/VSl or MVS system that supports MSS can use
VM/SP MSS support, and can act as host for the communicator program. There
is, however, a requirement for MSS I/O device.s in the VS system to match the
definition of the virtual machine.
When OS/VS is IPLed, the system tests for any 3330Vs not online. When one is
found, an order is issued to MSC for demount. The 3330V address is passed to
MSC. The order tells MSC to demount any volumes currently mounted on that
3330V.
A 3330V may be offline to a virtual machine because none of VM/SP's 3330Vs
were allocated to the virtual machine at that virtual address. However, the 3330V
may be a valid address to MSC. If the virtual machine issues a demount order to
one of these 3330V devices, a volume in use by VM/SP or another virtual machine
MSC can be demounted.
The following rule must be used when defining (via 10GEN) 3330V devices in a
VS system to run in a virtual machine to which an MSC interface is dedicated.
For each 3330V defined in the VS system there must be a corresponding 3330V
defined to VM/SP 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 33 30Vs 140-17F can
be defined (via 10GEN) in the OS/VS system running in CPUID 22222.
Chapter 16. Planning for the 3850 Mass Storage System
135
Defining the MSS Communication Device
CP issues 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 control language used to
start DMKMSS in VS. For example:
//MSSCOMM
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. It is a VS requirement to
provide a UNITNAME statement for this device, for example:
UNITNAME NAME=017,UNIT=017
The Mtm Storage Control Tables
This topic is provided for those who 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 MSS
only upon request from VM/SP, 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 plan to run more than one MSS virtual machine
or to run VS MSS jobs in the MSS communication virtual machine).
MSC is controlled by tables that reside on DASD. These tables are used, among
other things, to define the MSS configuration. This configuration includes such
items as addresses to be used for all components of the system, and available paths
from all connected hosts to all these component devices. 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
processor channel attachment to the staging adapter.
When a virtual machine is given access to MSS, one interface to MSC is dedicated
to that virtual machine. To MSC, this is the same as having that interface connected to a native processor. The MSC tables must be constructed so that MSC
can process requests from the virtual machine. MSC must treat the requests as if
they came from a native processor, controlling other components of MSS such that
MSS activity, as seen by VM/SP 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 the MSC upper interfaces dedicated to it. Suppose
that VM/SP's 3330V 250 is dedicated to the virtual machine as virtual device
136
VM/SP Planning Guide and Reference
address 150. When virtual CPUID 12345 issues an order to 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/SP 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/SP 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. Interruptions received from the virtual machine's 150 are received on VM/SP'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/SP's 250 is the
volume demounted.
Two different virtual machines, having the same virtual device addresses can run
concurrently under VM/SP. 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.
Example
One configuration has a native processor with two block multiplexer channels,
channell and 2, and one Staging Adapter. Channell 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/SP 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 must 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.
Chapter 16. Planning for the 3850 Mass Storage System
137
Creating MSS Volumes
Before a pair of MSS data cartridges can be treated as a volume or accessed as
VM/SP system volumes, they must be initialized as the image of a 3330-1 disk
pack. 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 Access Method Services, which in turn is a
standard component of OS/VS 1 and OS/VS2. CREATEV can run either under
VS on a native processor, or under 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 issued from either
a native processor or a VS virtual machine. CONVERTV will make a bit by
bit copy of the 3330-1 on the MSS 3330V.
•
All or 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/or VS System Residence
A VS system can be loaded in a virtual machine from a 3330V volume because
VM/SP can make the virtual IPL device appear to be a 3330-1. The following
steps describe one way this can be done:
138
•
Use the CREATEV command to create an MSS volume with a volume serial
number of VOL001.
•
Define a directory entry for a virtual machine (VS2VM) with an MDISK
statement, describing a minidisk spanning cylinders 1 through 401 on volume
VOLOO1.
•
VM/SP mounts VOLOOI and allocates the minidisk when VS2VM 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 VS2VM.
•
IPL the virtual device address corresponding to the minidisk as a VS2 system
residence device.
VM/SP Planning Guide and Reference
The YM/SP RDEYlCE MIICI'O
The 3330V device addresses generated in CP 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).
When coding the RDEVICE macro for a 3330V device address, either
FEATURE = VIRTUAL or FEATURE=SYSVIRT must be coded, where:
•
VIRTUAL defines a 3330V that may not be used for system volumes. It may
be dedicated or attached to virtual machines as a 3330-1 or 3330V.
•
SYSVIRT defines a 3330V that is used for VM/SP system volumes. MSS volumes that are 3330V, can be mounted as SYSVIRT 3330V devices, but cannot
be dedicated or attached to a virtual machine.
Chapter 16. Planning for the 3850 Mass Storage System
139
140
VM/SP Planning Guide and Reference
Part 2. Defining Your VM/SP System
Part 2 describes macros and control statements you need to define your VM/SP
system. It contains:
•
Introduction to System Definition
•
Creating your VM/SP Directory
•
Preparing the Real I/O Configuration File (DMKRIO)
•
Preparing the Systeni Name Table File (DMKSNT)
•
Preparing the CP System Control File (DMKSYS)
•
Additional System Definition Files
Part 2. Defining Your VM/SP System
141
142
VM/SP Planning Guide and Reference
Chapter 17. Introduction to System Definition
Before starting system generation on a real machine, you must create three files
that describe the VM/SP system you are generating. There are two optional additional files. You can use card input, or create these files using the System Product
Editor. If you are modifying an existing VM/SP system, you can use the System
Product Editor to alter existing files. You can also use other systems to create
these files on tape in a card-to-card image, or use another VM/SP or VM/370 system to create a tape in tape dump format. In these cases you have to bring the files
into the system generation process using the CMS commands TAPE LOAD,
MOVEFILE, and TAPPDS.
Three files that you must prepare are:
•
Real I/O configuration file (DMKRIO), which defines the I/O configuration
on the real machine.
•
CP system control file (DMKSYS), which defines the usage of CP-controlled
DASD volumes, and starter system defaults.
•
VM/SP directory file (normally a CMS file named USER DIRECT), which
contains the VM/SP directory entries that define the virtual machine configuration for each user.
You can also change the forms control buffer load (DMKFCB).
ISystem Integrity
In addition, you should prepare the system name table (DMKSNT) 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 can not be loaded by VM/SP.
"Chapter 9. Saved Systems and Discontiguous Segments" describes the requirements for saving systems.
An operating system is said to have system integrity when it is designed, implemented, and maintained to protect itself against unauthorized access, and does so
to the extent that security controls specified for that system cannot be compromised. VM/SP Control Program system integrity is defined as the inability of any
program running in a virtual machine not authorized by a VM/SP Control Program
mechanism under the customer's control, and/or a guest operating system mechanism under the customer's control, to:
1.
Circumvent or disable the Control Program main or secondary storage protection
2. Access a Control Program (CP) password protected resource
3.
Obtain control in real supervisor state, or with privilege class authority or directory capabilities greater than those it was assigned
4.
Circumvent the system integrity of any guest operating system, which itself has
system integrity (i.e., MVS or VM/SP) as a result of an operation by any
VM/SP Control Program facility.
Chapter 17. Introduction to System Definition
143
The following terms apply to the system integrity definition:
main storage protection: refers to the isolation of one virtual machine from another,
which the Control Program accomplishes by the use of hardware Dynamic Address
Translation.
secondary storage protection: refers to the disk extent isolation implemented for
minidisks/virtual disks by the Control Program (CP) through channel program
translation.
password protected resource: refers to resources protected by Control Program
(CP) logon passwords and minidisk passwords.
directory capabilities: refers to those directory options that control the use of functions intended to be restricted by specific assignment, such as those that permit system integrity controls to be bypassed or those not intended to be generally granted
to users.
guest operating system: refers to a system control program that operates under the
VM/SP Control Program.
VM/SP system integrity applies to the following environments for MVS guest
machines only:
•
•
•
•
V=R with the NOTRANS option
V=R with the Shadow-Table-Bypass SET command option
The Preferred Machine Assist
The Single Processor Mode.
However, when any of these facilities are used within an MVS guest machine, an
MVS user or program that has been given authority to bypass MVS system integrity controls may also be able to bypass the system integrity controls built into
VM/SP. In these circumstances, it is the customer's responsibility to assure that
the required MVS system integrity controls are installed, and that authorized programs and users are properly controlled.
ICustomer Responsibilities
VM/SP Control Program system integrity does not specifically include the protection of data between multiple users of a single CMS batch system, nor does it
apply to virtual machines using Non-Disruptive Transition (NOT) support.
Protection of the customer's data remains the customer's responsibility. For system
integrity to be meaningful, proper use of security controls is essential.
Some areas for which effective controls should be implemented are:
•
•
•
•
144
VM/SP Planning Guide and Reference
Password protection
Assignment of appropriate privilege classes
Assignment of directory options
Set up and authorization of guest virtual machines.
Particular actions and restrictions may vary, depending on the system configuration
or environment. The customer is responsible for the selection, application, adequacy, and implementation of these actions and restrictions, and for appropriate application controls.
Note: IBM will accept APARs that describe exposures to the system integrity of
VM/SP or that describe problems where a program running in a virtual machine
not authorized by a mechanism under the customer's control introduces an exposure to the system integrity of VM/SP. A customer who discovers a system integrity problem or exposure should report it to the Customer Support Center (FE Level
1).
Chapter 17. Introduction to System Definition
145
146
VM/SP Planning Guide and Reference
Chapter 18. Creating Your VM/SP Directory
The VM/SP directory contains the entries of all potential virtual machines permitted to logon the VM/SP system. Without the proper directory entry, a user cannot
logon to VM/SP. Entries in the directory contain:
•
User identification and password
•
Virtual machine I/O configuration
•
Associated virtual and real addresses
•
Disk usage values
•
Virtual processor storage size
•
Other options
There must be at least one CONSOLE or SPOOL directory entry for each user,
except those whose password is NOLOG. These options are discussed in the directory program control statement descriptions.
The directory usually resides on the VM/SP system residence disk, and is pointed
to by the VOLIlabel. On a count-key-data DASD, this is at cylinder 0, track 0,
record 3. On an FB-512 DASD, it is at absolute block 5. The VM/SP Directory
program (module DMKDIR, started by the DIRECT command, or run
stand-alone) processes your control statements and writes the directory on disk.
You describe your real configuration when you create the real I/O configuration
file (DMKRIO). You describe your many virtual configurations with Directory
program control statements.
To create a VM/SP directory, you must:
•
Prepare Directory program control statements
•
Format and allocate DASD space to contain the directory
•
Run the Directory program
During system generation, you must (I) format and allocate DASD space for the
directory and (2) generate it.
Chapter 18. Creating Your VM/SP Directory
147
Considerations for Preparing the Directory Control Statements
First, prepare a directory control statement that defines the device on which the
VM/SP directory is to be written. This statement (DIRECTORY) must be the
first control statement in the input to the Directory program. It is followed by the
sets of statements describing your virtual machines.
Next, prepare Directory program control statements describing each virtual
machine. The descriptions contain accounting data, options, and virtual machine
configurations for each virtual machine that appears in the VM/SP directory.
VM/SP does not check for overlapping extents. Therefore, you must ensure that
minidisk extents defined in the VM/SP directory do not overlap each other and (in
the case of 3330, 3340, and 3350 disks) do not overlap the "alternate track" cylinders. If overlap conditions exist, file data damage is inevitable. You must define
one or more virtual machines for the operator. You should define virtual machines
for the system analyst or system programmer.
The operator's virtual machines control:
•
The VM/SP sessions
•
Allocation of machine resources
•
Spooling activity
•
Online disk areas
Also define virtual machines for system analysts that:
•
Perform system analysis
•
Modify certain VM/SP functions
and virtual machines to update or operate:
148
•
The CP system
•
The eMS system
•
The hardware
•
Other operating systems that run in the virtual machine environment
VM/SP Planning Guide and Reference .
System Suppo~ Virtual Machines
At system generation, two additional virtual machines should be created beyond
those needed by VM/SP users. These machines include one each for hardware and
software support. IBM FE programming support should be consulted when you
establish these virtual machines.
Hardware Support
The hardware support is for:
•
The processor, which must be supported in a dedicated environment. This is
because there is no method available that allows concurrent support of the
processor, real storage, and channels when running problem programs.
•
Input/output equipment, which can be supported using online test (OLT)
under OLTSEP. The OLTSEP program can be run in its own virtual machine.
Any offline testing capabilities of 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/SP directory for the IBM service representative. The virtual machine should
have enough virtual storage defined to run OLTSEP. Normally, the device being
tested is dedicated to the service representative's virtual machine. The system
operator can dedicate devices to a virtual machine by issuing the ATTACH command.
The virtual machine for hardware support should have the minimum configuration
required to run online tests, and provide access to CMS 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 used.
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 eMS allowing editing and printing of all VM/SP
recorded machine check and channel check errors. This directory entry is included
in the VM/SP directory provided with the starter system.
Software Support
The virtual machine for software support should have sufficient system resources
allocated to recreate problems (virtually) that occur on the real machine, and to
perform software service activities. ECMODE ON must be specified for this
machine.
Chapter 18. Creating Your VM/SP Directory
149
Sample Directory Entries
The following sample VM/SP directory entries provide you with some of the virtual machines necessary for system operation and updating. The indentations are for
readability and are not required by the directory program. LINK control statements are used whenever possible to reduce the number of changes to the VM/SP
directory whenever a minidisk extent is moved. A brief explanation of some of the
virtual machine userids follows.
A Hanlware Service Virtual Machine (EREP)
The following directory entry defines the virtual machine (EREP) 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 VM / SP OLSTEP and E"or Recording Guide.
USER EREP IBMCE 768K 2M FG
ACCOUNT EREP IBMCE
IPL CMS
CONSOLE 01F 3215
SPOOL OOC 2540 READER A
SPOOL OOD 2540 PUNCH B
SPOOL OOE 1403 A
LINK MAINT 190 190 RR
LINK MAINT 19D 19D RR
LINK MAINT 201 192 RR
MDISK 191 3380 099 001 VMSRES WR READ WRITE
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 in the DMKSYS file. 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/SP, the operator's virtual machine needs only class A
command privileges. The MDISK control statement defines the 191 minidisk,
which contains CMS files, EXEC procedures, and service programs to update
VM/SP.
USER OPERATOR OPERATOR 3M 16M ABCDEG
ACCOUNT 2 OPERATOR
CONSOLE 009 3215 T MAINT
SPOOL OOC 2540 READER *
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
LINK MAINT 190 190 RR
LINK MAINT 19D 19D RR
LINK MAINT 19E 19E RR
MDISK 191 3380 040 001 VMSRES MR ROPER WOPER MOPER
150
VM/SP Planning Guide and Reference
A Yirtual Machine to Receive System Dumps (OPERATNS)
The userid for the following directory entry is the userid specified on the
SYSDUMP operand of the SYSOPR macro when the VM/SP system was generated. All abnormal termination dumps are sent to this virtual machine. This user
normally is given command privilege classes B, C, E, and G. If the directory entry
contains all disks normally attached to the system, described as full-volume minidisks, you can rewrite the VM/SP directory, using the DIRECT command. The
operations group can examine any disk while it is attached to the system, when
these disks are defined as full-volume minidisks.
USER OPERATNS IPCS 512K 1M BCEG
ACCOUNT 1 SYSPROG
IPL CMS
CONSOLE 009 3215
SPOOL DOC 2540 READER D
SPOOL ODD 2540 PUNCH A
SPOOL ODE 1403 A
LINK MAINT 190 190 RR
LINK MAINT 19D 19D RR
LINK MAINT 19E 19E RR
MDISK 191 3380 212 001 VMSRES MR RIPCS WIPCS MIPCS
MDISK 193 3380 213 008 VMSRES MR RIPCS WIPCS MIPCS
Other System Virtual Machines
In addition to virtual machines discussed to this point, there are virtual machines
that:
•
Support and update the VM/SP system
•
Test new releases of the system before placing them into production
•
Provide other users with a remote file spooling capability.
Chapter 18. Creating Your VM/SP Directory
151
A. Virtual Machine for Updating and Supporting YM/SP (MAINT)
The following directory entry defines a virtual machine (MAINT) that can support
and update the VM/SP system. The MAINT virtual machine's command privilege
classes include class E and class G, so it can issue the SAVESYS command to save
CMS, CMSL, and other systems.
USER MAINT CPCMS 3M 16M ABCDEFG
ACCOUNT 1 SYSPROG
OPTION ECMODE REALTIMER
IPL 190
CONSOLE 009 3215
SPOOL OOC 2540 READER *
SPOOL OOD 2540 PUNCH A
SPOOL OOE 1403 A
MDISK 123 3380 000 885 VMSRES MW
MDISK 125 3380 000 885 VMPK01 MW
MDISK 126 3380 000 885 VMSTGE MW
MDISK 190 3380 052 045 VMSRES MW
MDISK 191 3380 011 008 VMSRES MW
MDISK 194 3380 019 021 VMSRES MW
MDISK 201 3380 832 021 VMSRES MW
MDISK 293 3380 853 011 VMSRES MW
MDISK 294 3380 864 011 VMSRES MW
MDISK 393 3380 001 068 VMSTGE WR
MDISK 394 3380 809 076 VMSTGE WR
MDISK 19E 3380 127 045 VMSRES MW
MDISK 319 3380 100 027 VMSRES MW
MDISK 19D 3380 221 027 VMSRES MW
RSYSRES WSYSRES
RSYSRES WSYSRES
RSYSRES WSYSRES
ALL
WMAINT
RMAINT WMAINT
RMAINT WMAINT
RMAINT WMAINT
RCMSAUX WCMSAUX
RCPAUX WCPAUX
READ WRITE
READ WRITE
ALL
WMAINT
ALL
WMAINT
ALL
WMAINT
MSYSRES
MSYSRES
MSYSRES
MMAINT
MMAINT
MMAINT
MMAINT
MCMSAUX
MCPAUX
MMAINT
MMAINT
MMAINT
Following is a summary of MAINT's minidisk usage:
Disk
Usage
123
125
126
190
Provides full pack read/write access to volume VMSRES.
Provides full pack read/write access to volume VMPKO 1.
Provides full pack read/write access to volume VMSTGE.
CMS system disk (S-disk). Contains the CMS nuclei (CMS and
optionally, CMSL) and the CMS modules and EXEC procedures available to CMS users. Any virtual machine that wants to use CMS links to
this disk.
Work area. This is MAINT's A-disk.
CP TEXT retention.
EREP TXTLffis.
CMS PTFs and updates.
CP PTFs and updates.
CMS source files.
CP source files.
Y-disk extension of the 190 S-disk.
Optional Program Products.
HELP files.
191
194
201
293
294
393
394
19E
319
19D
152
VM/SP Planning Guide and Reference
The DirectorytProgram
You can run the VM/SP directory program under CMS (using the DIRECT command) or stand-alone. The stand-alone 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/SP directory in the
VOLllabel. If the active system directory is the directory being updated, it is
placed in use at this time. You can print the new directory by issuing the CMS
command PRINT USER DIRECT (or PRINT filename DIRECT).
The virtual machine running 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/SP system residence volume, your virtual machine's current
directory entry must have write access to the volume containing the current
VM/SP directory.
Example: Assume that you have the following virtual machine for online directory
modification.
USER DIRMAINT DIRM 1M 2M BG
ACCOUNT 4 SYSADMIN
OPTION REALTIMER
IPL CMS
CONSOLE 009 3215
SPOOL C 2540 READER *
SPOOL D 2540 PUNCH A
SPOOL E 1403 A
SPECIAL OFF TIMER
LINK MAINT 190 190 RR
LINK MAINT 19E 19E RR
MDISK 191 3380 200 003 VMSRES
MDISK 193 3380 086 009 VMSEXT
MDISK 195 3380 203 009 VMSRES
MDISK 123 3380 000 885 VMSRES
MR RDIRM WDIRM MDIRM
MR RDIRM WDIRM MDIRM
MR RDIRM WDIRM MDIRM
MW
Using XEDIT you can create or modify a card-image file of the VM/SP 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 formats this file into the form of a directory, and replaces the old directory
with this new one.
Chapter 18. Creating Your VM/SP Directory
153
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 eMS
The VM/SP Directory program records the configuration of each user's virtual
machine in the VM/SP directory. Each virtual machine configuration includes
counterparts of the components found in a real machine: a virtual operator's console, virtual storage, and virtual I/O de,jces 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 with XEDIT to include additional
directory entries.
The CMS DIRECT Command
Use the CMS DIRECT command to process a directory file to see if it follows the
required format. To actually change or swap the currently active VM/SP
directory, you must have write access to the system-owned (system residence or
IPL device) volume that contains tbe 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 qualification and wish to 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.
154
VM!SP Planning Guide and Reference
To build a VM/SP 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/SP
directory each time it is created. If you run the directory program under VM/SP,
the newly created directory is dynamically swapped, and placed in use by VM/SP
(provided that the directory you update is currently in use by the system, or the
target directory pack is present in the system owned list). The format of the
DIRECT command is:
DIRECT
[~~~~name [~i~~gpe [fil~mOde ]]]
[(EDIT)
1
where:
filename [filetype [filemode]]
is the identification of the file containing control statements for the
Directory program. If no filename and filetype are specified, the program defaults to a file named USER DIRECT; otherwise, it looks for
the file named. If only filename is specified, filetype defaults to
DIRECT. The filemode defaults to * if not specified.
(EDIT)
specifies that the directory is to be examined, but not changed.
Under CMS, the DIRECT command loads the directory creation module. The first
statement encountered must be a DIRECTORY statement. (If not found, the program stops.) 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 ends, the old directory is not altered. Normal
completion places the directory in use by VM/SP. After the new directory is created, it can be printed by issuing the CMS command PRINT USER DIRECT or
PRINT filename DIRECT.
Chapter 18. Creating Your VM/SP Directory
155
Invoking Directory as a Stand-alone Program
Stand-alone Directory program operation in a virtual machine is the same as CMS
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. The directory control statements must be in the same virtual reader file as
the directory program itself.
I
When running as a stand-alone program, DMKDIR searches for a console at
address 009 or 01 F. If there is no operational console at one of these addresses,
the program enters a wait state until an interrupt occurs to identify the address of
the console. If any non-console device is physically connected to address 009 or
01F, it must be detached or results are unpredictable.
Directory Control Statements
Control statements should be in the formats illustrated in the following pages, with
one or more blanks as operand delimiters. All operands are positional from left to
right. If any operand is omitted, remaining 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 verify all control
statements before ending. If the directory runs out of space, the program stops
immediately. After an abnormal ending, the old directory is not altered, and the
new directory is not saved.
156
VM/SP Planning Guide and Reference
DIRECTORY Control Statement
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:
DIRectory
cuu
devtype
volser
[alt-cuu]
where:
cuu
is the address of the device to contain the directory and is specified in
three hexadecimal digits.
devtype
represents a supported device type suitable for the VM/SP directory
(2314,2319,2305,3330,3340,3350,3375,3380, or FB-512). 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.
Note: 3330V (virtual 3330) volumes associated with 3850 Mass Storage System cannot be specified as the residence device for the VM/SP
directory.
volser
is the volume serial number of the directory volume (one to
six-alphameric characters).
al t-cuu
identifies an alternate device address for writing the directory if the
primary cuu is not available. For multiprocessing systems, an alt-cuu
specification allows native execution of the directory program on
either processor.
Chapter 18. Creating Your VM/SP Directory
157
USER Control Statement
The USER control statement defines a virtual machine and creates a VM/SP directory entry. It identifies the directory entry for one user. A separate USER statement must be prepared for each directory entry required. The format of the USER
control statement is:
User userid pass [stor [mstor [cl [pri [le [ld [Cd [es ] ] ] ] ] ] ] ]
ON· ON
ON
ON
OFF OFF OFF OFF
where:
userid
is a one to eight-character user identification. Any alphameric characters may be used except SYSTEM. SYSTEM is the userid of the
VM/SP system VMBLOK, and should never be used for a virtual
machine.
If you plan to use any of the following CMS commands, the userid
must contain those characters valid for CMS filenames.
FILELIST
RDRLIST
NAMEFIND
RECEIVE
NAMES
SENDFILE
NOTE
TELL
These commands create and reference files that have the userid as the
filename. Valid characters for CMS filenames are A-Z, 0-9, $, #, @,
+, - (hyphen), : (colon), and _ (underscore).
There must be at least one CONSOLE or SPOOL directory entry for
each user. These options are discussed in the directory program control statement descriptions.
Notes:
1. The userid should not contain the characters "LOGONxxx,"
where xxx is one of your terminal addresses. During logon this
character string is assigned to the terminal at address xxx from the
time the initial interrupt is received until the user is identified.
2. The userid should not contain the same characters as the
"LUNAME" defined in VTAM. The "LUNAME," although
unique to each VTAM service machine, may not be unique to
VM/SP if more than one VTAM service machine is running under
VM/SP.
3. Do not specify ALL as a userid. It is reserved for VM/SP.
4. If the userid of AUTOLOGI (a reserved system user identification) is used, during the VM/SP IPL operation, the AUTOLOGI
virtual machine is automatically logged onto the system.
158
VM/SP Planning Guide and Reference
In application, the AUTOLOGI 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, initiates
the logon of other virtual machines to the system.
5. If the userid is 1-4 all numeric characters, unpredictable responses
may occur for commands using both the userid and a 1-4 digit
numeric spoolid as parameters (such as the class D query command).
pas s
is a one to eight-character user-security password that must be entered
by the user to gain access to the VM/ SP system and the virtual
machine you are defining in these control statements.
Note: Use the reserved password NOLOG for users who do not have
a virtual machine configuration in the VM/SP directory. The NOLOG user uses the real card reader spool device as a means of entry for
processing by the CMS batch facility. NOLOG is used for spooling
purposes only. Attempts to logon using this password are not allowed.
Specifying NOLOG provides additional security for your VM/SP
installation.
star
is one to eight-decimal digits that define the virtual machine's storage
size. It must be a multiple of 4K. The last character must be K or M.
The default is 128K. The minimum size is 8K. All entries not on a 4K
boundary are rounded up to the next 4K boundary. The maximum
size is 16M.
mstar
is one to eight-decimal digits that define the maximum virtual machine
storage size that this user can define after logging on the system. It
must be coded in multiples of 4K. The last digit must be K or M. The
default size is 1M. All entries not on a 4K boundary are rounded to
the next 4K boundary. The minimum size is 8K. The maximum size
that can be specified is 16M.
cl
is one to eight-alphabetic characters from A to H (with no intervening
blanks) defining the privilege class(es) of this user. The default is G.
Note: 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 desired.
pri
is a number from 1 to 99 used by the CP priority dispatcher. One is
the highest priority; 64 is the default.
Note: The same priority value can be used for several users. Also, if
the specification for this statement is not entered, line end (Ie), line
delete (Id), character delete (cd), and escape (es) characters default to
system-defined values.
Chapter 18. Creating Your VM/SP Directory
159
The special VM/SP logical editing symbols below may be set ON, OFF, or substituted with two hexadecimal characters or one graphic character of your choice.
Note: In addition to directory specification, you can change these logical editing
symbols usin.g the TERMINAL command. The default value for all symbols is ON.
The exception to this rule is a virtual machine started by the CP AUTOLOG command. In this case all logical line editing is OFF.
160
Ie
is a one-character "line end" symbol or a two-character hexadecimal
representation of the symbol. ON sets the system default value (#).
OFF disallows "line end" symbol 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.
VM/SP' Planning Guide and Reference
ACCOUNT Control Statement
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. 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:
Account
number
[distribution]
where:
number
is a one to eight-character account number 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 omitted.
Chapter 18. Creating Your VM/SP Directory
161
OPTION Control Statement
The OPTION control statement selects specific options. This statement is optional
and, if used, must follow the USER statement or another OPTION statement. It
must precede the first device statement (CONSOLE, MDISK, DEDICATE, LINK,
or SPOOL). Multiple OPTION statements can be inserted if the options selected
exceed one statement record length. The format of the OPTION control statement
is:
Option
[Real timer]
[Ecmode]
[Isam]
[Virt=real]
[Acet]
[Svcoff]
[BMXl
[epUID bbbbbb]
[AFFinity nn]
[VMsave]
[STFirst]
[370E]
[Maxconn nnnnn]
[MIH]
where:
REALTIMER
provides a timer for the virtual machine that is updated during virtual processor run time and 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 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 extended control mode (such as
VM/SP itself).
2. Use the dynamic address translation facility (such as OS/VS1,
OS/VS2, DOS/VS,DOS/VSE, VSE/ AF, VM/370, and
VM/SP).
3. Use control registers other than zero (such as OS GTF (General Trace Facility), which uses Monitor Call and requires control register eight).
4. Depend on the System/370 extended channel masking
feature.
The ECMODE option must also be specified for the virtual
machine that is to perform system support or updating. ECMODE
is also required when using the clock comparator.
Note: A virtual machine defined without the ECMODE option in
the directory is limited to six I/O channels, while a virtual machine
with the ECMODE option may address up to 16 I/O channels. If
a virtual machine with ECMODE runs 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 ECMODE
option runs in extended control mode, the I/O masking for all 16
162
VM/SP Planning Guide and Reference
channels is handled via extended control register 2. This facility
can also be obtained by issuing the CP command SET ECMODE
ON.
ISAM
provides special channel command word translation routines that
permit OS/PCP, MFT, and MVT ISAM programs (that dynamically modify their CCWs) to operate properly in a virtual
machine. This is required only for virtual machines that use
OS/PCP, MFT, or MVT ISAM access methods or OS/VS ISAM
when running either in a V =R partition or in non-paging mode
under OS/VS. This option is not needed for DOS, DOS/VS,
DOS/VSE, VSE/ AF, 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.
VIRT=REAL
is a performance option that allows you to place your virtual
machine in lower storage, such that its virtual storage addresses
correspond to real storage addresses (except page zero, which is
relocated). Real page zero is controlled by the CP nucleus. No
CCW 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/SP 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 anyone time. A named or
shared system cannot be loaded (via IPL) in a virtual=real area.
The device address must be specified in the IPL command. To
generate a VM/SP system with a virtual=real machine, see
"Specifying a Virtual=Real Machine" in Chapter 10.
ACCT
users with the ACCT option in their directory can track another's
use of virtual machine resources. For example, a user who sends a
job to the CMS batch virtual machine can be charged for time
used in the batch machine. Note that the ACCT option should be
specified in the directory of the CMSBATCH virtual machine so
user/job identifying information is printed on the forms separators
of spooled output files.
SVCOFF
specifies that CP, instead of the virtual machine assist feature or
the VM/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.
Note: All SVC 76 interrupts are handled by CP whether or not
the SVCOFF option is specified.
BMX
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 SIO 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.
Chapter 18. Creating Your VM/SP Directory
163
The channel mode setting for all channels except virtual channel
zero can be changed by the CP DEFINE CHANNEL command.
CPUID bbbbbb
provides a processor identification (CPUID) to be stored in
response to the STIDP instruction. It is necessary to associate a
different CPUID with each virtual machine attached to an MSC
port. This is because solicited/unsolicited messages are directed to
the host system in the virtual environment using the CPUlD.
There is no checking by VM/SP to ensure that all virtual machines
using the SET CPUID command have specified different processor
serials. The hexadecimal field 'bbbbbb' is the processor identification number. The processor identification number (serial) is only
a portion of the complete CPUlD. The CPUID identification
stored in response to a STIDP instruction is a string of 16
hexadecimal digits shown as follows:
aabbbbbbccccdddd
where:
aa
is the version code. These two digits are forced to
X'FF' to identify that the virtual machine is running
under VM/SP.
bbbbbb
is up to six hexadecimal digits that indicate the processor
identification number. This field is set by the directory
OPTION statement values or modified by the SET
CPUlD command.
cccc
is the model number. This field contains a high order 0
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.
If the CPUlD is not specified by the SET CPUlD command or the
OPTION control statement, the CPUlD stored as a result of the
STIDP instruction is the real CPUlD. The first two digits are set
to X'FF' and the last four digits are set to X'OOOO' (present
CPUlD logic). A processor serial of more than six digits on the
SET CPUlD command results in an error message.
A processor identification number (serial) of fewer than six
hexadecimal digits results in zeros to the left of the number. A
three-byte field in the VMBLOK (VMCPUlD) contains the value
set as a result of invoking this DIRECTORY option.
AFFINITY nn is two decimal digits between 00 and 63, specifying that virtual
machine execution is to be performed on a designated processor
(nn). This attribute is useful only in the VM/SP attached
processor and multiprocessor environments. Any hexadecimal
value from 00 to 3F is a valid main (IPL) or attached (non-IPL)
164
VM/SP' Planning Guide and Reference
processor address. However, the value selected must match the
preset values established for your IPL and non-IPL processors
when the system was installed. If the AFFINITY option is not
selected, the virtual machine is serviced by the first available
processor from the VM/SP dispatch queue. An affinity setting in
the VM/SP directory can be overridden by the CP SET AFFINITY command. If the system is running in attached processor or
multiprocessor mode and an error forces recovery to uniprocessor
mode, the affinity setting of virtual machines assigned to the
non-IPL processor is cancelled. Virtual machine processing may
continue on the IPL processor.
VMSAVE
specifies that the virtual machine contents are to be saved if
VM/SP is terminated or if VM/SP terminates the indicated virtual
machine. The contents of the registers and real storage of the virtual machine are saved on DASD space and made available to
userid(s) specified by the NAMESYS macro instruction.
Notes:
1. This option is effective only if you have exactly one VMSAVB
DASD area defined. The option is enabled only if that area
does not contain a VMSAVB system. If more than one area is
defined, or if a valid system is already stored in that area, the
SET VMSAVB command must be used.
2.
STFIRST
To cancel the VMSAVE specification use the SET VMSAVB
OFF command.
specifies that the indicated virtual machine is authorized to use the
SET STBYPASS command when virtual machine assist is active on
the system for a virtual=virtual user.
Note: This is a restricted performance option that should be
reserved only for virtual machine userids used to run production
MVS, SVS, OS/VS1, or DOS/VS operating systems.
370E
specifies that the MVS/System Extensions support be enabled for
the indicated virtual machine. See the table under "Using the Performance Options" in Chapter 10, for a list of VM/SP processors
that support this option.
MAXCONN nnnnn
is the maximum number of Inter-User Communications Vehicle
(IUCV) connections allowed for this virtual machine. If the
MAX CONN option is omitted, the default is 4. The maximum is
65,535.
Note: The MAX CONN option is applicable only to virtual
machines. For CP system code, a limit of 4,096 paths is established when the CP system is initiated.
MIH
specifies that Missing Interrupt Handler support be enabled for the
indicated virtual machine. When a missing interrupt is detected,
an interrupt will be simulated by CP.
Chapter 18. Creating Your VM/SP Directory
165
IUCV Control Statement
The IUCV control statement defines an authorization for establishment of a communication path with another virtual machirie or a CP system service. A virtual
machine can initiate communications with itself without directory authorization.
The ability to initiate a CONNECT to a CP system service always requires specific
authorization. CP system service communications must be restricted to service
type virtual machines.
The format of the IUCV control statement is:
IUCV
userid
*CCS
[ ALLOW
ANY
]
[PRIORITY]
[MSGLIMIT limit]
where:
userid
is the one to eight-character user identification of the virtual machine
or CP system service with which this virtual machine is authorized to
establish a communication path.
*CCS
is the CP system service name required for VCNA.
ALLOW
is a general authorization indicating that any other virtual machine
may establish a communications path with this virtual machine. No
further authorization is required in the virtual machine initiating the
communication.
ANY
is a general authorization indicating that a communications path can
be established between this virtual machine and a:ny other virtual
machine. ANY does not apply to CP system service names.
"
PRIORITY indicates that a communicatio~path with the specified virtual
machine or CP system service is capable of handling priority as well as
nonpriority communications if J'equested via the CONNECT function.
If the PRIORITY option is omitted) no path authorized by this entry is
able to handle priority messages.
MSGLIMIT limit
defines the maximum number of outstanding messages allowed on any
path authorized by this entry. A lower limit can be specified via the
CONNECT and ACCEPT functions. If omitted, the message limit is
taken from the CONNECT or ACCEPT parameter list. Limits specified by CONNECT and ACCEPT can be different. If omitted from
the parameter list, a default of lOis used. The maximum allowed value for message limit is 255.
166
VM/SP Planning Guide and Reference
Notes:
1. PRIORITY and MSGLIMIT are keywords and can be specified in any order.
2.
When the CONNECT function is invoked, the directory entries are searched in
a definite order:
•
The invoker's IUCV control statements are searched for an entry for the
target's userid, and then
•
If the target is not a CP system service, the invoker's IUCV control statements are searched for an ANY entry.
•
The target's IUCV control statements are searched for the ALLOW entry.
The first entry found that is applicable is used to establish the priority status
and message limit for the path.
3.
Connections invoked from CP system code do not need directory
authorization. Priority status and message limit are taken from the CONNECT
parameter list.
4.
The IUCV control statement can be used as many times as needed for any user
to define authorizations needed for that virtual machine.
5.
Communications with Console Communication Services (CCS) for VCNA
require an IUCV control statement with *CCS as the userid.
6.
Communication with the CP Message System Service does not require authorization by the virtual machine. If an IUCV control statement is specified, a
userid of *MSG should be used. Although the PRIORITY and MSGLIMIT
options may be specified on the control statement, the specifications will never
be used since the virtual machine will only be receiving messages.
Chapter 18. Creating Your VM/SP Directory
167
IPL Control Statement
The IPL control statement contains the name of the system to be loaded for the
user when they log on. This statement is optional. If specified, it must follow the
USER statement, and must precede the first device statement (CONSOLE,
MDISK, or SPOOL). This control statement may contain data to be passed to the
system being loaded. The IPL statement can be overridden by the user at logon
time by specifying "LOGON userid NOIPL."
Note: If the user is the primary system operator, an automatic IPL is performed at
logon time.
The format of the IPL statement is:
Ipl
iplsys [PARM data]
where:
iplsys
is a one to eight-character system name or the one to three-digit 1/0
virtual address of the device containing the system to be loaded.
PARM data passes up to 48 bytes of data after the keyword, P ARM, excluding all
leading and trailing blank characters, but including all embedded
blanks, to your virtual machine's general purpose registers (4 bytes
per register), starting with the high order byte of general register O.
Usage
168
VM/SP, Planning Guide and Reference
Although the VM/SP IPL command allows up to 64 characters on
the PARM option, the directory restricts each statement to a single
card image, limiting the number of characters that can be entered on
the IPL Control Statement in the directory. The 'parmdata' on the
IPL Control Statement is loaded into general registers 0-12 and is
passed to the application specified by 'iplsys'.
SCREEN Control Statement
The SCREEN control statement is used to define the color and extended-highlight
options for the user terminal. The SCREEN control statement is optional. If used,
it must follow the USER control statement and precede the first device statement
(CONSOLE, MDISK, DEDICATE, LINK, or SPOOL). The format of the
SCREEN control statement is:
SCREen
area
{color [hilight]} {hilight [color ]} ....
NONe
DEFault
where:
area
specifies data to be highlighted or defined in color. Area may be:
ALL entire screen. If this operand is specified, none of the following
may be used:
INArea
input area.
STArea
status area.
OUTarea
output areas. If this operand is specified, none of
the following may be used:
CPOut
CP output.
VMOut
virtual machine output.
INRedisp
input redisplay.
color
hilight
NONe
hilight
color
DEFault
indicates color and extended-highlight attributes for the specified area.
Valid colors are:
BLUe
RED
PINk
GREen
TURquois
YELlow
WHite
blue
red
pink
green
turquoise
yellow
white
Chapter 18. Creating Your VM/SP Directory
169
values for hilight are:
NONe
BLInk
REVvideo
UNDerlin
none
blink
reverse video
underline
One color and/or one extended-highlight attribute must be entered for each area
specified. The extended-highlight and color attributes are not positional. If both
are specified, either may be first.
Multiple SCREEN control statements are allowed. If you use multiple statements,
they must be in a group with no other types of control statements between them.
Usage Notes:
1. A default value of NONE is applied for any unspecified extended-highlight
attribute. DEFAULT is used for any unspecified color attribute. The
DEFAULT color is monochrome (green and white).
2. If the ALL operand is used, it must be the first operand specified on the first
SCREEN control statement for the user.
3. If the OUTAREA operand is used, CPOUT, VMOUT, or INREDISP may.not
be specified.
4.
No SCREEN control statement operands may appear more than once within a
user's directory entry.
Example:
The SCREEN control statement:
SCREEN OUTAREA' RED NONE INAREA GREEN BLINK STATAREA PINK UNDERLIN
results in the following assignments:
170
Area
Color
Highlight
CPOUT
VMOUT
INREDISP
INAREA
STATAREA
red
red
red
green
pink
none
none
none
blink
underline
VM/SP Planning Guide and Reference
CONSOLE Control Statement
The CONSOLE control statement specifies the virtual console. The format of the
CONSOLE control statement is:
Console
cuu
devtype [class]
[userid]
where:
cuu
is the virtual device address of one to three hexadecimal digits.
devtype
is the device type:
1052
3210
3215
3270
A 3270 specification forces TERMINAL CONMODE 3270 but is
otherwise identical to a 3215 specification. Similar to the TERMINAL CONMODE 3270 specification, the devtype 3270 specification
applies only to local non-SNA display devices that have a 3270 compatible command set. These devices are:
•
•
•
•
•
•
•
Model 138 console
Model 148 console
Model 158 console
3277 (Model 2)
3278 (Models 2, 3, 4, 5 2A, 2C, and 3C)
3279 (Models 2A, 2B, 2C, 3A, and 3B)
3036.
Only one console may be specified. If a different console is sometimes
required, use the CP DEFINE command to change the console
address or add an alternate console.
For a 1052, 3210, 3215, or 3270 specification the system accepts any
real console or terminal. 3270 is not supported for disconnected
users; full screen channel programs will be command rejected when a
user is disconnected.
class
is a one-character spooling class. A through Z and 0 through 9 may
be specified. The class governs printing of real spooled output. If the
class operand is omitted, the default for console spooling is class T.
userid
is the one to eight-character secondary userid whose console is to be
used when the user disconnects.
If userid is specified, the class operand must also be specified.
For more information about defining consoles, see VM/ SP Operating Systems in a
Virtual Machine.
Chapter 18. Creating Your VM/SP Directory
171
MDISK Control Statement
The MDISK control statement describes the cylinder extent to be owned by the
user on a direct access device. The DASD area assigned with this statement
becomes the user's minidisk. During logon, the owner of the minidisk obtains a
link to it in the access mode specified on the MDISK control statement.
I
Warning: Neither CP nor the directory checks that minidisks def"med with the
MDISK statement do not overlap each other, and (for 3330,3340,3350,3375, and
3380 disks) that they do not overlap the "alternate track" cylinders at the end of the
real disk. If overlap occurs, fHe damage is inevitable.
The format of the MDISK control statement is:
Mdisk cuu devtype ~CYlr
T-DISK
.
blkr
cyls volser [mode [pr [pw [pm]]]]
cyls
blks
~
where:
cuu
is the virtual device address of 1 to 3 hexadecimal digits.
devtype
is the device type:
2305
2311 Top
(Top half of a 2314 or 2319)
2311 Bottom (Bottom half of a 2314 or 2319)
2314
2319
3330
3340
3350
3375
3380
FB-512
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 .
{ blkr
172
VM/SP Planning Guide and Reference
is a three-digit decimal cylinder relocation factor that specifies the cylinder on a real disk that 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 they log on. It
is a part of their virtual configuration until they log off or detach the
disk. The data area is then returned for reallocation for another
T-DISK area. To maintain security, this area should be erased before
it is returned. blkr specifies the relocation factor in blocks for
FB-512.
Note: It is not advisable to start a minidisk at real cylinder zero (unless the minidisk is to be used by OS ISAM, 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 they and the VM/SP system use to
identify the disk. CP-owned volumes must not have minidisks beginning at real cylinder zero.
cyls
is a one to three-digit decimal number specifying the number of cylinders.
blks
is a one to six-digit decimal number specifying the number of FB-512
blocks.
Maximum Minidisk Sizes (cylinders or blocks)
Device
Type
2314/2319
3310
3330
3330
3333
3333
3340
3340
3350
33,70
3375
3380
Model(s)
lor 2
11
1
11
35
70
native mode
CMS/VSAM
CMS 800-byte
Format
CMS 512, lK, 2K,
or 4K Format
200 cyls.
126,016 blocks
404 cyls.
808 cyls.
404 cyls.
808 cyls.
348 cyls.
696 cyls.
555 cyls.
558,000 blocks
959 cyls.
885 cyls.
203 cyls.
not supported
246 cyls.
246 cyls.
246 cyls.
246 cyls.
348 cyls.
682 cyls.
115 cyls.
not supported
182 cyls.
121 cyls.
203 cyls.
126,016 blocks
404 cyls.
808 cyls.
404 cyls.
808 cyls.
348 cyls.
696 cyls.
555 cyls.
558,000 blocks
959 cyls.
885 cyls.
Note: The number of cylinders indicated for the 3344 is for each of
the four logical 3340-70 devices.
If the device is a 2314 or 2319 and it is to be formatted by IBCDASDI
or Device Support Facilities for 3375/3380, the minimum minidisk
size is two cylinders. 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.
Chapter 18. Creating Your VM/SP Directory
173
volser
is the volume serial number of the DASD volume (one- to
six-alphameric characters).
mode
is the access mode that consists of up to two letters. The first letter
specifies the primary access mode (read-only, write or multiple). The
optional second letter indicates the alternate access mode (read-only
or write access) desired if the primary access is·not available. An
optional 'V' character, when appended to the mode request on an
MDISK statement, specifies virtual RESERVE/RELEASE
processing. Valid modes are:
Mode Meaning
R
Primary read-only access. The read-only link is established as
long as no other user has the disk in write status. If there is an
existing write link to the disk no link is given. R is the default
mode if the link is to another userid.
RR
Primary read-only access or alternate read-only access. The
read-only access is established even if another user has the
disk in write status. The alternate access of R assures that the
user will get the read link no matter what links currently exist
to the disk.
W
Primary write access. The write link is established only if there
are no other current links to the disk. If another user has the
disk in read or write status no link is given.
WR
Primary write access or alternate read-only access. If write
access is available then the link is established. Otherwise, the
alternate access of a read-only link is given.
M
Primary multiple access. A write link is established unless
another user already has write access to the disk, in which case
no link is given.
MR
Primary multiple access or alternate read access. A write link
is established unless another user already has write access to
the disk, in which case a read link is given since it was the
alternate access requested.
Note: Unpredictable results can occur when one user has a
read-only (R or RR) link to a device that is being updated by a
user who has the device in write status (W or WR).
MW
Primary multiple access or alternate write access. A write link
is established in all cases.
CAUTION
CMS does not protect a user from loss of data on a disk when
multiple users have write access to the disk. More than one user
writing to the same virtual device can result in a permanent loss
of data. Users should not be linking with MW mode to obtain
the M or MR function. (The M or MR access modes will allow
only one write link to a disk.)
174
VM/SP Planning Guide and Reference
If a 'V' is appended to the immediate right of the primary access mode
specification (or the alternate access mode specification, if any), then
CP's virtual RESERVE/RELEASE support will be used in the I/O
operations for the specified device. Thus, if the mode specified for a
minidisk is MWV, the minidisk will function with write linkage using
CP's virtual RESERVE/RELEASE function.
If a mode specification is omitted from the MDISK statement, it
defaults to W.
pr
is the password that allows other users to share the device in read-only
mode (a one to eight-character field).
pw
is the password that allows another user to access the device in write
mode (a one to eight-character field).
pm
is the password that allows other users to gain multiple access to the
device (a one to eight-character field).
Notes:
1.
A write password (pw) cannot be specified without a read password (pr). A
multiple password (pm) cannot be specified without both a read password (pr)
and a write password (pw).
2.
If ALL is used for pr, pw, or pm, any user is allowed to link with the corresponding access mode to this minidisk without specifying a password.
3.
When MSS support is used, the volume serial number may specify an MSS
3330V volume. In this case, the volume serial number must be six characters.
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, VM/SP
attempts 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 a minidisk reserved by another virtual machine.
6.
Protecting minidisks by specifying passwords on the MDISK statement provides additional security for your VM/SP installation.
Chapter 18. Creating Your VM/SP Directory
175
Examples:
MDISK 230 3380 5 10 WORK01 W ALL WRITE
is an MDISK statement for a minidisk with read/write access to 10 cylinders
located on a real 3380 disk volume labeled WORKOl, 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.
MDISK 191 3380 50 15 CPDSK4 W RDPASS WRX2*
is an MDISK statement for a minidisk with read/write access to 15 cylinders
located on a real 3380 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.
MDISK 190 FB-512 75100 15748 FBACMS WR READ WRITE
is an MDISK statement for a minidisk with write access to 15748 FB-512
blocks on the real device labeled FBACMS. If the minidisk is already accessed
by another user, read-only access is provided. The minidisk begins at relative
block 75100 on FBACMS.
176
VM/SP. Planning Guide and Reference
SPOOL Control Statement
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 statement is:
Spool cuu devtype [class]
[ww 11 ] [2WCGM] [CFS] foATCK
4WCGM
~TS
]
tNODATCK
where:
cuu
is the virtual device address (one to three-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 following unit record addresses must be used:
PRINTER ODE
PUNCH 000
READER DOC
devtype
is the device type:
1403
2501
1443
3203
3211
2540 R[EADER]
2540 P[UNCH]
3262
3289
3525
3505
3800
4245
class
is a one-character spooling class. The characters A through Z, 0
through 9, and * can be used. 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.
For example:
SPOOL ODE 1403 A
specifies a SPOOL record for a virtual 1403 at address OOE. The output class is A.
Chapter 18. Creating Your VM/SP Directory
177
specifies the physical characteristics of the paper to be loaded into the
3800 printer. (ww) indicates the hexadecimal width code of the
paper. See Figure 16 for 'width codes. (11) indicates the decimal
length of the paper. Specify (11) as a decimal number using
half-inches. If (ww 11) is not specified, 14-7/8 x 11 inches is
assumed.
[ww 11]
2WCGM
[ 4WCGM
]
specifies the number of writable character generation modules
(WCGM) assumed for the virtual 3800 printer. A WCGM is a
64-position portion of the 3800's character generation storage that
holds the scan elements of one character set. A 3800 can have either
two or four WCGMs. If 2WCGM is specified, the virtual 3800 printer
is assumed to have two WCGMs. If 4WCGM is specified, four
WCGMs are assumed. If neither is specified, 4WCGM is the default.
DATCK ]
[ NODATCK
specifies processing of certain virtual 3800 data checks. If DATCK is
specified, all data checks are reflected to the virtual machine (provided
the 'BLOCK DATA CHECK' CCW has not been issued). If
NODATCK is specified, only data checks that occur due to invalid
translate table specifications or unmatched FCB codes are reflected to
the virtual machine. This is the default condition.
Note: DATCK should be used only when necessary as it severely
increases the overhead associated with simulation of WRITE and SKIP
CCW's to the virtual 3800. In general, the reflection of data checks
due to overprinting and invalid EBCDIC codes is not necessary.
[~:~
]
designates the stacker assumed for the virtual 3800 printer. You may
specify either CFS (Continuous Form Stacker) or BTS (Burster
Trimmer Stacker). If neither is specified, CFS is assumed.
Note: All parameters of the SPOOL control statement are positional.
They must be specified in the order shown.
178
VM/SP Planning Guide and Reference
X'OI'
X'02'
X'03'
X'04'
X'05'
X'06'
X'07'
X'08'
X'09'
X'OA'
X'OB'
X'OC'
X'OD'
X'OE'
X'OF'
6-1/2 in.
Reserved
Reserved
8-1/2 in.
Reserved
9-1/2 in.
9-7/8 in.
10-5/8 in.
11 in.
12 in.
Reserved
Reserved
13-5/8 in.
14-3/10 in.
14-7/8 in.
(165 nun ISO)
(180 nun ISO)
(215 nun ISO)
(235 mni ISO)
(250 nun ISO)
(270 nun ISO)
(280 nun ISO)
(305 nun ISO)
(322 nun ISO)
(340 nun ISO)
(363 nun ISO)
(378 nun ISO)
Figure 16. AvaUable Form Width Codes
When defining devices, make sure the devices are defined (and separated) within
their own control unit range, and not shared with other devices.
Chapter 18. Creatinl Your VM/SP Directory
179
DEDICATE Control St¥ement
The DEDICATE control statement specifies that a real device is to be dedicated to
this user. MSS 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 VM/SP. A real device may be dedicated to only one user at a time.
Should a device be specified as dedicated 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:
DEDicate
where:
NETwork
is the keyword used if a remote 3270 Information Display System
Printer (3284, 3286, 3287, 3288, or 3289) is to be automatically
attached to a virtual machine at logon time. If this keyword is omitted,
a local device is assumed.
cuu
is the one to three character virtual device address.
resource is the four character resource id of a remote device as specified in
DMKRIO. This operand must be specified if the NETwork keyword
is specified, and is only valid if NET is specified.
rdev
is the one to three character real device address.
VaLID
is the keyword that must be used if the volser is less than four characters long and rdev is not specified. It is optional when rdev is specified
or volser is a length of four or more characters. In cases when rdev is
not specified, the CP system will find an available rdev.
If the VOLID operand is used, the volume must be attached to the
system when the user logs on. When the user logs off, the operator
can then detach the volume from the system.
180
volser
is the volume serial number of a disk pack mounted on some real disk
storage device, or of an MSS volume to be dedicated to the virtual
machine. The volser can be from one to six alphameric characters
long.
3330V
specifies that all interruptions, including cylinder faults and attentions
received on the rdev are to be passed to the virtual machine in its cuu.
RIO
specifies that the virtual device is to be in read-only status. If this
operand is omitted, the status defaults to read/write.
VM/SP Planning Guide and Reference
Notes:
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 to 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. Some devices use a shared subchannel protocol
and others do not. (Subchannel protocols for all devices supported by VM/SP
are listed in Appendix B under the table heading "Shared Subchannel.")
Devices should be grouped by control unit within a given channel according to
their subchannel usage. Grouping devices that use the shared subchannel protocol together with devices that do not use the shared protocol can result in
errors if all of the devices are using the same control unit. While the DEDICATE statement controls real devices, this restriction applies equally to real
and virtual devices. The following is an example of a virtual machine's DEDICATE statements that can cause operational conflict.
DEDICATE 10E 30E (30E 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 (YCUBLOK) in CPo 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 YCUBLOK. Thus, the subsequent processing of a channel 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
YCUBLOK). Therefore, when defining devices, make sure the devices are
defined (and separated) within their own control unit range and not shared
with other devices.
Since there is no control unit on the real hardware for a system console it
should be noted that this restriction applies to any system console such as the
3138, 3148, and 3158.
Examples:
DEDICATE OB8 OBO
is a DEDICATE statement for a device at real address OBO. Its virtual
address is OB8.
DEDICATE 250 MY PACK
is a DEDICATE statement that defines, for this virtual machine, virtual
address 250 as the real device where DASD volume MYPACK is mounted.
This restriction also applies to SPOOL statements and combinations of DEDICATE and SPOOL statements.
Chapter 18. Creating Your VM/SP Directory
181
Remote 3270 Information Display System Printers can also be attached by the
NETWORK ATTACH command. For more details see the Operator's Guide.
3.
When the real device is a 3330V, the action VM/SP 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:
OED 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/SP, transparent to the virtual machine.
OED cuu rdev 3330V
The real device must again be a VIRTUAL 3330V. All cylinder faults and
unsolicited interrupts received by VM/SP on the rdev will be passed to the
virtual machine.
OED cuu VOLID 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 MSS 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.
OED cuu rdev volser
The difference between this example and the previous one is that in this
case the real device address is preselected and must have the VIRTUAL
feature. This format allows you 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.
DED cuu rdev volser 3330V
This format is the same as the previous one, except that the virtual device
becomes a 3330V, such that VM/SP does not intercept any cylinder fault
interrupts or the associated attention interrupts.
182
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 MSS support. (See" Appendix D. VM/SP
Restrictions. ")
5.
When dedicating a real CTC, the CTC should be on a separate real channel
from all other virtual devices because of a possible lock-out problem.
VM/SP Planning Guide and Reference
LINK Control Statement
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 for one of the virtual machines with an MDISK statement.
•
Define a link to that volume, with the LINK statement for all other virtual
machines that use the volume.
Later, if you must move or change that volume, you need only update the one
MDISK statement; the LINK statements need not be updated.
The LINK control statement and the MDISK control statement have the same
authority level (neither has higher priority than the other). The format of the
LINK control statement is:
Link
userid
vaddr1
[vaddr2 [mode]]
where:
userid
is the one to eight-character user identification of the user to be
linked-to.
vaddr1
is the virtual device address of the device to be linked-to, which is
owned by "userid." This virtual device address consists of three
hexadecimal digits.
vaddr2
is the virtual device address that the device is to be linked-as for the
virtual machine being defined. If not specified, "vaddr2" defaults to
the same address as the linked-to device (three hexadecimal digits). If
your virtual machine has the ECMODE option, any address up to
X'FFF' is valid; otherwise, any address up to X'SFF' is valid.
mode
is the access mode that consists of up to two letters. The first letter
specifies the primary access mode (read-only, write or multiple). The
optional second letter indicates the alternate access mode (read-only
or write access) desired if the primary access is not available. Valid
modes are:
Mode Meaning
R
Primary read-only access. The read-only link is established as
long as no other user has the disk in write status. If there is an
existing write link to the disk no link is given. R is the default
mode if the link is to another userid.
RR
Primary read-only access or alternate read-only access. The
read-only access is established even if another user has the
disk in write status. The alternate access of R assures that the
user will get the read link no matter what links currently exist
to the disk.
Chapter 18. Creating Your VM/SP Directory
183
W
Primary write access. The write link is established only if there
are no other current links to the disk. If another user has the
disk in read or write status no link is given.
WR
Primary write access or alternate read-only access. If write
access is available then the link is established. Otherwise, the
alternate access of a read-only link is given.
M
Primary multiple access. A write link is established unless
another user already has write access to the disk, in which case
no link is given.
MR
Primary multiple access or alternate read access. A write link
is established unless another user already has write access to
the disk, in which case a read link is given since it was the
alternate access requested.
Note: Unpredictable results can occur when one user has a
read-only (R or RR) link to a device that is being updated by a
user who has the device in write status (W or WR).
MW
Primary multiple access or alternate write access. A write link
is established in all cases.
CAUTION
CMS supports multiple accessed read-only disks in full. CMS
does not support write access to disks by multiple users. CMS
does not protect a user from loss of data on a disk when multiple
users have write access to the disk. More than one user writing
to the same virtual device can result in a permanent loss of data.
CMS disks should never have more than one existing write link at
a time.
A disk accessed in write mode by one CMS user is available to
other CMS users, but flles on the disk that are altered by the
write-mode user cannot be read by the other users.
Note: If the mode is not specified, the default is R.
184
VM/SP Planning Guide and Reference
It is the responsibility of the operating system running in each virtual machine to
keep data from being destroyed or altered on shared disks.
If userA owns a virtual device that was obtained via a directory MDISK statement:
MDISK 100 3380 5 10 VMDISK W READ WRITE
Then userB may have a directory LINK control statement to obtain this device at
logon time:
LINK userA 100 200 RR
Any number of users may have directory LINK control statements to either userA's
or userB's device. However, if userC has a directory LINK to userB's device (that
was obtained by a LINK to userA's device):
LINK userB 200 300 RR
then no user can obtain a LINK (either through a directory LINK control statement or the LINK command) to this device through userC because no more than 2
levels of indirect directory links are permitted.
Chapter 18. Creating Your VM/SP Directory
185
SPECIAL Control Statement
The SPECIAL control statement specifies the 110 units available to the user that
need not have a real 110 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:
SPEcial
cuu
devtype
[IBM TELE]
where:
cuu
is a one to three-character virtual device address.
devtype. is the device type:
2701
2702
2703
3088
3138 (virtual 3138 console)
3148 (virtual 3148 console)
3158 (virtual 3158 console)
3270 (virtual 3270 only)
CTCA (channel-to-channel adapter)
TIMER (pseudo-timer device)
IBM TELE valid only if devtype is 2701, 2702, or 2703
For example, a virtual machine running 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 this multiple-access system rather than logging on as a separate virtual machine.
Note: The Integrated Communications Attachment (ICA) on System/370 Models
135, 135-3, or 138 should be specified as a 2701.
186
VM/SP: Planning Guide and Reference
Directory Entries for eMS/DOS
The VSE system and private libraries are accessed in read-only mode under
eMS/DOS. If more than one eMS virtual machine is using eMS/DOS, you
should update the VM/SP directory entries so the VSE system residence volume
and the VSE private libraries are shared by all eMS/DOS users.
The VM/SP directory entry for one eMS virtual machine should contain MDISK
statements defining VSE volumes. VM/SP directory entries for other eMS/DOS
users should contain LINK statements.
For example, assume the VSE system libraries are on cylinders 0-149 of a 3330
volume labeled DOSRES. Also, assume the VSE/ AF private libraries are on cylinders 0-99 of a 3330 volume labeled DOSPRI. Then one eMS machine (for example, DOSUSERl) would have the MDISK statements in its directory entry.
USER DOSUSER1 password 1M 2M G
MDISK 331 3330 0 150 DOSRES R rpass
MDISK 231 3330 0 100 DOSPRI R rpass
All other eMS/DOS users would have links to these disks. For example:
LINK DOSUSER1 331 331 R rpass
LINK DOSUSER1 231 231 R rpass
For more information about directory entries for eMS/DOS virtual machines, see
VM / SP Operating Systems in a Virtual Machine.
Note: Refer to the VM / SP Installation Guide for a list of the sample directories
supplied with the Product Tape.
Chapter 18. Creating Your VM/SP Directory
187
188
VM/SP ·Planning Guide and Reference
Chapter 19. 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 processor. VM/SP 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 accurately.
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 you have so devices can be added in
the future without performing another system generation. Bear in mind, however,
that the control blocks generated (RDEVBLOK, RCUBLOK, and RCHBLOK)
occupy space in real storage.
For the 3081 Processor Complex, in addition to preparing the real I/O configuration file, you must prepare the input/output configuration program source file and
run the Input/Output Configuration Program to define the I/O configuration to
the processor. See "Coding Considerations for the Input/Output Configuration
Program Source File" later in this chapter, for more information.
When preparing the RDEVICE and RCTLUNIT entries, refer to "Appendix B.
Configuration 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.
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
189
The macros, in their proper sequence, are:
Units Referred To
Macro Name
CLUSTER {
j
TERMINAL
RDEVICE
RCTLUNIT
RCHANNEL
RIOGEN
Remote Display Stations
~
I/O Devices
Control Units
Channels
System Console
The file should be created in the order shown:
DMKRIO CSECT
CLUSTER macro
TERMINAL macro
RDEVICE macros
RCTLUNIT macros
RCHANNEL macros
RIOGEN macro
END
Note: There 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 come before all other real I/O
configuration macros. See special requirements for TERMINAL macros for
devices attached to the 3274 ModellC under "Coding the Real I/O Configuration
Macros for Remote 3270s."
All 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.
190
VM/SP Planning Guide and Reference
Coding the Real 110 Configuration Macros for Remote 3270s
Two types of remote 3270 configurations are supported: a cluster control unit with
multiple terminals and printers attached and stand-alone display stations. The clustered configurations attach to either a 3271, 3274 ModellC, or 3276 control unit.
The stand-alone station is a 3275 display station that 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, TERMINAL, 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 3270 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 ModellC, 3275, or
3276) for the remote 3270 configuration. Each CLUSTER macro must have a different label. This label is coded on the RDEVICE macro that defines the corresponding binary synchronous line and 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 3274 Modell C that has only 3278s, 3279s (attached via Terminal Adapter
Types AI, 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 ModellC has
3277s, 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 3278s, 3279s, 3287s (attached via Terminal Adapter Types
AI, 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,3287 (attached via Terminal Adapter Types Bl, 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 3275, 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.
After all CLUSTER-TERMINAL groups of macros have been coded, code the
other real I/O configuration macros. You must code an RDEVICE macro for each
binary synchronous line that supports remote 3270 stations. Specify the.label of
the corresponding CLUSTER macro on the RDEVICE macro (CLUSTER=label).
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
191
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 3271,3274 Model1C,
or 3276) on a leased BSC line, or a stand-alone 3275 on either a switched or leased
BSC line. One CLUSTER macro must be specified for each 3271,3274 Model
1C, 3275, and 3276.
Note: Each CLUSTER macro must immediately precede the TERMINAL macros
defining the devices attached at each remote 3270 station. The groups of CLUSTER and TERMINAL macros must come before all other macros in the DMKRIO
file.
The format of the CLUSTER macro is:
Name
label
Operation
CLUSTER
Operands
CUTYPE={ 3271 }
3274
3275
3276
,GPOLL=cudv
,LINE=cuu
,DIAL= ~YES~
,NO
where:
label
is a name of the CLUSTER macro. It must be specified. The label may be
any assembler language symbol. The label establishes a special symbolic
name for this cluster control unit or stand-alone station.
CUTYPE=1
~ ~ ~:
3275
3276
l
is the station control unit. It is either 3271, 3274 Model1C, 3275, or 3276.
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
ready to send data over the line is allowed to do so. The characters, cudv,
are the 4-digit hexadecimal general polling characters assigned to the station
control unit. The hexadecimal equivalent of the EBCDIC transmission code
is in the form cudv, where:
cu are the polling characters for the control unit
dv are the characters for any available input device
The general polling characters for a remote 3270 device (dv) are always
X'7F' and the general polling characters for the control unit are defined
when the control unit is installed. Use Figure 17 on page 198 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.
192
VM/SP Planning Guide and Reference
Note: The 3274 and 3276 terminal control unit address switches are set by
you to match 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 associated with this CLUSTER macro.
DIAL={~~
}
specifies whether the 3275 has the Dial feature. DIAL-NO must be specified if CUTYPE-3271.
Examples:
The following CLUSTER macro describes a 3271 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 I/O configuration file (DMKRIO), the CLUSTER macro must immediately come before TERMINAL macros that. define stations attached to that cluster or stand-alone station.
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
193
TERMINAL Macro
Use the TERMINAL macro to define:
•
a display station or printer that is attached to the remote 3270 display system
or
•
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 stand-alone 3275 display
station.
Code one TERMINAL macro for each display device and each 5K printer attached
to a cluster control unit (3271, 3274 ModellC, 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 TERMINAL macro for an
unused terminal address, specify a valid TERM= operand and the correct selection
or addressing characters. All a~ card P2.Si!i9n must be present in t!1e control
unit for any terminal address generated, whether a ieniiinal is physically attachea
'Or not. Failure to meef this requirement will result in timeouts with remote device
type 3274 and 3276 control units.
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, code a TERMINAL macro for all 3278s, 3279s, 3287s, and 3289s in groups of 8 until all
3278s, 3279s, 3287s, and 3289s have been included. You must code a TERMINAL macro for every terminal address in each group of 8. Following these macros,
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 stand-alone station (3275). Since a 3276 is a cluster controller and not a stand-alone, code each 3276 with a TERMINAL macro. 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.
194
VM/SP Planning Guide and Reference
The format of the TERMINAL macro is:
Name
label
Operation
TERMINAL
Operands
TERMJ3275\
3276
3277
3278
3279
l3284
3286
3287
3288
.3289
,SELECT=cudv
[,MODEL=1
,MODEL=2 ]
,MODEL=3
,MODEL=4
,MODEL=5
[, FEATURE=OPRDR]
Note: All TERMINAL macros defining devices attached to a remote 3270 station
must follow the CLUSTER macro that defines the control unit for that station.
Groups of CLUSTER and TERMINAL macros must come before all other macros
in the DMKRIO file.
where:
TERM=f
1
~~~~
3277
3278
3279
l
~~::J
3287
3288
3289
is the deVIce type of the remote 3270 station attached to the clustered or
stand-alone 3270 control unit. If TERM= 3276, 3278, or 3279, MODEL=
must be specified.
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
195
tSELECT=cudv
are the 4-digit hexadecimal selection or addressing characters assigned to this
device, where:
cu
dv
are the characters for the control unit
are the characters for the device
Use Figure 17 on page 198 to determine the selection and addressing characters for this device. The SELECT operand is ignored if DIAL = YES is specified for the 3275 in the CLUSTER macro.
Note: If a printer is attached to the 3275, it has the same address as the
3275 display station.
MODEL=1]
MODEL=2
MODEL=3
[ MODEL=4
MODEL=5
is the model number of the terminal or printer. The default is model 2.
Note: If TERM= 3276, 3278, or 3279, MODEL= must be specified, and
should be equal to the actual model of the real device. If the model specification doesn't match the real device, unpredictable results may occur.
The following is a list of terminals and their model numbers:
3275
3276
3277
3278
3279
3284
3286
3287
3288
3289
Model 2
Model 2, 3, or 4
Model 2
ModeI2,3,4,or5
Model 2 or 3
Model 2 or 3
Model 2 or 3
Modell or 2
Model 2
Modell or 2
Note: If TERM= 3276, 3278, or 3279, the model number 2, 3, 4, or 5
must be specified.
196
VM/SP. Planning Guide and Reference
The following printers can be attached to a 3271 cluster control unit:
•
•
•
•
mM 3284 Printer Model 2
mM 3286 Printer Model 2
mM 3287 Printer Models 1 and 2
IBM 3288 Printer Model 2
The following printers can be attached to a remote 3274 Model1C cluster
control unit:
•
•
•
•
mM 3284 Printer Model 2
IBM 3286 Printer Model 2
mM 3287 Printer Models 1 and 2
IBM 3288 Printer Model 2
IBM 3289 Printer Models 1 and 2
The following printers can be attached to a 3276 cluster control unit:
•
•
IBM 3287 Printer Models 1 and 2
IBM 3289 Printer Models 1 and 2
The following printers can be attached to a stand-alone 3275 station:
•
IBM 3284 Printer Model 3
IBM 3286 Printer Model 3 (via RPQ MB4317)
FEATURE=OPRDR
specifies the optional operator identification card reader feature, available
on the 3277 Display Station, Model 2, or the magnetic slot reader on a
3276, 3278 Display Station, Models 2, 2A, 3,4, and 5, or 3279 Color Display Station, Models 2A, 2B, 3A, and 3B.
Examples
Example 1: This TERMINAL macro describes a 3277 with a selection address of 2,
and a control unit address of 2.
TERMINAL TERM=3277,SELECT=E2C2,FEATURE=OPRDR
Example 2: This TERMINAL macro describes a 3286 with a selection address of 3
and a control unit address of 3.
TERMINAL TERM=3286,SELECT=E3C3
Example 3: This TERMINAL macro describes a 3284 with a selection address of 4
and a control unit address of 4.
TERMINAL TERM=3284,SELECT=E4C4,MODEL=2
Example 4: This TERMINAL macro describes a 3275 Display Station with a 3284
Printer, Model 3, attached and a control unit address of O.
TERMINAL TERM=3275,SELECT=6040,MODEL=3
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
197
If no printer is attached to the 3275, code:
TERMINAL
TERM=3275,S~LECT=6040
Use this column for:
Device selection
• Specific
poll
• General poll
• Fixed return addresses
•
Use this column for:
3270 control unit selection
• addresses
If the Control
Unit or Device
Humber is:
If the Control
Unit Humber 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
The EBCDIC
Code (in
hexadecimal)
is:
40
Cl
C2
C3
C4
C5
C6
C7
C8
C9
4A
4B
4C
4D
4E
4F
50
Dl
D2
D3
D4
D5
D6
D7
D8
D9
SA
5B
5C
5D
5E
5F
Figure 17. Remote 3270 Control Unit and Delice Addressing
198
VM/SP Planning Guide and Reference
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
The EBCDIC
Code (in
hexadecimal)
is:
60
61
E2
E3
E4
E5
E6
E7
E8
E9
6A
6B
6C
6D
6E
6F
FO
Fl
F2
F3
F4
F5
F6
F7
F8
F9
7A
7B
7C
7D
7E
7F
3271, 3274, and 3276 Addressing
General Poll
for Control
Unit 5
Specific
Poll Device
4 on Control
Unit 5
Select
Device 4
on Control
Unit 5
Control
Unit
Address
EBCDIC
C5
C5
Device
Address
7F
7F
Control
Unit
Address
C5
C5
Device
Address
C4
C4
Control
Unit
Address
E5
E5
Device
Address
C4
C4
3275 Addressing
General Poll
for Control
Unit 5
Specific
Poll
for Control
Unit 5
Select
Control
Unit 5
Control
Unit
Address
EBCDIC
C5
C5
Device
Address
7F
7F
Control
Unit
Address
C5
C5
Device
Address
40
40
Control
Unit
Address
E5
E5
Device
Address
40
40
FJgUI'e 18. Examples of Remote 3270 Addressing
Figure 18 shows some examples of valid polling characters.
Chapter 19. Preparing the Real I/O Configulation File (DMKRIO)
199
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 included
on the real VM/SP system is 4096.
I
I
RDEVICE macro instructions describe each device, or group of devices, attached
to your processor. These can be in any order (except when used in conjunction
with the CLUSTER macro10). They must be contiguous and must come before all
RCTLUNIT and RCHANNEL macros in the real I/O configuration file
(DMKRIO). Also, RDEVICE macro instructions must follow all groups of
CLUSTER and TERMINAL macros, if any. The first RDEVICE macro generates
the label DMKRIODV, which indicates the start of real device blocks to CPo
The name field may not be specified for the RDEVICE macro instruction. If a
name is specified it is ignored. The RDEVICE macro 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 "Special
Considerations for Coding the 3704/3705 RDEVICE Macro" in this chapter, for
additional information and special considerations.
The RDEVICE macro statement is not used for SNA supported terminals.
'0
1
200
VM/SP Planning Guide and Reference
See "Chapter 12. Planning for 3270s" before you code an RDEVICE macro for a binary synchronous line used by remote 3270s.
The format of the RDEVICE macro is:
Name
label
Operation
RDEVICE
Operands
ADDREss=lcuu
t,DEVTYPE=type[,MODEL=model]
1(cuu,nn)~
[,FEATURE=(feature[,feature] ... )]
!'-
/
,-
,CLASS=~6~~6'Cl] ... »)
~
JTAPE
<,TERM
GRAF
JURI
~ URO
,>
,
,
-
J
BSCA )
!'-
-
IBM1 ,
SDLC
,ADAPTER= \
~
....
TELE2~
TYPE11
TYPE2~
TYPE3 ,
TYPE4}
-
[,ALTCU=CUU
]
[,SETADDR=sadnum]
[ , CPNAME=cpname ]
[ ,BASEADD=cuu]
[, CLUSTER=label]
[,IMAGE=imagelib]
[ , CHARS=ffff]
[ , FCB=lpi]
[ , DPMSIZE=n]
where:
ADDRESS={CUU
}
(cuu,nn)
is the real 110 device address (or addresses).
cuu is three-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.
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 addresses 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 character 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. This is because only one system display console can be specified for each RDEVICE macro.
When using more than one 3705, you must generate each unit independently so that each has the controller attribute. Otherwise, VM/SP considers
the 3705s to be 270x lines and, therefore, not usable by guest virtual
machines.
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
201
DEVTYPE=type
is the type of device.
The device type can be CTCA, HFGD, ICA, 1017, 1018,
1052,1053, 1403, 1443,2150,2250,2260,2265,2301,2303,2305,
2311,2314,2319,2321,2401,2402,2403,2404,2415,2420,2495,
2501, 2520P, 2520R, 2540P, 2540R, 2671,2701, 2702, 2703,2955,
3036,3066,3088,3138,3148,3158,3203,3210,3211,3215,3230,
3262,3268,3277,3278,3279,3284,3286,3287,3288,3289,3330,
3333,3340,3350,3375,3380,3410,3411,3420,3430,3505,3525,
3704,3705,3800,3851,4245,4250,7443, 8809,orFB-512.
Coding Considerations
Additional information relating to the support of HFGD (High Function
Graphic "Device) devices can be found in the Graphics Access
Method/System Product General Information Manual, GC33-0125. For
TWX terminals, 3101 display terminals, or 3232 keyboard 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, 2702, 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. Specify a 3250 device as a
2250. An MSS 3330V device address must be defined as
DEVTYPE=3330 with one of the two FEATURE= operands allowed.
Refer to the explanation of the FEATURE operand that follows.
For 3287 printers attached via a 3272 Control Unit Model 2, specify
DEVTYPE= 3284 or 3286.
For a 3289 Model 4 to be attached to a 4331 Display Printer Adapter as a
system printer, specify DEVTYPE= 3289E. Note that while a DEVTYPE
specification of 3289 and a MODEL specification of 4 is allowable, the
result will be the generation of a graphic device rather than a system
printer.
Since a CTCA may tie up a channel, it is recommended that you generate
only one per channel. If other devices are to be attached to the same channel as a CTCA, they should be non-critical devices such as readers or printers.
202
VM/SP Planning Guide and Reference
The system console must be specified in both the RDEVICE and
RCTLUNIT macros. Specify the system console in both macros as follows:
Processor
System Console
135, 135-3, 145,
145-3, 155 II
3210 or 3215
138
3138 (if in display mode)
3215 (if in printer-keyboard mode)
148
3148 (if in display mode)
3215 (if in printer-keyboard mode)
158
3158 (if in display mode)
3215 (if in printer-keyboard mode and has the
3213 Printer Modell)
165 II, 168
3066
3031, 3032, 3033, 3033-N,
3033-S,3042
3036
4331,4341
3278 Model 2A (if in display mode)
3215 (if in printer-keyboard mode)
3081
3278 Model 2A (if in display mode)
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
203
Addresses OFO through OFF are reserved for the attachment of the support
processor subsystem devices, for the SIGM and SIGP instructions that are
used by the instruction processing function and support processor to communicate with each other, and as spare addresses OFO to OFF, which have
the following assignments:
•
•
•
•
•
•
OF2 - 3278 Model 2A primary console
OF3 - 3278 Model2A additional console or 3287 Printer
OF4 - 3278 Model2A additional console or 3287 Printer
OF5 - 3278 Model 2A additional console or 3287 Printer
OF6 - SIGM instruction
OF7 - SIGP instruction
OFO, OFl, OF8 through OFF - spares
Device types 2540R and 2540P refer to the same IBM 2540 Card Read
Punch (as do 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 processor 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 any error
recordings. CP does not use unsupported devices for its own operations.
If a device specified in the RDEVICE macro is not supported by VM/SP,
the following MNOTE message (warning level) is generated:
UNSUPPORTED DEVICE TYPE
The device is generated as an unsupported device. An unsupported device
can be used only 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/SP
directory for the virtual machine, or if it is attached to it by the CP
ATTACH command.
Notes:
1. If you code a 2702 device type the SETADDR value must be specified.
2. If you code a 3278 or 3279 device type the MODEL= operand must
be specified.
204
VM/SP Planning Guide and Reference
MODEL=model
is the model number for a particular device.
Model number, if not specified, defaults to zero except for the 3203, which
defaults to 4. It must be coded for 2305, 3330, and 3333 DASD, 3278,
and 3279 display devices, and 3203, 3289, and 3262 printers. If a model
number is not coded for 3704 or 3705 devices, or the 3262 printer, an
MNOTE is generated.
Model is a value that can be:
Value
Device
lor 2
4 or 5
1 or 11
1,2, or 11
1 or 11
A1-H8
1, 2, 3, 4, 5, or 6
5 or 7
1,2, or 3
3,4,5,6, 7, or 8
1
2,3,4, or 5
2A
2C
2 or 3
4
2305
3203
3262
3330
3333
3704, 3705-1, or 3705-11
2415
2420
3410 or 3411
3420
3272 or 3274, Model 1B
3278
3278 consoles for 4300 processors
3279 consoles for 4300 processors
3279
3289
Notes:
11.
For a 3704/3705 outside the Al - H8 model range, specify MODEL=H8.
The 3277 Modell is a 480-character display screen and is supported by
VM/SP only as a dedicated device.
3. If a model number is included for devices that do not require model numbers,
system generation is ended with an error message.
4. If DEVTYPE=3278 or 3279, MODEL= must be specified.
5. Specify 3278 Model 2A for 4300s equipped with 3279 Model 2C consoles.
2.
FEATURE=(feature [, feature] ... )
are the device's optional features. Features can be written in any order.
They are:
Feature
7-TRACK
CONY
DUALDENS
OPRDR
Explanation
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 or
3279
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
205
Feature
SYSVIRT
TRANS
UNVCHSET
VIRTUAL
2CHANSW
4CHANSW
4WCGMS
FH
Explanation
A 3330V (DEVTYPE=3330) device that may
be used by VM/SP 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
3350 Fixed-head Feature (3340 optional)
Note: For a 3330V device, either FEATURE=VIRTUAL or
FEATURE=SYSVIRT must be specified.
Coding Considerations
To allow CMS to correctly verify tape mode set operations, the correct feature code for a tape device must be specified.
Note: The dual density selected by the DUALDENS feature is dependent
on the tape device and model specified in the DEVTYPE and MODEL
operands.
If the local 3277, 3278, or 3279 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 by inserting a magnetically encoded card.
Use the FEATURE=OPRDR operand of the RDEVICE macro to specify
that this is a display device with a card reader. FEATURE=OPRDR is
invalid if DEVTYPE=3158.
Notes:
1. The 7-TRACK, CONY, DUALDENS, and TRANS features are not
allowed for the 8809.
2. The 7-TRACK, CONY, and TRANS features are not allowed for the
3430.
Although allowable, it is not necessary to designate
FEATURE = (2CHANSW/ 4CHANSW) on the RDEVICE macro.
DMKCPI dynamically determines if the hardware has a two- or
four-channel switch feature.
FEATURE = FH is valid only for a 3350 DASD device or a 3330 in emulation mode. For all other DASD devices that may have the FH feature
installed, it is either provided by the device type (e.g. 2305) or determined
at ]PL or VARY ONLINE time.
206
VM/SP Planning Guide and Reference
Specifying FEATURE=(2CHANSW/4CHANSW) on the RDEVICE macro to indicate hardware support of reserve/release CCWs is unnecessary.
DMKCPI determines this by issuing a release CCW to the tape or
count-key-data DASD volumes. For FB-512 devices, the RDFEAT bit in
the appropriate FB-512 RDCBLOK is checked. If the hardware supports
the two- or four-channel switch feature, the FTRRSRL bit is turned on in
the RDEVFTR field. FEATURE = (2CHANSW / 4CHANSW) on the
RDEVICE macro is allowed, but when specified, causes the following
MNOTE to be issued:
2CHANSW} FEATURE IGNORED
{ 4CHANSW
(cl[,cl] ... )
DASD
TAPE
TERM
GRAF
URI
URO
is the device class. It is either the output spooling class or a special subclass
for unsupported devices.
Output Spooling Classes
The spooling classes (cl,cl. .. ) list up to four output spooling classes separated by commas. This form of the CLASS operand can be specified only
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.
CLASS is used by the CP START command and may be changed by this
command. For a complete description of the START command, and for
more information about spooling classes, see the VM/ SP Operator's Guide.
Subclass for Unsupported Devices
Specify a device subclass for unsupported device types only. 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 DEVTYPE operand does not appear in the list of valid
device types.
Subclasses are:
DASD
TAPE
TERM
GRAF
URI
URO
Direct Access Storage Devices
Tape devices
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.
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
207
For example, a 1287 Optical Reader is an unsupported device for VM/SP.
It does not appear in the list of VM/SP supported devices 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:
RDEVICE ADDRESS=010,DEVTYPE=1287,CLASS=URI
defines a 1287 Optical Reader at address 010. The 1287 belongs to the
unit record input (URI) subclass.
Notes:
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 stopping CCW translation (by issuing SET
NOTRANS ON). A maximum of 32 sense bytes can be in the
RDEVBLOK created for an unsupported device.
2. The CLASS operand is invalid if you are specifying service record file
devices.
ADAPTER=
~~~~
SDLC
't'ELE2
I
~~::~j
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. It is
ignored if specified for any other device type.
BSCA specifies an IBM Binary Synchronous Terminal Adapter Type II for
a 2701, or an IBM Binary Synchronous Terminal Control Type II for a
2703, 3704, or 3705. BSCA must be specified for remote 3270 terminals
and printers.
IBM 1 specifies that an IBM Terminal Adapter Type I attaches a 1050 or
2741 to a 2701, or that an IBM Terminal Control Type 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 operates 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:
•
•
•
208
VM/SP .Planning Guide and Reference
A Telegraph Terminal Adapter Type II in a 2701
A Telegraph Terminal Control Type II in a 2702 Qr 2703
A Line Interface Base Type I in a 3704 or 3705
TYPEI specifies the channel adapter accessed by a 3704. For
DEVTYPE-3705, TYPE 1 or TYPE4 may be coded. In identifying the
channel adapter, TYPEI or TYPE4 must be specified for the Emulation
Program (EP). In identifying the line adapter, mMl, TELE2, or BSCA
can be specified only in relation to another RDEVICE macro containing
ADAPTER-TYPEI or TYPE4.
SETADDR=sadnum
is the set address (SAD) command 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
V_ue
Commumd
o
SADZERO
SADONE
SADTWO
SADTHREE
(no SAD command is issued)
1
2
3
4
CPTYPE={ EP }
NCP
PEP
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.
NCP specifies the Network Control Program.
PEP specifies the Partitioned Emulation Program.
ALTCU=cuu
specifies an alternate control unit address to be used if paths through the
primary control unit are unavailable. cuu is a three-digit hexadecimal
address. Only one ALTCU can be specified.
The ALTCU cuu must specify an address with a low order of 0 or 8. Otherwise, the following MNOTE is issued:
INVALID ALTCU ADDRESS
The ALTCU operand is valid only for tape and DASD volumes. An
MNOTE is issued if an invalid device type is specified.
"ALTCU" IS INVALID FOR DEVICE TYPE "devtype"
The ALTCU operand should be specified only when you have the String
Switch feature to support two control unit paths to a device.
In an MP system, the alternate control unit address may be the same as the
primary control unit address. If there are two physical control units with
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
209
the same address, they cannot be a~tached to both processors at the same
time. In order to attach a primary control unit and an alternate control unit
to both processors of an MP system, you must specify different control unit
addresses.
The ALTCU cuu address should specify the low address associated with the
alternate real control unit. When the FEATURE = xxx-DEVICE operand
indicates that the control unit supports more than sixteen devices and the
devices on the second or following group of sixteen devices are defined by
separate RDEVICE macros, the ALTCU cuu should identify the logical
RCUBLOK in VM/SP. VM/SP constructs one RCUBLOK for each set of
sixteen devices supported by the real control unit.
Assuming 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
RCTLUNIT 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
RCTLUNIT ADDRESS=400,FEATURE=32-DEVICE
RCHANNEL ADDRESS=3
RCHANNEL ADDRESS=4
CPNAME=ncpnarne
is the one to eight-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.
Note: Failure to code the CPNAME operand on the RDEVICE macro for
the 3704/3705 base address causes VM/SP to mark the device "not operational" at IPL time. The cluster on that 3704/3705 is therefore unusable.
BASEADD=cuu
is the native address (load address) of the 3704/3705 that controls the
physicalline(s). This operand is required for correct operation of VM/SP
recovery management for emulation lines based on a 3704/3705. This
operand is valid only if ADAPTER=IBMI (or =TELE2 or =BSCA). It
must be specified in order to use the 370x EP Line Trace Facility.
CLUSTER=label
is the label of the CLUSTER macro that defines the clustered or
stand-alone remote control unit attached to this line. This operand is valid
only if ADAPTER=BSCA is specified.
lMAGE=irnagelib
is the image library to be used by the 3800 printer device after a cold start
if none is specified on the START command. If this operand is omitted, the
default is IMAG3800.
210
VM/SP Planning Guide and Reference
CHARS=ffff
is one-to-four 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 GFI0.
DPMSIZE=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 omitted, the default 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 operand is omitted, the default is 6.
Examples:
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)
RDEV1CE ADDRESS=(OCO,4),DEVTYPE=2401
RDEV1CE ADDRESS=(030,8),DEVTYPE=2702,ADAPTER=TELE2,
SETADDR=2
X
X
Special Considerations/or Coding the 3704/3705 RDEVICE Macro
The 3704/3705 Communications Controllers have varied uses. Consequently,
there are special considerations for coding the RDEVICE macro.
IBM 3704 Communications
Controller
Model
--x-;A2
A3
A4
Storage
16K
32K
48K
64K
IBM 3705 Communications Controller
3705-1
3705-11
Model
A1, B~, D1
A2, B2, C2, D2
B3, C3, D3
B4, C4, D4
C5, D5
C6, D6
D7
D8
Storage
16K
48K
80K
112K
144K
176K
208K
240K
E1,
E2,
E3,
E4,
E5,
E6,
E7,
E8,
32K
64K
96K
128K
160K
192K
224K
256K
F1,
F2,
F3,
F4,
F5,
F6,
F7,
F8,
G1,
G2,
G3,
G4,
G5,
G6,
G7,
G8,
H1
H2
H3
H4
H5
H6
H7
H8
Figure 19. mM 3704/3705 Models
I
Note: Specify any 3704/3705 outside the range of models listed in Figure'19 as
MODEL=H8.
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
211
EP-Only Control Programs: If the 3704/3705 is to be run in emulation mode:
•
Use the (cuu,nn) form of the ADDRESS operand to generate multiple
RDEVBLOKs.
•
Specify 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 IBMl, TELE2, or BSCA, as appropriate.
For ADAPTER=IBMI (or TELE2), the SETADDR operand must also be specified, exactly as if the device were a 2702 or 2703.
Note: If you use the (cuu,nn) form of the ADDRESS operand to generate multiple
RDEVBLOKs and specify the CPNAME and ADAPTER=TYPEI operands on
the RDEVICE macro, the additional RDEVBLOKs are generated as
ADAPTER=IBMI and SETADDR=4.
Other 3704/3705 RDEVICE Considerations: For each physical 3704/3705 there
should be only one RDEVICE macro that specifies the ADAPTER=TYPEl,
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 RDEVICE macro
that specifies the ADAPTER=TYPEl, TYPE2, TYPE3, or TYPE4, MODEL, and
CPTYPE operands. There must never be a second use of the CPNAME operand.
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.
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 file all RCTLUNIT macros required to specify real addresses that
the EP control program may use.
If you have a 3704/3705 and a 2701/2702/2703 on the same VM/SP system, the
virtual addresses for the 3704/3705 must not be the same as any of the real
2701/2702/2703 addresses.
Examples:
Examples of RDEVICE macro specifications follow.
Example 1
RDEVICE ADDRESS=(020,16),
DEVTYPE=3704,
MODEL=A2,
ADAPTER=TYPE1,
CPNAME=VMEP01
x
X
X
X
This describes a 32K 3704 at address X'020', with 15 emulator lines addressed
X'021' to X'02F' and with the default parameter of ADAPTER=IBMI and
SETADDR=4. The 3704 is to be loaded with the Emulation Program 'VMEPOl'.
212
VM/SP Planning Guide and Reference
Example la
RDEVICE ADDRESS={030,16),
DEVTYPE=3704,
ADAPTER=IBM1,
SETADDR=2,
BASEADD=020
x
X
X
X
This describes an additional 16 emulator lines on the same 3704 specified by
Example 1.
3704/3705 E"or Messages: The RDEVICE macro instruction generates an entry
in a table of programmable communications controllers when DEVTYPE=3704 or
3705 is specified. This table has a maximum of 10 entries. The following message
results if more than ten 3704 or 3705 devices are specified:
MORE THAN 10 TP CONCENTRATORS
This message indicates that the RDEVBLOK is generated, but no entry is made in
the Programmable Communications Controller table.
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
213
Unit Record Error Messages
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 DEVTYPE= 1403, 1443,
2501, 2540P, 2540R, 3203, 3211, 3262, 3289E, 3505, 3525, 3800,0r4245 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 in the printer or punch table; the device cannot be used for CP
spooling.
Control Unit Error Messages
The RCTLUNIT macro generates an RCUBLOK containing an index to each of
sixteen possible devices. When ALTCU 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
radd~2
Error Example:
RDEVICE ADDRESS=140,ALTCU=150
RDEVICE ADDRESS=150
RCTLUNIT ADDRESS=140
RCTLUNIT ADDRESS=150
RCHANNEL ADDRESS=1
Device 140 is defined with a primary control unit address of 140 and an alternate
control unit address of 150. The ALTCU = 150 specification indicates that the 150
RCUBLOK will contain an index to the 140 RDEVBLOK. In this example, an
RDEVICE macro also appears for device 150. A conflict arises since the
RCUBLOK 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.
214
VM/SP' Planning Guide and Reference
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 classes: 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
can be divided 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 RCTLUNIT 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 card
reader/punch and the system console 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
RCTLUNIT macros.
For control units supporting a range of more than eight device addresses, use the
FEATURE operand. The base address 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 supports
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 divis·ible 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/SP requires that all devices on one physical control unit be specified on a single RCTLUNIT macro. The microcode in the 3830-2 that supports 3350 DASD
allows address skipping (in blocks of eight addresses) on the same physical controi
unit.
Error Example:
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 CP. All addresses on a physical control
unit must be specified with a single RCTLUNIT macro using the
FEATURE=xxx-DEVICE operand, where appropriate, for a contiguous range of
addresses.
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
215
A device that attaches directly to the channel without a separate control unit must
still have an RCTLUNIT macro coded for it. For example, if a 3210 is defined
with an RDEVICE macro, it must have a corresponding RCTLUNIT macro.
The 388() Storage Control Unit contains two director modules. Each director
module acts as a control unit providing input/output operations to a string of
devices. Since each director module is separately addressable, one RCTLUNIT
macro statement is required for each module. The optional ALTCH operand of the
RCTLUNIT macro allows specification of up to three alternate channel interfaces
to a single director module. VM/SP supports a maximum of four channel paths to
a single director module.
RCTLUNIT macro instructions describing the control units for your system may be
in any order, but they must be contiguous and follow a~ of the RDEVICE macro
instructions in 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 need not be specified for the RCTLUNIT macro instruction. If a
name is specified it is ignored. The macro generates a name by appending the control unit address to the characters RCU. For example, if the control unit address is
230, RCU230 is generated.
The format of the RCTLUNIT macro is:
Name
label
Operation
RCTLUNIT
Operands
ADDRESS= cuu
,CUTYPE=type
[,ALTCH=<n,n,n)] [,FEATURE=xxx-DEVICE] [,UCW=
~~~~ f]
where:
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.
Note: If you have a 2701,2702, or 2703, and a 3704 or 3705 running in
emulation mode, make sure that their addresses are not the same.
CUTYPE=type
is the device type of the control unit. One of the following device type
numbers can be specified: 1052,2150,2250,2314,2319,2403,2404,
2415,2495,2501,2520,2701,2702,2703,2803,2804,2820,2821,
2822,2826,2835,2840,2841,2844,2845,2848,2955,3036,3066,
3088,3138,3148,3158,3210,3215,3262,3272,3274,3345,3411,
3430,3505,3525,3704,3705,3803,3811,3830,3880,3851,4245,
7443, CTCA, DPA, FTA, HFCU, ICA, IFA, ISC, SVPC.
Only one CTCA may be defined at a time.
216
VM/SP Planning Guide and Reference
In addition, any other control unit that can be attached to a real processor
may be specified in an RCTLUNIT macro instruction by its device type.
Notes:
1. Specify an Integrated Printer Adapter (IPA) as a 2821.
2. Specify a 3274 ModellB as a 3272.
3. If you are using a 3289 Model 4 Printer as a system printer
(DEVTYPE=3289E) attached to a 4331 Display Printer Adapter,
specify CUTYPE=SVPC in the corresponding RCTLUNIT macro. Be
careful not to specify a control unit type of 3272 or 3274. This-will
result in locking out other devices on the adapter, such as 3278s or a
second printer, while a printer is operating.
Even though some devices attach directly to the channel without a separate
control unit, an 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 an RCTLUNIT macro. If several devices
have addresses that are within the same control unit address, only one
RCTLUNIT macro can be specified. Which control unit you specify is not
important.
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. You can specify up to three alternate channels for AP or UP systems. Only one alternate
channel can be specified for multiprocessor systems. Specification of more
than one alternate channel path for MP generated systems produces the following MNOTE:
INVALID ALTCH SPECIFICATION
There can be no 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).
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
217
FEATURE=xxx-DEVICE
is the optional control unit feature. The feature, xxx-DEVICE, indicates
that the control unit is controllirig 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, 3088, 3272, 3274, 3345,
3704, 3705, 3803, 3830, 3880, FTA, HFCU, ICA, IFA, or ISC.
The prefix xxx for a 3088 must be either 32 or 64.
The Integrated File Adapter's 9821 feature, when used with 3344s, is too
large for the RCTLUNIT macro to handle. The range of addresses
160-lF7 is invalid.
A DASD controller, such as a 3830, can be ordered with a hardware feature to support 16,32, or 64 devices. The RCTLUNIT macro must specify
FEATURE=XXX-DEVICE to match the hardware feature of the controller, regardless of the actual number of devices attached to it. The
ADDRESS operand is also very critical. For 32 devices, ADDRESS must
be xOO, x20, x40, etc. (where x is the channel number); always an even
multiple of x20 (decimal 32). Likewise, for 64 devices, the only correct
addresses are xOO, x40, x80, and xCO.
This information is important when an upgrade of installed DASD controllers occurs. Make sure the ADDRESS value is changed in addition to the
FEATURE specification. For any unsupported control unit,
FEATURE = 16-DEVICE is valid and is the maximum you can specify.
Unsupported control units are any that do not appear in "Chapter 2. Configurations. "
Warning: The starter system does not provide support for configurations
over 16 devices when you are defining those needed to do the system generation. Therefore, if you have control units that share more than 16
devices that are switchable to another processor, the channel interface enable switch on the other processor should be in the disable position while
you perform the system generation.
UCW={SHR}
UNS
is the attribute of the UCW. This can be specified only for 3272 or 3274
control units.
SHR indicates a shared UCW
UNS indicates an unshared UCW
218
VM/SP Planning Guide and Reference
Examples:
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
3880, and a 3705 with lines 040 through 04B.
RCTLUNIT ADDRESS=018,CUTYPE=3215
RCTLUNIT ADDRESS=230,CUTYPE=3880,FEATURE=32-DEVICE
RCTLUNIT ADDRESS=040,CUTYPE=3705,FEATURE=16-DEVICE
Channel Error Messages
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 error message is issued when one RCTLUNIT macro is coded (specifying
the ALTCH operand), and an additional RCTLUNIT macro is coded, which creates an RCUBLOK for the alternate channel address (specified by the first
RCTLUNIT macro).
CHANNEL TABLE FOR RCUxxx IN USE BY RCUyyy
Error Example:
RDEVICE ADDRESS=250
RDEVICE ADDRESS=350
RCTLUNIT ADDRESS=250,ALTCH=(3)
RCTLUNIT ADDRESS=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 RCTLUNIT macro and RDEVICE macro for 350 must
be removed.
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
219
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
110 configuration.
The RCHANNEL macro instructions describing your channels may be in any
order, but they must be contiguous and follow all of the RCTLUNIT macro
instructions in DMKRIO. The first RCHANNEL macro instruction generates the
label DMKRIOCH, which indicates the start of the real channel blocks to CPo
No name need be 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:
Name
label
Operation
RCHANNEL
Operands
ADDRESS=address
'CHTYPE={ SELECTOR
MULTIPLEXOR
BLKMPXR
FTA
}
where:
ADDRESS=address
I
is the real address of the channel. It is a hexadecimal number from 0 to F.
CHTYPE=!SELECTOR
MULTIPLEXOR
BLKMPXR
FTA
is the type of channel.
SELECTOR indicates a selector channel.
MULTIPLEXOR indicates a byte multiplexer channel.
BLKMPXR indicates a block multiplexer channel.
FTA indicates a file tape adapter on a 43xx.
Examples:
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=BLKMPXR
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.
220
VM/SP Planning Guide and Reference
RIOGEN Macro
Use the RIOGEN macro instruction to generate the channel index table and unit
record and console tables. RIOGEN must appear as the last macro instruction
before the END statement in the DMKRIO file.
The name field must not be specified for the RIOGEN macro. The format of the
RIOGEN macro is:
Name
label
Operation
RIOGEN
Operands
CONS=cuu
[,ALTCONS=(cuu[,cuu,cuu ... ])]
[,SRF=(cuu[,cuu,cuu ... ])]
where:
CONS=cuu
is the address of the VM/SP 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, 3278, or 3279 (local attachment), or a 3278 Model 2A, 1052 (via a
2150 freestanding console), a system console for the 3158 (in
printer-keyboard mode with the 3213 Printer Modell 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 specifi~d. These devices, which should be located as
close as possible to the primary system console, may be any device supported as a VM/SP logon device (except for those remote terminals connected via 3704/3705 Communications Controllers). If the primary
system console is not operational at VM/SP system initialization, an
attempt is made to access the first alternate console. If the first alternate
console is not operational, an attempt is made to start the next alternate
console. If an operational console is found, the console will be used as the
VM/SP system operator's 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
OAR).
Coding Considerations: The alternate console must not be a telecommunications line on a real IBM 3704/3705 Communications Controller unless
the 3704/3705 was previously loaded by some other operating system with
a 270X Emulator Program.
If the alternate console is an IBM 2741 Communication Terminal, or 3767
Communication Terminal (operating as a 2741), it must use the EBCDIC
transmission code. If the alternate console is a local 3277, it must be a
Model 2.
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
221
[,SRF=(cuu[,cuu,cuu ... ])]
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 3033AP or 3033MP system, there are two 3036 consoles. Each of
these consoles has two 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 (see note 3). The
RIOGEN macro statement produces an MNOTE warning message if you
specify more than 32 SRF devices.
Notes:
1.
In 3033AP or 3033MP systems with I/O configured asymmetrically to one
processor, 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, but the frames from that SRF device are not placed on the error
recording cylinders.
3.
Only one of the two SRF devices of a 3036 console is accessible at anyone
time by the VM/SP control program. Therefore, if both SRF devices of a
3036 are specified on the RIOGEN macro, message DMKIOH559W will be
issued for one of these SRF devices during initialization of the error recording
cylinders. Since both SRF devices of a 3036 console contain identical frame
data, only one SRF per 3036 needs to be successfully accessed during error
recording initialization.
Examples:
The following examples define a primary system console (OlF) with an alternate
console (050), and a system console (009) with no alternate console.
RIOGEN CONS=01F,ALTCONS=050
RIOGEN CONS=009
222
VM/SP: Planning Guide and Reference
Example of Coding the Real 110 Configuration File (DMKRIO)
In this example, macros are coded to support the following real devices:
1 2540 Card Reader/Punch
1 3505 Card Reader
1 3525 Card Punch
2 1403 Printers with the Universal Character Set feature
1 3211 Printer with the Universal Character Set feature
1 3215 Console Printer-Keyboard
1 2955 Data Adapter Unit
7 3279 Color Display Stations
1 3705 Communications Controller (with an IBM1, TELE2 and
BSCA adapter)
1 2305 Fixed Head Storage with 8 addresses
23330 Disk Storage devices (One unit has eight modules and the
other has ten. The unit with ten modules has eight of them
switchable between two channels.)
1 3350 Direct Access Storage with 8 addresses (string switched)
1 3380 Direct Access Storage with 16 addresses
1 3420 Magnetic Tape Unit, Model 8
2 3420 Magnetic Tape Units, Model 7
1 Multiplexer channel
1 Selector channel
3 Block multiplexer channels
1 Channel-to-Channel Adapter
2 channel interfaces on the 3851 MSC
96 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/SP system volumes
43330-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 20 shows the real configuration. The real I/O configuration file that supports this example is shown in Figure 21.
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
223
Channel 0
I
I
008
3811
Printer Control
010
I
OOC 000
~~
1
I
080
OBO
3274
DIsplay Control
2821
Control Unit
002
I
018
H
,..... 030
~
012
H
2540 Card
Reader Punch
3705
Communications
Controller
'-
3215 Console
3505
Card Reader
-
080
'-
2955 Data
Adapter Unit
BSCA
-
03F
040
-
04F
050
-
IBM1
TELE2
'-- 05F
, - 018
-
I
OOE
-L:;:J I
-
018
013
'-
3525
Card Punch
3279 Color
Display Station
f-
-
-
'-- 01E
OOF
-L::::J
Channel 1
I
180
190
~180
3803
Storage Control
~
181
3420-7
Tape Drives
~
CPU
r--
Channel 2
I-""'--
-190
3420-8
Tape Drive
3803
Storage Control
-
1
I-
240
3830-2
Storage Control
~
-
-
r- 250
-
240
250
3350 Disk
Drives
200
uf~
3803-3
Storage Control
~210
1
-
3830
Storage Control
-
-
- 3350 Disk
I-- - Drives
-
-
I
1
201
208
209
2AO
200
3851 MSC
2835
Storage Control
-
--
200
2305
Drives
-
23F
'-- 259
'-- 247
r-
...... 207
Channel 3
I
330
340
3830
Storage Control
r-
3830
Storage Control
[=
1--1
==
-
I
----,
33~0
350/450
Disk
Drives
3830
Storage Control
--[ :::0;.
-
337
300
Drives
Channel-toChannel Adapter
359
Channel 4
I
440
3880
Storage Control·
; - 440
-
---
3380 Disk
Drives
-
-
-
'-- 44F
Figure 20. Example of a Real ComJgUf8tion
224
VM/SP Planning Guide 8!ld Reference
I
410
3830-3
Storage Control
.-- 410
-
-
--- -
-
I
4AO
-
3330 Disk
Drives
-
'-- 43F
3851 MSC
DMKRIO CSECT
COPY OPTIONS
RDEVICE ADDRESS=002,DEVTYPE=3211,CLASS=(X,A),FEATURE=UNVCHSET
RDEVICE ADDRESS=00C,DEVTYPE=2540R
RDEVICE ADDRESS=00D,DEVTYPE=2540P,CLASS=(X,A)
RDEVICE ADDRESS=00E,DEVTYPE=1403,CLASS=(X,A),FEATURE=UNVCHSET
RDEVICE ADDRESS=00F,DEVTYPE=1403,CLASS=('S),FEATURE=UNVCHSET
RDEVICE ADDRESS=012,DEVTYPE=3505
RDEVICE ADDRESS=013,DEVTYPE=3525,CLASS=(X,A)
RDEVICE ADDRESS=(018,7),DEVTYPE=3279,MODEL=3
RDEVICE ADDRESS=01F,DEVTYPE=3215
RDEVICE ADDRESS=(030,16),DEVTYPE=3705,ADAPTER=BSCA,BASEADD=OBO
RDEVICE ADDRESS=(040,16),DEVTYPE=3705,ADAPTER=IBM1,BASEADD=OBO
RDEVICE ADDRESS=(050,16),DEVTYPE=3705,ADAPTER=TELE2,BASEADD=OB0
RDEVICE ADDRESS=080,DEVTYPE=2955
RDEVICE ADDRESS=OBO,DEVTYPE=3705,ADAPTER=TYPE4,MODEL=F4,CPTYPE=EP
RDEVICE ADDRESS=(180,2),DEVTYPE=3420,FEATURE=DUALDENS,MODEL=7
RDEVICE ADDRESS=190,DEVTYPE=3420,FEATURE=DUALDENS,MODEL=8
DEVICE ADDRESSES 200, 201, 208, 209 ALLOW ACCESS TO MSC TABLES
RDEVICE ADDRESS=(200,2),DEVTYPE=3330,MODEL=1
RDEVICE ADDRESS=(208,2),DEVTYPE=3330,MODEL=1
RDEVICE ADDRESS=(210,48),DEVTYPE=3330,MODEL=1,FEATURE=SYSVIRT
RDEVICE ADDRESS=(240,8),DEVTYPE=3350,ALTCU=340
RDEVICE ADDRESS=2AO,DEVTYPE=3851
RDEVICE ADDRESS=2DO,DEVTYPE=2305,MODEL=2
RDEVICE ADDRESS=(330,8),DEVTYPE=3330,MODEL=1
RDEVICE ADDRESS=(350,8) ,DEVTYPE=3330,MODEL=1
RDEVICE ADDRESS=(358,2),DEVTYPE=3330,MODEL=11
RDEVICE ADDRESS=3DO,DEVTYPE=CTCA
RDEVICE ADDRESS=(410,48),DEVTYPE=3330,MODEL=1,FEATURE=VIRTUAL
RDEVICE ADDRESS=(440,16),DEVTYPE=3380
RDEVICE ADDRESS=4AO,DEVTYPE=3851
RCTLUNIT ADDRESS=000,CUTYPE=3811
RCTLUNIT ADDRESS=008,CUTYPE=2821
RCTLUNIT ADDRESS=010,CUTYPE=3505
RCTLUNIT ADDRESS=018,CUTYPE=3274
RCTLUNIT ADDRESS=030,CUTYPE=3705,FEATURE=48-DEVICE
RCTLUNIT ADDRESS=080,CUTYPE=2955
RCTLUNIT ADDRESS=OBO,CUTYPE=3705
RCTLUNIT ADDRESS=180,CUTYPE=3803
RCTLUNIT ADDRESS=190,CUTYPE=3803
RCTLUNIT ADDRESS=200,CUTYPE=3830,FEATURE=64-DEVICE
RCTLUNIT ADDRESS=240,CUTYPE=3830
RCTLUNIT ADDRESS=2AO,CUTYPE=3851
RCTLUNIT ADDRESS=2DO,CUTYPE=2835
RCTLUNIT ADDRESS=330,CUTYPE=3830
RCTLUNIT ADDRESS=340,CUTYPE=3830
RCTLUNIT ADDRESS=350,CUTYPE=3830,FEATURE=16-DEVICE,ALTCH=4
RCTLUNIT ADDRESS=3DO,CUTYPE=CTCA
RCTLUNIT ADDRESS=400,CUTYPE=3830,FEATURE=64-DEVICE
RCTLUNIT ADDRESS=440,CUTYPE=3880,FEATURE=16-DEVICE
RCTLUNIT ADDRESS=4AO,CUTYPE=3851
RCHANNEL ADDRESS=O,CHTYPE=MULTIPLEXOR
RCHANNEL ADDRESS=1,CHTYPE=SELECTOR
RCHANNEL ADDRESS=2,CHTYPE=BLKMPXR
RCHANNEL ADDRESS=3,CHTYPE=BLKMPXR
RCHANNEL ADDRESS=4,CHTYPE=BLKMPXR
RIOGEN CONS=01F,ALTCONS=018
END
Figure 21. RealI! 0 ComJgW'8tion File
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
225
Considerations for Coding the Input/Output Configuration Source File
If you are generating VM/SP on a 3081 Processor complex, you must define addi-
tional I/O information to the processor controller. To define the I/O configuration
to the 3081 processor, create an input/output configuration source file and write it
to the processor controller using the Input/Output Configuration Program. The
10CP source file you create should contain entries that match the real I/O configuration file.
When preparing the 10CP source file, be sure you code the 10CP macro definitions
in the following order:
•
•
•
Channel paths
Control units
I/O devices
It is not necessary to group all macro definitions of the same type together; howev-
er, you must insure that devices and control units are defined under the appropriate
channel macros. If not, 10CP fails with an error message.
Do not intermix 10CP macro definitions and VM/SP I/O macro definitions in the
same file. You must maintain two distinct files; the real I/O configuration file and
the corresponding 10CP source file. See the OS/VS2 MVS, VM/SP and
Stand-Alone Versions Input/Output Configuration Program User's Guide and Reference for 10CP source file coding conventions.
Figure 22 is an example of the 10CP source file needed to match the real I/O configuration defined in Figure 21. For additional information about the
Input/Output Configuration program, refer to "Chapter 8. Planning for Virtual
Machine Operating Systems (Other than CMS)."
226
VM/SP Planning Guide and Reference
Example: Coding the Input/Output Configuration Source FOe
ID
MSG1='SAMPLE IOCP FILE'
CHPID PATH=«OO,O,O» ,TYPE=BY
CHPID PATH=«01,1,0»,TYPE=BL
CHPID PATH=«02,2,0»,TYPE=BL
CHPID PATH=«03,3,0» ,TYPE=BL
CHPID PATH=«04,4,0»,TYPE-BL
CNTLUNIT CUNUMBR=000,PATH=00,SHARED=N,UNIT=3811,
UNITADD=( (00,8»
CNTLUNIT CUNUMBR=001 ,PATH=00,SHARED=N,UNIT=3811 ,
UNITADD=( (08,8»
CNTLUNIT CUNUMBR=002,PATH=00,SHARED=N,UNIT=3505,
UNITADD= ( ( 10,8) )
CNTLUNIT CUNUMBR=003,PATH=00,SHARED=N,UNIT=3274,
UNITADD= ( ( 18,8) )
CNTLUNIT CUNUMBR=004 , PATH=OO , SHARED=N,UNIT=3705 ,
UNITADD=«30,48»
CNTLUNIT CUNUMBR=006,PATH=00,SHARED=N,UNIT=2955,
UNITADD=( (80,8»
CNTLUNIT CUNUMBR=007,PATH=00,SHARED=N,UNIT=3705,
UNITADD=(BO)
CNTLUNIT CUNUMBR=010,PATH=01,SHARED=Y,UNIT=3803,
UNITADD=( (80,8»
CNTLUNIT CUNUMBR=011,PATH=01,SHARED=Y,UNIT=3803,
UNITADD= ( (90,8) )
CNTLUNIT CUNUMBR=020,PATH=02,SHARED=N,UNIT=3830,
UNITADD= ( (00,6'4) )
CNTLUNIT CUNUMBR=021,PATH=02,SHARED=N,UNIT=3830,
UNITADD=( (40,8»
CNTLUNIT CUNUMBR=024,PATH=02, SHARED=N,UNIT=3851,
UNITADD=( (AO,8»
CNTLUNIT CUNUMBR=025,PATH=02,SHARED=N,UNIT=2835,
UNITADD= ( (DO, 8) )
CNTLUNIT CUNUMBR=031,PATH=03,SHARED=N,UNIT=3830,
UNITADD= ( (30,8) )
CNTLUNIT CUNUMBR=032,PATH=(03,04),SHARED=N,UNIT=3830,
UNITADD=«50,16»
CNTLUNIT CUNUMBR=033,PATH=03,SHARED=N,UNIT=CTCA,
UNITADD=( (CO,8»
CNTLUNIT CUNUMBR=034,PATH=03,SHARED=N,UNIT=3830,
UNITADD= ( (40,8) )
CNTLUNIT CUNUMBR=040,PATH=04,SHARED=N,UNIT=3830,
UNITADD=«00,64»
CNTLUNIT CUNUMBR=041,PATH=04,SHARED=N,~NIT=3880,
UNITADD=«40,16»
CNTLUNIT CUNUMBR=042,PATH=04,SHARED=N,UNIT=3851,
UNITADD= ( (AO, 8) )
IODEVICE ADDRESS=002,UNIT=3211,CUNUMBR=000
IODEVICE ADDRESS=00C,UNIT=2540R,CUNUMBR=001
IODEVICE ADDRESS=00D,UNIT=2540P,CUNUMBR=001
IODEVICE ADDRESS=00E,UNIT=1403,CUNUMBR=001
IODEVICE ADDRESS=00F,UNIT=1403,CUNUMBR=001
IODEVICE ADDRESS=012,UNIT=3505,CUNUMBR=002
IODEVICE ADDRESS=013,UNIT=3525,CUNUMBR=002
IODEVICE ADDRESS=(018,7),UNIT=3279,MODEL=3,CUNUMBR=003
*IOCP
DUMMY DEVICE FOR CP ONLY
*IOCP
IODEVICE ADDRESS=01F,UNIT=3215,CUNUMBR=003
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Figure 22 (Part 1 of 2). IOCP Source File
Chapter 19. Preparing the Real I/O Configuration File (DMKRIO)
227
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
IODEVICE
ADDRESS=(030,16),UNIT=3705,CUNUMBR=004
ADDRESS=(040,16),UNIT=3705,CUNUMBR=004
ADDRESS=(050,16),UNIT=3705,CUNUMBR=004
ADDRESS=080,UNIT=2955,CUNUMBR=006
ADDRESS=OBO,UNIT=3705,CUNUMBR=007
ADDRESS=(180,2),UNIT=3420,MODEL=7,CUNUMBR=010
ADDRESS=190,UNIT=3420,MODEL=8,CUNUMBR=011
ADDRESS=(200,2),UNIT=3330,MODEL=1,CUNUMBR=020
ADDRESS=(208,2),UNIT=3330,MODEL=1,CUNUMBR=020
ADDRESS=(210,48),UNIT=3330,MODEL=1,CUNUMBR=020
ADDRESS=(240,8),UNIT=3350,CUNUMBR=(021,034)
ADDRESS=2AO,UNIT=3851,CUNUMBR=024
ADDRESS=2DO,UNIT=2305,MODEL=2,CUNUMBR=025
ADDRESS=(330,8),UNIT=3330,MODEL=1,CUNUMBR=031
ADDRESS= (350,8) ,'UNIT=3330 , MODEL= 1 , CUNUMBR=032
ADDRESS=(358,2),UNIT=3330,MODEL=11,CUNUMBR=032
ADDRESS=3DO,UNIT=CTC,CUNUMBR=033,TIMEOUT=N
ADDRESS=(410,48),UNIT=3330,MODEL=1,CUNUMBR=040
ADDRESS=(440,16),UNIT=3380,CUNUMBR=041
ADDRESS=4AO,UNIT=3851,CUNUMBR=042
Figure 11 (Part 1 of 1). IOCP Source Flle
228
VM/SP Planning Guide and Reference
Chapter 20. 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 NAMESYS macro creates an entry in the system name table for a virtual
machine operating system or saved segment.
•
The NAMENCP macro creates an entry in the system name table for a
3704/3705 control program.
•
The NAME3800 macro creates an entry in the system name table for a 3800
named system.
The system name table is assembled by a system programmer. It describes the system to be saved via the SAVESYS command and to be IPLed by name. Shared
segments can be specified. These segments must consist of all reentrant code.
The system name table (DMKSNT) is a pageable module. It may not exceed one
page (4K) in size.
Note: For a list of the DMKSNT files supplied with the Product Tape, refer to the
VM/SP Installation Guide.
The sample DMKSNT files each have seven entries: one each for saving copies of
CMS, CMSL, CMSVSAM, CMSAMS, CMSDOS, INSTVSAM, and CMSBAM.
The CMSL entry can be removed from your DMKSNT if you have no need of a
CMS shared system located in high virtual storage. If you use all recommended
labels and allocations and the starter system supplied DMKSYS, you can save these
segments during the system generation procedure. The INSTVSAM segment is a
CMSDOS segment that is used only during the procedure for loading and saving
CMSVSAM, CMSAMS and CMSBAM segments. For an explanation of this procedure, and for an illustration of the storage layout resulting from this suggeste~
configuration, see "Loading and Saving Discontiguous Saved Segments" in the'
VM / SP Installation Guide.
If you wish to change or add to the suggested system name table, code your own
macro and create a DMKSNT file of your own. One entry can be created for each
type of discontiguous segment.
If you create your own version of the system name table, your file must have a
CSECT and END statement:
DMKSNTBL CSECT
NAMESYS
macros (one for each virtual machine operating system or segment you wish to save)
NAMENCP macros (one for each 3704/3705 control
program you create)
NAME3800 macros (one for each 3800 named system you
create)
END
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. Information about coding the NAMESYS, NAMENCP, and NAME3800 macros follows.
Chapter 20. Preparing the System Name Table File (DMKSNT)
229
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 permitted.
The format of the NAMESYS macro is:
label
NAMESYS
SYSSIZE=nnnnnK,SYSNAME=name, [VSYSRES=cccccc,]
VSYSADR=[cuu
],SYSVOL=cccccc, [SYSCYL=nnn,
]
[IGNORE]
[SYSBLOK=nnnnnn,]
SYSSTRT=~(cc,p),l [SYSPGCT=pppp,]
lpppppp, ~
SYSPGNM=(nn,nn,nn-nn, ... ),
SYSHRSG=(s,s •... ),
PROTECT=lg~Ff
[USERID=userid,] [RCVRID=rcvrid,]
[SAVESEQ=~. ~
. .lJ
lprlorlty5
where:
label
is any desired user label.
SYSSIZE=nnnnnK
where nnnnnk represents the least 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
is the name (up to eight alphameric characters) of the system or segment to be used for identification by the SAVESYS and/or IPL commands. The name selected must not be one that could be interpreted
as a hexadecimal device address (for example, A or E).
VSYSRES=cccccc
is the real volume serial number (up to six 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 you code
VSYSADR=IGNORE, but you must specify it as null (VSYSRES=,).
This operand is flagged and ignored if USERID= is specified.
VSYSADR=cuu
is the virtual address of the minidisk that is the system residence volume of the system to be saved. This operand defaults to IGNORE if
USERID = is specified. Other values are flagged.
"VSYSADR=IGNORE" must be coded when you are defining a discontiguous saved segment. It may also be used when defining a saved
system to improve performance.
Note: If you are likely to have a large number of eMS users active at
one time, you should distribute eMS activity over two volumes by (1)
setting up a second eMS system residence volume and dividing the
users between the two eMS system residence volumes or (2) putting
your program products on one spindle and eMS non-resident commands on another spindle.
230
VM/SP Planning Guide and Reference
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) of the
DASD volume designated to receive the saved system or segment.
This must be a CP-owned volume.
SYSCYL=nnn,
}
{ SYSBLOK=nnnnnn,
is the real starting location of the virtual disk (specified by VSYSRES
and VSYSADR) that is the system residence volume for the system to
be saved. For count-key-data DASD, specify the SYSCYL= parameter. This operand is flagged and ignored if USERID= is specified.
For fixed-block DASD, specify the SYSBLOK= parameter. This
operand is flagged and ignored if USERID= is specified.
SYSSTRT={(CC,P) , }
pppppp,
is the starting location on SYSVOL where this named system is to be
saved. During SAVESYS and IPL processing, this location is used to
generate DASD addresses for I/O operations. For count-key-data
SYSVOL devices, specify (cc,p), where cc designates the starting cylinder address and p the starting page address. For fixed-block
SYSVOL devices, specify pppppp, representing the starting page
address. These numbers are specified in decimal.
The number of pages written to this area is the total number specified
on the SYSPGNM operand, plus one information page. This operand
is ignored if VSYSADR=IGNORE, but you must specify it as null
(SYSCYL=, or SYSBLK=,).
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 N AMESYS macro calculates the
number of pages to be saved.
SYSPGNM=(nn,nn,nn-nn, ... )
are 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 SYSPGCT specification.
SYSHRSG=(s,s, ... )
are segment numbers designated as shared (numbered from zero up,
with the first segment, for example, specified as 0). Pages in these
segments are set at IPL time to be used by any user loading by this
name. All shared segments must be reenterable. The maximum number of defined shared segments is 78. This operand is flagged and.
ignored if USERID= is specified.
Chapter 20. Preparing the System Name Table File .(DMKSNT)
231
PROTECT= {
~~F }
indicates that VM/SP is to run either with protected (ON) or unprotected (OFF) shared segments for the named 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/SP control program; the change will be seen by all users of the
shared page.
USERID=userid
is the userid of the virtual machine that is saved in the designated area.
(This user can IPL from that area.) Any value specified for USERID
indicates that this is a VMSAVE target area specification.
Note: More than one target area may be specified for a single userid
by including more than one NAMESYS macro with the same
USERID= parameter.
RCVRID=rcvrid
is the userid of the virtual machine authorized to access a system save
area. This is an optional parameter. It defaults to the value specified
for USERID. The parameter is flagged with an MNOTE and ignored
if specified when USERID= is not specified.
SAVESEQ={
.10.
}
prJ.orJ.ty
specifies the order in which multiple virtual machines will be saved.
Values can be from 0 to 255. The virtual machine with the lowest
number is saved first. If two virtual machines have the same value, the
one that enabled the VMSAVE option first is dumped first. This
parameter is flagged with an MNOTE and ignored if specified when
USERID = is not specified. If the SAVESEQ priority value is not
supplied, the default value is 10.
The number of 4K pages available per DASD cylinder is:
Pages/ Cylinder
24
32
57
120
96
150
DASDType
3340-35,3340-70,2305
2314,2319
3330,3333
3350 (in native mode)
3375
3380
Information on the following subjects is in VM / SP System Programmer's Guide:
•
•
•
•
•
•
232
VM/SP: Planning Guide and Reference
Determining when to save a system
Using the SAVESYS command
Saving the CMS system
Saved system restrictions for CMS
Saving OS
Using discontiguous saved segments (CMSDOS, CMSVSAM, CMSAMS,
CMSBAM)
Coding the NAMENCP Macro
You must create an entry in the system name table (DMKSNT) for each separate
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/SP. In this way, you do not have to
regenerate the VM/SP system just to update the system name table.
Use the NAMENCP macro to define 3704/3705 program entries in the system
name table. The format of the NAMENCP macro is:
label
NAMENCP
CPSIZE=nnnK,
CPNAME=ncpname,
CPTYPE={EP }
SYSPGCT=pp,
SYSVOL=volser,
SYSSTRT~1 (CCC,p)~
pppppp
where:
label
is any desired user label.
CPSIZE=nnnK
is the storage size of your 3704/3705. 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 value may
be equal to the number of pages implied by the CPSIZE operand plus four pages for con~rol information, but it must not
exceed that total.
SYSVOL=volser is the volume serial number (volser) of the DASD volume des-
ignated to receive the CP image. That volume must be
CP-owned.
SYSSTRT={(CCC,P)}
pppppp
is the starting location on SYSVOL where this named system is
to be saved. During SAVESYS and IPL processing this is used
to generate the DASD addresses for I/O operation. For
count-key-data SYSVOL devices, specify (ccc,p), where ccc
designates the starting cylinder address and p the starting page
address. For fixed-block SYSVOL devices, specify pppppp
representing the starting page address. These numbers are specified in decimal.
Chapter 20. Preparing the System Name Table File (DMKSNT)
233
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. More than one named system 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:
label
NAME3800
CPNAME=libnarne,
SYSPGCT=pppp,
SYSVOL=volser,
SYSSTRT= (ccc ,p).
where:
label
is any desired user label.
CPNAME=libnarne
is the name of the 3800 image library. This name is used in the
IMAGELIB or IMAGEMOD command. The name must be
from one to eight alphameric characters.
ISYSPGCT=PPPP
is the total number of pages (pppp) to be saved for the image
library. This value is a decimal number up to four 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
(pppp). Be sure to round up to the next whole page.
SYSVOL=volser 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.
234
VM/SP Planning Guide and Reference
Chapter 21. Preparing the CP System Control File (DMKSYS)
The CP system control file consists of macro statements that describe the
following:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
CP system residence device
System storage size
CP-owned direct access devices
System operator's user identification
System timer value
System pointer variables
Automatic performance monitoring parameters
Accounting parameters
System identification
System spool parameters
Security journaling parameters
System dump space parameters
System T-DISK security parameters
Missing I/O interruption timer intervals
You are responsible for ensuring the presence and accuracy of the macros
described below.
The DMKSYS ASSEMBLE file provided with the starter system does not assemble
properly unless you have reserved adequate space for the CP nucleus.
The format of the DMKSYS file follows:
DMKSYS
CSECT
SYSOWN
SYSRES
SYSOPR
SYSCOR
SYSTIME
SYSMON
SYSJRL
SYSACNT
SYSFORM
SYSPCLAS
SYSID
SYSORD
SYSMIH
SYSLOCS
END
macro
macro
macro
macro
macro
macro
macro
macro
macro
macro
macro
macro
macro (optional)
macro
Notes:
1. Sample DMKSYS files are provided with the starter system, and are listed in
the VM/SP Installation Guide. If you use these, you can save the CMS system
at the end of sy,stem generation. The VM/SP installation procedure prompts
you to ask if you want the sample DMKSYS file punched. You may modify
this file if you wish. For example, you could modify the starter system
DMKSYS file to add other CP-owned volumes.
2.
SYSLOCS must always be the last macro coded.
Chapter 21. Preparing the CP System Control File (DMKSYS)
235
3.
You must code all macro statements, except for SYSMIH, even if you code no
operands on some macro statements. SYSMIH is optional.
4. If the SYSMIH macro is coded, it must be placed immediately before the
SYSLOCS macro.
Performance Considerations for Coding the DMKSYS File Macros
The following recommendations may help reduce arm and channel contention, and
may improve the performance of a VM/SP system.
•
Provide separate CP volumes for paging and spooling and have the volumes
mounted on separate channels.
•
If you have a heavy I/O production virtual machine (for example, one that is
running OS/VSl or VSE/ AF), try to keep all its major I/O devices on a separate channel from a channel handling the CMS system residence volume or
other user's disks.
•
Try to keep read-only minidisks (for example, the CMS system residence disk
and source disks) that are frequently accessed on separate volumes from users'
read/write minidisks. If possible, also keep them on separate channels.
If you have disks with fixed head areas (2305/3340/3350/3380) you should
use them for preferred paging. To do this, allocate this area as preferred paging space using the Format/Allocate program. For more details see the Operator's Guide.
•
The relative amounts of storage for dynamic paging and free storage can be
optimized by using the FREE operand of the SYSCOR macro statement. You
should initially allocate one page of fixed free storage for each virtual machine
that is logged on, based on the average number of users that you expect to
have logged on at anyone time.
•
Using the automatic monitoring facilities, study the load conditions and performance profile for your system as soon as possible. These facilities, used
with programs similar to the IBM FDP (Field Developed Program) Virtual
Machine Facility/370: Performance/Monitor Analysis Program are designed
to make data collection and reduction easy, thus allowing the analyst to concentrate on analysis. Data collection can be performed on a regular basis by
specifying AUTO = YES on the SYSMON macro instruction. The system
assumes default values for other operands if none are specified.
•
You can determine the monitoring interval for the missing interruption handler
support. Some classes of devices may require an interval other than the default
interval provided in DMKSYS. For instance, if you have many direct storage
devices, you may need to lengthen the time interval for the DASD class. This
would eliminate the unnecessary missing interruption handler processing for
devices that are functioning properly. Be careful not to lengthen the time
interval too much, since you may lose the usefulness of missing interruption
monitoring.
The SYSMIH macro statement controls the time intervals for missing interruption monitoring. If you have already generated the system, you can change
the time intervals with the SET MITIME command.
236
VM/SP: Planning Guide and Reference
SYSOWN Macro
Use the SYSOWN macro to generate the list of up to 255 CP-owned DASD volumes. A CP-owned volume is either the CP system residence volume, or a volume
that contains VM/SP paging, spooling, dump, directory, or temporary disk space.
It must contain a CP allocation table allocating these areas at cylinder 0, record 4
for count-key-data devices, or blocks 3 and 4 for FB-512 devices. Even if a volume has a VM/SP allocation table in the appropriate area, allocation data is
ignored unless the volume appears as an operand in the SYSOWN macro instruction.
Note: The SYSOWN macro must appear before the SYSRES macro in the assembly listing.
The name field must not be specified for the SYSOWN macro. The format of the
SYSOWN macro is:
Operatian
SYSOWN
Operands
valid, [valid, ... ]
where:
is the CP-owned volume identification of from one- to six- alphameric
characters.
valid
Example:
The following is an example of the SYSOWN macro:
SYSOWN VMSRES,VMSTGE
Special Considerations for Allocating Space on CP-Owned Volumes: The' following
considerations should help you to allocate space efficiently on CP-owned volumes:
•
The SYSOWN macro statement does not distinguish preferred from nonpreferred cylinders on a volume. Use the SYSORD macro statement to specify
the order in which the preferred/ nonpreferred devices are to be searched to
satisfy paging and spooling operations. The CP Format/Allocate service program accepts PAGE and TEMP as operands on the control statements to designate preferred and nonpreferred paging areas (spool, page overflow).
•
If a volume is specified in a SYSOWN statement, but is not mounted when the
generated system is loaded (via the IPL command), that volume is considered
not available to VM/SP. Processing continues, if possible. The operator can
mount and attach the volume later, if it is needed.
•
Only volumes that contain paging, spooling, dump, directory, or T -DISK space
need be identified as CP-owned volumes. All other volumes are described
either by directory entries or by logically attaching the entire device.
•
If you add another volume to the SYSOWN list, you must add it at the end of
the list. (Otherwise, if you attempt a warm start after regenerating and loading
CP, the relative entry number used to locate system spool buffers is incorrect.)
Then reassemble DMKSYS, build the CP nucleus, and reload it on the system
Chapter 21. Preparing the CP System Control File (DMKSYS)
237
residence volume or on an alternate IPL device. Use the GENERATE EXEC
procedure to reassemble DMKSYS and reload the CP nucleus. Refer to the
VM / SP Installation Guide for details on using the GENERATE EXEC.
•
If you have saved systems (systems that can be loaded by name, thus not per-
forming the initial program load procedure), you must reserve space on a
CP-owned volume to hold the named systems you want saved. The DASD
space you reserve, for each named system you wish to save, should be enough
to contain the number of pages specified in the SYSPGCT operand of the
NAMESYS macro, plus one page for system use.
•
If your VM/SP system has a 3704 or 3705, you must reserve space on a
CP-owned volume to contain the 3704/3705 control program image. See
"Chapter 13. Planning for the 3704/3705 Control Program" for information
about how much DASD space you should reserve.
238
VM/SP Planning Guide and Reference
SYSRES Macro
Use the SYSRES macro instruction to describe characteristics of the CP system residence volume.
The name field must not be specified for the SYSRES macro instruction.
Special Considerations for Coding the SYSRES Macro: The following information
should help you when you code the SYSRES macro:
•
All operands must be specified with appropriate values.
•
Areas required for SYSNUC, SYSERR, SYSWRM, and SYSCKP must be
formatted using the CP Format/Allocate service program, and must be allocated as permanent space on the SYSRES volume, but not in cylinder O.
•
VM/SP allows 2314 or 2319 "alternate track" cylinders 200-202 to be used
for normal data if they are not needed to replace defective tracks.
•
On a 3340, "alternate track" cylinders cannot be used for normal data. On a
3340 Model 35, use only cylinders 0-347. On a 3340 Model 70, use only cylinders 0-695.
•
An MSS 3330V volume may not be used as the VM/SP SYSRES volume.
Chapter 21. Preparing the CP System Control File (DMKSYS)
239
The format of the SYSRES macro is:
Name
Operation
SYSRES
Operands
SYSVOL=serial,
SYSRES=[(] (addrllS [ , a 1 taddr]) [) ]
SYSTYPEJ2305
2314
2319
3330
3340
3350
3375
3380
FB-512
1f
SYSNuc=~strtCYl
strtpage
~'
SYSCLR={~~S~
SYSERR=
{strtcYl [ , cylcount ~ }
[ (]
strtpage
SYSCKP=
[ (]
,2
,pagecount
, 100
{strtcYl [, cylcount ~ }
strtpage
SYSWRM= [(] rtrtCYl
strtpage
,1
,pagecount
,50
[) ]
[) ]
[CYlcount
~ } [)]
,1
, pagecount .
, 50
,
where:
SYSVOL=serial
is the volume identification of the system residence disk. 'serial' is a string
of up to six characters.
SYSRES=address ({address[,altaddr]})
designates a three-digit hexadecimal device address (cuu) for the DASD
volume to contain the newly generated system. [altaddr] identifies an alternate address for writing the CP nucleus. For multiprocessing systems, specification of an alternate address allows native execution of CP module
DMKSAV on either processor. DMKSAV writes the newly generated CP
nucleus on the IPL volume. If both address and altaddr are specified,
parentheses are required.
240
VM/SP Planning Guide and Reference
SYSTYPE= 2305
2314
2319
3330
3340
3350
3375
3380
FB-512
is the device type of the system residence device.
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. 2305 applies to both 2305-1 and
2305-2.
SYSNuc=Jstrtcyl
~,
1strtPage~
is the number of the real starting cylinder where the CP nucleus resides
(strtcyl) or the starting page number of the CP nucleus for FB-512
(strtpage).
strtcyl is a one to three-digit decimal number.
strtpage is a one to six-digit decimal number.
Normally,
•
•
•
•
•
•
•
A 2314 or 2319 device requires seven contiguous cylinders
A 2305 or 3340 device requires ten contiguous cylinders
A 3330/3333 device requires four contiguous cylinders
A 3350 device requires two cylinders
A 3375 device requires three cylinders
A 3380 device requires two cylinders
An FB-512 requires approximately 220 pages
to contain the CP nucleus.
SYSCLR=~ ~~S
!
specifies automatic clearing of all previously written data and directory
areas residing on T -DISK DASD space. This prevents other users from
accidentally accessing these areas. If (YES) is specified, T-DISK DASD
space is cleared to binary zeroes at CP initialization and when attaching a
CP-owned volume containing T-DISK allocations. T-DISK space is also
cleared when a user detaches aT-DISK. Specifying SYSCLR= YES provides additional security for your VM/SP installation. If you specify (NO),
the system will clear cylinder 0, track 0 on T-DISK DASD.
The SYSCLR option is required. Specifying SYSCLR with invalid or misspelled options produces the following MNOTE:
INVALID SYSCLR OPTION
and the specification defaults to YES.
Chapter 21. Preparing the CP System Control File (DMKSYS)
241
SYSERR=
\
strtcyl
[ (]
strtpage
'
CYIcount~
[ :~agecount
!
[)]
, 100
is the number of the real starting cylinder (strtcyl), or the starting page
number for FB-S12 (strtpage), where error records are written. Optionally,
it is the number of cylinders required for error recording (cylcount) or the
number of FB-S12 pages (pagecount).
The strtcyl is a one to three-digit decimal number designating the starting
cylinder of the error recording area.
The cylcount is a one-digit decimal number between 2 and 9 designating
the number of cylinders.
The strtpage is a one to six-digit decimal number designating the starting
page of the error recording area.
The pagecount is a one to six-digit decimal number designating the number
of pages.
SYSCKP=
[ (]
~
i
strtcyl
strtpage
rCYlcountl!
~ i~gecounJ
[) ]
is the number of the real starting cylinder (strtcyl), or the starting page
number for FB-S12 (strtpage), of the checkpoint area. It is optionally the
maximum number of cylinders to contain the dynamic checkpoint start data
(cylcount), ·or the number of FB-S12 pages to be reserved (pagecount).
The default for pagecount is SO.
The checkpoint space available determines how many spool file IDs may be
assigned. The maximum number of spool file IDs is the lesser of either the
9900 system limit or the number of checkpoint slots allocated. The strtcyl
is a one to three-digit decimal number designating the first real cylinder
where CP checkpoint start information is to be saved.
The cylcount value is a two-digit decimal number (1 through 20) that
defines the maximum number of cylinders to contain checkpoint start data.
If cylcount is not specified, 1 is the default value. For example: one cylinder of a 3330 will allow slightly less than 2000 spool file IDs.
The cylcount/ pagecount operand is optional. If included, the
strtcyI! strtpage and cylcount/ pagecount operands must be separated by a
comma and enclosed in parentheses. Parentheses are optional when only
the strtcyl operand is specified.
242
VM/SP Planning Guide and Reference
The number of cylinders or pages required for the checkpoint start data is
dependent upon the device type. They are as follows:
Device Type
Minimum Recommended
No. of Cylinders/Pages
Cylinders/Pages for
9900 Spool File ·IDs
2305
3 cylinders
14 cylinders
2314
2 cylinders
11 cylinders
2319
2 cylinders
11 cylinders
3330
1 cylinder
6 cylinders
3340
3 cylinders
14 cylinders
3350
1 cylinder
4 cylinders
3375
1 cylinder
5 cylinders
3380
1 cylinder
3 cylinders
50 pages
FB-512
298 pages
Use the following formulas to calculate space needed for the dynamic
checkpoint start area. The formula for each device type is:
Device Type
Formula
2314/2319
N
=
[34+ (NSP /32) + (NRS/34)]
32
2305/3340
N
=
[26+ (NSP /32) + (NRS/34)]
24
3330
N
=
[59+ (NSP /32) + (NRS/34)]
57
3350
N
=
[122+ (NSP/32)+(NRS/34)]
120
3375
N
=
[98 + (NSP /32) + (NRS/34)]
96
3380
N
=
FB-512
N
=
[152+ (NSP /32) + (NRS/34)]
150
[2+ (NSP /32) + (NRS/34)]
Figure 23. Dynamic Checkpoint Start Area Calculations
where:
N
is the number of cylinders or pages required for checkpoint start
data.
NSP
is the number of spool files to be checkpointed. There are 32
entries per 4096-byte record.
NRS
is the number of real spooling devices defined in DMKRIO.
Note: When using the formulas above for count-key-data DASD, disregard
any remainder in the answer.
Chapter 21. Preparing the CP System Control File (DMKSYS)
243
SYSWRM=[ (]
!:::::::e [i;::::::~ I [)]
is the number of the real starting cylinder (strtcyl), or the starting page
number for FB-S12 (strtpage), to contain the warm start data. It is
optionally the maximum number of cylinders to contain the warm start data
(cylcount), or the number of FB-S12 pages to be reserved (pagecount).
The strtcyl is a one to three-digit decimal number designating the first real
cylinder where CP warm start information is to be saved.
The cylcount value is a two-digit decimal number (1 through 20) that
defines the maximum number of cylinders to contain warm start data. If
cylcount is not specified, one is the default value.
strtpage is a one to six-digit decimal number.
pagecount is a one to six-digit decimal number.
The cylcount/ pagecount operand is optional. If included, the
strtcyl/strtpage and cylcount/pagecount operands must be separated by a
comma and enclosed in parentheses. Parentheses are optional when only
the strtcyl/ strtpage operand is specified.
Use the following formulas to calculate the number of warm start cylinders
or pages required. When you use the formulas, disregard all remainders.
For example, for a 3330 system residence volume with:
•
•
•
A maximum of 32 spool files in the system at one time
A maximum of 128 cylinders available for spool files
A maximum of SO active users at one time
the calculation is
N
=
[59 + 32/32 + 128/128 + 200/50]
57
244
VM/SP Planning Guide and Reference
65
57
The formula for each device type is:
Formula
Device Type
2314/2319
N
= [34+~NSF/32~+~NCS/128~+~~NAUx4~/50~1
32
3340/2305
N
= [26+(NSF/32~+~NCS/128~+(~NAUx4~/50~J
24
3330
N
= [59+~NSF/32)+~NCS/128)+(~NAUx4~/50~J
57
3350
N
= [122+(NSF/32~+(NCS/128)+«NAUx4~/50)J
120
3375
N
= [98+(N~F/32)+(NCS/128)+(~NAUx4)/150~1
96
3380
N
= [152+(NSF/32)+(NCS/128)+~(NAUx4)/50)]
150
FB-512
N
= [2+(NSF/32)+(NPS/85)+«NAUx4)/50)]
Figure 24. Warm Start Area Calculations
where:
N
is the number of cylinders or pages required for warm start data.
NSF
is the maximum number of spool files in the system at anyone time. There
are 32 spool file blocks per 4096-byte re.cord
NCS
is the number of cylinders available for spool files. There are 128 allocation blocks per 4096-byte record.
NPS
is the number of pages available for spool files. There are 128 allocation
blocks per 4096-byte record.
NAU is the maximum number of active users in the system at anyone time':.
There are 50 accounting records per 4096-byte record.
Example:
The following SYSRES macro defines the system residence volume as the 3380
volume with a serial number of VMSRES. During the system generation procedure
this volume is found at address 123. The VM/SP nucleus resides at cylinder 882
and the warm start storage area is cylinders 877 and 878. The error recording area
starts at cylinder 879 and the checkpoint start storage area is cylinder 442. The
format of the SYSRES macro is:
SYSRES SYSVOL=VMSRES,SYSRES=123,SYSTYPE=3380,SYSNUC=882,SYSCLR=,
SYSWRM=(877,2) ,SYSERR=(879,2),SYSCKP=(442,1)
Chapter 21. Preparing the CP System Control File (DMKSYS)
X
245
SYSOPR Macro
Use the SYSOPR macro instruction to specify the system operator's userid, and the
userid of the operator who is to receive VM/SP system dumps. The same use rid
may be specified in both operands.
The name field must not be specified for the SYSOPR macro instruction.
The format of the SYSOPR macro is:
Name
Operation
Operands
SYSOPR
[SYSOPER=OPERATOR ]
SYSOPER=userid
[,SYSDUMP=OPERATNS]
,SYSDUMP=userid
where:
SYSOPER=OPERATOR ]
[ SYSOPER=userid
is the userid of the virtual machine to be assigned to the system operator. If
SYSOPER is not specified, the userid OPERATOR is used.
The userid is a character string up to eight- characters long.
SYSDUMP=OPE~TNS ]
[ SYSDUMP=userld
is the userid (a string of up to eight characters) of the virtual machine whose
spool input receives the system dump file after a system restart. This userid
also receives guest virtual machine dumps produced by CP VMDUMP, if you
specify the destination as SYSTEM. If SYSDUMP is not specified, the userid
OPERATNS is used. If you plan to use IPCS, allow this operand to default to
OPERATNS or specify the IPCS userid.
Example:
The following SYSOPR macro designates the OP virtual machine as the system
operator and directs the system dumps to the CPSYS virtual machine.
SYSOPR SYSOPER=OP,SYSDUMP=CPSYS
246
VM/SP Planning Guide and Reference
SYSCOR Macro
Use the SYSCOR macro instruction to generate the internal control block called
the CORTABLE. The AP and MP operands specify whether VM/SP will try to
make use of an additional processor.
The name field must not be specified for the SYSCOR macro instruction.
The format of the SYSCOR macro is:
Name
Operation
SYSCOR
Operands
RMSIZE=~
xxxxxK
yyM
f
[, FREE=ffff]
[
,AP=l~~S
,MP= ~~~S
I]
~
[TRACE=nnn]
where:
RMSIZE={XXXXXK }
yyM
is the amount of real storage available for VM/SP. This value limits the
amount of real storage used by VM/SP if less than the total amount of real
storage available in the real machine. If the available real storage is less than
this value when VM/SP is initialized, a message indicating the amount of storage available is displayed at the operator's console.
The value, XXXXX, is a three to five-digit number that designates the amount of
real storage in terms of K bytes, where lK= 1024 bytes. This value may range
from 384K to 16384K. It must always be a multiple of 2.
The value, yy, is a one or two-digit number that designates the amount of storage in terms of M bytes, where IM=1024K bytes. This value may range from
1M to 16M.
Note: Do not specify a value much larger than the size of real storage, because
the generated core table uses a large amount of real storage.
FREE=ffff
is a one to four-digit riumber that specifies the number of fixed free storage
pages to be allocated at VM/SP initialization. This number must be greater
than three. The amount of storage represented must not. be greater than ether
25 % of the value specified for RMSIZE, or RMSIZE less the V =R area if generated.
The recommended initial value for ffff is one page for each virtual machine
logged on, based on the average number of virtual machine users.
If FREE is not specified, VM/SP allocates three pages for the first 256K of
real storage and one page for each additional64K thereafter not including the
V=R size, if any. In AP and MP modes, the default is increased by 25%.
Chapter 21. Preparing the CP System Control File (DMKSYS)
247
One method of determining if you need to increase the value of FREE (after
your initial sysgen) is to XEDIT your CPNUC MAP and locate the label
"DMKFRENP." Write down the hex location of DMKFRENP, get out of
XEDIT, and issue the command:
DCP hexloc.8
The first four bytes are the number of extends (in hex). The last four bytes are
the number of disextends. If the extends are greater than the disextends, you
should increase FREE by the difference.
AP1!~S }
YES specifies that processing is in attached processor mode if the attached
processor is available at system IPL.
NO specifies that processing is in uniprocessor mode regardless of the presence
of an attached processor.
MP={!~S
}
YES specifies that initialization processing occurs in multiprocessor mode.
NO specifies that initialization processing occurs in uniprocessor mode regardless of the presence of a second processor.
MP= YES and AP= YES parameters are mutually exclusive. A system generated for MP execution will run on an MP, AP, or UP system. However, it will
not function with maximum efficiency for AP or UP modes of operation. If
you code both AP= YES and MP= YES, the following MNOTE is issued:
"MP=YES AND AP=YES BOTH SPECIFIED; MP=YES ASSUMED"
Note: An additional 25 % of free storage is allocated in AP or MP mode. (See
FREE=.)
TRACE=nnn
is the decimal number of 4K pages to be used for the trace table. If the number
of pages specified on the TRACE operand is not larger than the default trace
table size provided by the system (one page for each 256K of real storage), the
default size will be used for the trace table.
Examples:
The first example defines real storage as 256K (262,144 bytes) and the second
example defines real storage as 1M (1,048,576 bytes).
SYSCOR
SYSCOR
248
VM/SP Planning Guide and Reference
RMSIZE=256K
RMSIZE=1M
SYSTIME Macro
Use the SYSTIME macro instruction to generate information needed to set the
hardware time of day (TOO) clock. The value stored in the TOO clock represents
time taken at Greenwich Mean Time, and must be corrected to local time whenever
it is examined. The system operator can alter the defined time value by using the
store clock function.
The name field must not be specified for the SYSTIME macro instruction.
The format of the SYSTIME macro is:
Name
Operation
Operands
SYSTIME
ZONE=h
[ZONE=O
]
ZONE=(h,m)
ZONE=(h,m,s)
ZONE= (h, , s )
[ ,LOC=EAST ]
, LOC=WEST
[ ,ID=GMT
,ID=xxx
J
where:
ZONE=O
ZONE=h
ZONE=(h,m)
ZONE=(h,m,s)
ZONE= (h, , s )
is the time zone difference from Greenwich Mean Time. If ZONE is not specified, a value of 0 hours (Greenwich Mean Time) is used.
The variable h is a number that represents hours. It can have a value from 0 to
13, but when coupled with the m and s fields, the total effective zone difference
must not exceed 13 hours.
The variable m is a number that represents minutes.
The variable s is a number that represents seconds.
LOC=EAST]
[ LOC=WEST
specifies whether the time zone difference is to be taken EAST or WEST of
Greenwich Mean Time. The default value for LOC is EAST. When the effective value of ZONE is 0, the setting of LOC is meaningless.
Chapter 21. Preparing the CP System Control File (DMKSYS)
249
ID=GMTJ
[ ID=xxx
is the name of the time zone. The default for ID is GMT. The variable xxx is a
three-character string.
Examples:
The following examples show how to code the SYSTIME macro for several different time zones.
SYSTIME
SYSTIME
SYSTIME
SYSTIME
SYSTIME
SYSTIME
SYSTIME
250
VM/SP Planning Guide and Reference
ZONE=5,LOC=WEST,ID=EST
ZONE=4,LOC=WEST,ID=EDT
ZONE=6,LOC=WEST,ID=CST
ZONE=7,LOC=WEST,ID=MST
ZONE=1,LOC=EAST,ID=SET
ZONE=1,LOC=EAST,ID=BST
ZONE=10,LOC=EAST,ID=EST
(Eastern Standard Time)
(Eastern Daylight Time)
(Central Standard Time)
(Mountain Standard Time)
(Standard European Time)
(British Summer Time)
(Australian Eastern Standard Time)
SYSMON Macro
The SYSMON macro is used to start daily automatic performance data collection
with the VM Monitor. The IBM Field Developed Program Virtual Machine Facility /370: Performance/Monitor Analysis Program is equipped with a front end
assembly language routine that contains the appropriate diagnose commands to
read the file and perform data reduction.
The format of the SYSMON macro is:
Name
Operation
SYSMON
Operands
[USERID=OPERATORJ
USERID=userid
[,CLASS=M
,CLASS=class
J
[,AUTO=NO ]
, AUTO=YES
[lENABLE=<PERFORMlUSERlDASTAP)
]
,ENABLE=(classa,classb,classc, ... )
[lTlME=<09:00 l 17:00)
,TIME=(h1:m1,h2:m2)
,TIME=ALL
,TIME=NONE
:J
*I
l LIMIT=(50000 l NOSTOP)
I,LIMIT=(limit,STOP)
I,LIMIT=(limit,NOSTOP)
I,LIMIT=(limit,SAMPLE)
*
*I
I
I
I
*
[,BUFFS=CEU default]
, BUFFS=n
where:
USERID=OPERATOR ]
[ USERID=userid
is the userid of the virtual machine that will receive the monitor spool file in its
virtual reader. The default is OPERATOR but any system directory entry may
be specified.
Chapter 21. Preparing the CP System Control File (DMKSYS)
251
]
CLASS=M
[ CLASS=class
specifies the spool file class to be generated to contain monitor data. Any class
(A through Z and 0 through 9) may be used but the default M is preferred
since the VMAP data reduction Field Developed Program is designed to reduce
only spool files of that class.
AUTO=NO ]
[ AUTO=YES
specifies whether or not automatic monitoring should take place according to
remaining SYSMON parameter specifications. The default, NO, requires you
to make a specific change to cause automatic monitoring. All other parameters
may be system default values, giving positive and useful monitoring results.
]
ENABLE= (PERFORM, USER,DASTAP)
[ ENABLE=(classa,classb,classc, ... )
specifies any combination of monitor classes of data collection. It is assumed
that the system analyst understands the use of various classes, overhead resulting from data collection, and relative magnitude of the corresponding data
reduction. The default specifies sampled data classes only and is considered the
least that can be specified for useful data reduction. The default classes are
sufficient for analysis of a system's load and performance profile with a view to
diagnosis of possible bottlenecks and for establishing long term growth
patterns.
TIME=(09:00,17:00) ]
TIME=(h1:m1,h2:m2)
TIME=ALL
[ TIME=NONE
specifies the time period in each day that automatic monitoring (performance
data collection) should take place. This parameter may indicate a start and
stop time in hours and minutes using a 24-hour clock. Continuous monitoring
(if ALL is specified), or no monitoring (if NONE is specified) occurs unless the
operator or system analyst overrides this specification with the MONITOR
command. If a system restart occurs during an automatic monitoring period,
the old spool file is closed out and a new one is started, according to the
SYSMON specifications. For useful data reduction, several hours of monitoring are suggested.
Note: This same closeout occurs at midnight if ALL is specified.
252
VM/SP Planning Guide and Reference
LIMIT= (50000, NOSTOP) ]
LIMIT=(limit,STOP)
LIMIT=(limit,NOSTOP)
[ LIMIT=(limit,SAMPLE)
specifies the maximum number of monitor record buffers that can be added to
the monitor spool file before it is closed, and whether or not monitoring should
be stopped when the limit is reached or the periodic closing of the monitor
spool file after a specified number of samples (also defined by the value of
LIMIT) have been collected. This parameter gives you more control over the
amount of spool space that can be used by the automatic monitoring facility. It
can also be used to create several small monitor spool files, rather than one
large file, and give the data reduction facility an opportunity to start processing
the morning's data while collecting the afternoon's data. 'limit' can be any decimal number between 10 and 50000. When determining the value for 'limit',
take into consideration the classes of data collection enabled, the size of the
associated records, and the sampling interval. Remember that each monitor
buffer contains approximately 4000 bytes of data space.
Specifying SAMPLE allows your analyst to define the rate at which spool files
will be produced. Since sampled data is collected at very precise intervals of
time, according to the value specified in the MONITOR INTERVAL command
(default 60 seconds), the spool file may be consistently and repeatedly closed.
Monitor spool files obtained in this manner contain performance data covering
consecutive, and equal intervals of time. This data contains the same number
of PERFORM, DASTAP, and, possibly, USER (if no users logged on or off)
records. This capability could form the basis of a real time performance analysis facility.
BUFFS=CPU default]
[ BUFFS=n
specifies the number of data collection buffers needed by the monitor to avoid
suspension incidents. Data collection suspension occurs when output to tape or
spool files cannot keep ahead of data collection, and an overrun condition
occurs. By increasing the number of monitor buffers, suspension incidents can
be reduced or eliminated. The default depends on the processor on which the
system is running. (See the VM / SP System Programmer's Guide for a
description of the MONITOR command.) If not satisfied with the defaults, you
may specify any number of buffers from 1 to 10.
Example:
SYSMON USERID=ANALYST,AUTO=YES,ENABLE=(PERFORM),
TIME=ALL,BUFFS=1
This example specifies automatic monitoring for 24 hours a day using only the
PERFORM class of data collection and one buffer. The spool file created is practically unlimited in size, ~aking the 50000 default and will be sent to the ANALYST
virtual machine's reader each midnight, at system restart, or shutdown. M is the
default spool file class.
Note: All of the above automatic monitoring specifications may be overridden by
the operator or system analyst using the MONITOR command.
Chapter 21. Preparing the CP System Control File (DMKSYS)
253
SYSJRL Macro
The SYSJRL macro is used to specify the inclusion of the journaling and/or password suppression facility.
The format of the SYSJRL macro is:
Name
Operation
Operands
SYSJRL
[ ,JOURNAL=NO ]
, JOURNAL=YES
[,STQUERY=NO ]
,STQUERY=YES
[ ,LOGUID=OPERATOR ]
, LOGUID=userid
[ ,LOGLMT= ( 2 , 3 , 4) ]
,LOGLMT=(x,y,z)
[ ,LNKUID=OPERATOR ]
,LNKUID=userid
[,LNKLMT=(2,5, 10) ]
,LNKLMT=(x,y,z)
[,PSUPRS=NO
., PSUPRS-YES
]
where:
,JOURNAL=NO ]
[ , JOURNAL=YES
indicates whether or not the journaling facility is to be operative in the system
being generated.
,STQUERY=NO ]
[ ,STQUERY=YES
indicates whether or not the ability to SET and QUERY the journaling function
should be a part of the system being generated. STQUERY=YES may be
specified only if JOURNAL = YES is also specified.
, LOGUID=OPERATOR]
[ ,LOGUID=userid
is the userid that should receive the indication that an invalid logon password
count has been reached or exceeded. If this userid is disconnected or logged
off, the operator will receive the message generated.
254
VM/SP Planning Guide and Reference
,LOGLMT={2 , 3 , 4)]
[ ,LOGLMT={x,y,z)
is the invalid LOGON/AUTOLOG password threshold specification. The value specified applies to a single userid for a single LOGON session. x is the value which, when reached or exceeded, causes a type 04 accounting record to be
generated for that and each following LOGON/ AUTOLOG containing an
invalid password. y is the value which, when reached or exceeded, causes a
message to be sent to the userid specified by LOGUID for that and each following LOGON/AUTOLOG containing an invalid password. z is the value
which, when reached, causes the LOGON/ AUTOLOG command to be disabled. A new VM logon screen will be displayed and a new logon sequence can
be started.
Note: z replaces the present fixed limit of 4 and may be any decimal number
from 1 to 255. x and y may be any decimal number from 0 to 255. 0 is a special case that indicates the applicable function should be bypassed. For example, if LOGLMT=(0,5,5) is specified, no accounting records are generated.
,LNKUID=OPERATOR]
[ ,LNKUID=userid
is the userid that should receive the indication that an invalid link password
count has been reached or exceeded. If this userid is disconnected or logged
off, the operator will receive the message generated.
,LNKLMT=(21S,10>]
[ ,LNKLMT=(x,y,z)
is the invalid LINK password threshold specification. The value specified
applies to a single userid for a single LOGON session. x is the value that, when
reached or exceeded, causes a 06 accounting record to be generated for that
and each following LINK containing an invalid password. y is the value that,
when reached or exceeded, causes a message to be sent to the userid specified
by LNKUID for that and each following LINK containing an invalid password.
z is the value that, when reached, causes the LINK command to be disabled for
the current LOGON session.
Note: z replaces the current fixed limit of 10 and may be any decimal number
from 1 to 255. x and y may be any decimal number from 0 to 255. 0 is a special case that indicates the applicable function to be bypassed. For example, if
LNKLMT=(2,0,10) is specified, no message is sent.
I
[
PSUPRS=NO ]
• ,PSUPRS=YES
indicates whether or not the facility that suppresses the password on the command line should be part of the system being generated.
Note: If PSUPRS=YES is specified for a 2741 terminal, passwords will be
typed upon a mask. Specifying PSUPRS= YES provides additional security for
your VM/SP installation.
Chapter 21. Preparing the CP System Control File (DMKSYS)
255
SYSACNT Macro
SYSACNT is a required system generation macro instruction used to specify spooling of accounting records.
The format of the SYSACNT macro is:
Name
label
Operation
SYSACNT
Operands
-
,...
USERID=~OPE~TOR~
user.l.d
,OUTPUT= ~PUNCH ~
READER
,CLASS=~f
class
~
,LIMIT= ~Q
~
nnnnn
...
-
where:
label
is any desired label.
USERID={ OPE~TOR }
user.l.d
is the virtual machine identification to which all files are spooled. OPERATOR
is the default userid.
OUTPUT={ PUNCH }
READER
is the type of spool file to be created. PUNCH is the default type.
CLASS={f
}
class
is the class of the spool file to be created. A-Z and 0-9 can be specified. Class
C is the default.
LIMIT={Q
}
nnnnn
is the number of records to be accumulated before the file is closed and made
available to the virtual machine. nnnnn is up to 5 decimal digits from 0 to
32,767. 0, the default, indicates that the file is not to be closed automatically.
Accounting records are accumulated in a spool file identified by the USERIDand
CLASS parameters until either the number of records specified in the LIMIT
parameter is reached or until the ACNT command is issued with the CLOSE operand. At that time, the records are sent to the virtual punch or reader, as specified
in the OUTPUT parameter.
If accounting records are stored in reader files in your virtual machine, they should
be processed periodically to avoid accumulating and tying up system resources.
Note: The accounting records can be moved to tape via the SPTAPE command fot
later processing.
256
VM/SP Planning Guide and Reference
SYSFORM Macro
Use the SYSFORM macro instruction to specify:
•
A list of user forms with their corresponding operator forms. Operator forms
can also be specified as NARROW, so that a narrow (94-character) separator
page is printed.
•
Default user forms for printer, punch, and console. (The default operator
forms are obtained from the list of user/operator forms.) These defaults
apply:
When creating a virtual printer, punch, or console spool file, unless you
have overridden the default with a SPOOL or CLOSE command.
When the operator issues a START command for a printer or punch without specifying a form, and this is the first START command since cold
starting VM/SP.
The format of the SYSFORM macro is:
Name
Operation
SYSFORM
Operands
[(userform,operform [ ,NARROW]
[,DEFPRT=userform]
[,DEFPUN=userform]
[,DEFCON=userform]
)
...
]
where:
userform
specifies the one-to-eight character user form name. Use this form in CP
SPOOL, CLOSE, CHANGE, PURGE, ORDER, QUERY, and TRANSFER
commands.
operform
specifies the one-to-eight character name for the corresponding operator form.
If no userform or operform pairs are specified, no form list is generated. In this
case, no distinction is made between user forms and operator forms.
NARROW
specifies printing on narrow (94-character) paper. Separator information will
not print beyond this width.
DEFPRT
specifies the default user (and implicitly, operator) forms when creating virtual
printer spool files, or when starting the real printer.
If DEFPRT is not specified, the default is DEFPRT=STANDARD.
DEFPUN
specifies the default user (and implicitly, operator) fomis when creating virtual
punch spool files, or when starting the real punch.
If DEFPUN is not specified, the default is DEFPUN=STANDARD.
Chapter 21. Preparing the CP System Control File (DMKSYS)
257
DEFCON
specifies the default user (and implicitly, operator) forms when creating virtual
console spool files.
If DEFCON is not specified, the default is DEFCON = STANDARD.
Examples:
1. Default case.
SYSFORM
No user/operator form list, therefore no distinction between user forms and
operator forms.
Default forms are STANDARD for printer, punch, and console.
2. Defaults specified.
SYSFORM DEFPRT= VANILLA,DEFPUN= WHITE
No user/operator form list, therefore no distinction between user forms and
operator forms.
Default forms are VANILLA for the printer, WHITE for the punch, and
STANDARD for the console.
3.
User/operator form list.
SYSFORM (LISTING,QN-8-14),
(DOCUMENT,TN-6-8~NARROW),
(OUTPUT,PN-6-14),
DEFPRT=OUTPUT,DEFCON=DOCUMENT
User form LISTING corresponds to operator form QN-8-14.
You issue the command SPOOL PRINTER FORM LISTING, and the operator sees form QN-8-14. Likewise, user form DOCUMENT corresponds to the
narrow operator form TN-6-8, and OUTPUT corresponds to PN-6-14. All
other forms have the user form equal to the operator form.
OUTPUT/PN-6-14 is the default form for the printer. DOCUMENT/TN-6-8
is the default form for console spool files. STANDARD is the default for the
punch.
258
VM/SP Planning Guide and Reference
x
x
x
SYSPCLAS Macro
Use the SYSPCLAS macro instructio~ to classify printed output with a classification title. This title is printed on the output separator page, and optionally at the
top or bottom of each page of output.
You can specify a different classification title for each output class (A-Z and 0-9),
providing up to 36 different classifications.
The macro specifies a list of class/title pairs. The TOP or BOTTOM option can be
specified for any pair. The TOP option specifies that this title is to be printed at
the top of all pages of output, not just the separator page. The BOTTOM option
prints the title at the bottom of all output pages.
The format of the SYSPCLAS macro is:
Name
Operation
SYSPCLAS
Operands
[ (c, 'title' [ ,TOP
]
[ ,BOTTOM]
)
...
]
where:
c
is a one-character spool file class. It must be alphameric.
title
is a classification title for this class. It may be up to 46 characters long.
The title may contain any characters. It must be enclosed in quotes. Quotes
within the title are coded as two consecutive quotes, and ampersands are coded
as two consecutive ampersands.
TOP
specifies that this title is to be printed both on the separator page, and at the
top of each page of output.
BOTTOM
specifies that this title be printed both on the separator page, and at the bottom
of each page of output.
See "Usage Notes" for more information.
Examples:
1. No classifications desired.
SYSPCLAS
No classification titles are generated.
Chapter 21. Preparing the CP System Control File (DMKSYS)
259
2.
Classifications generated.
SYSPCLAS (R,'CUSTOMER CONFIDENTIAL'),
(N,'COMPANY NAME' ,TOP)
Class R output is printed with CUSTOMER CONFIDENTIAL on the separator page. Class N output has COMPANY NAME on the separator page, and
at the top of each page of output.
Usage Notes:
1.
The SYSPCLAS macro replaces previous support for class X files in module
DMKBOX.
2. The title line is inserted at the top or bottom of each page. To do this, CP
inserts a CCW to print one space, followed by the title line before or after each
"skip to channell" CCW issued by the guest operating system. There are
several things to consider about this:
260
a.
The titles are inserted as the file is being created. If the file is later
changed to a different class, the titles 'in the file are not changed. However,
the title on the separator page always reflects the true class of the file.
b.
Inserting the title on the output page adds a line of output to the printed
page. If the guest application is counting lines, its count will be incorrect.
This can result in alternating output and blank pages.
c.
If the guest doesn't use "skip to channell," the title lines are never
printed.
d.
If the guest doesn't issue "skip to channel I" at the end of the file, and the
BOTTOM option is being used, the last page will not have a classification
title on it. Usage of the TOP option keeps this from happening.
VM/SP Planning Guide and Reference
SYSID Macro
The SYSID macro statement allows you to identify a system with an
eight-character identification, which is printed on the output separator page.
The processor ID is specified with a model number and a serial number. If you
have more than one VM/SP processor, a list of system ID's with corresponding
processor model and serial numbers can be specified. When VM/SP is initialized
via IPL, the initialized processor is matched with an entry in the list of system ID's,
thus identifying the local system ID. The processor ID of the IPLed processor is
obtained with the STORE CPUID instruction. If no match is found, a default system ID is assumed.
The format of the SYSID macro is:
Name
Operation
SYSID
Operands
[(systemid,model,serial) , ... ]
[ ,DEFAULT=defid]
where:
systemid
specifies the one-to eight-character system ID that identifies a uniprocessor system.
model
designates a three-to four-digit number that specifies the processor model
number (for example 158,3031, or 4341) for a multiprocessor system.
serial
is a five- or six-digit number that specifies the processor serial number corresponding with the system ID. An AP user should use the serial number and
model number of the main (IPL) processor in the SYSID statement. For an
MP user, use the serial and model number of both processors in the SYSID
macro.
DEFAULT=defid
designates the one- to eight-character default system ID. This ID is selected if
the processor is not found in the list, or if there is no list.
Examples:
1.
Default case.
SYSID
No system ID is printed on the separator page.
2.
Single processor user.
SYSID DEFAULT=CUSTOMER
Gives this VM/SP system the ID "CUSTOMER." This ID will be printed on
the separator page.
Chapter 21. Preparing the CP System Control File (DMKSYS)
261
3. Multiple processor user.
SYSID (CUSTSYS1,158,13289),
(CUSTSYS2,4341,23145),DEFAULT=OTHERSYS
If this system is IPLed on the 370/158 serial number 13289, the system ID is
CUSTSYSI. If it is IPLed on the 434,1 serial number 23145, the system ID is
CUSTSYS2. If it is IPLed on any other system, the system ID is OTHERSYS.
262
VM/SP: Planning Guide and Reference
x
SYSORD Macro
Use the SYSORD macro statement to specify the order in which preferred and/or
nonpreferred paging and spooling devices are searched for available pages to satisfy paging/spooling operations. Different search orders may be specified for preferred and nonpreferred devices. SYSORD is a required macro statement. It must
be included in DMKSYS prior to the SYSLOCS macro statement.
I
The format of the SYSORD macro is:
Name
Operation
SYSORD
Operands
[SYSFH=
(devtype[,devtype, ... [, (devtype,devtype, ... )]])]
[SYSMH=
(devtype[,devtype, ... [, (devtype,devtype, ... )]])]
[SYSTEMP=(devtype[,devtype, ... [, (devtype,devtype, ... )]])]
where:
devtype
is a supported DASD type
SYSFH=
designates the priority order for searching device types that have preferred
fixed-head paging (PAGE) cylinders or extents defined. A specified device
type indicates a single device or several devices of the same device type in a
chain. Supported fixed-head device types (in order of decreasing performance)
are: 2305, 3350, 3330, and 3340. A device type may appear only once within
this operand.
Note: The 3330 specification for SYSFH is included only for fixed-head 3350s
running in 3330 compatibility mode.
SYSMH=
designates the priority order for searching device types that have preferred
moveable-head paging (PAGE) cylinders or extents defined. A specified
device type indicates a single moveable-head device or several moveable-head
devices of the same device type in a chain. Supported moveable-head device
types (in order of decreasing performance) are: 3380, 3375, 3370, 3310, 3350,
3330,3340, and 2314. A device type may appear only once within this operand.
SYSTEMP=
designates the priority order for searching device types that have nonpreferred
(TEMP) cylinders or extents defined. TEMP space is used for overflow paging
operations and all spooling operations. A specified device type indicates a single fixed or moveable-head device or several devices of the same device type in
a chain. Supported device types (in order of decreasing performance) are:
2305, 3380, 3375, 3370, 3310, 3350, 3330, 3340, and 2314. A device type
may appear only once within this operand.
Chapter 21. Preparing the CP System Control File (DMKSYS)
263
The brackets in the format of the SYSORD MACRO represent options in specifying the operands. For each operand, the three options indicated are:
1.
The option to specify the operand. If specified, at least one device type is
required.
Example:
SYSFH= (devtype)
SYSMH= (devtype)
SYSTEMP= (devtype)
2.
The option to specify more than one device type.
Example:
SYSFH= (devtype,devtype, ... )
SYSMH= (devtype,devtype, ... )
SYSTEMP= (devtype,devtype, ... )
3.
The option to specify for devtype, a list of device types indicating that the
device types in the inner parentheses are to have equal priority with each other.
Example:
SYSFH=(devtype,(devtype,devtype, ... ), ... )
SYSMH= (devtype, (devtype,devtype, ... ), ... )
SYSTEMP=(devtype,(devtype,devtype, ... ), ... )
A request for a page of external page space is satisfied by allocating space on a preferred paging cylinder or extent, provided that one exists on the system and that it
has a page slot available. You specify preferred and nonpreferred paging space by
using the PAGE and TEMP operands of the CP Format/Allocate service program.
Within the class of CP-owned volumes with preferred space, pages are first allocated from volumes with fixed-head cylinders or extents in the order specified by
the SYSFH operand. (If SYSFH is not specified, the default order is used.) If no
fixed-head space is available, then pages are allocated from volumes with
moveable-head cylinders or extents in the order specified by the SYSMH operand.
(If SYSMH is not specified, the default order is used.) Finally, if no preferred
space is available, pages are allocated from volumes with nonpreferred space in the
order specified by the SYSTEMP operand. (If SYSTEMP is not is specified, the
default order is used.)
Spooling space is not allocated from preferred space. Spooling space is allocated
from volumes with nonpreferred space in the order specified by the SYSTEMP
operand. (If SYSTEMP is not specified, the default order is used.)
A rotary paging scheme is used to evenly distribute external DASD pages across all
volumes of a specific device type and to allow concurrent paging operations. For
each SYSFH/SYSMH/SYSTEMP operand, a device type order specification of
(devtype,devtype,devtype, ... ) indicates a series of unique device types, where each
device type may indicate a single device or a chain of devices of the same type. If a
chain exists, pages are allocated on all devices within the chain on a rotating basis.
When all available pages on the device chain are used, the next specified device
type is examined for available pages. Allocation of DASD pages occurs in this
264
VM/SP Planning Guide and Reference
manner until all device types specified within the parentheses are used. A device
type order specification of (devtype,devtype, (devtype,devtype, ... ) ,... ) indicates that
the device types in the inner parentheses are to have equal priority with each other.
The same rotary scheme is used for the allocation of spooling space from nonpreferred devices.
The following example shows the sequence in which paging or spooling space
would be allocated from all CP-owned volumes having cylinders or extents defined
as specified in the SYSORD macro below. The example is meant to illustrate the
allocation technique, not necessarily the desirable allocation of paging or spooling
space.
SYSORD SYSMH=(3380,3350) SYSTEMP=((3370,3310),3330)
Preferred
for paging
Preferred
for paging
Preferred
for paging
Nonpreferred
Nonpreferred
~ ~ ~ ~ ~
VOL1
VOL3
VOL5
VOL7
VOL9
Preferred
for paging
Preferred
for paging
Nonpreferred
Nonpreferred
Nonpreferred
~ ~~ ~
VOL2
VOL4
VOL6
VOL8
Using the previous example, paging cylinders or extents would be allocated in the
following sequence:
1.
On an alternating basis on VOLI and VOL2 until all fixed-head PAGE space
is used on these volumes.
2.
On VOLS until all fixed-head PAGE space is used on that volume.
3.
On an alternating basis on VOL3 and VOL4 until all moveable-head PAGE
space is used on these volumes.
4.
On VOLS until all moveable-head PAGE space is used on that volume.
S.
On an alternating 'basis on VOL6, VOL7, and VOL8 until all TEMP space is
used on these volumes.
6. On an alternating basis on VOL9 and VOLIO until all TEMP space is used on
these volumes.
Spooling cylinders or extents would be allocated in the following sequence:
1. On an alternating basis on VOL6, VOL7, and VOL8 until all TEMP space is
used on these volumes.
2.
On an alternating basis on VOL9 and VOLIO until all TEMP space is used on
these volumes.
Chapter 21. Preparing the CP System Control File (DMKSYS)
265
SYSORD is a required macro statement. Though the statement is required, the
operands are optional. If SYSORD is specified without operands, the following
default priority orders apply:
SYSFH= (2305, 3350, 3330, 3340)
SYSMH= (3380, 3375, 3370, 3310, 3350, 3330, 3340, 2314)
SYSTEMP=(2305, 3380, 3375, 3370, 3310, 3350, 3330, 3340, 2314)
A device type may appear only once within each SYSFH/SYSMH/SYSTEMP
statement. If duplicate device types are specified within an operand, the following
MNOTE is issued:
'SAME DEVICE TYPE SPECIFIED MULTIPLE TIMES'
You should eliminate the multiple specification and reassemble DMKSYS.
Specifying an operand other than SYSFH/SYSMH/SYSTEMP produces the following:
'KEYWORD PARAMETER 'parameter' UNDEFINED IN MACRO DEFINITION'
You have specified an invalid keyword. Only SYSFH, SYSMH, or SYSTEMP are
allowed.
Specifying an invalid device type within any operand generates one of these
MNOTES:
'INVALID DEVICE TYPE FOR SYSFH'
'INVALID DEVICE TYPE FOR SYSMH'
'INVALID DEVICE TYPE FOR SYSTEMP'
Missing parentheses or parentheses without following operands generate the
MNOTE:
'POSITIONAL OR EMPTY PARMS NOT ALLOWED'
266
VM/SP Planning Guide and Reference
SYSMIH Macro
Use the SYSMIH macro instruction to define the time interval desired for missing
interruption monitoring. I/O activity is monitored for the following devices:
•
•
•
•
I.
Direct access storage devices
Graphic devices
Tape deVices
l1nitrecorddevices
Miscellaneous devices
If you specify zero for a device group, monitoring is set off for that group.
Do not specify the name field for the SYSMIH macro instruction.
The format of the SYSMIH macro is:
Name
Operation
SYSMIH
Operands
[
DASD='~r!~ :; ~ ]
[,TAPE=~:~ ~~ ~ ]
[,GRAF= ~~~ !~ ~
[, UR
]
llQQtJ
=~ mm:ss
[,MISC=~~~~~t ]
where:
DASD={ 0: 1 5 }
nm:ss
specifies the time interval value for count-key-data direct access storage devices
(CLASDASD) and fixed block architecture devices (CLASFBA). You can
specify a maximum value of 99 for mm (minutes) and a maximum value of 59
for ss (seconds). If you do not specify a value for this class, the time interval is
set to the default value, 15 seconds.
GRAF={ 0: 30 }
mm:ss
specifies the time interval value for graphic devices (CLASGRAF). You can
specify a maximum value of 99 for mm (minutes) and a maximum value of 59
for ss (seconds). If you do not specify a value for this class, the time interval is
set to the default value, 30 seconds.
TAPE={10: 00 }
mm:ss
specifies the time interval value for tape devices (CLASTAPE). You can specify a maximum value of 99 for mm (minutes) and a maximum value of 59 for ss
(seconds). If you do not specify a value for this class, the time interval is set to
the default value, 10 minutes.
UR={ 1 :OO}
mm:ss
specifies the time interval value for unit record input devices (CLASlJRI) and
unit record output devices (CLASURO). You can specify a maximum value of
Chapter 21. Preparing the CP System Control File (DMKSYS)
267
99 for mm (minutes) and a maximum value of 59 for ss (seconds). If you do
not specify a value for this class, the time interval is set to the default value, 1
minute.
MISC={12:00}
mm:ss
specifies the time interval value used for miscellaneous devices. Miscellaneous
devices include MSS devices, CLASGRAF TYP328x and TYP1053, and
CLASURO TYP3800 and TYP3289E printers. MSS devices include
CLASSPEC TYP3851 and CLASDASD FEATURE=SYSVIRT or
FEATURE = VIRTUAL. You can specify a maximum value of 99 for mm
(minutes) and a maximum value of 59 for ss (seconds). If you do not specify a
value for this class, the time interval is set to the default value, 12 minutes.
Notes:
1. If you do not specify a value for a device class, CP uses the default time interval.
2. If you specify zero for a device group, monitoring is set off for that group.
Specify zero for any device that you do not use.
3.
Use the SET MITIME command to change the time intervals of device classes.
Use the QUERY MITIME command to determine the time intervals in effect.
4. If you specify a time interval for a device class below its default value, be careful not to shorten the time interval too much since this may cause unnecessary
missing interruption handler processing for devices that are functioning properly.
5.
If you specify more that one time interval for a device class, the last value
coded is used.
6.
If you remove module DMKDID from the load list, and later issue the SET
MITIME or QUERY MITIME command, CP issues a message that missing
interruption monitoring is not available.
7. If you specify an invalid time value in the SYSMIH statement, the time value is
set to the default, return code 4 is generated, and the following MNOTE is
issued:
INVALID TIME VALUE SPECIFIED FOR class - TIME SET TO time
Here, class indicates the device class that has the invalid time value and time
indicates the default value for this class.
8. If a 3800 is installed, the time interval for unit record devices should be
increased to 5 minutes because of the warm-up time required by the printer.
268
VM/SP Planning Guide and Reference
Example:
This example illustrates the use of the SYSMIH macro instruction to:
•
•
•
•
I.
Set a 15 second time interval for direct access storage devices
Set a 20 second time interval for graphic devices
Disable I/O monitoring for tape devices
Set a one minute time interval for unit record processing
Disable I/O monitoring for Miscellaneous devices
SYSMIH GRAF=OO:20,TAPE=OO:OO,MISC=OO:OO
Chapter 21. Preparing the CP System Control File (DMKSYS)
269
SYSLOCS Macro
The SYSLOCS macro instruction is a required macro used to generate internal
pointer variables. This must be the last macro in the DMKSYS file.
The name field must not be specified for the SYSLOCS macro instruction. No
operands are required for the SYSLOC;S macro. If one is specified, it is ignored.
The format of the SYSLOCS macro is:
I
Operation
SYSLOCS
270
VM/SP Planning Guide and Reference
I Operands
Chapter 22. Additional System Definition FOes
The Forms Control Buffer Load (DMKFCB)
The DMKFCB module is supplied with the product tape. This module defines a
3211,3203-4,3203-5,3262-1, 3262-5, 3262-11, 3289 Model 4, or 4245 Printer
forms control buffer image. There are two names provided for an FCB image.
FCB 1 controls printing at 6 lines per inch, 66 lines per page and has the following
specifications:
Line
Represented
1
3
5
7
9
11
13
15
19
21
23
64
Channel
Skip
Specification
1
2
3
4
5
6
7
8
10
11
12
9
FCB8 controls printing at 8 lines per inch, 68 lines per page and has the following
specifications:
Line
Represented
1
4
8
12
16
20
24
28
32
36
63
66
Channel
Skip
Specification
1
2
3
4
5
6
7
8
10
11
12
9
If you wish to alter the supplied buffer load, see VM/ SP System Programmer's
Guide for directions.
Chapter 22. Additional System Definition Files
271
The Universal Character Set and Font Offset Buffer
The DMKUCS, DMKUCB, DMKUCC, DMKPIA, and DMKPIB modules are
supplied with the product tape. These modules correspond to the following printer
types:
Printer Type
1403
3211
3203
3289
3262
Module Name
DMKUCS
DMKUCB
DMKUCC
DMKPIA
DMKPIB
If you wish to change the supplied buffer load for a particular device, see the corresponding module's prologue.
272
VM/SP Planning Guide and Reference
Appendixes
A.
Licensed Programs and Integrated Emulators
B.
Configuration Aid
C.
Compatible Devices
D.
VM/SP Restrictions
Appendixes
273
274
VM/SP Planning Guide and Reference
Appendix A. Licensed Programs and Integrated Emulators
The Conversational Monitor System (CMS), and the Control Program (CP) are
distributed as components of VM/SP. Certain other facilities mentioned in this
publication are not part of VM/SP, but can be separately ordered from mM.
These include: mM System/360 and System/370 operating systems, mM language processors and other mM Program Products, mM Installed User Programs,
and IBM Field Developed Programs. For more information, contact your IBM representative.
VM/370 Assembler
The VM/370 Assembler is distributed as a part of the VM/SP system and is
required for installation and further support of the system. All necessary installation and support macros are provided in CMS libraries.
Licensed Programs
The following is a list of mM Licensed Programs and their respective program
numbers that VM/SP users have found useful.
Program·Products are listed first in each area, followed by Program Offerings
(Field Developed Programs(FDPs) and Installed User Programs(IUPs», and Programming Requests for Price Quotation(PRPQs).
More information may be found in the IBM DPD Software Directory, form number
GB21-9949.
General Business Applications:
Interactive Instructional Authoring System (lIAS)
Interactive Instructional Presentation System (lIPS)
General Purpose Simulation System V OS (GPSS-V)
Alpha Search Inquiry System (ASIS)
Planning Control and Decision Evaluation (PLAN CODE/I)
5668-001
5668-012
5734-XS2
5736-N14
5740-XX8
A Departmental Reporting System II (ADRS-II)
Applicant Tracking System
APL Data Interface - Version II (APL/DI-II)
Alpha Search Inquiry System Online Update
Braille Utilities
Financial Planning System II (FPS-II)
5796-PLN
5796-PLT
5796-PNG
5798-CFJ
5798-CRZ
5798-DCN
Scientific and Engineering Applications:
MATH/BASIC
General Purpose Simulation System V OS (GPSS-V)
Continuous System Modeling Program III (CSMP-III)
7534-XM8
5734-XS2
5734-XS9
Storage and Information Retrieval System (STAIRS/ CMS)
APL Forcasting and Time Series Analysis
APL Statistical Library
General Purpose Simulation System VSAPL (GPSS-APL)
VSAPL Advanced Statistics Library (STATLIB2)
List Processor 370 (LISP /370)
5785-CAH
5796-PFX
5796-PHW
5796-PJG
5796-PJT
5796-PKL
Appendix A. Licensed Programs and Integrated Emulators
275
APL Multivariate Time Series Analysis
APL Workspace Structure Analyzer
SOFTCOPY - A CADAM drawing viewer
PASCAL/VS Compiler
3277 Graphics Attachment Plotter Tablet
5796-PLX
5796-PNB
5796-PNP
5796-PNQ
5798-DCE
Project Management:
Project Evaluation and Control System (PEACS)
Automated Project Planning and Evaluation (APPLES)
5785-EAE
5796-AZR
Application Development:
System Productivity Facility (SPF)
COBOL Interactive Debug
Interactive Productivity Facility (IPF)
Display Management System/370 (DMS/370)
Development Management System/DPCX (DMS/DPCX)
Display Management System/CMS (DMS/CMS)
Entry Level Interactive Application System I (ELIAS-I/VM)
5668-009
5734-CB4
5748-MSl
5748-XC3
5748-XC4
5748-XXB
5748-XXK
Virtual Spooled Reader Display / CMS
Automated Project Planning and Evaluation (APPLES)
Query By Example (QBE)
Structured Programming Macros
VM/CMS Library and SPMOL-II Simulation
Application Enabling Facility (AEF)
5796-AYK
5796-AZR
5796-PKT
5798-CLF
5798-CYA
5798-DBF
Systems and Installation Management:
VM/lnteractive Problem Control System OPCS)
5748-SAl
Automated Project Planning and Evaluation (APPLES)
VS Memory Analysis (VS/REPCAK)
VM/ CMS Performance Monitor Analysis (VMAP)
5796-AZR
5796-PDZ
5798-CPX
Auditor and Security Support Aids:
Display Management System/370 (DMS/370)
VM Directory Maintenance (DIRMAINT)
Display Management System/CMS (DMS/CMS)
VM Interactive File Sharing (VM/IFS)
5748-XC3
5748-XE4
5748-XXB
5748-XXC
JES2 Informational Retrieval System for CMS
APL Statistical Library for VSAPL
APL Decision Table Processor and Code Generator
VSAPL Advanced Statistics Library
A Departmental Reporting System II (ADRS-II)
Source Compare Audit Utility (SUPER-C)
APL Data Interface II (APL/DI-II)
5796-AYD
5796-PHW
5796-PJB
5796-PJT
5796-PLN
5796-PLZ
5796-PNG
Text and Office Systems Applications:
Graphics Attachment Support
Document Composition Facility (DCF)
276
VM/SP Planning Guide and Reference
5799-AXX
5748-XX9"
Storage and Informational Retrieval System (STAIRS/CMS)
Document Composition Facility for 6670
Professional Office System (PROFS)
5i85-CAH
5798-DBR
5799-BEX
Graphics Applications:
Digital Interactive Graphics Interpretive Mapping
5668-959
5668-978
5748-XXH
Interactive Circuit Design
SOFTCOPY - A CADAM Drawing Viewer
3277 Graphics Attachment Storage Tube
3277 Graphics Attachment Plotter Tablet
3279 Business Graphics
3277 APL Graphics Attachment Support
3277 Graphics Attachment Support
Interactive Geo-Facilities Graphics (IGGS)
5796-PLR
5796-PNP
5798-DAG
5798-DCE
5798-DEB
5799-AXW
5799-AXX
5799-AYB
I GAM/SP
Graphic Data Display Manager (GDDM)
Interactive and Personal Computing:
Interactive Instructional Authoring System (lIAS)
Interactive Instructional Presentation System (lIPS)
Stat/BASIC
Business Analysis/BASIC
Math/BASIC
Planning Control and Decision Evaluation (PLANCODE/I)
VS/BASIC
5668-011
5668-012
5734-XA3
5734-XMB
5734-XM8
5740-XX8
5748-XX1
McGill University System for Interactive Computing (MUSIC)
Applicant Tracking System
5796-ATL
5796-PLT
APL Support and Applications:
A Programming Language (VSAPL)
5748-AP1
APL Continuous System Modeling (CSMP)
APL System Extensions
APL Forcasting and Time Series Analysis
APL Function Editor for VSAPL
APL Statistical Library
APL Decision Table Processor
General Purpose Simulation System VSAPL (GPSS-APL)
VSAPL Advanced Statistics Library (STATLIB2)
APL Interactive Training Course
General Cross Assembler Generator
APL/DI File Create using PL/I
IMS APL Data Link for VM/ CMS
A Departmental Reporting System II (ADRS-II)
APL Handbook of Technical Workspace
Interactive Circuit Design
APL Multivariate Time Series Analysis
Extended Editor and Full Screen Manager
APL Workspace Structure Analyzer
APL Data Interface Version II (APLDI-II)
APL Data Language
5785-KAE
5796-AZT
5796-PFX
5796-PGY
5796-PHW
5796-PIB
5796-PIG
5796-PIT
5796-PIW
5796-PKD
5796-PKP
5796-PLE
5796-PLN
5796-PLP
5796-PLR
5796-PLX
5796-PLY
5796-PNB
5796-PNG
5798-CHR
Appendix A. Licensed Programs and Integrated Emulators
277
3277 Graphics Attachment Plotter Tablet
Financial Planning System II (FPS-II)
VSAPL Variable Conversion Processor
3277 APL Graphics Attachment Support
5798-DCE
5798-DCN
5798-DEH
5799-AXW
Query Programs and Support:
Query by Example (QBE)
A Departmental Reporting System II (ADRS-II)
APL Data Interface Version II (APLDI-II)
5796-PKT
5796-PLN
5796-PNG
DOS/VS, DOS/VSE SCp, Compilers, Utilities, and Aids:
DOS PL/I Optimizing Compiler and Library
DOS COBOL Compiler and Library
DOS RPG II
DOS/VS Sort/Merge Version 2
5736-PL3
5736-CBl
5746-RGl
5746-SM2
OS/VS SCP, Compilers, Utilities, and Aids:
OS Assembler H
COBOL Interactive Debug
OS FORTRAN IV G
OS FORTRAN IV H Extended
OS FORTRAN IV Library Mod II
OS PL/I Checkout Compiler
OS PL/I Optimizing Compiler and Library
OS/VS COBOL Compiler and Library
VS FORTRAN Compiler and Library
FORTRAN Conversion Aid
PL/I Language Construction Processor
PASCAL/VS
Structured Programming Macros
FORTRAN Utilities for VM/370
5734-ASl
5734-CB4
5734-F02
5734-F03
5734-LM3
5734-PL2
5734-PL3
5740-CBl
5748-F03
5796-PFG
5796-PLL
5796-PNQ
5798-CLF
5798-DFH
MVS SCP, Compilers, Utilities, and Aids:
FORTRAN Interactive Debug
5734-F05
VS Memory Anaylsis (VS)
5796-PDZ
VM SCP, Aids, Utilities:
System Productivity Facility
I GAM/SP
FORTRAN Interactive Debug
VM/VTAM Communication Network Application (VM/VCNA)
EP/VS for OS/VS and VM/370
VSE/Virtual Storage Access Method (VSE/VSAM)
DOS/VS Sort/Merge Version 2
Device Support Facility (DSF)
VS FORTRAN Compiler and Library
Interactive Productivity Facility
VM Pass Through Facility (PVM)
VM/Interactive Problem Control System (VM/IPCS)
VM/Directory Maintenance (DIRMAINT)
278
VM/SP Planning Guide and Reference
5668-009
5668-978
5734-F05
5734-RC5
5744-ANl
5746-AM2
5746-SM2
5747-DSl
5748-F03
5748-MSl
5748-RCl
5748-SAl
5748-XE4
Remote Spooling Communication System (RSCS)
Display Management System/CMS (DMS/CMS)
VM Interactive File Sharing (VM/IFS)
Graphic Data Display Manager (GDDM)
Entry Level Interactive Application System I (ELIAS-I/VM)
Document Composition Facility (SCRIPT/VS)
VM+DOS/VSE System IPO/E DB/DC (SIPO/E)
VM+DOS/VSE System IPO/E DC (SIPO/E)
VM + DOS/VSE System IPO /E Batch/Interactive (SIPO /E)
5748-XPI
5748-XXB
5748-XXC
5748-XXH
5748-XXK
5748-XX9
5750-AAE
5750-AAF
5750-AAJ
Storage and Information Retrieval System (STAIRS/CMS)
CMS Host Development, Testing 8100 COBOL
JES2 Information Retrieval System for CMS
Virtual Spooled Reader Display / CMS
APL System Extensions
Assembler H CMS Interface
FORTRAN Conversion Aid
Batch Monitor for VM/ CMS
List Processor/370 (LISP /370)
Query by Example (QBE)
IMS APL Data Link for VM/ CMS
Source Compare Audit Utility (SUPER-C)
VM Real Time Monitor (SMART)
Teleprocessing Virtual Machine (TPVM)
Pascal/VS Compiler
VM Diskette Copy
Virtual Librarian
CMS Sort for VM/CMS plus extensions
VM Performance Monitor Analysis (VMAP)
VM/CMS Library and SPMOL-II Simulator
Application Enabling Facility
Airline Control Program Testing in VM
Professional Office System (PROFS)
5785-CAH
5785-DCG
5796-AYD
5796-AYK.
5796-AZT
5796-PEJ
5796-PFG
5796-PGZ
5796-PKL
5796-PKT
5796-PLE
5796-PLZ
5796-PNA
5796-PNC
5796-PNQ
5796-PNT
5796-PNZ
5798-BDW
5798-CPX
5798-CYA
5798-DBF
5798-DEP
5799-BEX
Appendix A. Licensed Programs and Integrated Emulators
279
Integrated Emulators
Emulator-dependent programs (except for DOS emulation under OS or OS/VS)
that run on a particular processor equipped with the appropriate compatibility features can run on that processor in DOS or OS virtual machines under VM/SP.
Figure 25 shows, by processor model number, which integrated emulators can run
under VM/SP and the compatibility feature numbers (#xxxx) that are required.
No changes are required to the emulators, to DOS or OS, or to VM/SP to allow
emulator-dependent programs to run in virtual machines.
On the System/370 Model 158 only, the virtual machine assist feature cannot
operate concurrently with the 7070/7074 compatibility feature (#7117).
In an Attached Processor (AP) system, a virtual machine can use the SET AFFINITY command to make use of an emulator installed on only one of the processors.
The Directory option for Affinity may be used instead, with similar results.
8/360
Processor
Model
Model
135,135-3,138
145,145-3,148
15511,158
165 II
168
4331
#7520
20
1401
1440
1460
1410
7010
1401
1440
1460
#4457
#4457
#4458
#3950
#3950
Figure 25. Integrated Emulators that Run under VM/SP
280
VM/SP Planning Guide and Reference
7070
7074
7080
709
7090
7094
709411
#7117
#7117
#7127
#7118
#7128
#7119
#7129
Appendix B. Configuration Aid
Appendix B lists the devices and control units that can be specified in a VM/SP
system generation, grouped by use. The maximum number of devices that can be
specified in the FEATURE= operand of the RCTLUNIT macro is listed, along
with whether or not the control units can operate on a shared sub channel.
Listed are the devices that can be attached to each control unit, and 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. For example, the chart of tape devices indicates that a 2401,
2402, or 2420 can be attached to a 2803 or 2804 control unit.
RCTlUHIT
Type OT
Device
System
Consoles
CUTYPE=
RDEVICE
Other Operands
1052
-
-
1052
-
3210
-
3210
-
3066
-
3066
3138
-
-
3138
-
3148
-
3148
-
3158
-
-
3158
3036
-
3036
3272
-
3278
MODEl=2A
2701
-
-
-
2701
ADAPTER=BSCA, IBM1, or
TElE2
3215
2150
Transmission
Control
Units
Maximum
FEATURE=
Shared
SubchanDEVTYPE=
nel
3215
2150
2702
32-DEVICE
-
2702
ADAPTER=BSCA, IBM1, or
TElE2
SETADDR=O, 1, 2, or 3
2703
176-DEVICE
-
2703
ADAPTER=BSCA, IBM1, or
TElE2
Appendix B. Configuration Aid
281
~CTLUNIT
Type of
Device
Transmission
Control
Units
(cont.>
CUTYPE=
(Local
Attach.>
Other Operands
!6-DEVICE
256-DEVICE
-
3704
3705
ICA
16-DEVICE
-
ICA
-
2955
-
yes
2260
1052
-
-
yes
2265
-
-
-
2250
-
32-DEVICE
yes
3277
3284
3286
3288
FEATURE=OPRDR
32-DEVICE
yes
3277
3278
3279
3284
3286
3287
3288
3289
4250
FEATURE=OPRDR
MODEL=2, 3, 4, or 5
MODEL=2, or 3
-
3230
3268
4250
-
HFGD
-
2848
32-DEVICE
2845
2840
3272
3274
DPA
HFCU
Remote
3270
Display
Devices
RDEVICE
3704
3705
2955
Display
Devices
Maximum
FEATURE=
Shared
Subchannel
DEVTYPE=
1
32-DEVICE
ADAPTER=BSCA, IBM!,
TELE2, TYPE1, TYPE2,
TYPE3, or TYPE4
MODEL=A! through H8
SETADDR=O, 1, 2, or 3
CPTYPE=EP
CPNAME=ncpname
BASEft.DD=cuu
ADAPTER=BSCA, IBM1,
TELE2, or SDLC
-
2701
-
-
2701
ADDRESS=cuu (line
address)
ADAPTER=BSCA
CLUSTER=label
2703
-
-
2703
ADDRESS=cuu (line
address)
ADAPTER=BSCA or SDLC
CLUSTER=label
ICA
-
-
ICA
ADDRESS=cuu (line
address)
ADAPTER=BSCA
CLUSTER=label
lIf a 3287 is attached to a 3272, the 3287 is specified as a 3284
or 3286.
282
VM/SP Planning Guide and Reference
RCTlUNIT
Type of
Device
Shared
Subchannel
DEVTYPE=
CUTYPE=
Maximum
FEATURE=
Remote
3270
Display
Devices
(cont.)
3704
3705
--
-
-
3704
3705
Direct
Access
storage
Devices
2841
-
yes
2311
2321
2303
2314
2319
IFA
--
yes
16-DEVICE
-
2314
2319
3830
3830
32-DEVICE
160-DEVICE
-
3330
3330
3880
3345
3880
ISC
32-DEVICE
16-DEVICE
16-DEVICE
64-DEVICE
--
3330
3333
3333
3830
3880
3345
ISC
IFA
3830
3880
ISC
IFA
3880
3880
64-DEVICE
64-DEVICE
16-DEVICE
160-DEVICE
160-DEVICE
64-DEVICE
64-DEVICE
64-DEVICE
16-DEVICE
64-DEVICE
64-DEVICE
3880
16-DEVICE
32-DEVICE
64-DEVICE
2820
Tape
Devices
-
---
RDEVICE
Other Operands
ADDRESS=cuu (line
address)
ADAPTER=BSCA
CPTYPE=EP
BASEADD=cuu
ClUSTER=label
MODEl=l, 2, or 11
FEATURE=SYSVIRT,
FEATURE=VIRTUAL
MODEl=l, 2, or 11
MODEl=1 or 11
MODEl=1 or 11
3340
3340
3350
3350
-
3375
3380
-
FB-512
yes
2301
FEATURE=FH
FEATURE=FH
3310
3370
2835
16-DEVICE
-
2305
FTA
16-DEVICE
-
FB-512
2803
2804
16-DEVICE
16-DEVICE
yes
2401
2402
2420
MODEl=1 or 2
MODEl=1, 2, 3, 4, 5, 6,
or 8
FEATURE=7-TRACK,
DUAlDENS
MODEl=1, 2, 3, 4, 5 or 6
FEATURE=7-TRACK, CONY,
DUAlDENS
MODEl=5 or 7
Appendix B. Configuration Aid
283
RCTlUNIT
Type of
Device
Tape
Devices
(cont.)
CUTYPE=
3411
2403
2404
2415
FTA
16-DEVICE
16-DEVICE
RDEVICE
Other Operands
yes
3410
3411
MODEl=1, 2, or 3
FEATURE=7-TRACK,
DUAlDENS
yes
2403
2404
MODEl=l, 2, 3, 4, 5 or 6
FEATURE=7-TRACK, CONY,
DUAlDENS
yes
2415
MODEl=1, 2, 3, 4, 5 or 6
FEATURE=7-TRACK, CONY
-
8809
3411
-
yes
3410
3411
MODEl=1, 2, or 3
FEATURE=7-TRACK,
DUAlDENS
3430
-
yes
3430
FEATURE=DUAlDENS
yes
3420
MODEl=3, 4, 5, 6, 7 or 8
FEATURE=7-TRACK,
DUALDENS
-
1403
2540P
ClASS=(class[,class ... ])
FEATURE=UNVCHSET
ClASS=(class[,class ... ])
3803
Unit
Record
Output
Devices
Maximum
FEATURE=
Shared
Subchannel
DEVTYPE=
2821
16-DEVICEl
-
1443
-
-
1443
CLASS=(class[,class ... ])
3811
-
-
3211
ClASS=(class[,class ... ])
3262
-
-
3262 2
MODEl=5
ClASS=(class[,class ... ])
2826
-
1018
SVPC
-
SVPC
-
3203
-
3505
-
3800
4245
2520
2520P
ClASS=(class,[class ... ])
-
3262
MODEL=! or 11
3289
MODEl=4
3203
MODEl=4 or 5
CLASS=(class,[class ... ])
3525
ClASS=(class,[class ... ])
-
-
3800
MODEl=3 or 8
FEATURE=4WCGMS,
IMAGE=imagelib,
CHARS=ffff,FCB=lpi,
DPMSIZE=n
ClASS=(class[,class ... ])
-
-
4245
MODEL=1
CLASS=(class[,class ... ])
lFEATURE=16-DEVICE should be specified for 3803 when the communicator
feature is used, allowing access to a second tape control unit and
eight more tape drives.
2The RCTLUNIT, when coded as 3262, is valid for DEVTYPE=3262,
MODEL=5.
284
VM/SP Planning Guide and Reference
RCTLUNIT
Type of
Device
Unit
Record
Input
Devices
CUTYPE=
2540R
-
2495
2671
2826
-
-
-
1017
2501
-
-
2501
CTCA
-
yes
CTCA
-
3088
-
7443
2821
2520
3505
2495
2822
Special
Devices
Maximum
FEATURE=
3088
7443
-
Shared
Subchannel
DEVTYPE=
64-DEVICE
-
RDEVICE
Other Operands
2520R
3505
Appendix B. Configuration Aid
285
286
VM/SP Planning Guide and Reference
Appendix C. Compatible Devices
The devices listed below are functionally equivalent to the 2770 Communication
System. Details on the feature requirements for operational control of such devices
are not contained in VM/SP publications, but in the programming and operating
publications that support these devices.
mM 6640 Document Printer-Communicating
•
Programming Guide for Communicating with the IBM 6640 Document Printer,
Form No. G544-1001
•
IBM 6640 Document Printer - Communicating User's Guide, Form No.
S5.44-0507
•
IBM 6640 Document Printer - Communicating Operating Instructions, Form
No. S544-0506
IBM Office System 6 Information Processors (6/650,6/440,6/430)
•
Programming Guide for Communicating with the IBM Office System 6 Information Processors, Form No. G544-1003
•
IBM 6/450,6/440, and 6/430 Information Processors - Communicating
User's Guide, Form No. S544-0521
•
IBM 6/450, 6/440, and 6/430 Information Processors - Communicating
Operating Instructions, Form No. S544-0522
IBM Mag Card II Typewriter - Communicating and IBM 6240 Mag Card Typewriter - Communicating
•
Programming Guide for Communicating with the IBM Mag Card II Typewriter
and the IBM 6240 Mag Card Typewriter, Form No. G544-1005
•
IBM Mag Card II Typewriter - Communicating and IBM 6240 Mag Card
Typewriter - Communicating Reference Guide, Form No. S544-0549
•
IBM Mag Card II Typewriter - Communicating and IBM 6240 Mag Card
Typewriter - Communicating Operating Instructions, Form No. S544-1005
Appendix C. Compatible Devices
287
288
VM/SP Planning Guide and Reference
Appendix D. VM/SP Restrictions
A virtual machine created by VM/SP is capable of running an IBM System/360 or
System/370 operating system as long as certain VM/SP restrictions are not violated. Virtual machine restrictions and certain execution characteristics are stated
in this appendix.
VM/SP
Two components, CP and CMS, have been extensively modified and integrated
into a VM/370 Release 6 base. This collective package (CP and CMS) is referred
to as VM/SP. However, there are recommended program products (Remote
Spooling Communication Subsystem (RSCS) Networking, program number
5748-XPl) and Interactive Problem Control System (IPCS) Extension, program
number 5748-SAl) available that have been technically advanced to provide supportive function to VM/SP.
Restrictions - Channel Program
Looping channel programs should be avoided. Execution of a backward transfer in
channel CCW to an I/O CCW that will present channel end and device end at the
same time could result in locking out the device as well as the channel. Users
attempting to access devices on the channel will also be locked out. To recover
from this state, the CP HALT command must be issued to the device or have the
operator issue a system reset.
When issuing CCW's in which a data address is specified, that address must be
within the virtual machine size regardless of whether data transfer is involved or
not. The use of an address above the virtual machine size will result in VM/SP
forcing a channel program check.
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 modified channel programs given special consideration by CP) are:
•
Those generated by the Indexed Sequential Access Method (ISAM) running
under OS/PCP, OS/MFT, and OS/MVT
•
Those generated by ISAM running in an OS/VS virtual=real partition
•
Those generated by the OS/VS Telecommunications Access Method (TCAM)
Level 5, with the VM/SP 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
specified in its VM/SP directory entry. There is no such restriction for DOS
Appendix D. VM/SP Restrictions
289
ISAM, or for ISAM if it is running in an OS/VS virtual = virtual partition. If ISAM
is to run in an OS/VS virtual = real partition, you must specify the ISAM option in
the VM/SP directory entry for the OS/VS virtual machine.
Virtual machines using OS/VS TCAM (~evel 5, generated or invoked with the
VM/SP option) issue a DIAGNOSE instruction when the channel program is modified. This instruction causes CP to reflect the change in the virtual CCW 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 PCI bit in the real CCW string. Each time the real CCW
string is executed, the resulting PCI interruption causes CP to examine the corresponding virtual CCW 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 NOTRANS
option has been set on.
290
VM/SP Planning Guide and Reference
Minidisk Restrictions
The following restrictions exist for minidisks:
1. In the case of read home address with the skip bit off, VM/SP 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.
In the case of read device characteristics to an FB-512 device with the skip bit
off, VM/SP modifies the data in user storage at completion of the channel
program so the data reflects the true minidisk size and characteristics. Therefore, the data buffer area cannot be dynamically modified during the
input/ output operation.
Note: The user should not attempt to use this data during the I/O operation.
3.
On a minidisk, if a CCW string uses multitrack search on input/output operations, further operations to that disk must have preceding seeks or continue to
use multitrack operations. There is no restriction for dedicated disks.
4.
OS/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
lSAM or OS/VS ISAM running virtual=virtual.
Note: Because a VS 1 system using VM handshaking does no paging, any
ISAM programs run under VSl are treated by VM/SP as though they are running in an ADDRSPC=REAL partition.
5.
VM/SP does not return an end-of-cylinder condition to a virtual machine that
has a virtual 2311 mapped to the top half (that is, tracks 0 through 9) of 2314
or 2319 cylinders.
6. If your channel program for a count-key-data minidisk does not perform a seek
operation, VM/SP inserts a positioning seek operation into the program to
prevent accidental accessing. 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.
7.
A DASD channel program directed to a 3330, 3340, 3350, 3375, or 3380
device may give results on dedicated drives that differ from results on minidisks
having non-zero relocation factors if the channel program includes
multiple-track operations and depends on a search ID high or a search ID equal
or high to end the program. This is because the record 0 count fields on these
devices 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 end prematurely if a real record 0 is encountered.
Appendix D. VM/SP Restrictions
291
Notes:
a.
Minidisks with non-zero relocation factors on 3330, 3340, 3350, 3375, or
3380 devices are not usable under OS and OS/VS systems. This is because
the locate catalog management function employs a search ID equal or high
CCW to find the end of the VTOC.
b.
If the 'R' byte field of 'CCHHR' = 0 at the time a virtual SIO is issued, but
the 'CCHHR' field is read in dynamically by the channel program before
the Search ID CCW is executed, the real Search ID CCW will use the relocated 'CCHHR' field that was dynamically read in, causing incorrect
results. To avoid this problem, the 'R' byte of 'CCHHR' should not be
defaulted to binary zero by the virtual machine if the search arguments are
to be read in dynamically and a Search ID on "Record RO" is not desired.
If the DASD channel programs directed to 3330/~340/3350/3375/3380
8.
devices include a write record R(O), results differ depending on whether the
3330/3340/3350/3375/3380 is dedicated or nondedicated. A full-pack
minidisk is treated the same as any nondedicated device. For a dedicated
3330/3340/3350/3375/3380, a write R(O) is allowed, but you must be aware
that the track descriptor record may not be the same from one
3330/3340/3350/3375/3380 to another. For a nondedicated
3330/3340/3350/3375/3380, a write record R(O) is replaced by a read
record R(O) and the skip flag is set on. This could result in a command reject
condition due to an invalid command sequence.
9.
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 is
to be dynamically read or if a search ID on record 0 is not wanted.
10. On FB-512 devices, the use of the CE area is different for dedicated devices
and minidisks. Any user with. a dedicated device can use the CE area. However, only class F users can use the CE area for minidisks.
11. FB-512 diagnostic commands are also handled differently for dedicated
devices and minidisks. Any user with a dedicated device can issue diagnostic
CCWs. For minidisks, however, only users with a minidisk equal to the size of
the entire pack can issue a diagnostic control command. Because diagnostic
sense commands must be chained from a diagnostic control command, this
restriction indirectly applies to those commands also.
12. DIAGNOSTIC READ HOME ADDRESS and DIAGNOSTIC WRITE
HOME ADDRESS commands are supported only for:
•
•
Dedicated devices
Minidisks that start at cylinder 0 (real)
13. Refer to Device Support Facilities, GC35-0033, for procedures on formatting
3375 and 3380 direct access storage for use in an OS/VS operating system
running in a virtual machine.
292
VM/SP Planning Guide and Reference
14. When a virtual 3330 Modell is mapped to a real 3330 Model 11 and a virtual
machine references sense information during error recovery, incorrect results
will occur. Since sense byte 6, bits 1 and 2, is referenced differently by 3330
Models 1 and 11, the results will be unexpected.
Timing Dependencies
Timing dependencies in input/output devices or programming do not function
normally under VM/SP:
1. The following telecommunication access methods (or the designated option)
violate the restriction on timing dependency by using program-controlled interrupt techniques and/or violate the restriction on dynamically modified channel
programs:
•
OS Basic Telecommunications Access Method (BTAM) with the dynamic
buffering option.
•
OS Queued Telecommunications Access Method (QTAM).
•
DOS Queued Telecommunications Access Method (QTAM).
•
OS Telecommunications Access Method (TCAM).
•
OS/VS Telecommunications Access Method (TCAM) Level 4 or earlier,
and Level 5 if TCAM is not generated or invoked with the VM/SP option.
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 CTCA, 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 in page zero or beyond the end of the virtual=real area.
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/SP if issued from third level storage. For example,
a reset poll macro has a NOP effect if executed from virtual=virtual storage in
a VSl system that is running under VM/SP.
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.
Appendix D. VM/SP Restrictions
293
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/SP system processing. An example of such a device is the mM 1419
Magnetic Character Reader.
4.
The operation of a virtual block multiplexer channel is timing dependent. For
this reason, the channel appears available to the virtual machine operating system, and channel available interrupts are not observed. However, operations
on virtual block multiplexing devices should use the available features like
Rotational Position Sensing to heighten use of the real channels.
5.
Devices that experience extreme pedormance penalties if not reinstructed within a fixed interval may experience this penalty during every I/O operation. An
example is the 8809 tape drive. Setting the mode to "streaming" may actually
result in a slower data rate than running in nonstreaming mode. Execution
delays, caused by normal VM/SP processing, prevent a timely reinstruct and
the 8809 tape drive may sustain a 1.2 second delay on every I/O operation.
You must decide (based mainly on the size of the I/O buffers) between running at 100 IPS with continuous delays and running at 12.5 IPS, and set the
mode accordingly.
Processor Model-Dependent Functions
On the System/370 Model 158 only, the virtual machine assist feature cannot
operate at the same time with the 7070/7074 compatibility feature (#7117).
Programs written for processor model-dependent functions may not run properly in
the virtual machine under VM/SP. The following points should be noted:
294
1.
Programs written to examine the machine logout area do not have meaningful
data since VM/SP 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 VM/SP.
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/SP will be running on.
VM/SP Planning Guide and Reference
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 oth~
er 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 abide by the following requirement:
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.
Note: Virtual machines running CMS do not need to abide by these requirements.
Here, only unit record spooling and diagnose I/O 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 a random 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 the real channel, channel
model-dependent error recovery procedures can use STIDC to identify the channel.
Channel extended logouts are reflected to the virtual machine in a manner that is
processor model- and channel model-dependent and constant with the data
returned by STIDC (provided that the virtual-to-real channel mapping abides by
the requirement stated previously).
A difference in the handling of channel extended logouts occurs if the virtual
machine uses the bit in control register 14 to mask out channel extended logouts.
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 CSW is never set. However, channel extended logouts will not be lost when
they are kept pending along with their associated I/O interrupts by the channel
masks in control register 2 and the PSW. 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 \ogout in its own error recording cylinders.
Appendix D. VM/SP Restrictions
295
Virtual Machine Characteristics
Other characteristics that exist for a virtual machine under VM/SP are as follows:
1. 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 processor and channels operates in these cases, but is unable
to provide predictable protection to other virtual machines. In addition, violation of this restriction may compromise the soundness of the system. The
results are unpredictable.
2. A two-channel switch can be used between the processor running a virtual
machine under VM/SP and another processor.
3. The DIAGNOSE instruction cannot be issued by the virtual machine for its
normal function. VM/SP 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 VM / SP System Programmer's Guide.
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 virtual control
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 of dedicated unit record devices or certain self-modifying IPL sequences of tape
devices.
6. VM/SP spooling does 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/SP does not support count control on the virtual 1052 operator's console.
8. Programs that use the integrated emulators function only if the real system has
the appropriate compatibility feature. VM/SP does not attempt simulation.
The DOS emulator running under OS or OS/VS is not supported under
VM/SP.
9. The READ DIRECT and WRITE DIRECT instructions are not supported for
a virtual machine.
296
VM/SP Planning Guide and Reference
10. The SET CLOCK instruction cannot be simulated and is ignored if issued by a
virtual machine. The STORE CLOCK instruction is a nonprivileged instruction and cannot be trapped by VM/SP; 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.
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 IPL with the NO CLEAR option overlays one page of
virtual machine storage. The IPL simulator uses one page of the virtual
machine to initiate the IPL function. The starting address of the overlaid page
is either the result of the following formula:
virtual machine size
= starting address of the overlaid page
2
or the hexadecimal value 20000, whichever is smaller.
14. To maintain data 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 ended with an interrupt
whose CSW indicates incorrect length and a channel program check.
Notes:
a.
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.
b.
Data chained seek CCWs with counts of less than four are not the same as
those used by the data security of VM/SP and will give an error when
used.
15. When an I/O error occurs on a device, the hardware maintains a conditional
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/SP, the conditional connection is maintained until
the SENSE command is executed, but I/O activity from other virtual machines
can begin on the device while the sense data is being reflected to the virtual
machine. Therefore, you 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.
Appendix D. VM/SP Restrictions
297
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, thus changing the mode setting of all 7 -track
tape devices attached to that control unit.
17. A shared system or one that uses discontiguous saved segments cannot be
loaded (IPL) into a virtual machine running in the virtual = real area.
18. 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.
19. 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.
20. The Program Controlled Interruption (PCI) FETCH option for load module
calling is not supported for OS/MFT or VS1.
21. 3081 processors do not permit use of one megabyte segments for virtual
machines. Any attempt by a relocatable virtual machine using 1Mb segments
to use the DAT facility for address translation, results in a translation exception.
22. The Input/Output Configuration Program must not be run while single
processor mode is active on the system. Objectionable results may occur.
23. OS/VS2 is supported in uniprocessor mode only.
298
VM/SP Planning Guide and Reference
MSS Restrictions
1. There are two OS/VS system data sets associated with a 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 operating system. If more than one OS/VS system (running in
either native mode 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 programming support in the virtual machine must recognize and access the
virtual device as a 3330V.
3. The following must be the same: the definition of 3330V addresses in the MSC
tables, the DMKRIO module, and the IOGEN for any OS/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 VM / SP System Programmer's Guide.
4.
Each active volume in the MSS must have a different 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 for VM/SP residence, paging,
spooling, or temporary disk space.
6.
You must not change the volume serial 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.
7.
CP commands that require action from the central server must not be issued
from the central server virtual system.
If virtual volumes are to be shared between processors, the virtual machine
must handle cylinder faulting.
Appendix D. VM/SP Restrictions
299
eMS Restrictions
The following restrictions apply to CMS, the conversational subsystem of VM/SP:
1.
CMS runs only on a virtual processor provided by VM/SP.
2. The maximum sizes (in cylinders or blocks) of CMS minidisks are as follows:
Device
Type
2314/2319
3310
3330
3330
3333
3333
3340
3340
3350
3370
3375
3380
Model(s)
lor 2
11
1
11
35
70
native mode
CMS/VSAM
CMS 800-byte
Format
CMS 512, lK, 2K,
or 4K Format
200 cyls.
126,016 blocks
404 cyls.
808 cyls.
404 cyls.
808 cyls.
348 cyls.
696 cyls.
555 cyls.
558,000 blocks
959 cyls.
885 cyls.
203 cyls.
not supported
246 cyls.
246 cyls.
246 cyls.
246 cyls.
348 cyls.
682 cyls.
115 cyls.
not supported
182 cyls.
121 cyls.
203 cyls.
126,016 blocks
404 cyls.
808 cyls.
404 cyls.
808 cyls.
348 cyls.
696 cyls.
555 cyls.
558,000 blocks
959 cyls.
885 cyls.
3. If CMS cannot calculate a true time, it will display
*. ** in place of n.nn or x.xx.
4.
Programs that operate under CMS are encouraged to use documented interfaces. Those programs that modify DMSNUC or other CMS control blocks in
order to accomplish their interfaces with the CMS system, may hamper the
performance and reliability of the system.
5.
CMS uses VM/SP spooling to perform unit record I/O. However, a program
running under CMS can issue its own SIOs to attached dedicated unit record
devices.
6.
Only those OS and VSE tasks that are simulated by CMS can be used to run
OS and VSE programs produced by language processors under CMS.
7.
Many types of object programs produced by CMS (and OS) languages can be
run under CMS using CMS's simulation of OS supervisory functions. Although
supported in OS and VSE virtual machines under VM/SP, the writing and
updating of non-VSAM OS data sets and VSE files are not supported under
CMS.
8.
CMS can read sequential and partitioned OS data sets and sequential VSE
files, by simulating certain OS and VSE system services.
The following restrictions apply when CMS reads OS data sets that reside on
OS disks:
300
•
Read-password-protected data sets are not read unless they are VSAM
data sets.
•
BDAM and ISAM data sets are not read.
VM/SP' Planning Guide and Reference
•
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 keys are ignored and only the data is read, except for
VSAM.
•
User labels in user labeled data sets are ignored.
The following restrictions apply when CMS reads VSE files that reside on DOS
disks:
•
Only VSE sequential files can be read. CMS options and operands that do
not apply to OS sequential data sets (such as the MEMBER and CONCAT
options of FILEDEF and the PDS option of MOVEFILE) also do not
apply to VSE sequential files.
•
The following types of VSE files cannot be read:
VSE DAM and ISAM files.
Files with the input security indicator on.
VSE files that contain more than 16 extents. (Note: User labels occupy
the first extent; therefore, the file can hold only 15 additional data
extents.)
•
Multivolume files are read as single volume files. End-of-volume is treated
as end-of-file and there is no end-of-volume switching.
•
User labels in user labeled files are ignored.
•
Since VSE files do not contain BLKSIZE, RECFM, or LRECL
parameters, these parameters must be specified via FILEDEF or DCB
parameters; otherwise, BLKSIZE=32760 and RECFM=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 VSE implementation. Specifying the
DUMMY option with the DLBL command will cause an execution-time
error.
9. Assembler program usage of the ISAM Interface Program (lIP) is not supported.
10. CMS/DOS support is based on the VSE/ Advanced Functions program product. With VSE, prior releases of VSAM are not supported under CMS/DOS.
11. System logical units (SYSIN, SYSRDR, SYSIPT, SYSLST, and SYSPCH), are
not supported for VSE formatted FB-512 devices because the SYSFIL function (SVC 103) of VSE is not supported under CMS/DOS.
12. Programs created using CMS/DOS are not recommended for transfer directly
to a VSE machine because:
Appendix D. VM/SP Restrictions
301
•
The CMS/DOS VSE linkage editor is designed to link edit VSE programs
under CMS/DOS only.
•
Programs created using the CMS/DOS assembler may have incorrect
ESD's. In this case, the OS assembler is used. The OS assembler is not
compatible with VSE.
•
Some VSE macros and SVC's are simulated. The code generated is not
complete under CMS/DOS.
13. Setting the PSW EC mode bit on is not recommended because CMS handles
interrupts in BC mode only.
14. To ensure that the saved copy of the S-STAT or Y-STAT is current, a validity
check is performed when a saved system is IPLed. This check is performed
only for S-DISKS and Y-DISKS formatted in 512-, 1024-, 2048-, or 4096-byte
CMS blocks. For 800-byte block disks, the saved copy of the S-STAT or
Y-STAT is used. The validity checking consists of comparing the date when
the saved directory was last updated with the date when the current disk was
last updated. If the dates for the S-STAT are different, then the S-STAT is
built in user storage. If the dates for the Y-STAT are different, then the
Y-disk is accessed using the CMS ACCESS command: ACCESS 19E Y/S * *
Y211. This means that even when the S- and Y-disks are accessed in
read/write mode and then RELEASED, the message DMSINSI00W S-STAT
and/or Y-STAT NOT AVAILABLE will result.
Miscellaneous Restrictions
1. 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 system to be put into an enabled wait state.
2. If you plan 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 logon 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 logon
after IPL. The larger the real machine size, the lesser the possibility of this
occurring.
3. For remote 3270s, VM/SP supports a maximum of 256 binary synchronous
lines minus the number of 3704/3705 Communications Controllers.
4. If an I/O device (such as a disk or tape drive) drops ready 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
The DASD address of the Y-DISK will be whatever was specified when eMS was generated. For
the standard system this will be 19E.
302
VM/SP Planning Guide and Reference
FORCE commands are not effective because they do not complete until all
waiting 110 is finished. The system operator should determine which 1/0
device is involved and make that device ready once more.
5.
Any modifications to local OPTIONS COPYFILE, unless otherwise specified
in existing documentation, is not supported.
6. If you are using an IBM 3031, 3032, or 3033 processor, you must dedicate the
service record file (SRF) device to VM/SP. Thus, the channel on which the
SRF is located cannot be dedicated to any virtual machine.
7.
When using the SPOOL, DEDICATE, and SPECIAL directory control statements to define virtual devices, specify virtual addresses that do not conflict or
compete with the virtual control unit interface. This conflict or competition
occurs because devices can require special 110 interface protocol from control
units such as shared, and nonshared sub channel 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 channell 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.
8. If you are using an 8809 tape device, it is required to have a tape mounted with
the drive ready before issuing a CP DETACH command. This allows the tape
drive mode to be returned to the default mode when execution of the command
completes.
9.
Logical device support is not designed to simulate all aspects of real device
support. Some instances are:
•
Logical device support always passes channel end and device end to the
virtual machine together.
•
The PCI bit in the CCW is not handled by logical device support.
•
Ending status on 110 only is passed back to the virtual machine (not
initial).
10. When using two channel-to-channel adapters (dedicated to virtual machines),
and the CTCAs are operating on the same channels on each CPU, then the virtual machines should use the control CCW to prevent locking out the channel.
11. If using conmode 3270 with a guest SCP such as MVS, SCRNSAVB ON must
be specified; otherwise, unpredictable results may occur.
12. If the number of virtual devices exceeds the formula (7FFF divided by
VDEVBLOK size) unpredictable results may occur. This is due to the design
usage of the virtual control block structure.
Appendix D. VM/SP Restrictions
303
13. When TERMINAL CONMODE 3270 is in effect, tracing should not be done
at the same console, as unpredictable results may occur.
14. When using the 3081 processor, V=V users can no longer use 1 Mb
(megabyte) segments for constructing shadow tables.
15. If a terminal has an inhibited (non-display) read up and either a delayed PF
key or an undefined PF key is used, the input area will be rewritten without the
inhibited attribute byte, therefore displaying any data typed in at that point.
The clear key can be used following the PF key to rewrite the inhibited read.
16. If a NETWORK ENABLE is issued to a device with advanced features and a
NETWORK ATTACH is issued prior to powering the device on, then the
advanced features will be non-operational. The device must be powered on
and enabled prior to the NETWORK ATTACH.
17. When using the virtual channel-to-channel adapter it is possible to receive a
spurious attention interrupt after receiving attention plus busy in response to a
data transfer operation. The spurious attention may occur if both the X and Y
sides of the VCTCA are doing the same data transfer operation. (For
example, both doing writes or both doing reads.)
18. If a 3278 Model 4 is switched to alternate mode (43 line screen) and the terminal is then dialed to a virtual machine, the terminal will not be reset to
default mode (24 line screen). The 3278 Model 4 will remain in alternate
mode if alternate mode is started after the logo has been written and an erase
write alternate has been issued to the screen.
19. VM support of the 3800 printer as a non-dedicated virtual spooling device does
not save the loaded FCB between spool files. When a virtual spool file is
closed, the loaded FCB is not kept. When a spool file is opened, a default
FCB is set. A hex 63 (LOAD FCB) CCW must be done to set up any other
FCB for the spool file. This support is different from VM support of other virtual spooling devices, such as a 3211 printer.
20. In Single Processor Mode, CP-owned volumes must be on strings and control
units that are not online to the MVS native side.
21. Users with the cross memory feature(#6850) installed and MVS Release 2 or
3, cannot use the single processor mode (SPM) or non-disruptive transition
(QVM) functions of VM/SP.
304
VM/SP Planning Guide .and Reference
Index
Special Characters
·CCS, directory option 166
A
A-disk
CMS primary user disk 47
accessing 52
access
filemodes, CMS files 52
Access Method Services
DASD devices supported 66
DOS VSAM data set support 65
OS data set support 65
SAM data set support 65
storage requirements 42
supported under CMS 65
ACCESS, command (CMS) 52
ACCOUNT, directory control statement 161
accounting number, defining in directory 161
ACCT, directory option 163
ADAPTER operand, RDEVICE macro 208
ADDRESS operand
RCHANNEL macro 220
RCTLUNIT macro 216
RDEVICE macro 201
Advanced Control Program Support, processor feature 10
AFFINITY, directory option 164
allocating
DASD space for the. directory 40
space on CP-owned volumes 237
ALLOW, directory option 166
ALTCH operand, RCTLUNIT macro 217
ALTCONS operand, RIOGEN macro 221
ALTCU operand, RDEVICE macro 209
alternate blocks, FB-512 disks 63
alternate console, defining 221
alternate console, restriction 123
alternate path support
1/0 scheduling 77
restrictions 79
sample RCHANNEL macros 79
sample RCTLUNIT macros 78, 79
sample RDEVICE macros 78
supported switches 77
alternate tracks
FB-512 63
minidisks 60
system residence devices 61
2314/2319 62
333'0 60
334d 60
3340 allocation conversion 61
3340 cylinder assignments 61
3340 error recovery 61
3350 60
3375 62
3380 62
alternate tracks/blocks 60
AMS (see Access Method Services)
ANY, directory option 166
AP (see attached processor system)
AP operand, SYSCOR macro 248
APFZAP, used to install MSS 134
APL Assist, processor feature 10
APL, use with CMS 50
assembler
use with CMS 50
VM/370 275
attached processor system
generating 113
performance measurement 98
specifying AP initialization, SYSCOR macro 248
support modules 113
system identification, SYSID macro 261
System/370 Extended Feature 99
unsupported with Small CP option 33
using shared segments 93
3033AP, channel-set switching 80
attachments
3270s
remote 115
AUTO operand, SYSMON macro 252
auxiliary storage, required by CMS 45
available real storage
calculating 104
Formula 1 104
B
BASEADD operand, RDEVICE macro 210
BASIC, use with CMS 50
Binary Synchronous Lines (see BSC lines)
blocks
FB-512, alternate 63
minidisks, alternate 60
BMX, directory option 163
BOTTOM operand, SYSPCLAS macro 259
BSC lines
coding RDEVICE macro 191
3270 support 116
BUFFS operand, SYSMON macro 253
C
C (spool file class) operand, SYSPCLAS macro 259
calculating available real storage 104
calculating dasd space 108
calculating the maximum size of the virtual=real area 105
cardless system
required devices 7
CCWs, reserved 87
channel
alternate, RCTLUNIT macro 217
errors, RCTLUNIT macro 219
channel interface
Mass Storage Control 131
positions for Staging Adapter 132
channel switching
alternate path support 77
between two processors 75
channel-set switching facility 80
on one processor 76
system generation macros 75, 76
tape 76
two- or four-channel switch feature 74, 75, 76
Index
305
channel-set switching facility 80
channel-to-channel adapter, processor feature 10
CHARS operand, RDEVICE macro 211
checkpoint cylinders, by device type 243
checkpoint start data
calculating cylinders needed 243
DASD requirements 38, 39
defining cylinders 242
CHTYPE operand, RCHANNEL macro 220
CLASS operand
RDEVICE macro 207
SYSACNT macro 256
SYSMON macro 252
classifying printed output 259
clock comparator 9
CLUSTER macro
CUTYPE operand 192
DIAL operand 193
examples 193
format 192
GPOLL operand 192
label requirements 192
LINE operand 193
CLUSTER operand, RDEVICE macro 210
CMS
A-disk 47
alternate nucleus 94
assembler, use with CMS 50
auxiliary storage requirements 45
capacity of virtual disks 53,54
command language 49
default device addresses 46
devices supported 46
DIRECT command 154
disk and file management 51
CMS 51
OS/DOS 51
VSAM 51
disk file format 52
disks 47
access 51
capacity 53, 54
formatting 51,52
labels 52
linking 52
FB-512 blocks 53
file directory 53
files
access modes 51
format 52
identification 55
maximum usable number 54
sharing 52
FORMAT command 51,52,60
formatted disks volume label contents 52
introduction 3
invoking the directory program 154
libraries 48
limited support of OS and VSE 50
master file directory 55
minidisk labels 63
minimum configurations 7
nucleus
storage requirements 45
partitioned data sets 48
plan~ing considerations 45
program language facilities 50
program languages supported under CMS 50
records, maximum usable number per file 54
restrictions 300
306
VM/SP Planning Guide and Reference
saving the CMS system S6
sharing the system residence volume 74
simulated partitioned data sets 48
storage requirements 4S
support of DL/I S 1
symbolic names for devices 46
system disk
S-disk 47
system libraries
macro 48
text 49
tape support 5S
unit record support 47, S6
useful Program Products 275
virtual storage requirements 45
CMS/DOS
ASSGN command 69,70,71
CMSBAM discontiguous saved segment 69,95
CMSDOS discontiguous saved segment 69,95
directory entries 187
disk label information area 71
DLBL command 69,70,71
librarian programs 70
planning considerations 69
SET DOS ON command 69, 70
tape handling 70
VSE compilers 69
VSE sysres 69
VSE system and private libraries 69
VSE system generation considerations 69
when VSE system must be online 70
CMSBAM doslib 49
CMSBAM segment 229
CMSDOS segment 229
CMSLIB maclib 48
CMSLIB txtIib 49
COBOL, compiling under CMS 50
coding DMKRIO macros for remote 3270s 191
color, defining via SCREEN directory control statement 169
communication facility
virtual machine, IUCV 91
virtual machine, VMCF 92
components
VM/SP
CMS (Conversational Monitor System) 3
CP (Control Program) 3
introduction 3
Conditional Swapping, processor feature 10
configurations
aid 281
DASD 11
devices 8
magnetic tapes 14
processors 9
supported by CMS 8
supported by VM/SP 7
terminals 15,20,21,22,24
transmission control units 24
unit record devices 14
VM/SP minimum 7
CONNECT, authorizing via IUCV directory control
statement 166
CONS operand, RIOGEN macro 221
console
alternate, defining in RIOGEN macro 221
defining real system console 221
CONSOLE, directory control statement 171
consoles, supported by VM/SP 15
control blocks, DMKRIO, defining 189
control program (CP) (see CP (Control Program»
Control Store Extension 13
control units
DASD supported by VM/SP 11
error messages for RDEVICE macro 214
local terminal support 21
magnetic tape control units supported by VM/SP 14
remote terminal support 22, 23
unit record control units supported by VM/SP 14
copying 3330-1 volumes to 3330V volumes 138
CORTABLE, defining in DMKSYS 247
count-key-data devices
characteristics 36
CMS block 53
device geometry 36
CP
device simulation 47
disk access 51
dump space, DASD requirements 38,39
dump space, formula 39
error recording, DASD requirements 38
free storage requirements 31
introduction 3
minimum configurations 7
nucleus
DASD requirements 38
excluding SNA CCS 127
reducing its size 33
processing reserved CCWs 87
real control blocks storage requirements 31
real storage requirements 31
example 32
resident nucleus storage requirements 31
saved systems, DASD requirements 38,41
Special Message Facility 92
storage requirements 38
trace table storage requirements 31
VM/SP directory, DASD requirements 38,40
warm start data, DASD requirements 38, 39
CP assist, description 11 0
CP NETWORK command support 122
CP nucleus dasd requirements 38
CPNAME operand
NAMENCP macro 233
NAME3800 macro 234
RDEVICE macro 210
CPSIZE operand
NAMENCP macro 233
CPT-TWX 33/35, supported remotely on start-stop
lines 122
CPTYPE operand
NAMENCP macro 233
RDEVICE macro 209
CPUID, directory option 164
creating and updating a 3800 named system 129
creating MSS volumes 138
CTCA, coding RDEVICE macro 202
CUTYPE operand
CLUSTER macro 192
RCTLUNIT macro 216
space
allocating for the directory 40
allocating on FB-512 volumes 37
calculating for saved systems 108
definition 36
formatting for the directory 40
needed by CMS 45
reserving for 3704/3705 control program
image 123
storage
for CMS minidisks 43
required for Access Methods Services 42
required for CMS/VSAM 42
required for CP nucleus 38
supported by VM/SP 11
SYSOWN macro 237
SYSRES macro
checkpoint cylinders, calculating 243
warm start cylinders, calculating 245
DASD operand, SYSMIH macro 267
DASTAP, data collection class 252
data collection
defining in SYSMON macro 251
performance measurement and analysis 98
Data Streaming, processor feature 10
DEDICATE
directory control statement 180
DEFAULT operand, SYSID macro 261
DEFCON operand, SYSFORM macro 258
DEFINE, command (CP), use in disk access 52
defining minidisks 57
defining minidisks in the directory 172
defining the MSS communication device 136
defining your system
introduction 143
DEFPRT operand, SYSFORM macro 257
DEFPUN operand, SYSFORM macro 257
DEQ macro, releasing a device 85
device sharing between processors 88
device sharing, one processor 89
Device Support Facilities
minidisk
alternate tracks 60, 61
labels 63
OS/VSE 59
2314/2319 formatting 59
devices
channel switching 75
coding RDEVICE macro
system console 203
unsupported devices 204
configuration aid 281
DASD supported by VM/SP 11
dedicating to virtual machines 180
default addresses for CMS 46
linking at logon 183
magnetic tape supported by VM/SP 14
processors supported by VM/SP 9
required for cardless system 7
sample configuration 223
D
DASD (Direct Access Storage Device)
allocating on CP-owned volumes 237
configuration aid 283
control units supported by VM/SP 12
error recording space requirements 38
sharing 84
reserve/release support 84,86
Index
307
simulated by programming 186
simulated I/O, specifying 186
special, configuration aid 284
subclass, defining unsupported devices 207
supported by CMS 46
supported by CMS VSAM 66
supported by VM/SP 8
terminals supported by VM/SP 15
unit record devices supported by VM/SP 14
unsupported, coding RDEVICE macro 204
used by an operating system in a virtual machine 28
DEVTYPE operand, RDEVICE macro 202
diagnose instruction
invoking logical device support facility 90
DIAL command 101
DIAL operand, CLUSTER macro 193
Direct Access Storage Device (see DASD)
direct access storage requirements for CP 36
DIRECT command
format 155
overview 154
directory
*CCS option 166
ACCOUNT control statement 161
ACCT option 163
AFFINITY option 164
allocating DASD space 40
ALLOW option 166
ANY option 166
CMS file directory 53
considerations for preparing entries 148
CONSOLE control statement 171
control statements 156
CPUID option 164
DEDICATE control statement 180
defining accounting number 161
defining distribution code 161
defining volume to contain 40
DIRECTORY control statement 157
ECMODE option 162
entries for CMS/DOS 187
examples
a hardware maintenance virtual machine 150
a virtual machine for updating the directory 153
a virtual machine for updating VM/SP 152
a virtual machine to receive system dumps 151
the system operator's virtual machine 150
formatting DASD space 40
hardware support 149
IBM TELE option 186
invoking under CMS 154
IPL control statement 168
ISAM option 163
IUCV control statement 166
LINK control statement 183
MAXCONN option 165
MDISK control statement 172
MIH option 165
MSGLIMIT option 166
NETWORK option 180
OPTION control statement 162
overview 147
PRIORITY option 166
program 153
R/O option 180
REALTIMER option 162
requirements for changing 153
running the directory program stand-alone 156
SCREEN control statement 169
software support 149
308
VM/SP Planning Guide and Reference
SPECIAL control statement 186
SPOOL control statement 177
SVCOFF option 163
USER control statement 158
VIRT=REAL option 101, 163
VMSA VE option 165
VOLID option 180
3330Voption 180
370E option 165
directory capabilities, defined 144
DIRMAINT, sample directory entry 153
discontiguous saved segments 93
attaching 94, 95
detaching 95
EXEC procedures 94
saving 94
usage requirements 96
disk access 51
disks
CMS, access 51
formatting for CMS 51,52
labels, CMS 52
management
CMS 51
OS/DOS 51
VSAM 51
display devices, configuration aid 282
distribution code, defining in the ~irectory 161
DL/I, support in CMS/DOS environment 51
DMKMSS 134
DMKRIO
preparing for system generation 189
RCHANNEL macro 220
RCTLUNIT macro 215
RDEVICE macro 200
RIOGEN macro 221
sample configuration 223
sequence of macros 190
TERMINAL macro 194
3270, example assemble file 118
DMKSNT
creating an entry for 3704/3705 123
creating your own version 229
for saved systems 93
NAMENCP macro 233
NAMESYS macro 230
NAME3800 macro 234
preparing 229
DMKSPA maclib, attached processor system 113
DMKSPM maclib, multiprocessor system 114
DMKSYS
CP-owned volumes for saved systems 93
performance considerations 236
preparing system control file 235
SYSACNT macro 256
SYSCOR macro 247
SYSFORM macro 257
SYSID macro 261
SYSJRL macro 254
SYSLOCS macro 270
SYSMIH macro 267
SYSMON macro 251
SYSOPR macro 246
SYSORD macro 263
SYSOWN macro 237
SYSPCLAS macro 259
SYSRES macro 239
SYSTIME macro 249
DMSSP maclib 48
DOS (Disk Operating System)
assembling VSE programs under CMS 48
initializing minidisks 59,62
macro library for CMS 48
support under CMS 50
DOS PL/I Optimizer, compiling under CMS 50
DOS/VS COBOL, compiling under CMS 50
DOS/VS RPG n, compiling under CMS 50
DOS, macro library for CMS 48
DOSGEN EXEC procedure
discontiguous saved segments 94
DOSMACRO maclib 48
DPMSIZE operand, RDEVICE macro 211
dump space, DASD requirements 39
dumps
directory entry, example 151
routing 151
DUMPT, used to install MSS 134
Dynamic Address Translation feature, System/370,
introduction 3
E
ECMODE, directory option 162
ECPS Expansion, processor feature 10
Emulation Program (see also 3704/3705 control program)
minimum storage required 122
support provided by 122
emulators
integrated emulators under VM/SP 279
ENABLE operand, SYSMON macro 252
EP-only control programs 212
EREP, sample hardware maintenance virtual machine 150
error recording
cylinders, defining 242
DASD requirements 38, 39
error recovery support 61
estimating dasd storage requirements for CMS minidisks 43
excluding SNA CCS modules 127
execution-time libraries 49
Expanded Control Store 13
expanded virtual machine assist 110
Extended Control Mode, System/370, introduction 3
Extended Control-Program Support 9
description 11 0
extended floating-point feature 9
F
FB-512
allocating DASD space 37
allocating DASD space for the directory 40
alternate blocks, minidisks 63
capacity for CMS minidisks 43
characteristics 37
CMS block 53
coding RDEVICE macro 202
CP DASD requirements 38
DASD space requirements
checkpoint start data 38
CP nuCleus 38
error recording 38
paging 38
saved systems 38
spooling 38
VM/SP directory 38
warm start data 38
device geometry 37
disks 38
format defective block procedure 63
minidisk space allocation 43
specifying in SYSRES macro 241
specifying preferred paging, SYSORD macro 263
starter system
forms control buffer supplied 271
introduction 4
FCB operand, RDEVICE macro 211
FEATURE operand
RCTLUNIT macro 218
RDEVICE macro 205
TERMINAL macro 197
features
processor
Advanced Control Program Support 10
APL Assist 10
Channel Indirect Data Addressing 9
channel-to-channel adapter 10
clock comparator 9
Conditional Swapping 10
Data Streaming 10
desirable 10
ECPS Expansion 10
extended floating-point 9
floating-point 9
required 9
system timing facility 9
virtual machine assist 9
Word Buffer 9
two-channel switch 27
VM/VS Handshaking 73
Field Developed Programs (FDPs), under VM/SP 275
file sharing 52
files
CMS
filemodes 52
maximum number of records 54
sharing 52
directory 53
management
CMS 51
OS/DOS 51
VSAM 51
fixed head feature, RDEVICE macro 205
floating-point feature 9
font offset buffer 272
form width codes 179
FORMAT
command(CMS)
usage 52
format defective block procedure, FB-512 disks 63
Format/ Allocate program
allocating DASD space as PERM 93
flagging defective tracks 62
formatting minidisks 60
overview 36
forms control buffer
supplied with starter system 271
Formula 1 (calculating available real storage) 104
Formula 2 (calculating maximum size of virtual=real
area) 105
FORTRAN IV, compiling under CMS 50
four-channel switch, RDEVICE macro 205
FREE operand, SYSCOR macro 247
free storage, permanently allocated for CP 31
free storage, required by CMS 45
Full American National Standard Common Business Oriented
Language (see COBOL)
Index
309
G
IPL
general polling characters 192
generating a VM/SP system that supports a 3850 131
GENIMAGE, updating a 3800 named system 129
GPOLL operand, CLUSTER macro 192
GRAF operand, SYSMIH macro 267
graphic device support
eliminating support modules 34
guest operating system, defined 144
directory control statement 168
ISAM Interface Program (lIP) 66
ISAM, difectory option 163
IUCV
authorizing communication path 166
directory control statement 166
overview 91
special directory considerations 167
structure of the SNA environment 125
H
J
Handshaking, VM/VS feature 73
hardware
maintenance directory entry 150
Mass Storage System support 131
remote, supported configurations 116
support, virtual machine description 149
hardware assist (see Extended Control-Program Support)
hardware devices supported by VSE 66
hardware support virtual machine, described 149
HFGD, coding RDEVICE macro 202
highlight, defining via SCREEN directory control
statement 169
JOURNAL operand, SYSJRL macro 254
I
IBM
Field Developed Programs (FDPs) 275
program products
IBM program numbers 275
integrated emulators 279
useful with VM/SP 275
IBM TELE, directory option 186
ICA (see Integrated Communications Attachment)
ID operand, SYSTIME macro 250
identification of CMS files 55
identifying disk files 55
IEHDASDR, disk formatting 59
IMAGE operand, RDEVICE macro 210
IMAGELIB, updating a 3800 named system 129
IMAGEMOD, updating a 3800 named system 129
INDICATE command, performance measurement 98
Installed User Programs (IUPs), under VM/SP 275
INSTVSAM segment 229
Integrated Communications Attachment
coding RDEVICE macro 202
features, required and optional 26
Integrated File Adapter, supported models 12
Integrated Printer Adapter, supported models 12, 14
Integrated 3203 Model 4 Printer Attachment 14
Inter-User Communication Vehicle (see IUCV)
internal control block, generating 247
internal pointer variables, generating with SYSLOCS
macro 270
invoking the Directory Program (DMKDIR) under CMS 154
IOCP (Input/Output Configuration Program)
coding considerations 226
example source file 227
MVS version 83
overview 82
planning considerations 29
references 83
stand-alone version 82
VM/SP version 83
310
VM/SP Planning Guide and Reference
L
labeling
minidisks 63
languages
supported by CMS 50
libraries
CMSBAM doslib 49
execution-time libraries 49
PROPLIB loadlib 49
system macro libraries 48
CMSLIB maclib 48
DMSSP maclib 48
DOSMACRO maclib 48
OSMACRO maclib 48
OSMACROI maclib 48
OSVSAM maclib 48
TSOMAC maclib 48
system text libraries 49
CMSLIB txtlib 49
TSOLIB txtlib 49
VSE system and private libraries 69
your own 49
licensed programs 275
LIMIT operand
SYSACNT macro 256
SYSMON macro 253
limited support of OS and VSE in CMS 50
line code, determining for 3270s 117
LINE operand, CLUSTER macro 193
LINK
command(CP), use in disk access 52
command, sharing minidisks 64
directory control statement 183
LINKDMK, used to install MSS 134, 135
linking CMS disks 52
LINKPROC, used to install MSS 134, 135
LNKLMT operand, SYSJRL macro 255
LNKUID operand, SYSJRL macro 255
loader tables, CMS storage requirements 45
LOC operand, SYSTIME macro 249
local 3270 support 21
Logical Device Support Facility
data transfer 90
overview 90
simulation of real device support 91
subfunctions 90,91
logical records, CMS 54
LOGLMT operand, SYSJRL macro 255
LOGUID operand, SYSJRL macro 254
M
macros
DOS macro library under CMS 48
NAMENCP 233
NAMESYS 230
NAME3800 234
OS macro libraries under CMS 48
OS macros under CMS, simulating 50
RCHANNEL 220
RCTLUNIT 215
RDEVICE
coding to support 3704/3705 control program 210
coding to support 3800 image library 210
introduction 189
RIOGEN 221
SYSACNT 256
SYSCOR 247
SYSFORM 257
SYSID 261
SYSJRL 254
SYSLOCS 270
SYSMIH 267
SYSMON 251
SYSOPR 246
SYSORD 263
SYSOWN 237
SYSPCLAS 259
SYSRES 239
SYSTIME 249
TSO macro library under CMS 48
VSAM macro library under CMS 48
VSE macro library under CMS 48
magnetic tape
control units supported by VM/SP 14
devices supported by VM/SP 14
main storage protection, defined 144
MAINT
sample software service virtual machine 152
Mass Storage Control 131
channel interfaces 131
Mass Storage Control Tables 136
Mass Storage Facility 131
Mass Storage System
communication device, defining 136
communicator program 134
copying 3330-1 volumes to 3330V volumes 138
creating MSS volumes 138
eliminating support modules 33, 34
generating VM/SP to support 131
Mass Storage control tables 136
minidisks 59
missing interrupt handler support 84
OS/VS1 jobs 134
OS/VS2 jobs 135
performance note 97
supporting processors 131
unsupported with Small CP option 33
master file directory, identifying CMS files 55
MAXCONN, directory option 165
MDISK
control statement, sharing minidisks 64
directory control statement 172
overlap warning 172
messages
RCTLUNIT macro, channel errors 219
RDEVICE macro
control unit errors 214
unit record errors 214
MIH (see Missing Interrupt Handler)
minidisks
alternate tracks 60
FB-512 63
2314/2319 62
3330 60
3340 60
3340 allocation conversion 61
3340 cylinder assignments 61
3340 error recovery 61
3350 60
3375 62
3380 62
boundaries 59
defining 57
example 58
initialization 60
labels 63
linking 64
minimum size 58
MSS 59
multiple 59
OS 59
overlap 59
overview 57
sharing 64
space allocation 58
starting cylinder 58
VSE 59
VTOC 57
minimum configurations
CMS 7
VM/SP 7
MISC operand, SYSMIH macro 268
Missing Interruption Handler
directory option 165
eliminating support modules 33,34
overview 84
performance considerations 236
SYSMIH macro 267
unsupported with Small CP option 33
MODEL operand
RDEVICE macro 205
SYSID macro 261
TERMINAL macro 196
models
3704/3705 communications controllers 211
modules providing AP support 113
modules providing MP support 114
MONITOR command, performance measurement 98
monitoring and service support facility (MSSF)
MSSFCALL instruction 81
SCPINFO command 81
MP (see multiprocessor system)
MP operand, SYSCOR macro 248
MSGLIMIT, directory option 166
MSS (see Mass Storage System)
MSS minidisks 59
MSSF (see monitoring and service support facility)
MSSFCALL instruction 81
multiple service record files 28
multiple virtual machines using the same operating system 74
multiprocessor system
generating 114
performance measurement 98
specifying MP initialization, SYSCOR macro 248
support modules 114
system identification, SYSID macro 261
System/370 Extended Feature 99
unsupported with Small CP option 33
Index
311
using shared segments 93
Multisystem Communication Unit
coding RDEVIC~ macro 202
overview 11
planning considerations 28
processors supported 11
MVSGuest
eliminating support modules 33,34
unsupported with Small CP option 33
MVS/System Extensions Support
requirements 111
System/370 Extended Facility, processors supported
System/370 Extended Feature, processors supported
MVS/System Product Support
requirements 111
System/370 Extended Facility, processors supported
System/370 Extended Feature, processors supported
N
named system, creating, 3800 printing subsystem 234
NAMENCP macro
CPNAME operand 233
CPSIZE operand 233
CPTYPE operand 233
format 233
if not used 35
SYSPGCT operand 233
SYSSTRT operand 233
SYSVOL operand 233
NAMESYS macro
format 230
PROTECT operand 232
RCVRID operand 232
SAVESEQ operand 232
SYSBLOK operand 231
SYSCYL operand 231
SYSHRSG operand 231
SYSNAME operand 230
SYSPGCT operand 231
SYSPGNM operand 231
SYSSIZE operand 230
SYSSTRT operand 231
SYSVOL operand 231
USERID operand 232
VSYSADR operand 230
VSYSRES operand 230
NAME3800 macro
CPNAME operand 234
format -234
if not used 35
SYSPGCT operand 234
SYSSTRT operand 234
SYSVOL operand 234
NARROW operand, SYSFORM macro 257
NCP and PEP sharing 126
NCP, structure of the SNA environment 126
Network Control Program (see NCP)
NETWORK, directory option 180
nucleus
CP
DASD requirements 38
real storage requirements 31
reducing its size 33,34
312
VM/SP Planning Guide and Reference
o
99
99
99
99
object programs (TEXT files), under CMS 50
obtaining the M~S communicator program 134
operating systems
performance characteristics 97
performance guidelines 97
planning considerations 73
saving core-image copies on disk 93
sharing the system residence volume 74
using reserve/release 84,86
OPERATNS, sample directory entry 151
OPERATOR, sample directory entry 150
OPERFORM operand, SYSFORM macro 257
OPTION, directory control statement 162
OS (Operating System)
initializing minidisks 59
macro libraries for CMS 48
minidisks 59
support under CMS 50
OS FORTRAN IV, compiling under CMS 50
OS minidisks 59
OS/VS COBOL, compiling under CMS 50
OSMACRO maclib 48
OSMACROI maclib 48
OSVSAM maclib 48
OUTPUT operand, SYSACNT macro 256
output spooling classes, RDEVICE macro 207
p
page tables 31, 93
paging
DASD requirements 38, 41
default DASD search order 266
performance considerations 236
specifying preferred paging devices 263
VM/VS Handshaking feature 73
partitioned data sets
CMS, limited support 50
simulated, CMS support 48
password protected resource, defined 144
password suppression facility, SYSJRL macro 255
PEP, structure of the SNA environment 126
PERFORM, data collection class 252
performance
characteristics 97
considerations
coding DMKSYS macros 236
heavy production I/O 236
large number of CMS users 230
missing interrupt handler support 236
read-only minidisks 236
using automatic monitoring facilities 236
using fixed head devices for paging 236
using the VM Real Time Monitor (SMART) 98
data collection, SYSMON macro 251
Extended Control-Program Support 98, 110
guidelines 97
virtual machine assist 109
measurement and analysis
INDICATE command 98
MONITOR command 98
SYSMON macro 98
MVS/System Extensions Support 99
described 111
processors supported 99
options 98
queue drop elimination 111
virtual machine assist 98
performance measurement and analysis 98
physical record, CMS 53
PL/I, compiling under CMS 50
planning considerations, system generation 3
preferred paging, specifying 263
preferred spooling, specifying 263
printer forms, specifying, SYSFORM macro 257
PRIORITY, directory option 166
processor
controller 29
desirable features 10
required features 9
supported by VM/SP 9
program languages
supported by CMS 50
Program Products (PPs), under VM/SP 275
Programmable Operator Facility 49
PROPUB loadlib 49
PROTECT operand, NAMESYS macro 232
PSUPRS operand, SYSJRL macro 255
Q
queue drop elimination, performance guidelines 111
R
R/O, directory option 180
RCHANNEL macro
ADDRESS operand 220
CHTYPE operand 220
examples 220
format 220
RCHBLOK
creating 220
RCTLUNIT macro
ADDRESS operand 216
ALTCH operand 217
channel errors 219
configuration aid 281
CUTYPE operand 216
examples 219
FEATURE operand 218
format 216
UCWoperand 218
using to define alternate paths 77
RCUBLOK
addressing 215
creating 215
RCVRID operand, NAMESYS macro 232
RDEVBLOK
creating 200
RDEVICE macro
ADAPTER operand 208
ADDRESS operand 201
ALTCU operand 209
BASEADD operand 210
CHARS operand 211
CLASS operand 207
CLUSTER operand 210
coding
system console 203
to support 3704/3705 control program 212
to support 3800 image library 210
TWX terminals 208
3270s 118
configuration aid 281
control unit error messages 214
CPNAME operand 210
CPTYPE operand 209
DEVTYPE operand 202
DPMSIZE operand 211
FCB operand 211
FEATURE operand 205
format 201
four-channel switch feature 205
IMAGE operand 210
MODEL operand 205
output spooling classes, defining 207
overview 200
SETADDR operand 209
subclass, defining for unsupported devices 207
two-channel switch feature 205
unit record error messages 214
using to define alternate paths 77
3704/3705 error messages 213
3704/3705 examples 212
real control blocks, real storage requirements 31
real I/O configuration file
BSC lines 191'
CLUSTER macro 192
coding
3270s 191
preparing 189
RCHANNEL macro 220
RCTLUNIT macro 215
RDEVICE macro 200
RIOGEN macro 221
sample configuration 223
sequence of macros 190
TERMINAL macro 194
real storage
allocated at virtual machine logon 33
requirements for CP 31
requirements for VM/SP 31
saved systems, DASD requirements 108
validating 102
REALTIMER, directory option 162
records, maximum usable number per CMS file 54
reducing the CP nucleus size 33
remote attachments, 3270s, planning considerations 115
remote hardware, supported configurations, 3270s 116
remote 3270s
eliminating support modules 33,34
restrictions 115
support 115
unsupported with Small CP option 33
RESERVE macro, reserving a device 85
reserve/ release
data integrity 86
DEQ macro 85
dynamic determination of support 86
handling reserve CCWs 85, 86
RESERVE macro 85
restrictions 88, 89
device sharing between real processors 88
device/minidisk sharing 89
shared DASD 84, 86
simulation 87
summary of support 88
using with operating systems 84, 86
virtual 87
reserved CCWs 87
resource identification codes
sample list 119
Index
313
3270s 117
restrictions
channel model-dependent functions 295
CMS 300
dynamically modified channel program 289
looping channel programs 289
minidisk 291
miscellaneous 302
MSS 299
processor model-dependent functions 295
reserve/release
device sharing between real processors 88
device/minidisk sharing 89
timing dependencies 294
virtual machine characteristics 296
RIOGEN macro
ALTCONS operand 221
CONS operand 221
examples 222
format 221
SRF operand 222
RMSIZE operand, SYSCOR macro 247
s
S-disk
CMS system disk
accessing 51
system macro libraries 48
system text libraries 49
S/370 Assembler 50
SAMGEN EXEC procedure
discontiguous saved segments 94
sample directory entries 150
saved segments
discontiguous 93
saved systems
CMS 56
DASD requirements 38,41
defining 230
naming 95,230
overview 93
sharing 95
SAVESEQ operand, NAMESYS macro 232
saving CMS 56
SCPINFO command, usage with MSSF 81
SCREEN, directory control statement 169
secondary storage protection, defined 1~4
segment table 31
SELECT operand, TERMINAL macro 196
SERIAL operand, SYSID macro 261
service record file
capability 28
operand, RIOGEN macro 222
SETADDR operand, RDEVICE macro 209
shared DASD
data integrity 86
environments 86
performance degradation 86
rationale 85
reserve/release support 84,86
restrictions 88, 89
shared segments
in AP /MP mode 93
protection 93, 94
sharing minidisks 64
SHRTABLE SHRPAGE pointer 93
simulated I/O devices, specifying 186
small CP option
314
VM/SP~
Planning Guide and Reference
support modules deleted
Missing interrupt 33
MVS Guest 33
remote 3270 33
TTY terminal 33
3066 33
3340 alternate track 33
3375/3380 33
3704/3705 33
3800 printer 33
3850MSS 33
SNACCS
eliminating support modules 33, 34, 127
NCP and PEP sharing 126
planning considerations 125
structure of the SNA environment 125
supported devices 8
tracing transactions
error trace 127
normal trace 126
unsupported with Small CP option 33
usage with IUCV 92
software support virtual machine, described 149
SPECIAL, directory control statement 186
SPOOL, directory control statement 177
spooling
accounting records, SYSACNT macro 256
DASD requirements 38,41
defining virtual devices 177
performance considerations 236
RDEVICE macro 207
specifying preferred spooling devices 263
SRFmode 28
SRF operand, RIOGEN macro 222
Staging Adapter, channel interface positions 132
start-stop lines, low speed 121
starter systems
FB-512, introduction 4
3330, introduction 4
3340, introduction 4
3350, introduction 4
3375, introduction 4
3380, introduction 4
STQUERY operand, SYSJRL macro 254
string switch feature 77
string switching 84
structure of the SNA environment 125
support package, 3704/3705 control program 121
SVCOFF, directory option 163
swap tables 31, 93
symbolic names, CMS devices 46
synchronous lines, medium speed 121
SYSACNT macro
CLASS operand 256
format 256
LIMIT operand 256
OUTPUT operand 256
spooling accounting records 256
USERID operand 256
SYSBLOK operand, NAMESYS macro 231
SYSCKP operand, SYSRES macro 242
SYSCLR operand, SYSRES macro 241
SYSCOR macro
AP operand 248
examples 248
format 247
FREE operand 101, 247
MP operand 248
RMSIZE operand 247
TRACE operand 248
SYSCYL operand, NAMESYS macro 231
SYSDUMP operand,SYSOPR macro 246
SYSERR operand, SYSRES macro 242
SYSFH operand, SYSORD macro 263
SYSFORM macro
DEFCON operand 258
DEFPRT operand 257
DEFPUN operand 257
examples 258
format 257
NARROW operand 257
OPERFORM operand 257
USERFORM operand 257
SYSHRSG operand, NAMESYS macro 231
SYSID macro
DEFAULT operand 261
examples 261
format 261
MODEL operand 261
SERIAL operand 261
SYSTEMID operand 261
SYSJRL macro
format 254
JOURNAL operand 254
LNKLMT operand 255
LNKUID operand 255
LOGLMT operand 255
LOGUID operand 254
PSUPRS operand 255
STQUERY operand 254
SYSLOCS macro
format 270
SYSMH operand, SYSORD macro 263
SYSMIH macro
DASD operand 267
example 269
format 267
GRAF operand 267
MISC operand 268
TAPE operand 267
UR operand 267
usage notes 268
SYSMON macro
AUTO operand 252
BUFFS operand 253
CLASS operand 252
ENABLE operand 252
example 253
format 251
LIMIT operand 253
TIME operand 252
USERID operand 251
SYSNAME operand, NAMESYS macro 230
SYSNUC operand, SYSRES macro 241
SYSOPER operand, SYSOPR macro 246
SYSOPR macro
example 246
format 246
SYSDUMP operand 246
SYSOPER operand 246
SYSORD macro
error messages 266
example 265
explained 264
format 263
SYSFH operand 263
SYSMH operand 263
SYSTEMP operand 263
SYSOWN macro
example 237
format 237
VOLID operand 237
SYSPCLAS macro
BOTIOM operand 259
C (spool file class) operand 259
examples 259
format 259
TITLE operand 259
TOP operand 259
usage notes 260
SYSPGCT operand
NAMENCP macro 233
NAMESYS macro 231
NAME3800 macro 234
SYSPGNM operand, NAMESYS macro 231
SYSRES macro
example 245
format 240
special coding considerations 239
SYSCKP operand 242
SYSCLR operand 241
SYSERR operand 242
SYSNUC operand 241
SYSRES operand 240
SYSTYPE operand 241
SYSVOL operand 240
SYSWRM operand 244
SYSRES operand, SYSRES macro 240
SYSSIZE operand, NAMESYS macro 230
SYSSTRT operand
NAMENCP macro 233
NAMESYS macro 231
NAME3800 macro 234
system consoles
coding RDEVICE macro 203
configuration aid 281
defining 221
system control file
CP-owned volumes for saved systems 93
performance considerations 236
preparing system control file 235
SYSACNT macro 256
SYSCOR macro 247
SYSFORM macro 257
SYSID macro 261
SYSJRL macro 254
SYSLOCS macro 270
SYSMIH macro 267
SYSMON macro 251
SYSOPR macro 246
SYSORD macro 263
SYSOWN macro 237
SYSPCLAS macro 259
SYSRES macro 239
SYSTIME macro 249
system definition
considerations for VSE 69
defining
your system 143
DMKRIO, preparation 189
introduction 4
options
performance 98
virtual = real 100
requirements
channel switching, one processor 76
channel switching, two processors 75
locally supported display 119
remotely attached display 116
Index
315
starter systems 4
introduction 4
supported SYSRES device types 4
3704/3705 requirements 122
3800 image library requirements 129
system dumps, defining a virtual machine to receive 151
system identification, SYSID macro 261
system integrity
APARs 145
defined 143
for MVS guest machines 144
your responsibilities 144
system macro libraries 48
system name table
creating an entry for 3704/3705 123
creating your own version 229
for saved systems 93
NAMENCP macro 233
NAMESYS macro 230
NAME3800 macro 234
preparing 229
system operator, SYSOPR macro 246
system residence devices, alternate tracks 61
system residence volume
sharing 74
system support
virtual machine description 149
system support virtual machines 149
system text libraries 49
System Timing facility 3,9
System/370
requirements
dynamic address translation feature 3
extended control mode 3
system timing facility 3
System/370 Extended Facility
processors supported 99
System/370 Extended Feature
attached processor restriction 99
processors supported 99
SYSTEMID operand, SYSID macro 261
SYSTEMP operand, SYSORD macro 263
Systems Network Architecture Console Communications
Services (see SNA CCS)
SYSTIME macro
examples 250
format 249
ID operand 250
LOC operand 249
ZONE operand 249
SYSTYPE operand, SYSRES macro 241
SYSVOL operand
NAMENCP macro 233
NAMESYS macro 231
NAME3800 macro 234
SYSRES macro 240
SYSWRM operand, SYSRES macro 244
T
T-DISK, defining 57
T -DISK, directory option 172
TAPE MODESET (example) 55
TAPE operand,SYSMIH macro 267
tapes
channel switching 76
CMS restrictions 55
configuration aid 283
control units supported by VM/SP 14
316
VM/SP Planning Guide and Reference
devices supported by VM/SP 14
dual density feature 206
handling, CMS/DOS 70
support for CMS 55
TCU (see Transmission Control Units)
Telegraph Control Type II Adapter 16
TERM operand, TERMINAL macro 195
TERMINAL macro
coding 194
control unit and device addressing 198
examples 197
FEATURE operand 197
format 195
MODEL operand 196
remote 3270 addressing 199
SELECT operand 196
TERM operand 195
terminals
adapters 20, 21
attachable 20
categories 20
required features 18
special considerations 18
supported as virtual system consoles 15
supported by VM/SP 15
supported on start/stop lines 122
TTY support 33, 34
TEST BLOCK
3081 hardware instruction, validating storage 102
text libraries
CMS 49
TIME operand, SYSMON macro 252
Time-of-DAY (TOD) clock
defining in SYSTIME macro 249
Time-Sharing Option (see TSO)
TITLE operand, SYSPCLAS macro 259
TOD clock (see Time-of-Day clock)
TOP operand, SYSPCLAS macro 259
trace entries, SNA CCS 126
TRACE operand, SYSCOR macro 248
trace table, CP real storage requirements 31
tracing for SNA Console Communications Services 126
tracks
alternate
3330 60
3340 60
3340 cylinder assignments 61
3350 60
minidisks, characteristics 60
transient area, CMS storage requirements 45
Transmission Control Units (TCUs)
configuration aid 281
Integrated Communications Attachment 26
remote terminal control unit support 22, 23
supported by VM/SP 24
2701 required features 25
2702 required features 25
2703 required features 26
3704/3705 required features 27
TSO, macro library for CMS 48
TSO, text library for CMS 49
TSOLIB txtlib 49
TSOMAC maclib 48
TTY
eliminating support modules 33,34
terminal support 33
unsupported with Small CP option 33
two-channel switch
feature 27, 77, 84
RDEVICE macro 205
two-channel switch additional feature 77
TWX terminals, coding RDEVICE macro 202, 208
u
unit record
control units supported by VM/SP 14
devices
configuration aid 284
support for CMS 47,56
supported by VM/SP 14
error messages for RDEVICE macro 214
universal character set 272
UNLOCK command, releasing virtual=real area 103
unsupported devices 204
defining subclass 207
UR operand, SYSMIH macro 267
USER
data collection class 252
directory control statement 158
user forms, specifying, SYSFORM macro 257
user program area, CMS storage requirements 45
USERFORM operand, SYSFORM macro 257
USERID operand
NAMESYS macro 232
SYSACNT macro 256
SYSMON macro 251
using performance options 98
v
VCNA, structure of the SNA environment 125
VIRT=REAL, directory option 163
virtual console, definition of 7
virtual disks 51', 52
virtual disks, defining in the directory 172
virtual machine assist 9
expanded 11 0
general information 109
performance option 98
Virtual Machine Communication Facility (see VMCF)
Virtual Machine/System Product (see VM/SP)
virtual machines
communication facility
IUCV 91
VMCF 92
control blocks 31
dedicating real devices 180
defining 147
in directory 158
spooling devices 177
the virtual console in the directory 171
hardware support 149
introduction 3
linking devices at logon 183
naming systems 229
operating systems 4
queue drop elimination 111
saving copies of operating system 93
saving the contents 165
sharing minidisks 64
sharing the system residence volume 74
software support 149
using reserve/release 86
VMSAVE directory option 165
virtual reserve/release 87
Virtual Storage Access Method (see VSAM)
Virtual Storage Extensions (see VSE)
virtual storage requirements 103
virtual storage, required by CMS 45
virtual system consoles, supported by VM/SP 15
Virtual Telecommunications Access Method (see VTAM)
virtual=real
bypassing CCW translation 100
calculating maximum size of area
examples 106
determining the size of CP 33
Formula 2 105
generating CP to support 101
overview 100
releasing the area 100
restrictions 101
specifying a virtual=real machine 100
specifying the amount of space 103
storage validation considerations 102
unsupported with Small CP option 33
use with multipoint teleprocessing system 101
virtual storage requirements 103
VM/SP
channel switching 74
components of 3
DASD requirements for the directory 38,40
DASD supported 11
defining you system 143
dump space, DASD requirements 38, 39
dump space, formula 39
Extended Control-Program Support 110
Field Developed Programs (FDPs) 275
Installed User Programs (IUPs) 275
introduction 3
minimum configuration 7
minimum configurations 7
paging, DASD requirements 38,41
Program Products (PPs) 275
real storage requirements
for CP 31
reducing the size of the CP nucleus 33, 34
reserve/release support 85
spooling, DASD requirements 38,41
support of the 3704 and 3705 122
supported devices 8
system definition
forms control buffer load 271
real I/O configuration file 189
system control file 235
system name table 229
virtual storage requirements 103
VM/SP directory 147
system generation, introduction 4
terminals supported 15
transmission control units supported 24
two-channel switch feature 27
3704/3705 control program support 122
VM/SP directory
DASD requirements 38,40
MDISK statement 64
VM/VS Handshaking feature 73
VM/370 Assembler 275
VMCF
overview 92
SMSG command 92
VMSAVE, directory option 165
VOLID operand, SYSOWN macro 237
VOLID, directory option 180
volume label contents, CMS formatted disks 52
VS APL, use with CMS 50
Index
317
VS BASIC, use with CMS 50
VSAM (Virtual Storage Access Method)
CMS support 65
CMS support for OS and VSE users 50
DASD devices supported 66
DASD requirements 42
data set compatibility with CMS 66
DOS/VS SORT/MERGE support 65
ISAM Interface Program (liP) 66
master catalog 65
minidisks 65
OS macro support 65
planning considerations 67
VSE macro support 65
VSAM and AMS requirements 42
VSAM, macro library for CMS 48
VSAMGEN EXEC procedure
discontiguous saved segments 94
VSE minidisks 59
VSE system generation considerations 69
VSE, macro library for CMS 48
VSEVSAM EXEC 48
VSYSADR operand, NAMESYS macro 230
VSYSRES operand, NAMESYS macro 230
VTAM Communications Network Application (see VCNA)
VTAM, structure of the SNA environment 125
VTOC, minidisk allocation 57
w
warm start data
calculating cylinders needed 245
DASD requirements 38, 39
defining cylinders 244
Word Buffer, processor feature 9
x
xxx-DEVICE feature, RCTLUNIT macro 218
z
ZONE operand, SYSTIME macro 249
1
1017, coding RDEVICE macro 202
1018, coding RDEVICE macro 202
1050, control units, models and features 19
1050, supported as a virtual console 16
1050, supported remotely on start-stop lines 122
1052, coding RDEVICE macro 202
1053, coding RDEVICE macro 202
1403
coding RDEVICE macro 202
font offset buffer 272
supported models 14
universal character set 272
1443
coding RDEVICE macro 202
supported models 14
318
VM/SP Planning Guide and Reference
2
2150
coding RDEVICE macro 202
supported models 15
2250, coding RDEVICE macro 202
2260, coding RDEVICE macro 202
2265, coding RDEVICE macro 202
2301, coding RDEVICE macro 202
2303, coding RDEVICE macro 202
2305
allocating DASD space for the directory 40
coding RDEVICE macro 202
CP DASD requirements 38
DASD space requirements
checkpoint start data 38
CP nucleus 38
error recording 38
paging 38
saved systems 38
spooling 38
VM/SP directory 38
warm start data 38
specifying in SYSRES macro 241
specifying preferred paging, SYSORD macro 263
supported models 11
2311, coding RDEVICE macro 202
2314
allocating DASD space for the directory 40
alternate tracks, minidisks 62
capacity for CMS minidisks 43
coding RDEVICE macro 202
CP DASD requirements 38
DA&1) space requirements
checkpoint start data 38
CP nucleus 38
error recording 38
paging 38
saved systems 38
spooling 38
VM/SP directory 38
warm start data 38
defective tracks 62
specifying in SYSRES macro 241
specifying preferred paging, SYSORD macro 263
used by OS in a virtual machine 76
2319
alternate tracks, minidisks 62
coding RDEVICE macro 202
defective tracks 62
specifying in SYSRES macro 241
2321, coding RDEVICE macro 202
2401
coding RDEVICE macro 202
supported models 14
2402
coding RDEVICE macro 202
supported models 14
2403
coding RDEVICE macro 202
supported models 14
2404
coding RDEVICE macro 202
supported models 14
2415
coding RDEVICE macro 202
supported models 14
2420
coding RDEVICE macro 202
supported models 14
2495, coding RDEVICE macro 202
2501
coding RDEVICE macro 202
supported models 14
2520, supported models 14
2520P, coding RDEVICE macro 202
2520R, coding RDEVICE macro 202
2540, supported models 14
2540P, coding RDEVICE macro 202
2540R, coding RDEVICE macro 202
2671, coding RDEVICE macro 202
2701
coding RDEVICE macro 202
emulation 122
features, required and optional 25
remote terminal support 25
2702
coding RDEVICE macro 202
emulation 122
features, required and optional 25
remote terminal support 25
2703
coding RDEVICE macro 202
emulation 122
features, required and optional 26
remote terminal support 26
2741
coding RDEVICE macro 202
features, required and desirable 18
supported as a virtual machine console 16
supported remotely on start-stop lines 122
2780, remote terminals 121
2803, supported models 14
2804, supported models 14
2816 Switching Unit 76
2821, supported models 14
2835, supported models 12
2844, supported models 12
2955, coding RDEVICE macro 202
3
3031, specifying system console 203
3032, specifying system console 203
3033
AP, channel-set switching 80
multiple service record files 28
specifying SRF devices 222
specifying system console 203
3036
coding RDEVICE macro 202
supported models 15, 17
3066
coding RDEVICE macro 202
eliminating support modules 33,34
supported models 15
unsupported with Small CP option 33
3081
AP, channel-set switching 80
Input/Output Configuration Program 82
Processor Controller 29
system monitoring and reconfiguration 81
TEST BLOCK instruction 102
3082 Processor Controller 81
3088 Multisystem Communication Unit
coding RDEVICE macro 202
overview 11
planning considerations 28
processors supported 11
3101
RDEVICE macro
coding considerations 202
specifying an adapter 208
supported models 16
supported remotely as CPT-TWX 33/35 122
3138, coding RDEVICE macro 201
3148, coding RDEVICE macro 201
3158, coding RDEVICE macro 201
3203
coding RDEVICE macro 202
font offset buffer 272
forms control buffer 271
supported models 14
universal character set 272
3210
coding RDEVICE macro 202
supported models 15
3211
coding RDEVICE macro 202
font offset buffer 272
forms control buffer 271
supported models 14
universal character set 272
3213, supported models 14
3215
coding RDEVICE macro 202
console simulation 17
supported models 15
3230
coding RDEVICE macro 202
3232
supported models 16
supported remotely as CPT-TWX 33/35 122
3262
coding RDEVICE macro 202
font offset buffer 272
forms control buffer 271
supported models 14,20
universal character set 272
3268
coding RDEVICE macro 202
3270
coding CLUSTER macro 192
coding TERMINAL macro 194
control unit and device addressing 198
determining line code 117
device addressing 198
local configurations supported 21
models and features 20
planning considerations 115
remote (see remote 3270s)
remote 3270 support requirements 116
resource identification codes sample list 119
sample remote configuration 118
screen copy support 115
support for local configurations 119
support on binary synchronous lines 116
system generation requirements 116, 119
3270 support on binary synchronous lines 116
3271
CLUSTER macro 191, 192
required features 22
supported attachments 20
supported models 22
3272
required features 21
supported attachments 20
Index
319
supported models 21
3274
CLUSTER macro 191, 192
supported attachmeDls 20
supported models 21, 22
3275
CLUSTER macro 191, 192
coding real 1/0 macros 191
coding the TERMINAL macro 195
required features 23
supported models 16, 23
3276
CLUSTER macro 191, 192
coding the TERMINAL macro 195
required features 23
supported models· 16, 22
3277
coding RDEVICE macro 202
coding the TERMINAL macro 195
supported models 16, 17, 20
3278
coding RDEVICE macro 202
coding the TERMINAL macro 195
supported models 15, 17,20,22
3279
coding RDEVICE macro 202
coding the TERMINAL macro 195
supported models 15, 17, 20, 22
3284
coding RDEVICE macro 202
coding the TERMINAL macro 195
supported models 20, 23
3286
coding RDEVICE macro 202
coding the TERMINAL macro 195
supported models 20, 23
3287
coding RDEVICE macro 202
coding the TERMINAL macro 195
supported models 14, 20, 22
3288
coding RDEVICE macro 202
coding the TERMINAL macro 195
supported models 20
3289
coding RDEVICE macro 202
coding the TERMINAL macro 195
font offset buffer 272
forms control buffer 271
supported models 14, 20, 22
universal character set 272
3310 11, 43, 263
3310 (see also FB-512)
3330
allocating DASD space for the directory 40
alternate tracks, minidisks 60
capacity for CMS minidisks 43
coding RDEVICE macro 202
CP DASD requirements 38
DASD space requirements
checkpoint start data 38
CP nucleus 38
error recording 38
paging 38
saved systems 38
spooling 38
VM/SP directory 38
warm start data 38
specifying in SYSRES macro 241
specifying preferred paging, SYSORD macro 263
320
VM/SP Planning Guide and Reference
starter system
forms control buffer supplied 271
supported models 11
3330-1, copying to 3330V volumes 138
3330V
coding RDEVICE macro 139,202
copying 3330-1 volumes to 138
demounting 133
directory option 180
mounting 133
used as VM/SP system volumes 133
using for VS system residence 133
3330V volumes as VS system residence 138
3333
coding RDEVICE macro 202
supported models 11
3340
allocating DASD space for the directory 40
alternate tracks, eliminating support modules 33,34
alternate tracks, minidisks 60
alternate tracks, unsupported with Small CP option 33
capacity for CMS minidisks 43
coding RDEVICE macro 202
CP DASD requirements 38
cylinder assignments 61
DASD space requirements
checkpoint start data 38
CP nucleus 38
error recording 38
paging 38
saved systems 38
spooling 38
VM/SP directory 38
warm start data 38
DDR utility 61
error recovery 61
specifying in SYSRES macro 241
specifying preferred paging, SYSORD macro 263
starter system
forms control buffer supplied 271
starter system considerations 62
supported models 11
3344
DDR utility 61
error recovery 61
3345, supported models 12
3350
allocating DASD space for the directory 40
alternate tracks, minidisks 60
capacity for CMS minidisks 43
coding RDEVICE macro 202
CP DASD requirements 38
DASD space requirements
checkpoint start data 38
CP nucleus 38
error recording 38
paging 38
saved systems 38
spooling 38
VM/SP directory 38
warm start data 38
special features
Control Store Extension 13
Expanded Control Store 13
specifying in SYSRES macro 241
specifying preferred paging, SYSORD macro 263
starter system
forms control buffer supplied 271
supported models 11
3370 11,43,263
3370 (see also FB-512)
3375
allocating DASD space for the directory 40
capacity for CMS minidisks 43
coding RDEVICE macro 202
CP DASD requirements 38
DASD space requirements
checkpoint start data 38
CP nucleus 38
error recording 38
paging 38
saved systems 38
spooling 38
VM/SP directory 38
warm start data 38
eliminating support modules 33,34
specifying in SYSRES macro 241
specifying preferred paging, SYSORD macro 263
starter system
forms control buffer supplied 271
unsupported with Small CP option 33
3380
allocating DASD space for the directory 40
capacity for CMS minidisks 43
coding RDEVICE macro 202
CP DASD requirements 38
DASD space requirements
checkpoint start data 38
CP nucleus 38
error recording 38
paging 38
saved systems 38
spooling 38
VM/SP directory 38
warm start data 38
eliminating support modules 33,34
specifying in SYSRES macro 241
specifying preferred paging, SYSORD macro 263
starter system
fonns control buffer supplied 271
unsupported with Small CP option 33
3410
coding RDEVICE macro 202
supported models 14
3411
supported models 14
3420
coding RDEVICE macro 202
supported models 14
3430
supported models 14
3505
coding RDEVICE macro 202
supported models 14
3525
coding RDEVICE macro 202
supported models 14
370E, directory option 165
3704
coding RDEVICE macro 202
supported models 122
3704/3705
creating an entry in the system name table 123
eliminating support modules 33,34
error messages for RDEVICE macro 213
examples of RDEVICE macro 212
features not supported 27
line speeds 121
miming the control program 233
planning considerations 122
RDEVICE macro coding considerations 211,212
required features 27
reserving DASD space for control program image 123
storage sizes 211
support provided by 121
supported models 27
unsupported with Small CP option 33
3704/3705 control program
.
(EP) Emulation Program 122
introduction 121
minimum storage required 122
planning considerations 122
related publications 121
support package 121
basic material 121
support under VM/SP 122
terminals supported 121
3705
coding RDEVICE macro 202
supported models 122
3767
required features 24
supported models 17, 24
supported remotely as a 2741 122
3800
coding RDEVICE macro 202
eliminating support modules 33,34
hardware features supported 130
image library
coding RDEVICE macro to support 210
generating VM/SP to support 129
named system
creating 129
specifying delayed purge queue 211
updating 129
planning considerations 129
related publications 130
supported models 14
unsupported with Small CP option 33
3803, supported models 14
3811, supported models 14
3830
specifying 64-device feature 215
supported models 12
3850 Mass Storage System (MSS)
communication device, defining 136
communicator program 134
copying 3330-1 volumes to 3330V volumes 138
creating MSS volumes 138
eliminating support modules 33,34
generating VM/SP to support 131
Mass Storage control tables 136
minidisks 59
missing interrupt handler support 84
OS/VS1 jobs 134
OS/VS2 jobs 135
performance note 97
supporting processors 131
unsupported with Small CP option 33
3851
coding RDEVICE macro 202
Mass Storage Facility 131
missing interrupt handler support 84
3880
buffer features 13
director modules, channel switching 76
speed matching operation 13
supported models 12
Index
321
322
4
7
4245
coding RDEVICE macro 202
forms control buffer 271
supported models 14
4250
coding RDEVICE macro 202
supported models 20
4331, specifying system console 203
4341, specifying system console 203
7412, supported models 15
7443, coding RDEVICE macro 202
VM/SP Planning Guide and Reference
8
8809
coding RDEVICE macro 202
supported models 14
SC19-6201-3
<
~
""'-
en
"'tI
.,"'tI
:r
P+
CD
c.
:i"
!=
en
~
en
n
CD
I
en
o
N
I
W
- - ---- ------
-
-~-,-
®
VM/SP Planning
GuidQ and Reference
SC19-6201-3
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. You may use this form to communicate your
comments about this publication, its organization, or subject matter, with the understanding
that IBM may use or distribute whatever information you supply in any way it believes
appropriate without incurring any obligation to you.
Your comments will be sent to the author's department for whatever review and action, if
any, are deemed appropriate. Comments may be written in your own language; English is
not required.
..:C g
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.
CD _Q
E
U)
.~:E
=.-
g~
Ie)
U)
.5 Q
t:-
E~
E
~ E
co
E Ie)
"'C
=
=
CD
...
.c
co -Q
.c
.~
~
No
o
o
o
o
o
o
o
o
0.
=.f!
_Q
• Does the publication meet your needs?
CD
Q
en
Yes
:s
CD
E:.e
CD rn
:E~
rn
• Did you find the material:
Easy to read and understand?
Organized for convenient use?
Complete?
Well illustrated?
Written for your technical level?
e
• What is your occupation?
CD rn
en
rn
• How do you use this publication:
As an introduction to the subject?
o
o
o
o
o.e
= e=
fJ
C
0.
co
CD
Co)
en
en
CD CD
=
a.:
.:9.!!!
~
For advanced knowledge of the subject?
To learn about operating procedures?
o
o
o
As an instructor in class?
As a student in class?
As a reference manual?
o
o
o
c..
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 or
you may mail directly to the address in the Edition Notice on the back of the title page.)
SC19-6201-3
n
~
~
Reader's Comment Form
'11
0
Ii
~
0:s
IQ
r:;-
• <
s:
..........
en
'1J
'1J
or
::J
::J
5'
Please Do Not Staple
Fold and Tape
Fold and Tape
co
G)
c:::
a:
III
CD
Q)
NO POSTAGE
NECESSARY
IF MAILED
INTHE
UNITED STATES
::J
C.
jJ
CD
CD
....
CD
.....
::J
(')
-CD::n
CD
BUSINESS REPLY MAIL
FIRST CLASS
PERMIT NO. 40
z
ARMONK, N.Y.
9
en'
w
-..,J
POSTAGE WILL BE PAID BY ADDRESSEE:
0
..........
~
w
I nternational Business Machines Corporation
0
0
Department G60
I
W
P. O. Box 6
.:f:!
Endicott, New York 13760
'1J
~.
::J
CD
c.
5'
Fold
Fold
If you would like a reply, please print:
YourName _____________________________________________________
Company Name ____________________________ Department ___________
Street Address _______________________________
City _______________________________________
~
en
~
en
n
..a.
co
I
en
N
---- ----~
-----_
....
-------
- --
~
-~-.
®
State _________,.----------- Zip Code _ _ _ _ __
IBM Branch Office serving you ____________________________________
0
..a.
I
W
SC19-6201-3
"'0
or
::J
::J
::J
co
G)
c::
c.:
(t)
Q)
::J
a.
:0
....,
(t)
(t)
""'
(t)
::J
C')
(t)
:::!1
CD
z
9
en
w
'-J
o
..........
.,J:::.
w
o
oI
W
~
"'0
:::!.
::J
.-+
(t)
a.
::J
C
en
~
en
()
(0
I
0)
N
o
.....
I
W
-..-.--- . .-.------- ------
-- -
-~-,-
®
Download PDF
Similar pages