SY20 0885 0_VM370_System_Logic_and_Problem_Determination_Guide_1976 0 VM370 System Logic And Problem Determination Guide 1976
User Manual: SY20-0885-0_VM370_System_Logic_and_Problem_Determination_Guide_1976
Open the PDF directly: View PDF 
.
Page Count: 665
| Download | |
| Open PDF In Browser | View PDF |
SY20-0885-0
IBM Virtual Machine Facility/370:
System Logic and Problem Determination Guide
1976
Page Missing From
Original Document
Page Missing From
Original Document
PREFACE
This publication provides the IBM system
hardware and software support personnel
with the information needed to analy~e
problems that may occur on the IBM Virtual
Machine Facility/370 (VM/370).
"Section 4. Diagnostic Aids" contains
.debugging commands for problem solving,
~ait state
and ABEND codes, error codes,
ret,urn codes, and information about the
DASD'Dump Restore Program.
CMS/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 DOS simulation mode of
CMS is currently active; that is, the eMS
command
"Section
5.
Appendixes"
contains
reference information that may be useful
when Qebugging VM/370, such as: the VM/370
pr09~amming
restrictions,
the CMS
ZAP
Service Program, and the VM/370 coding
conventions and equate symbols.
SET DOS ON
has been previously issued.
The phrase "CMS file system" refers to
disk files that are in CMS's 800-byte bloc~
format; CMS's VSAM data
sets are not
included.
A system failure is usually accompanied
by a dump of processor storage.
The dump
can occur by means of an automatically
invoked dump program, or a standalone dump
program.
An example of a standalone dump
program is:
·HOW TO. USE THIS MANUAL
•
Use the problem determination part of
section 1 to help you to determine what
type of error has occurred. Write down
a1~
error messages,
ABEND codes and
return codes, and
obtain a storage
dump.
•
Consult the !~Ll1Q: ~~§!~! ~~§§g~~§ for
information about the error message,
ABEND code, or return code. The !~L11Q:
~~§!~~ Me22gg~2 also
contains extensive
cross-reference information that may be
·he1pfu1 to you.
•
Isolate the component of VM/370 in which
the problem occurred.
•
Use the list of restrictions in "Section
5. Appendixes" to be certain that the
operation that was being performed was
valid.
BPS Storage Print Program, No. 360-UT-056
HOW THIS MANUAL IS ORGANIZED
This manual contains five sections:
"Section
1.
Introduction"
contains
debugging
information
about
error
conditions that may occur within VM/310.
This debugging information tells you what
to do about ABENDs, loops, wait states, and
incorrect output. Section 1 also contains
a brief description of three of the VM/370
components.
The components
that
are
described are: the VM/370 Control Program
(CP), the Conversational Monitor System
(CMS),
and
the
Remote
Spooling
Communications Subsystem (RSCS).
"Section 2. Method of Operation and
Program
Organization"
contains
the
functions and relationships of the program
routines in VM/370.
section 2 indicates
the program operation and organization in a
general way
to serve as a
guide in
understanding the programming of VM/370.
It is not meant to be a detailed analysis
of VM/370 programming and cannot be used as
such.
"Section 3.
Directories"
contains a
description of all the asse.ble modules in
CP, CMS,
and RSCS.
It also contains
extensive cross-references between modules
and labels within a VM/370 component.
•
Use "Section 3. Directories" and use the
Data Areas and Control Block
~2~!f
to---he1p--you-~0 --isolate--the
problem.
!~Ll1~:
•
Use "Section 2. Method of Operation and
Program Organization" if necessary, to
understand the operation that was being
performed.
PREREQUISITE PUBLICATIONS
!~~ !!~!yg! ~~fh!n~ Igf!!!!~Ll1Q:
1~!~QgYf!!2~,
Order No.
GC20-1800
Order
No.
COREQUISITE PUBLICATIONS
!~~ Q~L!§ ~Bg Y~L11Q !22gm~!g£ g£Qg£~mmg£~2
§~i~g,
!~~
Order No.
Q~L!§,
1~gg~~gg,
GC33-4021
~Q~LY§, ~Bg
Order No.
Y~L11Q
GC33-4010
!§§g!£!g£
§~2~gm ~g22~gg2'
Order No.
GC20-1808
SECTION 1. INTRODUCTION • • • • • • • • • 11
Introduction To Debugging.
11
How To Start Debugging • •
• • • • 11
Does a Problem Exist? . • • •
11
Analyzing the Problem. • •
.' •• 12
Using VM/370 Facilities to Debug ~
12
CP Abnormal Termination.
••
12
CP Termination without a Dump. . 1 6
CM S Abnormal Termina tion • •
• • • 16
Virtual Machine ABEND (Other Than CMS) 18
Unexpected Results • • • • • • • • • • 23
Unexpected Results in CP • • • •
23
Unexpected Results in a Virtual
Machine • • • •
• • • • 23
Loops. • • • • • •
• • • • 23
CP Disabled Loop •
• • • • 24
Virtual Machine Disabled Loop. • • • • 24
Virtual Machine Enabled Loop •
24
WAIT • • • • • • • •
• • • • 24
CP Disabled Wait • • • •
25
CP Enabled Wait. • • • •
• • 26
Virtual Machine Disabled wait • • • • • 26
virtual Machine Enabled Wait • • • • • 26
RSCS Virtual Machine Disabled Wait • • 27
RSCS Virtual Machine Enabled Wait • • • 28
Summary of VM/370 Debugging Tools • . • • 29
Comparison of CP and CMS Facilities for
Debugging • • • • • • • • • • • • •
33
Debugging CP on a virtual Machine • • • • 34
ABEND Dumps. • • • • • • • • • • • • • 34
Us in g the VMFDUMP Command. • • • • • • 34.
How to Print A CP Abend Dump From Tape 35
Reading CP ABEND Dumps • •
35
Reason for the ABEND •
• • • • 35
Collect Information.
• 36
Register Usage • • • • •
• • • • 36
Save Area Conventions. •
• • • • 36
Virtual and Real Control Block status. 37
VMBLeK •
• 37
VCHBLOK. •
• • • • 37
VCUBLOK.
• • • • 38
VDEVBLOK • • •
• • • • 38
RCHBLOK.
• • • • • • • • • • 39
RCUBLOK.
39
RDEVBLOK •
• • • • • • • 39
Identifying a Pageable Module. • • • • 40
Reading CMS ABEND Dumps. •
• • • • 41
Reason for the ABEND • • • • • • • • • 41
Collect Information.
• • • • 41
NUCON AREAS. • • •
41
Register Usage • • •
• • 43
Nucleus Load Map • •
• • 43
Load Map • • • •
• 43
CP Introduction. •
• • • • 45
CP Initialization. •
• • • • 45
Virtual Machine Management • • • • • • 46
Spooling • • • • • • • • • • • • • • • 47
Console Functions. • • • •
• • • • 48
Program States • • • • • •
• • • • 48
Preferred virtual Machine.
• • • • 48
VM/VS Handshaking. • • • •
• • • • 50
CP Interruption Handling • • • •
• 52
Free Storage Management. • . • •
• 53
storage Protection • • • • • • •
• 54
Executing the Pageable Control Program 54
System Support Modules • • •
• 55
Control Register Usage • • .
• 55
Restr~ctions and Conventions for
pageable CP Modules
55
Data Area Modules. •
• 55
Interruption Handling. • •
• 55
. SVC Interruptions • •
• 55
Executable Modules •
• 56
External Interruptions •
• 57
Program Interruptions. • • • • •
• 57
Virtual Timer Maintenance • •
• 65
I/O Management • • • • • • • • •
66
I/O Supervisor • • • • • • • • •
• 66
Real I/O Control Blocks. • • • •
• 66
Virtual I/O Requests • • •
• • • 67
I/O component States • • •
• 69
I/O Interruptions. • • • •
• 70
Virtual I/O Interruptions.
• 70
Scheduling I/O Requests. • •
• 71
Virtual Console Simulation.
• 72
Remote 3270 Programming. • •
• 73
I/O Programs for Bisync Lines and
Remote 3270s • • • • • • • • • • • • • 74
Data Formats - Bisync Lines and Remote
3270. • • • • • • • • •
• 75
Allocation Management. • •
• 76
Normal paging Requests • •
• 76
DASD Storage Management. •
• 80
Paging I/O • • • • • • • •
• 81
Virtual Storage Paging Error Recovery. 82
Virtual Relocation • • • • • • •
• 82
Free storage Management. • •
• 84
CP Ini tializa tion. • • • • •
• • 85
Initialization and Termination •
• 85
Console Functions. • • • •
• 88
Dispatching and Scheduling •
• 88
CP Spooling. • • • • • • • •
• 93
Spool Data and File Format •
• 93
spool Buffer Management. • • • • • • • 94
Virtual Spooling Manager (DMKVSP). • • 94
Real spooling Manager (DMKRSP) • • • • 96
Spooling Commands • • • • • • • • • • • 97
spool File Error Recovery • • • • • • • 99
Recovery from System Failure • • • • • 100
Recovery Management Support (RMS) • • • 100
system Initialization for RMS • • • • • 100
Overview of Machine Check Handler • • • 101
system/370 Recovery Features • • • • • 101
Overview of Channel Check Handler • • • 105
Channel Control Subroutine • • • • • • 105
Individual Routines • • • • • • • • • • 106
Error Recording Interface for Virtual
Machines. • • • • • • • • •
.107
Error Recording and Recovery • • • • • 107
Error Record Writing • • • • • • • • .107
DASD Error Recovery, ERP (DMKDAS) • • • 108
Tape Error Recovery, ERP (DMKTAP). • .109
3270 Remote Support Error Recovery • • 110
The Conversational Monitor system (CMS).111
The CMS Command Language
• • 111
The File System. • • • •
.111
Program Development. • •
• • 112
Interruption Handling in CMS •
• .112
Functional Information. •
.115
structure of CMS storage
• • 116
Free Storage Management. •
.116
CMS Handling of PSi Keys.
• .123
CMS SVC Handling. • • • •
• .124
SVC Types and Linkage Conventions.
.124
User and Transient Program Areas . • • 126
Called Routine Start-up Table. • •
• 126
Returning to the Calling Routine.
.126
CMS Interface for Display Terminals • • 129
os Macro simulation under CMS • • • • • 130
os Data Management Simulation. • •
.130
Handling Files that Reside on C~S
Disks • • • • • • • • • • • • • • • • 130
Handling Files that Reside on os or
DOS Disks. • • • • • •
• • • • 130
simulation Notes • • • • • • • • • • • 131
Access Method su pport. • •
• • • 134
Reading OS Data Sets and DOS Files
Using OS Macros • • • •
• • 136
DOS/VS Support under CMS
• • • 137
CMS Support for OS and DOS VSAM
Functions • • • • • • • • • • • • • • 138
RSCS Introduction. . • • • •
• .138
Remote Spooling Communications
Subsystem: Overview • • • • • • • • • • 138
The RSCS Virtual Machine and the
VM/370 Control Program (CP)
• • 139
Locations and Links. • • • •
• • • 139
Remote Stations • • • • • • •
• •• 139
Betwork Control: RSCS and VM/370
Commands. • • • • • • • •
• • • • 140
RSCS Commands. • • • • • •
• • • • 140
VM/370 CP and CMS Commands For RSCS • • 140
The RSCS Control Program.
• • • • 141
The RSCS Supervisor. • •
• • • • 141
Ta sk Management. • • • •
• • 141
I/O Management • • • • •
• • 142
Interruption Handling. •
• • • • 142
Virtual Storage Management
• • • • 142
RSCS Task Structure. • • •
• • • • 142
Crea te System Tasks: DMT CRE. • • • • • 143
Process Commands: DMTCMX •
• .143
Process Messages: DMTMGX • • • • • • • 143
Terminate system Tasks and Handle
Program Checks: DMTREX • • • • • • • • 143
Communicate with the VM/370 Spool
File System: DMTAXS • • • • • • • • • 144
Manage Telecommunication Line
Allocation: DMTLAX • • • • • • • • • • 144
Line Driver Tasks: DMTNPT and DMTSML .144
The SML Line Driver Program • • • • • • 144
SML Processors • • • • • • • • • • • • 145
The SML Line I/O Handler Routine:
COMSUP • • • • • • • • • • • • • • • • 145
The SML Function Selector Routine:
$START • • • • • • • • • • • • • • • • 145
Block and Deblock SML Teleprocessing
Buffers: $TPPUT and $TPGET • • • • • • 145
The NPT Line Driver Program • • • • ~ • • 146
The NPT Line Monitor Routine: LIBEIO .146
The NPT Function Selector Routine:
BPTGET • • • • • • • • • • • • • • • • 146
NPT Input File Processing • • • • • • • 146
NPT Output Processing Routines • • • • 147
Major Data Areas • • • • • • • • • • • 147
SVECTORS: Supervisor Control Queues
and Supervisor Routine Addresses • • • 147
RSCS Supervisor Queue Elements • • • • 147
MAINMAP: storage Available to RSCS
.147
Programs and Tasks • • • • • • •
TAREA: The Save Area for an
.147
Interrupted Task • • • • • • • •
.147
LINKTABL: Link Description Data.
.147
TAG: The RSCS File Descriptor. •
.147
RSCS Request Elements • • • • • •
VM/370 Data Areas Referenced by RSCS .148
RSCS storage Requirements • • • • • • • 148
synchronizing and Dispatching Tasks • • .149
• 149
The WAIT/POST Routines • • • •
.149
Synchronization Locks. • • • •
Asynchronous Interruptions and Exits .149
using Asynchronously Requested
Services: DMTWAT. • •
.150
Posting a Synch Lock. • • • • •
.150
Dispatching in RSCS. • • • • • •
.150
Task-to-Task Communications. • •
.150
ALERT Task-to-Task Communication
.150
GIVE/TAKE Task-to-Task Communication .151
Input/Output Methods and Techniques • • 152
Active and Pending I/O Queues • • • • • 152
Handling Link Activity: LINKTABLs and
TAGs • • • • • • • • • • • • • • • • • 152
How Links Handle Files • • • • • • • • 152
Transmitting VM/370 Files to an RSCS
Link. • •
• • • • • • • • • • • 153
Processing Files from Remote Stations.153
SECTION 2. METHOD OF OPERATION AND
PROGRAM ORGANIZATION • • • • •
.155
CMS Program Organization • •
.155
Introduction to CMS • • • • •
.160
Initialize the CMS Virtual Machine
Environment • • • • • • • • • • • • • 160
Initialization: Loading a CMS Virtual
Machine from Card Reader • • • • • • • 160
Initializing a Named or Saved System .162
Handle the First Command Line Passed
to CMS • • • • • • • • • • • • • • • • 162
Setting and Querying Virtual Machine
Environment Options • • • • • • • • • 163
Process and Execute eMS Files • • • • • 163
Maintaining an Interactive Console
Environment • • •
•••••
.163
Console Management and Command
Handling in CMS • • • • • • • •
.163
Maintaining an Interactive
Command/Response Session • • • •
.163
Method of Operation for DMSINT •
.164
Method of Operation for DMSITS •
.165
Load and Execute Text Files. • .' •
.168
Process Commands That Manipulate the
File System • • • • • • • • • •
.177
Manage the CMS File System • • •
.177
How CMS Files are Organized in
Storage • • • • •
.177
File Status Tables
• 177
Chain Links. • • •
.178
CMS Record Formats • •
.178
Disk Organization in CMS • • • • • • • • 178
Physical Organ~zation of Virtual
Disks • • • • • • • • • • • • • • • • 180
The Master File Directory. • • • • • • 180
Keeping Track of R/W Disk storage:
QMSK and QQMSK • • • • • • • • • • • • 180
Dynamic storage Management: Active
Disks and Files • • • • • • • • • • • 182
CMS Routines Used to Access the File
System. • • • • • • • • • •
• .182
Input/Output Operations. • •
• •• 182
Unit Record I/O Processing.
• .183
Handle Interruptions. • •
• • • • • 184
DISK I/O IN CMS. • • • • •
• .184
Manage CMS Free Storage. • •
• .185
Simulate Non-CMS Operating Environments. '192
Access Method support for Non-CMS
Operating Environments. • • • • • • • • 193
CMS Support for the virtual storage
Access Method. • • • • • •
• • • • 193
Creating the DOSCB Chain • • • • • • • 193
Executing an AMSERV Function • • • • • • 193
Executing a VSAM Function for a DOS
User. • • • • • • • • • • • • •
• .194
CMS/DOS SVC Handling • • • • • • • • • 195
Executing a VSAM Function for an os
User. . . . . . . . . . . . .
• • • 196
Completion Processing for os and DOS
VSAM Programs. • • • • • •
• •• 19a
OS Simulation by CMS • • • • •
• 198
Simulating a DOS Environment Under
CMS • • • • • • • • • • • •
• .207
Initializing DOS and processing DOS
System Control Commands • • • • • • • 207
setting or Resetting system
Environment Options. • • • •
• .208
Process CMS/DOS OPEN and CLOSE
Functions. • • • • • • • • •
• .209
Process CMS/DOS Execution-Related
Control Commands • • • • • • • • • • • 210
Simulate DOS SVC Functions • • • • • • 211
SVCs Treated as No-Op by CMS/DOS • • • 213
Process CMS/DOS Service Commands • • • 213
Terminate Processing the CMS/DOS
Environment • • • • • • • • • • • • • 213
Perform Miscellaneous CMS Functions •• 213
CMS Batch Facility • • • • • • • • • ~213
General Operation of DMSBTB • • • • • • 213
General Operation of DMSBTP • • • • • • 214
Other CMS Modules Modified in CMS
Batch • • • • • • • • • • • • • • • • 215
CP Program Organi zation. • • • • • • • .216
Use of the Annotated Flow Diagram • • • 216
VM/370 CP Interruption Processing • • • 216
SVC Interruptions - Problem state • • • 216
SVC Interruptions - Supervisor state .216
External and Clock Interruption
Reflection • • • • • • • • • • • • • • 217
MONITOR Interruption Processing • • • • 217
Program Interruption Processing • • • • 217
virtual I/O Operations and Interruption
Processes • • • • • • • • • • • • • • • 218
CTCA Operations Between Two virtual
Machines.
• • • • • • • • • • 218
Scheduling I/O for CP and the Virtual
Machine • • • • • • • • • • • • • • • 218
Standard DASD I/O Initiated via
Diagnose. • • • • • • • • • • •
.219
General I/O Operation Initiated Via
01agnose. • • • • • • • • • • •
.219
virtual Machine I/O Instruction
simulation and Interruption
aeflection. • • • • • • • • • •
.219
Virtual Console Simulation. • •
.219
LQcal Graphic I/O and Interruption
Processing • • • • • • • • • • • • • • 220
Locate and Validate an ISAM Read
$equence • • • • • • • • • • • • • • • 220
S~heduling CP and Virtual Machine 1/0
operations and Interruption Handling.221
Terminal Console I/O Control,
START/STOP, 3210, 3215, and Others • • 222
Console Scheduling. • • • • • •
.222
3704/3705 Interruption Handler.
.223
Handling Remote 3270 with Binary
Synchronous Lines • • • • • • •
.224
Real Storage Allocation and Page
'Management. • • • • • • • • • •
.225
Reading/Writing a DASD page To/From
Virtual Storage • • • • • • • • • • • 225
Allocation and Deallocation of DASD
Space • • • • • • • • • • • • • • • • 226
Shared segment Storage Management • • • 226
Temporary Disk storage Management • • • 226
Paging I/O Scheduler • • • • • • • • .227
Release Virtual Storage Pages • • • • • 227
Free Storage Managemen t. • • • • • • .227
CP Initialization and Termination
Procedures. • • • • • • • • •
.228
Virtual Machine Initialization and
Termination. • • • • • • • • •
.229
Console Function (CP Command)
Processing. • • • • • • • • •
.230
Dispatching and Scheduling. • •
.231
Spoooling Virtual Device to Real
Device. • • • • • • • • • • • •
.232
Spooling to the Real Printer/Punch
output Device • • •
• • • • • .233
spooling to the Real Input Device • • • 234
Spool File Deletion • • • • • • • • • • 234
Recovery Management Support operation.234
User Directory Routines. • • • • • • .236
Save the 3704/3705 Control program
Image Process • • • • • • • • • • • • 236
Spool File Checkpoint and Recovery • • 236
RSCS Program Organization. . • • •
.238
SECTION 3. DIRECTORIES • • • • • •
CMS Module Entry Point Directory •
. CMS Module-to-Label Cross Reference. •
CMS Label-to-Module Cross Reference • •
CP Module Entry Point Directory • •
CP"Module-to-Label Reference • • •
CP Label-to-Module Cross Reference ••
RSCS Module Directory. • • • • • •
RSCS Module Entry Point Directory.
RSCS Module-to-Label Cross Reference •
RSCS Label-to-Module Cross Reference •
.245
.247
.265
.281
.321
.341
.373
.447
.455
.465
.469
SECTION 4. DIAGNOSTIC AIDS • • • • • •
CP Internal Trace Table • • • • • • • •
CP Commands Used To Debug the Virtual
Machine
• • • •
ADSTOP • • • • • • • • • • • • • • • •
• 477
• 477
.479
.480
BEGIN. •
• • • • • • • 482
DISPLAY ••
• • • • 483
DUMP •
• • • • 489
SET. •
• • • • 492
STORE.
• • • • 499
SYSTEM • •
• • • • 502
TRACE.
.503
CP Commands for System Programmers and
system Analysts.
• • • • 508
DCP. • • • • • • •
• • • • • • • 509
DMCP • • •
• • • • 511
LOCATE. •
• • • • 513
MONITOR. •
• • • • •
• • • • • 514
QUERY. • •
• .515
STCP • • •
• • • • • • • • • 528
DASD Dump Restore (DDR) Service Program
and How To Use It • • • • • • • • • • • 529
Invoking DDR under CMS • • • • • • • .529
Invoking DDR as a Standalone Program .530
DDR Control statements • •
• .530
I/O Definition statements.
• • • • 531
CP Wait State Codes. • • •
• .540
CP ABEND Codes. • • • • • •
• .542
CMS Return Codes. • • • • •
• .557
CMS DMSFREX Error Codes. • • • •
• .558
Error Codes from DMSFREE, DMSFRES, and
DMSFRET • • • • • • •
•• ••
.558
CMS ABEND Codes. • • • • • • • • •
.559
ABEND Recovery • • • • • • • • •
.559
RSCS Message-To-Label Cross Reference • • 563
CMS Commands for Debugging.
• • • • 568
DEBUGGING with CMS •
• • • • • 568
CMS Debugging Commands • • • • • • • • • 568
DEBUG • • • • • • • • • • • • • • • • • 568
SVCTRACE • • • • • • • • • • • • • • • 584
DASD Dump Restore Service Program and
How To Use It • • • • • • • • • • • • • 586
Invoking DDR under CMS • • • • • • • • 586
Invoking DDR as a Standalone Program .586
SECTION 5. APPENDIXES. • • • •
.587
APPENDIX A: VM/370 CODING CONVENTIONS •• 589
CP Coding Conventions • • • • • • • • • • 589
CP Loadlist Requirements • • • • • • • • 590
APPENDIX B: CP AND RSCS EQUATE SYMBOLS
VM/370 Device Classes, Types, Models
and Features • • • • • • • • • • • • •
VM/370 Machine Usage • • • • • • • • •
VM/370 Extended Control Registers • • •
VM/370 CP Usage. • • •
•
VM/370 Registers • • • • • • • •
•
.591
.592
.594
.595
.596
.598
APPENDIX C: CMS EQUATE SYMBOLS • • • • • 599
CMS Usage Equates. • • •
.599
CMS Register Equates • • • • • • • • • • 601
APPENDIX D: DASD RECORD FORMATS. •
.603
Record 0 Track 0 Cylinder 0 Only.
.603
Record 1 (24 Bytes). • • • •
.604
Record 2, 4096 Bytes. • • •
.604
Record 3 •
• • • • • • • •
.604
Record 4 •
• • • • •
.605
Record 5 • • •
• • • • •
.605
Record 6 •
• • • •
.605
Record F3. • • • • • • • •
.605
Record F4. • •
.606
Record 4 •
• • • • •
.606
2314 Record Layout.
.606
Cylinder 0, Track O.
• • • • • • • • 606
All Cylinders Except 0, Track O. •
.606
3330 Series Record Layout. • •
.607
Cy linder 0, Track O. • • • • • • •
.607
Any Cylinder Except O.
.608
2305 Model 1 and Model 2 •
.608
Cylinder 0, Track O. • • •
.608
Any Cylinder Except O. • •
.608
3340 Series Record Layout. •
.609
Cylinder 0, Track O. • • • •
.609
Any Cylinder Except O. • • •
.609
APPENDIX E: VM/370 RESTRICITONS. •
.611
CP Restrictions. • • • • • •
.611
Dynamically Modified Channel Programs • • 611
Minidisk Restrictions. • • • • • •
.611
Timing Dependencies. • • • • • •
.613
CPU Model-Dependent Functions. • •
.614
Virtual Machine Charact.eristics. •
.614
CMS Restrictions. • • • • •
.616
Miscellaneous Restrictions. • • •
.618
APPENDIX F: VIRTUAL DEVICES USED IN CMS.619
APPENDIX G: FUNCTION CODES FOR DIAGNOSE
INSTRUCTIONS • • • • • • • • • • • • • • 621
APPENDIX H: CMS ZAP SERVICE PROGRAM • • • 623
ZAP Input Control Records.
.624
special Considerations for Using the
ZAP Service Program. •
.629
APPENDIX I: APPLYING PTFS. •
.631
Supporting A VM/370 System.
.631
VM/370 Update Procedures.
.631
Updating a Module. • • •
.633
Control Files. • • • • • •
.634
Applying PTFs to VM/370. •
.635
Updating Modules Using the V"FASM EXEC
Procedure • • • • • • • • • • • • • • • 638
Using VMFASM to Apply IBM-Supplied
updates • • • • • • • • • • • • • • • • 639
Using VMFASM to Apply Your Own Updates .641
Other Files Produced by VMFASM • • • • • 644
Figure
Figure
1.
2.
Figure
3.
Figure
Figure
Figure
4.
5.
6.
Figure
Figure
Figure
7.
8.
9.
Does a Problem Exist •••••••• 13
Debug Procedures for waits
and Loops ••••••••••••••••••• 14
Debug Procedures for Unexpected
Results and an ABEND. . .
15
ABEND Messages •••••••••••••• 19
ABEND Problem Type •••••••••• 2l
Unexpected Results Problem
Figure 39.
Figure 40.
Figure 41.
Figure 42.
Type •••••••••••••••••••••••• 23
Figure 10.
Figure 11.
Figure 12.
Figure 13.
Figure 14.
Figure 15.
Figure 16.
Figure 17.
Figure 18.
Figure 19.
Figure
Figure
Figure
Figure
20.
21.
22.
23.
Figure 24.
Figure 25.
Figure 26.
Figure 27.
Figure 28.
Figure 29.
Figure 30.
Figure 31.
Figure 32.
Figure
Figure
Figure
Figure
33.
34.
35.
36.
Figure 37.
Figure 38.
Loop Problem Type ••••••••••• 25
CP 'Wait Problem Type •••••••• 25
virtual Machine wait
Problem Type •••••••••••••••• 27
RSCS wait Problem Type •••••• 28
Summary of VM/370 Debugging
Tools ••••••••••••••••••••••• 29
comparison and CP and CMS
Facilities for Debugging ••• ~33
CMS Control Blocks •••••••••• 42
Sample CMS Load Map ••••••••• 44
Overview of Interruption
Handling •••••••••••••••••••• 53
DIAGNOSE X'5C'/VMMLEVEL
Field Analysis •••••••••••••• 64
User Dispatching States ••••• 90
User Status Changes ••••••••• 91
RMS Control Register
Assignments .•••••••••••••••• l02
Summary of lOB Indicators ••• 109
CMS File System ••••••••••••• 113
CMS Storage Map ••••••••••••• 117
CMS Command (and Request)
Processing •••••••••••••••••• 127
PSW Fields When Called
Routine Starts •••••••••••••• 128
Register Contents When
Called Routine Starts ••••••• 128
Simulated OS Supervisor
Calls .•...........•.•.•...•. 131
DCB Fields That Can Be
Specified for Each Access
Method •••••••••••••••••••••• 135
RSCS Virtual Machine
Configuration ••••••••••••••• 139
RSCS Commands and
Functions ••••••••••••••••••• 140
VM/370 DIAGNOSE
Instructions Issued by the
RSCS Program •••••••••••••••• 141
RSCS Tasks •••••••••••••••••• 143
Data Flow Between RSCS and
Remote stations via the SML
Li n e Dr i v e r ••••••••••••••••• 1 45
SML Function Processors ••••• 146
RSCS storage Allocation ••••• 148
Input to the DMTWAT Routine. 149
Movement of Data During a
Typical GIVE/TAKE
Transaction ••••••••••••••••• 152
I/O Queues and Subqueues •••• 153
Chaining of Data Areas
Required for File TAG
Manipulation •••••••••••••••• 154
Figure 43.
Figure 44.
Figure 45.
Figure 46.
Figure 47.
Figure 48.
Figure 49.
Figure 50.
Figure 51.
Figure 52.
Figure 53.
Figure 54.
Figure 55.
Figure 56.
Figure 57.
Figure 58.
Figure 59.
Figure 60.
Figure 61.
Figure 62.
Figure 63.
An Overview of the
Functional Areas of CMS ••••• 155
Details of CMS system
Functions and the Routines
That Perform Them ••••••••••• 156
CMS Storage Map ••••••••••••• 161
PSW Fields When Called
Routine Is Started •••••••••• 167
Register Contents When
Called Routine Is Started ••• 168
How CMS File Records Are
Chained Together •••••••••••• 177
Format of a File status
Block; Format of a File
Status Table •••••••••••••••• 178
Format of the First Chain
Link and Nth Chain Links •••• 179
Arrangement of Fixed-Length
or Variable-Length Records
in Files •••••••••••••••••••• 179
Structure of the Master
File Directory •••••••••••••• 181
Disk Storage Allocation
Using the QMSK Data Block ••• 181
Flow of Control for Unit
Record I/O processing ••••••• 183
Relationship in storage
Between the CMS Interface
Module DMSAMS and the
CMSAMS and CMSVSAM DCSSs •••• 194
The Relationships in storage
Between the User Program
and the CMSDOS DCSS and the
CMSVSAM DCSSs ••••••••••••••• 195
Relationship in Storage
Between the User Program,
the OS Simulation and
Interface Routines, and
the CMSDOS and CMSVSAM
DCSSs ••••••••••••••••••••••• 196
os Functions that CMS
Simulates ••••••••••••••••••• 199
CP Commands and Their
Module Entry Points ••••••••• 230
Overview of RSCS Program
Organization •••••••••••••••• 238
Program Organization for
the Multitasking Supervisor.239
Program Organization for
the REX System Service
Tasks ••••••••••••••••••••••• 240
Program Organization for
the AXS System Service Task.241
Program Organization for
the SML Line Driver Task •••• 242
Program Organization for
the NPT Line Driver Task •••• 243
CP Trace Table Entries •••••• 478
Annotated Sample of Output
from the TYPE and PRINT
Functions of the DDR
Program ••••••••••••••••••••• 539
Figure 67.
Figure 64.
Figure 65.
Figure 66.
CP ABEND Codes •••••••••••••• 542
CMS ABEND Codes ••••••••••••• 560
Summary of SVC Trace Output
Lines ••••••••••••••••••••••• 586
Figure 68.
Figure 69.
Devices supported by a CMS
Virtual Machine ••••••••••••. 619
Function Codes for
DIAGNOSE Instruction •••••••• 621
System Support plan ••••••••• 638
The VM/370 Control Program
(CP)
manages the
resources of
a single computer
such that
multiple computing systems appear to exist.
Each "virtual computing system", or virtual
machine, is the functional equivalent of an IBM
System/370.
The person trying to determine the
cause of a VM/370 software problem must consider
three separate areas:
•
identify the problem, collect information and
determine the cause so that the problem can be
fixed.
When running VM/370, you must also
decide whether the problem is in CP, the virtual
machine, or the problem program.
A good approach to debugging is:
The Control Program (CP) ,
which controls the
resources of the real machine.
1.
Recognize that a problem exists.
2.
Identify the
affected.
3.
Analyze the
data you
have available,
collect more data if you need it, then
isolate the data that pertains to your
problem.
4.
Finally, determine the cause of the problem
and correct it.
The virtual machine operating system running
under the control of CP, such as CMS, RSCS,
OS, DOS, or VM/370.
The problem program, which executes under the
control of
a virtual
machine operating
system.
problem type
~2~~:
DOES A PROBLEM EXIST?
§g!~§:-order-No:-GC20=1823:
There are four types of problems:
Once the
area causing
the problem
is
identified,
the appropriate person should use
all available information and determine the
cause of the problem.
The IBM Program systems
Representative
(PSR)
or a system programmer
handles all problems with CP, Conversational
Monitor
System
(CMS),
Remote
Spooling
communication Subsystem (RSCS), and Interactive
Problem Control System
(IPCS); information that
is helpful in debugging CP, CMS, and RSCS is
contained in this publication.
The applications
programmer handles all problem program errors;
techniques for applications program debugging
are found in the !~Ll1Q: £~~ Q2~!~§ ~Y!~~.
•
•
•
•
For information about the Interactive
Problem Control System refer to the !~LJIQ:
Interactive Problem Control ~Y2i~~ (lgf~) Q2~~!2
If the problem is caused by a virtual machine
operating system other than CMS and RSCS, refer
to the publications pertaining to that operating
system for specific information.
However, use
the CP debugging facilities,
such as the CP
commands, to perform the recommended debugging
procedures discussed in the publication that
pertains to the other operating system. The IBM
PSR or a system programmer handles problems with
virtual machine operating systems.
If it becomes necessary to apply a PTF
(Program Temporary Fix)
to
a component of
VM/370, refer to "Appendix J: Applying PFTs" for
detailed information on applying PTFs.
and
the
area
ABEND (Abnormal End)
Unexpected results
Loop
wait state
The abnormal end is the most easily identified
problem.
An abnormal termination causes an
error message.
Unexpected results, such as missing or incorrect
output, or incorrect format, is another easily
identified problem.
Unproductive processing time is a problem not
easily recognized, especially in a time-sharing
environment. When you are using VM/370, you are
usually sitting at a terminal and do not have
the lights of the CPU control panel to help you
recognize this type of problem.
HOW TO START DEBUGGING
Before you can
recognize that
correct any problem, you
one exists.
Next, you
must
must
You may have a looping condition if your
program takes
longer to execute
than you
anticipated. Check your output. If the number of
output records or print lines is greater than
expected, the output may really be the same
information repeated many
times.
Repetitive
output usually indicates a program loop.
Section 1. Introduction
11
Another way
to identify a loop
is to
periodically examine the current PSW. If the PSW
instruction address always has the same value,
or if the instruction address has a series of
repeating values,
the program
probably is
looping.
A wait state may exist if your program is
taking longer to execute then expected.
To
identify a probable wait state, display the
current PSW on the terminal.
Periodically,
issue the CP command
QUERY TIME
and compare the elapsed processing time.
When
the elapsed processing time does not increase,
the wait state probably exists.
Figures 1-10 help you to identify problem
types and the areas where they may occur.
CP ABNORMAL TERMINATION
When CP abnormally terminates, a dump is taken.
This dump can be directed to a tape or printer
or dynamically allocated to a DASD. The output
device for a CP ABEND dump is specified by the
CP SET command.
See "ABEND Dumps" in this
section for a description of the SET and VMFDUMP
cOllmands.
Use the dump to find what caused CP to
terminate.
Find why
the system abnormally
terminated and then see how the condition can be
corrected. See "Reading CP ABEND Dumps" in this
section for detailed information on reading a CP
ABEND dump.
REASON FOR THE ABEND: CP terminates and takes an
abnormal-- -termInation
dump
under
three
conditions:
•
Program Check in CP
ANALYZING THE PROBLEM
Once the type of problem is identified, the
cause of it must be determined.
There are
recommended
procedures
to
follow.
These
procedures are helpful, but do not identify the
cause of
the problem
in every
case.
Be
resourceful.
Use
whatever data
you
have
available.
If the cause of the problem is not
found after the recommended debugging procedures
are followed,
it may be necessary to undertake
the tedious job of checking through listings at
your desk.
See the
!~LllQ:
~~~
information on using VM/370
a problem program.
Examine the PROPSW and INTPR fields in the
Prefix Storage Area (PSA)
to determine the
failing module.
•
Examine the SVC old PSW (SVCOPSW) and ABEND
code (CPABEND)
fields in the prefix storage
area to determine the module that issued the
SVC 0 and the reason it vas issued.
CPABEND contains an
abnormal termination
code.
The first three characters identify
the failing module (for example, ABEND code
BLD001 indicates
DMKBLD is
the failing
module) •
User's Guide
for
facIlIties-to debug
•
USING VM/370 FACILITIES TO DEBUG
Once the problem and the area where it occurs is
identified, you can
gather the information
needed to determine the cause of the problem.
The type of information you want to use varies
with the type of problem. The tools used to
gather the information vary depending upon the
area in which the problem occurs. For example,
if looping is the problem, you should examine
the PSW.
For a CP loop, you must use the
operator's console to display the PSW, but for a
virtual machine loop you can display the PSW via
the CP DISPLAY command.
The
following shows
specific
debugging
procedures for the various error conditions.
The procedures tell you what to do and what
debugging tool to use.
For details on how to
invoke and use the debugging tools refer to "CP
Commands For Debugging",
"CMS Commands For
tebugging", and "Debugging With CMS" in section
4.
12
Module Issuing an SVC 0
Pressing SYSTEM RESTART on CPU Console
Examine the old PSW at location X'08' to find
the location of the instruction that was
executing when SYSTEM RESTART was pressed.
The operator presses SYSTEM RESTART when CP
is in a disabled wait state or loop.
PROCEDURE WHEN CP ABEND OCCURS: The information
In--low-storage -- tells- you-'-the status of the
system at the time
CP terminated.
Status
information is stored in the CPSTAT field of the
PSA.
You should be able to tell the module that
was executing by looking at the PSA. See "Save
Area Conventions" in this section and refer to
the appropriate save area
(SAVEAREA, BALRSAVE,
or FREESAV~ to see how that module started to
execute.
Exalline the real and virtual control blocks
to find the status of I/O operations.
The PSA
is described in the !!1L37.Q: Q!!! Ar.!i!!2 !!!S
~Q~!IQ! ~!Q£~
1Qgi£·
Examine the CP internal trace table.
This
table can be extremly helpful in determining the
events that preceded the ABEND. The CP internal
trace table description in Section 4 tells you
how to use the trace table.
IBM VM/370: System Logic and Problem Determination Guide
Does a problem exist?---_
START
DEBUGGING
Is there an ABEND condition? - - - - - - _ _ .
II
If the message
DMKDMP9081 SYSTEM FAILURE, CODE XXX XXX
appears on the console and
the alarm rings,
this is a CP ABEND.
The system dumps to disk or to the
printer if the set dump E command
has been issued, and automatically
performs I PL.
• ~
Is there a wait or Loop? _ _ _ _ _ _ _ _ __
a
rs;:;l
II
II
If the messages
DMKDMP9081 SYSTEM FAI LURE, CODE XXXXXX
DMKCKP9601 SYSTEM WARMSTART DATA SAVED
PMKCKP961W SYSTEM SHUTDOWN COMPLETE
appear on the console,
this is a CP ABEND.
The system dumps to tape
or printer and stops. _ _ ~
~
If pressing the REQUEST key on the operator's
console leaves the REQUEST PENDING light on,
a CP disabled wait state exists.
The CPU console light will be on. _
~
II
If the CPU console wait light is on,
the system IS in a CP enabled wait state. __
~
II
If the real PSW problem bit is OFF,
there IS a CP loop.
II
If the message
DMSABNI48T SYSTEM ABEND XXX,
CALLED FROM YYYYYY
appears on the terminal,
this is a CMS ABEND.---~
II
,
II
If an ABEND message
from the virtual machine appears
on the terminal,
this is an ABEND in the
operating system controll ing
this virtual machine. _ _ _ ~
•
~
If any of the following messages
DMKDSP450W CP ENTERED; DISABLED WAIT PSW
DMKDSP451W CP ENTERED; INVALID PSW
DMKDSP452W CP ENTERED; EXTERNAL INTERRUPT
LOOP
DMKDSP453W CP ENTERED; PROGRAM INTERRUPT
LOOP
appears on the terminal,
there IS a disabled wait or an interrupt loop in the
virtual machine. - - - - - - - - -
')
No problem exists
Otherwise, an ABEND
condition does not exist,
GO TO
II
an Interrupt,
II
If processing has ceased in the virtual
machine without reaching end-of-job,
If pressing the ATTN key once does not cause
=) ___________
(0
...J
Unexpected R e s u l t s ? - - - - - - - - - _
II
C5J
there is a disabled loop in the virtual machine. )
GJ
the virtual machine is in an
enabled wait state and no I/O interrupt
If an operating system which
executes properly on a real machine
fails to execute properly under VM/370,
has occu rred.
there are unexpected results
in CPo
---------1_- rs;l
II
II
V
If a program which executes under
the control of an operating system on
a real machine fails to execute correctly
with the same operating system under
VM/370,
there are unexpected resOJlts
~
in the virtual machine. - - - ~
If the program's output is
maccurate or mlssmg,
there are unexpected results
in the problem program.
If the output is redundant
check for a loop. - - -
II
II
If processing time exceeds normal expectations,
the virtual machine may have an enabled loop. )
II Otherwise.~
f4;I
v__
____________
.J
o
r::\
0
Otherwise, check for a wait or
~_____IOO_P_.~-----------------~
o
Figure
Does a Problem Exist?
Section 1. Introduction
13
Debug Procedures for a Wait
CP Disabled Wait - - - - - - - - - - - - - - - - - - - - - - - - - - - . ,
Use ALTER/DISPLAY console mode (if available), to display real PSW and CSW. Also,
display general and extended control registers and storage locations X'OO'-X'l00',
II
II
Press SYSTEM RESTART button to cause a CP ABEND
dump to be taken.
IPl.
CP Enabled Wait - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1
Press SYSTEM RESTART button to cause a
CP ABEND dump to be taken.
Use the dump to check the status of each VMBlOK. Also,
check RCHBlOK, RCUBlOK, and RDEVBlOK for each device.
Virtual Machine Disabled Wait
-------------------------f
Use CP commands (CMS users may use the CMS DEBUG command) to display
the PSW, CSW, general registers, and control registers.
II
Use the CP DUMP command (or CMS DUMP subcommand) to
take a dump.
Virtual Machine Enabled Wait - - - - - - - - - - - - - - - - - - - - - - - - 1
Take a dump.
Debug Procedures for a Loop
CPloop----------------------------------.,
Use ALTER/DISPLAY console mode (if available) to
display real PSW, general' registers, control
registers, and storage locations X'OO'-X'100',
II
II
Press SYSTEM RESTART button to cause a CP
ABEND dump to be taken.
Examine the CP internal trace table to see where the loop is.
Virtual Machine Disabled loop
------------------------1
Use the CP TRACE command to trace the loop.
II
II
II
Display the general registers and control registers
via the CP DISPLAY command.
Take a dump using the CP DUMP command.
Examine the source code.
Virtual Machine Enabled loop
-----------------------1
Trace the loop. Display the PSW, general registers,
and extended control registers.
II
II
Figure
14
2.
Take a dump.
Examine source code.
Debug Procedures for waits and Loops
IBM VM/370: System Logic and Problem Determination Guide
Debug Procedures for Unexpected Results
Unexpected Results in CP - - - - - - - - - - - - - - - - - - - - - - - - - ,
Check that the program is not violating any
CP restrictions.
II
II
II
Check that the program and operating system running
on the virtual machine are exactly the same as those
that ran on the real machine.
Use the CP TRACE command to trace CCWs, SIOs. and interrupts.
Look for an error in CCW translation or interrupt reflection.
If disk I{O error, use the CP DDR (DASD Dump Restore)
program to print the contents of any disk.
Unexpected results in a virtual machine
---------------------1
Check that the program executing on the virtual machine is
exactly the same as the one that ran on the real machine.
II
II
Make sure that operating system restrictions
are not violated.
Use CP TRACE to trace all I{O operations.
Debug Procedures for an ABEND
CPABEND-------------------------------,
Find out why CP abnormally terminated. Examine the
PROPSW, INTPR, SVCOPSW, and CPABEND fields in the PSA
from the dump.
II
II
Identify the module that caused the ABEND.
Examine the SAVEAREA, BALRSAVE, and FREESAVE areas of the dump.
If I{O operation, examine the real and virtual 110
control blocks.
CMSABEND------------------------------~
Determine reason for ABEND from code in ABEND
message DMSABN148T.
II
Enter debug environment or CP console function mode
to use the commands, to display the PSW, and to examine
low storage areas:
LASTLMOD and LASTTMOD
LASTCMND and PREVCMND
LASTEXEC and PREVEXEC and DEVICE
Look at the last instruction executed.
Take dump if need be.
Virtual Machine ABEND (other than CMS)
----------------------------------1
Examine dump, if there is one.
II
II
Figure
3.
Use CP commands to examine registers and
control words.
Use CP TRACE to trace the processing up to
the point where the error occurred.
Debug Procedures for unexpected Results and an ABEND
Section 1. Introduction
15
The values in the general registers can help
you to locate the IOBLOK, VMBLOK, and the save
area. Refer to "Reading CP ABEND Dumps" in this
section for detailed information on the contents
of the general registers.
where xxx is the ABEND code and yyyyyy is the
address of the instruction causing the ABEND.
The DMSABN module issues this message. Then, CMS
waits for a command to be entered from the
terminal.
In the PSA, if the program check old PSi
(PROPSi) or the SVC old PSi (SVCOPSi) points to
an address beyond the end of the resident
nucleus, the module that caused the ABEND is a
pageable module.
Refer to "Reading CP ABEND
Dumps" in this section to find out how to
identify that pageable module. Use the CP load
map that was created when the VM/370 system was
generated to find the address of the end of the
resident nucleus.
Because CMS is an interactive system, you may
want to use its debugging facilities to examine
status. You may be able to determine the cause
of the ABEND without taking a dump.
CP TERMINATION WITHOUT A DUMP
Two types of severe machine checks can cause the
VM/370 control program to terminate:
•
An unrecoverable machine check in the control
program
•
A machine check that cannot be diagnosed
The debug program is located in the resident
nucleus of CMS and has its own save and work
areas. Because the debug program does not alter
the status of the system, you can use its
options knowing that routines and data cannot be
overlaid unless you specifically request it.
Likewise, you can use the CP commands to debug
when you know that you cannot inadvertently
overlay storage because the CP and CMS storage
areas are completely separate.
I§A~g!
FOB THE ABEND:
First determine the
reason c~i-abi~imaIIi-ierminated. There are four
types of CMS abnormal terminations:
•
The DMSITP routine gets control whenever a
hardware program exception
occurs. If a
routine other than a SPIE exit routine is in
control, DMSITP issues the message
A machine check error cannot be diagnosed if
either the machine check old PSi or the machine
check interruption code
is invalid.
These
severe machine checks cause CP to terminate, but
no dump is taken since the error is recorded on
the error recording cylinders. The system is
automatically restarted and a message is issued
identifying the machine check error.
If an unrecoverable machine check
CP, the message
program Exception
DMSITP141T xxxxxxxx EXCEPTION OCCURRED
AT xxxxxx IN ROUTINE xxxxxxxx
and invokes DMSABN (the ABEND routine). The
ABEND code is OCx, where x is the program
exception
number
(O-F).
The
possible
programming exceptions are:
occurs in
DMKMCH6101 MACHINE CHECK SUPERVISOR DAMAGE
Code
--0-
appears on the CPU console. CP is terminated and
automatically restarted.
1
2
3
If the machine check handler cannot diagnose
a certain machine check, the integrity of the
system is questionable. The message
4
5
6
7
8
9
A
B
C
DMKMCH6111 MACHINE CHECK SYSTEM INTEGRITY
LOST
appears on the CPU console, CP is terminated and
automatically restarted.
D
E
Hardware errors are probably the cause of
these
severe machine
checks.
The
system
operator should run the CPEREP program'to print
the previous error and save the output for the
installation hardware maintenance personnel.
F
DMSABN148T SYSTEM ABEND xxx CALLED
FROM '1yyyyy
16
Imprecise
Operation
Privileged operation
Execute
Protection
Addressing
Specification
Decimal data
Fixed-point overflow
Fixed-point divide
Decimal overflow
Decimal divide
Exponent overflow
Exponent underflow
Significance
Floating-point divide
ABEND Macro
Control is given to
the DHSSAB routine
whenever a user routine executes the ABEND
macro. The ABEND code specified in the ABEND
macro appears in the abnormal termination
message DHSABN148T.
CMS ABNORMAL TERMINATION
When CMS abnormally terminates, the following
error message appears on the terminal:
!1~~ning
•
Halt Execution (HX)
Whenever the virtual machine opertor signals
an attention interruption and enters HX, CMS
terminates and issues "CMS".
IBH VM/370: System Logic and Problem Determination Guide
•
system ABEND
The ABEND
following:
A CMS system routine can abnormally terminate
by issuing the DMSABN macro. The first three
hexadecimal digits of the system ABEND code
appear in the CMS ABEND message, DMSABN148T.
•
The SVC handler, DMSITS, is re-initialized,
and all stacked save areas are released.
•
"FINIS * * *" is invoked by means of SVC 202,
to close all files, and to update the .aster
file directory.
--,
I
•
I
I
I
If the EXECTOR module is
is released.
•
All link
freed.
•
All FCB pointers are set to zero.
•
All user storage is released.
•
The amount of system free storage which
should be allocated is computed. This value
is compared to the amount of free storage
that is actually allocated.
•
The console input stack is purged.
The format of the DMSABN macro is:
r-'-
I
I
I
r
r"
l[labelJIDMSABNlcode I,TYPCALL=la!£ II
I
I
I (reg) I
I BALR II
IL _ _ _ _ _
I _ __ I L L . J . )
.I
label
is
any
label.
code
is the
abnormal termination
code
(O-FFF) that appears in the DMSABN148T
system termination message.
(reg)
is
the
register
containing
abnormal termination code.
TYPCALL=
specifies how control passes to the
TYPCALL=BALR
abnormal
termination
routine, DMSABN.
valid
Assembler
language
the
TYPCALL=SVC
Routines that do not reside in the
nucleus should use TYPECALL=SVC to
generate CMS SVC 203 linkage.
TYPCALL=BALR
Nucleus-resident
routines
TYPCALL=BALR to generate
branch to DMSABN.
a
~~Q£~QYB~
!H~~ £~a
ABEND OCCURS: After a CMS
ABEND, CMS provides two--courses of action. In
addition, you can enter the CP command mode and
use CP's debugging facilities by signalling
attention.
The two
are:
courses of
action available
blocks
function
performs
the
in real storage, it
allocated
by
DMSSLI
are
When the amount of storage actually allocated
is less
than the
amount that
should be
allocated, the message
DMSABN149T xxx x DOUBLEWORDS OF SYSTEM
STORAGE HAVE BEEN DESTROYED
appears on the terminal.
If the amount of
storage actually allocated is greater than the
amount that should be allocated, the message
specify
direct
If a CMS SVC handler abnormally terminates, it
sets an ABEND flag and stores an ABEND code in
NUCON (the CMS nucleus constant area).
After
the SVC handler has finished processing, the
ABEND condition is recognized. The DMSABN ABEND
routine issues the ABEND message, DMSABN148T,
with the ABEND code stored in NUCON.
recovery
DMSABN150W nnn (HEX xxx) DOUBLEWORDS OF
SYSTEM STORAGE WERE NOT
RECOVERED
appears on the terminal.
A DEBUGGING PROCEDURE: When a CMS ABEND occurs,
you-probably--want-to use the DEBUG subco.mands
or CP commands to examine the PSW and certain
areas of low storage. Refer to "CMS Debugging
Commands" in Section 4 for detailed description
of how to use the CMS DEBUG subcommands. See
"CP Commands Used to Debug the Virtual Machine"
and "CP Commands Used to Debug cpu in Section 4
for a detailed description of how to use the CP
commands.
Also refer to
Figure 12 for a
comparison
of the
CP
and CMS
debugging
facilities.
in CMS
•
Issue the DEBUG command and enter the debug
environment.
After using
all the DEBUG
subcommands that you need, exit from the
debug environment. Then, either issue the
RETURN command to return to DMSABN so that
ABEND recovery occurs, or
issue the GO
command to resume processing at the point the
ABEND occurred.
•
Issue a CMS command other than DEBUG and the
ABEND routine, DMSABN, performs its ABEND
recovery and then passes control to the
DMSINT routine to process the command just
entered.
The following procedure may be useful
determining the cause of a CMS ABEND:
1.
Display the PSW.
(Use
the CP DISPLAY
command or CMS
DEBUG PSW subcommand. )
Compare the PSW instruction address to the
current CMS load map to determine the
module that caused the ABEND.
The CMS
storage-resident nucleus routines are in
fixed storage locations.
Also
PSW.
2.
in
check the
interruption
code in
the
Examine
areas
of
low
storage.
information in low storage can tell
more about the cause of the ABEND.
The
you
Section 1. Introduction
17
Field
iASTLMOD
contaIns
Contents
LASTTMOD
Contains the name
module
loaded
transient area.
of the last
into
the
LASTCMND
Contains the name
command issued.
of the last
PREVCMND
Contains the
name
next-to-the-Iast
issued.
the name of the last
module loaded into storage via
the LOAD MOD command.
LASTEXEC
Contains the name
EXEC procedure.
PREVEXEC
Contains the
name of
the
next-to-Iast EXEC procedure.
DEVICE
Identifies the
caused
the
interrupt.
The low storage areas
the type of ABEND.
3.
4.
of
the
command
of the last
device
last
examined depend
that
I/O
on
Once you have identified the module that
caused the ABEND, examine the specific
instruction. Refer to your listing.
If you have not identified the problem at
this time, take a dump by issuing the DEBUG
DUMP subcommand.
Refer to "Reading CMS
ABEND
Dumps"
in
this
section
for
information on reading a CMS dump.
If you
can reproduce the problem, try the CP or
CMS tracing facilities.
If a dump was taken, it was sent to the
virtual printer.
Issue a CLOSE command to the
virtual printer to print the dump on the real
printer.
If you choose to run a standalone dump
program to dump the storage in your virtual
machine, be sure to specify the NOCLEAR option
when you issue the CP IPL command.
At any rate,
a portion of your virtual storage is overlaid by
CP's virtual IPL simulation.
If the problem can be reproduc~d, it is
helpful to trace the processing uS1ng the CP
TRACE command. Also, you can set address stops,
and display and alter registers,
control words
(such as the PS~, and data areas. The CP
commands can be very
helpful in debugging
because you can gather information at various
stages in processing. A dump is static and
represents the system at only one particular
time. Debugging on a virtual machine can often
be more flexible than debugging on a real
machine.
VM/370 may terminate or reset a virtual
machine if a nonrecoverable channel check or
machine check occurs in that virtual machine.
Hardware errors usually cause this type of
virtual machine termination.
One of the following messages appears on the CPU
console:
DMKMCH616I MACHINE CHECK; USER userid
TERMINATED
DMKCCH604I CHANNEL ERROR; DEV xxx;
USER userid; ~ACHINE RESET
VIRTUAL MACHINE ABEND (OTHER THAN CMS)
The abnormal termination of an operating system
(such as OS or DOS) running under VM/370 appears
the same as a similar termination on a real
machine.
Refer
to publications
for
the
specified
operating
system
for
debugging
information. However, all of the CP debugging
facilities may be used to help you gather the
information you need.
Because certain operating
systems
(OS/VS1, OS/VS2, and DOS/V~
manage
their own virtual storage, CP commands that
examine or alter
virtual storage locations
should be used only in virtual=real storage
space with OS/VS1, OS/VS2, and DOS/VS.
18
IBM VM/370: System Logic and Problem Determination Guide
ftessage
(Alarm rings)
DftKDftP9081 SYSTEft FAILURE CODE xxxxxx
CP ABERD, system dumps
Restart is automatic.
DMKDftP90SW SYSTEft DUKP FAILURE;
PROGRAK CHECK
DftKDftP906W SYSTEft FAILORE; ftACHINE
CHECK, ROR SEREP
DMKDftP907W SYSTEK DOKP FAILORE; FATAL
1/0 ERROR
If the dump program encounters a
a program check, machine check or
fatal
1/0 error,
a message is
issued indicating the error. CP
enters the wait state with code 3
in the PSW.
DKKCKF900W SYSTEft RECOVERY FAILORE;
PROGRAK CHECK
DMKCKP901W SYSTEft RECOVERY FAILORE;
ftACHINE CHECK, RON SEREP
DftKCKP902W SYSTEft RECOVERY FAILORE;
FATAL 1/0 ERROR - NOCL CYL
- WARK CYL
DKKCKP904W SYSTEft RECOVERY FAILORE;
INVALID WARM START DATA
DKKCKP910W SYSTEft RECOVERY FAILORE;
INVALID WARft START CYLINDER
DMKCKP911W SYSTEK RECOVERY FAILORE;
WARft START AREA FOLt
If
the
checkpoint
program
encounters
a program
check, a
machine check, a fatal 1/0 error or
an error relating to a certain warm
start
cylinder
or warm
start
data
conditions, a
message is
issued indicating the error and CP
enters the wait state with code 7
in the PSW.
DMKWRK902W SYSTEK RECOVERY FAILORE;
FATAL 1/0 ERROR
DMKWRft903W SYSTEft RECOVERY FAILORE;
VOLID xxxxx ALLOCATION
ERROR CYLINDER xxx
DKKWRM904W SYSTEft RECOVERY FAILORE;
INVALID WARK START DATA
DKKWRK909W SYSTEK RECOVERY FAILORE:
VOLID xxxxxx NOT KOUNTED
DMKWRW909W SYSTEK DUKP DEVICE;
ROT-READY
start
program
If the
warm
encounters
a
severe
error, a
message is issued indicating the
error and CP enters the wait state
code 9 in the PSW.
DKKDftP9081 SYSTEK FAILURE, CODE XXXXIX
DMKCKP9601 SYSTEM WARft START DATA SAVED
DMKCKP961W SYSTEM SHOTDOWN COKPLETE
CP ABERD, system dumps to tape or
printer. The
system stops; the
operator must IPL the system to
start again.
'----
Figure
Type of ABERD
4.
ABEND Kessages (Part 1 of 2)
to
disk.
----------------_._-----------'
section 1. Introduction
19
,----Type of ABEND
Message
1
DMKDMP905W SYSTEM DUMP FAILURE;
PROGRAM CHECK
DMKDMP906W SYSTEM DUMP FAILURE;
MACHINE CHECK r RUN SEREP
DMKDMP907W SYSTEM DUMP FAILURE; FATAL
I/O ERROR
-----------------------
-----,
1
If the dump program encounters a
program check r a machine check or
fatal I/O
error r a
message is
issued indicating the error.
CP
enters the wait state with code 3
in the PSW.
If the duap cannot find a defined
dump device and if no printer is
defined for the dumpr CP enters a
disabled wait state with code 4 in
the PSi.
-----------------------
CP
termination
with
automatic
restart when the two messages in
the "Messages" column are issued:
DMKMCH6101 MACHINE CHECK; SUPERVISOR
DAMAGE
The machine check handler encountered an unrecoverable error with
the VM/370 control program.
DMKMCH6111 MACHINE CHECK; SYSTEM
INTEGRITY LOST
The machine check handler encountered an error that con not be diagnosed; system integritYr at this
pointr is not reliable.
-------------------------------------------------CP terainaticn
occurs without automatic
restart
when
the two
messages in the "Messages" column
are issued:
DMKCCH603W CHANNEL ERROR r RUN SEREP r
RESTART SYSTEM
There was a channel check condition
from
which the
channel
check
handler could
not
recover.
CP
enters the wait state with condition code 2 in the PSi.
DMKCPI955W INSUFFICIENT STORAGE FOR
VM/370
The generated system requires more
real storage than is available. CP
enters the disabled wait state with
code OOD ,in the PSW.
---,-----------------------
DMSABN148T SYSTEM ABEND xxx
CALLED FROM xxxxxx
----------1
CMS ABEND;
the system accepts commands from the terminal. Enter the
DEBUG command and then the DUMP
subcommand to have CMS dump storage
l i o n the printer.
1
1
1
1
1
1-------------------------------------------------------------I
1 Others
1 When OS or DOS abnormally termi- 1
1
Refer to OS and DOS publication
1 nates on a virtual machine r the 1
for the abnormal termination
1 messages issued and the dumps taken 1
1
messages.
I are the same as they would be if OS 1
1
1
I or DOS abnormally terminated on a I
11.-_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _I_real
_ _ _ _machine.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _--I1
Figure
20
4.
ABEND Messages (Part 2 of 2)
IBM V"/370: System Logic and Problem Determination Guide
-----,
r-----
I Problem
I Type
ABEND
I
Where
I
IABEND Occurs I
CP ABEND
bistinguishing Characteristics
I
I
The alarm rings and the message
DMKDMP9081 SYSTEM FAILURE, CODE xxx xxx
appears on the CPU console. In this instance, the
system dump device is a disk, so the system dumps to
disk and automatically restarts. If an error occurs
in the dump, checkpoint, or warmstart program, CP
enters the wait state after issuing one or more of
the following messages:
DMKDMP90SW SYSTEM DUMP FAILURE; PROGRAM CHECK
DMKDMP906W SYSTEM DUMP FAILURE; MACHINE CHECK, RUN
SEREP
DMKDMP907W SYSTEM DUMP FAILURE; FATAL I/O ERROR
DMKCKP900W SYSTEM RECOVERY FAILURE; PROGRAM CHECK
DMKCKP901W SYSTEM RECOVERY FAILURE; MACHINE CHECK,
RUN SEREP
DMKCKP902W SYSTEM RECOVERY FAILURE; FATAL I/O ERROR
DMKCKP904W SYSTEM RECOVERY FAILURE; INVALID WARM
START DATA
DMKCKP910W SYSTEM RECOVERY FAILURE; INVALID WARM
START CYLINDER
DMKCKP911W SYSTEM RECOVERY FAILURE; WARM START AREA
PULL
DMKWRM902W SYSTEM RECOVERY FAILURE; FATAL I/O ERROR
DMKWRM903W SYSTEM RECOVERY FAILURE; VOLID xxxxxx
ALLOCATION ERROR CYLINDER xxx
DMKWRM904W SYSTEM RECOVERY FAILURE; INVALID WARM
START DATA
DMKWRM909W SYSTEM RECOVERY FAILURE; VOLID xxxxxx
NOT MOUNTED
CP ABEND
The
following
messages
appear on the CPU console:
DMKDMP9081 SYSTEM FAILURE, CODE xxxxxx
DMKDMP9601 SYSTEM WARM START DATA SAVED
DMKDMP961W SYSTEM SHUTDOWN COMPLETE
The system dumps to tape or printer and stops.
The
operator must IPL the system to restart. If an
error occurs in the dump or checkpoint program CP
enters the wait state after issuing one or more of
the following messages:
L -_____
Figure S.
DMKDMP90SW SYSTEM DUMP FAILURE; PROGRAM CHECK
DMKDMP906W SYSTEM DUMP FAILURE; MACHINE CHECK, RUN
SEREP
DMKDMP907W SYSTEM DUMP FAILURE; FATAL I/O ERROR
DMKCKP900W SYSTEM RECOVERY FAILURE; PROGRAM CHECK
DMKCKP901W SYSTEM RECOVERY FAILURE; MACHINE CHECK,
RUN SEREP
DMKCKP902W SYSTEM RECOVERY FAILURE; PATAL I/O ERROR
DMKCKP910W SYSTEM RECOVERY FAILURE; INVALID WARM
START CYLINDER
DMKCKP911W SISTEM RECOVERY FAILURE; WARM START AREA
PULL
_ _____________ -J
ABEND Problem Type (Part 1 of 2)
section 1. Introduction
21
------------------------------------------,
r
1 Problem
1
Where
1
ABEND Occurs 1
Type
ABEND
(Cont. )
1
I
Distinguishing Characteristics
--------------1
An unrecoverable machine check error has occurred.
One of the following messages:
CP termination
with
automatic
restart
DMKMCH6101 MACHINE CHECK SUPERVISOR DAMAGE
DMKMCH6111 MACHINE CHECK INTEGRITY LOST
1
1
1
1
1
1
appears on the CPU console. The system is automat- 1
1
1 ically restarted.
1
1 An unrecoverable channel check error has occurred.
I The message:
1
I DMKCCH603W CHANNEL ERROR, RUN SEREP, RESTART
1
1
I
1
I
I
I
I
1------------------------------------------------------I
1
1
1
I
CP termination without
automatic
restart
I
I
I
I
SYSTEM
1 appears on the CPU console, and CP enters the wait 1
1 state.
I
1-------------------------------------1
I Virtual maI The CMS message
1
1 chine ABEND 1
I
1 (CMS)
I DMSABM148T SYSTEM ABEND xxx CALLED FROM xxxxxx
I
I
I
1
I
I appears on the terminal. The system stops and 1
I
I waits for a command to be entered on the terminal. 1
I
I To have a dump taken, issue the CMS DEBUG
I
1 and then the DUMP subcommand.
Virtual machine ABEND
(other than
CMS)
command I
1
When OS or DOS abnormally terminates on a virtual
machine, the messages issued and the dumps taken
are the same as they would be if OS or DOS abnormally terminated on a real machine.
VM/370 may terminate or reset a virtual machine if
a nonrecoverabele channel check or machine check
occurs in that virtual
machine. One of the
following messages appear to the system operator
at the CPU console:
DMKMCH6161 MACHINE CHECK; USER userid TERMINATED
DMKCCH6041 CHANNEL ERROR; DEV xxx; USER userid;
MACHINE RESET
Also, the virtual machine user is notified, by one
of the following messages, that his machine was
terminated or reset:
L____________
Figure 5.
22
DMKMCH6191 MACHINE CHECK; OPERATOR TERMINATED
DMKCCH6061 CHANNEL ERROR; OP_RATOR TERMINATED
_________________________________,_____
ABEND Problem Type (Part 2 of 2)
IBM VM/370: System Logic and Problem Determination Guide
J
UIEXPECTED RESULTS
The unexpected results type of errors vary, from
operating systems improperly functioning under
VM/370 to output printed in the wrong for.at.
by the CMS DDR command
controlled by CMS. The
functions:
•
DUMP
dumps part, or all of the data from a
DASD device to magnetic tape.
•
RESTORE -- transfers data from tapes created
by DDR DUMP to a direct access device.
The
direct access device that the data is being
restored to must be the same type of device
as the
direct access
device originally
containing that data.
•
COpy
copies data from one device to
another device of the same type. Data may be
reordered, by cylinder, when copied from disk
to disk.
To copy on~ tape to another, the
original tape must have been created by the
DDR DUMP function.
•
PRINT -- selectively prints the hexadecimal
and EBCDIC representation of DASD and tape
records on the virtual printer.
•
TYPE -- selectively displays the hexadecimal
and EBCDIC representation of DASD and tape
records on the terminal.
UNEXPECTED RESULTS IN CP
If an operating system executes properly on a
real machine but does not execute properly with
VM/370, a problem exists.
Also, if a program
executes properly
under the control
of a
particular operating system on a real machine
but does not execute correctly under the same
operating system with VM/370, a problem exists.
There are programs
(such as time-dependent
programs) that CP does not support. Be sure that
one of these programs
is not causing the
unexpected
results in
CPo
Refer to
"CP
Restrictions" in Section 5 for a list of the
restrictions.
Ensure that the progr'am and operating system
running on the virtual machine are ~~~£!!I the
same as the one that ran on the real machine.
Check for the same:
•
•
•
Job stream
Copy of the operating system (and program)
Libraries
If the problem still is not found,
look for
an I/O problem. Try to reproduce the problem,
tracing all CCWs, SIOs, and interruptions via
the CP TRACE command. Compare the real and
virtual CCWs from the trace. A discrepancy in
the CCWs may indicate that one of the CP
restrictions was violated, or that an error
occurred in CPo
UNEXPECTED RESULTS II A VIRTUAL MACHINE
When a program executes correctly under the
control of a particular operating system on a
real
machine
but has
unexpected
results
executing under
the control
of the
same
operating system with VM/370, a problem exists.
You usually find that something was changed in
the operating system or problem programs. Check
that the job stream, the operating system, and
the system libraries are the same.
If unexpected results occur
(such as TEXT
records interspersed in printed output), you can
examine the contents of the system or user disk
files.
Non-CMS users may execute any of the
utility programs, which are included in the
operating system they are using to examine and
rearrange files.
For more details on using the
utility programs refer to the specific utilities
publication for the operating system running in
the virtual machine.
CMS users should use the DASD Dump Restore
(DDR) service program to print or move the data
stored on direct access devices. The VM/370
DASD Dump Restore (DDR) program can be invoked
in a virtual machine
DDR program has five
CMS users should refer to "Debugging with
CMS" in section 4 for instructions on using the
DDR command. "CP Commands for Debugging" in
section 4 contains information about executing
the DDR program in a real or virtual machine and
a description of the DDR control statements.
,.-------------------_._-,
1
Unexpected Results Problem Type
1
1----------------------------------1
1
CP
1 If an operating
system,
executes 1
1
1
I properly on a real machine but not I
1 properly with CP, a problem exists. 1
1
1 Inaccurate data on disk or
1
1
1 files (such as spool files) could 1
1
I be the cause of the error.
system 1
1----------------------1
1 Virtual I If a program executes correctly
1 Machine 1 under the control of a particular
1
1 operating
system
on
a real
1
1 machine,
but does not execute
1
1 correctly under the same operating
1
1 system
with V8/370,
a problem
1
1 exists.
L
1
1
1
1
1
I
1
~
Figure 6. Unexpected Results Problem Type
LOOPS
The real cause
of a loop usually
is an
instruction that
sets or branches
on the
conditj_on code incorrectly. The existence of a
loop can usually be recognized by the ceasing of
productive processing and a continual return of
the PSi instruction address to the same address.
If I/O operations are involved, and the loop is
a very large one, it may be extremely difficult
to define, and may even include nested loops.
One of the most difficult types of loops to
determine is entry to the loop from a wild
branch. The problem in loop analysis is finding
section 1. Introduction
23
either the instruction that should open the loop
or the instruction that passed control to the
set of looping instructions.
CP DISABLED LOOP
The system operator should perform the following
sequence when gathering information to find the
cause of a CP disabled loop.
1.
DISPLAY commands to
Use the ALTER or
display the real PSW, general registers,
control registers, and storage locations
X'OO'
X' 100' •
2.
Press the SYSTEM RESTART button to cause an
ABEND dump to be taken.
3.
Save the information collected for the
system
programmer or
IBM
Programming
support Representative.
Note: You can IPL a standalone dump program such
to dump the storage of
your virtual machine. If you choose to use a
standalone dump program, be sure to specify
NOCLEAR on the IPL command. Also, be aware that
the CP IPL simulation destroys a page of storage
in your virtual machine and the standalone dump
alters your virtual storage While the CP DUMP
co •• and does not.
i;-~he BPS storage Print
However, if the operating system in the
virtual machine manages virtual storage, it is
usually better. to use that operating system's
dump program.
CP does not retrieve pages that
exist only on the virtual machine's paging
device.
VIRTUAL MACHINE ENABLED LOOP
After the system operator has collected the
information, the system programmer or Field
Engineering representative examines it.
If the
cause of the loop is not apparent:
1•
2.
Examine the CP internal trace table to
determine the modules that may be involved
in the loop.
If the cause is not yet determined, assume
that a wild branch caused the loop entry,
and search the source code for this wild
branch.
You should perform the following sequence when
locating the cause of an enabled loop:
1.
Use the CP TRACE command to trace
entire loop.
Display the PSW and
general registers.
the
the
2.
If your virtual machine has the extended
control (EC)
mode and the EC option, also
display the control registers.
3.
Use the CP DUMP com,mand to dump your
virtual storage. CMS users can use the
DEBUG DUMP subcommand.
A standalone dump
may be used, but be aware that such a dump
destroys the contents of some areas of
storage.
4.
Consult the source code to search for the
faulty instructions, examining previously
executed modules, if necessary.
Begin by
scanning for instructions that set the
condition code or branch on it.
5.
If the way in which the loop was entered is
still undetermined, assume that a wild
branch has occurred and begin a search for
its origin.
VIRTUAL MACHINE DISABLED LOOP
When a disabled loop is in a virtual machine you
cannot communicate with the virtual machine's
operating system.
This means that signaling
attention does not cause an interruption.
To find the
disabled loop:
cause
of
a
virtual
machine
1.
Enter the CP console function mode.
2.
Use the CP TRACE command to trace the
entire loop.
Display general and extended
control registers
via the
CP DISPLAY
command.
3.
Take a dump via the CP DUMP command.
4.
Examine the source code.
WAIT
No processing occurs in the virtual machine when
it is in a wait state.
When the wait state is
enabled, an I/O interruption causes processing
to resume.
Likewise, when the Control Program
is in a wait state, its processing ceases.
Use the information gathered,
along with
listings, to try to find the entry into the
loop.
24
IBM VM/370: System Logic and Problem Determination Guide
r--------------1
Loop
---------------------,1 1r-------------'---------------------,
wait Problem Type
1
Problem Type
1--------------------------1
CP
1 The
CPU console wait light is 1
I disabled I off. The problem state bit of the 1
1 loop
1 real
pSW
is
off.
No
I/O 1
I
I interruptions are accepted.
I
1--Condition does not exist.
I CP
1 enabled
I loop
I
The program is taking longer to
I Virtual
execute
than
anticipated.
1 machine
Signaling
attention from the
1 disabled
terminal
does
not
cause an
I loop
interruption
in
the
virtual
I
machine. You cannot communicate
I
with the virtual machine's opera1
ting system by signaling attenI
tion.
1
I---------·"-~---·
1
Type
1 Distinguishing
Disa"bled CP
wait
Figure 7.
-------------1
The CPU wait light is on.
DMKMCH612W MACHINE CHECK TIMING
FACILITIES DAMAGE,
RUN SEREP
1
1
1
1
1
1
1
1
appears on the CPU console,
a machine
check
(probable
hardware
error)
caused the
CP disabled wait state. If the
message
Excessive processing time often
indicates
a
loop. Use the CP
QUERY TIME command to check the
elapsed processing time. In CMS,
the continued typing of the blip
characters
indicates
that
time is elapsing.
If time has
elapsed, periodically display the
virtual
psw
and
check the
instruction address. If th~ same
instruction,
or
series
of
instructions continues to appear
in the PSW, a loop
probably
exists.
DMKCCH603W CHANNEL ERROR, RUN
SEREP, RESTART
SYSTEM
appears on the CPU console,
a channel
check
(probable
hardware error)
caused the
CP disabled wait state. If the
message
DMKCPI955W INSUFFICIENT STORAGE
FOR VM/370
appears on the CPU console,
the
control
program
has
entered a disabled wait state
with code OOD in the PSW.
LOop Problem Type
Either the generated system
is larger
than
the
real
machine size, or a hardware
machine malfunction prevents
VM/370
from
using
the
necessary amount of storage.
If the message
CP DISABLED WAIT
A disabled wait state usually results from a
hardware malfunction.
During
IPL, normally
correctable hardware errors may cause a wait
state
because the
operating system
error
recovery procedures are not accessible at this
point. These conditions are recorded in the
current PSW.
DMKPAG415E CONTINUOUS PAGING
ERRORS FROM
DASD xxx
appears on the CPU console,
the control program
(CP) has
entered a disabled wait with
code OOF in the PSi.
CP may be in an enabled wait state with
channel 0 disabled when it is attempting to
acquire more free storage.
Examine extended
control register 2 to see whether or not the
multiplexer channel
is disabled.
A severe
machine check could also cause a CP disabled
wait state.
If a severe machine check or channel check
caused a CP disabled wait state, one of the
following messages appear:
1
Pressing the REQUEST key, or
the equivalent action, on the
operator's console, leaves the
REQUEST PENDING light on. If
the message
,
Virtual
machine
enabled
loop
1
Characteristics
Consecutive
hardware errors
are occurring on one or more
VM/370 paging devices.
Enabled CP
wait
---------------1
The CPU console light is on, 1
but
the
system
accepts I
_interruptions
_ _ _ _ _ _ _ _ _ _ _from
_ _ _ _I/O
_ _ _devices.,
_ _ _ _ _ _J
L
Figure 8.
CP wait Problem Type
DMKMCH612W MACHINE CHECK TIMING FACILITIES
DAMAGE; RUI SEREP
DMKCCH603W CHAINEL ERROR, RUN SEREP,
RESTART SYSTEM
Section 1. Introduction
25
If the generated system cannot run on the
real machine because of insufficient storage, CP
enters the disabled wait state with code OOD in
the PSW.
The insufficient storage condition
occurs if:
•
The generated system is
machine size
larger than the real
Using the dump, examine the VMBLOK for each
user and the real device, channel w and control
unit blocks.
If each user is waiting because of
a request for storage and no more storage is
available, there is an error in CPo There may be
looping in a routine that requests storage.
Refer to "Reading CP ABEND Dumps" in this
section for specific information on how to
analyze a CP dump.
or •
A hardware malfunction occurs which reduces
the available amount of real storage to less
than that required by the generated system.
The message
DMKCPI955W INSUFFICIENT STORAGE FOR VM/370
appears on the CPU console.
VIRTUAL MACHINE DISABLED WAIT
The VM/370 Control Program does not allow the
virtual machine to enter a disabled wait state
or
certain interrupt
loops.
Instead,
CP
notifies the virtual machine operator of the
condition with one of the following messages:
DMKDSP450W CP ENTERED; DISABLED WAIT
PSi
If CP cannot continue because consecutive
hardware errors are occurring on one or more
VM/370 paging devices, the message
DHKDSP451i CP ENTERED; INVALID PSW
DMKPAG415E CONTINUOUS PAGING ERRORS FROM
DASD xxx
DHKDSP452W CP ENTERED; EXTERNAL
INTERRUPT LOOP
appears on the CPU console and CP enters the
disabled wait state with code OOF in the PSW.
If more than one paging device is available,
disable the device on which the hardware errors
are occurring and IPL the system again.
If the
VM/370 system is encountering hardware errors on
its only paging device, move the paging volume
to another physical device and IPL again.
This error condition may occur if the
VM/370
paging
volume
was
not
properly
formatted.
!Q!~:
DMKDSP453W CP ENTERED; PROGRAM
INTERRUPT LOOP
and enters the console function mode. Use the CP
commands to display the following information on
the terminal.
•
•
•
•
Program
Channel
General
Control
status word
status word
registers
registers
Then use the CP DUMP command to take a dump.
The following procedure should be used by the
system
operator
to
record
the
needed
information.
1.
Use the alter/display mode of the CPU
console to display the real PSW and CSW.
Also, display the general registers and the
control registers.
2.
Press the SYSTEM RESTART
system ABEND dump.
3.
IPL the system.
button to
get a
Examine this information to find what caused
the wait.
If you cannot find the cause, try to
reconstruct the situation that existed before
the wait state was entered.
If you cannot find the cause of the wait or
loop from the information just gathered, try to
reproduce the problem, this time tracing the
processing via the CP TRACE command.
If CMS is running in the virtual machine, the
CMS debugging facilities may also be used to
display information. take a dump, or trace the
processing. The CMS SVCTRACE and the CP TRACE
commands record different information.
Figure
11 compares the two.
VIRTUAL MACHINE ENABLED WAIT
If the virtual machine is in an enabled wait
state, try to find out why an I/O interruption
has not occurred to allow processing to resume.
CP ENABLED WAIT
If you determine that CP is in an enabled wait
state, but that no I/O interrupts are occurring,
there may be an error in a CP routine or CP may
be failing to get an interrupt from a hardware
device. Press the SYSTEM RESTART button on the
operator's console to cause an ABEND dump to be
taken. Use the ABEND dump to determine the cause
of the enabled (and noninterrupted) wait state.
After the dump is taken, IPL the system.
26
CP treats the following enabled wait in a
virtual machine the same as a disabled wait. If
the virtual machine does not have the real timer
option and loads a PSi enabled only for external
interrupts, CP issues the message
DHKDSP450W CP ENTERED; DISABLED WAIT STATE
Because the virtual timer is not decremented
while the virtual machine is in a wait state, it
IBH VM/370: System Logic and Problem Determination Guide
cannot cause the external interrupt. A real
timer runs in both the problem state and wait
state and an external interruption can cause a
virtual machine to resume processing.
r-------------wait
I
Problem Type
--------------,I
I----~---------~--------------------
I Problem
I Type
Disabled
virtual
machine
wait
I
I
Distinguishing
Characteristics
The VM/370 Control Program does
not allow a virtual machine to
enter a disabled wait state or
certain program loops. Instead,
CP issues one of the following
message:
DMKDSP450W
DMKDSP451W
DMKDSP452W
DMKDSP453W
Enabled
virtual
machine
wait
I
I
I
I
I
I
I
I
I
I
CP ENTERED; DISABLED
WAIT PSW
CP ENTERED; INVALID
PSW
CP ENTERED; EXTERNAL
INTERRUPT LOOP
CP ENTERED; PROGRAM
INTERRUPT LOOP
A
PSW
enabled
for
I/O
interruptions is loaded. Nothing
happens if an I/O device fails to
issue an I/O interruption. If a
program
is
taking longer to
execute
than
expected,
periodically issue the CP command,
QUERY TIME. If the processing
time remains unchanged, probably
a virtual machine enabled wait
exists.
CMS types a blip character for
every two seconds of
elapsed
processing time. If the program
does not end and blip characters
stop typing~ an
enabled wait
state probably exists.
_______________
---J
~
Figure
9.
Virtual Machine Wait Problem Type
RSCS VIRTUAL MACHINE DISABLED WAIT
Three disabled wait conditions can occur during
the operation of the RSCS component of VM/370.
They
can
result
from
either
hardware
malfunctions or system generation errors.
CP
notifies the RSCS operator of the wait condition
by issuing the message
DMKDSP450W CP ENTERED; DISABLED WAIT
PSW
to the RSCS operator's
console.
Using CP
commands, the operator can display the virtual
machine's PSW.
The rightmost 3 hexadecimal
characters indicate the error condition.
WAIT STATE CODE X'OOl': If no RSCS message was
issued;--i -progrii---check interrupt occurred
during the execution of
the program check
handler. A progra.ming error is the probable
cause.
If the RSCS message
DMTREX091 T INITIALI ZATI ON FAI LURE
-- RSCS SHUTDOWN
was issued,
RSCS operation
was terminated
because of an error in the loading of DKTAXS or
DKTLAX.
A
dump of
virtual
storage
is
automatically taken. Verify that the CMS files
'DHTAXS TEXT' and 'DMTLAX TEXT' are correctly
written and that they reside on the RSCS system
residence device.
If the RSCS message
DMTREX090T PROGRAM CHECK IN SUPERVISOR
-- RSCS SHUTDOWN
was issued, the program
check handler has
terminated RSCS because of a program check
interrupt in other than
a dispatched line
driver.
A
dump of
virtual
storage
is
automatically taken. A program.ing error is the
probable cause.
The wait state code is loaded by DMTREX at
RSCS termination or automatically during program
check handling.
If neither of the last two messages was
issued, use the CP DUMP command to dump the
contents of virtual storage.
Do an initial
program load to restart the system. If the
problem persists, notify your system support
personnel.
WAIT STATE
£QQ~
X'007':
A program
check
interrupt- has
occurred
during
initial
process1ng, before the program check handler
could be activated. This may be caused by a
programming error or by an attempt to load RSCS
into an incompatible
virtual machine.
The
latter case can occur if the virtual machine has
(1) an incomplete instruction set, (2) less than
512K of virtual storage, or
(3) does not have
the required VM/370 DIAGNOSE interface support.
The wait state code is loaded automatically
during the initial loading and execution of the
RSCS supervisor, DMTINI,
DMTREX, DMTAXS or
DMTLAX.
Verify
that
the RSCS
virtual
machine
configuration has been correctly specified and
that the "retrieve SUbsequent file descriptor"
function of DIAGNOSE code X'14' is supported.
Dump the contents of virtual storage via the CP
DUMP command.
If the problem persists, notify
your system support personnel.
WAIT STATE CODE X'011': An unrecoverable error
occorred-when-readlng-the RSCS nucleus from DASD
storage.
This may be caused by a hardware
malfunction of the DASD device.
It may also be
the result of an incorrect virtual DASD device
definition, an attempt to use a system residence
section 1. Introduction
27
device unsupported by
RSCS,
incorrect RSCS
system generation procedures, or the subsequent
overlaying of the RSCS nucleus on the system
residence device.
The wait state code is loaded
by DMTINI after an attempt, successful or not,
to issue the message:
DMTINI402T IPL DEVICE READ I/O ERROR
r-------------------------------------------,
1
RSCS Wait Problem Type
1
1---------------------------------------------1
1 Problem
Type
1
1
1
Disabled
RSCS
wait
1
Distinguishing Characteristics
1
The RSCS operator is notified of
the wait state because CP issues
the message
DMKDSP450W
Verify that the RSCS system residence device
has been properly defined as a virtual DASD
device and that the real DASD device is mounted
and operable.
If the problem persists, dump
virtual storage via the CP DUMP command and
notify your system support personnel.
The RSCS
system residence device may have to be restored
or the ascs system may have to be regenerated.
CP ENTERED;
WAIT PSW
DISABLED
If, in addition, the message
DMTINI402T
IPL DEVICE
ERROR
READ
I/O
appears on the RSCS console, an
unrecoverable error has occurred
while reading the RSCS nucleus
from DASD storage.
RSCS enters
a disabled wait state with a code
of X'Oll' in the PSW.
RSCS VIRTUAL MACHINE ENABLED WAIT
Whenever Rses has no task ready for execution,
CMTDSP loads a masked-on wait state PSW with a
code of hexadecimal zeros.
This occurs during
normal ascs operation and does not indicate an
error condition.
An external interrupt caused
by command entry or an I/O interrupt due to the
arrival of files automatically causes processing
to resume.
If a program check occurs before
the program
~heck
handler is
activated, RSCS enters a disabled
wait state with a code of X'007'
in the PSi.
If a program check occurs after
the program
check handler is
activated, RSCS enters a disabled
wait state with a code of X'OOl'
in the PSW. One of the following
messages also appear on the ascs
console:
DMTREX090T
PROGRAM
CHECK
IN
SUPERVISOR
ascs
SHUTDOWN
DMTREX091T INITIALIZATION FAILURE
- - RSCS SHUTDOWN
1-------------------_·_---------------1
1 Enabled
1 RSCS
I RSCS
has
1 execution.
no task
ready for 1
A PSW, enabled for 1
1 wait
1 external and I/O interruptions, 1
I
I is loaded with a wait code of all I
I _ _ _ _ _ _ _ _ _I_ _zeros.
L
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _._--'I
Figure 10.
28
IBM VM/370: System Logic and Problem Determination Guide
RSCS Wait Problem Type
Figure 11 summarizes the VM/370 commands that are useful in debugging.
commands are classified by the function they perform •
.--------------------------------/ Function
/ comments
/
CP Command
Stop execution at
a specified location
Set
the
address
stop
before
the
prograll
reaches a
specified
address.
CMS allows
16 address
stops
to
be active
while
CP
allows only one.
Resume
execution
Resume
Begin
execution
where prograil
was
interrupted/
Continue
execution
at a specific 1c/ cation
L________
Figure
11.
CP and CMS
------------,/
CMS Command
DEBUG
ADS TOP {heX10C }
OFF
BReak id {symbOl}
hex10c
DEBUG
GO
---------------//
/
/
/
/
/
/ DEBUG
/
/
GO { S y mh01}
/
hex10c
/
/
/
/
/
/
-------------------------------------/
/ Begin [hex1oc]
/
/
/
/
/-----------------------------
/ Dump data / Dump
the
I
I contents
I
I of specisto/
/ fic
/
I rage 10ca/
/ tions.
I
I
I
I
/
1
The
/
.-.-,
I DUMP {heX10C 1 } I {-}I hex10c21
/
Lhex10c1 /
: Un!!!
/
/
/
L
.J
/
/.-,
/
/{. }/bytecount/
I
I
I
I ~!J2
I L L
.J
I
[*dUllpid]
----------/
, /DEBUG
II
., .,
// DUmp / sYllbo11/ /symbo12/
//
/hex10c1/ /hex10c2/
//
/
Q
/ /
*
/
//
L
.I
/
.1~
/
II
L.J
.J I
[ident]
I
/
I
/
./
/
I
I
.1
_.JI
___.__-____________ _
~
SUllllary of VM/370 Debugging Tools (Part 1 of 4)
section 1. Introduction
29
r-------------------------------------------------------------,
1 Function
1 comments
1
CP Command
1
C"S Command
I
-------------------------------------------------------------1
Display
da ta
1 Display
I contents
I of storage
1 locations
1 in hexadeI cimal)
1
1
I
1
r
r
' " 1 I DEBUG
I Display hexlocl
-}I hexloc21
II X
I
I : I~!Q
I
II
I
I
L
.J
II
I
1
r
, I I
I
I{ • } I bytecount III
I
I
I ~!Q
I II
I L L
.J.J I
I{
rl
I
symbol I n i l
1!~!Hlihl
I
L
J
I
r
"1
I
I n I
I
hexloc I 4 I
I
L
.J
I
--------------------------------------------------1
I Display
I
r
r
"1' I
I
I contents
IDisplay Thexlocll{-}lhexloc21
II
I
I of storage I
I : I~!Q
I
II
I
I locations
I
I
L
.J
II
I
I (in hexa- I
I
r
, II
I
I
I { • } I bytecount I I I
I
I decimal
I and EBCDIC) I
I
I~!Q
III
I
I
I L L
.J.J I
I
1-----------------,-------------------------,-------1
I Display
I
r
r
'"1 I
I
I storage
I Display KheXlOC11{ -} I hexloc21
II
I
Ike y
0 f
I
I : I ~!Q
I
II
I
I specific
I
I
L
.J
II
I
I
I
r
, II
I
I storage
I lccations
1{.}lbytecountlll
I
I in
hex- I
I
1~!Q
III
I
I adecimal
I L L
.J.J I
I
1
1-1 Display
I general
I registers
I
I
I
---------------------------------------1
I DEBUG
I
I
IDisplay Gre g l
I
I
I
l {-}lre g 2 1
I : I~!Q I
r
"1
I
I{ • }I regcoun t I
I
1
r
r
,
,
I~!Q
1 GPR regl [reg2]
I
I
I
I
I
I
I
1'1
I
I
ILL.J.J
1 Display
I floatingI point
I registers
I
I
I
I
I
r
r
,
,
I Display Yregll{ -} Ireg21
I
I
I : I~!Q I
I
I l L
.J
I
I
I
r
, I
1
I{ • }I regcount"
I
I
I~!Q
II
ILL.J.J
I Display
I control
I registers
I
I
r
r
,
IDisplay Xreg11{-}lreg21
I
I : I~!Q I
L.J
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
1------------------------------------------------1
I
I
1
--------------------1
,
I
I
I
I
I
I
I
I
I
I
I
I
I{. }lregcountll
I~!Q
II
I
I
ILL.J.J
I
I
I
I
I
I
I DEBUG
I PSW
I
I
I
I
I
I
I
I
I
I
I
r
,
1--------------------------------------------·-------1
I
I
I
I
I
I
I
Display
I Display
contents
I
of current I
virtual
I
PSW
in I
hexadecimal I
format
I
PSW
1--------------------------------
1
·-----1
I Display
I Display
CAW
DEBUG
I
I CAW
con- 1
CAW
I
I tents
I
I
I
1-------------------,-------_·_------------------_·_--I
I Display
I Display
CSW
I DEBUG
I
I CSW
con- I
I CSW
I
I tents
I
I
- - . JI
L________
Figure
30
11.
_________________________________.__.___
Summary of V"/370 Debugging Tools (Part 2 of 4)
IB" VM/370: System Logic and Problem Determination Guide
r---------------------------------------------------------------,
1 Function
1 Co •• ents
CP Command
1
eMS Command
1
-------------------------------------1
store
data
store
1
1
1
specified
ISTore Shexloc hexdata...
1 DEBUG
1
infor.a1
1 STore {SYllbOl} hexinfo
1
tion into 1
1
hexloc
1
consecutive storage locations w i t h - I I I
out align- 1
1
1
1
1
1
1 mente
1
11
1
1
1
1
1
1
1-----------------------------------------------------------1
1 Store
1
1
1
1
1
1
1
1
specified
1STore {hexloc }
words of
1
Lhexloc
information 1
into con- 1
(hexvord1[hexword2 ••• ])
secutive
1
1 fullword
1
1 storage
1
1 locations
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1 Store
ISTore Greg hexword1
[hexword2 ••• ]
1 specified 1
1 words of
1
1 information 1
1 into con1
1 secutive
1
1 general
1
1
1 registers
IDEBUG
1
ISET GPR reg hexinfo[hexinfo] 1
1------------------------------------------------------I
1
1
1
1
1
1
1
1
1
1
1
1
I-------------------------------------~-~--·~--"------------------1
1
1
1
1
1
1
1
1
1
Store
1 STore Ireg hexword 1
specified 1
[hexword2 ••• ]
words of
1
informationl
into con- 1
secutive
1
floating- 1
point
1
registers 1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1--------------------------------------------------1
1 Store
1STore Xreg hexword 1
1
1
1 specified
1 words of
1 data into
1
1
1
[hexword2 ••• ]
1
1
1
1
1
1
1 consecutive 1
1
1
1 control
1 registers
1
1
1
1
1
1
1
------------------------------~--------I
1 Store
1STore PSW [hexword1] hexword2
1 inforaationl
1 into PSW
1
IDEBUG
ISET PSW hexinfo [hexinfo]
1
1
1
1
1-------------------------------------------------1
1 store
1
1 informationl
1 in CSW
1
IDEBUG
ISET CSW hexinfo [hexinfo]
1
1
1
1
1----------------------------------------------------------1
1 Store
1
1DEBUG
1
1 informationl
ISET CAW hexinfo
1
1_in
1 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 1_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _--'1
L ________
_ _CAW
______
Figure
11.
Summary of VM/370 Debugging Tools (Part 3 of 4)
section 1. Introduction
31
,.------------------------------_._----------------------------------,
I Function 1 Comaents 1
CP Command
1
C~S Command
,
--------------·_-------------------------------1
Trace
Trace all 1 TRace ALL
,
1
execution
1
instructions,
1
interrupts, 1
and
1
1 branches
1
1,
11
1
1
1
1
1
1
1----------------------------------------------------------------1
1 Trace SVC
1 TRACE
SVC
1 interrupts 1
1 SVCTrace ON
1
1
1
1
1
1
1
1------·_----------------------------------------------------------1
1 Trace I/O
1 interrupts
1 TRace
1
I/O
PROgram
1--------------------------------------------------------I
1 Trace
1 TRace
1 program
1 interrupts
1
1
I Trace
1 TRace
1 external
1 interrupts
1
1
1
1
1
1
1
1
1-----------_·_----------------------------------------------1
EXTernal
I
1
1
I
,
1
1
1------------------------------------------------------------1
1 Trace
1 TRace PRIV
1
1
I privileged
1
1
1 instruc-
1
I
1
1 tions
1
1
1
1
I
1
1
1
1
1
1 Trace all
TRace
1 user I/O
1 operations I
SIO
1 Trace
SIO
CCW
-----------------·-------1
1-------------------------------------------------------I
1 TRace
I virtual andl TRace
1
1
1
1
1 real CCws
1
1
1
1 Trace
1 all user
1 TRace BRANCH
1
1
1
1
1
1---------------------------------------------------1
1 interrupts 1
1
1
1 and suc1 cessful
1
1
1
1
1
1
1 branches
1
I
1
1 Trace
1 TRace INSTruct
1
1
1 all in-
1
I
1
1 structions 1
1
1
1 End all
1 tracing
1 activity
1 TRace END
1
1
1 SVCTrace OFF
1
1
1
1
1
1 Trace reall Trace
1 MONitor STArt CPTRACE
1
1
1 machine
I events
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1------------------_·_-----------------------_·_--------I
1-----------------------------------------------------------,
1----------------------------------------------------------------·---1
1
1 events in
1 real
1 machine
1-----------------------------------------------------'---1
1 stop trac- 1 MONitor STOP CPTRACE
1 ing events 1
1
1
l i t h e real
1
1L _ _ _ _ _ _ _ _ _I _machine
1 ___________________________
1 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _.__ --'1
_________
Figure
32
11.
Summary of VM/370 Debugging Tools (Part 4 of 4)
IBM VM/370: system Logic and Problem Determination Guide
If you are debugging problems while your
virtual machine is running CMS, you can
choose the CP or CMS debugging tools. See
•
Figure 12 for a comparison
CMS debugging tools.
---------
1 Function 1
CP
1
of the
CP and
I
CMS
1
1 hexadecimal
format.
The
I storage
address of the
I first byte of each line is
I identified at the left.
I The contents of the genI eral and
floating-point
1 registers are printed at
I the beginning of the dump.
1
adecimal format.
The CMS
commands
do
not
display
storage
keys,
floating-point
registers
or control registers as
as the CP command does.
I
1
I
1
I
1
I
I
1----------------------------------------1
setting
Can set only one address 1 Can set up to 16 address 1
address
stop at a time.
1 stops at a time.
1
stops
1
1
-------------------------1
Dumping
The dump is printed in hexa- 1 The dump is printed in 1
contents
of storage to
the
printer
decimal format with EBCDIC
translation. The storage address of the first byte of
each line is identified at
the left. The control blocks
are formatted.
Display
the contents of
storage
and control registers
at
the
terminal
The display occurs in hexadecimal format with EBCDIC
translation. The CP command
displays
storage
keys,
floating-point registers and
control registers.
information
stored by the CP command is
limited only by the length
of the input line. The information can be fullword
aligned when stored. CP
stores data in the PSW, but
not in the CAW or CSW. However, data can be stored in
the CSW or CAW by specifying
the hardware address in the
STORE command. CP also
stores the status of the
virtual machine in the
extended logout area.
Tracing
information
CP traces:
--------------------_.------storing
The amount of information
• All interrupts, instructions and branches
• SVC interrupts
• I/O interrupts
• Program interrupts
• External interrupts
• Privileged instructions
• All user I/O operations
• Virtual and real CCW's
• All instructions
I
1
1
I
I
I
1
1
The display occurs in hex- 1
The CMS command stores up
to 12 bytes of information
and can store data in the
general registers but not
in the floating-point or
control registers. CMS
stores data in the PSW,
CAW, and CSW.
CMS traces all SVC interrupts. CMS displays the
rupts. CMS displays the
contents of general and
floating-point registers
before and after a routine
is called. The parameter
list is recorded before a
routine is called.
The CP trace is interactive.
You can stop and display
other fields.
'---------------------------------------12. Comparison of CP and CMS Facilities
Figure
for Debugging
Section 1. Introduction
33
dump data must fit on one reel; VM/370
does
not
support
multiple
tape
volumes.
Many CP
problems can be
isolated without
standalone machine testing.
It is possible to
debug CP by running it in a virtual machine.
In
most instances, the virtual machine system is an
exact replica of the system running on the real
machine. To set up a CP system on a virtual
machine, use the same procedure that is used to
generate a
Cf system on a
real machine.
However, remember that the entire procedure of
running service programs is now done on a
virtual machine. Also, the virtual machine must
be described in the real VM/370 directory. See
the !~LdlQ:
2Y2!~!
g£Qg£~!!~~~2
§~!~~
for
directions for setting up the virtual machine.
ABEND DUMPS
A third kind of dump occurs when the CP
system
cannot continue.
The CP
abnormal
termination dumps can be directed to a printer
or tape or be dynamically allocated to DASD.
If
the dump is directed to a tape, the dumped data
must fit on one reel of tape.
Multiple tape
volumes are not supported
by VM/370.
The
historical data on the tape is in print line
format and can be processed by user-created
programs or via CMS commands.
Use the CP SET command to specify the output
device for CP ABEND dumps.
The format of the
SET comlland is:
l-=~r-l-::::-l:~!~r -1-T~tLT-I--l
I
I
dumps only the CP storage area.
ALL
dumps all of real storage.
USING THE VMFDUMP COMMAND
Use the CMS VMFDUMP command to print the dump on
the real printer, when the CP ABEND dump is sent
to a disk.
The format of the VMFDUMP command
is:
---------------------,
,
,
I
r---
There are three kinds of abnormal termination
dumps possible when using CPo The first kind
occurs when the problem program cannot continue.
It terminates and in some cases attempts to
issue a dump.
The second occurs when the
operating system for your virtual machine cannot
continue.
It terminates and in some cases
attempts to issue a
dump.
In the VM/370
environment, both the problem program and the
virtual machine's operating system dumps go to
the virtual printer.
A CLOSE must be issued to
the virtual printer to have either dump print on
the real printer.
I
I
CP
I
I
I
r
r
I
I ERASE
I VMFDUMP
I
I
I NOMAP
I DUMPxx I
I NOHEX
I
I
I
.I
L
I
I NOFORM
I
I NOVIRT
IL_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _L _ _ _ _ _ _
I
I
I
I
I
.I
I
I
I
I
I
I
_.I
DUMP:xx
specifies the name of the CP dump file
to be formatted and printed.
xx may
be any value from 00 to 09.
Class D
spool files contain
only CP dump
files.
These files are searched for
the indicated dump file.
When the
file is found, it is used to create a
CMS file which, in turn, is formatted
and printed.
ERASE
specifies that the CMS file which is
being formatted and printed is to be
erased at
the conclusion
of the
program.
NOMAP
specifies that a load map is not to be
printed.
NOHEX
specifies that a hexadecimal
not to be printed.
dump is
ROFORM
specifies that no formatted
blocks are to be printed.
control
NOVIRT
specifies that only the real machine
control blocks are to be formatted.
This option is ignored if ROFORM is
also specified.
I
I
L.I
L _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _,,________________________
.1
Use the VMFDUMP command to format and print a
current or previous VM/370 system ABEND dump.
Specify
DUMP
specifies the ABEND Dump.
AUTO
automatically directs
to disk.
VMFDUMP
raddr
34
the ABERD
dump
directs
the
ABEND dump
to
the
specified unit
address
(either
a
printer or a tape unit).
If the
address specifies a tape device, the
to obtain
printout.
a
complete
formatted,
When the dump has been
messages is printed:
IBM VM/370: System Logic and Problem Determination Guide
hexadecimal
printed, one
of two
DUMP FILE - DUMP xx - PRINTED AND KEPT
"Load
Map"
later
in
this
section
instructions for generating a load map.
for
-- or -DUMP FILB - DUMP xx - PRINTBD AND ERASBD
REASON FOR THE ABEND
HOW TO PRINT A CP ABBND DUMP FROM TAPE
When the CP ABBBD dump is sent to a tape, the
records are
133 characters
unblocked, and
include carriage control characters.
Determine the immediate reason for the ABEND.
You need to examine several fields in the PSA
(prefix storage Area) which is located in low
storage, to find the reason for the ABEND.
•
Examine the program old PSW and program
interrupt code to find out if a program check
occurred in CPo The program old PSW (PROPSW)
is located at X'2S' and the program interrupt
code (INTPR) is at X'SB'.
If a program check
has occurred in supervisor mode, use the CP
system load map to identify the module.
If
you cannot find the module using the load
map,
refer to
"Identifying a
Pageable
Module."
•
Examine the SVC old PSW, the SVC interrupt
code, and the ABEND code to find out if a CP
routine issued an SVC O.
The SVC old PSW
(SVCOPSW)
is located at
X'20', the SVC
interrupt code (INTSVC) is at X'SA', and the
ABEND code (CPABEND) is at X'374'.
To print the tape, first make sure the tape
drive is attached to your system. Next, define
the printer and tape file:
FILEDEF ddname1 PRINTBR (RECPM P LRECL 133)
FILEDEF ddname2 {TAP2} (9-track DBB 1600
TAP1
RECPM F LRBCL 133 BLOCK 133)
Then use
tape:
the MOVEFILE
command to
print the
MOVEFILE ddname2 ddname1
The modules that may issue an SVC 0 are:
DMKBLD
DMKCFG
DMKCKS
DMKCPI
DMKCVT
DMKDRD
DMKDSP
DMKFRE
DMKHVD
DMKIOS
DMKNLD
DMKPGS
DMKPGT
DMKPRG
Two types of printed
dumps occur when CP
abnormally ends,
depending on
the options
specified in the CP SBT DUMP command. When the
dump is directed to a direct access device,
VMPDUMP must be used to format and print the
dump. VMFDUMP formats and prints:
•
•
•
•
•
•
•
Control blocks
General registers
Floating-point registers
Control registers
TOD (Time-of-Day) clock
CPU timer
Storage
The ABEND code (CPABEND) is a full word in
length. The first three bytes identify the
module that issued the SVC 0 and the fourth
hyte is
a binary
field
whose
value
indicates the reason for issuing an SVC O.
See "CP ABEND Codes, Reason and Action" in
section 3.
is printed
in
hexadecimal
Storage
notation, eight words to the line, with BBCDIC
translation at the
right.
The hexadecimal
address of the first byte printed on each line
is indicated at the left.
!Q~~:
If the CP SET DUMP command directed the dump
to tape or the printer, the printed format of
the dump is the same as with VMFDUMP, except
that the control blocks are not formatted and
printed.
When CP can no longer continue and abnormally
terminates,
you must
first determine
the
condition that caused the ABEND, and then find
the cause of that condition. You should know
the structure and function
of the Control
Program. The following discussion on reading CP
dumps includes many references to CP control
hlocks and control hlock fields.
Refer to
!~L12Q: R~~~ A~~~2 ~~g ~Q~~~Q! ~!Qf! 1Qg!f for a
description of the CP control blocks.
You will
need the current load map for CP to he ahle to
identify the modules from their locations. See
DMKPSA
DMKPTR
DMKRGA
DMKRNH
DMKRPA
DMKSCH
DMKTDK
DMKUDR
DMKVDB
DMKVDR
DMKVIO
DMKVMA
DMKVSP
Use the CP system load map to identify the
module issuing the SVC O. If you cannot
find the module using the CP system load
map, refer to
"Identifying a Pageahle
Module" in this Section.
• Examine the old PSW
at X'OS'.
If the
operator has pressed
the SYSTEM RESTART
button on the CPU console,
the old PSW
indicates the instruction executing when the
ABEND (caused hy pressing the SYSTEM RESTART
hutton) was recognized.
•
For a machine check, examine the machine
check old PSW and the logout area.
The
section 1. Introduction
35
machine check old PSW
(MCOPSW) is found at
X'30' and the fixed logout area is at X'100'.
Also examine the machine check interrupt code
(INTMC) at X'E8'.
COLLECT INFURMATION
To trace control blocks and
necessary to
know the
CP
conventions.
may contain
~~g!~!~!:
GRl
GR2
GR6,7,8
GR10
GR14,15
always contain
CP Running status Field
The CP running status is stored in CPSTAT at
location X'348'. The value of this field
indicates the running status of CP since the
last entry to the dispatcher.
CPSTAT Values gDg ~~gD!Dg
in wait state
X'40'
CP is running the user in RUNUSER
X'20'
CP is executing a stacked request
X'80'-
•
it is
usage
Contents
The-vIrtual address to be translated
The real address or parameters
The address of the active VMBLOK and
device control blocks
The address of the active IOBLOK
The external branch linkage
The following general registers
the saDe information:
•
modules,
register
The 16 general registers have many uses that
vary depending upon the operation. The contents
of some of the general registers follows:
Examine several other fields in the PSA to
analyze the status of the system.
As you
progress in reading the dump,
you may return to
the PSA to pick up pointers to specific areas
(such as pointers to the real control blocks) or
to examine other status fields.
The following areas of the PSA
useful debugging information.
REGISTER USAGE
-cp-is
!!~.9j.§!~.!:
GRll
GR12
GR13
Contents
'The-address of thE! active VMBLOK
The base register
for the module
executing
The address of the current save area,
if the module was called via an SVC
Use these registers, the CP control blocks,
and the data in the prefix storage area to
determine the error that caused the CP ABEND.
Current User
SAVE AREA CO.VENTIONS
The PSW that was most recently loaded by the
dispatcher is saved in RUNPSW at location
X'330',
and the address of the dispatched
VMBLOK is saved in
RUNUSER at location
X'338'.
Also,
examine the
contents of
control registers 0 and 1 as they were when
the last PSW was dispatched.
See RUNCRO
(X'340') and RUNCRl (X'344')
for the control
registers.
Also, examine the CP internal trace table to
determine the events that preceded the abnormal
termination. start with the last event recorded
in the trace table and proceed backward through
the trace table entries. The last event recorded
is the last event that was completed.
The trace table is at least one page (4096
bytes) long.
Cne page is allocated to the trace
table for each block of 256K bytes of real
storage available at IPL.
Each trace table
entry is 16 bytes leng.
The TRACSTRT field
(location X'OC') contains the address of the
start of the trace table.
The TRACEND field
(location X'10') contains the address of the
byte following the end of the trace table. The
address of the next available trace table entry
is found
in the TRACCURR
field
(location
X'14').
There are three save areas that may be helpful
in debugging CPo
If a module was called by an
SVC, examine the SAVEAREA. SAVEAREA is not in
the PSAi
the address of the SAVEAREA is found
in general register 13. If a module was called
by a BALR, the general registers are saved in
the PSA in an area called BALRSAVE
(X'240').
The DMKFRE save area and work area is also in
the PSA:
these areas are only used by the
DMKFREE and DMKFRET routines.
The DMKFRE save
area (FREESAVE)
is at location X'280'
and its
work
area
(FREEWORK)
follows at
location
X' 2CO' •
Use the save areas to trace back and find the
previous module executed.
•
SAVEAREA
An active save area contains the caller's
return address in
SAVERETN
(displacement
X'OO'). The caller's base register is saved
in SAVER12
(displacement X'04'), and the
address of the save area for the caller is
saved in SAVER13 (displacement X' 08'). Using
SAVER13, you can trace back again.
subtract 16
(X '10') bytes from the value at
X' 14' (TRACCURR) to find the address of the last
trace table entry recorded.
36
IBM VK/370: SY5tem Logic and Problem Determination Guide
•
•
BALRSAVE
•
All the general registers
are saved ~n
BALRSAVE after branching and linking
(via
BALR)
to another routine.
If you look at
BALR14 for the return address saved, BALR13
for the caller's save area, and BALR12 for
the caller's base register, you can trace
module control backwards.
Examine the virtual PSW and the last virtual
machine privileged instruction.
The virtual
machine PSW is saved in VMPSW (displacement
X'AS') and the virtual /lachine privileged or
tracing instruction
is saved
in VMINST
(displacement X'9S').
•
Find the name of the last CP command that
executed in VMCOMND (displacement X'14S').
•
Check the status of
following
fields
information.
FREESAVE
All the general registers
are saved in
FREESAVE before DMKFRE executes.
Use the
address of FREESAVE to trace module control
backwards.
Field
FREER 15
FREER14
FREER13
FREER12
FREERl
FREERO
I/O activity.
The
contain
pertinent
VMPEND (displacement X'63') contains the
interrupt pending summary flag.
The value
of
VMPEND
identifies
the
type
of
interrupt.
contents
The---entry
point
(DMKFREE
or
DMKFRET)
The saved return address
The caller's save area (unless the
caller was called via BALR)
The caller's base register
Points to the block returned (for
calls to DMKFRET)
Contains the number of doublewords
requested or returned
VMPEND
Values
i'4'o'X'20'
X'10'
X'OS'
X'02'
X'Ol'
!!~!!i!!g
Virtual
PER
(Program
Event
Recording) interrupt pending
Virtual program interrupt deferred
Virtual SVC interrupt deferred
Virtual pseudo page fault pending
Virtual I/O interrupt pending
Virtual external interrupt pending
VIRTUAL AND REAL CONTROL BLOCK STATUS
VMIOINT (displacement X'6A')
contains the
I/O interrupt pending flag.
Each bit
represents a channel (0-15). An interrupt
pending is indicated by
a 1 in the
corresponding bit position.
Examine the virtual and real control blocks for
more information on the
status of the CP
syste/l.
V"IOINT
Values
10000000
VMBLOK
The address of the VMBLOK is in general register
11. Examine the following VMBLOK fields:
•
01000000
00000000 Interrupt pending
on channel 0
00000000 Interrupt pending
on channel 1
The
virtual machine
running status
is
contained in VMRSTAT
(displacement X'SS').
The value of this field indicates the running
status:
000000'00
VMRSTAT
Status
i'80'X'40'
X' 20'
X'10'
X' 08'
X'04'
X'02'
X'Ol'
•
!!~!!niBg
~~!!!ti:B9
Waiting, executing console function
Waiting, page operation
Waiting, scheduled IOBLOK start
Waiting, virtual PSW wait state
Waiting, instruction siaulation
User not yet logged on
User logging off
virtual /lachine in idle wait state
The virtual .machine dispatching status is
contained in VMDSTAT
(displace/lent X'S9').
The value
of this field
indicates the
dispatching status:
VMDSTAT
Values
X'80'X' 40'
X'20'
X '10'
X'OS'
X'04'
~~!!B!B9
virtual
machine
is
dispatched
RUIUSES
virtual machine is compute bound
virtual machine in-queue time slice
end
Virtual /lachine in TIO/SIO busy loop
virtual machine is runable
Virtual machine in a queue
00000001 Interrupt pending
on channel 15
VMIOACTV
(displacement
X'36') is
the
active channel mask. An active channel is
indicated by a 1 in the corresponding bit
position.
VCBBLOK
The address of the VCBBLOK table is found in the
V"CBSTRT field
(displacement
X'lS')
of the
VMBLOK.
General register 6 contains the address
of the active VCBBLOK. Examine the following
VCBBLOK fields:
•
The virtual channel address is
VCBADD (displace sent X' 00 ') •
contained in
•
The status of the virtual channel is found in
the VCBSTAT field (displacement X'06'). The
value of this field indicates the virtual
channel status:
Section 1. Introduction
31
VCHSTAT
Values
X'80'X'40'
X'01'
•
VDEVSTAT
values
!1~~!!!!!g
X'80'- virtual subchannel busy
Virtual channel interrupt pending
X' 40'
virtual device busy
X'20'
virtual device :interrupt pending
X' 10'
virtual control unit end
X'OS'
virtual device :not ready
X' 04'
Virtual device attached by console
X'02'
function
VDEVREAL is dedicated
to device
X'01'
RDEVBLOK
tl~~!!!!!9
Virtual channel busy
Virtual
channel class
pending
virtual channel dedicated
interrupt
The value of the VCHTYPE field (displacement
X'07') indicates the virtual channel type:
VCHTYPE
Values
X'80'X'40'
~~~!!i!!g
Virtual selector channel
Virtual block multiplexer
•
The value of the VDEVFLAG field (displacement
X'07')
indicates
the
following
device
dependent information:
VCUBLOK
VDEVFLAG
Values
!1~~!!!!!g
X'80'- DASD--read-only device
Virtual 2701/2702/2703 device--line
X'SO'
enabled
DASD--TDISK space allocated by CP
X' 40'
Virtual 2701/2702/2703 device--line
X'40'
connected
Console--activity spooled
X'40'
DASD--2311 device simulated on top
X' 20'
half of 2314
DASD--2311
device
simulated
on
X' 10'
bottom half of 2314
Console
and
spooling
X'10'
device--processing first ccw
DASD--executing standalone seek
X'OS'
RESERVE/RELEASE
are
valid
CCW
X'02'
operation codes.
Vi~tual device sense bytes present
The address of the VCUBLOK table is found in the
VCUSTRT field
(displacement X' 1C')
of the
VMBLOK. General register 7 contains the address
of the active VCUBLOK.
Useful information is
contained in the following VCUBLOK fields:
•
The virtual control unit address is found in
the VCUADD field (displacement X'OO').
•
The value of the
1'06') indicates
control unit:
VCUSTAT
Values
X'80'X '40'
X'20'
X'10'
!1~~!!i!!g
Virtual subchannel busy
Interrupt pending in subchannel
Virtual control unit busy
Virtual
control
unit
interrupt
pending
Virtual control unit end pending
•
The
VDEVCSW field
(displacement
X'OS')
contains the virtual channel status word for
the last interrupt.
The value of the VCUTYPE field (displacement
X'07')
indicates the type of the virtual
control unit:
•
The VDEVREAL
field
(displacement
contains the pointer to the real
block, RDEVBLOK.
VCUTYPE
Values
•
The
VDEVIOB field
(displacement
X'34')
contains the pointer to the active IOBLOK.
•
For console
devices, the value
of the
VDEVCFLG field (displacement X'26') describes
the virtual console flags:
X'OS'
•
VCUSTAT field (displacement
the status of the virtual
X'80'X'40'
~~~!!i!!g
virtual control
unit on
shared
subchannel
Virtual
control
unit
is
a
channel-to-channel adapter
VDEVCFLG
values
!1~~!!!!!9
X'80'- User signaled attention too many
times
Last CCW processed was a TIC
X'40'
Data transfer occurred during this
X'20'
channel program
Virtual console function in progress
X' 10'
Automatic carriage return on first
X'OS'
read
VDEVBLOK
The address of the VDEVBLOK table is found in
the VMDVSTRT field (displacement X'20')
of the
VMBLOK. General register S contains the address
of the active VDEVBLOK.
Useful information is
contained in the following VDEVBLOK fields:
•
•
The virtual device address is found
VDEVADD field (displacement X'OO').
•
The value of the VDEVSTAT field (displacement
X'06') describes the status of the virtual
device:
3S
in the
X' 24')
device
For spooling devices, the
value of the
VDEVSFLG field (displacement X'27') describes
the virtual spooling flags:
IBM VM/370: system Logic and Problem Deteraination Guide
VDEVSFLG
Values
li~g!!!119
i 7 8'0'Spool reader--last command was a
feed
X I 80 1
Spool output--transfered to VSPXXUSR
I
1
X 40
Spool device--continuous operation
X I 20 1
Hold output--save input
1
XI 10
Spool
output--for
user
and
distribution
XI 08 1
Spool input -- set unit exc~ption at
EOF
XI 08 1
Terminal output required for spooled
console
X I 04 1
Device closed by console function
XI 02 1
spool output--purge file at close
XI 02 1
spool
input--device
opened
by
DIAGNOSE
X 1011
Spool output--DMKVSP entered via SVC
RCUBLOK
The address of the first RCUBLOK is found in the
ARIOCU field
(displacement X 1 3B8 1) of the PSA.
General register
7 points to
the current
RCUBLOK. Examine the following RCUBLOK fields:
•
The
RCUADD
field
(displacement
XIOOI)
contains the real control unit address.
•
The value of the
X1041) describes
unit:
RCUSTAT
Values
i'so'1140 1
X 20
X I Ol l
I
•
For output spooling devices, the VDEVEITN
field
(displacement
Xll01)
contains
the
pointer to the virtual spool extension block,
VSPXBLOK.
•
i'80'-
The address of the first RCHBLOK is found in the
ARIOCH field
(displacement I13B41)
of the PSA
(Prefix Storage
Area).
General
register 6
contains the address of the active RCHBLOK.
Examine the following RCHBLOK fields:
X Ol
XI 02 1
1103 1
XI 04 1
I
•
•
The real channel address is found in
RCHADD field (displacement XIOOI).
•
The value of the RCHSTAT field (displacement
X 1041)
describes the status of the real
channel.
RCHSTAT
Values
x'SO'X 40
1
X' 20 1
X '0 l'
•
1!~~ning
Channel busy
lOB scheduled on channel
Channel disabled
Channel dedicated
Control unit busy
lOB scheduled on control unit
Control unit disabled
Control unit dedicated
l
l1~gn!!!g
This control unit can attach to only
one subchannel
TCU is a 2701
TCU is a 2702
TCU is a 2703
Subordinate control unit
The RCUFIOB field (displacement 1108 1 ) points
to the first IOBLOK in the queue and the
RCULIOB field (displacement XIOCI) points to
the last IOBLOK in the queue.
RDEVBLOK
The address of the first RDEVBLOK is found in
the ARIODV field (displacement XI 3BCI) of the
PSA. General register 8 points to the current
RDEVBLOK. Also, the VDEVREAL field (displacement
11241) of each VDEVBLOK contains the address of
the associated RDEVBLOK. Examine the following
fields of the RDEVBLOK:
XIOOI)
The value of the RCHTYPE field (displacement
X'05 1) describes the real channel type:
•
The
RDEVADD field
(displacement
contains the real device address.
RCHTYPE
values
•
The values of the RDEVSTAT
(displacement
XI 04 1 ) and RDEVSTA2
(displacement X143 1)
fields describe the status
of the real
device:
x'SO'X 40
I
1
X 20
XI Ol l
I
•
the
1!~g!!i!!g
The value of the RCUTYPE field (displacement
X105 1) describes the type of the real control
unit:
RCUTYPE
Values
RCHBLOK
I
1
RCUSTAT field (displacement
the status of the control
1
1!~~!!ing
Selector channel
Block multiplexer channel
Byte mUltiplexer channel
System/370 type channel (System/370
instruction support)
The RCHFIOB field (displacement X108 1 ) is the
pointer to the first IOBLOK in the queue and
the RCHLIOB field (displacement XIOCI) is the
pointer to the last IOBLOK in the queue.
RDEVSTAT
Values
l1~g!!i!!g
Device busy
i7
lOB scheduled on device
XI 40 1
1120 1
Device disabled (offline)
II 10 1
Device reserved
XI 08 1
Device in intensive error recording
mode
Device intervention required
XI 04 1
11021
GRAF
IOBLOK
pending;
queue
requests
I
l
Dedicated device
(attached
X Ol
to a
user)
so'-
Section 1. Introduction
39
RDEVSTA2
Values
!15H!!!!!!g
X'80'- Active device is being reset
Device is busy with the channel
X'40'
Contingent connection present
X'20'
•
The value of the RDEVFLAG field (displacement
X'05') indicates device flags.
The following
flags are device dependent.
RDEVFLAG
Values
~t~~!!!!!g
1'80'- DASD--ascending order seek que?eing
DASD--volume preferred for pag1ng
X'40'
DASD--volume attached to system
X'20'
DASD--CP owned volume
X'10'
DASD--volume
mounted
but
not
X'OS'
attached
Console--terainal has print suppress
X'SO·
feature
Console--terminal executing prepare
X'40'
command
Console--IOBLOK
pendingi
queue
X'20'
request
Console--2741
terminal
code
X' 10'
identified
Console--device is enabled
X'OS'
Console--next interrupt from a halt
X'04'
I/O
Console--device is to be disabled
X '02'
Consolp.--3704/3705 NCP resource in
X' 0 l'
EP mode
Spooling--device output drained
X'SO'
Spooling--device output terminated
X' 40'
Spooling--device
busy
with
X'20'
accounting
Spooling--force printer to single
X '10'
space
Spooling--restart current file
X'OS'
Spooling--backspace the current file
X' 04'
Spooling--print/punch job separator
X'02'
Spooling--UCS buffer verified
X' 0 l'
Special--network control program is
X'SO'
active
Special--2701/2702/2703
emulation
X'40'
program is active
Special--3704/3705
is in
buffer
X'20'
slowdown mode
Special--automatic
dump/load
is
X '10'
enabled
Special--IOBLOK is pendingi queue
X'OS'
requests
Special--emulator lines are in use
x'04'
by system
Special--automatic dump/load process
X'02'
is active
Special--basic terminal unit trace
X' 01'
requested
•
The RDEVIOER
field
(displacement
X'48')
contains the address of the IOERBLOK for the
last CP error.
•
For spooling unit record devices, the RDEVSPL
field
(displacement X'lS')
points to the
active RSPLCTL block.
•
For
real
3704/3705
Communications
Controllers, several
pointer fields
are
defined.
The RDEVEPDV field
~isplacement
X'lC')
points to the .start of the f:ree
RDEVBLOK list fer EP lines. The RDEVNICL
field
(displace.ent X'38')
points to the
network control list and the RDEVCKPT field
(displacement X'3C')
points to the CKPBLOK.
Also, the RDEV"AX field (displacement X'2E')
is the highest valid NCP resource name and
the RDEVNCP field (displacement X'30') is the
reference name of the active 3705 RCP.
•
For terminal devices, additional flags are
defined. The value of the RDEVTFLG field
(displacement r'3A') describes the additional
flags:
RDEVTFLG
Values
l1~!!J!!!!g
X'80'- Terminal--logon process has been
initiated
Terminal--terminal in reset process
X'40'
Terminal--suppress attention Signal
X'20'
Graphic--logon process initiated
x'so'
Graphic--screen
full, more
data
X' 40'
waiting
Graphic--screen in running status
X'20'
Graphic--read pending
for screen
X' 10'
input
Graphic--last input not accepted
X'OS'
Graphic--timer request pending
X' 04'
Graphic--control
function
X'02'
interruption pending
Screen full, hold status
X'Ol'
•
For terminals, an additional flag is defined.
The value of the RDEVTMCD field (displacement
X'46') describes the line code translation to
be used:
RDEVTMCD
Values
!1~g!!!!!g
1'10·- UASCII--S level
APL
correspondence
x'oC'
APL PTTC/EBCD
x' os'
Correspondence
X'04'
PTTC/EBCD
x' 00'
IDENTIFYING A PAGEABLE MODULE
The value of the RDEVTYPC field (displacement
X'06') describes the device type class and
the value of the RDEVTYPE field (displacement
X'07') describes the device type.
•
The RDEVAIOE
field
(displacement
X' 24' )
contains the address of the active IOBLOK.
•
The RDEVUSER
field
(displacement
X' 2S')
points to the VMBLOK for a dedicated user.
The
RDEVATT field
(displacement
X'2C')
contains the attached virtual address.
40
If a program check PSi or SVC PSi points to an
address beyond the end of the CP resident
nucleus, the failing module
is a pageable
module. The CP system load map indicates where
the end of the resident nucleus is located.
Go to the address indicated in the PSi.
Backtrack to the beginning of that page frame.
The first eight bytes of that page frame (the
page frame containing the address pointed to by
the PSi)
contain the
name of the failing
module. If multiple modules exist within the
IBM VM/370: System Logic and Problem Determination Guide
same page frame, identify the module using the
load map and failing address displacement within
the page frame.
When CMS abnormally terminates, the terminal
operator must issue the DEBUG command and then
the DUMP subcommand if an ABEND dump is desired.
The DUMP formats and prints the following:
•
•
•
•
General registers
Extended control registers
Floating-point registers
storage boundaries with their
storage protect key
Current PSW
selected storage
•
•
corresponding
storage is printed in hexadecimal, eight
words to the line with EBCDIC translation at the
right.
The
hexadecimal
storage
address
corresponding to the first byte of each line is
printed at the left.
When
CMS can
no
longer continue,
it
abnormally terminates. You must first determine
the condition that caused the ABEND and then
find why the condition occurred.
In order to
find the cause of a CMS problem, you must be
familiar with the structure and functions of
CMS.
The discussion ab6ut reading'CMs dumps
refers to several CMS control blocks and fields
in the control blocks. Refer to the !~L37~:
&g~g
!I~g2
g~g
£g~!~gl
~lg£! 199i£
for a
description of each CMS control block. Figure
13 shows the relationships
of CMS control
blocks.
You also need a current CMS nucleus
load map to analyze the dump.
3.
Examine the external old PSW
(EXTOPSW) at
location X'lS'. If the virtual machine
operator terminated CMS, this PSW points to
the
instruction
executing
when
the
termination request was recognized.
4.
For a machine check, examine the machine
check old PSW (MCKOPSW) at location X'30'.
COLLBCT INFORMATION
Bxamine several other fields in NUCOH to analyze
the status of the CMS system. As you proceed
with the dump, you may return to NUCON to find
pointers to specific areas
(such as pointers to
file tables) or to examine other status fields.
The complete contents of NUCON and the other CMS
control blocks are described in the !J!ilZQ: !2atg
!~~g2 ~n~
£Qn~~Q! §!Q£!
Logi£. The following
areas of NUCON may contain useful debugging
information.
NUCON ARBAS
•
Save Area For Lov storage.
Before executing, DEBUG saves the first 160
bytes of low storage in a NUCON field called
LOWSAVE. LOiSAVE begins at X'CO'.
•
Register Save Area.
DMSABN, the ABEND routine, saves the user's
floating-point and general registers.
Contents
Userts~loating-point
registers
User's general
registers
User's extended control
registers
Field
FPRiOG
REASON FOR THE ABEND
Determine the immediate reason for the ABEND and
identify the failing module.
The ABEND message
DMSABN14ST contains an ABBND code and failing
address. "CMS ABEND Codes" in Section 3 lists
all the CMS ABBND codes, identifies the module
that caused the module to abnormally terminate,
and describes the action that should be taken
whenever CMS abnormally terminates.
•
GPRLOG
X'lS0'
ECRLOG
X 'lCO'
Device.
The name of the device causing the last I/O
interrupt is in the DEVICE field at X'26C'.
•
Last Two Commands or Procedures Executed.
You may have to examine several fields in the
nucleus constant area (NUCON) of low storage.
1.
2.
Examine the program old PSW (PGMOPSW) at
location X'2S'. Using the PSW and current
CMS
load map,
determine the
failing
address.
Examine the SVC
location X'20'.
old
PSW
(SVCOPS~
at
£g~!~J!!2
PRBVCMND
X'2AS'
LASTEXBC
X'2BO'
PREVEXEC
X'2BS'
Last CMS command
issued
Next to last CMS
command issued
Last EXEC procedure
invoked
Next to last EXEC
procedure invoked
Section 1. Introduction
41
DMSNUC
USERSECT
SUBSECT
OPSECT
SYSREF
DMSABW
CMSCB
DMSFRT
DMSERT
DBGSECT (Debug work areal
fields are filled in
FVS
DCB
DIOSECT
DECB
SVCSECT
PGMSECT
IOSECT
EXTSECT
AFTSECT (Create when the file is
opened. There is room for 5 AFTs in
DMSNUC, others are in free storage.
ADTSECT (Space is allocated when
DMSNUC is assembled, fields are
filled in when ACCESS command is
issued. There is one ADT entry for
each of the 10 possible disks.)
DEVTAB
BB
NUCON
Figure 13.
•
CMS Control Blocks
Last Module Loaded Into
Transient Area.
Pree
storage
and
The name of the last module loaded into free
storage via a LOADMOD
is in the field
LASTLMOD (location X'2CO'). The name of the
last module loaded into the transient area
via a LOADMOD is in the field LASTTMOD
(location X'2C8').
a simulated job file control block (JPCB), a
simulated data event block (DEB), and the
first in a chain of I/O blocks (lOBs).
•
The Last Command.
The last command entered from the terminal is
stored in an area called CMIDLIRE (X'7AOI),
and its corresponding PLIST is stored at
CMRDLIST (X'848 1 ) •
• Pointer to CMSCB.
•
The pointer to the CMSCB is in the PCBTAB
field located at XI 5CO'. CMSCB contains the
simulated as control blocks. These simulated
os control blocks are in free storage. The
CMSCB contains a PLIST for CMS I/O functions,
42
External Interrupt Work Area.
EXTSECT
(X'1550') is a work area for
external interrupt handler. It contains:
IBM VM/370: system Logic and Problem Determination Guide
the
The PSW, EXTPSW (X'lSFS')
Register save areas, EXSAVE1 (X'15BS')
separate area for timer interrupts,
EXSA VE (X '1550')
•
NUCLEUS LOAD MAP
I/O Interrupt Work Area.
IOSECT (X'1620') is a work area for the I/O
interrupt handler. The oldest and newest PSW
and CSW are saved.
Also, there is a register
save area.
•
Each time the CMS resident nucleus is loaded on
a DASD, and an IPL can be performed on that
DASD, a load map is produced. Save this load
map.
It lists the virtual storage locations of
nucleus-resident
routines and
work
areas.
Transient modules are not inclUded in this load
map.
When
debugging CMS, you
can locate
routines using this map.
The load map may be saved as a disk file and
at any time. A copy of the nucleus load
map 1S contained on the system with the file
identification of 'filename NUCMAP'. Issue the
prin~ed
Program Check Interrupt Work Area.
PGMSECT
(X'16BO') is a work area for the
program check interrupt handler. The old PSW
and the address of register
13 save area are
stored in PGMSECT.
LISTF
*
NUCMAPS
command to determine the filename.
•
Then issue
SVC Work Area.
PRINT filename NUCMAP
SVCSECT (X'174S') is a work area for the
interrupt handler.
It also contains
first four register save areas assigned.
SFLAG
(X'175S') indicates the mode of
called
routine.
The values
have
following meanings:
f!2.9
X'80'
X'40'
X'20'
X' 0 l'
SVC
the
The
the
the
to obtain
map.
SVC protect key is zero
Transient area routine
Nucleus routine
Invalid re-entry flag
current nucleus
load
Figure 14 shows a sample CMS load map.
Notice that the debug work area
(DBGSECT) and
the DMSINM module have been located.
LOAD MAP
is located
• Simulated CVT (Com.unications Vector Table).
The CVT, as supported by
(X'lCCS'). Only the fields
are filled in.
CMS, is CVTSECT
supported by CMS
The load map of a disk-resident command module
contains the location of control sections and
entry points loaded into storage. It may also
contain certain messages and card images of any
invalid cards or it may replace cards that exist
in the loaded files.
The load map is contained
in the third record of the MODULE file.
This load map is useful in debugging. When
using the
debug environment to
analyze a
program, use the program's load map to help in
displaying information.
There are two ways to get a load map:
• Active Device Table and Active File Table.
For file system problems, examine the ADT
(Active Device Table), or AFT (Active File
Table) in NUCON.
1.
When loading relocatable object code into
storage, make sure that the MAP option is
in effect when the LOAD command is issued.
Because MAP is the default option, be sure
that NOMAP is not specified.
A load map is
then created on the primary disk each time
a LOAD com.and is issued.
2.
When generating the absolute image form of
files already loaded into storage, make
sure that the MAP option is in effect when
the GENMOD command is issued.
Because MAP
is the default option, be sure that NOMAP
is not specified. Issue the MODMAP command
to type the load map associated with the
specified MODULE file on the terminal. The
format of the MODMAP command is:
REGISTEEt USAGE
To trace control blccks and
important to
know the CMS
conventions.
modules, it is
register usage
!!~gi§!5E! Contents
GR14
GR15
of the
!!5E§£Iil!:!:i2!l
Also, the SVC ABEND code, SVCAB,
at X'175A'.
GRl
GR12
GR13
a copy
Address-of the PLIST
Program's entry point
Address of a 12-doubleword
work area for an SVC call
Return address
Progra. entry point or
the return code
The preceding infor.ation should help you to
read a eMS dump. with a dump, the control block
diagra.s, and a CMS load .ap you should be able
to find the cause of the ABEND.
r-----------------------------------------,
I filename
I
I MODmap
I -_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ._J
!!!5EI5E:
filename
is the module whose map is to be
displayed. The filetype must be
MODULE.
Section 1. Introduction
43
FILE: lOAD
CMSMAP
INVALID CARD ••• :READ
*
*
*
*000000
DMSNUC
AT
D8SNUCU AT 002800
AT 000000
NUCON
SYSREF
AT 000600
AT 000274
PEIBM
CMNDlINE AT 0007AO
SOBFlAG AT 0005E9
IADT
AT 000644
DEVICE
AT 00026C
AT 000C90
DEVTAB
CONSOLE AT 000C90
ADISK
AT OOOCAO
DDISK
AT OOOCDO
SDISK
AT 000D10
YDISK
AT 000D20
TABEND
AT OOODFO
ADTSECT AT OOODFO
AFTSTART AT 001200
EXTSECT AT 001500
EXTPSW
AT 0015A8
AT 0015DO
IOSECT
IONTABl AT 001610
PGMSECT AT 001660
AT 001668
PIE
SVCSECT AT 0016F8
DIOSECT AT 001998
FVS
AT 001A88
ADTFVS
AT 001B48
KXFlAG
AT 001C2F
UFDBUSY AT 001C2E
CMSCVT
AT 001C80
DBGSECT....... AT 001D£HJ
DMSERT
AT 002098
DMSPRT
AT 002208
DMSABW
AT 002258
OPSECT
AT 002800
DMSERl
AT 002935
TSOBlKS AT 0029BO
SOBSECT AT 002A40
OSERSBCT AT 002AD8
INVALID CARD ••• :READ
ABBREV
AT 003000
OSABRV
AT 0030DO
INVALID CARD ••• :READ
CMSTIMER AT 003200
AT 003200
GETClK
DMSINM ......... AT 003200
INVALID CARD ••• :READ
AT 003308
TAPEIO
DMSTIO
AT 003308
Figure 14.
44
CONVERSATIONAL MONITOR SYSTEM
C
DMSNOC
OPlIB
CMSlIB
OSMACRO
DMSNOC
TEXT
MAClIB
MAClIB
MAClIB
ASSEMBLE
C1
D1
D1
Y2
C1
CMS191
CMS191
CMS191
CMS19E
SOURCE
9:01
9/21/72
9/21/72 8:47
9/21/72 8:44
7/19/72 18:11
9/18/72 23:09
DMSINA
TEXT
C1 C8S191
9/19/72
15:37
DMSINM
TEXT
C1 CMS191
9/18/72
20:36
DMSTIO
TEXT
C1 CMS191
9/19/72
10:33
Sample eM S Load Map
IBM VM/370: System Logic and Problem Determination Guide
a segment table that references a set
and swap tables that describe CP's
storage space.
of page
virtual
The VM/370 Control Program
(CP)
manages the
resources of a System/370 to provide virtual
storage support by using virtual machines. with
this support each terminal user appears to have
the complete function of a dedicated System/370
at his disposal r even though many other users
may
be
running
batch r
teleprocessing r
time-sharing r testing r or production jobs at the
same time.
The virtual space is divided into 2 parts;
the first part (4 segments (256K»
is reserved
for executable CP code,
both resident and
pageable; the second part (the remaining storage
of at least 256K) is dynamically allocated for
spooling
buffers
and for
user
directory
functions.
For a routine to be pageable, a
number of restrictions must be observed.
A user defines the configuration he requires
input/output
(I/O) device addresses r and a
storage size
up to
16 million
bytes
regardless of whether they
match the real
machine's configuration.
virtual devices must
have real counterparts r but not always in a
one-for-one ratio. For example r many users'
readers r punches r and printers can be mapped
onto common spool disks r and their virtual disk
devices may
be mapped
as minidisks
onto
different
sections of
common disk
packsr
effectively multiplying the number of logical
disk devices that are available on the real
machine.
When the system is loaded, resolved, and
written onto
the system
residence volume,
pagable modules must be loaded at addresses
higher in main storage than the symbol DftKCPEND,
which defines the last byte of the resident CP
nucleus.
This
is done by
reordering the
LOAD-LIST EXEC that the VftFLOAD procedure uses
when punching out the text decks that comprise
the Any pageable modules are listed after the
entry for DftKCPE.
In addition, the set page
boundary (SPB) loader control card must precede
each pageable module. This SPB card forces the
loader to start loading the succeeding module at
the next higher 4k page boundary and ensures
that the entire module is resident when it is
paged in.
Each user's virtual machine comprises:
•
An operator's console (his
terminal device)
local or
remote
•
A virtual CPU either
storage addressing.
•
Virtual storage of up to 16 million bytes
•
Virtual I/O devices
with or without virtual
!!.Q'!~:
If an operating
system that manages
virtual storage is running
in the virtual
machine r the CPU must have extended control (EC)
mode.
virtual I/O devices are controlled by the
virtual machine's operating system r not by CPo
Thus r for proper operation, the support for the
correct number and type of I/O devices must be
provided by the operating system of the virtual
machine. CP moriitors, translates r and schedules
all real I/C operations
to provide system
integrity.
It executes all virtual machine
operations in a problem state by trapping r
screening r and processing all the interrupts,
and passing on the necessary information to the
appropriate virtual machine. Only CP executes
in the privileged state.
To increase the amount of real main storage
available to the user's virtual machine r parts
of CP that are
infrequently used are not
resident in main storage.
Instead r they reside
on part of the auxiliary paging storage used by
the system r and are brought into main storage
only when they are required.
Because CP nonresident modules are paged into
main storage, CP also occupies virtual storage
space. The system VftBLOK, assembled into the
resident control program in the module DftKSYS r
defines this space. The VftBLOK has a pointer to
If several pageable modules perform similar
or related functions and if they are likely to
be resident at the same time, they may be
included in the same page by omitting the SPB
cards that would normally have preceded the
second and subsequent modules.
The group of
modules to be loaded together must not exceed 4K
as their total storage requirement; if they do,
one or more must be loaded in separate pages,
because no page boundary
crossover in the
pageable part of the control program is allowed.
All currently pageable CP modules punch their
own SPB card via an assembler PUNCH statement,
except those that are designed to reside in a
page along with other modules.
CP INITIALIZATION
System initialization (IPL)
prepares Vft/370 for
operation. IPL performs the following tasks:
•
Initializes main storage
•
ftounts devices
•
Reads spool file checkpoint records, on a
warm start from the warm start cylinder;
reads spool file checkpoint records on a
checkpoint
or
force
start,
from
the
checkpoint cylinders.
•
Allocates space for the system dump file
•
Logs on the system operator
In the case of a system restart that follows
a failure, active files and the system log
message are written on the warm start cylinder
before the CP nucleus can be brought into main
storage. The user can now log on.
section 1. Introduction
45
VIRTUAL MACHINE MANAGEMENT
A virtual machine is created for a user when he
logs on VM/370, on the basis of information
stored in his directory entry. The entry for
each user identification includes a list of the
virtual I/O devices associated with his virtual
machine and the real device equivalents.
The
directory file
contains
additional
information about the virtual machine.
Included
are the VM/370 command privilege classes for the
user, accounting
data, normal
and maximum
virtual storage sizes, and optional virtual
machine characteristics such as extended control
mode.
CP supervises virtual machine execution by
(1)
permitting only problem state execution
except in its own routines, and
(2) receiving
control after all interruptions occur on the
real system.
CP intercepts each privileged
instruction and simulates it if the current PSi
of the issuing virtual machine indicates a
virtual supervisor
state.
If
the virtual
machine is running in the problem state, an
attempt to execute a privileged instruction is
reflected back to the virtual machine as a
program interruption.
All virtual
machine
interruptions
(including
those
caused
by
attempting privileged instructions)
are first
handled by CP, and are reflected to the virtual
machine if an equivalent interruption would have
occured on the real machine.
The real CPU uses time-slicing to simulate
mUltiple
virtual
CPUs.
Virtual
machines
executing in a conversational mode are given
access to the real CPU more frequently than
those
that are
not; these
conversational
machines are
assigned the smaller
of two
possible time slices.
CP determines execution
characteristics of a virtual machine at the end
of each time slice on the basis of the recent
frequency of its console requests or terminal
interruptions.
The virtual machine is queued
for subsequent CPU usage according to whether it
is a conversational or nonconversational user of
system resources.
A virtual machine can gain control of the CPU
only if it is not waiting for some activity or
resource. The virtual machine itself may enter a
virtual wait state after an I/O operation has
begun. The virtual machine cannot gain control
of the real CPU if it is waiting for a page of
storage, an I/O operation to be translated and
started, or a CP command to finish execution.
A virtual machine can be assigned a priority
of execution. Priority is a parameter affecting
the execution privilege of a particular virtual
machine in comparison to other virtual machines
that
have
the
same
general
execution
characteristics.
priority may be assigned by
the
real machine
operator,
but is
more
frequently determined by the virtual machine's
directory entry.
46
The normal and maximum storage sizes of a
virtual machine are defined in the virtual
machine configuration in the VM/370 directory.
The virtual storage size can be temporarily
redefined to any value that is a multiple of 4K
and not greater than the value stated as the
maximum allowable in the directory. VM/370 uses
this storage as virtual storage. The storage
can appear as paged or nonpaged to the virtual
machine, depending upon whether the extended
control (EC) mode option was specified for that
virtual machine.
EC mode is
required if
operating systems that control virtual storage,
such as OS/VS1 or VM/370, are to be run in the
virtual machine.
storage in the virtual machine is logically
divided into 4096 byte areas called pages. A
complete set of segment and page tables describe
the storage of each virtual machine.
These
tables are maintained by CP and reflect the
allocation of virtual storage pages to blocks of
real storage. The System/370 machine uses these
tables to address virtual storage.
Storage in
the real machine is logically and physically
divided into 4096 byte areas called page frames
or blocks.
Only referenced virtual storage pages are
kept in real storage and, therefore, use real
storage more efficiently. A page can be brought
into any available page frame; the necessary
relocation is done during program execution by a
combination of VM/370 software and the dynamic
address translation hardware of the System/370.
The active pages from all logged-on virtual
machines and from the pageable routines of CP
compete for available page frames. ihen the
number of page frames available for allocation
falls below a threshold value, CP determines
which virtual storage pages currently allocated
to real storage are relatively inactive and
starts suitable operations to write them out on
a paging device (paging out).
Inactive pages are maintained on a direct
access storage device. If an inactive page has
been changed at some time during virtual machine
execution, CP assigns it to a paging device,
selecting the fastest such device with available
space. If the page has not changed, it remains
allocated in its original direct access location
and is written into real storage from there the
next time the virtual machine references that
page.
A virtual machine program can use the
DIAGNOSE instruction to inform CP that the
information from specific
pages of virtual
storage is no longer needed. CP then releases
the areas of the paging devices that had been
assigned to hold the specified pages.
Paging is done on demand by CPo
This means
that a page of virtual storage is not read from
the paging device and written to a real storage
block until it is needed for virtual machine
execution.
No
attempt is made by
CP to
anticipate what pages might be required by a
virtual machine.
While a paging operation is
being performed for one virtual machine, another
virtual machine can be executing. Any paging
operation started by CP is transparent to the
virtual machine.
IBM VM/370: System Logic and Problem Determination Guide
If the virtual machine is executing in EC
mode with translate on, two additional sets of
segment and page tables are maintained.
The
virtual machine operating systea is responsible
for the equivalency of the virtual storage
created by it to the virtual storage of the
virtual machine. CP uses this set of tables in
conjunction with the page and segment tables
created for the virtual machine at logon time to
build shadow
page tables for
the virtual
machine. These shadow tables map the virtual
storage created by the virtual aachine operating
system to the storage of the real computing
system.
The tables created by the virtual
machine operating system may describe any page
and segment
size permissible
in the
IBM
System/370.
The system operator can assign the reserved
page frames option to a single virtual machine
This option, specified by
the SET RESERVE
command, assigns a specific
amount of the
storage of the real machine to the virtual
machine.
CP
dynamically builds a
set of
reserved real storage page frames for this
virtual machine during its execution until the
maximum number "reserved" has been reached.
Because other virtual machines'
pages are not
allocated from this reserved set, the most
active pages of the selected virtual machine
remain in real storage.
During the process of CP system generation,
the installation may specify that a single
virtual machine is to be given an option called
virtual=real.
With this option, the virtual
machine's storage is allocated directly from
real storage at the time CP is initially loaded,
and remains allocated until released by an
operator command.
All pages except page zero
are allocated to the corresponding real storage
locations.
To
control the
real computing
system, real page zero must be controlled by
CPo Consequently, the real storage size must be
large enough to accommodate the CP nucleus, the
entire virtual=real virtual Ilachine, and the
rema1n1ng pageable storage requirements of CP
and the other virtual machines.
The virtual=real option improves performance
in the selected virtual machine because it
removes the need for CP to perform paging
operations for the selected virtual machine.
The virtual=real option is necessary whenever
programs that
contain dynamically
modified
channel programs
(excepting those of OS ISAM)
are to execute under control of CPo
A real disk device can be shared among multiple
virtual machines.
virtual device sharing is
specified in the directory entry or by a user
command.
If sharing is requested by a user
command,
an appropriate
password must
be
supplied before gaining access to the virtual
device.
A particular virtual machine can be
assigned read-only or read/write access to a
shared disk device. CP verifies each virtual
machine I/O operation against the parameters in
the virtual machine configuration to ensure
device integrity.
The virtual machine
operating systea is
responsible for the operation of all virtual
devices associated
with it.
These virtual
devices may be defined in the directory entry of
the virtual machine, or they may be attached to
(or
detached from)
the virtual
machine's
configuration while
it remains
logged on.
virtual devices aay be dedicated, as when mapped
to a fully equivalent real device; shared, as
when mapped to a ainidisk or when specified as a
shared virtual device; or spooled by CP to
interaediate direct access storage.
In a real machine running under control of
OS, I/O operations are normally initiated when a
problem program requests OS to issue a START I/O
instruction to a specific device. Device error
recovery is handled by the operating systea. In
a virtual machine, OS can perform these same
functions~ but the device
address specified and
the storage
locations referenced
are both
virtual.
It is the responsibility of CP to
translate the virtual specifications to real.
In addition, the interruptions caused by the
I/O operation are reflected to the virtual
machine for its interpretation and processing.
If I/O errors occur, CP records them but does
not initiate error recovery operations. These
are the responsibility of the virtual machine
operating system.
I/O operations started by CP for its own
purposes
(paging and spooling), are performed
directly and are not subject to translation.
SPOOLING
A virtual unit record device, which is mapped
directly to a real unit record device, is
dedicated. The real device is then controlled
completely by ihe virtual machine's operating
system.
CP facilities allow multiple virtual machines
to share unit record devices.
Because virtual
machines controlled by
CMS ordinarily have
modest requirements for unit record I/O, such
device sharing is quite advantageous, and it is
the standard mode of system operation.
Spooling operations stop if the direct access
storage space assigned to spooling is eXhausted,
and the virtual unit record devices are in a not
ready status. The system operator can make
additional spooling space available by purging
existing spool files or by assigning additional
direct access storage space to the spooling
function.
specific files can be transferred from the
spooled card punch or printer of a virtual
machine to the card reader of the same or
another virtual machine.
Files transferred
between virtual unit record devices by the
spooling routines are not physically punched or
printed. With this method, files can be made
available to multiple virtual machines, or to
different
operating
systems
executing
at
different times in the same virtual machine.
section 1. Introduction
47
CP spooling includes many desirable options
for the virtual machine user and the real
machine
operator.
These
options
include
printing multiple copies of a single spool file,
backspacing any number of printer pages, and
defining spool classes
for scheduling real
output.
The Remote Spooling Communications Subsystem
(RSCS), a component of VM/370, provides support
for the automatic transfer
of spool files
generated by VM/370 virtual machines to remote
locations. It also supports the transmission of
files from remote locations to virtual users.
RSCS uses
VM/370 to:
•
•
the
CP
spooling
facilities
of
Gain access to files spooled to RSCS by
transmission to remote
VM/370 users for
locations.
Transfer
files,
received
locations, to the intended
machines.
This support
is fully
from
VM/370
described in
remote
virtual
the
!~~
!~L]lQ: B~£~ ~§~~~§ §~!g~.
such as assigning a set of reserved page frames
to a selected virtual machine.
PROGRAM STATES
When instructions in CP are being executed, the
real computer is in the supervisor state; at all
other times, when running virtual machines, it
is in the problem state. Therefore, privileged
instructions can
only be executed
by CPo
Programs running on a virtual computer can issue
privileged instructions; such an instruction
causes an interruption that is handled by CPo
CP examines the operating status of the virtual
machine PSW.
If the virtual machine indicates
that it is functioning in supervisor mode, then
the
privileged
instruction
is
simulated
according to its type.
If the virtual machine
is in
problem mode,
then the
privileged
interrupt is reflected to the virtual machine.
Only CP may operate in the supervisor state
on the real machine. All programs other than CP
operate in the problem
state on the real
machine.
All user
interruptions, including
those caused by attempted privileged operations,
are handled by CP, which then reflects to the
user program only those interruptions that the
user program would expect from a real machine.
A problem program executes
on the virtual
machine in a manner identical to its execution
on a real System/370 CPU, as long as it does not
violate the CP restrictions.
CONSOLE FUNCTIONS
The CP console functions allow the user to
control the virtual machine from the terminal,
much as an operator controls a real machine.
virtual machine execution can be stopped at any
time by the terminal's attention key; it can be
restarted by typing in
the appropriate CP
command. External, attention, and device ready
interruptions can be simulated on the virtual
machine.
Virtual
storage, virtual
machine
registers, the PSW and CSW can be inspected and
modified.
Extensive trace
facilities
are
provided for the virtual machine, as well as a
single-instruction mode.
Commands control the
spooling and disk sharing functions of CPo
Console functions are divided into privilege
classes.
The directory entry for each user
assigns one or more privilege classes.
The
classes are:
•
•
•
Primary system operator
system resource operator
System programmer
Spooling operator
Systems analyst
IBM field engineer or PSR
General user
Commands in the system analyst class can
inspect real storage lecations, but they cannot
make modifications to real storage. Commands in
the operator class
control real resources.
system operator commands
include all those
relating to virtual machine performance options,
48
PREFERRED VIRTUAL MACHINE
CP
supports four
special virtual
machine
operating environment functions. Each function
can be applied to one virtual machine at a
time.
Although each function could be applied
to
a
different virtual
machine,
optimum
performance
would not
be achieved.
Each
function is discussed separately following.
CP attempts to provide
up to a specified
percentage of CPU time to a particular virtual
machine, provided that the virtual machine is
functioning in a way that fully utilizes CPU
time.
At
regular time
intervals the
CP
dispatcher checks the CPU time used by the
particular virtual machine.
If the specified
percentage is exceeded, the machine becomes the
lowest priority user in the system. If the
percentage used is lower than that specified,
the
virtual machine
has highest
priority
execution for the remainder of the interval.
The percentage of CPU time assured is specified
in the privileged class command that invokes the
function.
CP can also assure that a designated user is
never dropped from the active (in queue) subset
by the scheduler. When the user is runnable, he
IBM VM/370: system Logic and Problem Determination Guide
is placed in the dispatchable list at his normal
priority.
CP uses chained lists of table entries for
available and pageable pages. Pages for users
are assigned from the available list which is
replenished from the pageable list.
Pages that are temporarily locked in real
storage are not available or pageable. Paging
proceeds using demand paging with a "reference
bit" algorithm to select the best page for
swapping. The reserved page frames option gives
a particular virtual machine an essentially
"private" set of pages. The pages are not
locked, that is, they can be swapped, but
usually only for the specified virtual machine.
The number of reserved pages for the virtual
machine are specified as a maximum.
The page
selection routine selects an available page for
a reserved user and marks that page reserved if
the maximum specified for the user has not been
reached. If an available, unreferenced reserved
page is encountered during page replenishment
for the reserved user, it is used whether or not
the maximum h~s been reached.
If the page
selection routine cannot locate an available
page for other users because they are all
reserved, the routine may steal the reserved
pages.
This feature requires that the CP nucleus be
reorganized to provide a "hole" in real storage
large enough to contain the entire storage area
of the
virtual machine.
For
the virtual
machine, each page from page one to the last
page (n) is in its true real storage location;
only page zero is
relocated.
The virtual
machine runs in relocate mode, but because the
virtual page address is the same as the real
page address, 'no CCi translation is required for
the virtual machine. Because no CCi translation
is performed, no check is made of the I/O data
addresses. The virtual machine must ensure that
no I/O data transfer is specified into page zero
or into any page not in the virtual machine's
domain.
There are several considerations for the
virtual=real option of preferred machine support
that affect overall system operation:
be a high
availability, high throughput
machine.
The virtual=real storage can be
released by the operator.
That storage is
then available for paging. Once virtual=real
storage space is released by the operator, a
VM/310 IPL is necessary to reallocate that
storage to that virtual=real machine.
•
The virtual machine with the virtual=real
option operates in the pre-allocated storage
area with normal CCi translation in effect
until the execution of the SET NOTRAIS ON
command. At that time, all subsequent I/O
operations are performed from the virtual
CCis in
the virtual=real
space without
translation.
In this
mode, the virtual
machine must not perform I/O operations into
page zero nor beyond its addressable limit.
Violation of this
requirement may cause
destruction of the VM/310 system and/or other
virtual machines.
•
If the
virtual=real machine
performs a
virtual. reset
or IPL,
the normal
CCi
translation is performed until the issuance
of the SET NOTRANS ON command. Only the
virtual=real virtual machine can issue the
command.
A message is issued if normal
translation mode is entered.
The virtual machine assist feature is available
with system/310 Models 135, 145, and 158 and as
an RPQ on the Syste./310 Model 168. It improves
the performance of VM/310. It intercepts and
handles interruptions caused by svcs, invalid
page conditions and the following privileged
instructions:
LRl
STCTL
RRB
ISK
SSK
IPK
STNSH
STOSM
SSM
LPSi
SPKA
(load real address)
(store control)
(reset reference bit)
(insert storage key)
(set storage key)
(insert PSi key)
(store then and system mask)
(store then or system mask)
(set system mask)
(load PSi)
(set PSi key from address)
Although virtual machine assist feature is
designed te improve the performance of VM/310,
the virtual machines that do not have virtual
machine assist feature available may see a
performance improvement because
the virtual
machines with virtual machine assist feature are
using less of the system resources leaving more
resources available for the other users.
•
The area of contiguous storage built for the
virtual=real machine must be large enough to
contain the entire addressing space of that
machine.
!!EIYA1
•
While allocated as such, the storage reserved
for the virtual=real machine can be used only
by a virtual machine with that option. It is
not available to other users for paging space
nor
for VM/310
usage,
even when
the
virtual=real machine is net logged on. For
this reason, the virtual=real machine should
-0-
~Afn!!~ £Q!IBQb: Real control register 6
(see Bote 1) and a MICBLOK control virtual
machine assist feature. The MICBLOK is a list
of pointers to areas within V8/310 control
blocks. The control register 6 format follows:
Bit
~~2!l!~19
1=virtual machine assist feature on for
this virtual machine
O=virtual
machine
assist
feature
disabled (VM/310 mode)
section 1. Introduction
49
-,Bit
~~!!!!!!!g
INTERACTION WITH PROGRAM
l=Virtual machine is in problem state
O=Virtual machine is in supervisor state
(see Note 2)
2
l=ISK and SSK not handled by virtual
machine assist feature
O=ISK and SSK handled by virtual machine
assist feature
3
1=360 operations and 370 non-DAT
operations only
0=370 DAT operations allowed
(see Note 3)
4
l=SVC interruptions
not handled
by
virtual machine assist feature
O=SVC interruptions handled by virtual
machine assist feature
5
l=Shadow table mode: Shadow page fixup
done by virtual machine assist feature
O=Shadow Table fixup not allowed
6
Reserved (must be zero)
7
Reserved (must be zero)
8-28
Real address of
list
29-31
Unused (must be zero)
Notes:
-l~--control register
6 is loaded before
virtual machine is dispatched.
Bit 1 of control register 6 may be changed
by virtual machine assist feature during a
virtual machine status change~
3.
Bit 3 affects instructions that only a
virtual machine with the EC option may
execute. Specifically, they are: LRA, RRB,
IPK,
STNSM, STOSM, and SPKA. Bit 3 also
affects STCTL
even though it
can be
executed by a virtual machine without the
EC option.
virtual machine assist feature uses the list
of pointers, or MICBLOK, to access virtual
machine control information. The list must start
on a doubleword boundary. A MICBLOK is obtained
for each user when he logs on. The entries in
this list are as follows:
•
Pointer to the real address of
PSi currently in effect.
•
Pointer to
the 64 byte
workspace area
reserved for virtual machine assist feature.
50
!!:!fl ~Q~ ~~Y1!:!QB: On machines with
both virtual machine assist feature and the DOS
Emulation feature installed, local execution
(LEX)
mode inactivates virtual machine assist
feature;
privileged instruction interruptions
and SVC interruptions occur according to DOS
emulation architecture. When the machine is not
in LEX mode, the machine performs as described
for virtual machine assist feature.
!!!:!~~!£:!!Q!!
~~§!~!£!~~
y~~
OF
VIRTUAL MACHINE
ASSIST
l~A:!Y~~: Certain Interruptions mu~t--be handled
by VM/370. Consequently, the virtual machine
assist feature is not on in a virtual machine if
the machine has instruction address stop set
on.
VM/370
turns
SVC
handling
off
when
instruction address stop is set on, and turns it
back on after the stop occurs.
V"/VS HANDSHAKING
Pointer to the
control register
address
Privileged
instruction
interruptions
resulting from the virtual instructions may show
a PER event for instruction fetching,
just as
they would without the
feature.
Real SVC
interruptions may be followed by a program
interruption for
an instruction
fetch PER
event.
length, page
•
real
For virtual SVC interruption, PER monitoring
specified in the current real PSW, current
virtual PSi, or new virtual PSW causes a real
SVC
interrupt,
regardless of
the
values
specified in real or virtual control registers
9,10, and 11.
For virtual LPSW, similar
conditions
result
in
a
real
privileged
instruction interruption.
each
2.
o.
(g~~):
machine assist
feature except SVC and LPSW, PER monitoring
events are
indicated normally
as if
the
instructions were being executed in supervisor
state. Changes made to the virtual PSW or swap
table entries
in VM/370 real
storage are
indicated as storage alteration events, because
those locations are considered to be internal
registers to the virtual machine. A virtual
instruction that attempts to change the state of
the virtual PSW PER mask causes a privileged
instruction interruption, and the instruction is
suppressed.
PER monitoring specified in the real PSW
causes the VM/370 page invalid interruption to
be inactive.
virtual machine pointer
Real segment table pointer and
size, and segment size.
~!l;!!:! R~£Q!Ul!!!§
i~~-~II--ris~~i~tI~i~-li virtual
of
virtual
the virtual
The
V"/VS Handshaking
feature provides
a
communication path between CP and a virtual
machine operating system (OS/VS1)
that makes
each system control program aware of certain
capabilities or requirements
of the other.
V"/VS
Handshaking
performs
the
following
functions:
•
Closes CP spool files when the vsl job output
from its DSO, terminator, and output writer
is complete
•
Processes VS1 pseudo page faults
IB" V"/370: System Logic and Problem Determination Guide
•
Provides an optional nonpaging .ode for VS1
when it is run in the VM/310 environment
When
a VS1
virtual
machine with
the
handshaking feature is loaded (via IPL), its
initialization routines determine whether the
handshaking feature should be enabled. First,
VS1 determines if it is running under the
control of VM/310 by issuing a STIDP
(store
Processor ID)
instruction.
STIDP returns a
version codei a version code of X'FF' indicates
VS1 is running with V"/310.
If VS1 finds a
version code of X'FF', it then issues a DIAGNOSE
(X' 00' )
instruction
to store
the
V"/310
extended-identification
code.
If
an
extended-identification code is returned to VS1,
VS1 knows that V"/310 supports handshakingi if
nothing is returned to VS1, VM/310 does not
support handshaking.
At this time or any time
after IPL, the operator of the VS1 virtual
machine can issue the CP SET PAGE X ON command to
enable the pseudo page fault handling portion of
handshaking. If the VS1 virtual machine is in
the nonpaging mode and, if the pseudo page fault
handling is active, full handshaking support is
available.
Because the VS1 system does no paging, any
ISAM programs run under VS 1 are treated by
though they are running
in an
V"/310 as
ADDRSPC=REAL partition.
Therefore, the ISA"
option is required for the VS1 machine to
successfully execute the ISAM program.
When a page fault occurs for a VS1 virtual
machine, VM/310 checks that the pseudo page
fault portion of handshaking is active and that
the VS1 virtual machine is in EC .ode and
enabled for I/O interruptions.
Then, VM/370
reflects the page fault to VS1 by:
•
Storing the virtual machine address that
caused the page fault at location X'90' (the
translation exception address)
•
Indicating a program
code X' 14') to VS 1
•
Removing the VS1 virtual
wait and execution wait
interruption (interrupt
.achine fro.
When VS1 recognizes program interruption code
X'14', it places the associated task in wait
state. VS1 can then dispatch other tasks.
When the requested page becomes available in
real storage, VM/370 indicates the same progra.
interruption to VS1, except the high order bit
in the translation exception address field is
set on to indicate completion. VS1 removes the
task from page wait; the task is then eligible
to be dispatched.
When Vs1 runs under the control of
executes in nonpaging mode if:
If the handshaking feature is active, VS1 closes
the CP spool files when its job output from the
DSO, terminator, and output writer is complete.
Once the
spool files
are closed,
VM/310
processes them and they are sent to the real
printer or punch. During its job termination
processing, VSl
issues a
DIAGNOSE
(X'08')
instruction to pass the CP CLOSE command to
VM/310 for each CP spool file.
page
VM/370, it
•
Its virtual storage size is equal to the size
of the VM/370 virtual machine
•
Its virtual machine size is at least one
megabyte and no more than four megabytes.
•
The V"/VS Handshaking feature is available.
When VS1 executes in nonpaging mode, it uses
fewer
privileged
instructions
and
avoids
duplicate
paging.
The
VS1
Nucleus
Initialization progra. (NIP) fixes all VS1 pages
to avoid the duplicate paging.
!Qt~:
A page fault is a program interruption that
occurs when a page marked "not in storage" is
referred to by an instruction with an active
page. The virtual machine referring to the page
is placed in a wait state while the page is
brought
into
real storage.
Without
the
handshaking feature, the entire VSl virtual
machine is placed in page wait by VM/310 until
the needed page is available.
However,
with the handshaking feature, a
multiprogramming (or multitasking) VS1 virtual
machine can dispatch one task while waiting for
a page request to be answered for another task.
V"/370 passes a pseudo page fault
(program
interrupt X'14') to VS1.
When VS1 recognizes
the pseudo page fault, it places only the task
waiting for the page in page wait and can
dispatch another tasks.
The working set size may be larger for a
VS1 virtual machine in nonpaging mode than for
one in paging mode.
A VS1 virtual machine with the handshaking
feature avoids many of the instructions or
procedures that would duplicate the function
that V"/370 provides. For example, VS1 avoids:
•
15K (Insert storage Key)
uses a key table
•
Seek separation
devices
•
ENABLE/DISABLE sequences
Supervisor (IDS)
for
instructions
2314
in
direct
the
and
access
VS1
section 1. Introduction
I/O
51
•
TCn (Test Channel) instructions preceding SIO
(start I/O) instructions.
CP INTERRUPTION HANDLING
Interruption processing occurs within the CP
environment.
More than 30 modules control the
process of interrupting events brought about by
CP or virtual machine activity. Each module
handles a particular I/O device or class or a
function of CP, (for exaaple: tiaers, paging,
SVCs).
For
an overview
of
interruption
handling, see Figure 15.
I/O interruptions from completed I/O operations
initiate various completion routines and the
scheduling of further I/O requests. The I/O
interruption handling
routine also
gathers
device sense information.
When a
machine check occurs,
CP Recovery
Management Support
(RHS) gains control to save
data associated
with the
failure for
FE
maintenance.
RHS analyzes
the failure and
determines the extent of damage.
Damage assessment results
following actions being taken:
Program interruptions occur in t~o states. If
the CPU
is in the supervisor
state, the
interruption indicates a systea failure in the
CP nucleus
and causes
a system
abnormal
termination.
If the CPU is in the problem
state, a virtual machine is in execution. If
the program interruption indicates that the
Dynamic Address Translation (DAT) feature has an
exception, a virtual machine issued a privileged
instruction, or a protection exception occurred
for a shared segment system, CP takes control
and performs any required processing to satisfy
the exception.
Usually, the interruption is
transparent to the virtual machine. Most other
program
interruptions result
from
virtual
machine processing and are reflected to the
virtual machine for handling.
52
in
one
of
the
with
no
•
system termination
•
selective virtual user termination
•
Refreshing of damaged information
effect on system configuration
•
Refreshing of damaged information with the
defective storage page removed from further
system use
•
Error recording only for certain soft machine
checks
The system operator is
informed of all
actions taken by the RMS routines.
When a
machine check occurs
during VM/370 startup
(before the system is set up well enough to
permit RMS to operate successfully), the CPU
goes into a disabled wait state and places a
completion code of X'OOB'
in the high-order
bytes of the current PSi.
IBM VM/370: System Logic and Problem Determination Guide
The VM/370 Control Program (CP) is interrupt driven. Thus, when an interrupt occurs, control is passed to the appropriate Interrupt
Handler. These are:
•
•
From unknown channel, the interrupt is ignored
From an unsolicited Device End, bUild;a~n~IO~B:LO~K~~~~~~_'
C
and for: Console (Start/Stop) . . . .
and for 3270s on bisync lines
.C
DMKCNSIN
and for local 3270 devices, 3158 and 3066 cunsoles . .(
I
Unit Record (U/R), real spooling
•
From a dedicated device error, for either CP or a virtual machine
(DMKVCHI. the ERP for:
)
DASD
•
DMKDASER)
Tape
--C
DMKTAPER
)
From 3270 bisync line and channel errors",( DMKBSC)
Recoverable error? No, record error . . . .
DMKIOERR)
C DMKRSPEX)
From a solicited Device End
•
From a Channel ERROR, the Channel Check Handler.C DMKCCHNT)
DMKSTKIO)
--C
C
DMKGRF )
•
C
Monitor Tape I/O Operation
----------------~
DMKRGA or )
_.___D_M....,;.;K;.;.,R;..,;G;;.;B:::..-__
t
•
•
to stack 10BLOK
Yes.,
For Program Check interrupts, the Program Check Interrupt Handler • • • • • • •_ _ _•
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _. .~
'-------
DMKPRGIN passes control to the appropriate processor, depending on the type of program check, as follows:
.....c
DMK~TRAN )
•
For normal paging
•
For paging (virtual.....r DMKVAT )
machine in EC moder--- \.
.
•
For Supervisor state
•
~
For privileged instructions _ ._ _ _ _•
Figure
15.
DMKVIOEX passes control as follows:
DMKPRVLG passes control as follows:
instructions~
•
For DIAGI\JOSE
•
Fortimers~
•
For virtual machine I/O _ _ _ _ _ _ _111
•
Forconsole·G~
•
For Unit Record (U/R), virtual
.~
spooling
Overview of Interruption Handling
When an
SVC interruption occurs,
the SVC
interruption routine is entered. If the machine
is in problem state, the type of interruption is
usually reflected back to the pseudo-supervisor
(that is, the supervisor operating in the user's
virtual machine).
If the
machine is
in
supervisor state, the SVC interruption code is
determined, and a branch
is taken to the
appropriate SVC interruption handler.
event has occurred, such as the time of day, a
scheduled shutdown, or a reached user event.
The CPO timer indicates that a virtual machine's
allowed execution interval (time in queue) has
expired.
The external console interruption invokes cp
processing to switch from the primary console to
an alternate operator's console.
FREE STORAGE MANAGEMENT
If a timer interruption occurs, CP processes it
according to type. The interval timer indicates
time-slice end for the running user. The clock
comparator indicates that a specified timer
During its execution, CP occasionally requires
small blocks of storage that are used for the
duration of a task. CP obtains this storage
from the free storage area. The free storage
area is divided into various size subpools. The
requestor informs the free storage manager of
the size of the block required and the smallest
available subpool that fulfills the request is
allocated to the requestor. When the block is
Section 1. Introduction
53
no longer needed, the requestor informs the free
storage manager and CP returns the block to free
storage.
3.
Checks for a fetch protection violation on
a write CCW (except for spooling or console
devices) •
If the request for free storage cannot be
fulfilled, the free storage manager requests the
temporary use of a page of storage from the
dynamic paging area. If a page is obtained, the
page is chained to the free storage area and
used for that purpose until it is no longer
needed and subsequently returned to the dynamic
paging area.
A special case of storage protection occurs
when the CMS nucleus
resides in a shared
segment.
The nucleus must be protected and
still be shared by many CMS users. The program
interruption handler, DMKPRG, manipulates the
real storage key and real PSW key to ensure that
user programs and disk-resident commands run
with a different key than the nucleus code.
If the
request for
a page
fulfilled,
the
requestor waits
storage becomes available.
EXECUTING THE PAGEABLE CONTROL PROGRAM
cannot be
until free
STORAGE PROTECTION
VM/370 provides both fetch and store protection
for real storage. The contents of real storage
are protected from destruction or misuse caused
by erroneous or unauthorized storing of fetching
by the program.
Storage is protected from
improper storing or from both improper storing
and fetching, but not from improper fetching
alone.
When the CPU accesses storage, and protection
applies, the protection key of the current PSW
is used as the comparand. The protection key of
the CPU is bit positions 8-11 of the PSW.
If the CPU access is prohibited because of a
protection
violation,
the
operation
is
suppressed
or
terminated, and
a
program
interruption for a protection exception takes
place.
When the reference is made to a channel, and
protection
applies,
the
protection
key
associated with the I/O operation is used as the
comparand.
The protection key
for an I/O
operation is in bit positions 0-3 of the CAW and
is recorded in bit positions 0-3 of the CSW
stored as a result of an I/O operation.
If
channel access is prohibited, the CSW stored as
a
result
of the
operation
indicates
a
protection-check condition.
When a storage access is prohibited because
of a store protection violation, the contents of
the protected location remain unchanged.
If a
fetch protection violation occurs, the protected
information is not loaded into an addressable
register, moved to another storage location, or
provided to an I/O device.
To use fetch protection, a virtual machine
must
execute the
set
storage key
(SSK)
instruction referring to the data areas to be
protected, with the fetch protect bit in the
key. VM/370 subsequently:
1.
Checks for a fetch protection violation
when handling privileged and nonprivileged
instructions.
2.
Saves and restores the fetch protection bit
(in the virtual storage key)
when writing
and recovering virtual machine pages from
the paging device.
54
Calls to pageable routines are recognized at
execution time by the svc 8 linkage manager in
DMKPSA. For every SVC 8, the called address (in
the caller's GPR15) is tested to see if it is
within the resident nucleus. If it is less than
DMKCPEND and greater than DMKSLC, the called
routine's base address is placed in GPR12 and
control is passed to the called routine in the
normal way.
However, if the called address is
above DMKCPEND or below DMKSLC, the linkage
manager issues a TRANS macro, requesting the
pagin~
manager to locate and, if necessary,
page-~n the called routine.
The TRANS is issued
with LOCK
option.
Thus,
the lock
count
associated with the called routine's real page
indicates the
responsibility count
of the
module.
•
When the module
incremented.
is called,
•
When the routine exits via
is decremented.
the
count
is
SVC 12, the count
When the count reaches zero, the pageable
routine is unlocked and is eligible to be paged
out of the system.
However, because all CP
pageable modules are reentrant,
the page is
never swapped out, but when the page is stolen,
it is placed directly on the free page list.
Because
unlocked
page able
routines
participate in the paging process in a manner
similar to user virtual storage pages, the least
recently
used approximation
used by
page
selection tends to make highly used control
program routines, even when not locked, remain
resident.
The called routine is locked into
real storage until it exits.
Thus, it can
request asynchronously scheduled function, such
as I/O or timer interrupts, as long as it
dynamically establishes the interruption return
address for the requested operation and does not
give up control via an EXIT macro prior to
receiving the requested interruption.
Addressability for the module, while it is
executing, is
guaranteed because
the CALL
linkage loads the real address of the paged
module into GPR12
(the module base register)
prior to passing control.
If all addressing is
done in a base/displacement form, the fact that
the module is executing at an address different
from that at which it was loaded is transparent.
Although part of CP is pageable, it never runs
in relocate mode. Thus, the CPU is not degraded
IBM VM/370: system Logic and Problem Determination Guide
by the DAT feature being active, and no problems
occur because of handling disabled page faults.
•
The module cannot contain any A- or V-type
address constants that point to locations
within itself
or within
other pageable
modules, and it cannot contain any CCws that
contain data addresses within themselves.
The only exceptions are address constant
literals generated as the result of calls to
other modules (because these addresses are
dynamically relocated at execution time, they
must be resolved by the loader to the loaded
address of the called module) and a pageable
module that locks itself into storage.
In
,practice, this restriction means that data or
instructions within the pageable routine must
be
referenced
via
base/displacement
addressing, and the address in register 15
for a CALL may not be generated by a LOAD
ADDRESS instruction.
•
The pageable module must be no more than 4096
bytes in length.
SYSTEM SUPPORT MODULES
The system support modules provide CP with
several common functions for data conversion and
control block scanning and verification.
Most
of the routines are linked to via the BALR
option of the CALL macro, and make use use of
the BALRSAVE and TEMPSAVE workareas in DMKPSA.
Two exceptions are the virtual and real I/O
control
block scan
routines DMKSCNVU
and
DMKSCNRU. These routines do
not alter the
contents of the BALRSAVE area, and hence may be
called by another low level BALR routine.
CONTROL REGISTER USAGE
Every IBM System/370 CPU provides the program
with 16 lo~ical
control registers
(logical
registers s~nce the number that are active
depends on the features installed in the machine
at anyone time)
that are addressable for
loading and storing from basic control
(BC)
mode.
VM/370 provides only a single control
register, control register zero, for normal
virtual machines, and for processing systems
that do not require the full set of registers
(for example, CMS, DOS, or other operating
systems for system/360.
Any user whose virtual machine operating
system requires the use of control registers
other than control register zero, can request
the full set of 16 registers by specifying the
ECMODE option in the VM/370 directory entry for
his virtual machine.
A
virtual machine,
which utilizes
any
system/370
features that
use the
control
registers, requires the ECMODE option. Some of
these features are expanded timer support of the
System/370 CPU timer, clock comparator, etc.,
the virtual relocate mode and its instructions,
RRB, LRA, PTLB, virtual monitor calls, virtual
Program Event Recording (PER), etc.
RESTRICTIONS
MODULES
AND
CONVENTIONS FOR
PAGEABLE
CP
If
the four
above
design and
coding
restrictions are adhered to, the CP module can
be added to the
existing pageable nucleus
modules by
utilizing the
service routine,
VMFLOAD,
which
is
described
in
"VM/370
Maintenance Procedures" of the !~LJ1Q: ~~£y!£~
SgY!i~~~ R~~g~2! 199!f·
Additional information
can be found in the !~L1IQ: g!~~~!~g ~~g 212!~!
~~~~£2!!gD ~~!g~.
DATA AREA MODULES
In addition to the executable resident and
pageable modules, there are certain modules that
only contain data areas and do not contain
executable code. These modules are:
Resident
~ggYl~
DMKCPE
DMKRIO
DMKSYS
DMKTBL
Pageable
~ggYl~
DMKBOX
DMKEMS
UMKFCB
DMKSNT
DMKSYM
DMKUCB
DMKUCS
Pageable CP modules must observe the following
restrictions and conventions
when they are
designed and coded:
•
•
The module should be completely reenterable.
Any messages to be modified,
temporary work
or scratch areas, or program switches must be
allocated from system free storage or from
the caller's save area.
The module must be entered by the standard
SVC 8 CALL linkage.
Modules entered by BALR
or GOTO cannot be pageable.
contents
DefInes-the end of the CP nucleus
I/O device blocks
System constants
Terminal translate table
DMKTBM
Contents
output-separator table
Error message data module
3211 Forms Control Buffer
(FCB) load
tables
System name table
System symbol table
3211 Universal Character set Buffer
(UCSB) load tables
1403 Universal Character set
(UCS)
load tables
Terminal translate tables
SVC INTERRUPTIONS
SVC interruption occurs,
the SVC
When an
interrupticn routine (DMKPSASV) is entered.
If
the machine is in the problem state, DMKPSASV
takes the following action:
section 1. Introduction
55
EXECUTABLE MODULES
DMKBSC
DMKCCH
DMKCCW
DMKCFC
DMKCFM
DMKCNS
DMKCVT
DMKDAS
DMKDGD
DMKDMP
DMKDSP
DMKFBE
DMKGBF
DMKHVC
DKKHVD
DKKIOE
DMKIOS
DMKLOC
DMKKCH
DMKKSW
DMKOPB
DMKPAG
DMKPGT
DMKPBG"
DMKPRV
DMKPSA
DMKPTR
DMKQCN
DMKBGA
DMKRGB
DMKRGF
DMKRNH
DMKRPA
DMKBSP
DMKSCH
DMKSCN
DMKSTK
DMKTMB
DMKUNT
DMKVAT
DMKVCN
DMKVIO
DMKVMA
DMKVSP
DMKACO
DKKBLD
DMKCDB
DMKCDS
DMKCFD
DMKCFG
DMKCFP
DMKCFS
DMKCFT
DMKCKP
DMKCKS
DMKCPB
DMKCPI
DMKCPV
DMKCQG
DMKCQP
DMKCQR
DMKCSO
DKKCSP
DMKCST
DMKCSU
DMKDEF
DMKDIA
DMKDBD
DMKEIG
Df!KEf!A
DMKEMB
DMKEBM
DMKGIO
DMKIOC
DMKIOF
DMKIOG
DMKISK
DMKLNK
DMKLOG
DKKKCC
DKKKID
DKKMON
DKKKSG
DKKNEM
tMKNES
DMKNET
tKKNLD
DMKPGS
DMKRSE
DMKSAV
Df!KSEP
DMKSEV
DMKSIX
DMKSNC
DMKSPL
DKKTAP
DKKTDK
Df!KTHI
DMKTRA
DKKTBC
DKKTRM
DKKUDR
DKKUSO
DMKVCA
DMKVCH
DMKVDB
DMKVDR
DKKVDS
DMKVER
DMKVKI
DMKWRM
If the interruption was the result of an
ADSTOP (SVC code X'B3'), the message ADSTOP
AT XXXXX is sent to the user's terminal, the
overlaid instruction is replaced,
and the
virtual machine is placed in console function
mode (CP mode) via DKKCFKBK.
•
If the interruption was the result of an
error recording interface
(SVC 76),
DKKPSA
checks for
valid parameters
and passes
control to DKKVER to convert virtual device
addresses in the error record to real device
addresses.
The
actual
recording
is
accomplished in
DMKIOE and
DMKIOF.
If
recording is not possible, the interrupt is
reflected back to the virtual machine.
•
If the virtual machine was in EC mode or its
page 0 was not in real storage, then all
general and floating-point
registers are
saved, the user's VKBLOK is flagged as being
in an instruction wait,
and control is
transferred (via GOTO) to DMKPRGRF to reflect
the interruption to the virtual machine.
•
If the virtual machine was in BC mode and if
page 0 is in main storage, an aFpropriate SVC
old PSW is
stored in page 0
and the
interruption is reflected to the virtual
machine,
bypassing
unnecessary
register
saving.
If the new virtual PSi indicates the
wait state, all registers are saved in the
VKBLOK and control transfers to DMKDSPB for
PSi validation.
56
If the machine is in the supervisor state,
the SVC interruption code is determined and a
branch
is taken
to
the appropriate
SVC
interruption handler.
SVC 0
Impossible condition or terminal error.
The
SVCDIE routine initiates an abnormal termination
by using the DMKDMPDK routine.
SVC 4
Reserved for IBM use.
SVC 8
i-link request that transfers control from the
calling routine to the routine specified by
register 15~ The SVCLINK routine sets up a new
save area, and then saves the caller's base
register in register 12 and save area address in
register 13, and the return address
(from the
SVCOPSi) in the new save area.
If the called
routine is within the resident CP nucleus,
SVCLINK places its address in register 12 and
branches directly to the called routine.
If the
called routine is in a pageable module, a TRANS
macro is Ferformed for register 12 to ensure
that the page containing the called routine is
in storage.
Upon return
from the
TRANS
execution, the real address of the pageable
routine is placed in register 12 and SVCLINK
branches to the called
routine.
The real
storage location of DMKCPE is the end of the
resident CP nucleus.
Any modules loaded at a
IBM VK/370: System Logic and Problem Determination Guide
higher real storage
pageable modules.
address
are
defined
as
SVC 12
i-return request that transfers control from the
called routine to the calling routine) •
The
SVCRET routine is invoked.
If the routine that
issued the SVC 12 is in the pageable module
DMKPTRUL, then DMKPGSUL is called to unlock the
page. SVCRET then restores registers 12 and 13
(address ability and save area address saved by
SVCLINK), places the user's return address (also
saved in this area) back into the SVCOPSW, and
returns control to the
calling routine by
loading the SVCCPSW.
SVC 16
Releases current save area from the active chain
(removes
linkage pointers
to the
calling
routine).
The SVCRLSE routihe releases the
current save area by placing the address of the
next higher save area in register 13 and returns
control to the current routine by loading the
SVCOPSW.
This SVC is used by second level
interrupt handlers to bypass returning the first
level handler under specific circumstances. The
base address field
(register 12)
in the save
area being released is examined to determine if
the bypassed routine is in a pageable module.
If so, DMKPTRUL is called to unlock the page.
SVC 20
obtain a new save area.
The SVCGET routine
places the address of the next available save
area in register 13 and the address of the
previous save area in the save area pointer
field of the current save area.
There are 35 SAVEAREAs initially set up by
DMKCPINT for use by the SVC linkage handlers.
If all the save areas are used, the linkage
handlers call DMKFREE to obtain additional save
areas.
If DMKPSAEX is entered because of a timer
interruption, the state of the machine must be
determined~
If the machine was in wait state,
control is transferred to DMKDSPCB, and the
machine stays idle until another interruption
occu~s.
If the machine is in problem state, the
address of the current user's VMBLOK is obtained
from RUNUSER. The user's current PSW (VMPSW) is
updated from the external interruption old PSi,
the address of the current VMBLOK is placed in
register 11, and control is transferred to
DMKDSPCH.
For additional
information about
timers, see "Virtual Timer Maintenance."
If DMKPSAEX is entered because the operator
pressed
the
console
interrupt
button
(INTERRUPT), the following steps are taken:
The
current
system
operator's
(DMKSYSOP) is referenced.
The virtual machine is disconnected.
The operator can now log on from another
terminal.
pressing the console interrupt button
activates an alternate operator's console. For
a description of the processing of the external
interruption command, refer to module DMKCPB in
Section 2.
To reflect external interruptions to a virtual
machine, an XINTB~oK is queued on a chain
pointed to Df VMPXINT in the VMBLOK.
The
XINTBLOKs are
chained sequentially
by the
XINTSORT field that
contains the collating
number of the pending interruption. If more
than one interruption has the same collating
number, the interruption codes are ORed together
in the XINTCODE field for possible simultaneous
reflection.
When a
virtual machine is
enabled for
external interruptions, the XINTBLOK queue for
that machine is searched for an eligible block.
An XINTBLOK is eligible for reflection if one or
more bits of the XINTMASK field match the bits
in the low-order half word of control register O.
If the interruption was an interruption such as
CPU timer or clock comparator, the block is left
chained because reflection does not reset these
interruptions. If the reflected interruption(s)
does not represent all those coded in the
XINTMASK field, the block is left chained and
only the interruptions that were reflected are
reset. In all other conditions, the XINTBLOK is
unchained and returned to free storage.
PROGRAM INTERRUPTIONS
When a program interruption occurs, the program
interrupticn
handler
(DMKPRG)
is
entered.
Program interruptions can result from:
EXTERNAL INTERRUPTIONS
•
•
VMBLOK
•
Normal paging requests.
•
A paging request by a virtual machine
mode (virtual relocate mode).
•
Privileged instructions.
•
Program errors.
in Ee
For information paging requests, see "Allocation
Management" in this section.
If a program interruption is caused by the
virtual machine issuing a privileged instruction
when it is running in supervisor state, DMKPRVLG
obtains
the
address
of
the
privileged
instruction and determines the type of operation
requested. If the virtual machine was running
in problem state, the interruption is reflected
back to the virtual machine.
Section 1. Introduction
57
lLQ
E~lYl~~Q~£
control to the
(DMKVIOEX) •
!Q~=lLQ
INSTRUCTIONS DMKPRVLG transfers
-virtual--i;o
executive program
E~!Y!1EQE]
INSTRUCTIONS
DMKPRVLG
simulates valid non-I/O -prIvIleged-instructions
and returns control to DMKDSPCH.
For invalid
non-I/O privileged instructions, the routine
sets an invalid interruption code and reflects
the interruption to the virtual machine.
For
the privileged instructions (SCK, SCKC, STCKC,
SPT, and STPT that affect the TOO clock, CPU
timer, and TeD clock comparator, control is
transferred to
DMKTMR by
DMKPRVLG.
Other
instructions that are simulated are LPSW, SSM,
SSK, 1SK, and DIAGNOSE.
Although the CS and CDS instructions are
non-privileged, they
are not part
of the
standard instruction set
on IBM System/370
Models 135 and 145.
VM/370 simulates these
instructions on Models 135 and 145 that do not
have the optional hardware feature installed.
0000
Code
Class Function
iny-store---
0004
0008
OOOC
0010
0014
0018
001C
C,E
G
G
G
G
G
F
0020
G
0024
0028
002C
0030
0034
0038
003C
G
G
C,E,F
C,E,F
C,E
C,E
A,B,C
004C
Any
0050
System/370
EC
mode
non-I/O
privileged~
instruction simulation includes the following: ~ 0054
~0058
Definition
fQ!!~
SCK
SCKC
STCKC
SPT
STPT
STNSM
STOSM
STIDP
STIDC
LCTL
STCTL
LRA
RRB
PTLB
IPK
SPKA
-set-Clock
set Clock Comparator
store Clock Comparator
set CPU Timer
Store CPU Timer
store And AND System Mask
Store And OR system Mask
Store CPU Identification
Store Channel Identification
Load Control
store Control
Load Real Address
Reset Reference Bit
Purge Table Look-aside Buffer
Insert PSW Key
Set PSW Key From Address
A,B,C
G
005C
0060
G
G
G
0064
G
extended-identification
code.
Examine data from real storage
Execute CP console function
Pseudo-timer facility
Release virtual storage pages
Manipulate input spool files
standard DASD I/O
Clear
I/O
and
machine
chE!ck
recording
General
virtual
I/O
without
interrupts
Virtual device type information
Dynamic TIC modification
Return DASD start of LOGREC area
Read one page of LOGREC data
Read system dump spool file
Read system symbol table
Dynamically
update system
user
directory
Generate
accounting
cards
for
virtual user
Save
3704/3705 control
program
image
Enable or disable
for external
interruption
Virtual console interface for 3270
Error message editing
Provide virtual
machine storage
size
Load, find, or purge a named system
Rules for DIAGNOSE codes:
1.
The DIAGNOSE code must always be a multiple
of 4.
2.
Virtual machines issuing DIAGNOSE codes
should run with interruptions disabled to
prevent
loss
of
status
information
(condition code, sense, etc.) pertaining to
the DIAGNOSE operation.
X'OO' through X'FC' --Reserved for IBM use
x'100' through X'lFC' --Reserved for users
The DIAGNOSE co.mand communicates between a
virtual machine and CPo Correct CP execution of
DIAGNOSE requires that
the operand storage
addresses passed
to CP
via the
DIAGNOSE
interface be real addresses to the virtual
machine using the DIAGNOSE instruction.
In
VM/370,
the machine-coded
format for
the
DIAGNOSE command is:
flits 0
7 8 11 12 15 16
£!!Q!Q~~
fQQ~ Q:
Allows a virtual machine to
examine the VM/370 extended-identification code.
For example, an OS/VSl virtual machine issues a
DIAGNOSE code 0 instruction to determine if the
version of V"/370 it is running in supports the
VM/VS
Handshaking
feature.
If
the
extended-identification code is returned to VS1,
V"/370 supports handshaking; otherwise, it does
not.
31
f"-------T-~-·-------------------,
I
L-~
content
--83--rx
ry
code
58
83
_______
I rx I ry
I ________________
code
___ - L
JI
~_---L-
~!I!!g!H!~!Q!!
DIAGNOSE operation code
User-specified register number
User-specified register number
Hexadecimal
value that
selects
a
particular VM/370
control program
function.
The codes
and
their
associated functions are:
IBM
V~/370:
rx
ry
contains the virtual storage address where
the VM/370 extended-identification code is
to be stored.
is the number of bytes to be stored
(an
unsigned binary number).
If the V"/370 system currently running does not
support the DIAGNOSE code 0 instruction, no data
is returned to the virtual machine. If it does
support the DIAGNOSE code 0 instruction, the
following data is returned
to the virtual
machine (at the location specified by rx):
System Logic and Problem Determination Guide
r-------I Pield
--------------------,
I Attributes I
system
Nalle
VM/370
8 bytes,
EBCDIC
version
Number
The first byte is
the version number, the second
is the level, and
the third is the
prograll
level
change (PLC) number.
3 bytes,
hex
Version
Code
VM/370
executes
the STORE CPU ID
(STIDP)
instruction to determine
the version code.
1 byte,
hex
MCEL
VM/370
executes
the
STIDP
instruction to determine the maximum
length of
the machine check
extended
logout
area (MCEL).
2 bytes,
hex
VM/370
executes
the
STORE
CPU
ADDRESS
(STAP)
instruction
to
determine
the
processor
address.
2 bytes,
hex
The
userid
of
the virtual machine issuing the
DIAGNOSE.
8 bytes,
EBCDIC
CPU
Address
userid
LA
LA
DC
Description
CPPURC DC
CPPUNCL BOU
~!!2!Q~~ ~Q~~ ~:
A coapletion code is returned to the user as
a value in the register specified in ry.
A
completion
code
of
0
signifies
normal
completion.
If an error message is issued, the
completion code is equal to the numeric portion
of the error message.
Q!A2!~2j ~Q~l
time.
Bytes 0
Obtains total and
7 8
r
virtual CPU
15 16
23 24
31
-----------------------,
IMM/DD/lYIBB:MM:SSIVirt CPUITotal CPUI
'-----------_._------------Virtual
and
totdl
CPU
microseconds)
is
returned
logical value.
unchanged
by
the
list of
time
as
a
,
used
(in
doublevord
lQ: Releases pages.
where:
ri---contains the virtual address of
page to be released.
ry
Examines real storage.
contains the virtual address
page to be released.
Any of the virtual pages
storage are released.
in real
the first
of the
last
or auxiliary
contains a count of entries in the list.
ry+l contains the virtual address of the result
field that holds the values retrieved from
CP locations.
DIAGNOSE CODB 8: Allows a virtual machine
perform-CP-console functions.
to
where:
ri---contains the address (virtual)
of the CP
console function command and parameters.
ry
£:
where:
ri---contains the virtual address of a 32-byte
data area that does not cross a page
boundary, into which the following data is
stored:
where:
ri---contains the virtual address of a
CP (real) addresses.
ry
C' QUERY PILBS'
*-CPPUNC
The console function output goes to the
user's terminal, and then execution continues.
Any valid and authorized console function can be
executed in this manner.
~!!2!Q~~ ~QQ~
The condition code remains
DIAGNOSE code 0 instruction.
R6,CPPUBC
R10,CPPUNCL
X'83',X'6A',XL2'0008'
contains the length
of the associated
console
function
input,
up
to
132
characters.
DIAGNOSE CODE
miiiIpulatioii:--
1~:
Performs
input
spool
file
where:
ri---contains either a buffer address, a copy
count,
or
a spool
file
identifier,
depending on the value of the function
subcode in ry+1.
ry
(cannot be register 15) contains either the
virtual address of
a spool-input card
reader or, if ry+1 contains x'OPPP', a
spool file ID number.
ry+1 contains
a hexadecimal
interpreted by DMKDRDBR as
the following:
function
code
a command to do
The following example illustrates the virtual
console function:
Section 1. Introduction
59
Code
0000
0004
0008
OOOC
0010
0014
0018
OFFF
Function
Read-next spool buffer (data record)
Read next print SFBLOK
Read next punch SFBLOK
Select a file for processing
Repeat active file BB times
Restart active file at beginning
Backspace one record
Retrieve successor file descriptor
ry+1 on return, may contain error
codes which further
define a returned
condition code of 3.
9 READ/WRITE byte count greater than 2048
10 READ/WRITE buffer not
within user's
storage
cc=3 Uncorrectable I/O
error.
Register
contains the following:
13 CSW (8 bytes) returned to user.
15
Sense bytes are available if user issues a SENSE
comlland.
!2~g:
The
file
DMKDRDER.
manipulation
~!!~!Q~~ £Q~~ 1~:
is
performed
by
Performs limited disk I/O.
DIAGNOSE CODE 1C: Calls the DftKIOEFM routine to
clear-the-j;o error recording data on disk.
where:
ri---contains the code value 1, 2, or 3 to clear
and reformat the I/O ex'ror recording, M/C
recording, or both.
ry
rx
contains the device address of the disk.
is ignored.
~!!Q!Q~~ £Q~~
~Q:
Performs general
I/O without
in terruptions.
ry
points to a CCW chain to read or
limited number of disk records.
write a
Each read or write must specify no more than
2048 bytes
(usually 800 is used), and the CCW
chain is of a standard form,
as shown below.
For a 3330 or 3350 a SET SECTOR command would
precede each SRCH command.
Register 15 contains the number of reads or
writes in the CCW chain
(the number is two in
the following example for a typical CCW string
(to read or write two BOO-byte records):
A
B
SEEK,A,CC,6
SRCH,A+2,CC,5
TIC,*-8,0,0
RD or WRT,DATA,CC+SILI,800
SEEK HEAD,B,CC,6 (Omitted if HEAD No.
SRCH,B+2,CC,5
unchanged)
TIC,*-8,0,0
RD or WRT,DATA+800,SILI,800
SEEK and SRCH arguments for first RD/WRT
SEEK and SRCH arguments for second RD/WRT
The condition codes (cc) and completion codes
that are returned are as follows:
cc=O I/O complete with no errors
cc=l Error condition.
Register 15 contains one
of the following:
1 Device not attached
2 Device not 2314, 2319,
3330, 3340, or
3350
3 Attempt to write on a read-only disk
4 Cylinder number is not in the range of
user's disk
5 Virtual device
is busy or
has an
interrupt pending
cc=2 Error condition.
Register 15
of the following:
!l!~.I~:
rx
contains
address.
a
virtual tape
ry
contains the address of
to be executed.
or
DASD
device
the string of CCWs
The CCW string is processed by DftKCCWTR through
DftKGIOEX.
This
provides
full
virtual
synchronous I/O to any virtual tape or DASD
device specified (self-modifying CCW strings are
not permitted, however). Control returns to the
virtual machine only after completion of the
operation or
detection of
a fatal
error
condition. Condition codes and error codes are
returned to the virtual system. Unit record
devices are not supported.
The condition codes (cc) and completion codes
that are returned fellow:
cc=O I/O complete with no errors
cc=l Exception conditions. Register 15 contains
the following:
1 Device not attached
5 Virtual device
is busy or
has an
interrupt pending
cc=2
Exception
conditions.
Register
15
contains one of the following:
2 Unit exception bit in device status
byte=l
3 Wrong length record detected
cc=3
Error condition.
Register 15 contains
the following:
13 A permanent I/O error occurred. The two
low order positions of the user's R2
register contain the first two sense
bytes.
contains one
!Qig:
5
6
3
8
60
Pointer to CCW string not doubleword
aligned.
SEEK/SEARCH arguments are not within
range of user's storage
READ/WRITE CCW is neither read (06) nor
wri te (05)
READ/WRITE byte count=O
SUPFort is provided for DASD and tape
devices only.
All other devices have a return
code of 13 and a condition code of 3 in the
virtual machine's PSi.
DIAGNOSE CODE
information:--
IBM V6/370: System Logic and Problem Determination Guide
~~:
Provides virtual
device type
rx
contains a virtual device address, or a
value of -1 indicating a virtual console
whose address is not known.
If rx contained a value of -1 upon entry
and a virtual console
was found, the
register
contains the
virtual
device
address in the two low order bytes, upon
return.
ry
or if it was too late to change the real CCV
list because channel or device end had already
occurred, a condition code and return code are
returned to the virtual machine to notify it
that the real CCN string was not successfully
modified. The condition codes are as follows:
Condition
Code GR15
--00--
contains virtual device information.
1
1
ry+l contains real device information.
If ry is
register 15, then
only virtual device
information is supplied.
1
2
3
4
7 8
15 16
23 24
r
31
5
I
ry
IVDEVTYPCIVDEVTYPEIVDEVSTATIVDEVPLAGI
1--I
ry+1 IRDEVTYPCIRDEVTYPEIRDEVHDL Isee Notel
L___
5
6
~
7
!!g!.§!: The
low order byte of ry+1 contains
the current device line length (RDEVLLEN)
for a virtual console,
or the device
feature code
(RDEVPTR) for a device other
than a virtual console.
The condition
codes (cc)
and completion codes that are
returned follow:
8
2
9
J!E!~n~liQ!!
Successfully modified channel program
rx and ry registers are the same.
Device specified by ry register was
not found.
Address given to rx register was not
within user's storage space.
Address given by rx register was not
doubleword aligned.
CCW string corresponding to ry device
and rx address was not found.
CCV string corresponding to ry and rx
address was not found.
CCN at address specified by rx is not
a TIC or a NOP, or CCW in channel
program is not a TIC or a NOP.
New address in Toe is not within
user's storage space.
New address in TOC is not doubleword
aligned.
Too late to change the CCW string
(channel end
or device
end has
already occurred) •
cc=O Data transfer successful
cc=2 Real device does not exist
DIAGNOSE
locatIon
CODE
~~:
Returns
o£~he LOGREC area.
the
DASD
start
cc=3 Device address invalid; or device does
not exist
rx
on return contains the DASD location, in CP
format, of the first record of the syste.
I/O and machine
check error recording
area.
ry
is ignored.
Y!!Q!!Q§~ ~~~j
28: Hodifies a real TIC or
NOP CCV 1n a-channel program when the
associated virtual TIC or NOP has been
modified after a START I/O but before a
channel or device end interruption.
DIAGNOSE
data:--rx
ry
contains the address of the TIC or NOP
CCV that has
been modified.
The
address in rx, the new address in the
modified TIC CCV, and the addresses in
the new eeN list pointed to by the
modified TIC, .ust be "real" with
respect to the virtual m~chine; they
must be "second level" virtual storage
addresses to CPo
contains the virtual device address in
bits 16 through 31.
(Hust be a
different register than rx.)
Vhen DHKHVC has analyzed the DIAGNOSE, the
real CCV string and appropriate TIC or NOP is
located by a call to DHKCCWTC.
If a virtual TIC
had been changed to a NOP, a corresponding
change is made to the real TIC.
If a virtual
TIC had been changed to point to a new list of
CCVs or a virtual NOP had been changed to a TIC,
the program translates the new list via a call
to DHKCCVTR and modifies the existing channel
program to include the new real CCVs. If an
error was detected in the DIAGNOSE information,
~QYj
lQ:
Reads one
page
of
LOGREC
rx
contains the DASD location, in
of the desired record.
CP for.at,
ry
contains the virtual address of a page-size
buffer to receive the data.
The page of data is provided to the virtual
machine via DHKRPAGT. The condition codes are
as follows:
cc=O Successful read, data available.
cc=l End of cylinder, no data.
cc=2 Invalid cylinder, outside recording area
DIAGNOSE
£I1;;:--rx
~Q~j
1~:
Reads
the system
dump spool
contains the virtual address of a page-size
buffer to accept the requested data.
section 1. Introduction
61
ry
(cannot be
register 15)
virtual device address of
card reader.
a
contains the
spool-input
Code
0008
OOOC
ry+l on return, may contain error codes which
further define a returned condition code of
3.
The system chain of spool input files is
searched for a dump file belonging to the user
issuing the DIAGNOSE by DMKDRDMP. The first (or
next) record from the dump file is provided to
the virtual
machine via DMKRPAGT
and the
condition code is set to zero. The dump file is
closed by the CLOSE command issued from the
console.
DIAGNOSE
table:--
fQQ]
]~:
Reads
the
system
symbol
0010
~~~~!~g
rx points to a parameter list containing a
userid and distribution number.
rx points to a parameter list containing a
userid, account number, and distribution
number.
rx points to a data area containing up to
70 bytes
of user information
to be
transferred
to
the
accounting
card
starting in column nine.
!Q!~:
If ry contains X'0010', ry cannot be
register 15.
ry+l contains the length of
the data area
pointed to by rx. If rx points to a
parameter list
(ry not equal to X'0010'),
ry+l is ignored.
The following condition codes are returned to
the user by DMKHVC:
rx
ry
contains the start address of the page
contain the symbol
buffer that is to
table.
CC
-0
1
is ignored.
2
3
The system symbol table (DMKSYM) is read into
storage by DMKDRDSY at the location specified by
rx.
DIAGNOSE CODE 3C: Dynamically updates the system
~;e~-~I~e~t~~y-by DMKUDRDS.
rx
contains the first 4
serial label.
bytes of
the volume
ry
the first 2 bytes of the register specified
by ry contain the last 2 bytes of the
volume serial label.
DIAGNOSE CODE 4C: Generates accounting cards for
the-virtual-user. This code can be issued only
by a user with the account option (ACCT) in his
directory.
rx
ry
Code
0000
0004
62
contains the virtual address of either a
24-byte parameter list
identifying the
"charge to" user, or a variable length data
area that is to
be punched into the
accounting card. The interpretation of the
address is based on a hexadecimal code
supplied in rYe
If the virtual address
represents a parameter list, it must be
doubleword aligned; if it represents a data
area, the area must not cross a page
boundary. If rx is interpreted as pointing
to a parameter list and the value in rx is
zeros, the accounting card is punched with
the identification of the user issuing the
DIAGNOSE.
contains
a hexadecimal
function
interpreted by DMKHVC as follows:
code
~~~~!~g
rx points to a parameter list containing
only a userid.
rx points to a parameter list containing a
userid and account number.
~~~~!ng
Successful operation
User
does
not
have
account
option
privileges
Invalid userid in the parameter list
Invalid function hexadecimal code in ry or
an error occurred in trying to read in the
user machine block (UMACBLOK)
DMKHVC checks the VMACCOUN flag in VMPSTAT to
verify that the user has the account option and
if not, returns control to the user with a
condition code of 1.
If ry contains a code of X'0010',
performs the following checks:
DMKHVC
•
If the address specified in rx is negative or
greater than the size of the user's virtual
storage,
an
addressing
exception
is
generated.
•
If the combination of the address in rx and
the length in ry+l indicates that the data
area crosses a page boundary, a specification
exception is generated.
If the value in ry+l is zero, negative or
greater than 70, a specification exception is
generated.
If both the virtual address and the length
are valid, DMKFREE is called to obtain storage
for an account buffer (ACNTBLOK) which is then
initialized to blanks. The userid of the user
issuing the DIAGNOSE is placed in columns 1
through 8 and an accounting card identification
code of "CO" is placed in columns 79 and 80.
The user data pointed to by the address in rx is
moved to the accounting card starting at column
9 for a length equal to the value in ry+l.
A
call to DMKACOQU queues the ACNTBLOK for real
output. If a real punch is available, DMKACOPU
is called to punch the card; otherwise, the
buffer is stored in main storage until a punch
is free. DMKHVC then returns control to the
user with a condition code of O.
If ry contains other than X'0010' code,
control is passed to DMKCPV to generate the
card.
DMKCPV passes control
to DMKACO to
complete the "charge to" information; either
from the user accounting block (ACCTBLOK), if a
IBM VM/370: System Logic and Problem Determination Guide
pointer to it exists,
or from the user's
VftBLOK. DftKCFV then punches the card and passes
control back to DftKHVC to release the storage
for the ACCTBLOK, if one exists.
DftKHYC then
checks the parameter list
address for the
following conditions:
•
If zero, control is returned to the user with
a condition code of O.
•
If invalid,
generated.
•
If not aligned on a doubleword boundary, a
specification exception is generated.
an
addressing
exception
DIAGNOSE
32107---
program image.
2Q: Saves
the 3704/3705
contains
the virtu~l
parameter list (CCPARM)
ry
is ignored on entry.
address
rx
the
DIAGNOSE code X'0050'
invokes DMKSNC to
validate the parameter specifications and write
the page-format image of the control program to
the appropriate system volume.
ry
Code
~ii-
171
176
179
435
upon return,
codes:
contains the
following error
~~E!~n~!i2n
"ncpname" was not found in system name
table.
System volume specified
not currently
available.
Insufficient space reserved for program
and system control information.
System volume specified is not a CP owned
volume.
Paging error while writing saved system.
~!!2Mg~E £g~~ 2~:
contains the address of the console CCW
string. The format of the special display
CCW is:
CCW X'19', dataddr, flags, ctl, count
dataddr
flags
ctl
control
of
console interface for
is
When a 3704/3705 control program module has
been created, the CftS-based service routine
(SAVENCP) builds a parameter list (see CCPARft in
SAVENCF data areas)
of control information
required by CP to load the module into the
user's
virtual
storage.
It
passes
this
information to CP by a DIAGNOSE code X'0050'.
rx
2§: Virtual
Execution of DIAGNOSE code
58 allows a
virtual machine to quickly display large amounts
of data on a 3270 in a very rapid fashion. The
interface can display up to 1760 characters on
the screen with one write operation instead of
up to 22 individual writes, if each line was
limited to 80 characters.
Por a parameter list address that is nonzero
and valid, the userid in the parameter list is
checked against the directory list and if not
found, control is returned to the user with a
condition code of 2. If the hexadecimal code in
ry is invalid, control is returned to the user
with a condition code of 3.
If both userid and
hexadecimal code are valid, the user accounting
block
(ACCTBLOK) is built
and the userid,
account number, and distribution number are
moved to the block from the parameter list or
the user machine block belonging to the userid
in the parameter list. Control is then passed
to the user with a condition code of O.
~!!2Mg~E £g~~
£g~~
Sets a flag in the VMQSTAT to
reflect an external interruption to the virtual
machine when the PA2 key is pressed on a 3270
keyboard with the APL feature activated.
count
ry
is the address of the first byte
to be displayed.
is the standard CCW flag field.
is a control byte indicating the
starting
output
display
line
(0-22). If the high-order bit is
on, the entire 3270 output display
area is erased before the new data
is displayed. A value of X'PP'
clears the screen,
but writes
nothing.
is the number of bytes to be
displayed (maximum is 1760).
contains the address of the virtual console
device in bits 16-31.
If this ccw is issued to a virtual console
that is not simulated on a real 3270, a virtual
command rej~ct is
generated.
Otherwise, a
buffer is built in free storage and the data
pointed to by 'dataddr' is loaded into it. Data
chaining may be specified in the CCW to link
noncontiguous data
areas;
however,
command
chaining is an end-of-data indication for the
current buffer.
The starting line specified in 'ctl' is
correlated with the data 'count' to ensure that
the data does not overflow the allowed area.
Any invalid
specification will
generate a
command reject.
CP then processes the display CCW returning a
condition code of zero if the display was
successful or a nonzero code if an I/O error
occurred.
DIAGNOSE
£Q~~
2£: Edits error messages.
Execution of DIAGNOSE Code 5C edits an error
message according to the user's setting of the
EftSG function.
rx
contains the
edited.
address of the message
to be
ry
contains the
edited.
length of
to be
the message
section 1. Introduction
63
DMKHVC tests the VMMLEVEL field of the VMBLOK
and returns to the caller with rx and ry
modified as described in Figure 16.
r------------------------------------,
1
VM"LEVEL
1
Registers Upon Return
1
1------------------------------------ 1
IVMMCODEIVMMTEXTI
rx
1
ry
1
1------·_--------------------------------- 1
1 On
1 On
1 No change 1 No change 1
1-------------------------------------- 1
1 On
1 Off
1 No change 1 10 (length 1
1
1
1
1 of code)
1
1----------------------------,------1
1 Off 1 On
1 Pointer to 1 Length of
1
1
1
1 text part 1 text alone 1
1
1
1
1 of message 1
1-----------------------------------1
1
Off
N/A
L _ _off
_ _ _ _1
___
_ _ _ _1
__
_ _ _ _ _ _ _ _ _I _ 0
_ _ _ _ _ _ _ _ _J 1
Figure 16.DIAGNOSE X'5C'/VMMLBVEL Field
Analysis
LOADSYS
DIAGNOSE function:
Execution of the
DIAGNOsi- functIon-(ry=OO or 04) causes
the contrcl program to locate the name and
location of the named system and builds the
necessary page/swap tables. All virtual storage
pages into which the system is to be loaded are
released prior to loading the named system.
When the LOADSYS DIAGNOSE
is invoked, the
virtual
machine's
storage
is
expanded
dynamically, if necessary, and is completely
transparent to the virtual machine.
Whenever
the LOADSYS function is invoked, an automatic
PURGESYS function occurs prior to building new
page/swap tables.
The automatic PURGESYS allows
virtual machines to switch back and forth from
shared systems to nonshared systems.
LOADSYS
When the LOADSYS function is executed in
shared mode and the virtual machine has the CP
trace facility active, the following options are
reset if they are active: instruction trace and
branch trace.
All other options remain in
effect.
If no other tracing options are active,
the user receives the message: TRACE ENDED.
Note:
Note that DIAGNOSE code X'SC' does not write
the messagei it merely rearranges the starting
pointer and length. For CMS error messages, a
console
write is
performed following
the
DIAGNOSE, unless ry is returned with a value of
o.
~Q: Returns
the virtual machine
storage s~ze to the user.
CMS issues this
DIAGNOSE during initialization.
rx
PSi CONDITION CODE =
User's rx = address of where the named system
has been loaded and also the
starting
address
of
virtual
storage released prior to loading
the named system.
contains the virtual storage size.
ry
contains the
address of
the NAMED
system.
The name must occupy eight
bytes, be left justified and padded with
trailing blanks.
the contents must be a multiple of 4 and
its value cannot be greater than decimal
12.
ry=OO
loads the named system in shared mode
and
attach to
the user's
virtual
storage.
ry=04
loads the named system in non shared mode
and
attach to
the user's
virtual
storage.
ry=08
release the nailed
storage.
ry=OC
finds the starting address
system.
system from
virtual
of the named
If the address in the rx register is invalid
an addressing exception occurs.
If the code in
the ry register is invalid, a specification
exception occurs.
64
Successful Execution
PSW CONDITION CODE = 0
User's rx = address of where the named system
has been loaded.
DIAGNOSE CODE 64: Allows any virtual machine to
dynamIcally-load, purge, or find a named system
in its virtual storage.
CMS uses this DIAGNOSE
to support DOS simulation.
rx
LOADSYS function is executed in
machine assist feature
is reset.
•
Q!!~!Q§~ £~Q~
If the
~~iied mode, the virtual
User's ry
ending address of virtual storage
released prior to loading the
named system.
Note: A condition code of one in the user's PSW
is-ieflected only when the named system to be
loaded resides within the virtual machine size.
•
Unsuccessful Execution
PSW CONDITION COIE
Return
User's rx
system
User's ry
Return
errors
£YR~~§l§
= 2
code of 44 if the named
does not exist.
code of 174 if paging I/O
occur ..
DIAGNOSE
function:
The
PURGESYS
function r;I;i~;~-stoii~;--mide addressable to
the virtual machine when the LOADSYS function
was executed. The PURGESYS function releases
page/swap tables associated
with the named
system.
If the area released occupied a storage
address range greater than the virtual machine
storage
size,
this
area
is
now
made
non addressable to the virtual machine.
If the
named system
was being operated on
in a
nonshared mode, the storage which contained the
named system is cleared to binary zeros.
If the
PURGESYS function is executed for a named system
which had not been
loaded by the LOADSYS
function, no action takes place and the command
IBM VM/370: system Logic and Problem Determination Guide
is treated as a NOP. The PURGESYS function is
invoked dynamically by the control program when
a LOADSYS function is executed. The name of the
purged named
system is the same
as that
requested via the LOADSYS function.
•
•
The interval
X'SO'
=0
•
The time-of-day clock
Unsuccessful Execution
•
The time-of-day clock comparator
PSi CONDITION CODE = 1
This occurs if the named system was not found
in the user's virtual storage.
•
The CPU timer
PSi CONDITION CODE = 2
User's ry = Return code
system does
inactive.
The PINDSYS function
determines where the named system will be loaded
into storage, without
actually loading it.
PINDSYS also determines whether or not the named
system has already been invoked by this virtual
machine. PINDSYS is executed by CMS prior to
issuing the LOADSYS DIAGNOSE instruction. This
ensures that the named system to be loaded does
not overlay any part of th~ CMS nucleus and that
the named system is not already active (loaded)
in the virtual machine. If the named system is
active, no
subsequent LOADSYS
DIAGNOSE is
issued, therby keeping the current copy of the
named system active. The address of where the
named system resides is returned in the user's
rx register.
storage location
Before describing how CP maintains these timers
for virtual machines, it is necessary to review
how VM/370 uses the timing facilities of the
real machine.
1.
The location X'SO' interval timer is used
only for times1icing. The value placed in
the timer is the maximum length of time
that the dispatched virtual machine is
allowed to execute.
2.
The time-of-day clock is used as a tille
stallp for
messages
and
enables
the
compute elapsed in-queue
scheduler
to
the
dispatching
priority
time
for
calculation.
3.
The tille-of-day clock cOllparator facility
is used by CP to schedule timer driven
events for both control program functions
and for virtual machines.
A stack of
comparator requests is maintained and as
clock comparator interrupts
occur, the
timer request blocks are stacked for the
dispatcher via calls to DMKSTKIO.
4.
The CPU timer
functions:
Successful Execution
PSi CONDITION CODE = 0
User's rx
address of where the named system
resides in virtual storage.
User's ry
ending address of where the named
system
resides
in
virtual
storage.
PSi CONDITION CODE =
User's rx = beginning address of where the
named system
is loaded
into
virtual storage •.
User's ry
ending address of where the named
system is loaded into virtual
storage.
Unsuccessful Execution
PSi CONDITION CODE = 2
return code of 44 if the named
User's rx
system does not exist.
return code of 174 if paging I/O
User's ry
errors occur.
!Q~~:
timer at main
of 44 if the named
not
exist or is
1!!~~!~ Q!!§!Q~~ !Y~£!~Q~:
•
The System/370 with EC mode provides the system
user (both real and virtual) with four timing
facilities.
They are:
Successful Execution
PSi CONDITION CODE
•
VIRTUAL TIMER MAINTENANCE
Condition code 0 indicates that the
named
system
already resides
in
main
storage.
Condition code 1 indicates that the
named system
exists but
has not
been
previously loaded in virtual storage.
facility
perforlls
•
Accumulates CP overhead
•
Detects in-queue time slice end
•
Simulates virtual CPU timer
three
The
accumulation
of CP
overhead
is
accomplished as follows.
The VKTTIME field
in the
VMBLOK contains the
total CP
overhead incurred by the virtual machine;
it is initialized to the maximull positive
number
in
a
doub1eword,
X'7PPPFFPF
PPPPFPPP'.
Whenever CP performs a service
for a virtual lIachine, GR 11 is loaded with
the address of the V"BLOK and the current
value in VKTTIKE is placed in the CPU
timer.
When CP is
finished with the
service for that virtual machine the CPU
timer, which has been decremented by the
amount of CPU time used, is stored back
into VKTTIKE. GR 11 is then loaded with a
new VKBLOK pointer and the CPU timer is set
froll the new VKTTIKE field.
The allount of
CP overhead for a given virtual lIachine at
Section 1. Introduction
65
any point in time is the difference between
the maximum integer and the current value
in the VMTTIMB field.
since VMTTIME only accounts for supervisor
state overhead, detection of in-queue time
slice end is performed by the CPU timer
when the virtual machine is dispatched in
the problem state. The VMTMOUTQ field in
the VMBLOK is initialized to the amount of
problem state time that the virtual machine
is allowed to
accumulate before being
dropped from a queue. This initial value
is set by the scheduler (DMKSCH)
when the
virtual machine is added to a queue and its
value
depends
on the
queue
entered
(interactive or non-interactive) and on the
CPU model. For example, the initial value
of VMTMCUTQ
for a
user entering
Q1
(interactive)
on
a Model 145
is 300
milliseconds, while for
the same user
entering 02
(non-interactiv~
it is 2
seconds. Each time the user is dispatche~,
the value in VMTMOUTQ is entered into the
CPU
timer;
whenever
the
user
is
interrupted, the decremented CPU timer is
stored into VMTMOUTQ prior to being set
from the new VMTTIMB.
When the problem
state time slice has been exhausted; a CPU
timer interrupt occurs, the VMQSBND flag
bit is set in the VMBLOK, and the scheduler
drops the user from the queue.
At each
queue drop, the problem time used in-queue
(the difference between VMTMOUTQ and the
initial value)
is added
to the total
problem
time field
(VMVTIMB)
in
the
VMBLOK.
value to
the user.
Requests
time-of-day clock are ignored.
to
set
the
A real interval timer or CPU timer is one
that runs when the virtual machine is executing
or is in a self-imposed wait state (that is, the
wait bit is on in the virtual PSW).
A real
timer does not run if the virtual machine is in
a CP pseudo wait state (for example, page wait
or I/O wait) or if the virtual machine can be
run but is not being dispatched because of other
user interaction. Real timers provide accurate
interrupts
to
programs
that
depend
on
measurement of elapsed CPU and/or wait time.
They do not accurately measure wall time -- the
TOD clock must be used for this function.
An EC mode virtual machine with the real
timer opticn has both a real interval timer and
a real CPU timer. Real timer requests for
waiting machines are maintained in the clock
comparator stack. CPU timer requests are added
to TOD clock value at the time that they are
issued. Interval timer requests must have their
units converted.
In addition, if the virtual
CPU timer contains a large negative value, then
a real timer request is scheduled to occur when
the virtual machine becomes positive, so that
the pending timer interruption can be unflagged.
Comparator requests for real timer interruptions
are inserted into the stack whenever a virtual
machine enters a self-imposed wait. They are
removed either when the virtual machine resumes
execution or when it is forced
(or places
itself) into a pseudo wait.
I/O MANAGEMENT
Virtual CPU timer simulation is handled for
EC mode virtual machines if the value in
the virtual CPU timer is less than that in
VMTMOUTQ.
In this case, the VMBLOK is
flagged as "tracking CPU timer" and a CPU
timer interrupt is interpreted as a virtual
timer interrupt rather than as an in-queue
time slice end.
virtual location X'50' timers are updated by the
elapsed CPU time each time the dispatcher has
been entered after a running user has been
interrupted.
The size of the update is the
difference between the value of the timer at
dispatch (saved in QUANTUM at location X'54')
and the value of the timer at the time of the
interruption
(saved in QUANTUMR at location
X '4C') •
virtual clock comparator requests are handled
ty the
virtual timer
maintenance routine,
DMKTMR.
They are inserted into the general
comparator request stack and the virtual machine
is posted when the interruption occurs.
virtual clock comparator requests to set the
virtual CPU timer place the new value into the
ECBLOK. Requests to store the new value update
the ECBLOK field with the virtual CPU time used
since the last entry to dispatch and pass the
66
I/O SUPBRVISOR
The module, DMKIOS, handles the I/O requirements
of all system devices except the following
terminals: 1052, 3210, 3215, 2150, 2741, 3270
remote equipment, and compatible teletypewriter
devices. scheduling and interruption handling
for these devices is essentially a synchronous
process and does not require the queuing and
restart services of DMKIOS.
This is handled by
the module
DMKCNS.
For handling
the I/O
requirements of 3270 remote equipment, refer to
"Programming for 3270 Remote Terminals
an
Introduction" in this section.
REAL I/O CONTROL BLOCKS
To schedule
I/O requests and
control the
activity of the I/O devices of the system, I/O
control uses several types of control blocks.
These blocks are separated
into two basic
types.
•
Static blocks that describe the components of
the I/O system.
•
The dynamic blocks that represent active and
pending requests for I/O operations.
The I/O devices of the real system are
described by one control block for each channel,
IBM VM/370: system Logic and Problem Determination Guide
control unit, and device
available to the
control
program.
Units present
but
not
represented by control blocks are not available
for
either user-initiated
or
cP-initiated
operations.
Because all virtual machines are run in the
problem state, any atte.pt to issue a SIO
instruction results in a program interruption
that indicates a privileged operation exception.
This interruption is handled by CP's first level
program
interrupt
handler,
DMKPRGIN.
It
determines if the virtual machine was in virtual
supervisor state (problem state bit in the
virtual PSW is zero).
If so, the instruction
causing the interruption is saved in the VMBLOK
for
the virtual
machine
and control
is
transferred
to the
privileged
instruction
simulator, DMKPRVLG, via a GOTO.
DMKPRVLG
determines
if
the
privileged
operation affects the virtual I/O configuration.
DMKPRVLG
simulates
non-I/O
privileged
instructions
(such
as
LPSW) •
If
the
instruction's operation code is from x'9C to
X'9F', control is transferred to DMKVIOEX.
After clearing the condition code in the
user's VMBLOK,
DMKSCNVU is then called to
locate the virtual I/O blocks representing the
I/O components
(channel, control
unit and
device) addressed by the instruction. DMKVIOEX
then branches to handle the request based on the
operation requested.
VIRTUAL I/O REQUESTS
The virtual I/O interface maintained by CP
provides to the software operating in the user's
virtual machine, the condition codes, CSW status
information, and interruptions necessary to make
it appear to the user's virtual machine that it
is in fact running on a real System/370. The
virtual I/O interface consists of:
•
A virtual I/O configuration for each active
virtual machine that consists of a set of I/O
control blocks that are maintained in the
control
Program's
free
storage.
This
configuration is built at logon time from
information contained in the user's directory
file, and can be changed by the user or the
system operator.
•
A set of routines that maintain the status of
the virtual I/O configuration.
•
Other system
routines that
simulate or
translate the channel programs provided by
the user to initiate I/O on units in the real
system's configuration.
With a SIO, the condition code returned from
DMKSCNVU is tested to verify that all addressed
components were located. If they were not, then
a condition code of 3
(unit not available) is
placed in the PSW and control returns to the
dispatcher.
Otherwise, the addresses of the
appropriate virtual I/O
control blocks are
saved, and DMKVIOEX tests the status of the
addressed I/O units by scanning the VCBBLOKs,
VCUBLOKS, and VDEVBLOKs to locate the block that
contains the status of the addressed subchannel.
The subchannel status is indicated in:
selector
or
block
•
The
VCHBLOK for
a
multiplexer channel.
•
The VCUBLOK for a shared selector subchannel
on a byte multiplexer channel.
•
The VDEVBLOK for a nonshared subchannel on a
byte multiplexer channel.
When the block containing the status is
found, the status is tested. If the subchannel
is busy
or has
an interruption
pending,
condition code 2 is placed in the virtual PSW.
Otherwise, the subchannel is available and the
device and the control unit are tested for
interruption pending or busy.
If either is
found, condition code 1 is placed in the virtual
PSW and the proper CSW status is stored in the
virtual machine's page zero.
If all components
in the subchannel path
are free,
DMKVIOEX
proceeds to simulate the SIO by locating and
loading the contents of the virtual machine's
CAW from virtual location x'48' and testing the
device type of the unit addressed.
The device type is in the VDEVBLOK.
If the
device class code indicates
a terminal or
console, control
is passed to
the module
DMKVCNEX with a GOTO.
DMKVCNEX interprets and
simulates the entire channel program, moving the
necessary data to or fro. virtual storage and
reflecting the proper interruptions and status
bytes. When DMKVCNEX has finished, it passes
control directly to the dispatcher, DMKDSPCB.
If the referenced device is a spooled unit
record device,
DMKVIOEX passes
control to
DMKFSPEX
for additional
processing.
When
control returns to DMKVIOEI, it passes control
to DMKDSPCH.
If the device is not a terminal or a spooling
device, the SIO is translated and executed
directly cn the real
system's I/O device.
DMKVIOEX calls DMKFREE to obtain free storage
and then it constructs an IOBLOK in the storage
obtained. The IOBLOK serves as an identifier of
the I/O task to be performed.
It contains a
pointer to the channel program to be executed
and the address of the routine that is to handle
any
interruptions
associated
with
the
operation.
DMKVIOEX stores the contents of the user's
CAW in IOECAW and sets the interruption return
address (IOBIRA) to be the same as the virtual
interruption
return address
(DMKVIOIN)
in
DMKVIO.
The CCW translation routine (DMKCCWTR)
is then called to locate and bring into real
main storage all user pages associated with the
channel program, including those containing data
and CCWs. The following occurs:
•
The CCWs are translated.
•
A corresponding
constructed.
real
channel
program
Section 1. Introduction
is
67
•
The data pages are locked into real storage.
•
DMKCCWTR
returns
control
to
DMKVIOEX •
DMKVIOEX places the user in a pseudo wait
state, IOWAIT,
and calls the
real I/O
scheduler DMKIOSQV to schedule the I/O on the
real configuration.
DMKIOSQV queues the request for operation on
the real channel, control unit, and device
corresponding to the address used by the virtual
machine. When the real SID is issued, DMKIOS
takes the user out of IOWAIT and reflects the
condition code for the SID if it is zero. If it
is not zero, the operation is further analyzed
by DMKVIOIN.
In any case,
DMKIOSQV returns
control to DMKVIOEX, which passes control to
DMKDSPCH.
The CCW translator, DMKCCWTR, is called by the
virtual machine I/O executive program (DMKVIOEX)
when an I/O task block has been created and a
list of virtual CCis associated with a user's
SID request must be translated into real CCWs.
When the I/O operation from a self-modifying
channel program is completed, DMKUNTIS is called
by DMKIOS.
When retranslation of OS ISAM CCWs
is required, the self-modifying channel program
checking portion of DMKCCWTR calls DMKISMTB.
DMKCCWTR operates in two phases:
•
•
A scan and a translate phase.
A TIC-scan phase.
A self-modifying channel
function is also included.
Other privileged I/O instructions are handled
directly by
DMKVIOEX.
DMKVIOEX
scans the
virtual channel, control unit, and device blocks
in the same manner as for a SID and reflects the
proper status and condition to the virtual
machine. In some cases (TIO), the status of the
addressed devices is altered after the status is
presented.
If the operation active on the virtual device
is actually in progress in the real equipment,
the simulation of a HID or HDV is somewhat more
involved, since it requires the actual execution
of the instruction. In this case, the active
operation is halted and the resultant condition
code/status is returned to the user.
The virtual channel-to-channel adapter
(CTCA)
simulates
data
transfer
and
control
communication between two selector channels,
either on
two distinct processors
or two
channels on a single processor.
Data transfer
is accomplished via synchronized complementary
I/O
commands
(for
example,
read/write,
write/read) issued to both parts of the CTCA.
Each part of the CTCA is identical and the
operation of the unit is completely symmetrical.
The CTCA occupies an entire control unit slot on
each of
the two
channels attached.
The
low-order four bits of the unit address (device
address)
are ignored completely and are not
available for use.
The VM/370
control program
support for
virtual CTCA includes all status, sense data,
and interruption logic necessary to simulate the
operation of the real CTCA.
Data transfer,
command byte exchange, sense data, and status
data presentation for the
virtual CTCA is
accomplished via storage-to-storage operations
(MVCL, etc.).
No real I/O operations (excluding
paging I/O) nor I/O interruptions are involved.
Unit errors or control errors cannot occur.
68
program
checking
The scan and translate phase analyzes the
virtual CCW list. Some channel commands require
additional doublewords for control information
(for example,
seek addresses).
Additional
control words are also allocated (in pairs) if
the data area specified by a virtual CCW crosses
4096-byte page boundaries, or if the virtual CCW
includes an IDA (indirect data address) flag.
Space is obtained from DMKFREE for the real
CCW list,
and the translation
phase then
translates the virtual CCW list into a real CCW
list. TIC commands that cannot be immediately
translated are flagged for later processing by
the TIC-scan phase.
A READ or WRITE command
that
specifies that
data cross
4096-byte
boundaries is revised to include an IDA flag
that points to an indirect data address list
(IDAL) and a pair of words for each 4096-byte
page, in which each word handles a data transfer
of 2048 bytes (or less). The real CCW is flagged
as having a CP-generated IDA.
DMKPTRAN is
called
(via the TRANS macro)
to lock each
4096-byte page.
If the real CCW string does not fit in the
allocated free storage block, a new block is
obtained. The old block is transferred and
adjusted before being released. The translation
continues with the new block. The process is
repeated, as needed, to contain the real CCW
string.
Virtual CCWs having an IDA flag set are
converted to user translated addresses for each
IDAW ~ndirect data address wor~ in the virtual
lOlL. OMKPTR1N is called for each IDAW is. The
CCW is flagged as having a user (but not CP)
generated lOA.
The TIC-scan phase scans the real CCW list
for flagged
(untranslated)
TIC commands and
creates a
new virtual
CCW list
for the
untranslated commands.
Scan-translate phase
processing is then repeated.
When all virtual
CCWs are translated, the virtual CAW in the
IOBLOK task block is replaced by the real CAW
(that is, a pointer to the real CCW list created
by DMKCCWTR), and DMKCCWTR returns control to
OMKVIOEX. The user protection key is saved.
IBM VM/370: System Logic and Problem Determination Guide
r---------~---.-~--------~~-~
7 1 Address of Read
1 at 1
Because many of the OS PCP, MFT, and MVT ISAM
channel p~ograms are self-modifying, special
handling ~s required by the V6/370 control
program to allow virtual machines to use this
access method. The particular CCvs that require
special handling have the following general
format:
1
8 1
1 Address of TIC
1
1
1
at 2
-1-------------1
1
Unused
1
1
Unused
I-~-------~-I
9 1
1
Data area for READ at 1
I-------------~----I
10 1
SEEK HEAD on 9
1
11 1
TIC to 4
1
1---------------------------1
I-------------------~---I
o
A
12 1
2
6
8
r--------------------------------------,
1
READ DATA C+7 10 bytes
1
1
1
C
1------1-----1------1-------1
1
1
1
1
1
1----1-----1----1-----------1
E
F
1
13 1
Image of ____
TIC CCV at 2
L-_______________
~
1,
~~_______
1-----1------ 1----------1
B
D
1
Image of REID CCV at 1
1----------------------1
TIC to E
1
1
1
1
1
1----1---1------1------1
1
SEEK: SEEK head on D
1
1----1---1-------1------1
L
~
1_______________________________
SEARCH on D+2
1
The CCV at A reads 10 bytes of data. ~he
tenth byte forms the command code of the CCV at
E.
In addition, the data read in makes up the
seek and search arguments for the CCvs at E and
F. After the CCV string is translated by the
VM/370 control program, it usually is in the
following format:
The translated read CCV (at 1) is moved to
the save block at 12. The TIC CCW (at 2) is
moved to the save block at 13, and the addresses
of 1 and 2 are saved at 7. The read CCV at 1 is
modified to point to a 10-byte data area at 8+7
in the save block. The seek head CCV at 3 is
copied into the save block at 10, and the seek
address is modified to point to the data area at
9. At 11, a TIC CCi is built to rejoin the
translated CCV string at 4. The search at 4 (or
any subseguent
search referencing
D+2)
is
modified to point to 9+2.
The completed CCV
string has the following format:
r-
1
1
2 1
Readdata 8+7
------------.---,
1
10 Bytes
~---I
1
TIC to 10
I------~-------·------~--I
o
r
2
3
4
5
6
2
6
8
------------,
1
READDATA C+7 10 bytes
1
1----1-----1
1----1
1
TIC to 3
1
1
1
1
SEEK: SEEK head on 6
1
1----1----1---1
1
1
SEARCH on D+2
1
1----1----1-----1
1
1
1
etc.
1
1
1----1----1
1----1
1
I l l S AM word
1
L
To accomplish an efficient and non-timing
dependent translated operation for OS ISAM, the
virtual CCV string is modified in the following
manner.
DMKISMTR is called by DMKCCVTR if, during
normal translation, a CCV of the type at 1 is
encountered. The scan program locates the TIC
at 2 by searching the translated CCV strings.
The TIC at 2 locates the SEEK at 3.
The virtual address of the virtual SEEK CCV
at E is located fro. the RCWTASK header. Seven
doublewords of free storage are obtained and the
address of the block is saved in the IS1M
control word at 5. The seven doublewords are
used to save the following infor.ation from the
translated CCV strings:
3 1
14 1
1
1
-----1
Unused
Search on 9 + 2
1
----------------1
5 1
1
6 1
Etc.
1
1
IS1M
word
1
-I
1
------~-----·--~·---I
7 1
1
1----1
6 1
1
1
1
1----1---1---1
1
9 1
1
10 1
1
11 1
1
1---1
Unused
Data Area for Readdata
1
- - - - - - - - - - - - . -,----1
Seek Head on 9
1
1
TIC to 4
1
L
~
The interruption return address in the IOBLOK
is set to DMKUNTIS.
DMKURTIS restores the CCVs
to their
original for.at
fro. the
seven
doubleword extensions, moves the 10 bytes of
data from 8+7 into virtual storage (at C+7), and
releases the block. lor.al IIO handling is
resumed by DMKVIO and DMKURT.
IIO COMPONENT STATES
The I/O components represented by the control
blocks described in "Real I/O Control Blocks"
are in one of four states and the state is
indicated by the flag bits in the block status
Section 1. Introduction
69
byte. If the component is not disabled,
either busy, scheduled, or available.
it is
If the disabled bit is on, the component has
been taken offline by the operator or the system
and is at least temForarily unavailable.
A
request to use a disabled component causes the
IOBLOK to be stacked with an indication of
condition code 3 on the SIO and the real SIO is
not performed.
An I/O unit is busy if it is transferring
data (in the case of a channel or control unit),
or if it is in physical motion (in the case of a
device). If an I/O unit is busy, the IOBLOK for
the request is queued from the control block
representing that I/O unit.
An I/O unit is scheduled if it is not busy
but will become busy after a higher level
component
in the
subchannel path
becomes
available and an operation is started.
For
example, if a request is made to read from a
tape drive and the drive and control unit are
available, but the channel is bUSY, the IOBLOK
for that request is queued from the RCHBLOK for
the busy channel and the RCUBLOK and RDEVBLOK of
the drive and control
unit are marked as
scheduled. FutUre requests to that drive are
queued from the RDEVBLOK for the scheduled
device.
When
the channel
completes
the
operation,
the next
pending operation
is
dequeued and startedi the scheduled control unit
and device are then marked as busy.
The IOBLOKs for various I/O requests indicate
the status of that request by a combination of
the status bits in the IOBLOK and the queue in
which the block resides.
In general, an IOBLOK
is queued from the control block of the highest
level I/O unit (taken from device up to channel)
in the subchannel path that is not available.
Once the I/O operation is started, the IOBLOK is
chained
from
the
active
IOBLOK
pointer
(RDEVAIOB)
in the real device control block.
Flags in the IOBLOK status fields may also
indicate that a unit check has occurred, that a
sense is in progress, or that a fatal I/O error
(unrecoverable)
has been recognized by error
recovery procedures. After I/O control releases
control of the IOBLOK, it is stacked on the
queue of IOBLOKS and CPEXBLOKs anchored at
DMKDSPRQ in the dispatcher and control is passed
to the second level interruption handler whose
address is stored in IOBIRA.
I/O INTERRUPTIONS
I/O interruptions are either synchronous or
asynchronous.
Asynchronous
interruptions
indicate the change in status of an I/O unit
from the not ready to ready state or busy to not
busy state. In either case, if the affected
component has any pending requests queued from
its control block, they
are restarted and
whether or not the given interrupt is processed
any further depends upon the status of the
interrupting component.
Channel available and
control unit end type interruptions restart the
interrupting component.
An asynchronous device
end is passed to the user if the device is
dedicatedi otherwise, the device is restarted.
70
An
interruption
is
considered
to
be
synchronous if the interrupting device has a
nonzero pointer to an active IOBLOK.
In this
case, the following processing occurs:
•
If a unit check has occurred, a sense is
scheduled, and when the sense is completed,
the appropriate ERP is called.
•
If an ERP is currently in control of the task
(indicated by a flag in the IOBLOK), return
the IOBLOK to the appropriate ERP.
•
If the operation is incomplete (for example,
channel end is received without device end),
the IOBLOK is copied and the copy is stacked
but the original IOBLOK remains attached to
RDEVAIOB to receive the final interrupti
then, the control unit and the channel is
restarted.
•
If the operation is complete (that is, the
device is available), the IOBLOK is detached
from the device and stacked, and the device,
control unit and channel are restarted.
The restart operation usually dequeues the
next IOBLOK that is queued to the restarted
component and queues it to the next higher
component in the subchannel path.
When the
channel level is reached, a SIO is issued and
exit is taken to the dispatcher after handling
any non zero condition codes as previously
described.
VIRTUAL I/O INTERRUPTIONS
When an I/O interruption is received, the IOBLOK
is stacked for dispatching and control is passed
to
the address
specified
in the
IOBIRA
(interrupt
return
address)
field.
For
operations requested by DMKVIOEX, the return
address is DMKVIOIN
(virtual interrupt return
address). When DMKVIOIN receives control from
the dispatcher, it loads the virtual address of
the unit
with which
the interruption
is
associated from the IOBLOK and calls DMKSCNVU to
locate the
virtual device
control blocks.
DMKVIOIN then tests the IOBLOK status field to
determine the cause for the interruption.
If
the block has been unstacked because of an
interruption, the
field is zero.
If the
operation was not started, it contains the
condition code from the real SIO.
Note: The VIRA should not see a real condition
2 as the result of a SIO, since channel
busy conditions are
detected and reflected
before any real I/O operati.on is attempted.
code
A condition code of 3 is reflected virtual
machine and exit is taken
to the to the
dispatcher.
For a condition code of 1, the CSW
status field in the IOBLOK is examined to
determine
the cause
for
the CSW
stored
condition.
The status is reflected to the
virtual machine and various components of the
IBM V6/370: system Logic and Problem Deter.ination Guide
virtual configuration may be freed,
if the
status so indicates. For example, if the CSW
status indicated both channel end and device
end, the
operation was immediate
and has
completed. Thus, the CCW string (real)
may be
released and all
virtual components marked
available.
•
To 1I0veble head DASD devices that are queued
in order of seek address.
•
That release the affected component after
initiation (SEEKS and other control commands)
which are queued last-in-first-out
(LIFO)
from the control block.
The CSW
status returned for
a virtual
interruption must be tested in the same manner,
with the additional requirement that the status
be saved in the affected virtual I/O control
blocks and that the CSW be saved in the VDEVCSW
field for the device causing the interruption.
If the unit check bit is on in the status field,
the sense information saved in the associated
IOERBLOR
(pointed to by the IOBLOR) must be
retained so that a sense initiated by the
virtual
machine
receives
the
proper
inforllation.
Regardless of whether or not the operation
has been
successfully started,
the caller
requesting the I/O operation receives control
froll DMKIOS.
If a free path to the device is
found, the unit address is constructed and an
SIO is issued. If the resulting condition code
is zero, control is returned to the caller;
otherw·ise, the code is stored in the requestor's
IOBLOK along with any pertinent CSW status, the
IOBLOR is stacked, any components that become
available are restarted, and control is returned
to the caller.
In any case, when an interruption is received
for a virtual device, a bit in the interruption
mask, VCUDVIIT, for the device's control unit is
set to 1.
The bit that is set is the one
corresponding to the relative address of the
interrupting device on the control unit.
Por
example, if device 235 interrupts, the fifth bit
in the VCUDVINT lIask in the VCUBLOK for control
unit 30 on channel 2 is flagged.
Similarly, the
bit in the VCUCUINT in the affected VCUBLOK is
also set; in this case, bit 3 in VCHBLOK for
channel 2. If the interruption is a channel
class interrupt (PCI or CE), the address of the
interrupting unit
(235)
is stored
in the
VCHCEDEV field in the
VCHBLOK.
The final
interruption flag is set in the VMPEND field in
the VMBLOK for the interrupted virtual machine;
the bit set corresponds to the address of the
interrupting channel.
The next
time, the
virtual machine
is dispatched
and becomes
enabled for I/O.
Q~g~~~g ~~~!
2Y~YiBg: Requests to start
I/O on
system devices
are normally
handled PIFO.
However, requests to moveable head DASD devices
are queued on the device in ascending order by
seek address.
This ordered seek queuing is
perforlled to minimize intercylinder seek times
and to improve the overall throughput of the I/O
system.
CP assumes that very few virtual machines
perform chained SEEKs. Therefore, the first
logical address represents the position of the
arm upon completion of
the I/O operation.
Ordered SEEK queuing is based on the relocated
real
cylinder.
DMKIOS
uses the
cylinder
location supplied in IOBCYL for ordered SEEK
queuing.
This field is initialized by the
calling CP routine for paging and spooling or by
the CCW translator for virtual I/O. The CCW
translator, DMKCCW, supplies the IOBCYL value in
the following manner:
•
Reads the IPL record,
cylinder 0
relocates to
virtual
•
Recalibrates, issues a real calibrate
then SEEKs to virtual cylinder 0
SCHEDULING I/O REQUESTS
A task that requests an I/O operation lIust
specify the device on which the operation is to
take place and must provide an IOBLOR that
describes the operation.
Upon entry to DMKIOS,
Register 10 must point to the IOBLOR.
The
IOBLOK must contain at least a pointer to the
channel program to be started in IOBCAW and the
address to which the dispatcher is to pass
control in IOBIRA. In addition, the flags and
status fields should be set to zero. If the
operation is a VM/370 control program function
such as for spooling or paging, the entry point
DMKIOSQR is called.
If the requestor is the
virtual I/O executive (DMRVIOEX)
attempting to
start a virtual machine operation, the entry
point DMRIOSQV is called and some additional
housekeeping is done.
In
either case, an
attempt is made to find an available subchannel
path from the device to its control unit and
channel. If an I/O unit in the path is busy or
scheduled, the IOBLOK for the request is queued
to the control block of the I/O unit.
Requests
are
usually
first-in-first-out
(FIFO) ,
except
requests:
queued
those
•
Cha~nel
SEEKs,
relocates
to
the
and
virtual
cylinder
The IOBLOK queuing
subroutine of DMKIOS
recognizes that a request is being queued on a
1I0veable head DASD device by means of the device
class and type fields of RDEVBLOK.
Instead of
adding the IOBLOK to the end of the queue on the
RDEVBLOK, the queuing routine sorts the block
into the queue based on the cylinder number for
the request.
The cylinder
number for any
request to a DASD device is recorded in the
field IOBCYL.
The queue of IOBLOKs on a real
device block is sorted in ascending order by
seek address, unless the
entire device is
dedicated to a given user. In this cas~, DMKIOS
does not automatically schedule the device, and
no more than one request can be outstanding at
anyone time.
When an outstanding I/O request for a device
has completed, DMKIOS attempts to restart the
device by dequeuing and starting the next IOBLOK
queued on the device.
For non-DASD devices,
this is the first IOBLOK queued.
However, for
moveable headDASD devices, the queued requests
section 1. Introduction
11
are dequeued in either ascending or descending
order,
depending on
the current
position
(recorded in BDEVCYL)
and the direction of
motion of the arm.
If the arm is seeking up
(that is, toward the higher cylinder numbers),
the queue of IOBLOKs is scanned from the first
block toward the last until an IOBLOK is found
with an IOBCYL value equal to or greater than
the value in BDEVCYL, or until the end of the
queue is reached. At this point, the device is
flagged as seeking down and the queue is scanned
from last to first until an IOBLOK with an
IOBCYL value equal to or less than RDEVCYL is
found. When IOBLOK is found, it is dequeued and
started. The direction of motion is indicated
by an RDEVFLAG bit and the next request is
dequeued in the down direction until the head of
th~ queue is reached.
Because the queue itself is a two-way chained
list, no special handling for null or unity set
lists is
required, and
the ordered
seek
algorithm returns to FIFO queuing.
]~~!£~!~~ £~~nn~! ~Y~~2!!:
One of the facilities
of the VM/370 control program allows a virtual
machine to control one or more channels on a
dedicated basis.
The channels are attached to
the virtual machine by using the privileged
ATTACH CHANNEL co.mand.
A virtual machine can
have one
or more dedicated
channels.
In
addition, channels can be split between virtual
machines but a dedicated channel cannot be
shared between
two virtual
machines.
For
instance, channel 1 could
be dedicated to
virtual machine A, and channel 2 could be
dedicated to virtual machine B, or they could be
both dedicated to virtual machine A or B.
with a dedicated channel, all virtual machine
device addresses must be identical to the real
machine device addresses.
For instance, virtual
device 130 must be real device 130, and virtual
device 132 must be real device 132.
With
dedicated channels, CP does not perform any
virtual device address mapping.
CP error recording
and channel recovery
procedures are still in effect for dedicated
channels. The dedicated channel support can be
used in
conjunction with
the virtual=real
feature for
any virtual
machine that
is
occupying the virtual=real storage space.
appropriate
invoked.
processing
routine
in
DMKVCN
is
!!!!!!
~!!~g
Simulation ~2!!:tin.!§!: Obtains a buffer
for input ~;~;-ii~i- free storage. The location
of the buffer is set in the VCONCTL block. The
DMKQCNRD routine is called to schedule and
perform an actual read to the corresponding real
device representing the user's virtual console.
If SET LINEDIT ON is specified, the buffer data
is edited and translated to EBCDIC.
When the
read is completed, the data is moved to the
specified user address obtained from the address
portion of the virtual CCW. If command chaining
is specified, processing returns to fetch and
analyze the next CCW.
If command chaining is
not specified, the virtual CSW is constructed in
the VDEVBLOK and an interrupt is flagged as
pending in the VMBLOK.
The Write
Simulation Routine: Obtains
a buffer
f~i the-constiuctI~n-of--the-output message from
free storage.
The virtual machine data is
located from the virtual CCW address in the
VCONCTL block and moved to the data buffer. The
DMKQCNWT routine is called to write the data in
the buffer and provide the necessary length,
translation, and format functions.
Control is
received at the DMKVCN module upon completion of
the writing. At this point, the virtual CCW is
re-examined. If command chaining is specified,
processing continues to fetch and analyze the
next CCW.
If command chaining is not specified,
the virtual CSW is constructed in the VDEVBLOK
and an interruption is flagged as pending in the
VMBLOK.
The Control Simulation Routine:
Is used for the
NOP operation
requires no data transfer or I/O operation.
An
ALARM operation has no equivalent on low speed
teleprocessing equipmenti
thus, a
message
indicating the ALARM operation is constructed.
DMKQCNWT is called to output the constructed
message.
If the command is chained, processing
continues (for NOP or ALARM) to fetch the next
CCW and analyze it. If command chaining is not
specified and this is not the first CCR, a
virtual CSW is constructed in the VDEVBLOK and
an interruption is flagged as pending in the
VMBLOK. If this is the first (and only) CCW,
then a condition code of 1 is presented with
channel end and device end in the virtual CSW.
NOP
-an~--iLiR"--OperatI~ns:·-- A
VIRTUAL CONSOLE SIMULATION
1!!!Y~!
~!!n§~
QE~!~:ti2n: Is
similar to a
control
operation, because
no actual
I/O
operation is performed. However, there is data
transfer. The sense data from the VDEVBLOK is
moved to the virtual storage location specified
in the virtual CCW address.
If the command is
chained, processing continues to fetch the next
CCW and analyze it.
otherwise, an interruption
is flagged as pending in the VMBLOK.
!
DMKVCN receives control from the virtual machine
I/O executive, DMKVIO. When control is received,
the device is available with no interruptions
pending. A console control block, VCONCTL, that
is obtained from storage and chained from the
virtual device control block, VDEVBLOCK, by
DMKLOG
is
accessed for
use
during
the
interpretation of
the virtual
console I/O
sequence. The
user's CAW is
examined for
validity. If it is valid, the TRANS macro is
issued to fetch the first user CCW. This ccw is
moved to the VCCNCTL block for analysis.
The CCW is analyzed to determine if it is a
read, a write, a control, a sense, a TIC, or an
invalid operation. Based upon the analysis, the
72
!i!!Y~! !!£ Q~!!~~!!~n: Fetches the virtual CCW
addressed by the TIC address and analyzes the
fetched CCW.
If the fetched CCW is itself a
TIC, or if the TIC is the first CCR, a channel
program check condition is reflected to the
virtual machine as an interruption or as a CSW
stored condition, respectively.
!
IBM VM/370: system Logic and Problem Determination Guide
J~Y~!~~
Q£~~~!~2~:
Any other
operation is
considered invalid. Command reject status is
posted in the virtual
sense byte and the
operation is terminated with unit check status
presented in the virtual CSW.
r----------------"---------'--·----,
IOperationl Address IF1ags ITP Op 1 Count 1
1 Code
I Field 1
1 Code 1
1
1 1 byte 1 3 bytes 11 by tel 1 bytel2 bytesl
----J
L-_________
____________________
REMOTE 3270 PROGRAMMING
o
31 32
For a basic understanding of CP processing of
data relating
to 3270
devices on
binary
synchronous
lines,
the
information
and
terminology contained in J]~ ~~lQ In!Q~!s!i2~
Q!2£!~I 212!~! f2!£2n~n! Q~2£!i£!!Q~, GA27-2749,
and ~~~~~a! !~!Q~m~!!Qn - ]i~s~I 2Y~£h!Qn2~2
~Qmm~n!£a!!Qn2' GA27-3004, is required.
Operation Code
contains the hexadecimal value of the
type of operation performed by the
command.
7 8
Text messages to and from remote terminals
and printers can only be achieved when the
bisync line is in text mode.
•
Text messages from a remote device can be the
result of a general poll or specific poll
operation to the related device or devices on
the bisync line.
This polling communication
interface
is
accomplished
by
each
line-connected control unit having unique
specific poll and general poll recognition
circuitry and by the CP terminal list of
valid bisync lines and 3270 remote control
unit addresses.
This list, the terminal
list,
is
generated
by
VM/370
system
generation procedures employing TERMINAL and
CLUSTER macros.
For
more details about
terminal list generation, see the !~L1IQ:
R!a~n!ng
•
•
•
sng
X'Ol'
X'02'
X'03'
X'09'
X'23'
X'27'
X' 2F'
Every message (text or control)
that is
issued by CP mayor may not be responded to
by the remote station or control unit. The
type of response (or absence of response)
that CP receives depends on the receptiveness
of that device or
control unit to the
previously sent message (is the device ready
and enabled and accurately addressed) and the
content and correctness of the message
(no
line errors).
To establish the relationship of the line of
terminal response to a particular line or
device write or read operation, CP employs an
operation "tracking" facility
(TP op code)
imbedded in the issued CCws. The function
performed by the CP op code is described in
the following CCW formats.
63
WRITE
READ
NO-OP
POLL
SET MODE
ENABLE
DISABLE
Address Field
Depending on CCW usage, this field may
address an:
Area
The address of the
buffer)
located in
BSCREAD.
data area
(read
the BSCBLOK at
Table
The appropriate location in the table
of
data-link
control
characters
provided
in
the
module
DMKGRF
(Example: RVI, EOT, ENQ).
212!~m g~n~~~!!Q~ ~~!g~.
Reliability
and
dependability
of
line
operation is achieved by the use of: a double
addressing scheme, control characters with a
rigid
message
protocol,
and
complex
redundancy check
characters appended
to
transmission messages.
Examples of these
techniques are shown in the formats that
follow.
47 48
Valid operation codes are:
A
digest
of some
of
this
essential
information as it applies to VM/370 follows:
•
39 40
Response
(BSCRESP).
The address location of
the response message in the BSCBLOK.
List
The appropriate entry in terminal list
(NICBLOKS) associated with the READ or
WRITE operation. The entry for WRITE
operation is at location BSCSBL. The
entry for the READ operation is at
location BSCPOLL.
Note: To see how the key words AREA, TABLE,
RESPONSB, and LIST are used, refer to the CCW
sequences described in "I/O Program Routines for
Bisync Lines and 3270 Remote Devices" in this
section.
Flags
The flag bits turned on in the CCW: CC
(channel commands). CD (chained data),
SILl
(suppress
incorrect
length
indicatio~ ,
skip
(suppress
data
transfer to main storage) and PCI
(program controlled interrupt).
TP Op Code
An imbedded teleprocessing operation
code in the CCws used in bisync line
communications.
This
code
is
inspected
by
the
secondary
interruption handler, DMKRGFIN, when
section 1. Introduction
73
channel
end and
device end
are
received. The code is also used by
the error processing module, DMKBSC.
The code indicates the function being
performed by the associated command.
For use of the TP op codes, refer to
the formatted CCWs that follow.
count
Refers to the byte length of
READ or WRITE operation.
the CCW
I/O PROGRAMS FOR BISYNC LINES AND REMOTE 32105
Before
data communication
to remote
3210
equipment
can
take
place,
the
remote
teleprocessing line, the control unit and the
device(s)
must be enabled for communication.
This
occurs
when
control
unit
hardware
recognizes
a unique
string of
characters
transmitted on the line from CPo
Disabling a
line occurs in a similar manner. The following
is the
format of the
CCWs used
in the
enabling/disabling operation:
,.--------------------------------------,
10pera-ICommandlAddress IFlagslTP OplCountl
I tion
I Code
I
I
I Code I
I
,.----------------------------,
10pera-ICommandlAddress IFlagslTP OplCountl
Ition
I Code 1
1
I Code 1
I
1------------------------------1
IWrite 1 01
1 Table 1 CC, I 02
1 1 I
1
I SILl 1
1
1
1 an EOT I
1---------------------------1
1 write 1 01
1 List
1 CC, 1 03
ILIST 1
ladI
1
1 SILl 1
1
1
Idress-I
1
1
1
I
I
ling
I
I
1
1
1
1
Ichar. 1
1
1
1
1
I
1----
--------1
IRead
02
IResponsel SILII 05 1 2 1
IRe1
1
1
1
1
1
1 _ _ _ _ _ _1_ _ _ _ _
1 _ _ _ _1_ _ _ --'1
1L sponse
_ _ _ _ _I _ _ _ _ _ _
i
----.-----------,
10pera-ICoDmandlAddress IFlagslTP OplCountl
Ition
1 Code 1
1
ICode 1
1
1
----------1
IWrite 1 01
Area 1 CC, 1 10
Ivari-I
1 text 1
1
1 SILl 1
1able I
1---------------------1
I Read
I 02
1 Responsel SILII 11
1 2
I
IRe1
1
I
1
1
1
I
1
1
I
1
1sponse I
------------------------'
,
1-------------------------------------- 1
1Di s- 1 X' 2F ' I
0
1 CC, 1 01
1 1 1
1 SILl 1
1
1
1abl e l l
ILine
1
1
1
1
1
1
1-----·------------------ 1
ISet
1 X'23'
X'40'
CC, 1 01
1 1 1
SILl 1
1
1
1 Mode 1
1
1
IEnablel X'21'
0
SILII 01
1
Line
1L _
_ _ _ _1
_ _ _ _ _ _ _ _ _ _ _ •_ _ _ _ _ _ _ _1_ _ _ _ _ _ _ _ _ _ J1
to be
reset
mode.
reset
In situations where the line is found
in text mode,
CP can issue a write
sequence to put the bisync line in control
The following format illustrates the write
CCW.
r----------------------------------,
10pera-ICommandlAddress IFlagslTP OplCountl
1tion 1 Code 1
1
ICode 1
1
1------------------------------1
r-----------------"-----------------,
IWrite I 01
1 Table I SILII 09
I 1 I
1 _ _ _ _ _1 _ _ _ _ _ _
I ____
1 ____
1 _ _ _.J1
1L _EOT
____
10pera-ICommandlAddress IFlagslTP OplCountl
Ition 1 Code 1
1
ICode I
1
1-----1
IDis- 1 X'2F'
0
SILl 1 01
1
lable 1
1
1
ILine
1
1_ _ _ _ _ _ _ _ _ J1
L
____
After a line is
then be directed to
sequence of events
write continuous) is
enabled, communication
a particular resource.
(for a write disable
as follows:
can
The
and
Send a data link control character on the
line that places the control unit in control
mode.
This
mode makes
the control
unit
receptive to the specific address indicated by
the second CCW. The third CCW is a read CCW
that is needed for the acknowledgement response
from the addressed control unit.
Normally, in
response, CP transmits a block of data to that
device with a write text CCW.
Acknowledgement
of receipt of this data is contained by the read
response (write continue) CCW.
The format of
the CCW
write initial and
write continue
operation follows.
14
In situations where the expected response
from a remote station was not received or was
invalid, the channel program may request the
remote station to retransmit the response. The
following write ENQ format shows this sequence.
The remote station, upon receipt of the ENQ
message, responds by transmitting the expected
or valid response to the response area indicated
by the second CCW.
r--------
-,
10pera-ICommandlAddress IFlagslTP OplCountl
1 tion
I Cede 1
1
ICode 1
I
1-------------------
IWrite I
1 ENQ 1
01
1 Table
1
1---------------
1 CC, 1 03
1 SILII
--I
1
1
1
1
IRead
1 02
1Responsel SILII 11
2
1
IRe1
1
1
1
1
1 _ _ _ _ _1_ _ _ _ _ _1_ _ _ _1_ _ _ _ _ _-.A1
1L sponse
_____
IBM VM/310: system Logic and Problem Determination Guide
Read operations occur following a general
poll or a specific poll for text messages. In a
general poll sequence, CP transmits the general
poll characters to the attached control unit on
the bisync line. The control unit recognizes
the polling request, then the list (referred to
in the poll eew) of enabled devices is scanned
for any messages that are queued and ready for
transmission.
A positive acknowledgement (yes,
I have a message to transmit) from any of the
attached devices causes the next CCW to be
skipped. The last CCW provides the read buffer
and the count necessary for the incoming data
block from the first remote station on the list
that had a message queued for transmission. If,
however, all
remote stations
respond with
negative acknowledgement (no messages queued) or
any station queried for a response fails to
respond, then the channel program ends with the
third ccw.
The following read initial format
shows the initial read CCW sequence.
r-----------------------------------------,
IOpera-ICommandlAddress IFlagslTP OplCountl
Ition
I Code
I
I
ICode I
I
1------------------------------1
IWrite I 01
I Table I CC, I 02 I 1 I
I
I SILII
I
I
I EOT I
1------------------1
IPol1
I 09
List
ec, I 03 ILIST I
I
I
1-------11/0
I 03
INoI
lopera-I
Ition I
IIRead
SILl I
0
SILII 07
I
I
I
I
I
I
I
I
I
I
I
I
I
r---------------
i
I Opera-I Command I Address IFlagslTP OplCountl
Ition I Code I
I
ICode I
I
1----------------------------1
01
I Table
I CC, I 06 I 1 I
I
I SILl I
I
I
1--------------------------------1
IRead
I 02
I Area
I SILII 10 I 162 I
IWrite I
I
I NAK
Text I
I
I
I
I
I
IL_________________________________________
~
Once ep
message processing
receives an
error-free message fro. a remote station, CP
sends an RVI control character to the remote
station before processing the message.
The
remote station, upon recognition of the RVI
character, halts the
sending of additional
queued data and responds with EOT
(instead of
the normal ACKO/ACK1 response).
The second ceN
of the read interruption sequence processes the
EOT response from the remote station as shown in
the format below.
r--------------------
---,
I Opera-ICommand I Address IFlagslTP OplCountl
Ition I Cede I
I
ICode I
I
I------------~--------------I
IWrite I X'01' I Table
I
I
I RVI
I ce, I 06
I 51 LI I
I
I
2
I
I
1------------------------1
IRead I X'02' IResponsel SILII 11
I 2 I
I ReI
I
I
I
I
I
L
Isponsel
_________________________________
I
I
I
I- - - - - JI
---------------1
SILII 10 I 162 I
02
Area
Text
I _
IL___________________________
DATA FORMATS - BISYNC LINES AND REMOTE 3270
After CP receives a message from a remote
station, it
may ~eissue the
initial read
sequence to poll the remaining stations on thelist (assuming the list of enabled devices was
not exhausted on the first pass of the initial
read sequence). In the event that the list was
exhausted on either the first or a subsequent
initial read sequence, CP starts the poll delay,
then allows the poll delay interval to expire
before starting another read scan to the line
(assuming CP has no higher line priority tasks
to process) •
If, in the process of receiving
messages from remote stations, CP receives a
message block that is invalid or its beginning
or ending bisync control characters are not
recognized, CP can elect to send a negative
response back to the remote station.
This
negative response, the NAK control character,
causes the remote station to retransmit the
previous message to CPi this incoming message is
processed by the second CCW of the read repeat
sequence as shown in the format below.
CP, in conjunction with remote 3270 support,
uses the
following formats
for its
text
messages.
For a detailed explanation of the
abbreviations used, see the IBM 3270 Information
R!§£!gx
~~§t~m £Q!£Q~~nt
GA27-2749.
R~§£~iEli2n:-order-io:
Display commands use this message format for the
placement or erasure of data anywhere on the
display screen.
The
display commands that
implement this function are: WRITE
(XIF11),
ERASE/WRITE (XIF71) and COpy (X'F7 1 ).
Section 1. Introduction
75
~IIQI ~~!~g§ ~!~! ~~I~!!
r--------------------------
Another form of input message is the error
status message.
Error status is processed by
the
DMKBGF
module.
The
characters,
IB,
following the SOH signify that this message
contains sense and status data. The format of
this message follows.
ISTXIESCICMDIWCCIBSAI Buffer I Orders ISBAI
&_ Text
I _ _ _I_ _ _ _I _ _ _I_ _ _ _IAddress
LI _ _ _ _
_ _ _ _ _ _ _ _I_ _
_ _ _ _ _I_ _ _ _I
2
variable
- - - - - - // - - - - ,
I Buffer I
IAddress I
I ETX I
I
I
_ _ _ _ _ _ _ _ _ _ / / _ _ _ _ .J
2
r-------------------·-·-----·------,
1
IIndexlSOHI I I B ISTXICU IDeviSense/IETX I
IByte I
I
I
I
IADBlldrlStatusl
I
Bytes
I _____
I ___
I ___
I _ _ _I _ _ _I _ _ _I _ _ _I_
L
____I
_ _ - - . lI
The COpy command is limited to remote terminal
display devices and compatible printers located
on the same control unit.
Action starts by
pressing a PF key designated for the COPY
function.
CP responds by sending a message to
the control
unit that
contains both
the
designated printer and the display station that
requested the action and directs the control
unit to print the designated display buffer to
the printer specified.
The format of the COpy messages follow:
The test request message, upon receipt from
display terminals, is ignored by CPo The input
inhibit mode that the display terminal enters
upon pressing the test request key can be reset
only if the terminal user presses the BESET key.
The characters, 1/, following SOH indicate the
test request function.
The format of this
message follows.
.--------------------------------,
I Index I SOH I I I / I STX I Text I ETX
I
_ _ _ _ _I_ _ _ _ _I_ _ _I_ _ _ _
I _ _ _ _I_ _ _ _ _ _I _ _ _ _--'I
Il _BYTE
r--------------------------,
ISTXIESCI
CMD
ICCCI From
IETXI
IL _ _ _I_ _ _ _
I _X'F7'
IAddressl
_ _ _ _ _I_ _ _ _
_ _ _ _ _ _ _ --.lI
ALLOCATION MANAGEMENT
Beal storage space above the Control Program
nucleus is made up of the dynamic paging area
and
the free
storage
area.
Page
frames
(allocation space in real storage for a page of
data) in the dynamic paging area are allocated
to virtual machines and the control program to
satisfy paging requests. Blocks of storage,
requested by virtual machines and CP for working
storage, are allocated from the free storage
area.
r------------------------,
ISTXIESCI CMD IWCCISBAIBuff IETXI
IX'F1'1
I
IAdr
I
I
I
I
IL_________________________
I
I
I
I
I (4040 I --.lI
The following is
representative of typical
input-to-processor message formats.
The format
of a multiline read operation follows.
.---------------------------------------I Index ISTXICU IDevlAIDICursor ISBAIBuff
I
I Byte
I
I Adr I Adr I
I Address I
I Address I
l _ _ _ _. _ _ _ _ _ _ _ _ _ _ _ _
---I / - - - - - - - - - - - - - / / - - - - ,
I Text ISEAI Buff I Text I
I
I
I
I
I Adr
IETX
I
I
I
---I/------------------//---------'
76
NORMAL PAGING BEQUESTS
If a program interruption is caused by a normal
paging request (not from a virtual machine that
is running in EC mode with translation on),
DMKPRGIN determines whether a segment or page
translation error has occurred.
If one of these
errors occurred, an invalid address interruption
code is set, and the interruption is reflected
to the virtual machine supervisor. If a segment
or page translation error bas not occurred, the
virtual machine's current PSW is updated from
the program old PSW (PROPSW~, the address of the
current VMBLOK is placed in register 11, and
DMKPTRAN is called to obtain the required page.
When the paging operation is completed, control
is returned to DMKDSPCH.
NEXT storage, the
management of real storage~ and the management
of auxiliary storage (DASD paging devices).
IBM VM/370; System Logic and Problem Determination Guide
process of translation, CP encounters a CCW
that addresses a page that is not resident in
real storage, a call is made to the paging
manager
to
make
the
referenced
page
resident.
When operating in the CP relocate environment,
each virtual machine's virtual storage space is
described by two sets of tables.
•
•
One set,
the segment and
page tables,
describes the location . and availability of
any of the virtual machine's virtual pages
that may
be resident in
real storage.
Locations in these tables are indexable by
virtual address, and the entries contain
index values that reference corresponding
real storage addresses.
In addition, each
table entry contains an indication of whether
the corresponding virtual page is available
to the user in real storage. These tables are
referenced directly by the DAT feature when
the virtual machine's program is running.
The second set of tables, called swap tables,
is a map of the locations of the virtual
machine's pages on the DASD devices that
comprise the system's paging or auxiliary
storage. The DASD addresses in these tables
can either represent the source of a page of
virtual storage (the location to which a page
may be moved, if necessary)
or a dummy
address, indicating that the given page has
not yet been referenced, and thus has a value
of binary zeros.
The swap tables are arranged in a format
indexable by virtual storage address.
In
addition to containing the address of a page,
each entry contains flags and status bytes
that indicate such information as:
•
The storage protection keys to be assigned to
the page when it is made resident.
•
Whether the page is currently on its on its
way into or out of the system
(in transit),
etc.
These tables, are not referenced directly by
the hardware as are the page and segment
tables, but are used by paging management to
locate user pages that are needed to execute
a program.
virtual storage management is done by the
technique known as demand paging. This means
that a page of virtual storage is not 'paged in'
from its DASD auxiliary storage area until it is
needed.
CP
does not determine
the pages
required by
a virtual
machine before
it
executes.
A demand for a page can be made
either implicitly by the virtual machine or
explicitly by CPo
While the requested page is being fetched,
the requesting virtual machine is unable to
continue execution; however, it may be possible
to run other tasks in the system, and CP runs
these while the needed page is being paged in.
When the requested page is resident, the virtual
machine can be run and is dispatched in its
turn.
In addition to
demanding pages, virtual
machines implicitly or explicitly release page
frames of their virtual storage space. Part of
the space may be explicitly released from both
real and
virtual storage
via a
DIAGNOSE
instruction which indicates
to the control
program ihose page frames
that are to be
released. An entire virtual storage is released
when a user IPLs a new operating system or logs
off from the system.
CP also has virtual storage associated with
it. This space contains CP (some parts of which
need not always be resident in real storage) ,
and virtual storage buffers for spooling and
system directory operations.
Although CP makes
use of virtual storage space for its execution,
it does not run
in relocate mode.
Thus,
nonresident
modules
must
be
completely
relocatable.
Real storage management allocates the system's
page frames of real storage to satisfy the
demands for virtual pages made by the system's
virtual machines.
Efficiency
of allocation
involves a trade-off; the paging manager uses
only enough CPU time to ensure that:
•
The set of virtual storage pages that are
resident represent those pages that are most
likely to be used.
•
A sufficient number of cycles is available to
execute virtual machine programs.
•
An implicit demand for a page is made when a
program attempts to reference a page that is
not available in real main storage.
This
attempt causes a program interruption with
the interruption code indicating a page or
segment exception. Upon recognition of this
condition, control is passed to the paging
manager to obtain a page frame of real main
storage and to bring in the desired page.
Inefficiency in the first area causes a
condition known as thrashing, which means that
highly used pages are not allowed to remain
resident long enough for useful work to be
performed by or on them.
Thrashing could be
aggravated by the paging manager's page frame
selection algorithm or by a dispatcher that
attempts to run more tasks than the system can
handle (the sum of their storage requirements
exceeds the real paging space available in the
system).
Thus, the paging manager must keep
statistics on system and virtual machine paging
activity and make these statistics available to
the dispatcher to detect and prevent a potential
thrashing condition.
•
An explicit demand for a page can be made by
CP (for example, in the course of translating
a user's channel program).
If, in the
Inefficiency in the second area causes an
unacceptable ratio of CP overhead to virtual
machine program time, and in extreme case may
Section 1. Introduction
11
cause CP
to use excessive CPU
time.
To
understand how allocation is determined by CP,
the way in which the inventory of real storage
page frames is described to the system must be
understood.
Each page frame
(4096-byte block) of real
storage in the system is in one of two basic
states:
non-pageable
or
pageable.
A
non-page able page must remain resident in real
storage for some finite period of time; thus,
the page frame cannot be taken from its current
owner to give it to someone else. Pages can be
either permanently or temporarily non-pageable,
depending on their use.
Temporary loks usually occur when an I/O
operation has been initiated that is moving data
either to or from the page, and the page must he
kept in real storage until the operation has
completed.
A page can also be
if it
contains an
routine.
temporarily non-pageable
active nonresident
CP
In addition, a page can be non-pageable
through use of the LOCK command. Pages locked
this way are permanently resident until they are
explicitly unlocked by
the UNLOCK command.
Pages that are usually considered permanently
non-pageable are those that contain the resident
portion of CP and
those that contain the
system's free storage area in which control
blocks, I/O buffers, etc. are built.
The data area that page management routines
use to control and allecate real storage is the
cortable. Each page frame of real storage has a
corresponding entry in the cortable, and because
the table entries are fixed in length and
contiguous, the entry for any given real page
frame may be located directly by indexing into
the table. Each entry contains pointers that
indicate both the status and ownership of the
real page which it represents. Some pointers
link page table and swap table entries to the
real page (and thus establish ownership), while
others link the entry into one of several lists
that the paging routines use to indicate the
page frame's status and availability for paging.
A given cortable entry .ay appear on one of
three lists if its real page frame is available
for paging;
however, if the page referenced is
locked or it is in transit, its entry is not in
any list and is not referenced when available
page frames
are being
searched for
swap
candidates. The lists are known as the freelist,
the flushlst,
and the userlist,
and they
represent
various
levels
of
page
frame
availability.
•
78
The freelist contains page frames that are
immediately available for assignment to a
requesting virtual machine.
The virtual
storage pages for which they were last used
have either been released by their owners or
they have
been paged out
to auxiliary
storage. Requests for real storage are always
satisfied fro. the freelist. If the list has
been depleted, the requestor waits until a
new page frame becomes available as the
result of a virtual storage release or a
swap-out.
•
The flushlist contains
page frames that
belong to those virtual machines that have
been dropped from
an active dispatching
queue. The flushlst is the first place that
the page frame selection routine looks to
find a page to swap out or to assign to the
freelist for a virtual machine that requires
real storage space.
•
The userlist contains the cor table entries
for all other pageable pages in the system
that belong to active virtual machines.
Requests for real storage fall into two general
categories; those that are requesting space for
a page of virtual storage, and those
(such as
requests for CP work space)
that need page
frames for their own QS~.
The former,
more
general case is discussed first, because the
latter case is a suhset of the first.
The main page manager routine, DMKPTRAN, maps
a request for a specific virtual storage address
into a page frame
of real storage.
This
requires that the virtual page be read in and
the necessary tables be updated to show the
proper status of the page frame.
D"KPTRAN requires that the caller supply only
the virtual address to be translated and any
options that apply to the page to be located.
Most calls are made via the TRANS macro, which
sets up the necessary parameters, determines if
the required
page is resident,
and calls
D"KPTRAN if it is not.
When D"KPTRAN receives control, it first
tests to see if the requested page is resident.
This is done via the LRA instruction.
If the
page is resident, the routine locks the page if
requested and exits to the caller. If the LRA
indicates that the page is unavailable, it is
still possible
that the required
page is
resident.
This occurs if the page frame has
been placed on the freelist but has not been
assigned to another virtual machine.
When the
page swap routine removes a page frame from a
virtual machine, the unavailable bit is set in
the corresponding page table entry; however, the
real main storage index for the page frame is
left unchanged.
The page table entry is set to
zero only
when the corresponding
page is
actually assigned to another virtual machine.
Thus, if D"KPTRAN finds the page unavailable, a
further test is made on the page table entry to
see if the page can he reclaimed.
If the entry
is not zero (aside from the unavailable bit) ,
the cortable entry for the page frame is removed
from the freelist and the page frame is returned
to the calling virtual machine.
If the page table entry corresponding to the
requested virtual page is zero, the required
page is not in real storage and must be paged
in. However, it is possible that the page is
already on its way into lIain storage. This
condition is indicated by a flag in the SWPTABLE
entry for the virtual page. The DMKPAGIO routine
m~intains a queue of
CPEXBLOKs to be dispatched
when the pending page I/O is complete. The
CPEXBLOK for the page in transit is located and
IB" V"/370: system Logic and Problem Deter.ination Guide
a
new CPEXBLOK,
representing
request, is chained to it.
the
current
Before exiting
to wait for
the p~ging
operation to complete, DMKPTRAB checks to see if
the deferred return (DEFER option)
has been
specified. If it has not, DMKPTRAH returns to
the caller. If the
DEFER option has been
requested, DMKPTRAB exits to the dispatcher to
wait for page I/O completion. When the requested
page has been read into real storage, the list
of CPEXBLOKs are unstacked fifo to satisfy all
requests for the page that arrived while it was
in transit.
If a page is not in transit, a page frame of
real storage must be allocated to fill the
request. Before
the allocation
routine is
called, a test is made to see if the caller
wishes the return to his routine or to be
delayed until after the
requested page is
available. If the DEFER option is not requested,
DMKPTRAN returns to the caller after first
building and stacking a CPBXBLOK that allows
processing of the page request to be continued
the next time the dispatcher
(DMKDSPCH)
is
entered.
DMKPTRAN next calls the freelist manager
(DMKPTBFR)
to obtain the address of the next
available cortable entry. DMKPTRPR maintains a
fifo list of the cortable entries for those page
frames that
are immediately
available for
assignment. As DMKPTRFR releases these page
frames, a check is made to see if the number of
entries on the freelist has fallen below a
dynamically maintained minimum value. If it has,
the page selection routine (select) is called to
find a suitable page frame for placement in the
freelist.
The number maintained as the freelist
threshold has a value equal to the number of
users in queue1 plus the number of users in
queue2 plus 1.
The freelist is replenished directly by users
releasing virtual storage space.
The page-out
routine, DMKPGSPO, calls
DMKPTRPT to place
released page frames directly on the freelist.
However, most replenishment is done via the page
selection routine, select. select is called by
DMKPTRPR when the free list count falls below the
current m1n1mum,
or when a user
page is
reclaimed from the freelist.
In either case,
the selection algorithm attempts to find a page
to swap to auxiliary storage.
The highest
priority candidates for a swap are those page
frames whose cortable entries appear on the
flushlst.
Select attempts to take a flushed
page frame before it takes a page frame from an
active user. If such a page frame is found, it
is checked to see if it has been changed since
page-in. If not, it is placed in the freelist by
DMKPTRPT; otherwise, it is scheduled for a
swap-out by dequeueing the cortable entry from
the flushlst,
constructing a
CPEXBLOK for
dispatching after I/O completion, and exiting to
DMKPAGIO by a GOTO.
After the paging I/O is
complete, the entry is placed on the freelist
via a call to DMKPTRFT.
If the flushlst is exhausted, select must
take a page frame from an active user by
examining the page frames represented by the
entries in the userlist to locate the least
recently used user page frame.
This list is
scanned from top to bottom, and each page frame
is tested to see if its hardware referenced bits
have been set.
If a page frame has been
referenced, its bits are reset and it is queued
to the end of the userlist.
This process is
continued until either an unreferenced page
frame is found or the list is exhausted. An
unreferenced page frame is immediately selected.
Hvwever, if the list
is exhausted, it is
rescanned from the top. An unreferenced page
frame is always found; in the worst case it is
the first one tested on the userlist at initial
entry. However, if this occurs, it indicates
that the rate of entry to select is too low to
permit
differentiation
between
highand
low-usage page frames.
Once a page frame has been selected and
page-out is scheduled, control is returned to
DMKPTRPR, which then passes control back to
DMKPTRAN with the address of the cortable entry
that was allocated. In most cases, page-outs are
completely
overlapped
with
page-ins.
Approximately one half of all page-ins require a
corresponding page-out.
Once a page frame has been assigned, DMKPTBAH
checks to see if a page-in is required.
It
usually is, and the DASD address of the virtual
storage page must be obtained from the user's
swap
table entry
and
the I/O
operation
scheduled. However, if the page frame has not
yet been referenced
(as indicated by a DASD
address of zero), the real main storage page
frame is set to
zero.
After the page-in
operation has been queued, DMKPTRAN exits to the
paging I/O scheduler (DMKPAGIO) which initiates
the paging operation and exits to the dispatcher
(DMKDSPCH) to await the interruption.
After the required page has been read in or
the page frame has been set to zero, DMKPTRAH
queues the appropriate cortable entry to the end
of the
userlist, where
it eventually
is
available for page selection. After developing
the real storage address that corresponds to the
requested virtual address, DMKPTRAH tests to see
if the caller has requested that the page be
locked.
If LOCK is requested, the cortable
entry is de-queued from the userlist and is not
available for selection. A resident page can
also be locked by removing it from the USERLIST.
In addition, a LOCK count is maintained in the
cortable entry so that when all locks have been
satisfied the page frame can again be made
available for paging.
Some requests for main storage page frames
are
handled
differently
than
general
virtual-to-real storage mapping.
In particular,
it may be necessary for CP to obtain additional
free storage for control blocks, I/O lists,
buffers, etc.
This is handled by the free
storage manager, which makes a direct call to
DMKPTRPR tc obtain the needed storage.
Usually
this storage is immediately available (due to
the
page
buffering
technique
previously
described) •
However, if
the freelist
is
exhausted, the request for free storage is
recognized as a high priority call and queued
first on the list of those waiting for free page
frames.
The real storage manager (DMKPTR) accumulates
paging statistics that the scheduler
(DMKSCH)
section 1. Introduction
79
use to anticipate user storage requirements. A
count of page-reads and page-writes is kept in
each virtual machine's VMBLOK; the corresponding
total counts for the system are kept in DMKPSA.
A running total of the number of pages a virtual
machine has resident, at
each instance of
page-read, is kept in the VMBLOK. A count of the
number of
times a virtual
machine enters
page-wait, because a page frame has been stolen
from it,
is also kept in the VMBLOK.
The
section entitled "Controlling
the Depth of
Multiprogramming" under "Dispatcher/Scheduler"
describes the use to which the scheduler puts
these counts.
!~L1IQ
Yi£!Y~!=~~~!
QEi!2~:
The
V~/370
virtual=real option involves the mapping 1n a
one-for-one correspondence of a virtual machine
storage area with an equivalent real storage
area. For instance, virtual page 1 is in real
page frame 1 and virtual page 20 is in real page
frame 20.
virtual page 0, is relocated at the
end of the virtual storage space because it
cannot occupy real page frame O.
The
CP nucleus
is
altered at
system
generation to support the virtual=real option.
Virtual machines with virtual=real
(specially
identified in the directory) can then log on and
use the space reserved for this option. That
space can be used by only one virtual machine at
a
time.
Two virtual
machines
with
the
virtual=real capability cannot occupy the same
space at the same time.
The virtual=real option allows the virtual
machine to bypass the control program's 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
restriction in this situation
is that the
virtual machine does not perform I/O into page
frame 0 because this would perform a· data
transfer into real page frame O.
At the same
time, it is assumed, and cannot be checked, that
the virtual machine also does not attempt to do
I/O beyond the bounds of its virtual addressing
space. To do so would cause the destruction of
either the CP nucleus, which resides beyond the
virtual machine space, or another user's page.
The bypassing of CCW translation for the
virtual machine occupying the virtual=real space
is only invoked after the virtual machine has
executed the SET NOTRANS ON command.
This
command can only be issued by the virtual
machine occupying the virtual=real space. The
command initiates the bypass of CCW translation.
This option is automatically turned off if the
virtual machine performs an explicit reset or an
implied reset by performing a virtual IPL.
During virtual
machine IPL,
I/O must
be
performed into page frame O. For this reason,
normal virtual
IPL simulation
assumes CCW
translation in effect to accomplish the full
simulation. Once the IPL sequence has completed,
CCW translation can be bypassed by issuing the
SET NOTRANS ON command.
When the virtual machine demands a page frame
thr?ugh normal use of CP's page tables, the
pag1ng routine
recognizes the
virtual=real
capability. It then assigns the virtual page to
the equivalent real page frame and does not
80
perform a paging operation, because all these
pages are resident and are never swapped out.
Note:
The
virtual
machine
running
with
vIrtual=real is still run in System/370 relocate
mode.
Virtual 270X lines and sense operations from
the virtual machine do not use the virtual=real
function. These invoke CCW translation for the
virtual enable/disable lines and the transfer of
the sense bytes.
The UNLOCK command has a VIRT=REAL operand
that essentially releases the virtual=real area
for normal system paging use. Once the area has
been released, it can only be reclaimed for
additional virtual=r~al operations only by an
IPL of the VM/370 system.
The size of the
virtual=real
area
is
an
installation
specification that is part
of the special
nucleus generation procedure that is outlined in
the !1!Ll1Q: E!!!~!!i!!.9
~!!g ~I§i~!!! !!~!!~!:~:t!s.m
§y!g~.
The size of the area must be large
enough to contain the entire addressing s~ace of
whatever virtual machine wishes to occupy that
space. A virtual machine can use a smaller space
than is provided but cannot use a larger space
without regenerating the CP nucleus.
DASD STORAGE MANAGEMENT
Any virtual machine's virtual storage pages that
have been referenced but are not resident in
real storage must be kept in slots on the DASD
paging device. DASD page space is assigned only
when the page is selected for a page-out.
Certain DASD pages may also be marked read-only.
Thus, the DASD address slot initially associated
with the Fage should be considered to be the
source of the page only. If the page is changed
after it has been read into real storage, a new
slot must be obtained when it is paged out.
Examples of read-only pages are those which
contain portions of pageable saved systems and
pages which are part of a system spool file.
Slots can be reassigned when DMKPTRAN finds that
it must swap a page out to a movable head DASD
device. In this case, the old slot is released
and the new slot is obtained.
If a new slot is required, DMKPGT is called to
supply the address of an available slot. DMKPGT
maintains a chain of cylinder allocation maps
for each cylinder that has been assigned for
either virtual storage or spool file paging.
The allocation chains for spooling are kept
separately from those used for paging so that
they can be checkpointed in case of a system
failure. However, in other respects they are the
same. The allocation blocks for a given volume
are chained from the RDEVBLOK for the device on
which the volume is mounted. The chains of
cylinder
and
slot allocation
blocks
are
initialized by
DMKCPI.
Each block
on an
allocation chain represents one cylinder of
space assigned to paging, and contains a bit map
IBM V8/370: system Logic and Problem Determination Guide
indicating which slots have been allocated and
which are available.
Each block also has a
pointer to the next allocation block on the
chain, a cylinder number, and a record count.
DMKPGT searches this list sequentially until an
available slot is found; its DASD address is
then determined and passed back to the calling
routine. If DMKPGT cannot find a cylinder with a
de-allocated slot,
it enters
the cylinder
allocation phase. When an available cylinder is
found, it constructs a page allocation block for
this cylinder and allocates a page to the
caller.
space available
space on these
before it
allocates on any other available owned volumes.
Within the class of preferred devices, space is
allocated first on the fastest devices, and
these are spead out across channels and devices.
Allocation on non preferred devices is spread out
in the same manner.
cylinders for spooling
space are not allocated from preferred devices.
Allocation on a given device is done from the
relative center
of the volume
outward, a
cylinder at a time in a zig-zag fashion in an
attempt to minimize seek times.
When a request to allocate a slot for virtual
storage paging is received by DKKPGTGT and the
slot must be allocated on a moveable head
(2314/2319, 3330, 3340, or 3350) device, a
cylinder and slot are selected in the following
manner:
DMKPGT controls the paging and spooling I/O load
of the system by allocating cylinders evenly
across all available channels and devices. In
order for a device to be considered available
for the allocation of paging and spooling space:
•
Its volume serial number must appear
system's owned list.
•
It must have at
least one cylinder of
temporary space marked as available in the
cylinder allocation block which is located on
cylinder 0, head 0, record 3.
1.
CP tries to allocate
a space on the
cylinder at which the arm on the selected
device is currently positioned.
2.
If slots are not available on the current
cylinder, CP tries to allocate space on a
cylinder for which paging I/O has been
queued.
3.
If the above conditions cannot be met, CP
allocates space as close to the center of
the volume as is possible.
in the
At system initialization time, cpinit reads
in the allocation records for each volume and
constructs the chains
of device allocation
blocks
from
which
DKKPGT
allocates
the
cylinders. In managing the cylinder allocation,
DMKPGT takes three factors into consideration:
device type, device address, and possible status
as a preferred paging device.
Before DKKIOSQR is called, the queue of
IOBLOKs currently scheduled on the device is
examined.
If paging I/O
has already been
scheduled on a device,
the paging channel
programs are slot sorted and chained together
with TICs.
PAGING I/O
A reques~ for a cylinder of virtual storage
page space ~s satisfied by allocating space on a
preferred paging device,
provided that one
exists on the system and that it has page space
available.
Preferred
paging
devices
are
specified
by
the installation
at
system
generation time, and generally should be devices
on which excessive seek times do not occur. A
typical preferred paging device would be the lBK
2305 Fixed Head storage facility.
If the 2305
is assigned as a
preferred device, it is
possible to allocate some of its space for other
high priority data files without excessively
degrading paging.
An example pf such usage
would be for high activity read-only saved
system pages that are
not shared in real
storage, and high activity system residence
disks.
It is also possible to designate moveable
head DASD devices such as the 3330, 3340, 3350
and 2314/2319 Direct Access storage facilities
as preferred paging devices. The module(s) so
designated should not be
requiEed to seek
outside of a relatively narrow cylinder band
around the center of the paging areas.
It is
advisable to share the access arm of a moveable
head preferred paging device with only the
lowest usage data files.
on
If one or more preferred devices are defined
the system, CP allocates all of the page
DKKPAGIO handles all input/output requests for
virtual storage and spooling pages.
DKKPAGIO
constructs the necessary task blocks and channel
programs, expands the compressed slot addresses,
and maintains a queue of CPEXBLOKs for pages to
be moved.
Once the I/O scheduled by DKKPAGIO
completes, it unchains the CPEXBLOKs that have
been queued and calls DKKSTKCP to stack them for
execution. DKKPAGIO is entered by a GOTO from:
•
DKKPTRAN to
pages
read and
•
DMKRPA to read and
spool buffers
write virtual
write
virtual
storage
storage
In either case, all that needs to be passed
to DKKPAGIO is the address of the cortable entry
for the page that is to be moved, the address of
a swptable entry for the slot, a read or write
operation code, and the address of a CPEXBLOK
that is ·to be stacked for dispatching after the
I/O associated with the page has completed.
DKKPAGIO obtains an IOBLOK and builds a channel
program to do the necessary I/O, and uses the
device code that is part of the page address to
index into the system's owndlist and locate the
real device to which the I/O request should be
directed.
If the
device
is capable
of
rotational position sensing, the required sector
section 1. Introduction
81
is computed and a SET SECTOR command is inserted
into the
channel program.
The real
SIO
supervisor DMKIOSQR is then called to schedule
the operation on the proper device.
When
the
interruption for
the
paging
operation is processed hy
the primary I/O
interruption handler, the IOBLOK that controls
the operation is unstacked to the interruption
return address, waitpage, in DMKPAGIO. waitpage
then unchains the CPEXBLOKs that are queued to
DMKPAGG, and then stacks the queued CPEXBLOKs,
by calls to DMKSTKCP, in the order in which they
were received. The address of the real page
frame is filed into the appropriate page table
entry and the pointers denoting the ownership of
the real page frame are filed into the cortable
entry by the processing routines in DMKPTRAN.
If a fatal I/O error occurred for the related
page frame, the CPEXBLOKs associated with it are
flagged, and the dispatcher, DMKSDPCH, sets a
nonzero condition code when it activates the
pending task.
The error
recovery followed
depends on the operation being performed. Paging
I/O errors associated with spooling operations
are discussed in "DASD Errors During Spooling"
in this section, while errors associated with
virtual storage paging operations are discussed
later in section "Virtual storage Paging Error
Recovery".
DMKPAGIO
maintains its
own suhpool
of
preformatted paging IOBLOKs.
As I/O operations
complete, their IOBLOKs are added to a list of
availahle blocks; as new blocks are needed, they
are taken from this list.
If the list is empty,
DMKFREE is called to obtain storage for a new
block.
DMKPAGIO also periodically calculates
system paging overhead.
After 200 pages have
been moved
(read or written), the elapsed time
for the 200 page moves is computed, and the
paging rate is calculated in page moves per
second. The recent paging load, expressed as the
percentage of time that more than one half of
the system's pages were idle due to page-wait,
is
averaged with
the
previous load
and
re-projected as the expected load for the next
interval.
assigned to another virtual machine. All other
uncorrectable paging errors are hard because
they
more
drastically
affect
system
performance.
HARD ERROR RECOVERY: Hard paging errors occur on
eItber--ijo-errors- for page reads or upon of
exhausting the system's spooling and paging
space. Recovery attempted on hard errors depends
upon the nature of the task for which the read
was heing done. If the operation was an attempt
to place a page of a virtual machine's virtual
storage into real storage, the operation of that
particular virtual machine is terminated by
setting the page frame in error to zero and
placing the virtual machine in console function
mode. The user and operator are informed of the
condition, and the page frame causing the error
is not de-allocated, thereby ensuring that it is
not allocated to another user.
The control program
functions that call
DMKPTRAN
(such as spooling, pageahle control
program calls, and system directory management)
have the oFtion of requesting that unrecoverable
errors be returned to the caller. In this case,
the CP task may attempt some recovery to keep
the entire system from terminating
(ABEND). In
general, every attempt is made to at least allow
the operator to hring the system to orderly
shut-down if continued operation is impossible.
Proper installation planning should make the
occurrence of a space
exhaustion error an
exception. An unusually heavy user load and a
backed-up spooling file could cause this to
happen.
The operator is warned when 90% of the
temporary (paging/spooling) space in the system
is exhausted.
He should take immediate steps to
alleviate the shortage. possible remedies that
exist include preventing more users from logging
on and requesting users to stop output spooling
operations. More drastic measures might include
the purging of low priority spool files. If the
system's paging space is completely eXhausted,
the operation of virtual machines progressively
slows as more and
more users have paging
requests that cannot be satisfied and operator
intervention is required.
VIRTUAL STORAGE PAGING ERROR RECOVERY
VIRTUAL RELOCATION
Errors encountered during virtual storage
(as
opposed to spooling)
paging operations can
generally be classified as either soft or hard
errors. Soft errors allow the system to continue
operation without delay or degradation.
Hard
errors can cause noticeable effects such as the
abnormal termination of user tasks
(ABEND) and
response
degradation.
Errors
that
are
successfully retried or corrected are known only
to the I/O supervisor and the I/O error retry
and recording routines; they appear to the
second level interruption handlers (such as
waitpage) as if the original operation completed
normally.
SOFT ERROR RECOVERY: An I/O error that occurs on
a--page-swap=out--is considered to he a soft
error.
DMKPTRAH calls DMKPGTPG to assign a
different DASD page slot
and the page is
re-queued for output. The slot that caused the
error is not de-allocated, and thus is not
82
CP provides the virtual machine the capahility
of
using the
DAT
feature
of the
real
System/370. Programming simulation and hardware
features are comhined to allow usage of all of
the available features in the real hardware,
(that is, 2K or 4K pages, 64K or 1M segments).
For clarification,
follow:
some
fi~2!=!~Y~!
term
definitions
2!Q~!g~:
The physical storage
the real CPU, in which CP resides.
Second-level 2!Q~!~~:
avaIlable-to any virtual
of
The virtual
storage
machine, maintained by
CPo
1hi!~=1~Y~1 §!9~g9~:
defined by the system
IBM VM/370: System Logic and Prohlem Determination Guide
The virtual storage space
operating in second-level
storage, under control of page and segment
tables which reside in second-level storage.
E~g~
~~g
§~g!~~!
!~~1~§:
Logical mapping
between first-level and second-level storage.
!i~!~~l
E~g~
mapping between
storage.
~ng
§~g!~B!
second-level
§h~g2! Egg~ ~Bg §~g!~B! !~E!~2:
between first-level
storage.
storage
!g~l~§:
and
Logical
third-level
Logical mapping
and third-level
A standard, nonrelocating virtual machine in
CP is provided with a single control register,
control register zero that can be used for:
•
•
•
Extended masking of external interruptions
Special interruption traps for SSM
Enabling of virtual block multiplexing
A virtual machine that is allowed to use the
extended control
feature of
System/370 is
provided with a full complement of 16 control
registers, allowing virtual monitor calls, PER,
extended channel masking, and dynamic address
translation.
An extension to the normal virtual-machine
VMBLOK is built at the time that an extended
control virtual machine logs onto CPo This
ECBLOK
contains
the
16
virtual
control
registers, 2 shadow
control registers, and
several words of information for maintenance of
the shadow tables, virtual CPU timer, virtual
TOD clock comparator, and virtual PER event
data.
The majority of
the processing for
virtual address translation is performed by the
module DMKVAT, with
additional routines in
DMKPRG, DMKPRV, DMKDSP, DMKCDB, DMKLOG, DMKUSO,
and
DMKPTR.
The
simulation
of
the
relocation-control instructions (that is, LCTL,
STCTL, PTLB, RRB, and LARA)
is performed by
DMKPRV. These instructions, with the exception
of LCTL and STCTL, are not available to virtual
machines which are not allowed the extended
control mode.
When an extended control virtual machine is
first active, it has only the real page and
segment tables provided for
it by CP and
operates entirely
in second-level
storage.
DMKPRV examines each PSW loaded via LPSW to
determine when the virtual machine enters or
leaves extended control
or translate mode,
setting the
appropriate flag bits
in the
VMBLOK.
Flag hits are also set whenever the
virtual machine modifies control registers 0 or
1, the registers that
control the dynamic
address
translation
feature.
DMKDSP
also
examines PSWs that are loaded as the result of
interruptions to determine any changes in the
virtual machine's operating mode. The virtual
machine can load or store any of the control
registers, enter or leave extended control mode,
take interruptions, etc., without invoking the
address translation feature.
If the virtual machine, already in extended
control mode, turns on the translate hit in the
BC mode PSi, then the DMKVATMD routine is called
to examine the virtual control registers and
build the required shadow tables. (Shadow tables
are required because the real DAT hardware is
capable of only a first-level storage mapping.)
D!KV1TMD examines virtual control registers 0
and 1 to determine
if they contain valid
information for use in constructing the shadow
tables.
Control register zero specifies the
size of the page and segment the virtual machine
is using in the virtual page and seg.ent tables.
The shadow tables constructed by DMKV1TMD are
always in the sa.e
for. at as the virtual
tables.
The shadow seg.ent table is constructed in
first-level storage and initialized to indicate
that all segments are unavailable. Flags are
maintained in the VMBLOK to indicate that the
shadow tables exist. DMKVATMD also constructs
the shadow control registers 0 and 1. Shadow
control
register 0
contains the
external
interruption mask bits used by CP, mixed with
the hardware controls and enabling bits from
virtual control register O.
Shadow control
register 1 contains the segment table origin
address of the shadow segment table.
When the virtual machine is operating in
virtual translate mode, CP loads the shadow
control
registers
into the
real
control
registers
and
dispatches the
user.
The
immediate result of attempting to execute an
instruction is a segment exception, intercepted
hy DMKPRG and passed to DMKVATSX.
DMKV1TSI
examines
the
virtual
seg.ent
table
in
second-level storage. If the virtual segment is
not
available,
the
segment
exception
interruption
is reflected
to the
virtual
machine.
If the virtual segment is marked
available, then DMKV1TSX:
•
Allocates one full segment of shadow page
table, in the format specified by virtual
control register o.
•
page table
Sets all of the
indicate page not in storage.
•
Marks the segment
segment table.
•
Redispatches the virtual machine via DMKDSP.
available
entries
in the
to
shadow
Once again, the immediate
result is an
interruption, which is a paging exception and
control
is passed
to DMKVATPI.
DMKVATPI
references
the
virtual
page
table
in
second-level storage to determine if the virtual
page is available. If the virtual page is not
available, the paging interruption is reflected
to the virtual machine.
However, if the virtual
page is marked in storage, the virtual page
table
entry
determines
which
page
of
second-level storage is being referenced by the
third-level storage address provided. DMKVATPX
next determines if that page of second-level
storage is resident in first-level storage at
that time. If so, the appropriate entry in the
shadow page table is filled in and marked in
storage. If not, the required page is hrought
into first level storage via DMKPTRAN and the
shadow page table filled in as above.
As the virtual machine continues execution,
more shadow tables are filled in or allocated as
the
third-level
storage
locations
are
referenced.
Whenever
a
new
segment
is
referenced, another segment
of shadow page
Section 1. Introduction
83
tables is allocated.
Whenever a new page is
referenced, the appropriate shadow page table
entry is validated, etc. No changes are made in
the shadow tables if the virtual machine leaves
translate mode (usually via an interruption),
unless it also leaves extended control mode.
Dropping out of EC mode is the signal for CP to
release all of the shadow page and segment
tables and the copy of the virtual segment
table.
There are
some situations
that require
invalidating
all
of
the
shadow
tables
constructed by
CP or
even releasing
and
reallocating thea. Whenever DMKPTR swaps out a
page that belongs to
a virtual relocating
machine, it sets a bit in the VMBLOK indicating
that all of the shadow page tables must be
invalidated. Invalidation of all of the tables
is required since CP
does not know which
third-level
storage
pages
map
into
the
second-level page that is being swapped out.
The actual invalidation is handled by DMKVATAB,
called from DMKDSP when the virtual machine is
on the verge of being dispatched.
The other situations which cause shadow table
invalidation arise
from the
simulation of
privileged instructions in DMKPRV. Flags are
set in the VMBLOK whenever the virtual machine
loads either control register 0 or 1, and DMKPRV
calls DMKVATAB to perform whatever maintenance
is required. When control register 1 is loaded
by the virtual machine,
DMKVATAB must re-copy
the virtual segment
table into first-level
storage and invalidate the entire shadow segment
table. When control register
0 is loaded,
DMKVATAB examines the relocation-architecture
control bits to determine if they have changed,
(such that the format of the virtual page and
segment tables no longer matches that of the
shadow tables).
If the format has not changed,
the shadow tables are left intact; otherwise,
all of the shadow tables must be returned to
free storage and another set, in the new format,
must be allocated and initialized. The same
actions can result from modifying the control
registers via the CP console functions, in which
case DMKVATAB is called
from DMKCDB.
The
privileged operation, PTLB
also causes the
virtual segment tables to be re-copied and all
of the shadow page tables to be invalidated
because the shadow tables
are the logical
equivalent
of
the
translation
look-aside
buffer.
DMKPRV provides virtual interrogation of the
reference and change bits in the virtual storage
keys, which involve the privileged instructions
ISK, SSK,
and RRB. The privileged instruction
LRA is simulated via DMKVATLA, which searches
the virtual page and segment tables to translate
a third-level storage address to a second-level
storage address, returning a condition code
indicator to DMKPRV, or forcing an interruption
if the tables are incorrectly formatted.
control registers are set valid, with the shadow
segment table re-allocated at a minimum size and
all segments marked unavailable.
Flag bits are
set in the VMBLOK to indicate that the shadow
tables are artificially valid,
and DMKVATSX
reflects a translation specification exception
to the virtual machine as
soon as it is
dispatched.
While it is
possible for the
virtual machine to enter an interruption loop
(if the new PSW is also a translate mode PSW),
the cited process prevents the occurrence of a
disabled loop within CP, which would result if
the virtual machine is never dispatched.
FREE STORAGE MANAGEMENT
DMKPRE is responsible for the management of free
storage, and CP uses it to obtain free storage
for I/O tasks, CCW strings, various I/O buffers,
etc. It is used, in fact, for practically all
such applications except real channel, control
unit, and device blocks, and the cortable.
Block sizes of 30
doublewords or less,
constituting about 99 per cent of all calls for
free storage, are grouped into 10 subpool sizes
(3 doublewords each), and are handled by LIFO
(push-down stack) logic. Blocks of greater than
30 doublewords are strung off a chained list in
the classic manner.
When subpools are
exhausted, small size
blocks are generally obtained from the first
larger sized block at the end of available free
storage. Large size blocks, on the other hand,
are obtained from the high-numbered end of the
last larger block. This procedure tends to keep
the volatile small subpool blocks separated from
the large blocks, some of which stay in storage
for much longer periods of time; thus, undue
fragmenting of available stor.age is avoided.
DMKPRE initially starts without any subpool
blocks.
They are obtained from DMKFREE and
returned to DMKFRET on a demand basis.
The various cases of calls to DMKFREE for
obtaining free storage, or
to DMKFRET for
returning it, for subpool sizes and large sizes,
are handled as follows:
~Y~~~~l !!gilgBl~:
If a call for a sub pool is
made and a block of the suitable size is
available, the block found is detached from the
chain, the chain patched to the next sub pool
block of the same size (if any), and the given
block returned to the caller.
~Y~~~~l !~!
Most error situations that occur in the
virtual machine are handled by means of the
extended program interruptions associated with
the real address translation hardware. Whenever
a virtual relocating
machine loads control
registers 0 or 1 with an invalid value, DMKVAT
releases all of the shadow tables exactly as if
the hardware controls had changed. The shadow
84
Available: If a block of suitable
size is not avaIlable-when a call to DMKFREE is
made for a subpool, the chained list of free
storage is searched for a block of equal or
larger size. The first block of larger or equal
storage is
used to satisfy the
call
(an
equal-size block taking priority), except that
blocks within the dynamic
paging area are
avoided if at all possible. If no equal or
IBM VM/370: system Logic and Problem Determination Guide
larger block is found, all the subpool blocks
currently not in use are returned to the main
free storage chain, and then the free storage
chain is again searched for a block large enough
to satisfy the call. If there still is no block
large enough to satisfy
the request, then
DMKPTRFR is called to obtain another page frame
of storage from the dynamic paging area, and the
process is repeated to obtain the needed block.
If a call to DMKFREE is made for a block larger
than 30 doublewords, the chained list of free
storage is searched for a block of equal or
larger size. If an equal size block is found, it
is detached from the chain and given to the
caller. If at least one larger block is found
the desired block size is split off the high
numbered end of the last larger block found, and
given to the caller. If no equal or larger block
is found, DMKPTRFR is called to obtain another
page frame of storage from the dynamic paging
area, and the above process is repeated
(as
necessary) to obtain the needed block.
If a subpool block is g~ven back via a call to
DMKFRET,
the
block ~s
attached
to
the
appropriate subpool chain on a LIFO (push-down
stack) basis, and return is made to the caller.
If, however, the block was in a page within the
dynamic paging area, the block is returned to
the regular free storage chain instead.
CP INITIALIZATION
System initialization starts when the operator
selects the DASD device address of CP system's
residence volume (SISRBS) and presses the IPL
button. The System/370 hardware reads 24 bytes
from record 1 of cylinder 0 on SISRES into
location 0 of main storage. This record consists
of an initial PSW and a channel program. The
channel program reads the module DMKCKP into
location X'800' and gives it control. DftKCKP
checks location CPID in module DftKPSA.
If CPID contains the value CPCP or WARft,
DftKCKP saves the spool file control blocks,
system log messages, accounting information,
status of spool devices,
spool hold queue
blocks, and spool record allocation blocks and
writes them on the warm start cylinders.
If
CPID contains the value CPCP, DftKCKP loads a
disabled wait state code X'008'.
If location CPID does not contain the value
CPCP, DftKCKP now loads DftKSAV and passes control
to it at entry point DftKSAVRS. DMKSAV reloads a
page image copy of the CP nucleus into real
storage starting at page O. When DftKSAV is
finished, control is transferred to DftKCPI.
DftKCPI
performs
the
main
initialization
function.
This includes
calling DftKWRft to
retrieve the information stored on the warm
start cylinder.
This also includes calling
DftKCKS to initialize the dynamic checkpoint
cylinders and to checkpoint the current status
of the spool file system.
When DftKCPL has
finished,
it passes
control to
DftKDSPCB.
DftKDSPCB loads a wait state PSW to wait for
work.
INITIALIZATION AND TBRftINATION
If a block larger
than 30 doublewords is
returned via DftKFRET, it is merged appropriately
into the regular free storage chain.
Then,
unless the block was returned by DftKFRBTR (see
"Initialization") a check is made to see if the
area given back
(after all merging has been
done) is a page frame within the dynamic paging
area. If so, it is DftKPTRFT returns it to the
dynamic paging area for subsequent use.
After CP has been initialized, DMKCPVBN enables
the communication lines. Then an individual
virtual machine is attached to the system using
the following steps:
1.
The number of page frames allocated to free
storage depends upon the number of storage boxes
upon which
the Vft/370 control
program is
running, and is initialized by DftKCPINT (3 pages
for the first 256K and 1 page for each 64K
thereafter not including V=R size if any).
DftKFRETR is
called by
DftKCPINT to
merge
available blocks of storage into the regular
free storage chain regardless of their size.
1!~!!n~1_lg~~I!~!~~lion
When the CP receives the initial interrupt
from a
terminal on
an enabled
line
(normally initiated by a user dialing in on
a data-set),
the DftKCNSIN
routine is
entered. DftKCBSIB determines the terminal
device type, stores this information in the
terminal device block, writes the online
message and puts the terminal line in a
state
to
receive
an
attention
interruption.
2.
At!~~!ioA_~~~~_Q§~~
After the online message has been typed at
the user's terminal, and he has pressed the
ATTENTION
key,
D!KCISIB
(the
console-interruption
routine)
calls
DftKBLDVft to build a skeleton v.blok for the
user.
At
this time,
the userid
is
section 1. Introduction
85
LOGONxxx, where xxx is the terminal real
device address, and a flag is set to
indicate that
the user
has not
yet
completed the LOGON process.
•
Allocates and initializes virtual device
blocks, control unit blocks, and channel
blocks, using information from the user
device blocks portion of the directory.
Then D~KCNSIN calls DMKCF~BK, which types a
single blank at the terminal, and issues a
read to the terminal for the user to enter
his first
command
(normally
LOGON or
DIAL) •
•
Establishes links (as feasibl~
to all
DASD devices included in the directory,
the accessibility of any disk being
determined by the user access mode in
the
directory, and whether any other
user(s)
are presently linked to the
disk, in read-mode and/or write-mode.
After the first command has been entered by
the user,
DMKCNSIN further determines the
type of terminal.
If the terminal is a
2741, DMKTRMID is called to identify it as
either a 2741P
(PTTC/EBCD)
or a 2741C
(Correspondence) terminal.
If successful,
the correct device
type and translate
tables for input and output are set; if
not, flags are set to indicate the terminal
is not yet identified.
•
Initializes all other virtual device
blocks as appropriate, such as reader,
punch, printer, and terminal.
•
Kaps
all
devices.
•
Performs appropriate accounting.
•
Informs the user of the date and time of
the most recent revision to the system
log
message
(LOGMSG),
and of
the
presence of any
outstanding spooled
files in his virtual reader, printer, or
punch.
•
Sends a ready message to the user with
the date and time (and weekday), and a
message
to
the
system
operator
indicating that the user has logged on.
3.
Then control is returned to DMKCFMBK, which
determines if the first command is valid
(for example, LOGON, ~SG, or DIAL). If the
first command is not valid,
a restart
message is given, and the read to the
terminal
occurs again
for the
first
command. If the first command was LOGON
(or its abbreviation), DMKLOGON is called
to complete the process of attaching the
virtual machine to the system.
The
operations performed
include the following:
86
by
DMKLOGON
•
Ensures that the
maximum
virtual machines allowed on
is not being exceeded.
•
Obtains the userid from the command
line, and checks for a possible password
and other optional operands.
number of
the system
•
Checks the userid and password (entered
separately if not on the LOGON command
line) against entries in CP's directory
of users.
•
Ensures that the user is not logged on
at
another
terminal
(an
error
condition), or reconnects the user if he
was running, in the disconnect mode.
•
Obtains pertinent information on the
user's virtual ~achine from the user
machine block portion of the directory.
•
Stores the correct userid (replacing the
LOGONxxx userid used until now), virtual
storage
size,
and
other
vital
information in the virtual machine's
VKBLOK.
•
Allocates and initializes segment, page,
and swap tables
(necessary for handling
of
the
virtual
machine's
virtual
storage).
•
Allocates an extended VKBLOK (ECBLOK) if
the user's virtual
machine has the
ability to run in the extended control
mode.
virtual
devices
to
real
If the virtual machine has a device address
or a named system in the directory and the
initialization was not suppressed via an option
on the LOGON command line, then that device or
named system is then loaded (via IPL) at the
conclusion of the LOGON process.
Otherwise,
when the LOGON functions are complete, the
user's terminal is placed in CP read mode ready
for the entry of his first desired command.
Under the latter condition of no automatic
1PL, the user can IPL an alternate nucleus by
using the STOP option in the IPL command. This
option causes the normal IPL procedure to halt
execution prior to loading the initial PSi, and
issues a DIAGNOSE Code 8 that places the user's
terminal in
CP read mode.
A hexadecimal
character entered in location X'08' changes the
nucleus name.
A hexadecimal character entered
in location X'09' changes the apparent storage
size.
The
BEGIN command
allows the
IFL
procedure to continue.
Three commands alter the I/O configuration of a
user's virtual machine after he has logged on.
Two are user commands, while the third a system
operator command, because it affects the status
of real devices attached to the system.
The
ATTACH and DETACH commands are contained in
DKKVDB and DEFINE in DKKDEF. The system command
scanner
(DKKCFM)
calls both page able modules
after their format and privilege classes have
been validated. These commands access the same
control-block building subroutines in the module
DKKVDS that DMKLOG, the LOGON processor, uses.
IBK VK/370: System Logic and Problem Determination Guide
A!!~£hjB~ ~ S~~l R~!!£~:
The system operator can
dedicate any real device to a single virtual
machine by issuing the ATTACH command.
The
device attached is available only to the given
virtual machine, and all I/O requests to it are
handled by CCi translation. If the device is a
DASD, cylinder relocation does not occur when
SEEK addresses or home addresses are referenced.
The I/O supervisor does not queue operations on
the device, nor does it automatically restart it
or do
ordered seek
queueing.
Nonsharable
devices such as tape drives must be attached to
a virtual machine to be accessed by the virtual
machine.
A virtual machine can also have a
dedicated card read/punch or printer. However,
this is usually not necessary because of the
unit record spooling facilities of CPo
Unit
record input or output on a dedicated (attached)
device is not spooled by CPo The unit attached
may be given a different virtual address than
its real address; however, the virtual machine
may not already have a virtual device at the
attached address.
A real device cannot be
attached
(1) if it is currently dedicated to
another virtual machine, (2)
if it contains
mini-disks that are in use by other virtual
machines, or (3) if it is a system owned volume
that is in use for spooling or paging.
~~!!B!n~
~ !!~!Y~l
Device: A system user can
define a new virtuaI--device with the DEFINE
command that does not require the dedication of
a corresponding real device. Devices that can
be defined
are consoles,
spooled readers,
punches and printers, dialable TP lines, virtual
channel-to-channel adapters, pseudo timers, and
temporary disks.
With the DEFINE command, the
user can change any existing virtual device
address whether it corresponds to a shared or
dedicated real device or no real device unit.
The DEFINE command also describe the virtual
machine channel mode of operation, that is,
either selector or
block multiplexer.
The
default mode, selector channel mode, reflects a
channel busy to any SIO operation attempted on
the same channel path that has not completed the
previous
channel
SIO
operation.
Block
multiplexer
mode
allows
the
successful
initiation of different devices on the same
channel path.
Channel 0, a byte-multiplexer
channel, is unaffected by the DEFINE command.
Also, any channel with a channel-to-channel
adapter
(CTCA) defaults to selector mode of
operation
regardless of
the channel
mode
selected. Use of the DEFINE command with the
CHANNELS operand generates a virtual machine
reset; therefore, it should be invoked prior to
the virtual machine IPL operation.
Note: The channel mode selected has no bearing
on the types of channels that are attached to
the real system.
Temporary disks are
dynamically obtained
cylinders of DASD storage
space. They are
available to the user for as long as they are
part of his virtual machine configuration, but
the data on them is destroyed after the user
detaches the area. For all other purposes,
however, they appear to be a standard disk.
R~!!£h!~ ~ !!!!Y~! R~!!£~: A virtual device can
be removed fro. a virtual machine configuration
prior to logging off with the DETACH co •• and. A
user can detach any of his own devices, and the
system operator can detach a real device fro. a
virtual machine.
If the operator detaches the
device, the user is informed of the operator's
action. A real device can be detached only if it
is dedicated to a single virtual .achine or is
attached to the system and is not in use when
the DETACH is issued.
A user may permanently or temporarily disconnect
bis ter.inal or virtual machine from the system
by a console command, or the terminal or virtual
macbine may be forcibly disconnected by the
operator.
The system can also log off the
virtual machine. In any case, the routines that
handle the termination process
are in the
pageable module, DMKUSO.
PERMANENT DISCONNECT: The user may voluntarily
reiove-hIs--vIrtual-machine from the system via
the LOGOFF command. This command terminates all
virtual machine operation, releases all storage
occupied by control blocks and virtual storage
pages, and disconnects the teleprocessing line
connection to the user's terminal. If the user
specifies the HOLD option with LOGOFF, all of
the above occurs, except the teleprocessing line
remains enabled. This
option is especially
useful for dialed connections that are reused
immediately by another user.
The virtual machine can be forced off the
system by the system operator via the FORCE
command.
This
has the same effect
as a
user-initiated logoff, except that the user is
informed that the operator has logged off his
machine.
A virtual machine may also be logged
off the system:
•
If the time for a read of
expires (28 seconds).
a system password
•
If the user makes a connection to the system
but does not logon within a given period.
•
If
the
virtual
machine
is
running
disconnected (without an active terminal) and
tbe virtual machine attempts a terminal read
or enters a disabled wait state.
The DMKUSOLG and D~KUSOFF subroutines process
the LOGOFF command.
DMKDSP calls DMKUSOFF
directly by DMKDSP to force the logoff of a
disconnected user as previously described.
~~~gQ~A~I
~l~~Q!!~~!:
A user may temporarily
disconnect his terminal from his virtual machine
by using the DISCONN command, while allowing the
virtual machine to continue
to run.
This
command flags the virtual machine as being
disconnected and releases the user's terminal
and teleprocessing line. If the HOLD option was
specified in the DISCONN command, CP allows the
line to remain enabled, and another user can use
the terminal to log
on.
The disconnected
virtual machine continues to be dispatched until
Section 1. Introduction
81
it either attempts to execute a terminal read to
the disconnected console or it enters a disabled
wait state.
At this
time, the dispatcher
(DMKDSF) calls the routine DMKUSOll directly to
force the machine out of the system. While the
machine is disconnected from its virtual console
(real terminal) any terminal output is lost; in
addition, CP may apply a disconnected penalty to
the machines scheduling priority, to bias the
system in favor of interactive users.
A user's
virtual machine
may also
be
di5connected by the system. If the disconnected
user
logs on
to
the
system while
his
disconnected machine is still running he is
reconnected and can continue to interact with
th~ system in the usual manner.
The DMKUSO
command.
subroutine
processes
the
DISCONN
DftKCFM then calls the
process the command.
appropriate routine
to
After the command has been processed, control
is returned to DMKCFM. There are three possible
returns.
(1)
On a normal return, the input
buffer is scanned to see if there are any more
commands. If none exist, DMKCFft returns to the
virtual machine (if entered via DIAGNOSE)
or
calls DftKQCNRD to read the next command from the
terminal. (2) On a return plus 4, the VMCFWAIT
bit is turned off to allow the virtual machine
to run.
DMKFRET is called to return the input
buffer storage. Then control returns to either
the virtual machine, if entered via a DIAGNOSE
or to DftKDSPCH if entered via the ATTENTION key.
(3) On
a return plus 8, the operation is the
same as plus 4 except the VMCFWAIT bit is left
on.
DISPATCHING AND SCHEDULING
CONSOLE FUNCTICNS
CMKCFM analyzes CP commands and passes control
to the
appropriate routine to
handle the
command. DMKC1M can be entered by the ATTENTION
key at the user's terminal or directly from a
virtual machine.
When a console interruption occurs by the
ATTENTION key at the user's terminal, DMKIOSIN
calls
DMKCNSIN to
handle the
unsolicited
interruption, then DMKCNSIN calls DMKCFMBK.
DMKCFMBK first
calls DMKFREE
to obtain
storage for an 18 doubleword input buffer. Next,
DMKQCNiT is called to send the CP message to the
terminal to inform the user that he has entered
console function mode. DMKQCHRD is then called
to read
the command line entered
at the
console.
DMKCFMEN is the entry point for commands
coming directly
from the
virtual machine.
DMKPRGIN enters at DMKCFMEN here when a DIAGNOSE
instruction with a code of 8 is detected. The
address of an
18 double word input buffer is
passed in register 1; therefore, a read to the
terminal is not needed.
After either the read to the terminal or
entry from the virtual machine,
DMKSCNFD is
called to find the command type. On return from
DMKSCNFD, register 1 points to the start of the
command and register 0 contains the length of
the command. The entered command is matched
against a list of valid commands. The list
contains a 16-byte entry for each command. Each
entry contains 8 bytes for the name, 2 bytes for
class mask, 2 bytes for an abbreviation count,
and 4 bytes containing the routine address. If
the entered command matches an entry in the
list, it is then checked to ensure that a valid
abbreviation for the command has been used. If
this test is not successful, DMKSCN continues to
scan the list for a valid command. Should the
abbreviation be valid, a check is then made to
determine if this user is of the proper class to
use the command entered. If this is successful,
88
The scheduler, DMKSCH,
selects dispatchable
virtual machines
from the
virtual machine
population. The auxiliary routine that assists
the scheduler and dispatcher is the request
stack maintenance routine, DMKSTK.
To
make
decisions on
dispatching
and
scheduling, the control
program places all
virtual machines into various categories, and
recognizes user machines as being in one of
several states. The virtual machine categories
either interactive or non-interactive virtual
machine, are defined in the following way:
•
An interactive virtual machine is one whose
use of the system is punctuated by regular
and frequent termina1.I/0, and does not have
long CPU execution times.
A virtual machine
becomes eligible to enter interactive status
whenever a
channel program
for virtual
console I/O has completed, or whenever I/O
for
a
dedicated
or
~ia1ed
virtual
telecommunications line has completed.
•
A non-interactive virtual machine is one that
has violated an interactive criterion, or one
that has entered an idle wait state by
entering console function mode (equivalent to
stopped state), or by loading a wait state
PSi that
is not enabled for
any busy
channel.
CP schedules
interactive users
ahead
of
non-interactive
users.
Non-interactive users are subdivided into
several
classes.
Normal
non-interactive
virtual machines are scheduled by a priority
scheme described below. A virtual machine is
allowed to execute for a specified time
period and then it is placed in a list of
those machines that are waiting.
To give preference to certain classes of
virtual machines, a priority scheduling scheme
allows virtual machines to be SCheduled with a
priority class.
The priority is
a number
assigned by the directory; however, the number
may be altered by the system operator.
IBM VM/370: System Logic and Problem Determination Guide
To efficiently manage the large inventory of
potential virtual machines that are logged on to
the system, CP defines several states that a
virtual machine may occupy.
The scheduler can
move a virtual machine
from one state to
another; however, a virtual machine may exist in
only one state at any given instant.
CP can
then make scheduling and dispatching decisions
by looking only at
the subset of virtual
machines that are in the appropriate state. To
do this search, it also maintains lists of
virtual machines in certain executable states.
A user's virtual machine may be in one of the
following states:
--,-state
2
3
4
5
6
7
8
1.
The virtual machine's prOjected working set
size, calculated the last time it was
dropped from a queue, is expressed as a
percentage of the amount of main storage
available for paging.
This percentage,
usually between 0 and 100, is multiplied by
the
paging
bias
factor
(stored
at
DMKSCBPB).
2.
The
virtual
machine's
priority
(the
priority set by the directory or the class
A SET PRIORITY command)
is multiplied by
the user bias factor
(stored at DMKSCHUB),
and is added to the paging bias calculated
in step 1.
3.
The sum of paging and user bias is divided
by the sum of the bias factors to obtain a
weighted average.
4.
A base priority is obtained by storing the
TOD clock and using the high order word,
which increments by 1 approximately once
per second.
This word is then modified by
shifting it left or right based on the
priority delay factor (stored at DMKSCHPD).
If DMKSCBPD is positive, it indicates a
right shift,
thereby increasing the delay
interval of the base priority.
A negative
value indicates a left shift.
5.
The weighted average obtained in step 3 is
then logically added to the adjusted base
obtained in step 4.
6.
If the virtual machine is entering 02 for
the first time after being dropped from 01,
the interactive bias factor
(stored at
D"KSCBIB) is subtracted from the priority
obtained in step 5. If the virtual machine
is entering Ql,
or if it was last dropped
from Q2, the interactive
bias is not
applied.
7.
The result of steps 1 through 6 is the
scheduling or eligible list priority, and
is stored in the V"EPRIOR field of the
V"BLOK.
~g~ning
Interactive and dispatchable (in queuel,
in dispatch list)
Interactive and not dispatchable
(in
queuel, not in dispatch list)
Interactive and eligible for queuel, but
queuel is full (waiting for queuel, in
eligible list)
In wait state with terminal read or
write active
Hon-interactive and
dispatchable
(in
queue2, in dispatch list)
Hon-interactive and not dispatchable (in
queue2, not in dispatch list)
Hon-interactive and eligible for queue2,
but queue2
is full
(waiting for
queue2, in eligible list)
Idle waiting for asynchronous I/O or
external interruption, or stopped (in
console function mode)
Entries on the dispatch list are the VMBLOKS
for those virtual machines in states 1 and 5,
and represent the virtual machines that can be
run at any given time.
The dispatch list is
sorted by dispatching priority, which is the
ratio of CPU time to wait time over the length
of the current virtual machine task. A task is
defined as that execution that takes place
between terminal reads or entry to enabled wait
(that is, movement from state 4 or 8 to state 1)
and is re-projected for a virtual machine each
time it is dropped from a queue.
Virtual
machines entering state 1 always have a priority
of O.
The eligible list are virtual machines in
states 3 and 7; these virtual machines are
potentially executable but due to the current
load on the system they are not allowed to
compete for the CPU.
As soon as a virtual
machine in the dispatch list is dropped from
queue, the highest priority virtual machine(s)
in the eligible list is added to the dispatch
list. Conditions can arise where the virtual
machine that is added to the DISPATCH list bas a
projected working set size that far exceeds the
remaining system capacity.
The eligible list
has two components; a section composed of those
virtual machines waiting for 01
(interactive)
and a section composed of those virtual machines
waiting for 02
(non-interactive). Each section
of the list is sorted by scheduling priority,
which is determined at the time the virtual
machine is added to the eligible list, as
follows:
The
VBBLOK
is then
sorted
into
the
appropriate section of the eligible list in
ascending value of VMEPRIOR.
The effects of the
various biases
and the
delay factor
are
illustrated by the following examples.
~~~~~lg
1
Assume that two virtual machines are to be
added to the eligible list for Q2.
The
paging bias factor is 1, the user bias
factor is 1, and the priority delay factor
is o.
Virtual machine A has a projected
working set size of 80 percent of available
storage and a user priority of 50.
Virtual
machine B has a projected working set size
of 20 percent of available storage and also
has a user priority of 50. The biases are
obtained as follows:
Paging
Bias
80-i-,
20 I
1
Dser
Bias
+ 50-i-'
+ 50 X 1
Weighted
Bias
130/2----65
35
70/2
Section 1. Introduction
89
If A is added to the eligible list at base
time 0, its eligible list priority witll be
65. If the priority delay factor is 0, B
is added ~~~~~ of A provided that B is
eligible for entry to the list within the
next (65-35)
30 seconds. If the priority
delay factor is set to +1, the base is
incremented
once
every
two
seconds.
Therefore, although the bias difference is
still 30,
the delay time is
now 60
seconds.
2. The virtual machine priority value, in
the directory, may be overridden, and
is the means through which selected
users obtain improved performance.
~!~m£!~ ~
4. The interactive bias factor is a tool
that enhances command
response to
conversational commands that require
disk I/O, and that may be partially
executed in Q2.
To force A to be given
equal to B, a priority
calculated as follows:
80 + A
20 + B
2
2
=B
1
a weighted bias
differential is
60
-
Therefore, for the biases to be equal, A
must have a priority of 60 less than B.
For example, if 1 is given a priority of 10
and B is given a priority of 70, the biases
wuuld compute as follows:
Paging
Bias
80-i-,
+
User
Bias
,o-i-,
90/2
90/2
20 X 1 + 70 X 1
Weighted
Bias
--45---= 45
3.
The priority delay
factor is the
measure of the impact that the paging
and user biases are to have.
The
greater the delay value, the greater
1S
the maximum delay that can be
experienced by a given user.
If the paging bias factor is nonzero, the net
effect of the priority scheme is to discriminate
against virtual machines that require large
amounts of real storage. This discrimination
results in a higher level of multiprogramming
and increased CPU utilization;
however, it must
be traded off against poorer throughput for
large storage users.
The distributed scheduler
is ~Q! biased; the bias factors are as follows:
Paging bias factor
(DMKSCHPB)
User bias factor
(DMKSCHUB)
Priority delay factor
(DMKSCHPD)
Interactive bias factor (DMKSCHIB)
o
1
o
o
Thus, the basic
VM/370 scheduler schedules
virtual machines FIFO within user priority.
~!~m£!~
J
The large difference in priorities could te
lessened by
increasing the
user bias
factor.
If the user bias factor is set to
3 instead of 1, the calculated priority
differential is as follows:
80 + 31
20 + 3B
4
4
3 (B -
I)
1
,.------------------,
60
B -
20
HOW, 1 requires a priority
then B to achieve parity.
Paging
Bias
80-i-,
User
Bias
of only 20 less
For example:
30-i-3
17 0/4
20 X 1 + 50 X 3
170/4
+
weighted
Bias
--4"2----
1 In-Oueue
1 Rot-in-Queue 1
1--------------1
IDispatch 1 Ro IEligible 1 Ro 1
1 List
IListl List
IListl
r-------·--.l-------------I
1Interacti ve I
1
I 2 1
3
I 4 1
1------------------------1
IRon-Inter- 1
1
1
1
1
1
5
1 6 1
7
1 8 1
1 active
'-------------------_._---------'
Figure 17.
User Dispatching states
42
The above examples illustrate the following
general points about the use of the bias
factors, the delay factor, and the user
priority value:
1. The paging and user bias factors are a
measure of the relative importance of
the bias value. A high user bias
allows greater discrimination via the
assigned priority; while a high paging
bias makes storage requirement the
primary scheduling parameter.
90
Figure 17 is a graphic breakdown of the user
states,
showing
the
relationship
between
interactive and non-interactive states, in-queue
and
not-in-queue states,
and in-list
and
not-in-list states.
Figure 18 shows the possible user-state changes
and the reasons for them; any changes not
described are not possible.
To control the number
of virtual machines
allowed in queue, the scheduler monitors the
paging activity of all virtual machines and of
IBM VM/370: System Logic and Problem Determination Guide
---------------------,1
r
1
Status
Change
1
1
1---------1
1 From 1 To
1
Reason for Status Change
---------------------------2
Pagewait, SIO-WAIT,
1
1
2
2
3
4
4
5
5
5
5
5
6
7
8
1
1
1
or enabled
wait for any busy channel
4
Enabled wait for
interactive
terminal read or write
5
Exceeds in-queue time slice
7
Same as 1 to 5 except
that
queue 2 is full
8
Wait without active I/O, disabled WAIT or hit ATTN
1
Wait condition complete
5,7 Wait
completes, but in-queue
time slice exceeded
Another user drops from queuel
and now there is room
Terminal I/O completes
while
user is waiting
3
Terminal
I/O
completes, but
queuel is full
Terminal I/O completes
while
user is active in queue2
4
User puts up terminal read or
write and enters wait
6
Pagewait, SIO-WAIT, or enabled
wait for busy channel
7
Dropped
from
queue2 due to
in-queue time-slice end
8
Wait without
active I/O, disabled WAIT, or hit ATTN
5
wait condition completes
5
Room is found in queue2
5,7 IAsynchronous
I/O or external
1 interruption or BEGIN
Figure 18.
User Status Changes
the total system.
A decision as to whether or
not to move a potential virtual machine from the
eligible to the dispatch list is based upon
whether or not that its projected working set
exceeds
the
system's
remaining
capacity.
Individual virtual machine's working sets are
calculated and projected at queue drop time
according to one of the following formulas:
lA
last actual working set
lP
last projected working set
P
Current projected working set
The actual working set, A, is the smaller of the
two values determimined at queue drop time by
the following formula:
N
L
r
(P-A)
PRi
/
• + Steals
i= 1
A
-- or -Pages referenced
N
Number of page reads while in queue.
PR
Number of pages resident
page read.
Steals
Number of times page wait was entered
because of a stolen page.
at the
ith
The number of referenced pages is determined by
scanning the virtual machine's page tables for
software referenced bits. These bits are set by
D"KPTRAN when the page is taken from the virtual
machine by CPo
Thus the actual working set is
generally th~ average number of pages resident
at each page read.
However, this estimate is
sensitive to the overall system paging activity
for the following reasons:
1.
If there is no paging load on the system,
there is one page read for each resident
page, and no steals;
the working set
therefore tends to be equal to about one
half of the resident page total.
2.
As paging activity
increases, and the
working set location shifts, the working
set tends to increase toward the average
number of resident pages.
3.
If paging activity becom~s excessive, the
number of page steals 1ncreases to the
extent that the working set expands to the
maximum of the total
number of pages
referenced while in the queue.
P=(A+P)/2
If (lP-lA)
,
r
< 0
-- or -P=A
If (lP-lA)
r (P-A)
~
0
The working set is added to the current system
load, which consists of the sum of the working
sets for all virtual machines currently in a
que~e.
The sum is compared to the system
maX1mum, which is equal
to the number of
dynamically assignable pages in the system. If
the virtual machine's projected working set will
not push the system load over tthe virtual
machine maximum, he is placed in the queue and
added to the dispatchable list.
A
Actual working set at queue drop time
In summary, the scheduler selects the subset of
logged-on virtual machines that are allowed to
compete for the resources of the CPU, with the
constraint that a new virtual machine is not
added to the active subset if its projected main
storage requirement, added to that of the other
active virtual machines, causes the current
section 1. Introduction
91
capacity
of the
syste.
to be
exceeded.
Selection within scheduling
priority simply
means that a executable virtual .achine of high
priority is always added to the active subset
(to a queue) before a executable virtual machine
of lower priority. If the paging bias mechanism
is activated by setting the paging bias factor
to a nonzero value, scheduler selection is in
favor of smaller virtual machines; otherwise,
selection is within priority. Once the active
subset (the set of in-queue virtual machines)
has been selected, the dispatcher allocates
resources of the CPU among them.
The list of executable virtual machines in a
queue is sorted by dispatching (as opposed to
scheduling) priority. The dispatching priority
is a
running average of a
given virtual
machine's CPU
time/wait-time ratio.
Thus,
virtual machines who are most likely to go into
wait state, based on past performance, are
dispatched ahead of those whose demands on the
CPU are more extensive.
This simple ratio
priority is normally altered
if a virtual
machine is identified as compute bound by means
of the fact that it has executed for at least 50
ms. without entering the wait state.
In this
case, it is placed at
the bottom of the
dispatchable list.
On the other hand, virtual
machines identified as interactive by virtue of
the frequency their requests for terminal I/O
are placed at the top of the dispatchable list.
dispatchable
list at
its normal
priority
position.
However,
any active virtual machine
represents either
an explicit
or implicit
commitment of main storage. An explicit storage
com.itment can be specified
by either the
virtual=real option or the reserved page option.
An implicit commitment exists if neither of
these options are specified, and the scheduler
recomputes the
virtual machine's
projected
work-set at what it would normally have been at
queue-drop time.
Multiple virtual machines can
have the basic favored execution option set.
However,
if
their combined
main
storage
requirements
exceed the
sytem's
capacity,
performance can suffer due to thrashing.
The basic favored execution option removes
the primary source of elapsed time stretch~out
in a loaded time-sharing environment. However,
if the favored task is highly compute bound and
must compete for the CPU with many other tasks
of the same type, an installation can define the
CP~ allocation
to be made.
In this case, the
favored execution percentage
option can be
selected for one virtual machine.
This option
specifies that the selected virtual machine, in
addition to remaining in queue, receives a given
minimum percentage of the total CPU time, if he
can use it. The percentage is assured in the
following manner:
1.
The in-queue time slice is multiplied by
the requested percentage and added to the
virtual machine's current total CPU time
usage.
2.
When the
favored virtual
machine, is
executable, it is always placed at the top
of the dispatchable list until it has
obtained his guarantee.
3.
If
the
virtual machine
obtains
its
guarantee before the interval has elapsed,
it is placed in the dispatchable list
according to its caluculated dispatching
priority.
4.
In any case, at the end of the in-queue
time slice, the guarantee is recomputed as
in step 1 and the process repeated.
DMKDSP also provides a fast dispatch path for
virtual machines that
have issued specific
privileged instructions that are not handled by
the Virtual Machine Assist feature.
These virtual machines can be dispatched very
rapidly because the virtual machine's program
old PSM needs very little reconstruction to
redispatch the virtual machine, hence use of
full PSi reconstruction path is not required.
The decision for using the fast dispatch path
(DMKDSFA)
is accomplished by the module that
handles privileged operation, DMKPRV.
ihen the resources of the CPU (and real storage)
are
being allocated,
the dispatching
and
scheduling functions are implemented in such a
manner that
options exist which
allow an
installation to designate that certain virtual
machines are to receive preferential treatment.
The favored
execution options
allow an
installation to modify the algorithms described
above and force the system to devote more of its
resources to a given virtual machine than would
ordinarily be the case.
The options provided
are:
1.
2.
The favored execution option.
The favored execution percentage.
The favored execution option means that the
virtual machine so designated is never to be
dropped from the active (in-queue) subset by the
scheduler.
When
the virtual
machine
is
executable,
it is
to be
placed in
the
92
These options can impact the response time of
interactive virtual
machines and
only one
favored percentage virtual machine is allowed at
any given time.
Most of the routines in the CP nucleus are
reenterable and multiple control program or
virtual machine tasks can make use of one
routine at the same time. However, there are
certain areas where requests for a resource must
be serialized
(as in paging) or delayed while
previous requests are serviced (as in requests
to schedule I/O) •
IBM VM/370: System Logic and Problem Determination Guide
The routine handling the request obtains a
CPEXBLOK from free storage
and stores the
caller's registers in it; when the requested
resource is free, the CPEXBLOK is stacked for
the dispatcher via a call to the request stack
manager (DMKSTKCP). The dispatcher un stacks the
block and exits to the requesting routine the
next time it is entered.
I/O requests are
stacked in the same manner, except that the
stacking vehicle is the IOBLOK, and return is
passed to the address specified in the interrupt
return address (IOBIRA).
In either case, it
should be noted that the dispatcher always
unstacks and gives control
to any stacked
IOBLOKs and CPEXBLOKs prior to dispatching a
user.
This guarantees
that CP information
needed by a virtual machine (such as page
availability)
is always
as up-to-date
as
possible.
compression except that trailing blanks are
suppressed. The first two doublewords of each
buffer contain linkage information described
below, followed by the data and CCWs.
Bach spool logical record (card or print
line) is stored as one CCW that moves data (READ
or WRITB), a TIC to the following CCW, and the
full data record.
Space is left at the end of
each buffer so that a SENSE command can be
inserted to force concurrent channel end and
device end. For card punch channel programs
there is an additional back chain field that
points to the card previously punched so that
error recovery for punch equipment checks can
back up one card.
The only exception to the
format of RBAD/MRITB-TIC-Data is in buffers of
files directed to the printer. In this case,
immediate operation code CCWs (skips and spaces)
are followed by the next CCW.
CP SPOOLING
The spooling
functions.
•
support
in
CP
performs
three
Simulates the operation of the virtual unit
record devices that are attached to each
user's virtual machine configuration.
The
simulation is done in such a way that it
appears to the program in the virtual machine
that it is controlling a real unit record
device.
This
support
involves
the
interception and interpretation of virtual
machine SIOs, the movement of data to and
from the virtual machine's virtual storage
space, and the reflection of the necessary
interruption codes and ending conditions in
PSW's, CSW's and sense bytes. This support
is
provided
by
the
virtual
spooling
executive.
•
Operates the real unit record equipment,
attached to the system, that transcribes
virtual machine output spool files to the
real printer or punch and input from the real
card reader to DASD storage.
This function
is provided by the real spooling executive.
•
Provides an interface
among the virtual
machines, the
system operator,
and the
spooling system so that the locatioh, format,
priority and utilization
of the systems
spooling
data
and
resources
can
be
controlled.
SPOOL DATA AND FILB FORMAT
The buffers that collect and write spool data
are all one page (4096 bytes) in length, and
contain the data to be transcribed and all CCis
necessary for operating the unit record devices
that perform the transcription.
The data is
provided in the exact format required with no
In addition to the data and CCWs contained in
each spool buffer, the first two doublewords
contain forward and backward links to the next
and previous buffers in the file. This two-way
linkage allows the file to be backspaced or
restarted from any point at any time.
Also, it
means that if I/O errors are encountered while
reading one buffer, the file is put in system
hold status.
If purged, all buffers except
those in error are released. The two-way chain
allows this control of the file while preventing
fragmentation by allowing pages to be assigned
and released individually regardless of their
ownership.
The first spool buffer of an output spool
file contains a special data record called the
tag record. This record immediately follows the
two doublewords containing
the forward and
backward buffer linkage pointers. The tag record
allows VM/370 users to specify information to be
associated with spool files that they generate.
The information is entered via the CP TAG
command, although
the tag
record is
not
considered a spool file data record and is not
printed or punched as part of the spool file.
However, the contents may be interrogated via
the CP TAG QUBRY command.
The format of the tag record is a NOP CCW,
followed by a TIC to the next CCW and a 136 byte
data field. To differentiate the tag record
from an immediate NOP CCW (no TIC-data sequence)
independently of the command code, the 'skip'
bit
(bit 35)
in the CCM has the following
convention:
Bit
35
=0
=1
for
NOP CCW,
record)
for NOP
CCM
co.mand)
TIC,
data
(tag
(immediate
NOP
Each spool file in the system is controlled
by a spool file control block (SFBLOK)
that is
resident in storage.
While the file is open,
these blocks are chained
from the devices
(either real or virtual) that are processing the
file, and from device type file anchors after
section 1. Introduction
93
the file is closed.
There is one file chain
each for printer, readerv and punch files.
Each
SFBLOK contains information about the file that
describes its owner and originator (these can be
different for transfered files), the filename
and filetype, and the class and number of copies
for output files. All of these attributes can
be examined and most can be changed by the
file's owner or the system operator. The SFBLCK
also contains information such as the starting
and ending buffer addresses for the file, the
record size, certain file status flags, etc.
SPOOL BUFFER MANAGEMENT
Buffers that temporarily store spool data on its
way between DASD secondary storage and the
user's virtual machine are allocated from a pool
of virtual storage space that belongs to CPo
The size of this pool varies with the real
storage
available to
VM/370
(the
storage
specified at system generation or actual real
storage, whichever is less). Allocation is as
follows:
While a spool buffer is inactive, it resides in
real storage or on the paging device. After it
has been filled with data from the virtual
machine or a real input reader, it is written
to a page of secondary DASD storage.
The
allocation of pages on the spooling disk(s) is
managed by DMKPGT, which handles requests for
both pages of virtual storage and semi-permanent
spool file residence. DMKPGT maintains separate
allocation block chains for virtual storage and
spooling pages. Each block contains control
information and a bit map that allocates pages
on a single cylinder. If none of the cylinders
allocated have any
available pages, DMKPGT
enters its cylinder allocation routine.
DMKPGT attempts to even out the spooling and
paging I/O load by allocating cylinders across
channels and devices. To minimize seek times on
a given device, cylinders are allocated as close
to the relative center of the spooling or paging
area as possible.
f~~j~~ Q~!i£~
~y££~~!: All
actual I/O for the
page buffers on any device is controlled by the
paging I/O executive DMKPAGIO.
Virtual Buffers
___ !1!~£~!~~ __ _
VIRTUAL SPOOLING MANAGER (DMKVSP)
256K to 655,360 bytes
655,361 bytes to 1.1 megabytes
over 1.1 megabytes
128
320
640
virtual storage buffers are allocated in
l-page increments by DMKPGT at the time the
spool file is opened
for either input or
output.
If
no virtual
storage space
is
available, the virtual machine is placed in a
wait state until a buffer is freed
by another
virtual machine closing a file.
This places
limits on the number of concurrent spooling
operations permitted by
the system because
spooling operates as a high priority task.
Real storage is not allocated for a spooling
buffer until a virtual machine actually issues a
SIO that attempts to transfer data between the
buffer and the user's virtual storage space.
At
this time, a page of real storage is allocated
to the buffer via the real storage paging
manager.
The buffer is locked in main storage
(that is, is unavailable to be paged out) only
for the amount of time necessary to transfer the
data. After the data transfer is complete, the
buffer is treated as a normal page of virtual
storage, and can be selected to be paged out.
This ensures that low usage spool files do not
have buffers in real storage, while the buffers
for high usage files should remain resident.
The location of the spool buffer in real storage
is
transparent
to
the
virtual
spooling
executive, because all references to the data
therein are accomplished through the DAT feature
of the cPU.
The two functions of
the virtual spooling
manager are (1) to simulate the operation of all
spooled unit-record devices attached to the
user's virtual machine, and
(2)
to read and
write the spool files associated with those
devices.
The following virtual devices are
supported for spooling, with tbe exceptions
notefr:
•
IBM 2540 Card Reader/Punch,
feed read and column binary
except for punch
•
IBM 1403 Printer
positions)
2
•
IBM 3211 Printer (150 print positions)
•
IBM 3505 Card Reader
reading)
•
IBM 3525 Punch (except for the card
print, and data protect features).
Models
and
N1
(132
(except for mark senses
read,
The following consoles are supported for
spooling when entered into the directory as the
virtual system console:
•
IBM 1052 Printer-Keyboard, Model 7
2150 Console)
(via the
•
IBM 3210
and 2
Models 1
•
IBM 3215 Console Printer-Keyboard, Model 1
Console printer-Keyboard,
All virtual printers must have the universal
character set feature. No checking is done on
the spooled printer data.
However, any UCS
94
IBM VM/370: System Logic and Problem Determination Guide
buffer commands issued by the virtual machine
(load UCS buffer, block data checks, etc.) are
ignored.
It is
up to the user
and the
installation to ensure that
the output is
directed to the proper real printer via use of
the output CLASS feature described below. For
the 3211 printer, forms control buffer (PCB)
commands are accepted and simulated by means of
a virtual PCB maintained by the executive. The
use of the virtual PCB is the only way to
si~ulate end-of-form conditions reflected hy the
detection of a channel 9 or 12 punch. When the
spooled file is directed to a real 3211 or 1403,
the operator is responsible for loading the FCB
or mounting the proper carriage tape.
If any
of the unsupported
unit record
features are required, the real device must he
attached
directly
to the
user's
virtual
machine.
Thus, a 3505
reader could he a
spooling input reader, but attached directly to
a batch virtual machine when it is necessary to
read mark sense cards.
DMKVSP receives control from the virtual I/O
executive, DMKVIO, when
the user's machine
issues a SIO to a spooled unit record device.
DMKVIO does not pass control until it has been
determined that the device is availahle
(that
is,
non-busy
and
with
no
interruptions
pending).
DMKVSP first determines if the device
is currently processing a file.
If it is,
processing continues.
If this is the first
command issued hy the given device, a new output
file must be opened.
An open suhroutine is
called to build the control blocks necessary to
manage the file and to ohtain virtual storage
and DASD buffer space. Control is then returned
to DMKVSP.
Before the first record of an output spool
file is written, DMKVSP writes a tag record (NOP
CCW, TIC, data sequence)
and initializes the
136-byte data area to blanks. It then sets the
spool buffer displacement pointer to the first
doubleword in the buffer heyond the tag record.
DMSVSP then analyzes and interprets the channel
program associated with the virtual machine's
SIO.
Each CCW is
tested for validity of
command, address, flags, alignment, protection,
etc., and if the CCW is valid, the virtual
machine's data is moved from his own virtual
storage space to the buffer in the spooling
virtual storage.
When this buffer is full, it
is written to a page of DASD secondary storage
and
a
new
buffer
is
obtained.
The
interpretation of the virtual machine's channel
program continues until there are no more CCWs
or until an error condition is detected that
prohibits further processing. In either case,
the device is marked as having the proper
interruptions pending, a CSW is constructed, and
DMKVSP exits to the main dispatcher. In contrast
to nonspooled I/O, the virtual machine has
remained in a pseudo-wait
(IOWAIT) for the time
it took
to interpret
the entire
channel
program.
The output file can be logically closed by
the virtual machine either by issuing an invalid
CCw co.mand code, or hy the CP CLOSE co.mand.
In either case, DMKSPL checks for tag record
information in the VSPXBLOK.
(The VSPXBLOK,
pointed to by the VDEVEXTR field of the VDEVBLOK
for the output spool device, contains the tag
information entered via the CP TAG com.and.) If
tag data exists, the first spool buffer for the
file is read in, the tag data is inserted in the
tag record, and the buffer is rewritten to DASD
storage. If no tag data exists, the tag record
data field is left blank.
The device is then
cleared of pending
interruptions, the file
chains are completed, and the file is either
queued for output on a real device of the proper
type
(printer or punch), or, if IPER is in
effect, is queued for input to another virtual
machine.
Input file processing is similar to output file
processing, except for the
open and close
functions, and the analysis of CCW commands and
the direction of data movement.
Many common
routines are utilized to locate and verify CCWs,
obtain buffer space, and to move the spooling
data.
The difference in the open function is that
instead of creating a new file, it is necessary
to locate a reader file that already exists in
the system. To do this, the open subroutine
scans the SPBLOKs chained from the anchor,
READBRS, to find a file with an owner userid
that matches that of the caller and is not in
hold status.
If a file is not found, a unit
check or intervention required condition is
reflected to the virtual machine; otherwise, its
SPBLOK is chained to the control hlock for the
reader and the channel program is interpreted in
the same manner as for an output file.
After the input file is exhausted, a unit
exception is reflected to the user machine,
unless the user has requested either continuous
spooling or that an BOP not be reflected. With
continuous spooling, the unit exception is not
reflected until the last file for that virtual
machine is processed. If HOEOP is specified,
the simulation terminates with a unit check or
intervention required condition (similar to what
happens if the BOP hutton on a real reader is
not pushed) •
In either case, the input file is then
deleted from the system, unless the user has
specifically requested that his input files be
saved. If the file is saved, it can be re-read
any number of times.
Support of virtual console I/O for both the
virtual machine and VM/370 is provided as an
option for the VM/370 spooling capabilities.
This
support
fulfills
the
following
requirements:
Section 1. Introduction
95
•
Provides hardcopy support
Facility virtual machines.
•
Provides hardcopy support for display devices
used as system or virtual machine consoles.
•
Allows disconnected virtual machines to spool
virtual console output,
CP commands and
system resources to disk instead of losing
the output.
•
Improves the perfor.ance of virtual machines
that currently produce a large amount of
console output.
for
CMS
Batch
Whenever a SIO is issued to a virtual machine
console,
the virtual console manager
(DMKVCN)
determines if the spooling option is active.
If
it is, control is passed to the virtual spooling
manager at DMKVSPBP to insert the data into a
spool file buffer.
While console spooling
utilizes, basically, the same code as printer
spooling, the fcllowing exceptions are made:
•
A skip to channel 1 CCW
every 60 lines of output.
is inserted
after
•
The operator's virtual console spool buffer
is written out after every 16 lines of
output.
The virtual spool buffer is written out to
the allocated spool device when the first CCW
is placed in that virtual buffer. The linkage
drea of the virtual spool buffer takes the
form of a CLOSE file to allow checkpoint
(DMKCKP) to recover the active spool file in
the event of a shutdown because of system
failure.
The data in the virtual buffer, not
yet written out to the spool device will not
be recovered.
To maintain a pseudo closed file status for
console spool files, DMKSPL now assigns spool
identifications to all output spool files
where they are first queued.
A virtual system reset, device reset, or 1PL
does not close the virtual console spool
file. --The LOGOFF, FORCE, or DETACH of
virtual console commands
does close the
virtual console spool file.---The SHUTDOWN
command does close the operator's console
spool file.
If the SHUTDOWN command is
issued by a Class A user other than the
operator, the console spool file for both the
user and operator is closed.
The inclusion of the spool file tag record in
a virtual console spool file is processed by
DMKVSP and DMKSFL as described for printer spool
files in "Output File Processing" under "Virtual
Spooling Manager."
executive optimizes the use of main storage and
the CPU rather than running the system unit
record devices at their rated speeds.
DASD
input files are not double buffered and under
periods of peak load, input and output devices
tend to
run in bursts.
However, command
chaining is used for all unit record channel
programs so that the devices are running at
their
maximum
speed with
a
minimum
of
interruptions.
Both the input and output operations of DMKRSP
are interruption driven. Thus, DMKRSP does not
process unless an
internally or externally
generated
not-ready
to ready
device
end
interruption occurs. External interruptions are
generated by the hardware in the normal manner,
while internal, "pseudo
interruptions," are
generated by the software when an output file
has been queued on the real printer ~r punch
file chain, or when the operator issues a START
command to a drained device.
Upon receipt of the initial device end for a
printer
or
punch,
DMKRSP
searches
the
appropriate file chain for the SFBLOK of a file
whose class matches that of the device that was
made ready.
When the
SFBLOK is
located
(provided the file is not in a HOLD status) f it
is unChained from the output queue and chained
to the real device block that services the file.
A page of real main storage is then obtained for
use as a buffer,
and the output separator
routine
(DMKSEP)
is called to print output
identifier pages.
When DMKSEP returns control
to DMKRSP, the first buffer of the file is paged
into real main storage, and the CCWs in the
channel program that it contains are adjusted so
that their data addresses correspond to the real
addresses at which the data resides.
The real
SIO supervisor
(DMKIOSQR) is then called to
start the channel program, and DMKRSP exits to
the
dispatcher
(DMKDSPCH)
to
await
the
interruption.
When the channel end/device end interruption
for the completed buffer is unstacked to DMKRSP,
the forward chain file link field locates the
next buffer.
This buffer is paged-in, and the
process is repeated until the final buffer is
processed. At this point, the number of copies
requested for the file is decremented.
If the
number of copies is 0, processing is terminated
and the file is
deleted from the system;
otherwise, the process is repeated as many times
as necessary.
REAL SPOOLING MANAGER (DMKRSP)
When file processing is complete, a scan of
the appropriate output queue is again made, and
if a file is found it is processed.
If the
queue is empty, or if a file with a matching
class is not found, an exit is taken to DMKDSPCH
to wait for another ready interruption.
The real spooling manager operates the real unit
record devices that are attached to the system
and that are used to transcribe input data into
reader spool files and user output spool files
onto the
real printers and
punches.
The
output file processing can be modified by
either the system operator,
by a spoolin9
support command or as a result of system errors.
The operator commands allow a given file to be
backspaced or restarted, and
the files of
individual users or the whole system to be held
96
IBM VM/370: System Logic and Problem Determination Guide
and released for output.
I/O errors also affect
the spooling system, and a description of how
they are processed is in the section "Error
Recovery."
Reader file processing is initiated by the
receipt of a device end interruption from a
spooling card reader.
No explicit operator
command is required to start the processing of
an input file.
When the device end is unstacked
to DMKRSP, an open subroutine is called to build
the necessary control blocks and to obtain the
virtual, real, and DASD buffer space required
for the file.
A channel program to read 41
cards is built in the buffer, and DMKIOSQR is
called to start the reader.
When the interruption for the first buffer is
unstacked, the first card is checked for its
validity as
a userid
card.
The
minimum
information that this card must contain is the
use rid of the owner of the input file.
It may
appear
anywhere
on the
card,
with
the
restriction
that
it must
be
the
first
information punched. Optional information on
the userid card can include a filename and type
and/or the class of the virtual card reader to
which the file is to be directed. If the userid
is
valid, the
file processing
continues;
otherwise, the
operator receives
an error
message and processing is terminated.
After each file buffer is read, it is written
onto disk by the paging I/O routines in the same
way that virtual output files are handled. When
a unit exception signaling physical end-of-file
is received from the reader, the file is closed
by writing
the final buffer to
disk and
completing and
queuing the SFBLOK
to the
reader's file chain.
If the owner of the file
is currently logged on, he is given a message
indicating that a file has been read and if he
has an available card reader, it is posted with
a device end interruption.
An available reader
is one of the correct class which is ready, is
not bUSY, has no active file, and has no pending
interruptions.
Various routines in CP accumulate, format, and
punch account cards that contain system usage
information for certain users.
These routines
format the information into an SO-column card
image preceded by a punch CCW and call DMKACOAQ
to queue the card for real output.
DMKACOAQ
calls DMKACOPU to punch the card on a real
punch, if one is available; otherwise, the card
is queued in main storage until a punch is free.
When a punch finishes processing its last file,
a test is made to see if any accounting cards
have been queued.
If they have, DMKACOPU is
called to process them.
In addition to the cards generated by CP to
account for a virtual machine's use of system
resources, the user may request cards to be
punched in order to account for the use of
virtual machine resources by jobs running under
his userid.
In order to do so, the user must
have the account option
(ACCT) entered into the
directory.
To punch an accounting card, the user must
issue a code X'004C' DIAGNOSE instruction with a
pointer to either a parameter list containing
user specified "charge to" information, or a
data area containing up to 70 bytes of user
specified information to be punched into the
accounting
card.
DMKHVC
validates
the
instruction operands, builds an account buffer
(ACNTBLOK), and DMKACOQU is called to queue the
card
for
real
output.
For
additional
information
about
this user
option,
see
"DIAGNOSE Interface (DMKHVq" under "Privileged
Instructions."
When the user accounting option is being
utilized, the user must keep in mind that each
additional
accounting record
requested
is
occupying real storage space. Degradation of
system performance occurs if available storage
becomes filled with accounting data.
SPOOLING COMMANDS
The spooling commands
provide an interface
between the user, the system operator, and the
spooling system.
There are three types of
spooling commands:
•
Those that affect virtual devices
•
Those that affect real devices
•
Those that affect spool files that are queued
within the system
The commands that affect virtual devices are
generally available to all system users, and a
user can only affect the status of devices that
are attached
to his own
virtual machine.
Commands that affect the status of the real
system's spooling devices can be used by the
system operator only.
Commands that affect
closed spool files that are awaiting processing
are generally available to all users, with some
additional capabilities assigned to the system
operator.
For example, a user may alter the
char~cteristics only of those files that have an
owner's userid that matches his own, whereas the
system operator may change any spool file in the
system.
Each spool file in the system has a number of
attributes that are assigned to it, either
explicitly or by default, at the time that it is
created. These attributes and their values are
as follows:
•
Filename and filetype can be 24 character
fields.
Either or both can be replaced by a
user-supplied value.
section 1. Introduction
97
Spoolid number is a system-assigned number
between 1 and 9900.
It is automatically
assigned when the file is created (input) or
closed (output), and is unique within the
system. The file's owner, the device type,
and the id number are specified. Usually,
the userid defaults to the identification of
the user issuing the given command. Because
the identification number rather than the
filename and filetype is an identifier,
duplicate user-assigned names do not present
an identification problem.
•
The number of logical records
(cards or
print lines) in the file is an integer
between 1 and 16
million.
For printer
files, the record count also includes any
immediate operation code
space or skip
CCWs.
•
The originating user is the identification
of the file's creator, if the file has been
internally transferred from the originator's
printer or punch to the new owner's card
reader.
files transferred to a user's virtual reader can
also be controlled by class.
If the receiving
user has several readers, the input to each can
be limited to files of a certain class.
In
addition, the ORDER command allows sequencing of
input files by class as well as spoolid number.
output priorities can also be managed by
altering the hold status of a file. Individual
users can alter the hold status with the CHANGE
command, While the system operator can change
(hold or free) the files of specific individual
users.
These commands affect the status
virtual spooling devices:
Command
CLosi--
The number of copies requested for an output
file is between 1 and 99. Unless altered by
the user or operator, it defaults to 1.
•
The device type is used by DIAGNOSE for a
file transferred to a reader to determine
the virtual type of output device.
In addition to those attributes, a file that
is queued for real output or virtual input
always has a class associated with it.
A class
is a single alphameric character from A through
Z or from 0 to 9.
It controls both the real or
virtual device on which
the file will be
printed, punched, or read,
and the relative
priority and sequence of output on the device.
While each file is assigned a single class, each
real spooling output device can be assigned from
one to four classes.
The device then processes
only files that have a class attribute that
corresponds to one of its own, and processes
these files in the order that its own classes
are specified.
For example, if a printer is assigned the
classes A, D, 2, it processes any printer file
with a class of A before it searches the printer
output queue for a file with class D. All class
D files are printed before class 2 files.
The output class for a file is assigned at
the time the file is created and is the class
that is associated with the virtual device that
created it.
While each real spooling device can
have up to four classes, each virtual spooling
device can have only one. When a user logs onto
to the system, the class associated with a
device is the one defined in his directory entry
for that device.
However, he can alter this
class at any time by the SPOOL command.
As
files are created and closed by a device, they
take on the device's output class.
After they are closed
and are awaiting
output, their class can be changed by a CHANGE
command issued either by the file's owner or the
system operator.
The system operator can alter
the system generated output class (es) of a real
output device by the START command.
Output
98
SPOOL
of a
user's
!1~~n!!!g
Terminates spooling operations on a
specified device.
It clears
the
device
of any
pending
interrupt
conditions, and for
output files,
updates the tag record, completes and
queues the file
for real output.
Optional operands allow the user to
specify a filename and filetype, and
to override for the given file any
standard CLASS, HOLD/NOHOLD or COpy
operands set into the output device by
the SPOOL command.
Establishes the file attributes that
apply to files created on, or read by,
the given device.
It establishes the
class that will be in effect, whether:
files are to be automatically held,
input files are to be saved or purged
after reading, and output files are to
be
directed to
the real
system
Frinters and punches or are to be
transferred
to a
user's
virtual
reader.
The operator can use these commands to control
the activity of the real spooling devices:
Command
BACKSPAC
~~~~!~g
DRAIN
Stops the operation of a specified
output or input device after it has
finished processing the file on which
it is currently working. A printer
must be drained prior to the issuance
of the LOADBUF command.
Unit record
devices are normally drained prior to
system shutdown.
START
Restart a device after it has been
drained. Options allow the operator
to specify the spooling output class
Backspaces an active spooling device
for either a specified number of pages
(printers only) or to the beginning of
the file (printers or punches).
IBM VM/370: System Logic and Problem Determination Guide
for the output
device
separator records.
FLUSH
REPEAT
LOADBUF
SPACE
and
output
Immediately halts the output on the
specified device and either flushes
that copy of the file from the system,
or puts it into the system hold status
for future processing.
Supple.ents the
number of
copies
requested by the user for the file
when it was created. The operator can
specify a number froa 1 to 99 that is
added to the number specified by the
user.
Loads the universal
character set
buffer of the FCB of the specified
printer with the specified image. If
requested, the system verifies the
loading by printing its contents on
the affected printer.
Forces the output on the specified
printer
to
be
single
spaced,
regardless of the skipping or spacing
commands specified
by the
file's
creator.
~EQQ!
l!!~
~~~~g~!~~~ ~~!!~~g~:
The spooling
commands alter the attributes and status of
closed spool files that are queued and awaiting
processing.
When a command
applies to an
individual file, the device type (RDR, PUN, PRT)
and the spoolid number must be provided to
identify the file.
In most commands requiring a
spoolid, the keyword CLASS followed by a valid
spool class or the keyword ALL are acceptable
substitutes for the spoolid number. This causes
the command to be executed for all files of the
given class or device type. The use rid is the
identification of the user issuing the command,
except that the system operator must explicitly
supply the identification of the user whose
files he wishes to affect or he must specify the
keyword SYSTEM, which give$ access to all files
(valid for CHANGE, PURGE, ORDER, and TRANSFER
commands also).
Command
CHAUGi-
~~~~i~~
Changes the filename and filetype, the
number of copies, and the class of the
specified file.
Any of the above
attributes of a file can be determined
via the QUERY command.
HOLD
Places, via the system operator, the
specified file in a hold status. The
file is not printed or punched is
released by the system operator. The
operator can hold any user files by
device type.
FREE
Opposite of the HOLD co.mand.
Allows
a file or group of files that were
previously held to become available
for processing.
However, the user
cannot reset a hold that was set by
the operator with the HOLD command.
PURGE
Removes unwanted spool files from the
system before they are printed or
punched.
ORDER
Reorders the input files in a virtual
card reader.
It can order files by
identification number, by class, or by
any combination of the two.
TRANSFER
Transfers a virtual reader to another
user's virtual reader
without any
processing.
The TRABSFER
command
causes a changing in the owning userid
field in the file's SFBLOK.
SPOOL FILE ERROR RECOVERY
I/O errors on real spooling unit record devices
are handled by a transient routine that is
called by DMKIOS after it has sensed the unit
check associated with the error on a spooling
device.
If appropriate, a
restart CAW is
calculated and DMKIOS is requested to retry the
operation, in some cases waiting for a device
end that signals that the failing device has
been made ready after manual corrective measures
have been
taken.
If, after
retrying the
operation the error is unrecoverable, DMKIOS is
informed that a fatal
error has occurred.
DMKIOS then unstacks the interruption, flagged
as a fatal error, and passes control to real
spooling executive. The routines that handle
unstacked
interruptions
in
real
spooling
executive only module operations that have been
completed correctly or those that are fatal
errors.
If a fatal error is unstacked, the
recovery mechanism depends on the operation in
progress.
For fatal reader errors,
processing of the
current file is terminated and any portion of
the file that has been read and stored on disk
is purged.
The owner of the file is not
informed of the presence of a fractional part of
the file in the system.
For fatal printer or punch errors, the SFBLOK
for the partially completed file is re-queued to
the appropriate output list and processing can
be resumed by another available printer or
punch, or can be deferred until the failing
device is repaired.
In any case, the failing device is marked
logically offline, and no attempt is made by the
system to use it until the operator varies it
back online via the VARY command.
DASD I/O errors for page writes are transparent
to the user.
A new page for the buffer is
assigned,
the
file linkage
pointers
are
adjusted, and the buffer is rewritten.
The
failing page
is not
de-allocated and
no
subsequent request for page space is granted
access to the failing page. If an unrecoverable
error is encountered while reading a page,
processing depends on the
routine that is
reading the file.
If the processing is being
section 1. Introduction
99
done for a virtual reader, the user is informed
of the error and a unit check/intervention
required condition is reflected to the reader.
If the processing is being done for a real
printer or punch, the failing buffer is put into
the system hold status, and processing continues
with the next file.
In either case, the DASD
page is not de-allocated and it is not available
for the use of other tasks.
If the checkpoint start procedure encounters
I/O errors
or invalid
DASD data
on the
checkpoint cylinders, the operator is notified.
The FORCE
option of the
checkpoint start
performs all the checkpoint start functions
except that, invalid or unreadable files are
bypassed.
While this is at best a partial
recovery, the only other alternative is a cold
(COLD) start where all spool file data is lost.
RECOVERY MANAGEMENT SUPPORT (RHS)
If the space allocated for paging and spooling
on the system's DASD volumes is exhausted and
more 'is
requested by
a virtual
spooling
function, the user receives a message and a unit
check
intervention
required
condition
is
reflected to the virtual output device that is
requesting the
space, the output
file is
automatically closed and it is available for
future processing. The user can clear the unit
check and periodically retry the operation which
will start when space is free or completely
restart later from the beginning of the job. If
the task requesting the space is the real
spooling reader task, the operator receives an
error message and the partially complete file is
purged.
Any
time the
spooling space
is
exhausted, the operator is warned by a console
message and alarm. However, the system attempts
to continue normal operation.
The machine check handler (HCD)
minimizes lost
computing time caused by machine malfunction.
MCD does this by attempting to correct the
malfunction
immediately, and
by
producing
machine check records and messages to assist the
service representatives in determining the cause
of the problem.
The channel check handler (CCD) aids the I/O
supervisor
(DHKIOS) to recover from channel
errors. CCD provides the device dependent error
recovery programs (ERPs) with the information
needed to retry a channel operation that has
failed.
This support is standard and model independent
on the external level (from the user's point of
view there are no considerations, at system
generation time, for model clependencies) •
RECOVERY FROM SYSTEM FAILURE
SYSTEM INITIALIZATION FOR RMS
Should
the
system
suffer
an
abnormal
termination, CF attempts to perform a warm
start. Spool file and device data, as well as
other system information is copied from real
storage to
warm start
cylinders on
DASD
storage.
When the systme is reinitialized, the
spool data and other system data is retrieved
from the warm start cylinders and operation
continues.
DMKCPI calls to initialize the error recording
at cold start and warm start.
DMKIOEFL gives
control to DMKIOG to initialize the MCD area. A
store CPU ID (STIDP) instruction is performed to
determine if VM/370 is running in a virtual
machine environment, or running standalone on
the real machine. If VM/370 is running in a
virtual machine, the version code is set to a
hexadecimal 'FF' by DMKPRV. If the version code
returned is hexadecimal 'FF', the RMS functions
are not initialized beyond setting the wait bit
on in the machine check new PSW (virtual). This
occurs because machine check interruptions and
channel errors (other than channel data checks)
are not reflected to
any virtual machine.
VM/370, running on the real machine, determines
whether
the
virtual
machine
should
be
terminated.
If the warm start data in real storage had
damaged by the abnormal termination, the warm
start procedure recognizes the situation and
notifies the operator that a warm start cannot
be performed. Another recovery method would be
to attempt a checkpoint start.
The spool file recovery routines
(DMKCKS)
dynamically checkpoint on DASD storage; the
status of all open reader files, the status of
all closed output files,
real spooling device
data, and system hold queue information. This
information is stored on checkpoint cylinders
that are allocated, along
with warm start
cylinders, at system generation.
When a checkpoint (CKPT)
start is requested,
spool file and spooling device information is
retrieved from the checkpoint cylinders. Spool
file blocks are chained to their appropriate
reader,
printer
or punch
chains;
record
allocation blocks are reconstructed; spooling
device status is restored; and, system hold
queues are chained to
the proper devices.
system operation then continues.
100
If the version code is not X'FF,'
DMKIOG
determines
what
channels
are
online
by
performing
a
STORE
CHANNEL
ID
(STIDC)
instruction and saves the channel type for each
channel that is online.
The maximum machine
check extended logout length (MCEL) indicated by
the STORE CPU ID (STIDP) instruction is added to
the length of the MCD record header, fixed
logout length and damage assessment data field.
DMKIOG then calls DMKFRE to obtain the necessary
storage to be allocated for the MCH record area
and the CP executing block
(CPEXBLOK). DMKIOG
saves the pointers for the machine check record
and the CPEXBLOK in DMKMCH.
DMKIOG obtains the
storage for the I/O extended logout area and
IBM VM/370: System Logic and Problem Determination Guide
initializes the logout area and the ECSW to 1s.
The 110 extended logout pointer is saved at
location 172
and control
register 15
is
initialized with the address of the extended
logout area. The length of the CCH record and
the online channel types are saved in DMKCCH.
It should be noted that the ability of a CPU to
produce an extended logout or 110 extended
logout and the length of the logouts are both
model and channel dependent.
If VM/370 is being
initialized on a Model 165 II or 168, the 2860,
2870, and 2880 standalone channel modules are
loaded and locked by the paging supervisor and
the pointers are saved in DMKCCH. If VM/370 is
being initialized on any
other model, the
integrated channel support is assumed; this
support
is part
of
the channel
control
subroutine of DMKCCH.
Before returning to
CMKIOE the MCH/CCH recording cylinder for error
recording is initialized. DMKIOE passes control
back to DMKCPI and control register 14 is
initialized with the proper mask to record
machine checks.
CVERVIEW OF MACHINE CHECK HANDLER
A machine malfunction can originate from the
CPU, real storage or control storage. When any
of these fails to
work properly, the CFU
attempts to correct the malfunction.
When the
malfunction is
corrected, the
machine check handler
(MCH) is notified by a
machine check interruption and the CPU logs out
fields of inforaation in real storage, detailing
the cause and nature of the error. The model
independent data is stored in the fixed logout
area and the model dependent data is stored in
the extended logout area.
The machine check
handler uses these fields to analyze the error,
format an error record, and write the record out
on the error recording cylinder of SYSRES.
If the machine fails to recover from the
malfunction through its own recovery facilities,
the machine check handler is notified by a
machine check interruption.
An interruption
code, noting that the recovery attempt was
unsuccessful, is inserted in the fixed logout
area. The machine check handler then analyzes
the data and attempts to keep the system as
fully operational as possible.
Recovery from machine malfunctions can be
divided
into
four
categories:
functional
recovery,
system recovery,
system-supported
restart and syst~m repair. These levels of error
recovery are
discussed in their
order of
acceptability, functional recovery being most
acceptable
and system
repair being
least
acceptable:
!Y!~I!g!A1
RECCVERY: Functional
recovery is
recovery froi--i-ii~hine check without adverse
effect on the system or the interrupted user.
This type of recovery can be made by CPU retry,
the ECC facility, or the machine check handler.
CPU retry and ECC error correcting facilities
are discussed separately in this section tecause
they are significant in the total error recovery
scheme. Functional recovery by MCH is made by
correcting storage protect feature (SPF)
keys
and intermittent errors in real storage.
E!E11~
SI~Q!ISl: System
recovery is attempted
when functional recovery is impossible. System
recovery
is
the
continuation
of
system
operations at the expense of the interrupted
user,
whose virtual
machine operation
is
terminated. System recovery can only take place
if the user in question is not critical to
continued system operation. An error in a system
routine that is considered to be critical to
system operation precludes functional recovery
and would require a system-supported restart.
SYSTEM-SUPPORTED RESTART: When the aachine check
o~~urs In-i-crItical-routine, the primary system
operator is notified that the system cannot
continue tc operate. An automatic reload of the
system occurs. This type of recovery is tried
when functional and system recovery have failed
or could not be tried.
SYSTEM REPAIR: Sy~tem repair is recovery that
requIres-the- serv~ces of maintenance personnel
and takes place at
the discretion of the
operator. Usually, the operator has tried to
recover by system-sup~orted restart one or more
times with no success. An example of this type
of error is when a
hard error occurs so
frequently that system-supported restart is not
successful.
SYSTEM/370 RECOVERY FEATURES
The operation of the Machine Check Handler
depends on certain automatic recovery actions
taken by the hardware and on logout information
given to it by the hardware.
CPU
errors
are automatically
retried
by
microprogram routines.
These
routines save
source data
before it is altered
by the
operation. When
the error is
detected, a
microprogram returns the CPU to the beginning of
the operation, or to a point where the operation
was executing correctly, and the operation is
repeated. After several unsuccessful retries,
the error is considered permanent.
ECC checks the validity of data from real and
control
storage,
automatically
correcting
single-bit errors. It also detects multiple-bit
errors but does not correct them. Data enters
and leaves storage through a storage adapter
unit. This unit checks each douhlewcrd for
correct parity in each byte. If a single-bit
error is
detected, it
is corrected.
The
Section 1. Introduction
101
corrected double word is then sent tack into real
or control storage and on to the cpu.
When a
multiple-bit error is detected, a machine check
interruption occurs, and the error location is
placed in the fixed logout area.
MCH gains
control and attempts to recover from the error.
interruption.
To m~n~m~ze the possibility of
losing logout information by recursive machine
check interruptions, the machine check new PSW
gives control to DM~MCH with the system disabled
for further interruptions. There is always a
danger that a machine malfunction may occur
immediately after DMKMCH is entered and the
system is disabled for interruption.
Disabling
all interruptions is only a temporary measure to
give the initial analysis subroutine time to
make the fcllowing emergency provisions:
Two control registers are used by MCH for
loading and storing control information
(see
Figure 19). Control register 14 contains mask
bits which specify whether certain conditions
can cause machine check interruptions and mask
bits which control conditions under which an
extended logout can occur. Control register 15
contains the address of the extended logout
area.
•
It
disables
for
soft
machine
check
interruptions. Soft recording is not enabled
until the error is recorded.
•
It saves the contents of the fiXed and
extended logout areas in the machine check
record.
•
It alters the machine check new PSW to point
to the term subroutine.
The term subroutine
handles second machine check errors.
•
It enables the machine for hard machine check
interruption.
•
If a virtual user was running when the
interruption occurred, the running status
(GPRs, FPRs, PSW, M.C. old PSW, CRs, etc.) is
saved in the user's VMBLOK.
•
It initially examines the machine check data
for the following error types:
r--'---------------------------------,
1
1
1
IWordlBitsl Name of Field
14
o
Check-stop control
14
Synch. MCEL control
14
2
14
4
I/O extended logout
control
Recovery report mask
14
5
Degradation report mask
14
6
14
7
External damage report
mask
Warning lIask
14
8
Asynch. MCEL control
14
15
1 Associatedl
I
With
I
Asynch. fixed log
control
8-281 MCEL address
9
1
Mch-Chk
handling
Mch-Chk
handling
Chan-Chk
handling
Mch-Chk
handling
Mch-Chk
handling
Mch-Chk
handling
Mch-Chk
handling
Mch-Chk
handling
Mch-Chk
handling
Mch-Chk
handling
L
MCIC=ZERO
PSW invalid
System damage
Timing facilities damage
The occurrence of any of these errors is
considered uncorrectable
by DMKMCH;
the
primary system operator is informed, the
error is formatted and recorded, and the
system is shutdown followed by an automatic
restart function.
---..J
Figure 19. RMS Control Register Assignments
•
If the instruction processing damage bit is
on, it tests for the following types of
Jlalfunctions:
"ultiple-~it
Error in Main storage
Control ~s given to the main storage
analysis subroutine.
VM/370 Machine Check Handler 1I0dule
consists of the following functions:
•
•
•
•
•
•
•
•
SPF Key Error -- control is given
SPF analysis subroutine.
to the
Retry failed
If the cpu
was in
supervisor state the error is considered
uncorrectable and the VM/370 system is
terminated.
If the CPU was in problem
state, the virtual Jlachine is reset or
terminated
and the
system
continues
operation.
Initial analysis subroutine
Main storage analysis subroutine
SPF analysis subroutine
Recovery facility mode switching
Operator cOllmunication subroutine
Virtual user termination subroutine
soft recording subroutine
Buffer error subroutine
Termination subroutine
The initial
analysis subroutine
of
receives
control
by
a
lIachine
102
(DMKMCH)
DMK"CH
check
•
If CPU retry or ECC was successful on a soft
error, control is given to the soft recording
subroutine to format the record, write it out
on the error recording cylinder, and update
the count of soft error occurrences.
•
If external damage was reported, control is
given to the soft recording subroutine to
IBM V"/370: system Logic and Problem Determination Guide
format the record and write it
error recording cylinder.
out on
the
The main storage analysis subroutine is given
control when the machine check interruption was
caused by a multiple-bit storage error.
An
initial function points the machine check new
PSi to an internal subroutine to indicate a
solid machine check, in case a machine check
interruption
occurs while
exercising
main
storage.
Damaged storage areas associated with any
portion of the CP nucleus itself cannot be
refresbed;
multiple-bit storage errors in CP
cause the V"/370 system to be terminated. An
automatic restart reinitializes VM/370.
If the damage is not in the CP nucleus, main
storage is exercised to determine if the failure
is solid or intermittent. If the failure is
solid, the 4K page frame is marked unavailable
for use by the system.
If the failure is
intermittent, the page frame is marked invalid.
The change bits associated with the damaged page
frame are checked to determine if the page had
been altered, by the virtual machine.
If no
alteration had occurred w VM/370 assigns a new
page frame to the virtual machine and a backup
copy of the page is brought into storage the
next time the page is referenced.
If the page
had been altered V"/370 resets or terminates the
virtual machine, clears its virtual storage, and
sends an appropriate message
to the user.
Normal system operation continues for all other
users.
If an SPF machine check occurs, which is
associated with a virtual machine, the SPF
analysis subroutine exercises all 16 keys in the
failing storage 2K page frame.
If an SPF
machine check does not occur, the machine check
is intermittent and the swptable for the page
associated with the failing storage address is
located. The storage key for the failing 2K
storage page
frame is retrieved
fro. the
swptable and the change and reference bits are
set on in the storage key. The storage key is
then stored into the affected failing storage 2K
page frame.
If an SPF machine check occurs in
exercising the 16 keys 5 times each, then the
machine check is considered
solid and the
follow.ing actions are taken.
(1) The virtual
machine is selectively reset or terminated by
the virtual machine termination subroutine; (2)
The 4K page frame associated with the failing
address is removed as
an available system
resource. This is accomplished by locating the
cortable for the defective page and altering the
corfpnt and corpbpnt pointers to make the page
unavailable to the system.
The cordisa bit in
this cortable is set on to identify the reason
for the status of this page in a system dump.
The recovery facility mode switching subroutine
(DMKMCH"S) allows the service representative to
change the mode that CPU retry and ECC recording
are operating in.
This subroutine receives
control when a user with privilege class F
issues some form of the SET "ODE command.
A
check is initially made to determine if this is
V"/370 running under VM/370. If this is the
case, the request is ignored and control is
returned to the calling routine. The format of
the "ODE command is as follows:
SET MODE {RETRYI"AIN} {QUIETIRECORD}
The SPF analysis subroutine is given control
when the machine check interruption was caused
by an SPF error. An initial function points the
machine check new PSi to an internal subroutine
if a machine check interrruption occurs during
testing and
validation.
The
SPF analysis
routine then
determines if the
error was
associated with a failure in virtual machine
storage or in the storage associated with the
control program.
An SPF error associated with V"/370 is a
potentially catastrophic failure. Namely, V"/370
always runs with a PSi key of zero, which means
that the SPF key in main storage is not checked
for
an out-of-parity
condition.
The
SPF
analysis subroutine exercises all 16 keys in the
failing storage 2K page frame.
If an SPF
machine check occurs in exercising the 16 keys 5
times each, the error is considered solid and
the operating system is terminated with a system
shutdown. The system is automatically restarted
and VM/370 is reinitialized.
If an SPF machine
check does not occur, the machine check is
considered
intermittent. The
zero key
is
restored to the failing 2K page frame and this
is transparent to the virtual machine.
RETRY and MAIN imply CPU
storage, respectively.
retry
and
main
QUIET causes the specified facility to be
placed in quiet mode. RECORD causes the count
of soft errors to be reset to zero and the
specified facility to be placed in record mode.
The operator communciation subroutine is invoked
when the integrity of the system has degraded to
a point where automatic shutdown and reload of
the system has been tried and was unsuccessful,
or could not be attempted due to the severity of
the hardware failure.
A check is first made to
determine if the system operator is logged on as
a user, next a check is made to determine if the
system operator is disconnected. If either of
these checks is not affirmative a message cannot
be issued directly to the system operator.
A
LPSW is performed to place the CPU in a disabled
Section 1. Introduction
103
wait state with a recognizable wait
in the CPU instruction counter.
state code
The virtual
machine termination
subroutine
selectively resets or terminates a virtual user
whose operation has been interrupted by an
uncorrectable machine check.
First, the machine
is marked nondispatchable to prevent the damaged
machine from running before reset or termination
is performed.
The machine check record is
formatted and DMKIOEMC is called to record the
eiror. Then the user is notified by a call to
DMKQCNWT that a machine check has occurred and
that his operation is ter.inated.
The primary
system operator is notified of the virtual user
termination by a message issued by a call to
DMKQCNWT. If the virtual machine is running in
the virtual=real area, DMKUSO is c~lled to log
the virtual machine off the system and to return
the storage previously allocated to the virtual
machine and to clear any outstanding virtual
machine I/O requests. The HOLD option of LOGOFP
is invoked to allow a user on a dial facility to
retain the connection and thus permit LOGON
without re-establishing the line connection.
However, if the virtual machine is running in
the virtual area, and DMKCPM is then called to
put the virtual machine in console function
mode, the user must re-initialize the system to
commence operation.
The soft recording subroutine performs two basic
functions:
•
Pormats a machine check record and
DMKIOEMC to record the error on the
recording cylinder.
calls
error
£fY
R~trI ~y!~!
Mode: Quiet mode (bit 4 of
control register 14-Set to 0) can be entered in
one of two ways:
(1)
when 12 soft machine
checks have occurred, or (2)
when the SET MODE
RETRY QUIET command is executed by a class F
user.
In this mode, both CPU retry and ECC
reporting are disabled. The CPU remains in
quiet mode until the next system IPL (warm start
or cold start)
occurs or a SET MODE RETRYIMAIN
RECORD command is executed by a class P user.
]££
B~£QIg!ng
~Qg~§:
To
achieve
model
independent support, RMS does not set a specific
mode for ECC recording. The mode in which ECC
recording is
initialized depends
upon the
hardware design for each specific CPU model.
For the IBM System/370 Models 135, 145, 158, and
168, the hardware initialized state (therefore
the normal operational state for VM/370)
is
quiet mode.
Por the IBM System/370 Models 155
II and 165 II, the hardware initialized state
(the normal operational state for VM/370)
is
record mode.
An automatic restart incident due
to a VM/370 failure does not reset the ECC
recording mode
in effect at the
time of
failure.
The change from record to quiet mode for ECC
recording can be initiated in either of the
following ways; (1)
by issuing
the SET MODE
(MAINIRETRY) QUIET command, or ~) automatically
whenever 12 soft machine checks have occurred.
For
the
purpose
of
model
independent
implementation this occurs by setting bit 4 of
control register 14 to zero.
The change from quiet to record mode for ECC
recording can be accomplished by use of the SET
MODE MAIN RECORD command. This recording mode
option is for use by maintenance personnel only.
It should be noted that CPU retry is placed in
recording mode if it is not in that state when
the SET MODE MAIN RECORD command is issued.
While in
recording mode,
corrected ECC
reports are formatted and recorded on the error
recording cylinder,
but the primary systems
operator is not informed of these incidents.
Maintains the threshold for CPU retry and ECC
errors and switches from recording to quiet
mode when the threshold value is exceeded.
To accomplish this, a counter is maintained
by DMKMCH for successful
CPU retry and
corrected ECC events.
~g~ B~!II R~£QIg!ng ~Qg~:
Recording mode (bit 4
of control register 14 set to one)
is the
initialized state, and normal operating state of
VM/370 for CPU retry errors.
Recording mode may
also be entered by use of the CP SET command.
When 12 soft machine checks have occurred, the
soft recording subroutine switches the CPU from
recording mode to quiet mode.
For the purpose
of model-independent implementation
this is
accomplished by
setting bit 4
of control
register 14 to zero. Because in quiet mode no
soft machine check interruptions occur, a switch
from quiet mode to recording mode can be made by
issuing the SET MODE RETRYIMAIN RECORD command.
While
in
recording
mode,
corrected
CPU
- RETRYIMAIN reports are formatted and recorded on
the VM/370 error recording cylinder, but the
primary systems operator is not informed of
these occurrences.
104
On CPU models equipped with a high speed buffer
(155 II, 158,
165 II, 168) or a data lookaside
ta ble
(DLA T)
(165 II, 168)
the deletion of
buffer blocks because of hardware failure is
reported via a DEGRADATION report machine check
interruption.
MCR
enables
itself
for
degradation report machine check interruptions
at system initialization by setting bit 5 of
control register 14 to 1.
If a machine check
interruption occurs that indicates high speed
buffer or DLAT damage, MeR formats the record
and calls DMKIOEMC to record it on the error
recording cylinder, informs the primary systems
operator of the failure, and returns control to
the system to continue normal operation.
IBM VM/370: System Logic and Problem Determination Guide
Normally, when DHKCCH returns control to the
the error recovery program for
the device which experienced
the error is
scheduled. When the ERP receives control, it
prepares to retry the operation if analysis of
the IOERBLOK indicates that retry is possible.
Depending
on the
device
type and
error
condition, the ERP either effects recovery or
marks the event fatal and returns control to the
1/0 supervisor.
The 1/0 supervisor calls the
recording routine DHKIOE to record the channel
error.
1/0 supervisor,
The termination subroutine is given control if a
hard machine check interruption occurs while
DHKHCH is in the process of handling a machine
check interruption.
Note that
soft error
reporting is disabled for the entire time that
HCH is processing an error.
An analysis is performed of the machine check
interruption code
of the
first error
to
determine if it was a soft error. If it was,
the first error is recorded, the system status
is restored and control is restored to the point
where the first error occurred. If the first
error
was
a
hard
error,
the
operator
communication subroutine is given control to
issue a message directly to the system operator,
and to terminate CP operation.
OVERVIEW OF CHANNEL CHECK HANDLER
The channel check bandler (CC~
aids the 110
supervisor in recovering from channel errors and
informs the operator or service representative
of the occurrence of channel errors.
CCH receives control from the 110 supervisor
when a channel data check, channel control
check, or interface control check occurs. CCH
produces an 110 error block (IOERBLOg) for the
error recovery program and a record to be
written on the error recording cylinder for the
system operator or service representative. The
operator or service representative may obtain a
copy of the record by using the CPERBP programs.
A message about the channel error is issued each
time a record is written on the error recording
cylinder.
When the 110 supervisor program detects a
channel error during routine status examination
following
an SID,
TID, HID,
or an
110
interruption it passes control to the channel
check handler
(DKKCCH). DKKCCH analyzes the
channel logout information and constructs an
IOERBLOK, if the error is a channel control or
interface control check.
An BCSW is constructed
and placed in the
IOERBLOK.
The IOERBLOK
provides information for the device dependent
error
recovery
procedures.
DKKCCH
also
constructs a record to be recorded on the error
recording cylinder. Normally, CKKCCH returns
control to the 1/0 supervisor after constructing
an IOERBLOK and a record. However, if DHKCCH
determines that
system integrity
has been
damaged (system reset or invalid unit address,
etc.) then CP operation is terminated.
CP
termination causes DKKCCH to issue a message
directly to the system operator and place the
CPU in a disabled wait state with a recognizable
wait code in the CPU instruction counter.
Recovery is not initiated for channel errors
associated with 1/0 events inititated by a
virtual
machine,
however
these
causes
termination of the virtual machine after it has
been notified of the failure.
The error is
recorded by DKKIOECC on the error recording
cylinder.
The primary system operator is notified of
the failure, and DKKIOE returns control to the
system and normal processing continues.
CHANNEL CONTROL SUBROUTINE
Control is
passed to the
channel control
subroutine of DKKCCH after a SIO with failing
status stored, or an 1/0 interrupt because of a
channel control check, interface control check,
or channel data check.
If "logout pending" is indicated in the CSW,
the CP termination flag is set.
The existence
of
real device
blocks (RCHBLOK,
RCUBLOK,
RDEVBLOK), for the failing device address, is
determined by
a call to DKKSCNRU
and an
indicator is set if they do exist.
An indicator
is also set if the IOBLOK for the failing device
address exists.
A call to DKKFRBE obtains
storage space for the channel check record and
the channel
control subroutine
builds the
record.
If the indicators show that the real
device blocks and the IOBLOK exist, a call to
DKKFRBE obtains storage space and the channel
control subroutine builds the 1/0 error block
(IOERBLOK); if these blocks do not exist, the
IOERBLOK is not built. The IOERBLOK is used for
two purposes:
1.
The
device dependent
error
recording
program (ERP) uses the IOERBLOK to attempt
recovery on CP initiated 1/0 events.
If
the 1/0 events that resulted in a channel
check
are associated
with a
virtual
machine, the 1/0 fatal flag is set in the
IOBLOK and the virtual machine is reset,
cleared, and put into CP read status. The
length and address of .the channel check
record is placed in the IOERBLOK and the
IOERBLOK is chained off the IOBLOK.
2.
DMKIOECC uses the IOERBLOK to record the
channel check record on the error recording
cylinder.
The channel control subroutine gives control
to a channel dependent error analysis routine to
build or save the extended channel status word
(ECSW) •
When the channel control subroutine
regains control, eight active addresses are
saved in the channel check record.
If the CP termination flag is set, the 1/0
extended logout data fro. the channel check
record is restored to main storage for use by
SEREP. If the system operator is both logged on
Section 1. Introduction
105
as a user and connected to the system, a message
(DMKCCH603W) is sent to him advising him of the
channel error. A LPSW is then executed to place
the CPU in a disabled wait state with a wait
state code of 002
in the CPU instruction
counter.
If the CP termination flag is not set, a
check is made to determine if an IOERBLOK was
built by the channel control subroutine.
If an IOERBLOK was not built, DMKIOECC is
called to record the channel check record on the
error recording cylinder. The system operator
is
then
sent a
message
(DMKCCH6011
or
DMKCCH602I)
informing him of the error and
control is then returned to DMKIOS to continue
system operation.
If an IOERBLOK was built, control is returned
to DMKIOS, which calls the appropriate ERP.
Whether or not recovery is successful, DMKIOS
eventually calls DMKIOE to record the channel
check record.
DMKIOE examines the status of the
in CSW error in the IOERBLOK to determine if it
was a channel error; if so, it finds the length
and pointer to the channel check record and
records the
error on the
error recording
cylinder.
If this was not a channel error,
DMKIOE continues normal processing.
The 2860 logout area is checked to determine if
a complete logout exists; if not, CP termination
is necessary.
A check is made in the logout area for
validity of the CSW fields and bits are set. in
field to
the channel
check record's ECSW
indicate bad fields.
The channel logout is
then checked and
sequence codes are set based on the presence of
a channel control check, or an interface control
check. If a channel control check is present,
the codes set are determined through parity.
The count determines if parity is good and sets
a resultant condition code.
The logout area is examined to ensure that
the unit address has valid parity and is the
same address passed by DMKIOS. If so, the unit
address valid bit in the ECSW is set. If the
unit address is not valid the unit address valid
bit is reset to indicate the invalid condition.
The ECSW field in the channel check record is
moved to the IOERBLOK, if one exists.
After completing the ECSW the 2680 routine
moves the 2860 I/O extended logout into the
channel check record, set. the I/O extended
logout area to ones, and returns to the channel
control subroutine.
INDIVIDUAL ROUTINES
A separate channel error analysis routine is
provided for each type of channel for which
DMKCCH can be used.
The purpose of these
routines and the channel control subroutine is
to analyze the channel logout to determine the
extent of damage and to create a sequence and
termination code to be placed in the ECSW in the
IOERBLCK.
At system initialization, the correct
model dependent channel recovery routine is
loaded and the storage necessary to support the
routine is allocated. The model dependent error
analysis subroutines and routines and their
functions are as follows:
Since all of these systems have integrated
channels one common subroutine is used to handle
all of these CPU types. This subroutine:
If the channel failed to logout completely, at
least part of the logout area is all 1s. If a
fullword of ones is found,
a CP termination
condition exists.
A check is made in the logout area for valid
CSW fields, and bits are set in the channel
check record's ECSW field
to indicate bad
fields.
The termination and sequence codes are set
depending on the presence
of an interface
control check or channel control check.
If a
channel control check is present, the codes set
are determined through parity, count, and/or
data transfer checks. For the 2870, parity can
be determined directly from the channel logout.
•
Moves the ECSW to the IOERBLOK
The logout area is also examined to ensure
valid parity in the unit address and to ensure
that the address is the same as that passed to
DMKCCH by DMKIOS. If so, the unit address valid
bit in the ECSW is set.
•
Moves the hardware stored unit address and
the I/O extended logout to the channel check
record
The third word of the logout area is also
analyzed for type II errors. If a type II error
is found, a CP termination condition exists.
•
Sets the I/O extended
area to 1s
and ECSW
The ECSW field in the channel check record is
moved t6 the IOERBLOK, if one exists.
control
Before returning to
the channel control
subroutine, the 2870 routine moves the 2870 I/O
Indicates CP termination if the ECSW is not
complete, the channel has been reset, or
reset codes are invalid
Returns control
subroutine
106
to
logout area
the
channel
IBM VM/370: system Logic and Problem Determination Guide
extended logout into the channel check record
and sets the 1/0 extended logout area to ones.
This routine
logout.
analyzes 9
words of
the 28
word
The 2880 analysis routine handles channel
data checks, interface
control checks, and
channel control checks.
Termination code 3 (system reset) is not set
in the ECSW because the 2880 channel does not
issue system reset to the devices. Retry codes
of zero to five are possible.
Note: There are several catastrophic conditions
under which the CP termination flag can be set,
in the 2880 analysis routine. They are:
•
The channel did not complete the logout.
•
The CSW is not reliable.
•
The unit address in the 1/0 interruption
device address field is not correct.
If valid paraaeters are not found, the SVC is
reflected back to the virtual machine and no
recording takes place. If valid parameters are
passed, a pageable routine (DftKVER)
processes
the error record.
DftKVER validates the record passed by the
virtual machine.
If invalid conditions are
found, no recording takes place. Control is
returned to the SVC interruption routine in
DftKPSA to reflect the SVC to the virtual machine
as an SVC interruption. The action taken by the
virtual machine is dependent on the operating
system running in the virtual machine, not
Vft/370. If the record is valid, it is modified
by changing virtual information to real.
The
actual recording
is accomplished
by using
existing modules in DftKIOE and DftKIOF.
Control is then returned to the instruction
following the SVC 76 rather than reflecting the
SVC. This eliminates the duplication of error
recording in Vft/370 and the operating system in
the virtual machine. If DftKVER determines that
the recording represented a permanent I/O error,
a message
is sent to the
primary system
operator.
ERROR RECORDING AND RECOVERY
Only a channel check record is needed if the
channel has recognized an internal error and has
recovered from it without
any damage.
No
recovery action is necessary in these cases.
If
the
channel
address
in
the
1/0
interruption device address field does not match
the channel
address in the logout,
a CP
termination condition exists.
If the channel was doing a scan and the unit
control word had a parity check a CP termination
condition exists. If there was no parity check,
there was no damage during "the scan and only a
channel check record i p required.
Depending on the sequence the channel has
entered, the termination and sequence codes are
set; command address, unit addr.ess, and unit
status validity is determined; and the sequence
code is set valid. The ECSW field in the
channel check record is moved into the IOERBLOK,
if one exists.
Before returning to
the channel control
subroutine, the 2880 routine moves the 1/0
extended logout into the channel check record
and sets the 1/0 extended logout area to ones.
ERROR
RECORDI~G
INTERFACE FOR VIRTUAL ftACHINES
The error recording interface provides a means
of recordinq errors encountered by operating
systems running in a virtual machine under
Vft/370.
If the virtual operating system is
Vft/370, it must be the Release 2.0 version or
later. An SVC 76 issued by a virtual machine is
used to signal Vft/370 that error recording is
required.
The SVC
interruption handler in
DftKPSA examines general registers 0 and 1 to
determine if valid parameters have been passed.
The error recording facility is made up of four
modules.
One module (DftKIOE)
is resident and
the other three (DftKIOC, DMKIOF, and DMKIOG) are
pageable.
The error recording modules record temporary
errors (statistical data
recording)
for CP
generated I/O except for DASD devices with a
buffered log.
The error recording routines record:
unit
checks,
statistical data
counter
overflow
records, selected temporary DASD errors, machine
checks,
channel
~hecks,
and
hardware
environmental counter sense data on the error
recording cylinders of
the system resident
device in a format suitable for subsequent
processing by the CPEREP program. The recorder
asynchronously updates the
statistical data
counters for supported devices.
The recorder
also initializes the error recording cylinders
at IPL if they are in an unrecognizable format.
When the recorder is entered from DftKIOS, it
is entered at DftKIOERR. This entry is used for
unit checks and channel data checks.
A test is
made of
the failing CSW
(located
in the
IOERBLOK)
to see if the error was a channel
error. If it was, control is passed to routine
for recording channel checks.
The IOERBLOK sense data, IOBLOK flags, and
VftBLOK privilege class are examined to deter.ine
if the error should be recorded.
ERROR RECORD WRITING
After an error record is formatted, it is added
to the error recording cylinder using DftKRPAGT
Section 1. Introduction
107
and DMKRPAPT.
The error recording cylinders
have page sized records (4096 bytes). Each page
contains a header (8 bytes) which signifies: the
cylinder and page number of the page (4 bytes),
the next available space for recording within
page
(2
bytes), a page in-use indicator
(1
byte), and a flag byte.
Bach record within the
page is recorded with a 4-byte prefix.
If an error record is too large to be added
into a page, a new page is retrieved, updated
with record,
and placed back on the error
recording cylinder with the paging routines.
Two cylinders are used for error recording:
one cylinder is used exclusively for recording
the I/O errors and the other cylinder for
recording MCH/CCH errors.
The cylinders that
are used for error recording are specified by
the user at system generation time.
If either
error recording cylinder becomes 90 per cent
full, a message is issued to the operator using
DMKQCNWT to warn him of the condition.
If
either cylinder becomes full, another message is
issued to inform the operator and recording is
stopped on that cylinder.
Recording continues
on the cylinder that is not full.
If a channel check error is to be recorded,
the recorder is entered at DMKIOERR or DMKIOECC.
The channel check handler determines the entry.
A channel check error record is formatted.
A machine check enters at DMKIOEMC.
Pointers
are passed from the machine check handler in
registers 6 and 7 to locate a buffer where the
machine check record and length are saved. A
machine check error record is recorded with the
saved machine
check logout
and additional
information. The machine check error record is
written onto the error recording cylinder by
using the paging routines.
Hardware environmental counter records are
formed using routine DMKIOEEV.
This routine is
scheduled by DMKIOS after control is returned
from the ERP. Sense data information is stored
in the IOERBLOK by the BRP. The record formed
is called a nonstandard record.
recording.
The paging routines, DMKRPAPT and
DMKRPAGT, are used to read the error recording
cylinder's pages
(4096 byte records).
As each
page record is read, it is examined to see if
this record is the last recorded.
If so,
a
pointer in storage is saved so recording can
continue on that page record.
Control is then
returned to
the caller.
If
either error
recording cylinder is
in an unrecognizable
format,
that
cylinder
is
automatically
reformatted by CPo
DASD ERROR RECOVERY, ERP (DMKDAS)
Error recovery is attempted for CP initiated I/O
operations to its supported devices and for
user-initiated
operations to
CP
supported
devices that use a DIAGNOSE interface. The
primary control blocks used for error recovery
are the RDEVBLOK, the IOBLOK and the IOERBLOK.
In addition, auxiliary storage is sometimes used
for
recovery
channel programs
and
sense
buffers.
The initial error is first detected by the
I/O interruption handler which performs a SENSE
operation if a unit check occurs.
Unit check
errors are then passed to an appropriate RRP.
If a channel check is encountered, the channel
check interruption handler determines whether or
not retry is possible and passes control to an
ERP through the I/O interruption handler.
DASD
errors are processed as described below.
•
Channel control check is treated
check. It is retried 10 times.
as
seek
•
Interface control check is treated as
check.
It is retried 10 times.
seek
•
Channel data check is treated as data check.
It is retried 10 times.
~g.YiE!!!.!!!
DMKIOEPM is called by the CPEREP program via a
DIAGNOSE instruction. DMKIOEFM is invoked to
reset the specified error recording cylinders
(if
CLEARALL,
CLEARIO,
or
CLEARMC
was
specified). The clear is performed by resetting
each page-header, space-available
field.
A
pointer in storage is then updated to point to
the first page on the error r~cording cylinder
available for recording MCH and CCH records and
the first page available on the other error
recording
cylinder for
recording
outboard
errors. Control is then returned to the calling
routine.
£.b!!£!: Retry the operation 10 times
for 3330,
3340, 3350, and 2305 devices; twice
for the 2314 and 2319.
No record !2Y.!!S !ng
Recallbrate and retry
times (2314/2319).
No record found: Execute a READ HOME ADDRESS and
check--home-address against seek address.
If
they are the same, consider the error permanent.
If they are not equal recalibrate and retry the
channel program 10 times (2314/231~. For other
devices, return to caller.
~!!!!!
£.b!!£!: Retry the
that 3330/3350 seek
hardware.
DMKIOEPL is called by DMKCPI to find the first
available page that can be used' for error
108
,mis§i.!!g ,2SSI!!§§ ma:rks:
the channel progrii--~O
operation 10 times except
checks
are retried by
!.!!!!!I!!!ntiE.!! I!!g.Yi!~~:
Issue a
message to
console and wait for solicited device end. This
procedure is repeated once.
IBM VM/370: System Logic and Problem Determination Guide
~~§ Q~! £~~£!:
One retry of the operation.
Q~i~ £h~£~§:
For 2314/2319 retry the operation
256 times, with a recalibrate being executed
every 16th time. For the 2305/3340, retry the
operation 10 times. For the 3330/3350, the
operation is retried by hardware.
Q~~~~B~:
Retry the operation 10 times.
~!22!ng ~~~~~§§
m2~~~~:
Retry the
operation 10
times.
~Q!~2ng ~~j~£!:
The command is not retried.
f~~i~i~g £h~£!:
Test for command reject.
present, retry the operation 10 times.
If not
Environmental s~!~ E~~2~ni:
Issue a
UNLOAD-command and retry the operation.
BUFFER
back when the task has finished.
This enables
the Eap to receive control even if the retry was
successful and allows the freeing of all storage
gotten for CCWs and temporary buffers. The
IOBRCAW is set to the recovery CCW string
address.
In
handling
an
intervention
required
situation, the ERP sends a message to the
operator and then waits for the device end to
arrive. This is accomplished by a return to
DKKIOS with the ERP bit in the IOBSTAT field set
on and the IOBSTRT bit in the IOBFLAG field set
off. When the device end interruption arrives,
the
original
channel
program
which
was
interrupted is then started.
The ERP flags of the IOERBLOK are also used
to indicate when special recovery is being
attempted. For example, a READ HOKE ADDRESS
command when a no record found error occurs.
!~~£!
condition check: This error should not
occur. CP-does--not-use alternate tracks in its
paging or spooling management. When a disk pack
is formatted, any track that is marginal 1S
marked as permanently allocated and, therefore,
made unavailable for use by CPo
The error recovery routine keeps track of the
number of retries in the IOBRCNT field of the
IOBLOK. This cQunt determines if a retry limit
has been exeeded for a particular error. On
initial
entry from
DMKIOS
for an
error
condition, the count is zero.
Each time a retry
is attempted the count is increased by one.
The ERP preserves the original error CSW and
sense information by placing a pointer to the
original IOERBLOK in the RDEVBLOK. Additional
IOERBLCKs, which are received from DKKIOS on
failing restart attempts, are discarded. The
original
IOERBLOK
is thus
preserved
for
recording purposes.
The other two indicators are self explanatory
and are explained in Figure 20.
I
1________ I!elS ____________ 1 Action to be
IIOBSTATIIOBFLAG IIOBSTAT 1 Performed
IIOBERP IIOBRSTRT IOBFATALlby DKKIOS
------
0
o
o
0
o
0
0
1--------------
IReturn control
1 when solicited
1 device end
1 arrives
1
IRestart using
1 IOBRCAW
1
1Permanent I/O
1 Error
1
IRetry successfulll
L
Figure 20.
If after a specified number of retries,
DKKDAS fails to correct the error situation, the
operator mayor may not be notified of the error
condition.
Control is
returned to DKKIOS.
DMKIOS is notified of the permanent error by
posting the IOBLOK (IOBSTAT=IOBFATAL). The error
is recorded via DMKIOS by DKKIOERR, if DKKDAS
and DMKIOE determine that the error condition
warrants recording.
o
---,
~
Summary of lOB Indicators
If the error is uncorrectable or intervention
is required, the ERP calls DKKKSW to notify
operator. The specific message is identified in
the KSGPARK field of the IOERBLOK.
If the error is corrected by a restart, the
temporary or transient error is not recorded.
control is returned to DMKIOS witn the error
flag off.
TAPE ERROR RECOVERY, ERP (DKKTAP)
Before returning control to DMKIOS on either
a permanent error ,or a successful recovery, the
ERP frees all auxiliary storage gotten for
recovery CCWs, buffers,
and IOERBLOKs, and
updates the statistical counters for 2314 and
2319 devices.
Error recovery is attempted for user-initiated
tape I/O operations to CP supported devices that
use the DIAGNOSE interface. The primary control
blocks used for error recovery are the RDEVBLOK,
the IOBLOK, and the IOERBLOK.
In addition,
auxiliary storage is used for recovery channel
programs (repositioning and erase) •
The DMKIOS interface with the ERP uses the
IOBSTAT and lOB FLAG fields of the IOBLOK to
determine the action required when the Bap
returns to DMKIOS.
When retry is to be attempted the ERP turns
on the restart bit of the IOBFLAG field. The Eap
bit of IOBSTAT field is also turned on to
indicate to DMKIOS that the ERP wants control
The interruption handler, DKKIOS, performs a
SENSE operation when a unit check occurs. Tape
errors are then passed to D!KTAP. The sense
information associated with a unit check is
contained in the IOERBLOK. If a channel check is
encountered, the channel
check interruption
handler determines if retry is possible and
passes control to the RRP through the I/O
interruption handler.
section 1. Introduction
109
When an error is encountered and ERP receives
control, DMKTAP determines if this is the first
entry into the ERP for this task. The IOBRCNT
(lOB error count) field of the lOB is zero on
initial entry. On this first entry, the pointer
to the IOERBLOK is placed in the RDEVIOER field
of the RDEVBLOK. This preserves the original
error CSW and sense information for recording.
Thereafter, IOERBLOKS are discarded before a
retry is attempted or a permanent error is
passed to lOS.
The ERP
looks for
two other
specific
conditions. If the error count field is not
zero, entry must be due to a recovery attempt.
Thus, it may be a solicited device end to
correct an intervention required condition or a
retry attempt for either tape repositioning or
channel program re-execution.
The ERP keeps track of the number of retries
in the IOBRCNT field of the IOBLOK to determine
if a retry limit has been exceeded for a
particular error. If the specified number of
retries fails to correct the error, the error is
recorded and DMKIOS is notified of the permanent
error by turning on a status flag in the IOBLOK
(IOBSTAT=IOBFATAL) •
If the error is corrected by DMKTAP, the
temporary error is not recorded and control is
returned to DMKIOS with error flags all off.
When repositioning is required in order to
attempt recovery, additional
ERP flags are
contained in the IOERBLOK to indicate paths for
specific errors
(that is, data check on write
must
reposition, erase,
and then
reissue
original channel program).
All error recovery is started the same except
for intervention required errors.
The IOBFLAG
is
turned
on
to
indicate
RESTART
(IOBFLAG=IOBRSTRT), and the
IOBRCAW
(IOBLOK
Restart CAW) is filled with the restart channel
address word.
In addition, an IOBSTAT flag is
turned on to indicate that the ERP is in control
so that control can be returned to ERP during
all tape error recovery (IOBSTAT=IOBERP). In the
case of an intervention required error, the ERP
sends a message to the operator, and then
returns to DMKIOS with indications that tell
DMKIOS the ERP is waiting for a device end on
this device.
This is done by clearing the
restart flag and returning to DMKIOS with only
the LOBERP flag on.
When ERP has determined a permanent error
situation or successfully recovered from an
error, all
auxiliary storage
obtained for
recovery CCWs, buffers, and IOERBLOKs is freed
before a return is made to DMKIOS (see Figure 23
for a summary of the lOB indicators), also, the
statistical counters for 2400, 3410, and 3420
devices are updated.
3270 REMOTE SUPPORT ERROR RECOVERY
Recovery from errors associa ted with bisync
lines, and the related channel and transmission
control unit hardware is processed by DMKBSC.
Recovery from errors associated with data and
control processing by the remote station
(the
device) as defined by remote status and sense
byte definition
(see lIB:!.
l£IQ lnf.Q~.!!!B:!.!.Q1!
.Qi~E!B:I
£Q!!EQn~n:!:.
~~2£!:iE:!:.iQn,
Order
No.
GA27-2749)
is processed by DMKRGF.
,Control
blocks associated with these errors are the
CORTASK, the RDEVBLOK, the BSCBLOK, the NICBLOK,
the IOBLOK, and the IOERBLOK.
The interruption handler, DMKIOS, performs a
SERSE operation upon detection of a unit check
condition (IOERBLOK). The related sense data is
analyzed as it relates to the previous operation
(CORTASK or BSCBLOK, whichever is applicable).
If a channel check is encountered by the channel
check interruption handler, the channel check
interruption
(DMKBSC) procedures determine if
recovery can be attempted.
If it cannot be
retried, that operation is
aborted and an
appropriate message is sent
to the system
operator.
Depending on the
error encountered, ERP
receives control and either DMKBSC or DMKGRA and
DMKGRB determines if this is the first entry
into the ERP for this task.
The IOBRCRT (lOB
error count) field of the lOB is zero on initial
entry. On this first entry,
the pointer to the
IOERBLOK is placed in the RDEVIOER field of the
RDEVBLOK.
This preserves the original error CSW
and
sense
information
for
recording.
Thereafter, IOERBLOKs are discarded before a
retry is attempted or a permanent error is
passed to lOS.
The ERP
looks for
two other
specific
conditions.
If the error count field is not
zero, entry must be due to a recovery attempt.
Thus, it may be a solicited device end to
correct an intervention required condition or a
retry attempt channel program re-execution.
The ERP keeps track of the number of retries
in the IOBRCRT field of the IOBLOK to determine
if a retry limit has been exceeded for a
particular error.
If the specified number of
retries fails to correct the error, the error is
recorded and DMKIOS is notified of the permanent
error by turning on a status flag in the IOBLOK
(IOBSTAT=ICSFATAL).
If the error is corrected, the temporary
error is not recorded and control is returned to
DMKIOS with error flags all off.
When ERP has determined a permanent error
situation or successfully recovered from an
error, all
auxiliary storage
obtained for
recovery CCWs, buffers, and IOERBLOKs is freed
before a return is made to'DMKIOS (see Figure 23
for a summary of the lOB indicators).
Also, the
statistical counters for 3270 are updated.
If the error is uncorrectable or operator
intervention is necessary, ERP calls the message
writer to write the specific message.
110
IBM VM/370: System Logic ann Problem Determination Guide
Reference.
processing.
•
•
•
•
Introduction to CMS
Interruption handling
Functional information (how C"S works)
Register usage
DMSNUC structure
storage structure
Free storage management
SVC handling
os macro simulation
The Conversational Monitor System (CMS), the
major
subsystem
of
V"/370,
provides
a
comprehensive set of conversational facilities
to the user.
Several copies of CMS may run
under CP, thus providing several users with
their own time-sharing system.
CMS is designed
specifically for the V"/370 virtual machine
environment.
Each copy of CMS supports a single user.
This means that the storage area contains only
the data pertaining to that user.
Likewise,
each CMS user has his own machine configuration
and his own files. Debugging is simpler because
the files and storage area are protected from
other users.
programs can be debugged from the terminal.
The terminal is used as a printer to examine
limited amounts
of data.
After examining
program data, the terminal
user can enter
commands on the terminal to alter the program.
CMS, operating with CP, is a time-sharing
system suitable for problem solving, program
development, and general work.
It includes
several programming language processors, file
manipulation commands, utilities, and debugging
aids.
Additionally,
CMS can
simplify the
operation of other operating
systems in a
virtual machine environment ~hen controlled from
a remote terminal. For example, CMS can create
and modify job streams,' and to analyze virtual
printer output.
Part of the CMS environment is related to the
virtual machine environment created by CPo Each
user is completely isolated from the activities
of all other users, and each machine in which
CMS executes has virtual storage available to it
and managed for it.
The CP commands are
recognized by CMS. For example, the commands
allow messages to be sent to the operator or to
other
users, and
virtual
devices to
be
dynamically detached from the virtual machine
configuration.
THE CMS COMMAND LANGUAGE
The CMS command language offers terminal users a
wide range of functions.
It supports a variety
of programming languages, service functions,
file manipulation, program execution control,
and general system control.
The CMS commands
that are useful in debugging are discussed in
"Debugging with CMS" in this section.
For
detailed information on all other CMS commands,
refer to the !~L~IQ: ~~~ ~2~~sBg sBg ~s£!2
Figure
23
describes
CMS
command
THE FILE SYSTEM
CMS interfaces with virtual disks, tapes, and
unit record equipment. The CMS residence device
is kept as a read-only, shared, system disk.
Permanent user files may be accessed from up to
nine active disks. CMS controls logical access
to those virtual disks, while CP facilities
manage the device sharing and virtual-to-real
mapping.
User files in CMS are identified with three
designators: the filena.e, the filetype, which
can imply specific file characteristics to the
CMS file management routines, and the filemode,
which describes the location and access mode of
the file.
The compilers available under CMS default to
particular input filetypes, such as ASSEMBLE,
but the file manipulation and listing commands
do not. Files of a particular filetype form a
logical data library for a user; for example,
the collection of all COBOL source files, or of
all object
(TEXT)
decks, or of
all EXEC
procedures. This allows selective handling of
specific groups of files with minimum input by
the user.
User files can be created directly from the
terminal with the CMS EDIT facility.
EDIT
provides extensive context editing services.
File characteristics such as record length and
for.at, tab locations, and serialization options
can be specified. The system includes standard
definitions for certain filetypes.
CMS automatically allocates compiler work
files at the beginning of command execution on
whichever active disk has the greatest amount of
available
space, and
deallocates them
at
completion. Compiler object decks and listing
files are normally allocated on the same disk as
the input
source file or on
the primary
read/write disk, and are identified by combining
the input filename with the filetypes TEXT and
LISTING. These disk locations may be overridden
by the user.
A single user file is limited to a maximum of
65533 records and must reside on one virtual
disk.
The file management system limits the
number of files on anyone virtual disk to 3400.
All CMS disk files are written as 800-byte
records, chained together by a specific file
entry that is stored in a table called the
master file directory; a separate master file
directory is kept for,
and on, each virtual
disk. The data records may be discontiguous,
and
are
allocated
and
deallocated
automatically.
A subset of the master file
directory (called the user file directory)
is
made resident in virtual storage when the disk
directory is made available to CMS; it is
updated on the virtual disk at least once per
command if the status of any file on that disk
has been changed.
section 1. Introduction
111
Virtual disks may be shared by CMS users; the
facility is provided by VM/370 to all virtual
machines, although a user interface is directly
available in CMS commands. Specific files may
be
spooled
between
virtual
machines
to
accomplish
file
transfer
between
users.
Commands allow
such file
manipulations as
writing from an entire disk or from a specific
disk file to a tape, printer, punch, or the
terminal.
other commands write from a tape or
virtual card reader to disk, rename files, copy
files, and erase files.
Special macro libraries
and text or program libraries are provided by
CMS, and special commands are provided to update
and use them. CMS files can be written onto and
restored from unlabeled tapes via CMS commands.
~~Y!!Q~:
Multiple write access
produce unpredictable results.
under CMS
can
Problem programs which execute in CMS can
create files on unlabeled tape in any record and
block size; the record format can be fixed,
variable, or undefined. Figure 21 describes the
CMS file system.
PROGRAM DEVELOPMENT
CMS includes commands to create and compile
source programs, to modify and correct source
programs, to build test files, to execute test
programs and to debug from the terminal. The
commands of CMS are especially useful for as and
DOS/VS program development, but also may be used
in combination with other operating systems to
provide a virtual machine program development
tool.
CMS utilizes the as and DOS/VS compilers via
interface modules; the
compilers themselves
normally are not changed. To provide suitable
interfaces, CMS includes a certain degree of as
and DOS/VS simulation.
The sequential, direct,
and partitioned access methods are logically
simulated; the data records are physically kept
in the
chained 800-byte blocks
which are
standard to CMS, and are processed internally to
simulate as data
set characteristics.
CMS
supports VSAM catalogs, data spaces, and files
on as and DOS disks using the DOS/VS Access
Method Services.
as SVC functions such as
GETMAIN/FREEMAIN and TIME are simulated.
The
simulation restrictions concerning what types of
as object programs can be executed under CMS ar€
primarily related to the as/pcp, MFT, and MVT
Indexed Sequential Access Method
(ISAM) and the
telecommunications
access
methods,
while
functions related to multitasking in as and
DOS/VS are ignored by CMS.
INTERRUPTION HANDLING IN CMS
CMS receives virtual SVC, input/output, program,
machine, and external interruptions and passes
control to the appropriate handling program.
112
The
Conversational Monitor
System is
SVC
(supervisor call) driven. s'c interruptions are
handled by the DMSITS resident routines.
Two
types of SVCs are processed by DMSITS: internal
linkage SVC 202 and 203, and any other SVCs.
The internal linkage SVC is issued by the
command and function programs of the system when
they require the services of other CMS programs.
(Commands entered by the user from the terminal
are converted to the internal linkage SVC by
DMSINT) •
The
OS SVCs are issued
by the
processing
programs
(for
example,
the
Assembler).
INTERNAL LINKAGE ~!~~: When DMSITS receives
controj-as-a--result of an internal linkage SVC
(202 or 203), it saves the contents of the
general registers, floating-point registers, and
the SVC old PSW, establishes the normal and
error return addresses, and passes control to
the specified routine. (The routine is specified
by the first 8 bytes of the parameter list whose
address is passed in register 1 for SVC 202, or
by a halfword code following SVC 203.)
For SVC 202, if the called program is not
found in the internal function table of nucleus
(resident)
routines,
then DMSITS attempts to
call in a module
(a CMS file with filetype
MODULE) of this name via the LOADMOD command.
If the program was not found in the function
table, nor was a module successfully loaded,
DMSITS returns an error indicator code to the
caller.
To return from the called program, DMSITS
restores the calling program's registers, and
makes the appropriate normal or error return as
defined by the calling program.
QI~~R ~!~~:
The general approach taken by DMSITS
to process other SVCs supported under CMS is
essentially the same as that taken for the
internal linkage SVCs. However, rather than
passing control
to a command
or function
program, as is the case with the internal
linkage SVC, DMSITS passes
control to the
appropriate routine. The S'C number determines
the appropriate routine.
In handling non-CMS SVC calls, DMSITS refers
first to a user-defined SVC table (if any -- set
up by the DMSHDS program).
If the user-defined SVC table is present, any
SVC number (other than 202 or 203) is looked for
in that table.
If it is found, control is
transferred to the routine at the specified
address.
If the SVC number is not found in the
user-defined SVC table (or if the table is
nonexistent), the standard system table of as
calls is searched for that SVC number.
If the
SVC number is found, control is transferred to
the corresponding address in the usual manner.
If the SVC number is not in either table, then
the supervisor call is treated as an ABEND
call.
IBM VM/370: system Logic and Problem Determination Guide
DMSII:UC Area of Storage
til
~
til
..
t+
CD
til
CD
o
t+
1-1'
o
I:'
H
I:'
t+
t1
o
~
c:
o
....t+
o
I:'
...
W
Free Storage
Disk Storage
The DMSHDS initialization program sets up the
user-defined SVC table. It is possible for a
user to provide his own SVC routines.
All input/output interruptions are received by
the I/O interrupt handler, DMSITI. DMSITI saves
the I/O old PSi and the CSi (channel status
word) •
It then determines
the status and
requirements
of
the
device
causing
the
interruption and passes control to the routine
that processes interruptions from that device.
DMSITI scans the entries in the device table
until it finds the one containing the device
address that is the same
as that of the
interrupting device. The device table (DEVTAB)
contains an entry for
each device in the
system.
Each entry for a particular device
contains, among other things, the address of the
program that processes interruptions from that
device.
When the
appropriate interrupt
handling
routine completes its processing, it returns
control to DMSITI. At this point, DMSITI tests
the wait bit in the saved I/O old PSi. If this
bit is off, the interruption was probably caused
by a terminal
(asynchronous)
I/O operation.
DMSITI then returns control to the interrupted
program by loading the I/O old PSi.
status is present with attention and a write ccw
was terminated, its buffer is unstacked.
An
attention interrupt causes a read to be issued
to the terminal, unless attention exits have
been queued via the STAX, macro. The attention
exit with the highest ,-r'Iority is given control
at each attention until the queue is exhausted,
then a read is issued.
Device end status
indicates that the last I/O operation has been
completed.
If the last I/O operation was a
write, the line is deleted from the output
buffer and the next write, if any, is started.
If the last I/O operation was a normal read, the
buffer is put on the finished read list and the
next
operation is started.
If the read was
caused by an attention interrupt, the line is
first checked for the commands RT~ HO, HT, or
HX, and the appropriate flags are set if one is
found.
Unit exception indicates a canceled
read. The read is reissued, unless it had been
issued with ATTREST=NO, in which case unit
exception is treated as device end.
~~!Q~~LgY!£~LE~!!I~~_!!I~~~YE1!~~~:
Interruptions from these devices are handled by
the
routines
that
actually
issue
the
corresponding
I/O
operations.
When
an
interruption from any of these devices occurs,
control passes to DMSITI.
Then DMSITI passes
control to DMSIOW, which returns control to the
routine that issued the I/O operation.
This
routine can then analyze the cause of the
interrupti en.
y§~] £Q!!~Q~~~Q Qj!l£~ !~I~RRQgI!Q!§:
If the wait bit is on, the interruption was
probably caused by a nonterminal (synchronous)
I/O operation.
The program that initiated the
operation most likely called the DMSIOi function
routine to wait for
a particular type of
interruption (usually a device end.)
In this
case, DMSITI checks the pseudo-wait bit in the
device table entry for the interrupting device.
If this bit is off, the system is waiting for
some event other than the interruption from the
interrupting device; DMSITI returns to the wait
state by loading the saved I/O old PSi.
(This
PSi has the wait bit on.)
If the pseudo-wait bit is on, the system is
waiting for an interruption fro. that particular
device.
If this interruption is not the one
being waited for, DMSITI loads the saved I/O old
PSi. This will again place the machine in the
wait state.
Thus, the program that is waiting
for a particular interruption will be kept
waiting until that interruption occurs.
If the interruption is the one being waited
for, DMSITI resets both the pseudo-wait bit in
the device table entry and the wait bit in the
I/O old PSi.
It then loads that PSi.
This
causes control to be returned to the DMSIOi
function routine,
which, in
turn, returns
control to the program that called it to wait
for the interruption.
TERMINAL INTERRUPTIONS: Terminal input/output
Interruptions-are-handled by the DMSCIT module.
All interruptions other than those containing
device end, channel end, attention, or unit
exception status are ignored.
If device end
114
Interrupts
from devices under user control are serviced the
same as CMS devices except that DMSIOW and
DMSITI manipulate a user created device table,
and DMSITI passes control to any user written
interrupt processing routine that is specified
in the
user device table.
Otherwise, the
processing program regains control directly.
The
program interruption
handler,
DMSITP,
receives control when a program interruption
occurs. When DMSITP gets control, it stores the
program old
PSi and the contents
of the
registers 14, 15, 0, 1, and 2 into the program
interruption element (PIE).
(The routine that
handles the SPIE macro instruction has already
placed the address of the program interuption
control area
(PICA) into PIE.)
DMSITP then
determines whether or not the event that caused
the interruption was one of those selected by a
SPIE macro instruction. If it was not, DMSITP
passes control to the DMSABR ABEND recovery
routine.
If the cause of the interruption was one of
those selected in a SPIE macro instruction,
DMSITP picks up the exit routine address from
the PICA
and passes control to
the exit
routine.
Upon return from the exit routine,
DMSITP returns to the interrupted program by
loading the original program check old PSW. The
address field of the PSi was modified by a SPI!
exit routine in the PIE.
IBM VM/370: System Logic and Problem Determination Guide
On return
contains:
An external interruption causes control to be
passed to the external interrupt handler DMSITE.
If the user has issued the HNDEXT macro to trap
external interrupts, DMSITE passes control to
the user's exit routine.
If the interrupt was
caused by the timer, DMSITE resets the timer and
types the BLIP character at the terminal. The
standard BLIP timer setting is two seconds, and
the standard ELIP character is upper case,
followed by the lower
case
(it moves the
typeball without printing).
otherwise, control
is passed to the DEBUG routine.
Hard machine check interruptions on the real
are not reflected to a CMS virtual user by
A message prints on the console indicating
failure.
The user is then disabled and must
CMS again in order to continue.
CPU
CPo
the
IPL
FUNCTIONAL INFORMATION
The most important thing to remember about CMS,
from a debugging standpoint, is that it is a
one-user system. The supervisor manages only
one user and keeps track of only one user's file
and storage chains. Thus, everything in a dump
of a particular machine relates only to that
virtual machine's activity.
You should be familiar with register usage,
save
area structuring,
and control
block
relationships before attempting to debug or
alter CMS.
fro.
a
routine,
register
15
Return
Code
---0-(0
)0
~~~~i~g
NO error occurred
Called routine not found
Error occurred
If a CMS routine is called by an SVC 202,
registers 0 through 14 are saved and restored by
CMS.
Most CMS routines
register.
use register 12 as
a base
DMSNUC is the portion of storage in a CMS
virtual machine that contains system control
blocks, flags, constants, and pointers.
The CSECTs in DMSNUC contain only symbolic
references.
This means that
an update or
modification to CMS, which changes a CSECT in
DMSNUC, does not automatically force all CMS
modules to be recompiled.
Only those modules
that refer to the area that was redefined must
be recompiled.
The USERSECT CSECT defines space that is not
used by CMS.
A modification or update to CMS
can use the 18 fullwords defined for USERSECT.
There is a pointer (AUSER)
in the NUCON area to
the U3er space.
The DEVTAB CSECT is a table describing the
devices available for the CMS system. The table
contains the fcllowing entries:
When a CMS routine is called, Rl must point to a
valid parameter list (PLIST) for that program.
On return, RO mayor may not contain meaningful
information (for example, on return from a call
to FILEDEF with no change, RO will contain a
negative address if a new FCB has been set up;
otherwise,
a positive address of the already
existing FCB).
R15 will contain the return
code, if any.
The use of Registers 0 and 2
through 11 varies.
On entry
SVC 202:
B~g!2i~E
1
12
13
14
15
to a command
or routine
called by
Contents
The-address of the PLIST supplied
by the caller
The address entry point of the
called routine
The address of a
work area
(12
doublewords) supplied by SVCINT
The return address to the SVCINT
routine
The entry point
(same as register
12)
•
•
•
•
•
•
1
10
1
1
1
4
console
disks
reader
punch
printer
tapes
You can change some existing entries in
DEVTAB.
Each device table entry contains the
following information:
•
•
•
•
•
virtual device address
Device flags
Device types
symbol device name
Address of the interrupt
(for the console)
processing routine
The virtual address of the console is defined
at IPL time. The virtual address of the user
disks can be altered dynamically with the ACCESS
command. The virtual address of the tapes can
be altered in the device table.
Changing the
virtual address of the reader, printer, or punch
will have no effect.
section 1. Introduction
115
•
STRUCTURE OF CMS STORAGE
Figure 22 describes how CMS uses its virtual
storage.
The pointers
indicated
(MAINSTRT,
are all found
"AINHIGH, FREELOWE, and FREEUPPR)
in NUCON (the nucleus constant area).
The sections
following uses:
•
DMSHUC
of
CMS
storage
have
the
Low
Storage DMSFBEE
Free Storage
{Approximately X'03000' to X'OEOOO'
Area
This area is a free storage area, from which
requests from DMSFREE are allocated. The top
part of this area contains the File Directory
for the System Disk {SST AT).
If there is
enough room (as there will be in most cases) ,
the FREETAB table also occupies this area,
just below the SSTAT.
•
•
Transient Program Area (X'OEOOO' to X'10000')
The top of storage is occupied by the Loader
Tables that are required by the CMS loader.
These tables indicate
which modules are
currently loaded in the User Program Area
(and the Transient Program Area after a LOAD
COMMAND). The size of the Loader Tables can
be varied
by the SET
LDRTBLS command.
However, to successfully change the size of
the Loader Tables, the SET LDRTBLS com.and
must be issued immediately after IPL.
FREE STORAGE MANAGEMENT
Free storage can be allocated by the GETMAIN or
DMSFREE macros.
Storage allocated
by the
GETMAIN macro is taken from the user program
area, beginning after the high-address of the
user program.
Storage allocated by the DMSFREE macro can be
taken from several areas.
If possible,
DMSFREE requests are allocated
from
the
low-address free
storage
area.
Otherwise, DMSFREE requests are satisfied from
the storage above the user program area.
Because it is not essential to keep all
nucleus functions resident in storage all the
time, some of them are made "transient."
This means that when they are needed, they
are loaded from the disk into the Transient
Program Area.
Such programs may not be
longer than two pages,
because that is the
size of the Transient Area.
(A page is 4096
bytes of virtual storage.)
All transient
routines must be serially reusable since they
are not read in each time they are needed.
There are two types of DHSFREE requests for
free storage: requests for USER storage and
NUCLEUS storage.
Because the two types of
storage are kept in separate 4K pages, it is
possible for storage of one type to be available
in low storage, while no storage of the other
type is available.
CMS Nucleus (X'10000' to X'20000')
All GETMAIN storage is allocated in the user
program area, starting after the end of the
user's actual program. Allocation begins at the
location pointed
to by the
NUCON pointer
MAINSTRT. The location MAIN HIGH in NUCON is the
"high-extend" pointer for GETMAIN storage.
Segment 1 of storage contains the reenterable
code for the CMS Nucleus routines.
In shared
CMS systems, this is the "protected segment."
That is, this segment must consist only of
reenterable code, and may not be modified
under any circumstances. This fact implies
certain system restrictions for functions
which require that storage be modified, such
as the fact that DEBUG breakpoints or CP
address stops cannot be
placed in this
segment, in a saved system.
User Program Area (X'20000' to Loader Tables)
User programs are loaded into this area by
the LOAD command. Storage allocated by means
of the GETMAIN macro instruction is taken
from this area, starting
from the high
address of the user program. In addition,
this storage area can be allocated from the
top down by DMSFREE, if there is not enough
storage available in the low DMSFREE storage
area.
Thus the usable size of the User
Program Area is reduced by the amount of free
storage which has been allocated from it by
DMSFREE.
116
(Top pages of storage)
(X'OOOOO' to approximately X'03000')
This area contains pointers, flags, and other
data updated by the various system routines.
•
Loader Tables
Before issuing any
GETMAIN macros, user
programs must use the STRINIT macro to set up
user free storage pointers. The STRINIT macro is
issued only once, preceding the initial GETMAIN
request. The format of the STRINIT macro is:
r-------------------·--------------,
I
I
I r
r"
I
I [label] I STRINIT I ITYPCALL=I~!~ II
I
I
I
I I
I BALR II
I
IL__________________________________
I
ILL.J.J
- - JI
r
,
I
IBALRI
L
.J
indicates how control is passed to
DMSSTG, the routine that processes the
STRINIT macro. Because DMSSTG is a
TYPCALL=I~!~
IBM VM/370: System Logic and Problem Determination Guide
CONTROL BLOCKS
INFREESTORAGE-------.
VIRTUAL
STORAGE
ENDOFSTORAGE~---------------------------------
System Loader Table (Size determined
by SET LDRTBLS command) Storage Key = X'F'
FREEUPPR----~~----------------------~~----~
DMSFREE requests when
no more low storage available
FREELOWE -----+-- -
- - - - - - --
BBG
BEJG
Unused portion of User
Program Area
DMSNUC
MAINHIGH _ _ _+_ __
GETMA:
MAINSTRT---~.-
-
-
''"u:,~
--- -
--- J.,:.:Storage Key; X'E'
-
-
_L ~~ ~~
, . . . . - - - - - - - - - . . . . . , X'3000'
USERSECT
_____________
---1 X'2ADS'
SUBSECT
_____________
---1 X'2A40'
TSOBLKS
-------------1 X'29BO'
OPSECT
The User's Program
(program is loaded via the
LOAD command)
---------------1 X'2S00'
DMSABW
-----------1 X'2360'
-----------~X'2300'
X'20000'~--------------------S-to-r-a~ge--K-e~y-=-X-'E~'
CMS Nucleus
In "saved systems" this area
is a protected segment
(that is, all code must be
reentrant and cannot be
modified)
X'1 0000 -11----------------------=----'------4
Transient Program Area
X'EOOO'--II---------------:..---Low Storage OMS F R EE Free Storage Area
DMSFREE requests are filled from
this area. The upper part of this
area contains the System Disk MFD
followed by the FREETAB, if there is
enough room.
X'3000'-+------------------S-t-or-a~g-e-K-e~y-=-X--'E-'-0-r-X-'-F_'
DMSNUC
System Control Blocks, flags, constants,
and pointers.
X'O'--~--------------------~~~-----
*The half-page containing OPSECT and TSOBLOKS
has a storage key = X'E'
- - - - - - - - - - - 1 X'2190'
-----------IX'1DDO'
1---------------IX'1CCS'
FVS
I----------------t X'1ADS'
DIOSECT
"""--------------------t X'19ES'
SVCSECT
X'174S'
----------------------t
--------------------1 X'16BO'
---------------------1 X'1620'
---------------------1 X'1550'
- - - - - - - - - - - - 1 X'1200'
----------------1 X'DFO'
------------------1 X'C90'
--------------------1 X'700'
---------------------1 X'600'
-----------------------1 X'2EO'
NUCON
Figure 22.
eMS Storage Map
Section 1. Introduction
111
Refer to Figure 22 for a description of CMS
virtual storage usage.
The format of an element on the GETMAIN free
element chain is as follows:
nucleus-resident
routine,
other
nucleus-resident routines can branch
directly to it
(TYPCALL=BALR)
while
routines that are not nucleus-resident
must use linkage SVC (TYPCALL=SVC). If
no operands are specified the default
is TYPCALL=SVC.
r--------~------_y_----~------_,
0(0)
When the STRINIT macro is executed, both
MAINSTRT and MAINHIGH are initialized to the end
of the user's program, in the user program area.
As storage is allocated from the user program
area to satisfy GETMAIN requests, the MAINHIGH
pointer is adjusted upward.
Such adjustments
are always in multiples of doublewords, so that
this
pointer is
always
on a
doubleword
£oundary.
As the allocated storage is released,
the MAINBIGH pointer is adjusted downward.
4 (4)
I FREPTR -- pointer to next free
I
I
element in the chain, or 0
I
if there is no next element
I
I
1------1------1----1
-I
I FRELEN -- length, in bytes, of
I
I
this element
I
I
I
1--------1------1-----1----1
I
Remainder of this free element
I
>
>
>
<
<
<
The pointer MAINHIGB can never be higher than
FREELOWE, the "low-extend" pointer for DMSFREE
storage allocated in the user program area.
If
a GETMAIN request cannot be satisfied without
extending MAINHIGH
above FREELOWE,
GETMAIN
takes
an
error
exit,
indicating
that
insufficient storage is available to satisfy the
request.
When issuing a variable length GETMAIN, six
and a half pages are reserved for CMS usage;
this is a design value.
A user who needs
additional reserved pages (for example, for
larger directories)
should free up some of the
variable GETMAIN storage from the high end.
The area between MAINSTRT and MAINHIGH may
contain
blocks of
storage
that are
not
allocated, and that are therefore available for
allocation by a GETMAIN instruction.
These
blocks are chained together, with the first one
pointed to by the NUCON location MAINSTRT.
The DMSFREE macro allocates CMS free
The format of the DMSFREE macro is:
storage.
r--------------------------------.------------------------,
r
[label]
DMSFREE
,
DWORDS={ n } I,MIN={ n } I
(0)
I
(1)
L
r
I
.J
r
"r
r
"
L
L
.J.J
L
.J.J
r
r"
I,TYPE=IY~~R
I
II I,ERR=lladdrll
INUCLEUSII I
I ! II
I, AREA= I LOW II
I
IHIGH II
L
r
r"
I,TYPCALL=I~!f II
I
IBALRII
L
L.J.J
L
L - ___________________________________
_
L.J.J
---.--1
label
operand is not available, the Jargest
block of storage that is greatit-thari
or equal to the minimum is returned.
MIN=n specifies the minimum number of
doublewords of free storage directly
while MIN=(l)
indicates that
the
minimum is in register 1. The actual
amount of free storage allocated is
returned to the requesting routine via
general register o.
a valid assembler language label.
DWORDS={ n }
(0 )
is the number of doublewords of free
storage requested.
DWORDS=n specifies
the number of doublewords directly and
DWORDS=(O) indicates that register 0
contains the number of doublewords
requested.
r
,
TYPE=I.Y~~S
I
INUCLEUSI
MIN={ n }
( 1)
L
indicates a variable request for free
storage. If the exact number
of
doublewords indicated by the DWORDS
118
...
indicates the type of CMS storage with
which this request for free storage is
filled: USER or NUCLEUS.
IBM VM/370: System Logic and Problem Determination Guide
r
routines that are not nucleus-resident
must use linkage SVC (TYPCALL=SVC).
,
ERR=lladdrl
I .! I
J
L
is the return address if any error
occurs. "laddr" is any address that
can be referred to in a LOAD ADDRESS
(LA) instruction. The error return is
taken if there is a macro coding error
or if there is not enough free storage
available to fill the request.
If *
is specified for the return address,
the error return is the same as a
normal return.
r
,
AREA=ILOW I
IHIGHI
L
J
indicates the area of CMS free storage
from which this
request for free
storage is filled.
LOW indicates the
low storage area between DMSNUC and
the the transient program area. HIGH
indicates the area of storage between
the user program area and the CMS
loader
tables.
If
AREA is
not
specified,
storage
is
allocated
wherever it is available.
r
,
TYPCALL=I~!£
I
IBALRI
L
J
indicates how control is passed to
DMSFREE.
Because
DMSFREE
is
a
nucleus-resident
routine,
other
nucleus-resident routines can branch
directly to it
(TYPCALL=BALR)
while
The pointers FREEUPPR and PREELOWE in NUCOR
indicate the amount of storage that DMSFREE has
allocated from the high portion of the user
program area. These pointers are initialized to
the beginning of the loader tables.
The pointer PREELOWE is the "low-extend"
pointer of DMSFREE storage in the user program
area.
As storage is allocated from the user
program area to satisfy DMSFREE requests, this
pointer is adjusted downward. Such adjustments
are always in multiples of 4K bytes, so that
this pointer is always on a 4K boundary.
As the
allocated storage is released, this pointer is
adjusted upward.
The pointer PREELOWE can never be lower than
MAINHIGH, the "high-extend" pointer for GETMAIN
storage.
If
a DMSFREE request
cannot be
satisfied without
extending FREELOWE
below
MAINHIGH,
DMSPREE
takes
an
error
exit,
indicating
that
insufficient
storage
is
available to satisfy the request. Figure 22
shows the relationship of these storage areas.
The FREETAB free storage table is kept in
free storage, usually in low-storage, just below
the master file directory for the system disk
(S-disk). However, the FREETAB may be located
at the top of the user program area. This table
contains one byte for each page of virtual
storage.
Each
such byte contains
a code
indicating the use of that page of virtual
storage.
The codes in
this table are as
follows:
section 1. Introduction
119
~Q~~
USERCODE (X'Ol')
FLAGS
~~!m!!HI
The page is assigned to user
storage.
NUCCODE
(X'02')
The page is
assigned
nucleus storage.
TRNCODE
(X'03')
The page is part of
transient program area.
USARCODE
(X' 04')
The page is part of the user
program area.
SYSCODE
(X'OS')
The page is none of the
above. The page is assigned
to system storage, system
code, or the loader tables.
•
to
•
•
The
The
The
The
All completely unallocated 4K
pages are kept
on the user
chain, by convention.
Thus, if
one
of the
nucleus
chains
(low-storage or
high-storage)
contains a full page, then this
page must be transferred to the
corresponding user chain.
low-storage nucleus chain
low-storage user chain
high-storage nucleus chain
high-storage user chain
For each
of these
chains of
unallocated
ele.ents, there is a control block consisting of
four words, with the following format:
..-------------------------------,
1
POINTER -- pointer to the first 1
free element on the 1
1
chain; it is zero, if 1
1
the chain is empty.
1
o (0) 1
•
FL CL B (X • 4 0' )
Set
if
the
destroyed.
•
FLHC (X'20') -- High-storage chain.
set for both the nucleus and user
high-storage chains.
•
FLNU (X' 10') -- Nucleus chain.
for
both the
low-storage
high-storage nucleus chains •
•
FLPA
(X 'OS')
Page available.
This flag is set if there is a full
4K page available on the chain.
This flag may be set even if there
is no such page available.
1---------------------------1
4 ( 4)
1 NUM 1
the number of elements on
the c ha in.
1
1
1
1
8 (8)
1 MAX -- a value equal to or
1
greater than the size
of the largest element.
1
1
1
12 (C)
1 FLAGS- 1 SKEY - I TCODE -I Unused 1
1 Flag
1storage 1FREETAB 1
1
1 key
1 code 1
1 byte
L-_____________________________
.I1
1----------------------------1
1
1
points to the first element on this
chain of free elements.
If there are
no elements on this free chain, the
POINTER field contains all zeros.
NUM
contains the number of elements on
this chain of free elements. If there
are no elements on this free chain,
this field contains all zeros.
120
Destroyed
chain
has
flag.
been
set
and
SKEY
contains
the 1-byte
storage
key
assigned to storage on this chain.
TCODE
contains the l-byte FREETAB table code
for storage on this chain.
-----------1
POINTER
MAX
FLCLN (X'SO')
Clean-up flag.
This flag is set if the chain .ust
be updated.
This is necessary in
the following circumstances:
If one of the two high-storage
chains contains a 4K page that
is pointed to by FREELOWE, then
that page can be r.emoved from
the chain, and FREELOWE can be
increased.
the
other DMSFREE storage pointers are maintained
in the DMSFRT CSECT, in NUCON. The four chain
header blocks are the most important fields in
DMSFRT. The four chains of unallocated elements
are:
•
The following flags are used:
avoids failing searches.
It contains
a number not exceeding the size, in
bytes, of the largest element on the
free chain. Thus, a search for an
element of a given size is not be made
if that size exceeds the MAX field.
However, this number may actually be
larger than the size of the largest
free element on the chain.
When DMSFREE with TYPE=USER
(the default)
is
called, one or more of the following steps are
taken in an attempt to satisfy the request. As
soon as one of the following steps succeeds,
then user free storage allocation processing
terminates.
1.
Search the low-storage user
block of the required size.
chain for
a
2.
Search the high-storage user
block of the required size.
chain for
a
3.
Extend high-storage user storage downward
into the user
program area, modifying
FREELOWE in the process.
4.
For a variable request, put all available
storage in the user program area onto the
high-storage user chain,
and then allocate
the largest block available on either the
high-storage user chain or the low-storage
IBM VM/370: System Logic and Problem Determination Guide
user chain.
The allocated block will not
be satisfactory unless it is larger than
the minimum requested size.
4.
Get free pages from the high-storage user
chain, if they are available, and put them
on the high-storage nucleus chain.
5.
Extend
high-storage
nucleus
storage
downward into
the user
program area,
modifying FREELOWE in the process.
6.
For variable requests,
put all available
pages from the user chains and the user
program area onto the nucleus chains, and
allocate the largest block available on
either the low-storage nucleus chains, or
the high-storage nucleus chains.
When DMSFREE with TYPE=NUCLEUS is called, the
following steps are taken in an attempt to
satisfy the request, until one succeeds:
1.
Search the low-storage nucleus
block of the required size.
chain for a
2.
Get free pages from the low-storage user
chain, if any are available, and put them
on the low-storage nucleus chain.
3.
Search the high-storage nucleus chain for a
block of the required size.
The
DMSFRET
macro releases
free
storage
previously allocated with the DMSFREE macro.
The format of the DMSFRET macro is:
--,
r---
I [label]
I
I
I
I
I
L---
DMSFRET I DWORDS={ n },LOC={laddr}
(0)
(1 )
I
r
I r
r
r
I I,ERR=lladdrll I,TYPCALL=I.§!£ II
I BALRII
I I
II I
I !
....
L
L
L
I L
"
I
I
I
I
I
I
"
....
---------
r
------.1
,
TYPCALL=I~!.£
label
I
IBALRI
is any valid assembler language label.
L
(0)
is the
number of
doublewords of
storage to be
released.
DWORDS=n
specifies the number of doublewords
directly and DWORDS=(O) indicates that
register 0 contains the number of
doublewords being released.
LOC={ laddr}
(1 )
is the address of the block of storage
being
released.
"laddr"
is
any
address that can be refereed to in a
LOAD
ADDRESS
(LA)
iBstruction.
LOC=laddr
specifies
the
address
directly while LOC=(1) indicates the
address is in register 1.
r
When DMSFRET is called, the block being
released is placed on the appropriate chain. At
that point, the final
update operation is
performed, if necessary, to advance FREELOWE, or
to move pages from the nucleus chain to the
corresponding user chain.
Similar update operations are performed, when
necessary, after calls to DMSFREE, as well.
,
ERR=lladdrl
I !
I
L
..
indicates how control is passed to
DMSFRET.
Because
DMSFRET
is
a
nucleus-resident
routine,
other
nucleus-resident routines can branch
directly to it
(TYPCALL=BALR)
while
routines that are not nucleus-resident
must use SVC linkage (TYPCALt=SVC).
DWORDS={ n }
..
is the return address if an error
occurs. "laddr" is any address that
can be referred to by a LOAD ADDRESS
(LA) instruction. The error return is
taken if there is a macro coding error
or if there is a problem returning the
storage. If * is specified, the error
return address is the same as the
normal return address.
storage
allocated
instruction may be
following ways:
by
the
released
GETMAIN
macro
in any of the
1.
A specific block of such storage may be
released by means of the FREEMAIN macro
instruction.
2.
The STRINIT macro instruction releases all
storage allocated by any previous GETMAIN
requests.
section 1. Introduction
121
Almost all CMS commands issue a STRINIT
macro instruction. Thus, executing almost
any CMS command causes all GETMAIN storage
to be released.
3.
particular,
it
is
possible to release a
was never allocated.
•
All requests that are satisfied in
high storage must be of a temporary
nature, since all storage allocated
in high storage is released when
the
second
free
storage
initialization routine is invoked.
storage allocated
by the
DMSFREE macro
instruction may be released in any of the
following ways:
1.
A specific block of such storage may be
released by means of the DMSFRET macro
instruction.
2.
When CP's saved system facility is
used, the CMS system is saved at the
point just after the A-Disk has been
made accessible. It is necessary for
DMSFRE to be used before the size of
virtual storage is known, since the
saved system can be used on any size
virtual machine.
Thus,
the first
initialization
routine
initializes
DMSFRE so that limited functions can
be
requested,
while
the
second
initialization routine performs the
initialization necessary to allow the
full
functions of
DMSFRE to
be
exercised.
Whenever any user routine or CMS command
abnormally terminates (so that the routine
DMSABN is entered), and the ABEND recovery
facility of the system is invoked, all
DMSFREE storage with TYPE=USER is released
automatically.
Except in the case of ABEND recovery, storage
allocated by the DMSFREE macro is never released
automatically by the system.
Thus, storage
allocated by means of this macro instruction
should always be released explicitly by means of
the DMSFRET macro instruction.
INIT2
The system uses the DMSFRES macro instruction to
request
certain
free
storage
management
serv ices.
invokes
the second
initialization
routine.
This routine
is invoked
after the size of virtual storage is
known, and it performs initialization
necessary to allow all the functions
of DMSFRE to be used.
The second
initialization routine performs the
following steps:
1.
Releases all storage that
been
allocated
in
high-storage area.
2.
Allocates
the
FREETAB
free
storage
table.
This
table
contains one byte for each 4K
page of virtual storage, and so
cannot be allocated until the
size
of virtual
storage
is
known.
3.
The FREETAB table is initialized,
and all storage protection keys
are initialized.
4.
All completely
unallocated 4K
pages on the low-storage nucleus
free storage chain are removed to
the
user chain.
Any
other
necessary
operations
are
performed.
The format of the DMSFRES macro is:
r------------------------------------------------,
l[label]IDMSFRESI INITl
r
r"
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
INIT2
CHECK
CKON
CKOFF
UREC
CALOC
I,TYPCALL=ISVC II
I
IBALRII
L
I
I
I
I
I
I
L....
L
---'
label
is
any
label.
!lUT1
invokes
the
first
free
storage
initialization routine, so that free
storage requests can be made to access
the system disk.
Before this routine
is invoked, no free storage requests
may be made. After this routine has
been invoked, free storage requests
aay be made, but these are subject to
the following restraints until the
second
free
storage
management
initialization
routine
has
been
invoked:
122
valid
assembler
language
•
All requests for USER type storage
are changed to requests for NUCLEUS
type storage.
•
Error checking is limited before
initialization
is complete.
In
sometimes
block which
has
the
CHECK
invokes a routine which checks all
free storage chains for consistency
and correctness.
Thus, it checks to
see whether any free storage pointers
have been destroyed.
This option can
be used
at any time
for system
debugging.
CKON
turns on a flag which causes the CHECK
routine to be invoked each time a call
is made to DMSFREE or DMSFRET. This
can be useful for debugging purposes
(for
example, when
you wish
to
identify the routine destroying free
storage management pointers).
Care
should be
taken when
using this
IBM VM/370: system Logic and Problem Determination Guide
option, since the CHECK routine is
coded to be
thorough rather than
efficient.
Thus,
after the
CKON
option has been invoked, each call to
D!SPRBB or DftSPRET takes much longer
to be co.pleted than before.
CKOPP
turns off the flag that was turned on
by the CKON option.
UREC
is used by DftSABN during the ABEND
recovery process to release all user
storage.
CALOC
is used by D!SABN after the ABEND
recovery process has been co.pleted.
It invokes a routine that returns, in
register 0, the number of doublewords
of
free storage
that have
been
allocated. DftSABN uses this number to
determine whether ABEND recovery has
been successful.
A nonzero return code upon return from DftSFRES,
D!SFREE, or DftSFRET indicates that the request
could not be satisfied.
Register 15 contains
this return code, indicating which error has
occurred.
The following codes apply to the
DftSFRES, D!SFREE, and DftSFRET macros.
£2f!.~
1
Error
(DKSFREE)
Insufficient storage space is
available to satisfy the request for free
storage.
In
the case of
a variable
request, even the minimum request could not
be satisfied.
2
(DMSFREE or DMSFRET)
destroyed.
User storage pointers
3
(DMSFREE, DMSFRET, or
DMSFRES)
storage pointers destroyed.
4
(DMSPREE)
An invalid size was requested.
This error exit is taken if the requested
size is not greater than zero.
In the case
of variable requests, this error exit is
taken if the minimum request is greater
than the maximu. request.
(However, the
latter error is not detected if DMSFREE is
able to satisfy the maximum request.)
£.QS'!} III2I
c. The block overlaps another block already
on the free storage chain.
7
(DftSPRET) The address given for the block
being released is not doubleword aligned.
8
(D!SFRES)
An invalid
request code was
passed to the DMSFRES routine.
Because all
request codes are generated by the DMSFRES
.acro,
this error
code should
never
appear.
9
(DftSFREE, DftSFRET, or DMSFRES) Unexpected
and unexplained error in the free storage
management routine.
CftS HANDLING OP PSi KEYS
The the CftS nucleus protection scheme protects
the CMS nucleus from inadvertent destruction by
a user
ptogram. iithout it, it
would be
possible, for example, for a FORTRAN user who
accidentally assigns an incorrectly subscripted
array element to destroy nucleus code, wipe out
a crucial table or constant area. or even
destroy an
entire disk by
destroying the
contents of the master file directory.
In general, user programs and disk-resident
CftS commands run with a PSi key of X'E', While
nucleus code runs with PSi key of X'O'.
There are, however, some exceptions to this
rule.
Certain disk-resident CMS commands run
with a PSW key of X'O', because they have a
constant need to modify nucleus pointers and
storage.
The nucleus routines called by the
GET, PUT, READ, and WRITE macros run with a user
PSi key of X'E', to increase efficiency.
Nucleus
5
(DMSFRET) An invalid size was passed to the
DMSFRET macro. This error exit is taken if
the specified length is not positive.
6
(DMSFRET) The block of storage which is
being released was
never allocated by
DMSFREE. Such an error is detected if one
of the following errors is found:
TWO macros are available to any routine that
wishes to change its PSi key for some special
purpose.
These are the DMSKEY macro and the
DM SEIS macro.
The DMSKEY macro may be used to change the
PSi key to the user value or the nucleus value.
The DMSKEY NUCLEUS option causes the current PSi
key to be placed in a stack, and a value of 0 to
be placed in the PSW key.
The DMSKEY USER
option causes the current PSW key to be placed
in a stack, and a value of X'E' to be placed in
the PSi key. The DMSKEY RESET option causes the
top value in the DMSKEY stack to be removed and
re-inserted into the PSi.
a. The block does not lie entirely inside
either the low-storage free storage area
or
the user
program area
between
FREELOWE and FREEUPPR.
It is a requirement of the CMS system that
when a routine terminates, the DMSKEY stack must
be empty. This means that a routine should
execute a DMSKEY RESET option for each DMSKEY
NUCLEUS option and each DMSKEY USER option
executed by the routine.
b. The block crosses a page boundary that
separates a page allocated for USER
storage from
a page
allocated for
NUCLEUS type storage.
The DMSKEY key stack has a current maximum
depth of seven for each routine.
In this
context, a "routine" is anything invoked by an
SVC call.
Section 1. Introduction
123
The DMSKEY LISTUSER option causes the current
PSi key to be placed in the stack, and a new key
inserted into the PSi, determined as follows:
the SVC system save area stack is searched in
reverse order (top to bottom) for the first save
area corresponding to a user routine.
The PSi
key which was in effect in that routine is then
taken for the new PSi key. (If no user routine
is found in the search, then LISTUSER has the
same effect as USER.)
This option is used by OS
macro simulation routines when they must enter a
user-supplied exit routine; the exit routine is
entered with the PSi key of the last user
routine on the SVC system save area stack.
The BOSTICK option of DMSKBY may be used with
BUCLEUS, USER, or LISTUSER
(as in, for example,
DftSKEY BUCLEUS,IOSTICK)
if the current key is
not to be placed on the DMSKEY stack. If this
option is used, then no corresponding DMSKEY
RESET should be issued.
The DMSEXS
("execute in system mode") macro
instruction is useful in situations where a
routine is running with a user protect key, but
wishes to execute a single instruction which,
for example, sets a bit in the BUCON area. The
single instruction may be specified as the
argu.ent
to the
DftSEXS
macro, and
that
instruction will be executed with a system PSi
key.
ihenever possible, CMS commands run with a
user protect key. This protects the CMS nucleus
in cases where there is an error in the system
command which
would otherwise
destroy the
nucleus. If the com.and must execute a single
instruction or small group of instructions that
.odify nucleus storage, then the DftSKEY or
DftSEXS macros are used, so that the system PSi
key will be used for as short a period of time
as possible.
SVC TYPES AND LIBKAGE CONVEBTIONS
SVC conventions are important to any discussion
of CftS because the system is driven by SVCs
(supervisor calls). SVCs 202 and 203 are the
most common CMS SVCs.
svc 202 is used
both for calling nucleus
resident routines,
and for calling routines
written as commands (for example, disk resident
modules).
I typical coding sequence for an SVC 202 call
is the following:
LA
SVC
DC
R1,PLIST
202
AL4 (ERRADD)
Whenever SVC 202 is calle.d, register 1 must
point to a parameter list (PLIST). The format of
this parameter list depends upon the actual
routine or command being called, but the SVC
handler will examine the first eight bytes of
this parameter list to find the name of the
routine or command being called.
The "DC AL4(address)" instruction following
the SVC 202 is optional, and may be omitted if
the programmer does not expect any errors to
occur in the routine or coosand being called.
If included, an error return is made to the
address specified in the DCa DMSITS determines
whether this DC was inserted by examining the
byte following the SVC call inline.
A nonzero
byte indicates an instruction, a zero value
indicates that "DC AL4 (address)" follows.
CftS SVC HABDLIBG
DftSITS (IBTSVC) is the CftS system SVC handling
routine. The general operation of DftSITS is as
follows:
1.
2.
The SVC new
PSi
(low-storage location
X'60') contains, in the address field, the
address of DftSITS1. The DftSITS .odule will
be entered whenever a supervisor call is
executed.
DMSITS allocates a system and user save
area.
The user save area is used as a
register save area (or work are~
by the
called routine.
3.
The called routine is called (via a LPSi or
BALR) •
4.
Upon return fro. the called routine,
save areas are released.
5.
Control
routine
call) •
124
the
is returned to the caller (the
which originally
.ade the SVC
SVC 203 is called by CMS macros to perform
various internal system functions. It is used
to define SVC calls for which no parameter list
is provided. Por example, DMSFREE parameters
are passed in registers 0 and 1.
A typical calling
call is as follows:
SVC
DC
sequence for
an SVC
203
203
H'code'
The halfword deci.al code following the SVC
203
indicates the
specific routine
being
called.
DMSITS examines this halfword code,
taking the absolute value of the code by an LPR
instruction. The first byte of the result is
ignored, and the second byte of the resulting
halfword is used as an index to a branch table.
The address of the correct routine is loaded,
and control is transferred to it.
It
index
entry
name,
is possible for the address in the SVC 203
table to be zero. In this case, the index
will contain an 8-byte routine or command
which will be handled in the same way as
IBft Vft/370: system Logic and Problem Deter.ination Guide
the 8-byte name passed in
an SVC 202.
the para.eter list to
The progra •• er indicates an error return by
the sign of the halfword code.
If an error
return is desired, then the code is negative.
If the code is positive, then no error return is
.ade.
The sign of the ha1fword code has no
effect on deter.ining the routine which is to be
called, since DMSITS takes the absolute value of
the code to deter.ine the routine called.
Since only the second byte of the absolute
value of the code is examined by DftSITS, seven
bits (bits 1-7) are available as flags or for
other uses. Thus, for exa.p1e, DMSFREE uses
these seven bits to indicate such things as
conditional requests and variable requests.
When an SVC 203 is invoked, DMSITS stores the
ha1fword code into the BUCOB location CODE203,
so that the called routine can examine the seven
bits made available to it.
parameter list is invalid or cannot be
found, DMSITS handles the situation in the
same way it handles an error return from a
legitimate SiC routine.
The error code is
-3.
3.
Invalid SVC 203 code.
If an invalid code
follows SVC 203 in1ine, then an error
message is displayed, and the ABEND routine
is called to terminate execution.
When a program issues SVC 202, passing a routine
or command name in the parameter list, then
DMSITS must be searched
for the specified
routine or command.
(In the case of SVC 203
with a zero in the table entry for the specified
index, the same logic must be applied.)
The search algorithm is as follows:
All calls made by means of SVC 203 should be
made by
macros, with the
macro expansion
co.puting and specifying the correct half word
code.
The programmer may use the BNDSVC macro to
specify the address of a routine which will
handle any SVC call o',ther than for SVC 202 and
SVC 203.
1.
First, a check is made to see if there is a
routine with the specified name currently
occupying the system Transient Area.
If
this
is the
case,
then control
is
transferred there.
2.
second, the system function name table is
searched, to see if a command by this name
is
nucleus-resident.
If
successful,
control goes to
the specified nucleus
routine.
3.
Bext, a search is made for a disk file with
the specified name as the filename, and
MODULE as the fi1etype.
The search is made
in the standard disk search order. If this
search is successful, then the specified
module is loaded (via the LOADMOD command),
and centro1 passes to the storage location
now occupied by the command.
4.
If all searches so far have failed, then
DMSIBA (ABBREV)
is called, to see if the
specified routine name ~s a valid system
abbreviation for
a system
command or
function.
user-defined abbreviations and
synonyms are also checked.
If this search
is successful, then steps 2 through 4 are
repeated with the full function name.
5.
If all searches fail, then an error code of
-3 is issued.
In this case, the linkage conventions are as
required by the
user-specified sVc-hand1ing
routine.
CMS supports selected SVC calls generated by OS
and DOS/VS macros, by simulating the effect of
these macro calls.
DftSITS is the initial SVC
interrupt handler.
If the SET DOS command has
been issued, a flag in NUCON will indicate that
DOS/VS macro simulation is to be used. Control
is then passed to DftSDOS.
Otherwise, OS macro
simulation is assumed and DftSITS passes control
to the appropriate OS simulation routine.
There are several types of
recognized by DftSITS.
1.
2.
invalid SVC
calls
Invalid SVC number. If the SVC number does
not fit into any of the four classes
described above, then it is not handled by
DftSITS.
An appropriate error message is
displayed at the terminal, and control is
returned directly to the caller.
Invalid routine name in SVC 202 parameter
list.
If the routine named in the SVC 202
When a command is entered from the terminal,
DMSINT processes the command line, and calls the
scan routine to convert it into a parameter list
consisting of eight-byte entries.
The following
search is performed:
1.
DMSIBT searches for a disk file whose
filename is the command name, and whose
fi1etype is EXEC.
If
this search is
successful, EXEC is invoked to process the
EXEC file.
Section 1. Introduction
125
If
not found,
the
command name
is
considered to be an abbreviation and the
appropriate tables are examined. If found,
the abbreviation is replaced by its full
equivalent and the search for an EXEC file
is repeated.
2.
If there is no EXEC file, DMSINT executes
SVC 202, passing the scanned parameter
list, with the command name in the first
eight bytes.
DMSITS
will perform the
search described for SVC 202 in an effort
to execute the command.
3.
If DMSITS returns to DMSINT wi th a return
code of -3, indicating that the search was
unsuccessful, then DMSINT
uses the CP
DIAGNOSE facility to attempt to execute the
command as a CP command.
4.
transient program area may not invoke the RENAME
command.
In addition, it may not invoke the OS
macro iTO, which generates an SVC 35, which is
handled by DMSSVT.
DMSITS starts programs running in the user
program area enabled for all interruptions but
starts programs running in the transient program
area disabled
for all
interruptions.
The
individual program may have to use the SSM (SET
SYSTEM MASK)
instruction to change the current
status of its system mask.
CALLED ROUTINE START-UP TABLE
Figures 24 and 25 show how the PSW and registers
are set up when the called routine is entered.
If all these searches fail, then DMSINT
displays the error message UNKNOWN CP/CMS
COMMAND.
RETURNING TO THE CALLING ROUTINE
See Figure 23 for a description
search for a command name.
of
this
When the called routine finishes processing,
control is returned to DMSITS, which in turn
returns control to the calling routine.
USER AND TRANSIENT PROGRAM AREAS
TWO areas can hold programs that are loaded from
disk. These are called the user program area
and the transient program area.
(see Figure 22
for a description of CMS storage usage.)
The user program area starts at location
X'20000'
and extends upward
to the loader
tables.
Generally,
all user
programs and
certain system commands
(such as EDIT, and
COPYFILE) run in the user program area.
Because
only one program can be running in the user
program area at anyone time, it is impossible
(without unpredictable results)
for one program
running in the user program area to invoke, by
means of SVC 202, a module that is also intended
to be run in the user program area.
The transient program area is two pages long,
running from
location X'EOOO'
to location
X'FFFF'.
It
provides an area
for system
commands that may also be invoked from the user
program area by means of an SVC 202 call.
When
a transient module is called by an SVC,
it is
normally run with the PSW system mask disabled
for I/O and external interruptions.
The transient program
area also handles
certain OS macro simulation SVC calls.
OS SVC
calls are handled by the OS simulation routines
located either in
the CMSSEG discontiguous
shared segment or in the user program area, as
close to the loader tables as possible.
If
DMSITS cannot find the address of a supported OS
SVC handling routine, then it loads the file
DMSSVT MODULE into the transient area, and lets
that routine handle the SVC.
A program running in the transient program
area may not invoke another program intended to
run in the transient program area, including OS
macro simulation SVC calls that are handled by
DMSSVT. For example. a program running in the
126
The return is accomplished
by loading the
original SVC old PSW
~hich was
saved at the
time DMSITS was first entered), after possibly
modifying the address field.
The address field
modification depends upon the type of SVC call,
and on whether the called routine indicated an
error return.
For SVC 202 and 203, the called routine
indicates a normal return by placing a zero in
register 15, and an error return by placing a
nonzero code in register 15.
If the called
routine indicates a normal return, then DMSITS
makes a normal return to the calling routine.
If the called routine indicates an error return,
DMSITS passes the error return to the calling
routine, if one was specified, and abnormally
terminates if none was specified.
For
an SVC
202 not
followed by
"DC
AL4{address)", a normal return is made to the
instruction following the SVC instruction, and
an error return causes an ABEND. For an SVC 202
followed by "DC AL4{address)h, a normal return
is made to the instruction following the DC, and
an error return is made to the address specified
in the DC. In either case, register 15 contains
the return code passed back by the called
routine.
For an SVC 203 with a positive halfword code,
a normal return is made to the instruction
following the halfword code, and an error return
causes an ABEND.
For an SVC 203 with a negative
halfword code, both normal and error returns are
made to the instruction following the halfword
code.
In any case, register 15 contains the
return code passed back by the called routine.
For macro simUlation
user-handled SVC calls,
IBM VM/370: System Logic and Problem Determination Guide
SVC calls, and for
no error return is
Ves
Read line
from terminal
(.. n.me ..... )
Ves
Attempt to execute
LOADMOD name
MODULE from disk
Expand line by
inserting the
command name
EXEC to:
EXEC name
Name is now
the real name
from a
Svnonvm
Tobie
Pa3S control to the
routine (in the nucleus,
transient area, or
user area) to execute
the command
Name is now the
real name from the
Synonym Table
Issue SVC 202
(See the SVC 202
Subroutine)
Set RC = ·3
Upon completion,
return to SVC routine
Pass line
to CP
for processing
No
No
No
Display
UNKNOWN
CP/CMS
COMMANO
Ves
Notes:
1. If the terminal line was actually from an EXEC file, or if the
command SET IMPEX OFF has been executed, implied EXEC
is not in effect.
Display Ready
message, with
error code if
RC = 0
Figure 23.
CMS Command (and Request)
2. A -3 return code indicates SVC 202 processing did not find
the command.
3. If the terminal line was actually from an EXEC file, or if the
command SET IMPEX OFF has been executed, implied CP
is not in effect.
Processing
section 1. Introduction
127
,
,
1
Called Type
System Bask
Storage Key 1
Proble. Bit
1
1
-I
---I
1 SVC 202 or 203
Disabled
Syste.
1
Off
1
1
1
1 - Bucleus
1
resident
1
1
1
1
-1------1
1
Disabled
1
User
1
Off
1
1 svc 202 or 203
1 - Transient
1
1
1
1
area BODULE
1
1
1
1
1-------1
-I
1-------1
1 svc 202 or 203 1
Enabled
1
User
1
Off
1
1 - User area
1
1
1
1
1
1----------1-------1
1
1
Enabled
1
User
1
Off
1
1 User-handled
1
1----------1
1
1
1
Disabled
1
System
1
Off
1
1 os - DOS/VS
1 liuc leus
1
1
1
1
1 resident
1
1
1
1
1
1------------1-1
--I
1 os - DOS/VS
1
Disabled
1
Systea
1
Off
1
1 Transient
1
1
1
1
1 -area
module
1
1
1 _ _ _ _ _ _ _ _ _ _...1
L
-__________________
._ _ _ _
Figure 24.
PSW Fields When Called Routine Starts
,
Registers
Registers 1 Register 1 Register 1 Register
Register 1
Type
0-1
2 - 11
1
12
1
13
1
14
1
15
1
- - - - - - - - - -----1------1-----1
1-------1
SVC 202
Same as
Unpredic- 1 Address 1 User
1 Return
1 Address 1
table
1 of
1 save
1 address 1 of
1
or 203
caller
1 called
1 area
1 to
1 called
1
1
1
1
1 routine 1
1 DMSITS
1 routine 1
1----1-----1--------1-----1
1----1-----1
lather
L Same as
1 Same as
1 Address 1 User
1 Return
1 Same as 1
1
1 caller
1 caller
1 of
1 save
1 address 1 caller
1
1
1
1
1 caller
1 area
1 to
1
1
1 --1
1
1 _ _ _ _ _ _ _l
SI_T_S_ _ _
1 _ _ _ _ _---'1
L
_. _ _ _
_ _i
_ _D
_ _ _ _ _ft_
Figure 25.
Register contents When Called Routine Starts
recognized
by DMSITS.
As a result, DftSITS
always returns to the calling routine by loading
the SVC old PSW which was saved when DftSITS was
fi rst en te red.
Upon entry to DBSITS, all registers are saved as
they were when the SVC instruction was first
executed.
Upon exiting
from DftSITS,
all
registers are restored from the area in which
they were saved at entry.
The exception to this is register 15 in the
case of SVC 202 and 203.
Upon return to the
calling routine, register 15 always contains the
value which was in register 15 when the called
routine returned
to DftSITS
after it
had
completed processing.
If the called routine has system status, so that
it runs with a PSW storage protect key of 0,
128
then it may store
Save Area.
new values
into the
System
If the called routine wishes to modify the
location to which control is to be returned, it.
must modify the following fields:
•
For SVC 202 and
RUftRET and ERRET
address) fields.
•
For other SVCs, it
field of OLDPSW.
203, it must modify the
(normal and error return
must modify
the address
To modify the registers that are to be returned
to the calling routine, the fields EGPR1, EGPR2,
••• , EGPR15 must be modified.
If this action is
taken by the called
routine, then the SVCTRACE facility may print
misleading information, since SVCTRACE assumes
that these fields are exactly as they were when
DftSITS was first entered.
Whenever an SVC call
is made, DftSITS allocates two save areas for
that particular SVC call.
Save areas are
allocated as needed. For each SVC call, a system
and user save area are needed.
IBft VM/370: System Logic and Problem Determination Guide
When the SVC called routine returns, the save
areas are not released, but are kept for the
next SVC.
At the completion of each command,
all SVC save areas allocated by that command are
released.
The system save area is used by DMSITS to
save the value of the SVC old PSW at the time of
the SVC call, the calling routine's registers at
the time of the call, and any other necessary
control information.
Because SVC calls can be
nested, there can be several of these save areas
at one time. The system save area is allocated
in protected free storage.
The user save area contains 12 doublewords
(24 words),
allocated in
unprotected free
storage. DMSITS does not use this area at all,
but simply passes a pointer to this area (via
register 13.)
The called routine can use this
area as a temporary work area, or as a register
save area. There is one user save area for each
system save area.
The field OSAVEPTR in the
system save area points to the user save area.
The exact format of the system save area can
be found in the !~JIQ: ~A~A A~~A§ A~ £g~!!~l
~!2£~
~2g!£.
The most important fields, and
their uses, are as follows:
CALLER
CALLEE
(Full word)
The address of
instruction that resulted
call.
EGPRS
(16
Fullwords, separately
labeled
EGPRO, EGPR1,
EGPR2, EGPR3,
••• ,
The entry registers.
The
EGPR15)
contents of the general registers at
entry to DMSITS are stored in these
fields.
EFPRS
(4 Doublewords,
separately labeled
EFPRO, EFPR2, EFPR4, EFPR6)
The entry
floating-point
registers.
The
contents
of
the
floating-point
registers at entry
to DMSITS are
stored in these fields.
SSAVENXT
(Fullword)
The address of the next
system save area in the chain. This
points to the system save area which
is being used, or will be used, for
any SVC call nested in relation to the
current one.
SSAVEPRV
(Fullword)
The
address
of
the
previous system save
area in the
chain. This points to the 'system save
area for the SVC call in relation to
which the current call is nested.
OSAVEPTR
(Fullword) Pointer to the user
area for this SVC call.
the SVC
in this
CMS INTERFACE FOR DISPLAY TERMIliIALS
(Doubleword) Eight-byte symbolic name
of the called routine.
Por OS and
user-handled SVC calls, this field
contains a character string of the
fora SVC nnn, where nnn is the SVC
number in deci.al.
CODE
(Halfword)
For SVC 203, this field
contains the halfword code following
the SVC instruction line.
OLDPSW
(Doubleword) The SVC old PSW at
time that DMSITS was entered.
liIHMRET
(Pull word) The address of the calling
routine to which control is to be
passed in the case of a normal return
from the called routine.
EHRET
(Fullword) The address of the calling
routine to which control is to be
passed in the case of an error return
from the called routine.
CMS has an interface that allows it to display
large amounts of data in a very rapid fashion.
This interface for display terminals is much
faster and has less overhead than the normal
write because it displays up to 1760 characters
in one
operation, instead
of issuing
22
individual writes of 80 characters each (that is
one write per line on a display terminal). Data
that is displayed in the screen output area with
this interface is not placed in the console
spool file.
the
The DISPW macro allows you to use this
display terminal interface.
It generates a
calling sequence for the CMS display ter.inal
interface module, DMSGIO.
DMSGIO creates a
channel
program
and
issues
a
DIAGNOSE
instruction (Code 58)
to display the data.
DMSGIO is a TEXT file which must be loaded in
order to use DISPW. The format of the CMS DISPW
.acro is:
r-------I
I [label]
I
I
I
L-
r
DISPW
save
,
r
,
bufad I,LIRE=nl
I,BYTES=bbbbl
IL~!!~=~I
ILDllES=11~~1
L
L
.J
[ERASE=YES]
.J
[CARCEL=YES]
--,
I
I
I
I
I
---'
Section 1. Introduction
129
as DATA MANAGEMENT SIMULATION
label
is an optional macro statement label.
bufad
is the address of a buffer containing
the data to be written to the display
terminal.
r
,
ILINE=nl
ILINE=OI
L
~
is the number of the line, 0 to 23, on
the display terminal that is to be
written.
Line number
0 is
the
default.
r
The disk format and data base organization of
CMS are different from those of as.
A CMS file
produced by an as program running under CMS and
written on a CMS disk, has a different format
than that of an as data set produced by the same
as program running under as and written on an as
disk. The data is exactly the same, but its
format is different.
(An as disk is one that
has been formatted by an as program, such as
IBCDASDI.)
HANDLING FILES THAT RESIDE ON CMS DISKS
,
IBYTES=bbbbl
1~!I~~=11~QI
L
~
is the number of bytes
(0 to 1760) to
be written on the display terminal.
1760 bytes is the default.
[ERASE=YES]
specifies that the display screen is
to be erased before the current data
is written.
The screen is erased
regardless of the line or number of
bytes to be displayed.
specifying
ERASE=YES causes the screen to go into
"MORE" status.
[CANCEL=YES]
causes the
performed:
erased.
CANCEL operation to
the
output
area
CMS can read, write, or update any as data that
resides on a CMS disk. By simulating as macros,
CMS simulates the following access methods so
that as data organized by these access methods
can reside on CMS disks:
direct
identifying a record by a key or
by its relative position within
the data set.
partitioned
seeking a named
the data set.
sequential
accessing a record in a sequence
relative
to
preceding
or
following items in
the data
set.
be
is
member
within
Refer to Figure 26
and the "Simulation
Notes", then read "Access Method Support" to see
how CMS handles these access methods.
as MACRO SIMULATION UNDER CMS
When a language processor or a user-written
program is executing in the CMS environment and
using Os-type functions, it is not executing as
code.
Instead, CMS
provides routines that
simulate the as functions required to support as
language processors and their generated object
code.
CMS functionally simulates the as macros in a
way that presents equivalent results to programs
executing under
CftS.
The
as macros
are
supported only to the extent stated in the
publications
for
the
supported
language
processors, and
then only
to the
extent
necessary to successfully satisfy the specific
requirement of the supervisory function.
The restrictions for COBOL and PL/I program
execution listed in "Executing a Program that
Uses as Macros" in the !~L~lQ: gl~BBiB~ and
~I~~~~ §~~~I2t!Q~ §g!g~ exist because of the
limited simulation by CMS of the as macros.
Figure 26 shows the as macro
are partially
or completely
defined by SVC number.
130
functions that
simulated,
as
Because CMS does not simulate the indexed
sequential access method (ISAM), no as program
which
uses ISAM
can
execute under
CMS.
Therefore, no program can write an indexed
sequential data set on a CMS disk.
HANDLING FILES THAT RESIDE ON as OR DOS DISKS
By simulating as macros, CMS can read, but not
write or update, as sequential and partitioned
data sets that reside on as disks.
Using the
same simulated as macros, CMS can read DOS
sequential files that reside on DOS disks. The
as macros handle the DOS data as if it were as
data. Thus a DOS sequential file can be an input
to an as program running under CMS.
However, an as sequential or partitioned data
set that resides on an as disk can be written or
updated only by an as program running in a real
as machine.
CMS can execute programs that read and write
VSAM files from as programs written in the VS
BASIC, COBOL, or PL/I programming languages.
This CMS support is based on the DOS/VS Access
Method Services and
Virtual Storage Access
Method
(VSAM)
and therefore the as user is
limited to
those VSAM functions
that are
available under DOS/VS.
IBM VM/370: system Logic and Problem Determination Guide
..--
Macro
Title
-inAPl
WAIT
POST
EXIT/RETURN
GETMAIN
FREEMAIN
GETPOOL
FREE POOL
LINK
XCTL
LOAD
DELETE
GETMAIN/
FREEMAIN
TIMEI
ABEND
» SPIEl
SVC
NUliber
--00-01
02
03
04
05
06
07
08
09
10
11
13
14
RESTOREI
BLDL/FINDI
17
18
OPEN
CLOSE
STOWI
OPENJ
TCLOSE
DEVTYPEI
19
20
21
22
23
24
TRKBAL
WTO/WTORI
EXTRACTI
IDENTIFYI
ATTACHI
CHAPI
TTIMERI
STIMERI
DEOI
SNAPI
ENOl
FREEDBUF
_.STAE
25
35
40
41
42
44
46
47
48
51
56
57
60
DETACHI
CHKPTI
RDJFCBl
62
63
64
SYIADI
BSPI
GET/PUT
READ/WRITE
laTE/poINT
CHECK
TGET/TPUT
TCLEARQ
68
69
~STAX
93
94
96
Function
Read or-wrIte-direct access volumes
wait for an I/O completion
Post the I/O coapletion
Return from a called phase
Conditionally acquire user storage
Release user-acquired storage
simulate as SVC 10
Simulate as SVC 10
Link control to another phase
Delete. then link control to another
load phase
Read a phase into storage
Delete a loaded phase
Manipulate user free storage
Get the time of day
Terminate processing
Allow processing program to
handle program interrupts
Effective NOP
Manipulate simulated partitioned
data files
Activate a data file
Deactivate a data file
Manipulate partitioned directories
Activate a data file
Temporarily deactivate a data file
Obtain device-type physical
characteristics
NOP
Communicate with the terminal
Effective NOP
Add entry to loader table
Effective LINK
Effective Nap
Access or cancel timer
set timer
Effective NOP
Dump specified areas of storage
Effective NOP
Release a free storage buffer
Allow processing program to
decipher ABEND conditions
Effective NOP
Effective Nap
Obtain information from FILEDEF
command
Handle data set error conditions
Backup a record on a tape or disk
Access system-blocked data
Access system-record data
Manage data set positioning
Verify READ/WRITE completion
Read or write a terminal line
Clear terminal input queue
Create an attention exit block
1--11 Simulated in the transient routine "DMSSVT".
1 routines reside in the nucleus.
Other simulation
L-
Figure 26.
Simulated OS Supervisor Calls
SIMULATION NOTES
Because CMS has its own file srstem and is a
single-user system
operating 1n
a virtual
machine with virtual storage. there are certain
restrictions for the simulated OS function in
CMS.
For example. HIARCHY options and options
that are used only by OS multitasking systems
are ignored by CMS.
Listed below are descriptions of all the OS
macro functions that are simulated by CMS as
seen by the programmer.
Implementation and
Section 1. Introduction
131
progra. results that differ
Q~L!~ R!l! A!D!g§!§!S A!~!Q
Q~L!~ ~YE§!~i§9! ~§!~i~§§ !DS
fro. those given in
ID§!!YS!!QD§ and
A!£!9
LOAD-svca
The DCB and 8IARC8Y options
are ignored by CMS. All other
options of LOAD are supported.
LOAD
loads
the
specified
progra.
into
storage
(if
necessary)
and
returns the
address of the specified entry
point
in
register
zero.
However,
if the
specified
entry point is not in core
when SVC a is issued, and the
subroutine
contains
VCONs
which
cannot
be
resolved
within that TITLIE member, CMS
attempts
to resolve
these
references,
and
may return
another entry point address.
To insure a correct address in
register zero, the user should
bring such subroutines into
core
either
by
the
eMS
LOAD/INCLUDE commands or by a
VCON in the user program.
GET POOL/
lREEPOOL
All the options
of GETPOOL
and lREEPOOL are supported.
GETPOOL constructs a buffer
pool and stores the address of
a buffer pool control block in
the DCB.
lREEPOOL frees a
buffer pool
constructed by
GETPOOL.
DELETE-SVC9
All the options of DELETE are
supported.
DELETE decreases
the use count by one and if
the result is zero frees the
corresponding
virtual
storage. Code 4 is returned
in register 15 if the phase is
not found.
GET!AIN/
lREEMAINSVC10
All the options
of GETMAIN
and lREEMAIN are
supported.
Subpool
specifications
are
ignored.
TIME-SVC11
All the options of TIME except
MIC
are
supported.
TIME
returns the time of day to the
calling program.
ABEND-SVC13
The completion code parameter
is
supported.
The
DUMP
parameter is not. If a STAE
request
is
outstanding,
control is given to the proper
STAE routine.
If a
STAE
routine is not outstanding~ a
message indicating an ABEND
has occurred is printed on the
terminal
along
with
the
completion code.
SPIE-SVC14
All the options of SPIE are
supported.
The SPIE routine
specifies interruption
exit
routines
and
program
interruption types that will
cause the exit
routine to
receive control.
RESTORE-SVC11
The RESTORE routine in CMS is
a NOP. It returns control to
the user.
lD§!!YS!!2!~
are stated. 8IABC8Y options and those used only
by OS .ultitasking syste.s are ignored by CMS.
Validity checking is not perfor.ed within the
si.ulation routines.
The entry point na.e in
LIBK, ICTL, and LOAD (SVC 6, 1, a) must be a
.e.ber na.e or alias in a TITLIB directory
unless the CO!PSWT is set to on.
If the COMPSWT
is on, SVC 6, 1, and a .ust specify a MODULE
na.e. This switch is turned on and off by using
the COMPSWT macro. See the !AL~lQ: ~A~ ~Q!!!Dg
~DS A~S!Q l§i§!§D~§ for
descriptions of all CMS
user macros.
!acro-SVC !Q.
inip:svco
~!i!~!§D~~§
!D
1!]!§!~D!!!!2D
The TYPE option must be R or
W; the V, I, and K options are
not
supported.
The
BLKREl-ADDR must point to an
item nu.ber acquired by a NOTE
macro.
Other
options
associated with V, I, or K are
not supported.
WAIT-SVC1
All
options of
WAIT
are
supported.
The WAIT routine
waits for the completion bit
to be set in the specified
ECBs.
POST-SVC2
All
options of
supported.
POST
completion
code
completion
bit
specified ECB.
EIIT/RETURN
-SVC3
Post ECB, execute end of task
routine,
release
phase
storage,
unchain and
free
latest
request block,
and
restore registers depending on
whether this is an exit or
return from a linked or an
attached routine.
POST
are
sets
a
and
a
in
the
GET!AIN-SVC4
All the options of GET MAIN are
supported.
GETMAIN
gets
blocks of free storage.
lREEMAIN-SVCS
All the options of lREEMAIN
are supported. lREEMAIN frees
blocks of storage acquired by
GETMAIN.
LIRK-SVC6
The DCB and HIARCHY options
are ignored by CMS. All other
options of LIRK are supported.
LINK
loads
the
specified
program
into
storage
(if
necessary) and passes control
to the specified entry point.
ICTL-SVC1
The DCB and HIARCHY options
are ignored by CMS. All other
options of ICTL are supported.
ICTL
loads
the
specified
program
into
storage
(if
necessary) and passes control
to the specified entry point.
132
IBM VH/310: System Logic and Problem Determination Guide
BLDL-SVC18
BLDL is an effective NOP for
LINKLIBs and
JOBLIBs.
Por
MACLIBs,
item numbers
are
filled in the TTR field of the
BLDL list; the K, Z, and user
data fields,
as described in
Q~L!~
y~!~
H~~~g~!~~!
IDENTIPY-SVC41
The IDERTIPY routine in CftS
adds a RPQUEST block to the
load request chain for the
requested name and address.
ATTACH-SVC42
All the options of ATTACH are
supported in CftS as in OS
PCP.
The following options
are ignored
by CftS:
DCB,
LPftOD, DPMOD, HIARCHY, GSPV,
GSPL, SHSPV,
SHSPL, SZERO,
PURGE, ASYNCH, and TASKLIB.
ATTACH passes control to the
routine specified, fills in an
ECB completion bit if an ECB
is specified, passes control
to an exit routine if one is
specified, and returns control
to the instruction following
the ATTACH.
~~!2
Instructions,
are
set
to
zeros:--The-'alias' bit of the
C field is supported, and the
remaining bits in the C field
are set to zero.
PIID-SVC18
All the options of PIND are
supported.
PIND sets
the
read/write pointer to the item
number
of
the
specified
.ember.
STOi-SVC21
All the options of STOi are
supported. The 'alias' bit is
supported, but the user data
field is not stored in the
MACLIB directory
since CMS
MACLIBs do not contain user
data fields.
OPEN/OPENJSVC19/22
CLOSE/TCLOSESVC20/23
All the options of OPEN and
OPEIJ are supported except for
the DISP and RDBACK options
which
are
ignored.
OPEN
creates
a
CMSCB
(if
necessary), completes the DCB,
and merges necessary fields of
the DCB and CMSCB.
All the options of CLOSE and
TCLOSE are supported except
for the DISP option, which is
ignored. The DCB is restored
to its condition before OPEN.
If the device type is disk,
the file is closed. If the
device type
is tape,
the
REREAD option is treated as a
BEiIID.
DEVTYPE-SVC24
All the options of DEVTYPE are
supported.
DEVTYPE
moves
device
characteristic
information for a specified
data set into a specified user
area.
iTO/iTOR-SVC35
All options of iTO and iTOR
are supported
except those
options
concerned
with
.ultiple console support. iTO
displays a message' at the
operator's
console.
iTOR
displays a message
at the
operator's console, waits for
a reply, .oves the reply to
the specified area, sets a
co.pletion
bit
in
the
specified EeB, and returns.
EXTRACT-SVC40
The EXTRACT routine in CftS is
essentially a NOP. The user
provided answer area is set to
zeros and control is returned
to the user with a return code
of 4 in register 15.
Because
CMS
is
not
a
multitasking system, a phase
requested by the ATTACH macro
must return to CftS.
'CHAP-SVC44
The CHAP routine in CftS is a
NOP.
It returns control to
the user.
TTlftER-SVC46
All the options
supported.
STlftER-SVC47
All options of
STIftER are
supported except for TASK and
iAIT.
The TASK
option is
treated as if the REAL option
had been specified, and the
iAIT option is treated as a
ROP; it returns control to the
user.
DEQ-SVC48
The DEQ routine in CftS is a
NOP.
It returns control to
the user.
SNAP-SVC51
All the options of SNAP are
supported except for the DCB,
SDATA,
and PDATA
options,
which are ignored. SNAP always
du.ps output to the printer.
The dump contains the PSi, the
registers, and
the storage
specified.
ERQ-SVC56
The ERQ routine in CftS is a
NOP.
It returns control to
the user.
PREEDBUP-SVC57
All the options of PREEDBUP
are
supported.
PREEDBUP
returns a buffer to the buffer
pool assigned to the specified
DCB.
STAE-SVC60
All the options of STAE are
supported except for the XCTL
option,
which is
set
to
XCTLLYES; the PURGE option,
which is set to HALT; and the
ASYNCH option, which is set to
10.
STAE creates, overlays,
or cancels a
STAE control
block
as requested.
STAE
retry is not supported.
of TTIMER are
section 1. Introduction
133
DETACH-SVC62
The DETACH routine in CMS is a
NOP.
It returns control to
the user.
CHKPT-SVC63
The CHKPT routine is a Nap.
It returns control
to the
user.
RDJPCB-SVC64
All the options of RDJPCB are
supported.
RDJPCB causes a
Job Pile Control Block (JFCB)
to be read from a CMS Control
Block
(CMSCB)
into
real
storage for each data control
block specified. CMSCBs are
created by PILEDEP commands.
SYNADAP-SVC68
All the options of SYNADAP are
supported.
SYNADAP analyzes
an I/O error and creates an
error
message in
a
work
buffer.
SYNADRLS-SVC68
All the options of SYNADRLS
are supported.
SYNADRLS frees
the work area
acquired by
SYNAD and deletes the work
area
from the
save
area
chain.
BSP-SVC69
All the options of BSP are
supported.
BSP decrements the
item pointer by one block.
TGET/TPUTSVC93
TGET and TPUT operate as if
EDIT and WAIT
were coded.
TGET reads a terminal line.
TPUT writes a terminal line.
TCLEARQ-SVC94
TCLEARQ in CMS
clears the
input
terminal
queue
and
returns control to the user.
STAX-SVC96
NOTE
POINT
The manipulation of data is governed by an
access method.
To facilitate the execution of
as Code under CMS, the processing program must
see data as as would present it.
For instance,
when the processors expect an access method to
acquire input source cards sequentially, CMS
invokes specially written routines that simulate
the OS sequential access method and pass data to
the processors in the format that the as access
methods would have produced. Therefore, data
appears in storage as if it had been manipulated
using an as access method. For example, block
descriptor words (BDW),
buffer pool management,
and variable records are updated in storage as
if an as access method had processed the data.
The actual writing to and reading from the I/O
device is handled by eMS file management.
The essential work of the Volume Table of
Contents (VTOC)
and the Data set control Block
(DSCB) is done in CMS by a Master File Directory
(MPD)
which updates the disk contents, and a
Pile status Table
(PST) (one for each data
file).
All disks are formatted in physical
blocks of 800 bytes.
CMS continues to update the as format, within
its own format, on the auxiliary device, for
files whose filemode number is 4. That is, the
block and record descriptor words (BDW and nDW)
are written along with the data.
If a data set
consists of blocked records, the data is written
to, and read from, the I/O d~vice in physical
blocks, rather than logical records.
CMS also
simulates the specific methods of manipulating
data sets.
To accomplish this simulation, CMS supports
certain essential macros
for the following
access methods:
Updates a queue of CMTAXEs
each of
which defines
an
attention exit level.
•
BDAM
(direct) -- identifying a record
by a key or by its relative
position within the data set.
All the options of NOTE are
supported. NOTE returns the
item number of the last block
read or written.
•
BPAM
(partitioned) -- seeking
member within data set.
•
BSAM/QSAM
(sequential)
accessing
a
record in a sequence relative to
preceding or following records.
•
VSAM
(direc~
or
sequential)
access1ng a record sequentially
or directly by key or address.
1!.Q!~:
CMS :support of as VSAM
files is ba:sed on DOS/VS Access
Method
Services
and
virtual
Storage Access
Method
(VSAM).
Therefore,
the
as
user
is
restricted to
those functions
available under
DOS/VS Access
Method Services. See the section
"CMS Support for as and DOS VSAM
Functions" for details.
All the options of POINT are
supported.
POINT causes the
control
program
to
start
processing the next read or
write
operation
at
the
specified item number.
The
TTR field in the block address
is used as an item number.
CHECK
All the options of CHECK are
supported.
CHECK tests the
I/O operation for errors and
exceptional conditions.
DCB
The following fields of a DCB
may be specified, relative to
the particular access method
indicated:
134
ACCESS METHOD SUPPORT
a named
CMS also updates portions of the as control
blocks that are needed by the as simulation
routines to support a program during execution
(see Pigure
27).
Most
of the
simulated
supervisory as control blocks are contained in
the following two CMS control blocks:
IBft Vft/370: system Logic and Problem Determination Guide
!l~A1!
F,D
n (number)
a (address)
n
n
s (sYllbol)
DA
a
n
n
R,W
A,E,F,R
F,V,U
a
!lRA1!
F,D
n
a
n
n
s
PO
a
a
a
n
n
a
n
n
s
PS
s
PS
a
a
a
a
n
n
R,W
n
R,W, P
F,V,U
a
n
F,V,B,5,A,M,U
a
n
G,P,L,M
F,V,B,U,A,M,S
a
n
--------------------------------------------
DCB Fields That Can be specified for Each Access Method
CMSCVT
simulates
the
COllmunication
Vector
Table. Location 16 contains the address
of the CVT control section.
PUTX
PUTX support is provided only for data sets
opened
for
QSAM-UPDATE
with
simple
buffering.
C"SCB
is allocated from system free storage
whenever a FILEDEF command or an OPEN
(SVC19) is issued for a data set. The
CMS control Block (CM5CB) consists of a
File Control Block (FCB)
for the data
file, and partial sillulation of the Job
File control Block
(JFCB), Input/Output
Block
(lOB), and
Data Extent Block
(DEB) •
READ/WRITE (BI5AM)
BISAM is not supported in CMS.
The Data Control Block (DCB)
and the Data
Event Control Block
(DECB) are used by the
access method simulation routines of CMS.
READ/WRITE (BSAM and BPAM)
All the B5AM and BPAM options of READ and
WRITE are supported except for the 5E option
(read backwards).
READ (Offset Read of Keyed BDAM data set)
This type of READ is not supported because it
is only used for spanned records.
READ/WRITE (BDAM)
All the BDAM and BSAM
(create) options of
READ and WRITE are supported except for the R
and RU options.
The GET and PUT macros are not supported for
use with spanned records.
READ and WRITE are
supported for spanned records, provided the
filemode number is 4, and the data set is
Physical Sequential (B5AM) format.
The four methods of accessing BDAM records are:
GET (Q5A")
All the Q5AM options of GET are supported.
substitute mode is handled the same as move
mode. If the DCBRECFM is FB, the filemode
number is 4, and the last block is a short
block, an EOI indicator (X'61FFFF61') must be
present in the last block after the last
record.
GET (QI5AM)
QI5AM is not supported in CMS.
PUT (Q5AM)
All the Q5AM options of PUT are supported.
Substitute mode is handled the same as move
mode. If the DCBRECFM is FB, the file.ode
number is 4, and the last block is a short
block, an EOF indicator is written in the
last block after the last record.
PUT (QI5AM)
QI5AM is not supported in CM5.
1.
2.
3.
4.
Relative Block RRR
Relative Track TTR
Relative Track and Key TI~ey
Actual Address MBBCCHfl~
The restrictions
follows:
on those
methods
are
as
•
Only the BDAM identifiers underlined above
can be used to refer to records, since CMS
files have a two-byte record identifier.
•
CMS BDAM files are always created with 255
records on the first logical track, and 256
records
on
all other
logical
tracks,
regardless of the block
size.
If BDAM
methods 2, 3, or 4 are used and the RECFM is
U or V, the BDAM user must either write 255
records on the first track and 256 records on
every track thereafter, or he must not update
the track indicator until a NO SPACE FOUND
message is returned on a write. For method 3
(WRITE ADD), this message occurs when no more
dummy records can be
found on a WRITE
section 1. Introduction
135
request.
Por methods 2 and 4, this will not
occur,
and the track
indicator will be
updated only
when the
record indicator
reaches 256 aud overflows into the track
indicator.
•
Two files of the same filetype, which both
use keys, cannot be open at the same time.
If a program that is updating keys does not
close the file it is updating for some
reason, such as a system failure or another
IPL operation, the original keys for files
that are not fixed format are saved in a
temporary file with the same filetype and a
filename of ,KEYSAVE.
To finish the update,
run the program again.
•
Once a file is created using keys, additions
to the file must not be made without using
keys and specifying the original length.
•
The number of records in the data set extent
must be specified using the FILEDEP command.
The default size is 50 records.
•
The minimum LRECL for a
keys is eight bytes.
READING
MACROS
as DATA
SETS AND
CMS BDAM
DOS
PILES USING
as
The CMS MOVEFILE command and the same as
macros can also be used to manipulate and read
DOS sequential files that reside on DOS disks.
The as macros handle the DOS data as if it were
as data.
The following as Release 20.0 BSAM, BPAM, and
QSAM macros can be used with CMS to read as data
sets and DOS files:
ENO
FliD
GET
BOTE
POINT
POST
RDJFCB
READ
SYNADAF
SYNAl'RLS
WAIT
CMS supports the following disk
the as and OS/VS sequential and
access methods:
•
•
•
•
also
Before CMS can read an as data set or DOS file
that resides on a non-CMS disk, you must issue
the CMS ACCESS command to make the disk on which
it resides available to CMS.
The format of the ACCESS command is:
ACCESS cuu mode[/ext]
You
must
not
specify
options
or
file
identification when accessing an as or DOS
disk.
You issue the PILEDEP command to assign a CMS
file identification to the as data set or DOS
file so that CMS can read it. The format of the
PILEDEF command used for this purpose is: If you
are issuing a PILEDEF for a DOS file, note that
the as program that will use the DOS file must
have a DCB for it.
For "ddname" in the FILEDEF
command line, use the ddname in that DCB.
with
the DSN operand, enter the file-id of the DOS
file.
sometimes, CMS issues the FILEDEF command for
you.
Although the CMS MOVEFILE command, the
supported CMS program product interfaces, and
the CMS OPEN routine each issue a default
FILEDEF, yeu should issue the FILEDEF command
yourself to be sure the appropriate file is
defined.
After you have issued the ACCESS and PILEDEF
commands for an as sequential or partitioned
CMS commands
data set or DOS sequential file,
(such as ASSEMBLE and STATE) can refer to the as
data set or DOS file just as if it were a CMS
file.
Several other CMS commands can be used with
as data sets and DOS files that do not reside on
CMS disks. See the !~LJ.1.Q: ~11~ ~Q!!U!!~!!g ~!!g ~~£!:Q
R~!~I~~£~ for a complete
description of the CMS
ACCESS,
FILEDEF, LISTDS,
~JVEFILE,
QUERY,
RELEASE, and STATE commands.
formats for
partitioned
split cylinders
user labels
track overflow
alternate tracks
As in as, the CMS support of the BSP macro
produces a return code of 4 when attempting to
backspace over a tape mark or when a beginning
of an extent is found on an as data set or a DOS
file. If the data set or file contains split
cylinders, an attempt to backspace within an
136
switch,
file with
CMS users can read as sequential and partitioned
data sets that reside on as disks. The CMS
MOVEPILE command can be used to manipulate those
data sets, and the as QSAM, BPAM,
and BSAM
macros can be executed under CMS to read them.
BLDL
BSP
CHECK
CLOSE
DEO
D!VTYPB
extent resulting in a cylinder
produces a return code of 4.
For restrictions on reading as data sets and
DOS
files
under
CMS,
see
the
"VM/370
Restrictions"
in "Part
1. Debugging
with
VM/370".
The CMS FILEDEP command allows you to specify
the I/O device and the file characteristics to
be used by a program at execution time.
In
conjunction with the
as simulation scheme,
PILEDEP simulates the functions of the Data
Definition JCL statement.
PILEDEP may be used only with programs using
as macros and functions.
Por example:
IBM VB/370: system Logic and Problem Determination Guide
r--------------------------------------------------------r
r
"
r
,
FIledef
-----,
IDISK fn ft Ifmll IDSN ?
I
I
I All I I DSN q 1 [q 2 ••• ] I
L
L
JJ
J
r
r
"
L
L
JJ
DISK Ifn
ft
Ifm II
IFILE ggn~~~ IA111
DUMMY
Sgls!gg QE!ign:
r
,
IMEMBER membernamel
ICONCAT
I
L
filedef
filel
disk
proga
data
After
issuing this
command, your
referring to FILEl would access PROGA
your A-disk.
J
al
DOS/VS SUPPORT UNDER CMS
filedef filel terminal
data
for
your program
I/O performed by AUIPROC routine with
residual
count in
GPR15;
DMSSEB
returns normally.
program
DATA on
If you wished to supply data from your
terminal for FILE1, you could issue the command:
and enter the
recompiling.
GPR15>0
_________________ -J
without
fi tapein tap2 (recfm fb lrecl 50 block 100
9track den 800)
After issuing this command, programs referring
to TAPEIN will access a tape at virtual address
182.
(Each tape unit in the CMS environment has
a symbolic name associated with it.)
The tape
must have been previously
attached to the
virtual machine by the VM/370 operator.
The AUIPROC option can only be used by a program
call to FILEDEF and not from the terminal. The
CMS language interface programs use this feature
for special I/O handling of certain (utility)
da ta sets.
The AUXPROC option, followed b~ a fullword
address of an auxiliary process1ng routine,
allows that routine to receive control from
DMSSEB before any device I/O is performed. At
the completion of its processing, the auxiliary
routine returns control to DMSSEB signalling
whether I/O has been performed or not. If not,
DMSSEB performs the appropriate device I/O.
GPR15 is used by the auxiliary processing
routine to inform to DMSSEB of the action that
has been or should be taken with the data block
as follows:
CMS supports interactive program development for
DOS/VS.
7his includes
creating, compiling,
testing, debugging,
and executing commercial
application programs.
The DOS/VS programs can
be executed in a CMS virtual machine or in a CMS
Batch Facility virtual machine.
DOS/VS files and libraries
CMS. VSAM data sets can be
under CMS.
can be read under
read and written
The CMSjDOS en vironment
(called CMS/DOS)
provides many of the same facilities that are
available in DOS/VS.
However, CMS/DOS supports
only those facilities that are supported by a
single
(background)
partition.
The
DOS/VS
facilities supported by eMS/DOS are:
•
•
•
•
•
•
DOS/VS linkage editor
Fetch support
DOS/VS Supervisor and I/O macros
DOS/VS supervisor control block support
Transient area support
DOS/VS VSAM macros
The eMS/DOS environment is entered each time
the eMS SET DOS ON command is issued.
In the
eMS/DOS environment, eMS supports many DOS/VS
facilities.
When you no longer need DOS/VS
support under eMS, you issue the SET DOS OFF
command and DOS/VS facilities are no longer
available.
eMS/DOS can execute programs that use the
sequential
(SAM)
and virtual storage
(VSAM)
access
methods,
and
can
access
DOS/VS
libraries.
GPR15=0
No I/O performed by AUXPROC routine;
DMSSEB will perform I/O.
eMS/DOS cannot execute programs that have
execution-time restrictions, such as programs
that use sort
exits, teleprocessing access
methods or multitasking.
DOS/VS COBOL, DOS
PL/I, and
assembler language
programs are
executable under eMS/DOS.
GPR15<0
I/O performed by AUXPROC routine and
error was encountered.
DMSSEB will
take error action.
All of the CP and CMS online debugging and
testing facilities
(such as the CP ADSTOP and
STORE commands and the CMS DEBUG environment)
section 1. Introduction
137
are supported in the CftS;oOS environment. Also,
CP disk
error recording
and recovery
is
supported in CftS/DOS.
with its support of a CftS/DOS environment,
CftS becomes
an important tool
for DOS/VS
application
program
development.
Because
CftS/DOS was
designed as a
DOS/VS program
development tool, it assumes that a DOS/VS
system exists, and uses it.
The following
sections describe what is supported, and what is
not.
•
•
•
•
•
•
•
IBM 2314 Direct Access storage Facility
IBM 2319 Disk Storage
IBM 3330 Disk Storage, Models 1 and 2
IBM 3330 Disk Storage, Model 11 only as a
Model 1 or 2
IBM 3340 Direct Access Storage Facility
IBM 3344 Direct Access Storage
IBM 3350 Direct Access storage, only in 3330
Kodel 1 compatibility mode
CftS SUPPORT FOR as AND DOS VSAM FUNCTIONS
The
introduction
information:
CftS supports interactive program development for
OS and DOS programs using VSAM.
CftS supports
VSAM for OS programs written in VS BASIC, OS/VS
COBOL, or OS PL/I programming languages; or DOS
programs written in DOS/VS COBOL or DOS PL/I
progra.ming languages.
CMS does not support
YSAM for OS or DOS assembler language programs.
•
A brief description of the Remote Spooling
communications
Subsystem
(RSCS)
external
structure and the commands used to control
the system.
•
An overview of the RSCS control program, that
is, of the RSCS supervisor and RSCS tasks.
CMS also supports Access ftethod Services to
manipulate OS and DOS VSAft and SAM data sets.
Under CftS, VSAM data sets can span up to nine
DASD volumes.
CMS does not support VSAM data
set sharing; however, CMS already supports the
sharing of minidisks or full pack minidisks.
VSAM data sets created in CMS are not in the
CMS file
format.
Therefore,
CftS commands
currently used to manipulate CMS files cannot be
used for VSAM data sets which are read or
written in CMS. A VSAM data set created in CMS
has a file format that is compatible with OS and
DOS VSAM data sets. Thus a VSAM data set
created in CMS can later be read or updated by
OS or DOS.
Because VSAM data sets in CMS are not a part
of the CMS file system, CMS file size, record
length, and minidisk size restrictions do not
apply. The VSAM data sets are manipulated with
Access Method Services programs executed under
CMS,
instead of with
the CMS file system
commands.
Also, all VSAM minidisks and full
packs used in CMS must be initialized with the
IBCDASDI program; the CMS FORMAT command must
not be used.
CMS supports VSAM control blocks with
GENCB, MODCB, TESTCB, and SHOWCB macros.
the
In its support of VSAM data sets, CMS uses
RPS
(rotational
position sensing)
wherever
possible. CMS does not use RPS for 2314/2319
devices, or for 3340 devices that do not have
the feature.
provid(~s
the
following
• Descriptions of the nonprogrammable terminal
~ML)
line
(NPT)
and spool MULTI-LEAVING1
drivers.
•
Brief descriptions of major RSCS
and storage requirements.
data areas
•
Detailed information about RSCS supervisor
functions,
such
as
synchronizing
and
dispatching
tasks,
task-to-task
communications, I/O methods, and how RSCS
network links are manipulated.
The
VM/370 Remote
spooling
Communications
Subsystem ~SCS)
is the V~/370 component that
provides for the transmission of files across a
teleprocessing network controlled by the VM/370
computer.
using RSCS, virtual machine users can
transmi t
files to remote stations.
(Remote
stations are I/O configurations attached to the
YK/370 computer by communications lines.)
Also,
users at remote stations can transmit files to
VM/370 virtual machines and to other remote
stations using RSCS.
RSCS resides in a virtual machine dedicated
to remote spooling. using the RSCS command
manages
the
language,
the
RSCS operator
telecommunications
facilities
for
the
installaticn.
Operators at remote stations can manage their
own configurations using a subset of the command
language. Commands issued from remote stations
can be entered either at a terminal or from a
card reader.
Because CMS support of VSAM data sets is based
on DOS/VS
VSAM and
DOS/VS Access
Method
services, only disks supported by DOS/VS can be
used for VSAM data sets in CMS. These disks
are:
You can find detailed descriptions of RSCS
functions in the publication !.HLJ1.Q: lt~m.Q:t~
'Trademark of IBM
138
IBM VM/370: System Logic and Problem Determination Guide
LOCATIONS AND LINKS
AND THE VM/370 CONTROL
At a local installation there are a number of
transmission paths to remote stations. A unique
location identifier (locid) is assigned to each
of these remote stations.
Like the other VM/370 virtual machines, the RSCS
virtual machine runs under the control of CPo
In
extending
the VM/370
spooling
system
capability
to include
spooling to
remote
stations, RSCS interacts with the CP spooling
system. Therefore, some of the information in
this publication requires a knowledge of that
area of CP.
For each transmission path (nonswitched line)
or potential transmission path (switched line),
a link must be defined at the local VM/370
installation. Each such link is given a name
(linkid) that defines the location identifier of
the remote station to which the transmission
path leads. This link can be defined either at
system generation or by means of the DEFINE
command.
THE RSCS VIRTUAL MACHINE
PROGRAM (CP)
The RSCS virtual machine consists of the
virtual machine operator console, an RSCS system
disk,
and virtual
telecommunications lines.
During system generation, a virtual card reader
is defined for the RSCS virtual machine, but
this reader does not exist in the CP directory
entry for the RSCS virtual machine.
virtual printers, card punches, and readers
are defined dynamically as they are needed. For
example, when a file from a remote station is
transmitted to RSCS, a virtual punch is defined
to accept the file.
Similarly, virtual readers
are defined when RSCS
receives a file to
transmit. RSCS virtual storage also dumps onto
a virtual printer when abnormal termination of
the system
occurs.
Figure
28 shows
the
configuration of an RSCS virtual machine.
The minimum
RSCS is S12K.
virtual storage required
to run
OB1
Virtual
TCU
OB2
RSCS
Virtual
Machine
Virtual
TCU
REMOTE STATIONS
Remote stations
are configurations
of I/O
devices attached to the VM/370 computer by
binary synchronous {BSC} switched or nons witched
lines.
Two
types of remote
stations are
supported by RSCS: programmable remote stations
and nonprogrammable remote stations.
Programmable remote stations, such as the IBM
System/3 and System/370, are IBM processing
systems
with
attached
binary
synchronous
communications adapters. These systems must be
programmed to provide the MULTI-LEAVING line
protocol necessary for their devices to function
as remote stations. This programming support is
provided by a remote terminal processor
(RTP)
program generated according to HASP workstation
protocol and tailored to the system's hardware
configuration.
·Certain programmable
remote
stations
like the
System/3
can only
be
programmed to function as remote terminals.
Others, like the System/360 and System/370, can
function either as remote terminals or as host
batch systems using RSCS as a remote job entry
workstation.
Both of these types of remote
stations are managed by the spool MULTI-LEAVING
(SML) line driver of RSCS.
OB3
Virtual
TCU
~
Virtual
Console
l
191
f'-"""""I
~
RSCS
System
,-~".,
Nonprogrammable
remote
stations
are
I/O
configurations that cannot be programmed, but
are hard-wired to provide the line protocol
necessary for
them to function
as remote
stations. They can receive, read, print, punch,
and send files.
An example of a nonprogrammable
remote station is a 2780 Data Transmission
Terminal. Nonprogrammable remote stations are
managed by the NPT (Nonprogrammable Terminal)
RSCS line driver.
Figure 28. RSCS Virtual Machine Configuration
The types of devices supported for all types
of
remote
stations,
programmable
and
nonprogrammable, are listed
in the !~LJIQ:
]~~Q1~ ~EQQ!!ng £Q~~gn!£2i!QB§
.Y§~I~§ Q!!!g~.
2g~§I§1~!
(]2f2)
Section 1. Introduction
139
NETWORR CONTROL: RSCS AND VM/370 COMMANDS
r--------------------·
I Command
I Name
Both RSCS and VM/370 cOllmands are used to
control RSCS.
The RSCS com.ands are used to
control the RSCS network; VM/370 CP and CMS
commands are used by virtual lIachine users who
use the RSCS network.
I
I
------,
I
I
Function
BACKSPAC
Restarts
or repositions in a
backward
direction the
file
currently being transmitted.
CHANGE
Alters one or more attributes of
a file owned by RSCS.
CMD
Controls certain functions performed by a remote system, or
controls the logging of I/O activity on a specified link.
DEPINE
Temporarily adds a new link definition to the RSCS link table or
temporarily redefines an existing
link.
DELETE
Temporarily deletes a link definition from the RSCS link table.
DISCONN
places RSCS in disconnect mode
and optionally directs output to
another virtual machine.
DRAIN
Deactivates an
cation link.
VM/370 CP AND CMS COMMANDS POR RSCS
PLUSH
Discontinues processing the current file on the specified link.
The VM/370 CP TAG and SPOOL commands specify a
device to
be spooled and to
associate a
destination location identifier
(locid)
with
that device. SPOOL directs the file to the RSCS
virtual machine.
The CP CLOSE command or the
CMS PRINT or PUNCH cOllmands close the file and
transfer it to the RSCS virtual machine.
PREE
Resumes transmission on a communication link previously in HOLD
sta tus.
PWDSPACE
Repositions the file
being transmitted in
direction.
Data specified by the CP TAG command controls
processing of files transmitted across the RSCS
network.
When a VM/370 user creates a file to
be transmitted to a remote station via RSCS, the
TAG command text operand takes the following
format:
HOLD
Suspends file transmission on an
active link without deactivating
the line.
MSG
Sends a message
remote station.
ORDER
Reorders files enqueued on a specific link.
PURGE
Removes all or
from a link.
QUERY
Requests system information for a
link, a file, or for the system
in general.
START
Activates a specified
tion link.
TRACE
Monitors line activity
cified link.
RSCS COMMANDS
To manipulate the file being transmitted across
the network and to communicate with the various
network users, the RSCS control program provides
a command language.
Pigure 29 is a list of RSCS
commands and the functions they perform.
You
can find detailed descriptions of these commands
in the pUblication
!~LJ1Q:
~~!21~
§E221ing
£~!!~ni£~!i~n2 ~Y~212!~!
(~~£§)
Q2~E~~ ~~!~~.
The
operator
may enter
RSCS
commands
described in Pigure
29 at the RSCS virtual
machine console.
A subset of the RSCS command
language may be entered by operators of remote
stations.
lin kid [userid] [priority]
linkid
is the location identifier of the
link on which the file is to be
transmitted.
userid
is the remote virtual machine
that is to receive the file.
priority
is the
requested transmission
priority (a decimal number 0-99,
default 99).
The lower numbers
have higher priorities.
active
to a
communi-
currently
a forward
local
specified
or
files
communicaon a spe-
---------------------.-------~
Also, the CP SPOOL comlland directs files to the
RSCS virtual machine.
See the publication Por
details on how to use the CP TAG and SPOOL
commands to control RSCS network functions, see
the !~LdIQ:
B~!Qt~
§E221ing
~~!!yni£~!iQn2
~~~212!~!
140
(R2~2)
Pigure 29.
RSCS Commands and Punctions
~2~~~2 ~Yig~·
IBM VM/370: system Logic and Problem Determination Guide
When RSCS handles files being transmitted across
the network, the RSCS control program (line
driver tasks) issues CP DIAGNOSE instructions.
The DIAGNOSE instruction is the method of
communication between a virtual machine and CPo
In VM/370, the machine-coded format for the
DIAGNOSE instruction is:
o
7 8
11 12
15 16
31
-,
r
lL _ _ _
83_ _ _ _ _ _
rx
_
Content
83----rx
ry
Code
ry
_
Code
l
_____________________ J
There are two types of tasks: system service
tasks and line driver tasks.
The system service
tasks are those that provide the system support
functions for the supervisor and for other
tasks.
The line driver tasks are those that
manage the transmission paths to remote stations
and that interact between the remote stations
and
the
system
service
tasks
and
the
Supervisor. Each line driver task manages the
transmission of files to and from a single
remote station.
Figure
56
in
section
2
shows
the
communications paths between the supervisor,
system service tasks, line driver tasks, remote
stations, and VM/370 virtual machines.
R~E!g!H~!!2!!
DIAGNOSE operation code
User-specified register number
User-specified register number
Hexadecimal value
that selects
particular CP function.
In RSCS, a task is a single program or set of
subprograms that
can run
concurrently and
autonomously with
other such
programs and
subprograms, and which uses control functions
provided by the Supervisor.
a
THE RSCS SUPERVISOR
Figure 30 lists the DIAGNOSE function codes
used by RSCS, the functions of those codes, and
the RSCS modules from which they are issued.
---------------------,
l Issued bYl
r
l DIAGNOSE
l
Code
0008
OOOC
I Module (s) l
Function
Executes a CP command.
Gets the current
and date.
The RSCS supervisor is composed of a set of
service routines that provide functions for the
tasks that
run under them.
These service
routines may be called by any task.
In general,
they provide four kinds of services:
time
DMTAXS
DMTREX
DMTCMX
DMTMGX
DMTSML
DMTNPT
DMTSML
DMTNPT
0014
Manipulates input spool
files.
DMTAXS
DMTSML
DMTNPT
0020
Performs general
without interrupt.
I/O
DMTINI
0024
Determines virtual device type information.
DMTREX
DMTLAX
DMTSML
•
•
•
•
Task management
I/O management
Interrupt handling
Virtual storage management
TASK MANAGEMENT
The task management service routines provide
three kinds of services: task execution control,
task
synchronization,
and
task-to-task
communication.
Task execution control includes initiating
and terminating tasks. In general, the only task
to request these services is the REX system
control task, which is described below.
Task
execution control also includes the dispatcher,
DMTDSP, which activates task execution as soon
as that task is initiated and while the task is
active.
______________________________________
---J
005C
Edits error messages.
DMTREX
Figure 30. VM/370
DIAGNOSE Instructions
Issued by the RSCS Program
THE RSCS CONTROL PROGRAM
RSCS is
a control program composed
multitasking supervisor and
multiple
which are controlled by the supervisor.
of a
tasks,
The supervisor provides only those functions
that cannot be consistently provided by the
tasks themselves;
that
is, the supervisor
provides only the support necessary to control
and coordinate the execution of the tasks.
Task synchronization comprises a mechanism by
which tasks are made ready or not ready for
execution. When a task requests the services of
another task, the requestor task may suspend its
execution while the request is being processed.
The synchronization mechanism that accomplishes
this consists of two
routines, DMTWAT and
DMTPST.
DMTWAT causes the requestor task to
temporarily halt execution. DMTPST causes a
temporarily-halted task to resume execution.
For more information on task synchronization
refer to the section "Task synchronization".
There
are
communica tions:
and
(2)
the
(GIVE/TAKE) •
two
types
of
task-to-task
(1)
the DMTSIG routine (ALERT)
DMTGIV
and DMTAKE
routines
Section 1. Introduction
141
The
DMTSIG routine
allows
a task
to
immediately interrupt another task to pass it
information. The interrupted task must have an
asynchronous exit routine defined to handle the
interruption.
Functionally,
DMTSIG performs a
function analagous to an SVC instruction.
The DMTGIV and DMTAKE routines allow tasks to
exchange information buffers with other tasks.
The GIVE/TAKE function provides the means for
organized enqueuing and delivery of requests for
services or
information from one
task to
another.
For
more
information
on
task-to-task
communications,
refer
to
the
section
"Task-to-Task Communications" in this section.
I/O MANAGEMENT
I/O management
for
following functions:
•
•
•
•
tasks
consists
of
INTERRUPTION HANDLING
supervisor service routines handle three kinds
of interruptions: external interruptions, SVC
interruptions, and I/O interruptions.
In RSCS, supervisor routines use the SVC
(SUPERVISOR CALL)
to suspend the execution or
dispatching of a task when that supervisor
routine
received
control.
On
an
SVC
interruption in RSCS, DMTSVC is entered. DMTSVC
saves the status of the executing task and
passes control to the calling supervisor routine
in supervisor execution mode.
RSCS handles external
interruptions from
tasks
by searching
for asynchronous
exit
requests supplied by tasks. When a request with
a code matching the external interruption code
is found, its asynchronous
exit is taken;
otherwise,
the
external
interruption
is
ignored.
the
Handling requests for I/O operations
Handling I/O interrupts
starting an I/O operation
Completing an I/O request
Whenever a task requests the services of the
I/O manager, that task builds an I/O request
table to be passed to the I/O manager.
This
table consists of the following information:
I/O interruptions are handled by the RSCS I/O
manager. When an active I/O request causes an
I/O interruption, the status of the I/O request
is updated to reflect the new information.
Otherwise, a search is made for an asynchronous
exit request for the interrupting device. When
one is found, the asynchronous exit is taken.
Otherwise, the interruption is ignored.
VIRTUAL STORAGE MANAGEMENT
•
A synchronization
completion
•
The address of the device
operation is to take place
•
number of SENSE bytes
T~
when applicable
•
The address of
executed
the
lock for
signalling
on which
channel
to be
I/O
the I/G
returned,
program to
be
The following information is returned to the
task by the I/O manager, in the I/O request
table:
•
The condition code for the SID issued for the
I/O operation
•
The composite CSW
•
The SENSE bytes returned by the operation (if
any)
Using the information in this table, the I/O
manager enqueues the request on the specified
subchannel, starts the I/O operation, assembles
the return information in the requestor's I/O
request table, and posts the synchronization
lock in the I/O request table signalling that
the I/O operation is complete.
The supervisor virtual storage service routine
DMTSTO handles requests by
tasks for main
storage.
When a task requests main storage,
DMTSTO reserves page(s} of storage for it. Main
storage is freed directly by task programs.
DMTQRQ manages requests for free elements of
the
supervisor
status
queue.
Supervisor
routines call DMTQRQ to reserve and release
supervisor status queue elements.
RSCS TASK STRUCTURE
As described in the previous section, the RSCS
supervisor comprises a set of routines that
function
together
to manage
RSCS
system
processing. The supervisor provides a base for
many system programs called tasks.
(These tasks
are not to be confused with user-application
programs.)
The RSCS system service tasks perform less
generalized functions for the system than those
functions performed by the supervisor.
For
example, the AXS system service task is designed
specifically to access the VM/370 spool file
system.
The supervisor identically manages all tasks
in RSCS; the supervisor makes no distinction
between system service tasks and line driver
tasks.
Figure 31 is a list of the RSCS tasks
and a brief statement of the service each
performs.
142
IBM V"/370: System Logic and Problem Determination Guide
CREATE SYSTEM TASKS: DMTCRB
r---------
1
1
Task
Name
REX
-----,
1 Module 1
I Name 1
Function
DMTREX
Handles console I/O; accepts requests for services
passed by other
system service tasks or
line driver tasks; terminates
a task;
handles
program
check
interruptions.
DMTCRE
Creates a system service
or line driver task.
DMTCMX
Monitors
processing of
commands in RSCS;
executes the DEFINE, DELETE,
DISCONN, QUERY, and START
commands.
DMTMGX
1
1
Builds a message element
and passes the element to
to the appropriate tasks
for
transmission
or
printing.
DMTCOM
performs
common
task
functions.
1----------------------------1
1 AXS
I DMTAXS I Communicates
with the 1
1
1
1 spool file system.
I
1---------------------------------1
1 LAX
1 DMTLAX 1 Manages
telecommunica- 1
1
1
1 tions line allocation.
1
1---------------------------------1
1 Line
1 DMTSML 1 Manages a telecommunica- 1
1 tions line for a program- 1
I Driver 1
1
1
1 mabIe
remote
station 1
1
1
1
1 using RTAM.
1
1
1
1
1
1 DMTNPT 1 Manages a telecommunica- 1
1
1
1 tions line for a nonpro- 1
1
1
1 programmable remote sta- 1
J1
1L___________________________________________
1
1 tion terminal.
Figure 31.
If the command is
not one that DMTCMX
executes within its own code, the command line
is examined for syntax errors and then passed to
the appropriate task for execution. To do this,
DMTCMX generates a formatted table called a
com.and element to be passed to another active
task for execution via an ALBRT asynchronous
exit.
The commands CHANGE, ORDER, and PURGE are
executed by DMTAXS; the commands BACKS PAC, CMD,
DRAIN, FLUSH,
FREB, FWDSPACE, HOLD, MSG, TRACE
and START (for active links) are executed by the
line driver task for the specified link.
PROCESS MESSAGES: DMTMGX
DMTMGX
manages
distribution of
all
RSCS
messages, which may be generated by REX or by
any other RSCS task.
Each aessage to be issued
is presented to DMTMGX
(via GIVE/TAKE for tasks
other than REX) along with an internal routing
code and an internal severity code.
Messages may be addressed to the local RSCS
operator console, to the local VM/370 operator,
to a local VM/370 user console, to a remote
station operator, or to any combination of these
destinations, by means of the routing code. The
severity code is defined for each message, and
is an indication of the importance of the
message.
Messages for the RSCS local operator console
are enqueued for output on the RSCS virtual
machine console. Messages for the local VM/370
system operator and for local virtual machine
consoles are issued by means of execution of a
VM/370 MESSAGE command (through the DIAGNOSE
interface). Messages for remote RSCS operators
are presented to the line drivers for the
associated links by means of the RSCS MSG
command element interface.
This method of
message
handling
simplifies
RSCS
message
routing, tracing, and recording.
RSCS Tasks
The main system service task, REX, is loaded
with the supervisor during RSCS initialization.
The REX,., task,
in turn, creates other tasks
required - by the system.
DMTCRE reads these
other tasks from a CMS disk by means of a CMS
read access method. The task is then started as
a new active task under RSCS.
PROCESS COMMANDS: DMTCMX
CMTCMX receives commands by means of either GIVE
request elements passed by line driver tasks or
in the form of a console input line resulting
from a console read by DMTREX.
The commands DEFINE, DELETE, DISCONN, QUERY,
and START
(for inactive links) are executed by
DMTCMX. Execution of these commands generally
involves referencing and modification of system
status tables (SVECTORS, TTAGQ, TLINKS, etc.).
TERMINATE SYSTEM
CHECKS: DMTREX
TASKS
AND
HANDLE
PROGRAPI
When a line driver task requests termination, a
TAKE request is passed to DMTREX specifying that
function.
DMTREX marks the task as terminated,
then searches for active I/O associated with the
task.
If active
I/O
is
found, it
is
terminated. To ensure that system integrity is
maintained during the termination of the I/O, a
mechanism (at label QUIESE) is set up to handle
situations
in
which
an
HID
(Halt
I/O
instruction) does not take effect immediately.
All RSCS program checks are handled by a
routine in DMTREX.
Program check diagnostic
information is dumped, a message to the operator
is issued, and the
RSCS system status is
modified, depending on the nature of the program
check.
Section 1. Introduction
143
COMMUNICATE WITH
DMTAXS
THE VM/370 SPOOL
FILE SYSTEM:
DMTAXS is responsible for the maintenance of the
total RSCS
interface to the
VM/370 spool
system. When a spool file arrives at the RSCS
virtual machine, AXS receives the associated
asynchronous interrupt, reads and interprets the
file's VM/370 spool file block (SPBLOK) and TAG,
enqueues
the
file
for
transmission
as
appropriate, and notifies the appropriate line
driver of the new file's availability.
AXS
provides a GIVE/TAKE request interface to line
driver tasks for spool file data input and
output, and defines and detaches virtual spool
I/O devices as necessary. Also, AXS provides an
interface to DMTCMX for second-level command
execution support.
AXS maintains a queue of a fixed number of
virtual storage elements (called tag slots) that
describe files currently owned by the RSCS
virtual machine.
TO maintain RSCS integrity in
a simple way when a very large number of files
is enqueued on the RSCS virtual m~chine, the
virtual storage tag queue is not extended during
execution.
When a new file arrives at the RSCS virtual
machine, its destination locid is examined, and
it is accepted only if there is a matching
linkid for which there is a free tag slot
available.
If the file's destination locid is
not defined as a linkid, the file is purged and
the originating user is notified of the action.
If there is no free tag slot available for a
defined linkid, the file is left "pending", and
is accepted when a TAG slot becomes free.
While
a file is pending, it is not recognized by the
RSCS
command
processors,
and
cannot
be
referenced through RSCS functions.
To prevent links from being totally locked
out by an exhausted
(and stagnant)
virtual
storage tag queue, a minimum number of tag slots
is reserved for each link. This guarantees that
a minimum number of files is accepted for each
associated link.
The number of reserved slots
is defined during system generation or in the
DEFINE command for each link to be defined in
RSCS.
The appropriate number of slots to be
reserved for each link
may depend on the
expected file traffic, the link's line speed,
the expected time the link is to be active, and
the desired level of service to be provided to
the link.
This number for each link may be
arrived at through actual operational experience
in each location.
MANAGE TELECOMMUNICATION LINE ALLOCATION: DMTLAX
DMTLAX is responsible for line port resource
allocation
to line
driver tasks.
DMTLAX
allocates available switched ports
(when a link
is activated without a specified line address)
through an ALERT request interface. When a line
port is specifically
requested
(by virtual
address), DMTLAX checks the device for validity
as a line port.
144
LINE DRIVER TASKS: DMTNPT AND DMTSML
As part of the link activation process,
REX
(module DMTCRE)
loads and st.arts a line driver
task to service the remote location.
The general
are:
functions of
line driver
tasks
•
Manage I/O on the BSC line
•
Manage transmission of spool file data via a
GIVE/TAKE request to the AXS task
o
Provide GIVE/TAKE requests to
command module (DMTCMX)
the REX
task
The precise functional requirements vary from
line driver to line driver,
depending on t.he
type
of remote
station
t.he line
driver
supports.
Each
line
driver
is
responsible
for
maintenance of its link status and line act1vity
(TRAC~
records in the
RSCS system status
tables.
Two line drivers are provided, one to support
remote 2770, 2780, 3770 (in 2770 mode), and 3780
terminals, and another to interface to remote
HASP- and ASp-type systems or work stations.
THE SML LINE DRIVER PROGRAM
The SML line driver program
general types of routines:
is composed of four
Processors, which are routines that execute
the functions required by the HOST and RJE
processing modes.
o
An input/output routine that
transmits data on the BSC line.
accepts
and
•
A function selector routine that dispatches
one of the processors when a request for
services is received.
•
Buffer blocking and deblocking routines.
The SML line driver supports programmable
remote stations (in both HOST and RJE modes) for
HASP- and ASp-type systems.
HOST mode is that
processing mode in which a remote station may
submit jobs to VM/370 and receive print and
punch output from VM/370.
RJE mode is that
processing mode in which VM/370 may send jobs to
a remote batch system for processing and receive
print and punch output from
the remote batch
system.
Figure 32 shows the types of data flowing to
and from RSCS via the SML line driver program.
IBM VM/370: system Logic and Problem Determination Guide
THE SML FUNCTION SELECTOR ROUTINE: $START
HOST Mode
VM!370
f
SML
HOS~MOde
I
I
PRINT and PUNCH Output
RJEMode
System
RSCS
I
SML
I
RJE Mode
Figure
J
PRINT and PUNCH Output
32. Data Plow Between RSCS and Remote
stations via the SML Line Driver
The $START routine is entered when SML is
required
(by either a remote station or a
virtual machine) to perform a function.
The
purpose of this routine is to select a function
to execute. The routine performs this function
by using a commutator table, a list of synch
locks, and task control tables.
The SML commutator table is a branch table
consisting of branch (B) and no-operation (NOP)
instructions.
The targets
of the
branch
instructions are the seven processor routines,
each of which performs a specific function.
When the service of a processor is not required,
the Commutator Table entry for that processor is
a NOP instruction.
When the function of the
processor is required, the NOP instruction in
the commutator table entry for that processor is
replaced with a B instruction, thereby opening a
gate in the commutator table.
The
$START routine
cycles through
the
commutator table,
falling through
any NOP
instructions and taking any branches.
Control
is passed in this way to any processor whose
gate in the commutator table is open.
SML PROCESSORS
To support the HOST and RJE processing modes,
the SML program provides seven "processors," or
routines, that
handle the
seven functions
required to support the two processing modes.
Figure 33 is a list of the SML processors, the
processing modes they support, and a brief
statement of their function.
When a command is transmitted from a remote
station to RSCS, SML receives the command and
coordinates processing of
the command with
supervisor routines and the REX task command
module DMTCMX.
The SML
processor,
$WRTN1,
processes a
command request from a remote station by passing
a command request element to the REX task
(module DMTCMX) via a GIVE request. DMTCMX then
determines
whether the
command should
be
executed by DMTCMX, DMTAXS, or by the line
driver. If the command is to be executed by the
line driver, it is passed back to'SML via an
ALERT request. The SML routine CMDPROC then
executes the command.
When the processor completes the function
requested, it closes its gate in the commutator
table by replacing the B instructions with a NOP
instruction. $START continues cycling through
the commutator table taking any open branches.
When the bottom of the commutator table is
reached, $START tests a series of synch locks to
see if any have been posted,
signifying a
request for an SML function.
If any synch locks
are posted, $START opens the commutator table
gate for the requested processor and goes to the
top of the commutator table to start cycling
through it again.
If the bottom of the commutator table is
reached and there are no posted synch locks, SML
discontinues processing
by issuing
a wait
request via a call to the supervisor module
DMTWAT, waiting on a list of the synch locks.
When any 'of the synch locks is posted, $START
receives control, opens the appropriate gate,
and starts
cycling through
the commutator
table.
The task control table (TCT) is a DSECT
defining
data
required by
each
of
the
processors.
There is a TCT for each of the
processors.
Also, contained within the TCT is a
branch
instruction
to
the
appropriate
processor.
THE SML LINE IIO HANDLER ROUTINE: COMSUP
BLOCK AND DEBLOCK
$TPPUT AND $TPGET
The SML line I/O
handler routine, COMSUP,
controls communications on the BSC line for
SML. This routine receives data from the BSC
line and passes the data to the deblocker
routine ($TPGET). COMSUP also sends data (which
has been blocked by the blocker routine, $TPPUT)
to a remote station. COMSUP is also responsible
for acknowledging receipt of data over the line
using the standard BSC line contr~l characters.
SML TELEPROCESSING
BUPPERS:
Data received over the BSC line is placed in a
teleprocessing
(TP)
buffer. The size of TP
buffers is
specified by
a START
command
parameter and can be up to 1024 bytes.
Data contained in TP buffers is deblocked
into tanks, which are unit buffers of a specific
Section 1. Introduction
145
r----------------------------------------------,
Processor I
Mode
I
Function
I
I
1------1----------1--------------1
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
$CRTNl
I
HCST/RJE I Processes the followI ing
MULTI-LEAVING
I control records:
to transI permission
I mit,
request
to
SIGNON
I transmit, and
I control records.
I
I
I
I
I
I
I
I
I
I
I
$TPGET receives data from a BSC line (via the
COM SUP routine)
and allocates tanks to output
processors as they are needed.
$TPPUT receives tanks from input processors,
blocks the data in these tanks into TP buffers,
and gives control to COMSUP to transmit the
buffers over the line.
I
1--------1--------,-1-------------------1
I
$PRTN 1
I
RJ E
I
Processes print file
records received from
remote stations and
passes them to the
VM/370 spool system.
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I $URTNl
I RJE
I
I
I
I
I
I
I
I
I Processes punch file
I records received from
I remote
stations and
I passes them to the
I VM/370 spool system.
I
I
I
I
1---------1-----1---------------1
I
I
I
I
I
The NPT line driver program processes only one
file at a time; it can either receive a file as
input from the remote station or transmit an
output file to a remote station. These two
processes execute under control
of a line
monitor that reads and writes data over the ESC
line and a function
selector routine that
determines whether an input or output function
has been requested.
1---------1---------1--------------------1
THE NPT LINE MONITOR ROUTINE: LINEIO
I
I
I
I
I
I
The NPT line monitor routine, LINEIO, controls
communications on the BSC line.
This routine
sends and receives data over the BSC line.
$JRTN 1
I
I
I
I
I
I
HOST
I
I
I
I
I
I
Processes job
file
records received from
the remote
station
and passes them to
the VM/370 spool system.
I
I
I $WRTNl
I HOST/RJE \ In HOST mode, passes
I command request
eleI ments,
via DMTMGX,
I
I to DMTCMX for procesI
I sing.
I
I In RJE
mode, passes
I
I message request eleI
I ments to the RSCS opI
I era tor I s console.
I
I
1----------1
I
I
\
1----------------------
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
1-------1-----1
I $RRTNl
I
I
I HOST/RJE I Receives records from
I
I the VM/370 spool sysI
I tem for transmission
I
I to remote stations.
\
I
I
I
\-----\------1------------------\
I CMDPBOC
I
I Executes local com- I
I
I
I mands
passed
by I
I
I
I DMTCMX,
and passes I
I
I
I messages and commands I
I
I
I to remote stations.
I
L
-JI
I ________________________________________
I
I
Figure 33.
When the
data is received
from remote
stations, that data is received in the LINEINB
buffer. When data is transmitted to a remote
station, it is transitted using the LIHEBUFF
buffer.
The NPT buffers are a fixed size,
defined by
terminal type and
buffer size
specified on the SIGNON card.
THE HPT FUNCTION SELECTOR ROUTINE: NPTGET
When the NPT line driver program has been loaded
and initialized, the NPTGET program begins a
cycle in which it checks every three seconds for
one of three functions to perform:
•
•
•
Process a command
Read a file from a remote station
Write a file to a remote station
When a function is requested,
taken to the appropriate routine.
a branch
is
SML Function Processors
NPT INPUT FILE PROCESSING
size used to deblock the larger TP buffers.
There are 15 tanks; these are allocated as they
are needed by processors. The size of tanks is
determined by MULTI-LEAVING control bytes.
When an SML function has been requested, the
data must be either blocked for transmission (if
it is data for a remote station)
or deblocked
for processing (if it has been received from a
remote station) •
146
For files being received from remote stations,
two processing routines are executed: PUTVRFY
and PUTBLOCK. PUTVRFY reads the data contained
in the input buffer (LINEINB) and verifies the
BSC control characters for that data.
PUT BLOCK
deblocks the data in LINEINB, formats it for use
by VM/370, and then writes the data to the
VM/370 spool system.
IBM VM/370: system Logic and Problem Determination Guide
NPT OUTPUT PROCESSING ROUTINES
through GIVEQ. The DSECTS defining the elements
chained on these queues are: FREEE, TASKE, IOE,
ASYNE, and GIVEE.
For files being transmitted to a remote station,
three
processing
routines
are
executed:
"AKEBLOC, GETBLOCK, and GETVRFY.
"AKEBLOC accepts a block of data from the
V"/370 spool system and
passes control to
GETBLOCK. GETBLOCK then builds a buffer with
which to transmit the data and transmits the
data to the remote
station.
The response
received from that transmission is analyzed by
GETVRFY.
MAJOR DATA AREAS
MAINMAP: STORAGE AVAILABLE TO
TASKS
RSCS PROGRAMS AND
The MAINMAP DSECT is a grid of a fixed number of
bytes, each of which represents a page of
virtual
storage.
When a
task
(or
the
Supervisor) requests storage, the byte is filled
with the TASKID (generated by the Supervisor) of
the requestor, thus marking the storage page as
taken by that task.
When a page is free, its
map entry is cleared to zero by the task owning
the storage.
The major data areas used by RSCS are:
•
•
•
•
•
•
•
TAREA: THE SAVE AREA FOR AN INTERRUPTED TASK
SVECTORS
RSCS supervisor queue elements
KAINMAP
TAREA
LINKTABL
TAG
RSCS request elements
VM/370 data areas referenced by RSCS
The TAREA DSECT contains the PSW at which a task
is to resume execution, the contents of the task
general registers when it was interrupted, and
the task's request synchronization lock. This
area is used to maintain the status of a task
when it is interrupted by another task.
The data areas discussed below give a brief
functional overview of each data area and its
relationship to other data areas in the system.
These are not meant to be a comprehensive
description of the RSCS data areas.
Rather, it
is meant as an introduction to the types of data
used
by RSCS
in
performing its
various
functions.
SVECTORS:
SUPERVISOR
CONTROL
SUPERVISOR ROUTINE ADDRESSES
QUEUES
AND
LINKTABL: LINK DESCRIPTION DATA
The LINKTABL
DSECT describes
control data
associated with each link in the system. The
control data includes such information as the
linkid of the link, the task name for the link's
line driver
(that is, the name by which Rses
knows the task), the address of the line which
is used by the link, and so on. The link table
(a chain of LINKTABL DSECTS)
is built during
system generation and may be updated by the
DEFINE, DELETE, START, and DRAIN commands.
The SVECTORS DSECT contains:
TAG: THE RSCS FILE DESCRIPTOR
•
The PSW for the last task dispatched
•
The RSCS system Save area
•
The task ID and address of the
for the last task dispatched
•
pointers to the RSCS supervisor subqueues
The TAG DSECT defines the attributes and status
of a file being processed by RSCS.
The TAG is
built from information passed via the CP TAG
command (or its counterpart for remote stations)
and from the CP Spool File Block
(SFBLOK) that
describes the file.
Entry addresses for
routines
RSCS REQUEST ELEMENTS
task element
all supervisor
service
This data area is updated dynamically as tasks
execute and is used by RSCS to monitor the
execution status of the system.
Request elements are data tables built by task
programs when a service is to be requested by
the task.
RSCS SUPERVISOR QUEUE ELEMENTS
All supervisor status information pertaining to
tasks and
task requests is
maintained in
Supervisor storage defined
by the SVECTORS
DSECT. There are various queues defined in this
DSECT,
each
pertaining
to
a
particular
Supervisor function, and composed of elements of
similar format.
The heads of these queues are
defined in a portion of SVECTORS from FREEQ
For example, when a command is processed by
DMTCMX, the command line may be formatted into a
command element, which gives the following types
of information:
•
Length of the command element
•
The unique
element
code
identifying
the
Section 1. Introduction
command
147
•
The 1inkid to which command response is to be
returned
VM/370 DATA AREAS REFERENCED BY RSCS
•
Modifiers that
c omlland
There are two VM/370 CP data areas referenced by
RSCS when VM/370 spool files are processed:
•
A variable length buffer field containing the
command line
specify options
for a
given
•
SFBLOK The VM/370 spool file block
that contains control information and
describes attributes of a VM/370 spool
file.
This command element is then passed (via DMTSIG)
to another task for processing.
• SPLINK
The data block that links pages
VM/370 spool file buffer.
Other types of request elements are built to
Frocess individual commands and messages, to
create and terminate tasks, to process console
I/O, and so on.
RSCS STORAGE REQUIREMENTS
In many cases, elements are contained in a
generalized control area used when processing a
system
function,
for
example,
monitoring
requests for DMTAXS module to open or close a
VM/370 spool file.
Figure 34 shows the storage used by the RSCS
control program and how the parts of the system
(the Supervisor, the tasks, and the data areas)
fit together in storage.
0,
------------,
1
DMTVEC
1
270 1--------------------·---------- 1
1
DMTMAP
1
1-------------------------------1
1
DMTEXT
1
1-----------------------------1
1
DMTSVC
1
1
10000 r - - - - - - - - - - - - - - - - · - - - - - - - ,
1
DMTREX
1
1
DMTIOM
1
1
1
DMTQRQ
1
1-----------------------------1
1
DMTDSP
1
1
1
1
1
1
1
DMTSIG
1
1------------------------------ 1
1
DMTAKE
1
10001-----------------------------1
1
Supervisor Queue Extension
1
20001------------------------------- 1
/
/
/
/
/
/
/
/
/
/
Free storage
(al1oca table)
/L--
/
/
/
__________ -J
Figure 34.
Free Storage
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
700001----------------------1
1
Third Line Driver
1
740001----------------------1
1
Second Line Driver
1
78000 1----------------------·---1
1
First Line Driver
1
7COOOI----------------------1
1
DMTLAX
1
7 DOOO 1--------------------------·----1
1
DMTAXS
1
80000 '--------------------------------'
RSCS storage Allocation
lDMTINI begins at the first page
becomes part of free storage.
148
DMTINII
/
1----------------------------1
1
DMTSTO
1
1--------------------------------1
1
DMTASY
1
1------------------------------1
1
DMTGIV
1
DMTSYS
1 - - - - - ·- - - - - - - - - - - - - -
1-·---------------------------1
1
DMTPST
1
11
-----------------1
DMTASK
1
1------------------------------- 1
----------
1------------------
1------------------------------1
DMTWAT
DMTCRE
1---------_·_-------1
DMTCOM
1--------------------1
DMTMSG
1
1------------------------------ 1
1
--------·----1
1
DMTCMX
1
1-------------------------1
1
DMTMGX
1
-----1
1
of a
boundary following
DMTSYS.
IBM VM/370: system Logic and Problem Determination Guide
After
initialization its
storage
SYNCHRONIZATION LOCKS
The means
by which RSCS
synchronizes and
dispatches tasks are the WAIT/POST routines
(DMTWAT and DMTPST),
synchronization locks,
asynchronous
requests and
exits, and
the
dispatcher routine (DMTDSP).
synchronization locks
(or "synch locks")
are
fullwords contained in task
save areas or
control tables
(such as TAREA or IOTABLE).
Synch locks are also found in control areas 1n
function selector routines such as REXCYCLE in
module DMTREX.
The WAIT/POST method of task synchronization
(Supervisor modules DMTWAT and DMTPST) is used
when an executing task requires the services of
another task.
When this situation occurs, the
requesting task must suspend its execution while
it waits for the
requested service to be
performed.
In conjunction with the dispatcher,
WAIT/POST allows tasks to temporarily suspend
execution until they receive a signal
(via the
synch lock) that they can resume execution.
The synch lock must be set to zero before the
request for services is made. Setting the synch
lock to zero prepares it for processing by the
WAIT routine.
The first byte of the full word may contain
either a zero or a "post code." If the first
byte is zero, the task is nondispatchable,
because the requested service has not yet been
performed. A post code is a code which sets to
one any bit in the first byte of the synch
lock. DMTPST sets such a bit to specify that a
requested service has been completed.
THE WAIT/POST ROUTINES
To suspend its execution, the requesting task
calls DMTWAT, which inspects the synchronization
locks RSCS uses to synchronize task execution.
Completion of a service is signalled by means of
a synch lock, which is set
(or "posted")
by
DMTPST.
R1
r-----
1A (Synch Lock)
L
The requesting task, that is, the caller of
DMTWAT, may specify the address of a single
synch lock (as in the case of a GIVE Table or an
IOTABLE) or the address of a list of synch locks
(as in the case of REXCYCLE), one of which must
be posted by DMTPST before dispatching of the
requesting task can resume. Figure 35 shows the
contents of Register 1 on a call to DMTW1T.
Synch Lock
,
,.-----.,
1------> 1
--'
1 000000 1
,
-
.I
OR -synch Lock
r
R1
r-----------,
r---> 1
--,
0
1
1
"
--'
IA(list Address) 1------->1 A (Synch Lock) 1----'
Synch Lock
L-------'
1----------1
r
-,
11___________
A (Synch Lock) 1-------->
1 --0 - - '1
1
L
r--
------,
/
/
/
,
.I
/
1
1
11 (Synch Lock) 1---,
I
L___
Synch lock
,.---------,
>1
,
0
--'
Figure 35. Input to the DMTWAT Routine
ASYNCHRONOUS INTERRUPTIONS AND EXITS
key on the RSCS console, thereby asynchronously
interrupting execution of the REX task.
Asynchronous interruptions result from processes
external to RSCS. For example, during REX task
execution, the RSCS operator may press the ATTN
To handle asychronous interruptions, RSCS
tasks contain asynchronous exit routines. These
asychronous exit routines are set up during
initialization without dispatching
the task
being
requested to
perform the
requested
service.
Asynchronous exits are provided for
Section 1. Introduction
149
external
interruptions,
for
certain
I/O
interruptions, and for ALERT requests that occur
during execution of another task.
Asynchronous exits are taken after a
calls DMTASY specifying
the requested
conditions and
the entry
address of
asynchronous exit routine.
task
exit
the
DMTASY also handles external interruptions
reqeusted for the clock comparator. The request
element is queued on the asynchronous exit queue
and processed by DMTEXT.
The DMTASY clock
comparator provides a time delay mechanism by
using the CPU hardware clock comparator.
Asynchronous exit routines perform limited
function, often enqueueing requests for further
processing at a later time by dispatched tasks.
When the asynchronous exit routine completes
processing,
it
returns
control
to
the
supervisor, which then resumes dispatching tasks
via a call to the dispatcher (DMTDSP).
USING ASYNCHRONOUSLY REQUESTED SERVICES: DMTWAT
Before a task can use
the results of an
asynchronously requested service, it must ensure
that the service has been performed. To ensure
that the service has been performed, the calling
task signals that it is waiting for completion
of a service via a call to the supervisor
routine DMTWAT,
specifying the
synch lock
associated with the requested service.
If the high-order byte of the task's synch
lock is nonzero when DMTWAT inspects it, control
is returned directly to the calling task.
If
the high-order byte of the synch lock is zero,
DMTWAT marks the calling task nondispatchable
(via the task's request element), stores the
address of the task's request element in the
low-order bytes of the synch lock, and resumes
dispatching for other tasks.
POSTING ! SYNCH LOCK
When the requested service is comFlete the REX
Task signals completion by calling the POST
routine
(DMTPST), specifying
the requesting
task's associated synchronization lock.
The
POST routine sets the high-order byte of the
synch lock to nonzero.
This is referrred to as
"posting" that synch lock, and indicates that
the requested service is complete.
is marked "nondispatchable," a masked-on
state PSW is loaded by the dispatcher.
wait
In addition to posting a synch lock, DMTPST
inspects the synch lock to determine whether
DMTWAT has stored the address of a task element
in that synch lock, implying that the task is
nondispatchable. If this is the case,
DMTPST
marks the task's task element dispatchable and
clears the last three bytes of the synch lock to
zero.
Tasks may call DMTWAT specifying multiple
synch locks. When this is the case, each synch
lock is inspected and, if any synch lock is
posted, task execution resumes immediately. If
no synch locks are posted, the task element for
the calling task is marked nondispatchable, its
address is stored in each of the synchronization
locks, and dispatching is resumed for other
tasks.
When any synch lock in the list is posted,
the task element is marked dispatachable. The
dispatcher clears the low-order three bytes of
each
of the
task's synchronization
locks
(pointed to in the task element before task
execution is resumed) •
Refer to Diagrams 1-9 and 1-10 in the Method
of Operation section for details on processing
by DMTWAT and DMTPST.
TASK-TO-TASK COMMUNICATIONS
There are situations when a task requires the
services of another task in order to complete a
function.
For example, SML may require that AXS
open a file for input before processing of that
file can continue. RSCS task communicate with
each other to request these kinds of services
using
two
methods:
ALERT
task-to-task
communication and GIVE/TAKE communication.
Both methods use an element, which is a table
of information that describes the nature of the
request.
In general,
these elements
are
referred to as request elements and
ALERT
elements.
ALERT TASK-TO-TASK COMMUNICATION
The ALERT method of task-to-task communication
allows a task to interrupt another task to
request an immediate service.
The type of
request is described by an ALERT element, the
address of which is specified by the requesting
task in a call to DMTASY.
DISPATCHING IN RSCS
The supervisor functions return control to the
tasks by means of the dispatcher (DMTDSP). The
dispatcher scans the queue of tasks to be
executed (TASKE in SVECTORS), selects the first
dispatchable task element (that is, one that is
not marked nondispatchable by DMTWAT), moves
this task element to the end of the task queue,
and restarts its execution.
If no task element
150
The supervisor responds by g1v1ng control to
the asynchronous exit routine defined by the
request task and by passing to that task the
address of the ALERT element that describes the
requested service.
The
requested
task's (i.e.,
the
task
receiving the request) asynchronous exit routine
responds immediately and may copy the ALERT
element into
its own storage
for further
IBM VM/370: System Logic and Problem Determination Guide
processing. The receiving task's asynchronous
exit routine
then returns control
to the
supervisor, which allows the dispatched task to
resume execution.
The ALERT routine
(DMTSIG)
also notifies
another task that an asynchronous event has
taken place. In this case, DMTSIG is not used
with an ALERT request element.
GIVE/TAKE TASK-TO-TASK COMMUNICATION
While
the
ALERT
method
of
task-to-task
communication demands immediate response from
the alerted task, the GIVE/TAKE method provides
a means for ordered enqueueing of requests for
services. These requests are handled when the
servicing task is free to handle it, rather than
upon immediate demand.
Generally, request and response elements are
formatted tables of information that reside in
the storage of both the requesting task and the
task providing the service. During task-to-task
communication, these elements are passed from
one task to another, containing either requests
for services or responses to requests.
When the receiving task signals that it can
process a GIVE request, the receiving task
builds a TAKE table in its own storage.
The
TAKE table consists of a field to receive the
task name of the
requesting task and the
addresses and the lengths of a TAKE request
buffer
and
a
TAKE
response
buffer.
Functionally, these buffers complement the GIVE
request and response buffers and, like the GIVE
buffers, may
be at the same
location in
storage.
Once the TAKE table is built, the receiving
task specifies the address of the TAKE table in
a call to DMTAKE. The supervisor then moves the
GIVE request buffer (containing the GIVE request
element) to the receiving task's TAKE request
buffer.
The receiving
task performs
the requested
service and updates the GIVE request element and
places it in its TAKE response buffer.
This
modified
GIVE
request
element
contains
information on results of request processing to
be returned to the requesting task.
When all request processing is complete, the
receiving task again calls DMTAKE, specifying
the address of the TAKE table.
The supervisor
responds by immediately moving the contents of
the receiving task's TAKE reponse buffer to the
requesting task's GIVE response buffer, and
posting the synch lock in the requesting task's
GIVE table.
When a task requests services of another task
via GIVE/TAKE, it builds a GIVE table in its
storage.
The GIVE request buffer and a GIVE
response buffer.
(The request and response
buffers may
be at
the same
location in
storage. )
The GIVE request buffer contains a GIVE
request element, which is a table of information
describing the service being requested.
Once
the
GIVE request
element
is built,
the
requesting task clears the synch lock in its
address
of the
GIVE table
to zero
(in
preparation for a call to DMTWAT) and specifies
the address of the GIVE table in a call to
DMTGIV.
The supervisor then enqueues a supervisor GIVE
element containing a pointer to the GIVE table,
so that the request can be forwarded to the
receiving task when that task is ready to accept
the request.
If another
GIVE request addressed
to the
receiving task has been enqueued, it is given to
the receiving task as described above, and
dispatched task execution is resumed.
On each
call to
it, DMTAKE
first responds
to a
previously accepted GIVE request (if one exists)
and then gives another modified GIVE request
element back to the
calling task
(if one
exists).
The requesting task waits for request completion
by specifying the address of the synch lock in
its GIVE table in a call to the WAIT routine
(DMTWAT) •
The
receiving
task waits
for
request
availability by calling DMTWAT and specifying
the address of its "task request synch lock,"
which is located in its Task Save Area.
The
task request synch lock is cleared to zero by
DMTAKE when no GIVE request address to the
calling task remains enqueued.
It is posted by
section 1. Introduction
151
DMTGIV when such a request is enqueued as
result of DMTGIV processing for another task.
a
data area.
Figure 37 shows the
between these various data areas.
relationships
Figure 36 shows the movement of data during a
GIVE/TAKE transaction.
ACTIVE AND PENDING I/O QUEUES
SVECTORS
GIVEE
GIVEE
The supervisor I/O queues (MPXIOQ and SELIOQ)
include an active queue and a number of inactive
or "pending" subqueues.
Each element in the
active I/O queue represents an I/O operation
which is active on a particular nonshared I/O
subchannel.
The active I/O queue is ordered
according to ascending numerical I/O subchannel
address.
GIVEE
~====J---~==~~-C==~
GIVEQ
Request
' - -_ _- I ' -
Element
SML
STORAGE
(Giver)
When an I/O operation is requested on an idle
I/O subchannel, an I/O element representing the
request is built and enqueued on the active I/O
queue in its I/O subchannel's numerical address
position. The I/O operation is then started.
GIVE
Request
Table
..........
,
\.
\.
TAKE 2 \
(Taker)
I
\
\
I
,
Request
Table
I
\
\
TAKE
\
\
Figure 36.
\.
"- ......
/
.......
Movement of Data During
GIVE/TAKE Transaction
/
/
I
I
I
.,,/
When an I/O operation is requested on an I/O
subchannel for which an I/O element is enqueued
on
the active
I/O
queue, the
nonshared
subchannel is busy and, therefore cannot be
started immediately.
In this case, an I/O
element representing the request is built and
enqueued on
the subchannel's
inactive I/O
subqueue.
The
head of
this subqueue
1S
contained in the active I/O element enqueued on
the active I/O queue.
When the nonshared subchannel's active I/O
completes and the subchannel becomes available,
the first element on the inactive I/O sub queue
is enqueued on the active I/O queue and its I/O
operation is started.
a Typical
HANDLING LINK ACTIVITY: LINKTABLS AND TAGS
INPUT/OUTPUT METHODS AND TECHNIQUES
Two data structures are
created when RSCS
performs an I/O operation: an I/O element and an
I/O table.
The I/O table (defined by DSECT lOT ABLE) is
built by the requesting task and describes
specific inforaation required to perform the
requested I/O operation.
The I/O element
(defined by DSECT IOE)
is
built by the I/O request manager
(DMTIOM) and
consists
of
items of
system
information
describing a request for an I/O operation.
When the RSCS system is generated, a number of
TAG slots are generated and enqueued on the free
TAG queue. TAG slots are storage areas defined
by the TAG DSECTi TAG slots describe the files
being transmitted via RSCSi the free TAG queue
cOllprises those TAG slots available for a given
RSCS system.
The Free TAG Queue is define~ in the DSECT
TAGAREA, which also defines the status of TAG
slots in the RSCS system. TAGAREA is pointed to
by TTAGQ in SVECTORS.
HOW LINKS HANDLE FILES
I/O elements are placed on queues pointed to
in
SVECTORS: MPXIOQ
(for multiplexer
I/O
requests)
and
SELIOQ
(for
Selector
I/O
requests).
The elements in these two queues are
in ascending subchannel order.
Queue elements
may also contain pointers to subqueues, which
represent requests for use of the same nonshared
subchannel.
Each I/O elellent points to an I/O
table.
Each link in RSCS is defined by a LINKTABL
DSECT. The LPOINTER field of the LINKTABL DSECT
points to the link's inactive TAG queue. Tbis
queue comprises those TAGs describing files tbat
RSCS has not yet transmitted.
Only one TAG per
link can be active at a time.
Also, there is a queue of I/O asynchronous
exit request elements pointed to in the SVECTORS
The queue of LINKTABLs (called the link
table)
is pointed to by the TLINKS field in
SVECTORS.
152
IBM VM/370: system Logic and Problem Determination Guide
ACTIVE
IOE
SVECTORS
IOTABLE
MPXIOQ
SELlOQ
IOEXITQ
ASYNE
Figure 31.
ASYNE
ASYNE
I/O Queues and Subqueues
TRAISftITTIIG Vft/310 FILES TO AI ascs LIRK
from the active input queue and
returned to the Free TAG Queue.
When a Vft/310 file is spooled to RSCS for
specific link, RSCS accepts the file and:
its slot
is
a
PROCESSING FILES FROft REftOTE STATIONS
•
Obtains a free TAG slot for the file.
•
Builds a description
slot.
•
Enqueues the
TAG queue.
of the file in
the TAG
link's inactive
As in the case of Vft/310 spool files, when files
are received from remote stations, RSCS obtains
a TAG slot and builds a description of the file
in that slot.
However,
files from remote
stations are enqueued on the active output queue
(TAGACOUT in TAGAREA) •
When trans.ission to the reaote station begins,
the file's TAG is dequeued from the inactive TAG
queue and enqueued on the active input file
queue (TAGACIN in TAGAREA).
When transmission
of the file is complete, the TAG is dequeued
When the file is completely transmitted, its
TAG is dequeued from the active output queue,
closed to the Vft/310 spool system, and its freed
slot returned to the free TAG queue.
new TAG on the
Figure 38 shows the relationships between the
DSECTs described above.
section 1. Introduction
153
LlNKTABL
Link's Inactive llii Queue
These are TAG's representing
files waiting for transmission;
that is,waiting to be enqueued
on the Active Input TAG Queue
described below.
• • •
LPOINTER
Freg TAG Queue
All TAG "slots" which are
not in use to d()scribe a file
are enqueued on the free
TAG queue.
TLiNKS
TTAGQ
TAG
TAG
ITDTI
TAG
TAG
Active L!l.I2.!J.! TAG Queue
There may be only one active
input file for any given link on
this queue. Each file which is
being read from the VM/370 spool
system and transmitted to a
remote station is represented by
a TAG on this queue.
TAG
DTI~D
Figure 38. Chaining of Data Areas Required for File TAG Manipulation
154
IBM V8/310: sJste. Logic and Proble. Deter.ination Guide
Active Output TAG Queue
Each file which is being written
to the VM/370 spool system is
represented by a TAG on this
queue.
section 2 describes the progra. organization for
CftS, CP, and BSCS.
The CftS description is in two parts. The first
part contains figures showing the functional
organization of CftS. The second part contains
general information about internal structure of
CftS programs and their interaction with one
another.
CftS program organization is in two figures.
Figure 39 is an overview of the functional areas
8
,..---------,
Process
Commands
that Manipulate
the File System
Manage
the CMS
File
System
of CftS.
Each block is nu.bered and corresponds
to a .ore detailed outline of the function found
in Figure 40.
Figure 40 shows how CftS routines relate to
these functional areas. The numbers on top of
each detailed figure correspond to the numbers
on Figure 39.
In most cases, the detailed figures contain
three levels of information: the functional
topic, a breakdown of logical areas within that
topic, and the CftS routines that perform those
logical functions.
r---------,
Handle
I/O
Operations
Process
And
Execute
CMS Files
Initialize the
CMS Virtual
Machine
Environment
o
Handle
Interruptions
Manage
CMS
Storage
Simulate
Non-CMS
Operating
Envi ron ments
Perform
Miscellaneous
CMS Functions
Figure 39. An Overview of the Functional Areas of CftS
section 2. ftethod of Operation and Program Organization
155
(2
Initialize the
CMS Virtual
Machine
Environment
Process
and
Execute
CMS Files
r
Maintain an
Interactive
Console
Environment
DMSINI
Read theCMS
nucleus
I
I
I
Process
and Execute
EXEC Files
I
I
I
J
Load and
Execute
TEXT Files
Process
MODULE
Files
I
I
I
Perform
Library
Support
Functions
1
DMSINT
DMSEXC
DMSLOA
DMSMOD
DMSLBM
Interpret
commands
entered at
the console
Load a disk
version of
the EXEC
processor
Process the
LOAD and
INCLUDE
commands
Generate
a MODULE
file
Generate and
update MACLIB
files
DMSINS
DMSEXT
I
I
1
DMSINA
DMSLDR
DMSMOD
DMSLBT
Initialize
storage constants
and virtual disks
for a virtual
machine
Handle
synonyms and
abbreviations
Perform
EXEC
processing
Begin execution
of programs
in storage
Load a
MODULE
file
Generate
and update
a TXTLIB
library
DMSINT
DMSSCN
DMSLSB
Handle first
commands
entered at
the console
Process a
command line
and create
a PLiST
Process
loader
options
DMSSET
DMSCPF
DMSLlO
Set virtual
machine
environment
options
Pass a
command
line to CP
for execution
Create a
load map
and perform
loader I/O
I
I
DMSQRY
DMSITS
DMSMDP
Query the
virtual machine
environment
option settings
Process
command
functions
via SVC calls
Type a load
map at a
console
I
I
I
I
I
I
I
DMSGLB
Define libraries
to be searched
during execution
and assembly
I
DMSLGT
Create a chain
of TXTLIB
blocks for use
during execution;
release the chain
I
DMSLlB
Search TXTLIB
libraries for
undefined symbols;
close TXTLIB
libraries
Figure 40. Details of eMS System Functions and the Routines That Perform Them (Part 1 of 4)
156
IBM VM/310: System Logic and Problem Deteraination Guide
I
CD.
CD
Process
Commands
that Manipulate
the File System
I
Perform
General File
Support
Functions
I
DMSSTT
Verify the
existence of
a file and
return its address
1
Manage
the CMS
File
System
I
I
I
Perform
Data
Manipulation
Functions
I
DMSEDC, DMSEDF
DMSEDI, DMSEDX
Create and
update files
Manage
Virtual
Disk Data
I
I
1
I
I
Locate
Data in
the CMS
File System
Perform
File
Update
Functions
J
J
DMSPRT
DMAACC
DMSLAD
DMSARE
Print a
record
Access data
on a virtual
disk
Find an
active disk
table
Clear an
active
disk table
I
I
DMSLST
DMSUPD
DMSPUN
DMSACM
DMSLAF
DMSFNS
List the
names of
files on a
CMS disk
Update
source
files
Punch
a record
Build an
active disk
table
Find an
active file
table
Close any
open files
on disk
I
I
I
I
I
T
I
T
T
DMSSYN
DMSCPY
DMSTYP
DMSACF
DMSLFS
Create synonyms
and abbreviations
for a file name
Manipulate
disk file
records
Type a
record
Build file
status table
blocks for a
virtual disk
Find a file
status
table
I
I
I
I
DMSALU
Clear tables
and free storage
associated
with a disk
J
DMSRNM
DMSCMP
DMSASM
DMSLAF
Rename
a file
Compare
records in
two files
Interface
with the
assembler to
assemble files
Create or
delete active
file table
entries
I
I
I
DMSERS
DMSSRT
DMSDSK
Erase
a file
Sort/arrange
records in
a file
Load card-todisk, dump
disk-to-card
I
I
DMSRDC
DMSTPE
Read a
record
Process
TAPE command
functions
I
I
DMSMVE
Move data
from one
device to
another
Figure 40. Details of eMS System Functions and the Routines That Perform Them (Part 2 of 4)
Section 2. Method of Operation and Program Organization
157
CD
I
0r----'--.. .
Handle
110
Operations
I
I
Perform
Console
110
I
I
I
Perform
Perform
Perform
Write to
Unit
Record
110
Tape
110
a Display
Terminal
DMSDIO
I
OMSPIO
I
write one or
Perform print
more blocks
110 functions
I
DMSTPD
DMSSCR
Read a
PDS tape
Load display
buffers to be
displayed on
Read or
Start an
110 operation
I
Disk
110
I
DMSCIT
I
of disk data
I
I
DMSTOO, OM:; I HK
DMSCWT
Manipulate
Wait fora
console event
to complete
storage
management
chains
l
DMSCAT
Perform read
Read or
Issue a
card and punch
write a tape
card 110
record
I
I
DMSCWR
DMSTMA
input for
items on a
disk file
Write a
line to the
console
CMS
Interrupts
Storage
I
Wait for
110 to
Complete
I
DMSIOW
Wait for
an 110 event
to take place
DMSCIT
DMSFRE
Handle
console
Allocate and
release free
system and
user storage
interrupts
I
DMSGI
I
Read or write
I
I
DMSTIO
DMSBRD. DMSBWR
Stack a line
of console
DMSCRD
I
DMSCIO
Manage
Handle
DMSHDS
DMSITS
Set up and
display to
Handle SVC
screen
interrupts
I--
DIAGNOSE
Read an unloaded
PDS from tape
and place it in
a [IIIACLIB
handle user·
defined SVC
interrupts
DMSITI
Handle 110
interrupts
DMSSMN
Allocate and
release user storage
upon request by
OSGETMAINI
FREEMAN macros
DMSHDI
t--
Set up and
handle userdefined 110
in1errupts
I
DMSCRD
DMSPNT
DMSITE
Set the read
Read a
or write
line of
pointer for a
fHetoa given
file item
console
input
Handle
external
interrupts
I
DMSCWR
DMSITP
Write a line
to the console
Handle
program check
interrupts
figure 40. Details of e"s System functions and the Routines That Perform Them (Part 3 of 4)
158
IB" V"/370: System Logic and Problem Deter.ination Guide
CD.
0
I
Simulate
Non-CMS
Operating
Environments
r
Perform
Miscellaneous
CMS Functions
1
1
r
I
DMSBTB
Provide
Access
Method
Support
1
Simulate
OS
Functions
DMSFLD
Support
OSAM
Interpret OS
JC L parameters
for use by CMS
I
DMSSBS
Support
BSAM and
BPAM
I
Load the CMS
Batch Virtual
Machine
I
DMSDBG
DMSGND
DMSABN
Perform
DEBUG
functions
Generate
an auxiliary
directory
Handle
abnormal
termination
1
1
DMSBTP
Perform batch
processing
functions
-~
I
1
1
DMSOVR
DMSASD
DMSERR
Load the
SVCTRACE
module,
DMSOVS
Provide an
auxiliary
directory
Generate
error
messages
-I
1
1
DMSOVS
DMSLAD
DMSSVT, DMSSOP,
DMSSCT, DMSSMN,
DMSSVN, DMSSLN,
DMSSAB
Perform
SVCTRACE
functions
Include an
auxiliary
directory on
the FST chain
Simulate OS
macros
I
DMSSBD
DMSSEB
Support
BDAM
Perform
I/O functions
for OS
1
Simulate
DOS
Functions
I
DMSSOS
I
1
I
1
DMSVIB
DMSROS
Load the
CMS/VSAM
shared system
for OS VSAM
programs
Allow CMS to
ACCESS,STATE,
READ, NOTE,
and BACKSPAC
on OS disks
Initialize
DOS and
Process DOS
System Control
Commands
Process
DOS I/O
Functions
I
I
Process
DOS Execution
Related
Functions
I
1
I
Provide
DOSSVC
Simulation
Process
DOS
Service
Commands
I
I
Terminate
the DOS
Environment
1
I
DMSVIP
DMSLDS
DMSSET
DMSBOP
DMSDLK
DMSDOS
DMSSRV
DMSBAB
Interface with
VSAM programs
to perform VSAM
functions for
OS VSAM programs
List
information
about OS
data sets
Initialize
the CMS/DOS
environment
Simulate
the DOS/VS
OPEN function
Link·edit
DOS/VS
phases in
storage
Handle all
CMS/DOS SVC
requests
Copy books from
a source statement
library to an
output device
Pass control to
an abnormal
termination
routine via
STXIT AS macro
I
I
I
DMSOPT
DMSOR1, DMSOR2
DMSOR3
DMSFET, DMSFCH
DMSRRV
DMSITP
Load a phase;
begin program
execution
Copy modules
from a
relocatable
I ibrary to an
output device
Process program
interrupts
and SPI E
exits
I
DMSVSR
Reset fields
set during VSAM
processing and
purge the CMS/
VSAM DCSS
Set compiler
options
Locate a
specified
file
DMSASN
DMSOPL
1
DMSAMS
Support
VSAM
Access Method
Services
1
Associate system
or programmer
logical units
with physical units
Access a source
statement
library for a
DOS/VS compiler
1
1
DMSPRV
DMSDMP
Copy procedures
from a procedure
library to an
output device
Simulate
$$DUMP and
$$PDUMP; issue
CP DUMP
DIAGNOSE
1
DMSLLU
DMSCLS
DMSDSV
List assignments
of logical units
Simulate the
DOS/VS CLOSE
function
List the
directories
of libraries
I
DMSDLB
DMSDSL
Ass·ociate a
DTF table
filename with
a logical unit
Delete, compress,
I ist phases of
a DOSLIB
library
Figure 40. Details of eMS System Functions and the Routines That Perform Them (Part 4 of 4)
section 2. Method of Operation and program OrganiZation
159
INTRODUCTION TO CMS
This introduction contains brief descriptions of
the concepts on which CMS operates, for example,
how the CMS file system is organized.
This
introduction also contains descriptions of logic
flow for significant routines, for example, the
logic executed when the CMS command handler,
DMSITS, is invoked.
The following CMS information is organized
into topics that correspond to the functional
areas described in the previous charts.
INITIALIZE THE CMS VIRTUAL MACHINE ENVIRONMENT
There are four steps
CMS virtual machine:
Once written on the DASD,
a copy of the
nucleus is read into virtual machine storage.
One track
at a
time is
read from
the
disk-resident nucleus into
virtual storage.
DMSINS is then invoked to initialize storage
constants and to set up the disks and storage
space required by this virtual machine.
DMSINS performs three general functions:
•
Initializes
tables.
•
Processes IPL
and BATCH).
•
Initializes for os SVC processing, in the
case where a saved segment is not available
for
use
in
processing
os
simulation
req.uests.
storage
constants
command line
and
system
parameters (SEG=
involved in initializing a
•
processing the IPL command for a virtual card
reader.
•
processing the IPL command for a disk device
or a named or saved system.
•
processing the first command
the CMS virtual console.
•
setting up the options
for
machine operating environment.
line entered at
the
virtual
DMSINS
---Saves the address of
BUCON.
this virtual machine in
DMSLAD
---~~~ates and
returns the address of
for this virtual machine.
the ADT
DMSINI and DMSINS are the two routines that
are
mainly
responsible for
the
one-time
initialization process in which the virtual card
reader is initial program loaded.
DMSIBI also
handles the IPL process when a named or saved
system is loaded. The CMS command interpreter,
DMSINT, processes the first line entered from
the console as a special case; the processing
performed by this code is
a part of the
initialization process.
DMSSET sets up the
user-specified
virtual
machine
environment
features; DMSQRY allows the user to query the
status of these settings.
DMSACM
---Reads the S-disk
SSTAT.
INITIALIZATION: LOADING A
FROM CARD READER
DMSFRE
---Releases the low free storage allocated above
(to force SSTAT into high storage) so that it
can be used again.
CMS VIRTUAL
MACHINE
When a virtual card reader is specified by the
IPL command,
for example OOC, initialization
processing begins. Initialization refers to the
process of loading from a card reader as opposed
to reading a nucleus from a cylinder of a CMS
minidisk or reading a named or shared system
(description follows) •
IPL OOC invokes the CMS module DMSINI, which
requests that the operator enter information
such as the address of the DASD where the
nucleus is to be written, the cylinder address
where the write operation is to begin, and which
version of CMS is to be written (if there is
more than one to choose from).
When
all
questions are
answered,
the
requested nucleus is written
to the DASD.
Figure 41 shows the
structure of the CMS
nucleus.
160
DMSFRE
---illocates free
initialization.
storage to
be
used
during
DMSFRE
---illocates all low free storage so that the
system status table (SSTAT)
will be built in
high free storage.
ADT entry
and builds
DMSINS
---stores the address of SSTAT into
ADTFDA in NUCON.
the
ASSTAT and
R!12!1!!
Sorts the entries in the SSTAT.
DMSINS
---Checks for parameters BATCH and SEG=.
If
BATCH is specified, DMSINS sets the flag
BATFLAGS. If SEG= is specified, DMSINS loops
through again to read the segment name. At
this point, all the parameters on the command
line have been scanned.
IBM VM/370: system Logic and Problem Determination Guide
CONTROL BLOCKS
INFREESTORAGE----------~
END OF STORAGE
VIRTUAL
STORAGE
-r------------------.
System Loader Table (Size determined
by SET LDRTBLS command) Storage Key = X'F'
FREEUPPR----~r_------------------------._-----
DMSFREE requests when
no more low storage available
FREELOWE - - - 1 - - -
.
-
-
-
-
-
-
-
--
BBG
BBG
Unused portion of User
Program Area
DMSNUC
MAINHIGH ---+--G
--ETMA:
MAINSTRT-----t-- -
-
requ:t~ -
--- -
-
-
Storage Key = X'E'
X'3000'
-
X'2ADS'
~t:a~
_L ~y~ ~~
X'2A40'
X'29BO'
X'2800'
The User's Program
(program is loaded via the
LOAD command)
X'235O'
X'2300'
X'20000'~------------S-to-r-a~ge-K-e~y-=-X-'-E_i'
CMS Nucleus
In "saved systems" this area
is a protected segment
(that is, a" code must be
reentrant and cannot be
modified)
X'219O'
X'lDDO'
FVS
X'lADS'
X'l 0000 -11-------------------------'''----'------1
Transient Program Area
DIOSECT
X'19ES'
SVCSECT
X'174S'
X'EOOO'-It------------------'
Low Storage DMSFREE Free Storage Area
DMSFREE requests are filled from
this area. The upper part of this
area contains the System Disk MFD
followed by the FREETAB, if there is
enough room.
X'3000'-+----------S-t-or-a~g-e-K-e~y-=-X-'E-'-o-r-X-'-F_'
DMSNUC
System Control Blocks, flags, constants,
and pointers.
X'16BO'
X'1620'
X'1550'
X'1200'
X'DFO'
X'C90'
X'O' - - - - - - - - - - - - - - - - - - - -
*The half-page containing OPSECT and TSOBLOKS
has a storage key = X'E'
Figure 41.
X'700'
X'600'
X'2EO'
eMS Storage Map
section 2. Method of Operation and Program Organization
161
If SEG= is specified, the DIAGNOSE 64
FINDSYS function is
issued to determine
whether the segment specified on the command
line exists.
If it does, the DCSSAVAL flag
is temporarily set.
!B.t~!.!H!
DMSSTT
---pInds and returns the
CMS OS SVC-handler.
!H!1iI!Ul
Acquires
DMSSVT.
Issues DIAGNCSE 24 to
of the console.
enough
free
address of DMSSVT, the
storage
to
contain
obtain the device type
DM5LOA
---Loads DMSSVT.
DMSCWR
---wrItes the system id message to the console.
!2!2~11Hi
Sets the flag DCSSVTLD.
DMSCRD
---Reads the IPL command line from the console.
DMSSCN
---Puts 3 the IPL command line in PLIST format.
DMSINS
---If-the FINDSYS DIAGNOSE validated the segment
name specified on the IPL command line,
DMSINS issues a DIAGNOSE 64 SAVESYS function
for that segment.
DMSINS
Clears DCSSAVAL and ensures that all the
parameters on the command line are valid;
branches back to label INITLOOP to reprocess
for the segment just saved.
DM SINS
---1£-
the BATCH virtual machine is not being
IPLed, determines whether there is a PROFILE
EXEC or a first command line to be handled.
If so, issues SVC 202's to process these
commands and passes control to DMSINT, the
CMS console manager.
DMSACC
---ii-the BATCH virtual machine is being initial
program loaded,
accesses
the D-disk and
passes
control to
DMSINT, the
console
manager.
DMSINS
---1£-
BATCH is specified, sets BATFLAGS
BATFLAG2 in NUCON.
Saves the name of
BATCH saved system in SYSNAME in NUCON.
DMSACC
---Issues ACCESS 195 A to
virtual machine A-disk.
access
the
and
the
batch
DMSINS
---Issues DIAGNOSE 60 to get the size of the
virtual machine; sets up enough storage.for
this virtual machine.
DMSINS
---if-the DCSSAVAL flag is set, sees if the size
of the CMSSEG segment overlaps the size of
the virtual machine.
If this is the case,
DMSINS sets the flag DCSSOVLP and continues
the initialization
procedure for
a CMS
virtual machine running without the use of
the
CMSSEG segment,
that is,
performs
time-of-day
processing
and
05
initialization.
A named system is a copy of the nucleus that has
been saved and named
with the CP 5AVESYS
command.
It is faster to IPL a named system
than to IPL by disk address because CP maintains
the named system in page format instead of CMS
disk format.
That is, the saved system is on
disk in 4096-byte blocks instead of aOO-byte
blocks. The initialization of a saved system is
also faster because the SSTAT is already built.
The shared system is a variant of the saved
system.
In the
shared system,
reentl:ant
portions of the nucleus are placed in storage
pages that are available to all users of the
shared system.
Each user has his own copy of
nonreentrant portions of
the nucleus.
The
shared pages are protected by CP, and may not be
altered by any virtual machine.
If the CMSSEG segment can be used, DMSINS
issues the DIAGNOSE 64 LOADSYS function as
the final check to see if the segment is
usable.
If
the
segment
is
loaded
successfully, it can be used whenever one of
the functions contained in it is requested.
Because it is
not required immediately,
DMSINS issues
the DIAGNOSE
64 PURGESYS
function to purge the segment.
During DMSINI processing v the virtual machine
operator is asked if the nucleus must be written
(via message DMSINI607R).
If the operator
answers no, control passes directly to DMSINS to
initialize the named or saved system specified
by the operator in
his answer to message
DMSINI606R.
If the segment cannot be successfully
loaded, DMSINS turns off the DCSSAVAL flag.
HANDLE THE FIRST COMMAND LINE PASSED TO CMS
DMSIN5
---Checks for the availability of CMSSEG.
162
INITIALIZING A NAMED OR SAVED SYSTEM
DMSINT, the CMS console manager, contains the
code to handle commands stacked by module DMSINS
during initialization processing.
DMSINT checks
for the presence of a stacked command line, and
if there is one to process, processes it just as
it would a command entered during a terminal
session.
That is, DMSINT calls the WAITREAD
IBM VM/370: System Logic and Problem Determination Guide
subroutine and issues an SVC 202 to execute the
command.
When
first
command
processing
completes,
DMSINT receives control to handle
commands entered at the console for the duration
of the session.
SETTING AND QUERYING VIRTUAL MACHINE ENVIRONMENT
OPTIONS
DMSSET sets up the virtual machine environment
options, as outlined in the publication !~LJIQ:
CMS
Command and
Macro R~!~~~B£~.
DMSQRY
aisplays--these-settings--at the user console.
Both of
these modules are
structured and
relatively easy to follow,
except for some
sections of DMSSET.
whether the segment
storage.
overlays virtual machine
DMSSET
---If-the segment can be used
(i.e. does not
overlay the virtual machine storage)
the
DIAGNOSE 64 LOADSYS function is performed.
If the LOADSYS executes successfully, control
passes to DMSINT, where the segment is purged
(because it is only needed on demand) •
PROCESS AND EXECUTE CMS FILES
As shown in Part 1 of Figure 40, the five
general topics form the category "Process and
Execute CMS Files."
Two of these topics are
discussed in this
section: "Maintaining an
Interactive Console Environment" and "Loading
and Executing TEXT files."
MAINTAINING AN INTERACTIVE CONSOLE ENVIRONMENT
DMSSET
---Clabel DOS)
If a disk mode is specified on
the command line, ensure that it is valid.
DMSLAD
---I~the disk mode
specified is valid, locates
and returns the address of the disk.
DMSSET
---Issues DIAGNOSE 64 FINDSYS to locate the
CMSDOS segment.
If the
segment is not
already loaded, issues DIAGNOSE 64 LOADSYS to
load it.
DMSSET
---Sets up the SSB-transient area for use by DOS
routines.
DMSSET
---ii-SET DOS OFF has been specified, issues the
DIAGNOSE 64 PURGESYS function for the CMSDOS
segment and, if VSAM has been loaded, for the
CMSVSAM segment.
Two levels of information are discussed in the
following section. The first level is a general
discussion of how CMS maintains an interactive
console environment. The second- level is a more
detailed discussion of the methods of operation
mainly responsible for this' function.
CONSOLE MANAGEMENT AND COMMAND HANDLING IN CMS
There are two major functions concerned with
maintaining an interactive terminal environment
for
CMS:
console management
and
command
processing.
The CMS module that manages the
virtual machine console is DMSINT.
The module
responsible for command processing is DMSITS.
Many CMS modules are called in support of these
two functions but the modules in the following
list are primarily responsible for supporting
the functions:
DMSCRD
---Reads a line from the console.
DMSCWR
---wiItes a line to the console.
DMSSET
---Determines whether the name
segment is being changed.
DMSSCN
---converts a command line to PLIST format.
of the
CMSSEG
DMSSET
---Determines whether NONSHARE is specified.
If
so, the segment may be loaded and kept. If
RONSHARE is not specified, the segment is
purged, because it is needed only on demand.
IHHH21!I
Once a new name is placed in the SYSRAMES
table replacing CMSSEG,
the DIAGNOSE 64
FINDSYS function is
issued to determine
whether the
new name has
been entered
correctly. If the FINDSYS is successful, the
size of the virtual machine is compared to
beginning address of the segment to determine
DMSIRA
---coDverts abbreviated
names.
commands to
their full
DMSCPF
---Passes a command line to CP for execution.
MAINTAINING
SESSION
AN
IRTERACTIVE
COMMAND/RESPONSE
Three main
lines of control
maintain the
continuity for an interactive CMS session: (1)
handling of commands passed to DMSINT by the
Section 2. Method of Operation and Program Organization
163
initialization module, DMSINS
(2) handling of
commands entered
at the console
during a
session, and (3) handling of commands entered as
subset commands.
The following lists show the
main logic paths for first two functions.
Q~~~£]
Converts the command line
(subroutine waitread) •
to PLIST
format
Q~'§!!!l
Determines whether the command line is a null
line or a comment.
DMSLFS
---ii-the command line is neither a command line
nor a comment, determines whether the command
is an EXEC file.
DMSINT
---on-entry from DMSINA, processes any commands
passed via the console read put on the user's
console by that routine; that is processes
any commands the user stacks on the line as
the first read that DMSINT processes.
In
handling the first read, if that read is
null, control passes to the main loop of the
program, which is described in the following
section.
Q~'§!!!!
(AJHHUt!)
Determines
whether
the command
is
an
abbreviation and, if it is, returns its full
name.
DM SITS
---Passes the command line to DMSITS via an SVC
202. DMSITS is the CMS SVC handler.
For a
detailed description of the SVC handler, see
"Method of Operation for DMSITS."
DMSINM
---Get
the current time.
DMSCRD
---Branch to the waitread subroutine to
command line at the console.
read a
DMSSCN
---wiItread then calls DMSSCN to convert the
line just read into
plist format.
Once
converted to plist format, an SVC 202 is
issued (at label INIT1A)
to execute the
function.
This cycle is repeated until all
stacked commands are executed.
DMSCPF
---ii-the command could not be executed by the
SVC handler, passes the command to CP to see
if CP can execute it.
DMSFNS
---on-return from processing the command line
(label UPDAT) , closes any files that may have
been opened during processing.
Q~'§'§~]
Resets any flags or fields that may have been
set during OS processing.
DMSFNS
---When command
execution completes,
calls
DMSFNS (at label UPDAT) to close any files
that may have remained
open during the
command processing.
Q~'§!~!!
DMSVSR
---Ensures
that any
fields
set by
VSAM
processing are reset for CMS.
Also ensures
that the VSAM discontiguous shared segment is
purged.
DMSINT
---When the command line has been successfully
executed, builds a CMS ready message for the
user (label PRNREADY).
Ensures that
any fields
set for
VSAM
processing are reset for CMS.
Also ensures
that the VSAM discontiguous shared segment is
purged.
DMSCWR
---wrItes the ready message to the console •
.!HH!.!!!I
Sets up an appropriate status
CMS SUBSET, CMSjDOS, etc.).
message (CMS,
Q~'§!!l
DMSCWR
---writes the status message to the console.
Returns control to DMSINT at label INLOOP2 to
continue
monitoring
the
CMS
terminal
session.
METHOD OF OPERATION FOR DMSINT
DMSIBT
---irinches (from label INLOCP2) to the waitread
subroutine to read a line entered at the
console.
DMSCRD
---Reads
a line
entered
(subroutine waitread).
164
at
the
console
DMSINT, the console
manager, maintains the
continuity of operation of the CMS command
environment. The main control loop of DMSINT is
initiated by a call to DMSCRD to get the next
command. When the command is entered, DMSINT
calls DMSINM to initialize the CPU time for the
new command and then
puts it in standard
parameter list form by calling the scan function
program DMSSCN.
After calling DMSSCN, DMSINT
checks to see if an EXEC filetype exists with a
filename of the typed-in command.
(For example,
if AEC was typed in, it checks to see if ABC
EXEC exists.)
If the EXEC file does exist,
DMSINT adjusts register
1 to point to the same
IBM VM/370: System Logic and Problem Determination Guide
command as set up by DMSSCN,
but preceded by
CLS'EXEC', and then issues an SVC 202 to call
the corresponding EXEC procedure
('ABC EXEC' in
the example) •
If no such EXEC file exists for the first
word typed in, DMSINT makes a further check
using
the CMS
abbreviation-check
routine,
DMSINA. If, for example, the first word typed
in had been 'E', DMSINT looks up 'E' via the
tMSINA routine.
If an equivalent is found for
'E', DMSINT looks for an EXEC file with the name
of the equivalent word (for example, EDIT EXEC) ;
if such a file is found, DMSINT adjusts register
1
as described
above to
call EXEC
and
substitutes the equivalent word, EDIT, for the
first word typed in. Thus, if 'E' is a valid
abbreviation for 'EDIT' and the user has an EXEC
file called EDIT EXEC, he invokes this when he
merely types in 'E' from the terminal.
If no EXEC file is found either for the
entered command name or for any equivalent found
by DMSINA, DMSINT leaves the terminal command as
processed by DMSSCN and then issues an SVC 202
to pass control to DMSITS which, in turn, passes
control to the appropriate command program.
When the command terminates execution, or if
DMSITS cannot execute it, the return code is
passed in register 15.
A
0
return code
indicates
completion of the command.
METHOD OF OPERATION FOR DMSITS
DMSITS (INTSVC)
is the CMS system SVC handling
routine.
Since CMS is SVC driven, the SVC
interruption processor is more complex than the
other interruption processors.
The general operation of DMSITS is as follows:
1.
The SVC new
PSW
(low-storage location
X'60') contains, in the address field, the
address of DMSITS1.
Thus, the DMSITS
routine is entered whenever a supervisor
call is executed.
2.
DMSITS allocates a system and user save
area, as described below.
The user save
area is a register save area used by the
routine, which is invoked later as a result
of the SVC call.
3.
The called routine is invoked.
4.
Upon return from the called routine,
save areas are deallocated.
5.
Control
routine
call).
the
is returned to the caller (the
which originally
made the SVC
successful
A positive return code indicates that the
command was completed, but with an apparent
error; and a negative code returned by DMSITS
indicates that the typed in command could not be
found or executed at all.
In the last case, DMSINT assumes that the
command is a CP command and issues a DIAGNOSE
instruction to pass the command line to the CP
environment.
If the command
is not a CP
command, DMSINT calls DMSCWR to type a message
indicating that the command is unknown and the
main control loop of DMSINT is entered at the
heginning.
If the return code from DMSITS is positive or
zero, DMSINT saves the return code briefly and
calls module DMSAUD to update the Master File
Directory (MFD) on the user's appropriate user's
disk. DMSINT also frees the TXTLIB chain and
releases pages of storage if required.
After updating the master file directory,
DMSINT checks the return code that was passed
tack.
If the code is zero, DMSINT types a ready
message and the CPU time used by the given
command.
Control is passed to the beginning of
the main control loop of DMSINT.
If the return
code is positive, an error message is typed,
along with the CPU time used.
The command
caused the typing of an error message of the
format: DMSxxxnnnt 'text' where DMSxxx is the
module name,
nnn is the message identification
number, t is the message type, and 'text' is the
message explaining the error.
Control is then
passed to the beginning of the main control
loop.
The following expands upon various features
of the general operation that has just been
described.
The types of SVC calls recognized by DMSITS, and
the linkage conventions for each are as follows:
E!f
~~1:
When a called routine returns control
to DMSITS, the user storage key may be in the
PSi. Because the called routine may also have
turned on the problem bit in the PSW, the most
convenient way for DMSITS to restore the system
PSi is to cause another interruption,
rather
than to
attempt the
privileged Load
PSW
instruction.
DMSITS does this by issuing SVC
201, which causes a recursive entry into DMSITS.
DMSITS determines if the interruption was caused
by SVC 201, and if so, determines if the SVC 201
was from within DMSITS.
If both conditions are
met,
control
returns to
the
instruction
following the SVC 201 with a PSi that has the
problem bit off and the system key restored.
~!f ~~~:
SVC 202 is the most commonly used SVC
in the CMS system.
It is used for calling
nucleus resident
routines and
for calling
routines written as commands.
A typical coding sequence for an SVC 202 call
is the following:
LA
SVC
DC
R1 ,PLIST
202
AL4 (ERRADD)
section 2. Method of Operation and Program organization
165
Whenever SVC 202 is called, register 1 must
point to a parameter list (PLIST).
The format
of this parameter list depends upon the actual
routins or command being called, but the SVC
handler examines the first 8 bytes of the list
to find the name of the routine or command being
called. It searches for the routine or module
as described for SVC 201.
~~~~-H!!Q1~Q ~!~§:
The DC AL4{address) following the SVC 202 is
optional, and may be omitted if the programmer
does not expect any errors to occur in the
routine or command being called. DMSITS can
determine whether this DC
was inserted by
examining the byte following the SVC call. If
it is nonzero, then it is an instruction; if it
is zero, then it is a "DC AL4(address)".
There is no way to specify a normal or error
return from a user-handled SVC routine.
SVC 203: SVC 203 is used by CMS macros to
perfor;-various internal system functions. SVC
203 is an SVC call for which no parameter list
is provided.
An examFle is DMSFREE, for which
the parameters are passed in registers 0 and 1.
A typical
follows:
SVC
DC
sequence
for an
SVC
203
call
203
H'code'
The halfword decimal code following the SVC
203
indicates the
specific routine
being
called. DMSITS examines this halfword code as
follows: (1) the absolute value of the code is
taken, using an LPR instruction, (2) the first
byte of the result is ignored, and the second
byte of the resulting halfword is an index into
a branch table,
(3) the address of the correct
routine is loaded, and control is transferred
there, as the called routine.
It is possible for the address in the SVC 203
index table to be zero. In this case, the index
entry contains an 8-byte routine or command
name, which is processed in the same way as the
8-byte name passed in the parameter list passed
to SVC 202.
The sign of the halfword code indicates
whether the programmer expects an error return;
if so, the code is negative: if not, the code is
positive. Note that the sign of the half word
code has no effect on determining the routine
which is to be called, because DMSITS takes the
absolute value of the code to determine the
called routine.
Because only the second byte of the absolute
value of the code is examined by DMSITS, seven
bits (bits 1-7) are available as flags or for
other uses. For example, DftSFREE uses these
seven
bits
to indicate
such
things
as
conditional requests and
variable requests.
Therefore, DMSITS considers the codes H'3' and
B'259' to be identical, and handles them the
same as B'-3'
and B'-259', except for
error
returns.
When an SVC 203 is invoked, DMSITS stores the
halfword code into the NUCOI location CODE203,
so that the called routine can interrogate the
seven bits made available to it.
The programmer may use the
BNDSVC macro to specify the address of a routine
that processes any SVC call for SVC numbers 0
through 200 and 206 through 255.
If the BNDSVC macro is used, the linkage
conventions are
as required
by the
user
specified SVC-handling routine.
g~
~Af]9
SIMULATION SVC £!11~: CftS supports
certain of the-SVc-calIs-generated by OS macros,
by simulating the effect of these macro calls.
The proper linkages are set up by the OS
macro generations. DftSITS does not recognize
any way to specify a normal or error return froa
an OS macro simulation SVC call.
~Q~ ~!£
CALLS: All SVC functions supported for
CftS/DOS are--handled hy the CftS module DMSDOS.
DftSDOS receives control from DMSITS (the CMS SVC
handler) when that routine intercepts a DOS SVC
code and finds that the DOSSVC flag in DOSFLAGS
is set in NUCON.
DMSDOS acquires the specified SVC code from
the OLDPSW field of the current SVC save area.
Using this code, DftSDOS computes the address of
the routine where the SVC is to be handled.
Many CftS/DOS routines
(including DftSDOS) are
contained in a discontiguous shared segment
(DCSS).
Most SVC codes are executed within
DMSDOS, but
some are in
separate modules
external to DftSDOS. If the SVC code requested
is external to DMSDOS, its address is computed
using a table called DCSSTAB; if the code
requested is executed within DMSDOS, the table
SVCTAB is used to compute the address of the
code to handle the SVC.
DOS SVC calls are discussed in more detail in
"Simulating a DOS Environment Under CftS" in this
section.
INVALID ~!~
Invalid sVc
are:
~!11~:
There are several types of
calls recognized by DftSITS. These
•
Invalid SVC number. If the SYC number does
not fit into any of the classes described
above, it is not handled by DftSITS. An error
message is displayed at the terminal, and
control is returned directly to the caller.
•
Invalid routine name in SVC 202 parameter
list. If the routine named in the svc 202
parameter list is invalid or cannot be found,
then DftSITS handles the situation in the same
way it handles an
error return from a
legitimate SVC routine. The error code is
-3.
•
Invalid SVC 203 code. If an illegal code
follows SVC
203, an
error message
is
displayed, and the ABEND routine is called to
terminate execution.
When a program issues SVC 202, and passes a
routine or command name in the parameter list,
166
IBM VM/370: system Logic and Problem Determination Guide
DMSITS must search for the specified routine or
command.
(In the case of SVC 203 with a zero in
the table entry for the specified index, the
same logic must be applied.)
macro simulation SVC handling routine,
it calls
LOADMOD to load the file DMSSVT module into the
transient area, and lets that routine handle the
SVC.
The search order is as follows:
A program in the transient program area may
not invoke another progra. intended to execute
in the transient program area, including os
macro simulation SVC calls that are handled by
DMSSVT. Thus, for example, a program
in the
transient program area may not invoke the RENAME
command. In addition, it may not invoke the OS
.acro iTO, which generates an SVC 35, which is
handled by DMSSVT.
1.
A check is made to see if there is a
routine with the specified name currently
in the system transient area.
If so, then
control is transferred there.
2.
The system function name table is searched
to see if a co.mand by this name is nucleus
resident.
If successful, control goes to
the specified nucleus routine.
3.
A search is made for a disk file with the
specified name as the filename, and module
as the filetype.
The search is made in the
standard disk search order. If this search
is successful, then the specified module is
loaded by LOADMOD and control passes to the
storage location
now occupied
by the
command.
4.
If all searches so far have failed, then
DMSINA
(ABBREV) is called to see if the
specified routine name is a valid system
abbreviation for
a system
command or
function.
User-defined abbreviations and
synonyms are checked at the same time.
If
this search is successful, then steps 2
through 4 are repeated
with the full
nonabbreviated name.
5.
If all searches fail, then an error code of
-3 is forced.
There is one further functional difference
between the use of the two program areas.
DMSITS starts a program in the user program
area
so
that
it
is
enabled
for
all
interruptions.
It starts a program in the
transient program area so that it is disabled
for all interruptions. Thus, the individual
program may have to use the SSM (Set Syste.
Mask) instruction to change the current status
of its system mask.
Figures 42 and 43 show how the PSi and registers
are set up when the called routine is entered.
r--------------------------- ----,
I
1 Called Type
I System
1 Mask
1 Storage 1 Problem 1
1 Key
1
Bit
I
---I
ISVC 202 or 203 I Disabled
System
Off
I
I - Nuc residentl
1
1
1
1-----------_·_-
I------------u--------------,-----I
There are two areas which can hold program
modules which are loaded by LOADMOD from the
disk. These are called the user program area
and the transient program area.
The user program area starts at location
Xl 20000 1 and extends upward
to the loader
tables. However, the high-address end of that
area can be allocated
as free storage by
tMSFREE.
Generally, all
user programs and
certain system commands, such as EDIT
and
COPYFILE, execute in the user program area.
Because only one program can be executing in the
user program area at one time, unless it is an
overlay structure, it is impossible for one
program in the user program area to invoke, by
means of SVC 202, a module which is also
intended to execute the user program area.
The transient program area is two pages,
running from
location XIEOOOI
to location
X1100001.
It provides an
area for system
commands that may also be invoked from the user
program area by means of an SVC 202 call. For
example, a program in the user program area may
invoke the RENAME command,
because this command
is loaded into the transient program area.
The transient program
area also handles
certain OS macro simulation SVC calls.
If
tMSITS cannot find the address of a supported OS
ISVC 202 or 203 1 Disabled I User
1 - Transient
1
1
1
1 area MODULE I
I
,
,
Off
I
1
,
---I
I------------~-
,SVC 202 or 203 1 Enabled
User
Off
1
1 - User Area
I
I
I
1
1------------------------1
I User-handled
I Enabled I User
1
Off
1
1--------------lOS - Nuc res
1
,Disabled
System
Off
lOS - in DMSSVT 1 Disabled
System
Off
1
1
I
1
L---
Figure 42.
PSi Fields
Started
when Called
Routine is
When the called routine is finished processing
it returns control to DMSITS, which then must
return control to the caller.
RETURN LOCATION: The return is effected by
loading -the-original svc old PSW (which was
saved at the time DMSITS was first entered),
after possibly modifying the address field.
How
the address field is modified depends upon the
type of SVC call, and on whether the called
routine indicated an error return address.
section 2. Method of Operation and Program Organization
167
r----------------------------------------------------------
1
Type
1 0 - 1
1 2 - 11
1
12
1
13
1
14
1
1---------1----1------1-----1------1-----1
1 SVC 202 1
Saae
IUnpredict-1 Address 1
User
I Return I
1
or 203 1
as
1 able
1
of
I
save
1 address 1
I
1 caller 1
able
1
called 1
area
1
to
1
1
1
1
1 routine 1
1 DMSITS 1
1--------------------------------1
1
1
1
other
1
I
1
1
Same
as
caller
1
1
1
1
Same
as
caller
1
1
1
1
Address
of
called
routine
1
1
1
1
User
save
area
L---
Figure 43.
Register Contents when Called Routine is Started
For SVC 202 and 203, the called routine
indicates a normal return by means of a zero
returned in register 15, and an error return by
means of a nonzero in register 15.
If the
called routine indicates a normal return, then
DMSITS makes a normal return to the caller. If
the called routine indicates an error return,
then DMSITS returns to the caller's error return
address, if one was specified, and abnormally
terminates if none was specified.
For
SVC
202
not
followed
by
"DC
AL4(address)", a normal return is made to the
instruction following the SVC instruction, and
an error return causes an abnormal termination.
For SVC 202 followed by "DC AL4~ddress)", a
normal return
is made to
the instruction
following the DC, and an error return is made to
the address specified in the DC.
In either
case, register 15 contains the return code
passed by the called routine.
For SVC 203 with a positive halfword code, a
normal return
is made to
the instruction
following the halfword code, and an error return
causes an abnormally terminates.
For SVC 203
with a negative halfword code, both normal and
error returns are made
to the instruction
following the halfword code.
In any case,
register 15 contains the return code passed back
by the called routine.
For OS macro simulation SVC calls, and for
user-handled SVC calls, no error return is
recognized by DKSITS.
As a result,
DMSITS
always returns to the caller by loading the SVC
old PSW that was saved when DMSITS was first
entered.
~~~!~1~~ ~~~1g~j!!g~:
Upon entry to DKSITS, all
registers are saved as they were when the SVC
instruction was first executed. Upon exiting
from DHSITS, all registers are restored to the
values that were saved at entry.
The exception to this is register 15 for SVC
202 and 203.
Upon
return to the caller,
register 15 contains the value that was in
register 15 when the called routine returned to
DHSITS after it had completed processing.
Whenever an SVC call is made,
DKSITS allocates
two save areas for that particular SVC call.
168
Return
address
to
DMSITS
'-------,
15
Address
of
called
routine
Same
as
caller
1
1
1
1
I
1
1
I
1
1
1
--------------1
DMSITS uses the system save area
(DSECT
SSAVE) to save the value of the SVC old PSW at
the time of the SVC call, the caller's registers
at the time of the call, and any other necessary
control information. Since SVC calls can be
nested, there can be several of these save areas
at one time. The system save area is allocated
in protected free storage.
The user save area contains (DSECT EXTUAREA)
12 doublewords
(24 fullwords), allocated in
unprotected free storage. DMSITS does not use
this area at all, but simply passes to the
called routine a pointer
to this area in
register 13.
Thus, the called routine can use
this area as a temporary work area, or as a
register save area. There is one user save area
for each system save area, and the latter
contains a pointer to the former in the USAVEPTR
field.
The CMS leader consists of a nucleus resident
loader
(DMSLDR),
a file and message handler
program
(DMSLIO), a
library search program
(DMSLIE), and other SUbroutine programs. DMSLDR
starts loading at the
user first location
(AUSRAREA) specified in BUCON or at a user
specified location. When performing an INCLUDE
function, loading resumes at the next available
location after the previous LOAD, INCLUDE, or
LOADKOD.
The loader
reads in the
entire user's
program, which consists of one or more control
sections, each defined by a type 0 ESD record
("card").
Each control section contains a type
1 ESD card for each entry point and may contain
other control cards.
Once the user's program is in storage, the
loader begins to search his files for library
subprograms called by the program.
The loader
reads the library subprograms into storage,
relocating and linking them as required.
To
relocate
programs,
the
loader
analyzes
information on the SLC, ICS, ESD, TXT, and REP
cards. To establish linkages, it operates on
ESD, and RLD cards. Information for end-of-load
transfer of control is provided by the END and
LDT cards,
the ENTRY control
card, START
command, or RESET option.
The
leader
also analyzes
the
options
specified on the LOAD and INCLUDE commands. In
response to specified options, the loader can:
IBM VH/370: system Logic and Problem Determination Guide
•
Set the load area to
(CLEAR option).
•
Load the program at
(ORIGIN option).
a
•
Suppress creation of
disk (NOMAP option) •
the
•
Suppress the printing of invalid card images
in the load map (NOINvoption).
•
Suppress the printing of REP card
the load map (NOREP option).
•
LOad program into
TRANS option) •
zeros before
specified
loading
loca tion
load-map file
"transient area"
on
images in
Suppress TXTLIB search (NOLIBE option).
•
suppress text file search (NOAUTO option).
•
Execute the loaded program (START option).
•
Type the load map,
specified.
•
Set the program entry point (RESET option).
TYPE option
En!.!:I
The
routine is
entered
at the
first
instruction when it receives control from the
initial and resume loading routine.
It is
entered at ORG2 whenever a loader routine
requires the current address of a symbolic
location specified on an SLC card.
Q£~~2!!Q!!
This
routine
determines which
of
following situations exists, and takes
indicated action:
the
the
1.
The SLC card does not contain an address
or a symbolic name.
The SLC card
routine branches, via BADCRD in the
reference table search routine, to the
disk and type output routine (DMSLIO),
which generates an error message.
2.
The SLC card contains an address only.
The SLC card routine sets the location
to that address and
counter (LOCCT)
returns to RD, in the initial and resume
loading routine, to read another card.
3.
The SLC card contains a name only, and
there is a reference table entry for
that name.
The SLC card routine sets
LOCCT to the current address of that
name (at ORG2)
and
returns to the
initial and resume loading routine to
get another card.
4.
The SLC card contains a name only, and
there is no reference table entry for
that
name.
The
SLC card
routine
branches via ERRSLC to the Disk and Type
Output routine (DMSLIO), which generates
an error message for that name.
5.
The SLC card contains both an address
and a name.
If there is a REFTBL entry
for the name, the sum of the current
address of the name and the address
specified on the SLC card is. placed in
LQCCTi control returns to the initial
and resume
loading routine
to get
another card. If there is no REFTBL
entry for the name, the SLC card routine
branches via ERRSLC to the Disk and Type
Output routine, which generates an error
message for the name.
was
During its operation, the loader uses a
loader table
(REPTBL),
and external symbol
identification table (ESIDTB), and a location
counter (LOCCNT). The loader table contains the
names of control sections and entry points,
their current location,
and the relocation
factor.
(The
relocation
factor
is
the
difference between the compiler-assigned address
of a control section and the address of the
storage location where it is actually loaded.)
The ESIDTB contains pointers to the entries in
REPTBL for the control section currently being
processed by the loader.
The loader uses the
location counter to determine where the control
section is to be loaded. Initially, the loader
obtains from the nucleus constant area
the
address (LOCCNT)
of the next location at which
to start loading. This value is subsequently
incremented by the length indicated on an ESD
(typeO), END, or ICS card, or it may be reset by
an SLC card.
The loader contains a distinct routine for
each type of input card. These routines perform
calculations using information contained in the
nucleus constant area, the location counter, the
ESIDTB, the loader table, and the input cards.
Other loader routines perform initialization,
read
cards
into
storage,
handle
error
conditions, provide disk and typewritten output,
search libraries, convert hexadecimal characters
to binary,
proce~s end-of-file
conditions, and
begin execution of programs in core.
Following are descriptions
subprocessors with LDR.
the
(ORIGIN
•
if the
card, or to the address assigned (in
REPTBL) to a specified symbolic name.
of the individual
Punction
---ThIs- routine
sets the
location counter
(LOCCT) to the address specified on an SLC
Function
---ThIs-routine establishes a reference table
entry for the control-segment name on the
ICS card if no entry for that name exists,
adjusts the location counter to a fullword
boundary, if necessary,
and adds the
card-specified control-segment length to
the location counter if necessary.
!H!!.!:I
This routine has one entry point, named
C2AE1. The routine is entered fro. the
Section 2. Method of operation and Program organization
169
initial and resume loading routine when it
finds an ICS card.
control section.
To do
this, the
routine links to
the REFTBL search
routine.
The ESD type 0 card routine's
subsequent operation depends on whether
there already is a REFTBL entry for this
control section.
If there is such an
entry,
processing
continues
with
operation 5, below; if there is not, the
REFTBL search routine places the name of
this control section in REFTBL,
and
processing continues with operation 3.
QE~~~!~2~
1.
The routin~ begins its operation with a
test of card type.
If the card being
processed is not an
ICS card, the
routine
branches to
the ESD
card
analysis routine; otherwise, processing
continues in this routine.
2.
The routine tests for a hexadecimal
address on the ICS card. If an address
is present, the routine links to the
DMSLSBA
subroutine to
convert
the
address to binary, otherwise the routine
branches via BADCRD to the disk and type
output routine (DMSLIO).
3.
The routine next links to the REFTBL
search routine, which determines whether
there is a reference table entry for the
card-specified control-segment name.
If
such an entry is found,
the REFTBL
search routine branches to the initial
and resume loading routine;
otherwise,
the REFTBL search routine places the
control-segment name in the reference
table, and processing continues.
4.
The routine
determines whether
the
card-specified control-segment length is
zero or greater than zero.
If the
length is zero, the routine places the
current location counter value in the
reference table entry as the control
segment's starting address (ORG2), and
branches to the
initial and resume
loading routine.
If
the length is
greater than zero, the routine sets the
current location counter value at a
fullword boundary address.
The routine
then
places this
adjusted
current
location counter value in the reference
table
entry,
adjusts
the
location
counter
by
adding
the
specified
control-segment
length to
it,
and
branches to RD in the initial and resume
loading routine to get another card.
Function
---ThIs-routine creates loader table and ESID
table entries for the card-specified control
section.
~~!~~
This routine has one entry point, location
C3AA3.
The routine is entered from the ESD
card analysis routine.
QE~~~!iQ~
1.
If this is the first section definition,
its ESDID is proved.
3.
The routine obtains the
control section length
operation 4.
4.
The routine links to location C2AJl in
the ICS card routine and returns to
C3AD4 to obtain the current storage
address of the control section from the
REFTBL entry,
inserts the REFTBL entry
position
(N where this is the Nth
REFTBL entry) in the card-specified ESID
table location,
and calculates
the
difference
between
the
current
(relocated)
address
of the
control
section
and
its
card-specified
(assembled) address.
This difference is
the relocation factor; it is placed in
the REFTBL
entry for
this control
section.
If previous ESD's have been
waiting for this CSECT, a branch is
taken to
SDDEF, where
the waiting
elements are processed. A flag is set
in the REFTBL entry
to indicate a
section definition.
5.
REFTBL is
found in the
The entry
examined to determine whether it had
been defined by a COMMON.
If so, it is
converted from a COMMON to a CSECT and
performs operation 3.
6.
If the entry had
previously by an ESD
continues at 3.
7.
If the entry had been defined previously
as other than COMMON, DMSLIO is called
via ERRORM to print a warning message,
"DUPLICATE IDENTIFIER". The entry in
the ESID table is set negative so that
the CSECT will be skipped (that is, not
loaded) by the TXT and RLD processing
routines.
170
This routine first determines whether a
loader table (REFTBL)
entry has already
been established for the card-specified
not been defined
type 0, processing
Function
---ThIs-routine establishes a loader table entry
for the entry point specified on the ESD
card, unless such an entry already exists.
~~!~I
This routine is entered from
analysis routine.
QR~~~!iQ~
1.
2.
card-specified
and performs
the ESD
card
Branches and links to REFADR to find
loader table entry for first section
definition of the text deck saved by the
ESD 0 routine.
IBft VM/370: System Logic and Problem Determination Guide
2.
3.
4.
5.
The routine then adds the relocation
factor and the address of the ESD found
in operation 1 or the address in LOCCNT
if an ESD has not yet been encountered.
The sum is the current storage address
of the entry point.
card-specified external name. If none
is found, the REPTBL search routine sets
the undefined flag for the new loader
table entry.
2.
The routine links to the REFTBL search
routine to find whether there is already
a
REFTBL entry for the card-specified
entry point name. If such an entry
exists, the routine performs operation
4.
If there is no entry, the routine
performs operation 5.
Upon finding a REFTBL entry that has
been
previously
defined
for
the
card-specified name, the routine then
compares the REFTBL-specified current
storage
address
with
the
address
computed
in operation
2.
If
the
addresses are different,
the routine
branches and links to the DMSLIO routine
(duplicate symbol
warning);. if
the
addresses are the same, the routine
branches to location RD in the initial
and resume loading
routine to read
another card.
Otherwise,
it is assumed
that the REFTBL entry was created as a
result
of
previously
encountered
external references to the entry.
The
DMSLSBC routine is called to resolve the
previous external references and adjust
the REFTBL entry.
The entry point name
and address are
printed by calling
DMSLIO.
The routine resets a possible WEAK EXTRB
flag.
The routine
next places the
REPTBL entry's position-key in the ESID
table.
If the entry has already been
defined by means of an ESD type 0, 1, 5,
or 6, processing continues at operation
4.
Otherwise, it continues at operation
3.
3.
The relocated
RELPAC entry
REPTBL entry.
address is placed
in the external
in the
name's
4.
The ESD
type 2 card
routine then
determines (at location ESDOO)
whether
there is another entry on the ESD card.
If there is another entry, the routine
branches to location CA3Al in the ESD
card
analysis routine
for
further
processing of this card; otherwise, the
routine branches to location RD in the
initial and resume loading routine.
Exits
---This routine exits to location CA3A1 in the
ESD card analysis routine if there is another
entry on the ESD card being processed, and
exits to location RD in the initial and
resume loading routine if
the ESD card
requires no further processing.
If there is no REPTBL entry for the
card-specified entry point name, the
routine makes such an entry and branches
to the DMSLIO routine.
Function
---ihIs-routine makes loader table
entries for private code CSECT.
and ESIDTAB
Q:E~!~.:U.Q'!!
The ESD Type 4 Card Routine:
Punction
---ThIs-routine creates the proper ESID table
entry for the card-specified external name
and places the name's assigned address (ORG2)
in the reference table relocation factor for
that name.
£!!L!:!:I
This routine has two entry points: location
C3AHl and location ESDOO.
Location C3AHl is
entered from the ESD card analysis routine;
this occurs when an ESD type 2 card is being
processed. Location ESDOO is entered from:
•
The ESD card analysis routine, when the
card being processed is an ESD type 2, and
an absolute loading process is indicated.
•
The ESD type 0 card routine and ESD type 1
card routine, as the last operation in
each of these routines.
.Q.E~!~:!:.!2!!
1.
1.
The routine LDRSYM is called to generate
a unique character string number of the
form 00000001,
which is left in the
external data area NXTSYM; it is greater
in value
than previously
generated
symbol.
2.
The CSECT is then processed as a normal
type 0 ESD with the above assigned
name.
Function
---ihIs- routine creates reference table
ESIDTAB
entries
for
common
pseudo-register ESDs.
and
and
Q:E~!~!.!.Q'!!
The ESD type 5 and 6 card routine:
When this routine is entered at location
C3AH1, it first links to the REPTBL
search routine to
determine whether
there is
a
REFTBL
entry for
the
1. Links to ESIDINC in the ESD type
routine, to update the number of
entries.
0 card
ESIDTB
section 2. Method of Operation and Program Organization
171
2. Links to the REFTBL search routine to
determine
whether a
reference
table
(REFTBL) entry has already been created.
If there is no entry, the RBFTBL search
routine places the name of the item in the
REFTBL.
3.
If the ESIDTB entry was negative, this
is a duplicate to CSECT and processing
branches to RD.
Otherwise, the routine
links to the REFADR routine to obtain
the relocation factor of the current
control segllent.
3. If the REFTBL search routine had to create
an entry for the item, the ESD type 5 and
6 card routine indexes it in the ESIDTB,
enters the length and alignment in the
entry, indicates whether it is a PR or
common, and branches to ESDOO in the ESD
type 2 card routine to determine whether
the card contains additional ESD's to be
processed. If the entry is a PR, the BSD
type 5 and 6 card routine enters its
displacement and length in the REFTBL
before branching to BSDOO.
4.
The routine then adds the relocation
factor
(0, if the loading process is
absolute) and the card-specified storage
address. The result is the address at
which the text must be stored.
This
routine also determines
whether the
address is such that the text, when
loaded
starting
at
that
address,
overlays the loader or the reference
table.
If
a loader overlay
or a
reference table overlay is found, the
routine branches to the LDRIO routine.
If neither condition is detected, the
routine
proceeds
with
address
inspection.
5.
The routine then determines whether an
address has already
been saved for
possible use as the end-of-10ad branch
address.
If an address has been saved,
the routine performs operation 7; if
not, the routine performs operation 6.
6.
The routine determines whether the text
address is below location 128.
If the
address is below location 128, it should
not be saved for use as a possible
end-of-10ad branch address,
and the
routine performs operation 7; otherwise
the routine saves the address and then
performs operation 7.
7.
The routine then stores the text at the
address
specified
(absolute
or
relocated) and branches to location RD
in the
initial and
resume loading
routine to read another card.
4. If the REFTBL already contained an entry,
the ESD type 5 and 6 card routine indexes
it in the BSIDTB, checks alignment and
branches to ESDOO.
Note: The PR alignment is coded and placed into
the-REFTBL.
It is an error to encounter more
restrictive
alignment
PR
than
previously
defined. A blank alignment factor is translated
to full word alignment.
The WEAK EXTRN routine calls the search routine
to find the BXTRB name in the loader table. If
not found, set the WEAK EXTRN flag in the new
loader table entry. Bxit to BSDOO.
Function
---This- routine has two functions:
address
inspection and placing text in storage.
Exits
---The routine
follows:
to
two
locations,
as
1.
The routine exits to location RD in the
initial and resume loading routine if it
is being used to process a TXT card.
2.
The routine exits to location APRIL in
the REP card routine if it is being used
for REP card address inspection.
~!!:t.!:I
This
routine
has three
entry
points:
location C4AA1, which is entered from the ESD
card analysis routine, and locations REPENT
and APR1, which are entered from the REP card
routine for address inspection •
exits
.QEg!:~!i2!!
1.
2.
172
This routine begins its operation with a
test of card type.
If the card being
processed is not a TXT card, the routine
branches to
the RBP
card routine;
otherwise, processing continues in this
routine.
The routine then determines how many
bytes of text are to be placed in
storage, and finds whether the loading
process is absolute or relocating. If
the loading process is absolute, the
routine performs operation 4, below; if
relocating,
the
routine
performs
operation 3.
Function
---ThIs-
routine
storage.
places
text
corrections
in
£!!!:!:!:I
This routine has one entry point, location
C4AA3. The routine is entered froll the TXT
card routine.
.Q£g!:~:!:!2!!
1.
This routine begins its operation with a
test of card type.
If the card being
processed is not a REP card, the routine
branches to
the RLD
card routine;
IBM VM/370: System Logic and Problem Determination Guide
otherwise, processing continues
routine.
2.
3.
4.
5.
6.
7.
in this
The routine then links to the HEIB
conversion routine to convert the REP
card-specified correction address from
hexadecimal to binary.
]~!~~
This routine has two
C5AA1 and PASSTWO.
Q~~~g!!2n
1.
The routine then links to the HEIB
conversion routine again to convert the
REP card-specified ESID from hexadecimal
to binary.
The routine then determines whether the
2-byte correction being processed is the
first such correction on the REP card.
If it is the first correction, the
routine performs operation 5; otherwise,
the routine performs operation 6.
When the routine is processing the first
cOrrection, it links to location REPENT
in the TXT card routine, where the REP
card-specified correction
address is
inspected for loader overlay and for
end-of-load branch address saving; in
addition, if the loading process is
relocating, the relocated address is
calculated and checked for reference
table
overlay.
The
routine
then
performs operation 7.
When the correction being processed is
not the first such correction on the REP
card, the routine branches to location
APR1 in the TIT card routine for address
inspection.
The routine then links to the HEXB
conversion
routine to
convert
the
correction from hexadecimal to binary,
places the correction in storage at the
absolute
(card-specified) or relocated
address, and determines whether there is
another correction entry on the REP
card. If there is another entry, the
routine repeats its
processing from
operation 4,
above; otherwise,
the
routine branches to location RD in the
initial and resume loading routine.
Location C5AA1 writes each RLD card into
a work file (DMSLDR CMSUT1). Exit to RD
to process the next card.
Location PASSTWO reads an RLD card from
the work file.
At EOF got to C6AB6 to
finish this file.
2.
The routine uses the relocation header
(RH ESID) on the card to obtain the
current address (absolute or relocated)
of the symbol referred to by the RLD
card.
This address is found in the
relocation factor section of the proper
reference table entry. If the RB ESID
is 0, the routine branches to the LDRIO
routine (invalid ESD).
3.
The routine uses the position header (PH
ESID)
on
the card
to obtain
the
relocation factor of the control segment
in which the DEFINE CONSTANT assembler
instruction occurred. If the PH ESID is
0, the routine branches to BADCRD in the
REFTBL search routine (invalid ESID).
If
the ESIDTAB
entry is
negative
(duplicate CSECT), the RLD entry is
skipped.
4. The
routine
next
decrements
the
card-specified byte count by 4 and tests
it for O. If the count is now 0, the
routine branches to location RD in the
initial and resume
loading routine;
otherwise, processing continues in this
routine.
5.
The routine determines the length, in
bytes, of the address constant referred
to in the RLD card.
This length is
specified on the RLD card.
6.
The routine then adds the relocation
factor
obtained
in
operation
3
(relocation
factor of
the
control
segment in which the current address of
the symbol must be stored), and the
card-specified address. The sum is the
current address of the location at which
the symbol address must be stored.
7.
The routine then computes the arithmetic
value (symbol address
or expression
value) that must be placed in storage at
the address calculated in operation 6,
above, and places that value at the
indicated address.
If the value is
undefined, the
routine branches
to
location DMSLSBB, where the constant is
added to a string of constants that are
to be defined later.
8.
The routine again decrements the byte
count of information on the RLD card and
tests the result for zero.
If the
result is zero, go to operation 2;
otherwise, processing continues in this
routine.
Exits
---when all the REP-card corrections have been
processed, this routine exits to location RD
in the initial and resume loading routine.
Function
---ThIs-routine processes RLD cards, which are
produced by the assembler when it encounters
address constants within the program being
assembled. This routine places the current
storage address (absolute or relocated) of a
given defined symbol or expression into the
storage location indicated by the assembler.
The routine must calculate the proper value
of the defined symbol or expression and the
proper address at which to store that value.
entry points, locations
section 2. Method of Operation and Program Organization
173
9.
The routine next checks the continuation
flag, a part of the data placed on the
RLD card by the assembler.
If the flag
is
on,
the
routine
repeats
its
processing for a new address only; the
processing is repeated from operation ~.
If the flag is off, the routine repeats
its processing for a new symbol; the
processing is repeated from operation
2.
Exits
---This routine exits to location RD in
initial and resume loading routine.
Exits
---This routine exits to the location specified
in a general register. This may be either of
two locations:
1.
Location RD in the initial and resume
loading routine.
This exit occurs when
the END card routine is processing an
END card.
2.
The location in the LDT card routine
that is specified by that routine's
linkage to the END card routine.
This
exit occurs when the LDT card routine
entered this routine to clear the ESID
table and set the absolute load flag
on.
the
Function
---ThIs-routine saves the END card address under
certain circumstances, and initializes the
loader to load another control segment.
~B!fl
This routine has one entry point, location
C6AA1.
The routine is entered from the RLD
card routine.
Function
---ThIs-routine handles the
control cards.
ENTRY and
LIBRARY
~B!fl
This routine has one entry point,
location
CTLCRD1. The routine is entered from the tDT
card routine.
1.
This routine begins
test of card type.
processed is not
routine
branches
routine; otherwise,
in this routine.
its operation with a
If the card being
an
END card, the
to
the LDT
card
processing continues
2.
The routine then determines whether the
END card contains an address.
If the
card contains no address, the routine
performs operation 7,
below; otherwise,
the routine performs operation 3.
3.
The
routine
next
checks
the
end-address-saved
switch.
If
this
switch is on, an address has already
been saved,
and the routine performs
operation 7. If the switch is off, the
routine performs operation 4.
4.
The routine determines whether loading
is absolute
or relocated.
If the
loading process is absolute, the routine
performs operation 6;
otherwise, the
routine performs operation 5.
5.
The routine links to the REFADR routine
to obtain the current relocation factor,
and
adds
this
factor
to
the
card-specified address.
QE~f~!i2B§
1.
The CMS function SCAN is called to parse
the card.
2.
If the card is not an ENTRY or LIBRARY
card, the routine determines whether the
NOINV option
(no printing of invalid
card image~ was specified.
If printing
is suppressed,
control passes to RD in
the initial and resume loading routine,
where another card is read.
If printing
is not suppressed, control passes to the
disk and type output routine (DMSLIO),
where the invalid card image is printed
in the load map.
If the card is a valid
control card, processing continues.
ENTRY Card
6.
The routine stores the address (absolute
or relocated) in area BRAD, for possible
use at the
end-of-load transfer of
control to the problem program.
7.
Goes
to location
PASSTWO
routine) to process RLD cards.
8.
The routine then clears the ESID table,
sets the absolute load flag on, and
branches to the location specified in a
general register (see "Exits").
(in
----3.--1£
the ENTRY name is already defined in
REFTBL, its REFTBL address is placed in
ENTADR.
Otherwise, a new entry is made
in REFTBL,
indicating an
undefined
external reference (to be resolved by
later input or library search), and this
REFTBL entry's address is placed in
ENTADR.
4.
LIBRARY Card
----5:- Only
nonobligatory
reference LIBRARY
cards are
handled; any
others are
considered invalid.
RLD
6.
174
The control card is printed by calling
DMSLIO via CTLCRD; it then exits to RD.
Each entry-point naRe is individually
isolated a~ is searched for in the
HEFTBL.
If it bas already been loaded
and defined, nothing is done and the
next entry-point name
is processed.
IBM VM/370: System Logic and Problem Deteraination Guide
otherwise, the nonobligatory bit is set
in the flag byte of the RElTBL entry.
7.
QE~~~~!2n
1.
This routine begins its operation by
obtaining
the
number
of
entries
currently in the reference table (this
number is contained in area TBLCT), the
size of a reference table entry
(16
bytes), and the starting address of the
reference table
(always
the highest
address in storage, contained in area
TBLREl) •
2.
The routine then checks the number of
entries in the reference table.
If the
number is
0, the
routine performs
operation 5; otherwise,
the routine
performs operation 3.
3.
The routine next determines the address
of the first (or next)
reference table
entry
to
have its
name
checked,
increments by one the
count it is
keeping
of
name
comparisons,
and
compares the given name with the name
contained in that entry.
If the names
are identical, PRSERCH branches to the
location specified in the routine that
linked to it.
PRSERCH then returns the
address of
the REFTBL
entry;
else
PRSERCH performs operation 4.
4.
The routine then
determines whether
there is another reference table entry
to be checked.
If there is none, the
routine performs operation 5; if there
is another, the routine decrements by
one the number of entries remaining and
repeats its operation
starting with
operation 3.
5.
If all the entries have been checked,
and none contains the given name for
which this routine is searching, the
routine increments by one the count it
is keeping of name comparisons, places
that new value in area TBLCT, moves the
given name to form a new reference table
entry,
and
returns to
the calling
program.
Processing continues at operation 4.
Function
---ThIs-routine computes the storage address of
a given entry in the reference table.
jn~~I
This routine has one entry point,
location
RElADR.
The routine is entered for several
of the routines within the loader.
QE~!~!!2~
1.
Checks to see if requested ESDID is
zero.
If so, uses LOCCNT as requested
location;
branches
to
the
return
location + 44;
otherwise continues this
routine.
2.
The routine first obtains,
from the
indicated ESID table entry, the position
(n)
of the given
entry within the
reference table
(where the given entry
is the nth REFTBL entry).
3.
4.
5.
The routine then multiplies n by 16 (the
number of bytes in each RElTBL entry)
and subtracts this
result from the
starting address of the reference table.
The starting address of the reference
table is held in area TBLREF;
this
address is
the highest
address in
storage, and the reference table is
always
built
downward
from
that
address.
The
result of
the subtraction
in
operation 2, above,
is the storage
address of the given refer~nce table
entry.
If there is n~ ESD for the
entry, goes to operation 5; otherwise,
this routine returns to the location
specified by the calling routine.
Adds an element to the chain of waiting
elements. The element contains the BSD
data item information to be resolved
when
the
requested
ESDID
is
encountered.
Function
---ThIs- routine compares each reference table
entry name with the given name determining
(1) whether there
is an entry for that name
and
(2) what the storage address of that
entry is.
jn~~I
This routine is initially entered at PRSERCH,
and subsequently at location SERCH.
The
routine is entered from several routines
within the loader.
Exits
---This
routine exits
to
either of
two
locations, both of which are specified by the
routine that linked to this routine.
The
first location is that specified in the event
that an entry fer the given name is found;
the second location is that specified in the
event that such as entry is not found.
ESD Card Codes (col. 25 ••• )
Code
-0001
02
04
05
06
OA
~~~n!ng
SD
LD
ER
PC
CM
XD
WI
(CSECT or START)
(ENTRY)
(EITRN)
(Private code)
(COMMON)
(Pseudo-registe~
(WEAK EXTERN)
Section 2. Method of Operation and Program Organization
175
The ESD
ID table
(ESltTE)
is constructed
separately for each text deck processed by the
loader.
The ESIDTB produces a correspondence
between ESD ID numbers (used on RLD cards) and
entries in the loader reference table (REFTBL)
as specified by the ESD cards. Thus, the ESIDTB
is constructed while processing the ESD cards.
It is then used to process the TXT and RLD cards
in the text deck.
The ESIDTB is treated as an array and is
accessed by using the ID number as an index.
Each ESIDTB entry is 16 bits long.
Bits
0---
~ggni!lg
1, this entry corresponds to a CSECT
that has been previously defined.
All
TXT cards and RLD cards referring to
this CSECT in this text deck should be
ignored.
~f
If 1, this entry
definition (SD).
corresponds to a CSECT
2
waiting ESD items exist for this ESDID.
3
Unused.
4-15
REFTEL
etc. )
entry
number
(e.g.
1,
2,
3,
Bit 1 is very crucial because it is necessary
to use the VALUE field of the REFTBL if the ID
corresponds to an ER, CM, or PR; but, the INFO
field of the REFTEL entry must be used in the ID
corresponds to an SD.
REFTBL Entry
r--------------·----------------------,
10 (0)
I
1- - - - - - - - NAME
- - - - - - - - - I
I
I
1--------------_·_---------------------1
18(8)
19(9)
I
FLAG1
I
INFO
I
I
1--------1----------------------1
I 12 (C)
I 13 (D)
I
NOTE 1
I
VALUE
I
I
1---------1----·------------------------1
I 16 ( 10)
I 17 ( 11)
I
FLAG2 _
I
AtDRESS
I
IL _________
7F
07
XDBL
80
81
82
83
90
05
04
02
05
06
XUNDEF
XCXD
XCOMSET
WEAKEXT
CTLLIB
INFO Field:
Iteii.-----
doubleword
PR
alignment
Undefined symbol
Resol ve CXD
Define common area
Weak external reference
TXTLIBs not to be used
to resolve names
depends upon
the type
ESD Item
INFO Field
!.I.E~
~~!!!li!lg
SD
LD
CM
PR
(CSECT or START)
(ENTRY)
(COMMON)
(Psuedo Register)
VALUE Field: depends upon the
as-dces the INFO field.
ESD Item
SD
LD
CM
PR
(CSECT or START)
(ENTRY)
(COMMON)
(Psuedo register)
ESD
Relocation factor
ze:to
maximum length
item:
l.I.E~
of the
type of
the ESD
VALUE Field
l1g!!!ling
Absolue address
Absolue address
Absolue address
Assigned value
(starting from 0)
FLAG2 Eyte
lli! l1gg!li!lg
o Unused
1 Unused
2
3
Unused
Unused
Bit
-4'5
6
7
~~gni!l_g
Unused
Name was located in a
TXTLIB
section definition entry
Name specifically loaded
from command line.
Entries m~y be created in the loader reference
table pr10r to the actual defining of the
symbol.
For example, an entry is created for a
symbol if it is referenced by means of an EXTRN
(ER) even if the symbol has not yet been defined
or its type known.
Furthermore, common (CM) is
not assigned absolute addresses until prior to
the start of execution by the START command.
These circumstances are determined by the
setting of the flag byte;
if the symbol's value
has not yet been defined~ the value field
specifies the address of a patch control block
(PCB) •
-----------------------------~
A REFTEL entry is 20 bytes.
following uses:
NAME Field: contains the
ESO-data-Item.
The fields have the
symbolic name from the
These are allocated from
free storage and
pointed at from REFTBL entries or other PCBs.
~~2..!!i.!!g
Address of next PCB
Loader
Code
--:rE7D
7E
176
ESD
Code
00-0-1
03
5-7
Location of ADCON in storage
4
Flag byte
Routine
19!1~!
XBYTE
XHALF
XFULL
n~g.!!i!lg
PR - byte alignment
PR - halfword alignment
PR - fullword alignment
All address constant locations in loaded program
for undefined symbols are placed on PCB chains.
IBM VM/370: System Logic and Problem Determination Guide
All restrictions which apply to object files for
the OS linkage editor apply to CMS loader input
files.
(FST), chain links, and file records.
Figure 44
shows how these types of data blocks relate to
each other; the following text and figures
describe these relationships and the individual
data blocks in more detail.
FILE STATUS TABLES
PROCESS COMMANDS THAT MANIPULATE THE FILE SYSTEM
Figure 40 lists the CMS modules that perform
either general file system support functions or
that perform data manipulation.
MANAGE THE CMS FILE SYSTEM
A description of the structure of the CMS file
system and the flow of routines that access and
update the file system follows.
HOW CMS FILES ARE ORGANIZED IN STORAGE
CMS files are
types of data
Master
File Directory
organized in storage by
blocks:
the file status
File Status
Table Block (FSTB)
three
table
CMS files consist of 800-byte records whose
attributes are described in the file status
table (FST).
The file status table is defined
by DSECT FSTSECT.
The FST consists of such
information as the
filename, filetype, and
filemode of the file, the date on which the file
was last written, and whether the file is in
fixed-length or variable format.
Also, the FST
contains a pointer to the first chain link. The
first chain link is a block that contains
addresses of the data blocks that contain the
actual data for the file.
The FSTs are grouped into 800-byte blocks
called FST Blocks (these are sometimes referred
to in listings as hyperblocks). Each FST block
contains 20 FST entries,
each describing the
attributes of a separate file.
Figure 45 shows
the structure of an FST block and the fields
defined in the FST.
File Status
Table Entry
First Chain
Link (FCL)
Nth Chain
Link (NCL)
Addr
Address of
FSTB
Address of
an 800-byte
CMS Record
~______~______~________~~:~:~__R_e_co_rd_n~1
~----800-byte CMS
Figure 44. How CMS File Records
a~e
Record Containing File Data I t e m s - - - -.......~I
Chained Together
Section 2. Method of Operation and Program Organization
111
File Status
Table Block
Fields in a File
Status Table Entry
FST 1
FILE
--.-.--.-------------------------,---1
FST 2
NAME
FILE
TYPE
FST 4
DATE LAST WRITTEN
Write Pointer
(Number of Item)
FST 5
Filemode
FST 6
Disk Address
of 1st Chain Link
22
Read Pointer
(Number of Item)
26
Number of
Items in File
30 Fixed
Variable
31
Flag
Byte
Item Length (F)
Max. Item Length (V)
Number of
BOO-Byte Data Blocks
Figure 45.
Year
Format of a File Status Block; Format of a File Status Table
CHAIN LINKS
Chain links are 200- or aOO-byte blocks of
storage that chain the records of a file in
storage. There are two types of chain links:
first chain links and Nth chain links.
The first chain link points to two kinds of
data. The first ao bytes of the first chain
link contain the halfword addresses of the
remaining 40 chain links used to chain the
records of the file.
The next 120 bytes of the
file are the half word addresses of the first 60
records of the file.
The Nth chain links contain only halfword
addresses of the records that contained in the
file.
Because there are 41 chain links
(of which
the first
contains addresses for
only 60
records), the maximum size for any C"S file is
16,060 aOO-byte records.
Regardless of their format, the items of a
file are stored by C"S in sequential order in as
many aOO-byte
records as are
required to
accommodate them. Each record (except the last)
is completely filled and items that begin in one
record can end on the next record.
Figure 47
shows the arrangement of records in files for
files containing fixed-length records and files
containing variable-length records.
The location of any item in a file containing
fixed-length records
is determined
by the
formula:
(Item Number -
1) x Record Length
locations=
-------------800-----------------
where the quotient is the number of the item and
the remainder is the displacement of the item
into the file.
C"S RECORD FORMATS
CMS records are aOO-byte blocks containing the
data that comprises the file. For example, the
CMS record may contain several card images or
print images,
each of which is referred to a
record item. Figure 46 shows how chain links are
chained together.
C"S records can be stored on disk in either
fixed-length or variable-length format. However,
the two formats may not be mixed in a single
file.
178
For variable-length records, each record is
preceded by a 2-byte field specifying the length
of the record.
C"S
virtual disks
(also
referred to
as
minidisks)
are blocks of
data designed to
externally parallel the function of real disks.
several virtual disks may reside on one real
disk.
IBM VM/370: System Logic and Problem Determination Guide
Disk Aridre" of
2nd Chain Link
DISk Address of
Disk Address ot
f\ • Oth Data Block
3rd Chain Link
Disk Andress of
f\. lst Data Block
Cham
Linkago
Directory
•
•
•
Disk Address of
40th Chain link
Disk Address of
•
41S1Chaon Link
Disk Address of
1Sf Data Block
Disk Address of
2nd Data Block
.... .....
A ...
E
Disk Addre .. of
f\. 39B th Data Block
DISk Address of
1\. 399th Data Block
Disk Aridress of
59th Data Block
- - _ l
(n-2)
-
400'" 61
where n "" Cham LInk. Number
DISk Address of
60th Data Block
Figure 46. For_at of the First Chain Link and Nth Chain Links
Data block structure for file consisting of fixed-length records
Data brock structure for file consisting of variable-length records
1~-------~~~ec~~-------- J
800 ~----,
1st record
800
800
~-----I----
_________ - --2nd record
-~~--------
~--------------
L2J
-------[9-------L3
[9
- - -
,
3rd record
--------
-
800
2nd record
-------
L4
3rd record
8 0 0 1 - - - - - - - - - - - - - - - - , . . - - - - - 1 800
800
800
4th record
4th record
-~~--------------------~
5th record
8j~===-~--------------Figure
47.
ii
5th record
8
r-------------I
Arrangement of Fixed-Length or Variable- Length Records in Files
A CftS virtual
aachine .ay have up to 10
virtual
disks accessed
during a
terminal
session, depending on user specifications. Some
disks, such as the S-disk, are accessed during
eftS initialization; however, most are accessed
dynamically as they are needed during a terminal
session.
Section 2. ftethod of Operation and Program Organization
179
KEEPING
QQMSK
PHYSICAL ORGANIZATION OF VIRTUAL DISKS
Virtual disks
are physically
organized in
aOO-byte records. Records 1 and 2 of each user
disk are reserved for 1PL. Record 3 contains the
disk label.
Record 4 contains the master file
directory. The remaining records on the disk
contain user file-related information such as
the FSTS, chain links, and the individual file
records discussed above.
THE
~ASTER
FILE DIRECTORY
The master file directory (~FD)
is the major
file management table for a virtual disk. As
mentioned earlier, it resides on cylinder 0,
track 0, record 4 of each virtual disk.
Six
types of information contained in the master
file directory:
•
The disk
addresses of the
FST
describing user files on that disk.
•
A 4-byte "sentinel," which can be either FFFD
or FPFF.
FFFD specifies that extensions of
the Q~SK
(described below)
follow.
FFFF
specifies that no Q~SK extensions follow.
•
Extensions to the QMSK, if any.
•
General information describing
the disk:
The total number
blocks on the user's disk.
ADTNU~
ADTUSED The number of
in use on the disk.
entries
the status of
of
aOO-byte
blocks currently
ADTLEFT Humber of blocks
use (ADTNO~ - ADTUSED) .
remaining for
ADTLAST - Relative byte address of
last record in use on the disk.
the
ADTCYL
Number
user's disk.
the
of
cylinders
on
Unit Type - A l-byte field describing the
type of the disk: oa for a 2314, 09 for a
3330.
A bit mask called the QMSK, which keeps
track of the status of the records on
disk.
The QMSK is described in more
detail below.
Another bit map, called the QQMSK, which
is used only for 2314 disks and performs a
function similar to that of QMSK.
Figure 4a shows the structure of the master
file
directory.
Figure
44
shows
the
relationship of the Master File Directory, which
resides on disk, to data blocks brought into
storage for
file management
purposes, for
example, FSTs and chain links.
lao
TRACK OF
R/W DISK
STORAGE:
QMSK
AND
Because large areas of disk space need not be
contiguous in CMS, but are composed of aOO-byte
blocks
chain-linked
together,
disk
space
management
needs
to
determine
only
the
availability of blocks, not extents. The status
of the blocks on any read/write disk
(which
blocks are available and which are currently in
use) is stored in a table called QMSK. The term
QMSK is derived from the fact that a 2311 disk
drive has four aOO-byte blocks per track. One
block is a "quarter-track", or QTRK, and a
200-byte area is a "quarter-quarter-track", or
QQTRK. The bit mask for 2314, 2319, 3340, or
3330 records is called the QMSK,
although each
aOO-byte block represents less than a quarter of
a track on these devices.
On a 2314 or 2319 disk, the blocks are
actually grouped fifteen aOO-byte blocks per
even/odd pair of tracks.
An even/odd pair of
tracks is called a track group. On a 3330 disk,
the blocks are grouped fourteen aOO-byte blocks
per track. On a 3340 disk, the blocks are
grouped into eight aOO-byte blocks per track.
When the system is not in use, a user's QHSK
resides on the Master File Directory; during a
session it is maintained on disk, but also
resides in main storage.
QMSK is of variable
length, depending on how many cylinders exist on
the disk.
Each bit is associated with a particular
block on the disk. The first bit in QMSK
corresponds to the first block, the second bit
to the second block, and so forth, as shown in
Figure 49.
When a bit in QMSK is set to 1, it indicates
that the corresponding block is in use and not
available for allocation. A O-bit indicates
that the corresponding block is available. The
data blocks are referred to by relative block
numbers throughout disk space management, and
the disk I/O routine, DMSDIO, finally converts
this number to a CCHHR disk address.
A table called QQHSK indicates which 200 byte
segments
(QQTRK) are available for allocation
and which are currently in use. QQMSK contains
100 entries, which are used to indicate the
status of up to 100 QQTRK records. An entry in
QQMSK contains either a disk address, pointing
to a
QQTRK record that is
available for
allocation, or zero.
QQMSK is used only for
2314 files; for 3330, 3340, and 3350, the first
chain link occupies the first 200-byte area of
an aOO-byte block.
The QMSK and QQMSK tables for read-only disks
are not brought into storage, since no space
allocation is done for a disk while it is
read-only.
They remain, as is, on the disk
until the disk is accessed as a read/write
disk.
IBM VM/370: System Logic and Problem Determination Guide
..........- - - - - - - 2 Bytes - - - - - - - - :..
~
Byte 0
/
Disk Address of 1st FST Block
Disk Address of 2nd FST Block (if any)
••
·
Disk Address of Nth FST Block (if any)
Sentinel (Note 1)
Disk Address of 1st OMSK extension (if any)
·••
Disk Address of Nth OMSK extension (if any)
••
·
Not used - Zero filled
~
~ ~
••
•
/~
ADTUSED,ADTLEFT,ADTLAST
Byte 384
~
'/
Not used (zero)
Byte 599
~
Byte 364
Byte 380
Byte 382
Byte 600
ADTCYL
First 215 Bytes of OMSK
~
I
Entire 200-Byte OOMSK Table
L..
/
UNIT-TYPE (Note 4)
TL--_____(f_or_2_3_14_0n_ly_l_ _ _ _ _--IT
Figure q8.
structure of the Master File Directory
1 bit
1 bit
OMSK for 2314 or 2319
0
0
0
0
0
0
1
4
2
3
0
0
0
~ 1
1
1
10
11
12
9
0
0
0
0
g
~
T
~
i
~
0
0
5
~
13
0
l
0
0
6
0
1
14
0
~
0
0
7
~
15
0
i
OMSK for 3330
f--0
0
8
g
t
1 bit
1
0
[IJt
1bit
J
Number of OMSK Extensions
Required ,lif anyl
0
1
2
3
4
5
6
7
8
9
10
Record
o
10
0
1
3330
6
1
30
7
54
31
78
65
79 · 102
103 · 126
127 · 150
161 · 174
176 · 198
199 ·223
224 - 246
3
1V
0
~
L __~
Number of Cylinden on Disk
2314 or 2319
1 . 11
12. 54
55· 96
97· 139
140· 182
183·203
g
~
Block available
Block in use
1
8
2
9
0
H = Head
~
g
1
g
where:
C ~ Cylinder
R-
g g g g g g g
3340
4
5
g g
12
0
J
13
0
J
6
g
14
0
~
7
~
1
0
a
~
2
0
1~
J
,,-
3350
---
-
Figure 49. Disk Storage Allocation Using the QMSK Data Block
section 2. Method of Operation and Program Organization
181
DYNAMIC
FILES
STORAGE
MANAGEMENT: ACTIVE
DISKS
AND
CMS disks and files contained on disk are
physically
mapped
using the
data
blocks
described above: for disks, the QMSK, QQMSK, and
the MFD; for files, the FST, chain links, and
800-byte file records. In storage, all of this
data is accessed by means of two DSECTs whose
addresses are defined in
the DSECT NUCON,
ADTSECT and APTSECT.
DMSLAD: In the case where
specIfied, calls DMSLAD
extension disk exists.
an extension has been
to ensure that the
DMSLAD: Ensures that the specified disk
already accessed as a R/M disk.
is not
Y~~l!~:
In the case where the specified disk is
replacing a currently accessed disk, closes any
open files belonging to the duplicate disk.
DMSACC: verifies the parameters remaining on the
coiiimand line.
DMSALU: Releases any free storage belonging to
the-duplicate disk via a call to DMSFRE.
Also,
clears appropriate entries in the ADT for use by
the new disk.
The ADTSECT DSICT maps information in the active
disk table (ADT). This information includes
data contained in the MFD, FST blocks, the QMSK,
and QQMSK.
The DSECT comprises of ten "slots,"
each representing one CMS virtual disk.
A slot
contains significant information about the disk
such as a pointer to the MFD for the disk, a
pointer to the first PST block and pointers to
the QMSK and QQMSK, if the disk is a R/M disk.
Also contained in ADTSECT is information such as
the number of cylinders on the disk, the number
of records on the disk.
~~~!£~:
(Called as the first instruction by
DMSACF) Reads, from the Master File Directory,
QMSK, and the QQMSK for the specified disk;
also, DMSACM updates the ADT for the specified
disk using information from the MFD.
]~§J£l:
Reads into storage all the
associated with the specified disk.
FST blocks
!1~§J~~:
Handles error processing or processing
required to return control to DMSINT.
INPUT/OUTPUT OPERATIONS
Each open file is represented in storage by an
active file table (AFT).
The AFT
(defined by
the AFTSECT DSECT) contains data found on disk
in FSTs, chain links, and data records. Also
contained in the AFT is such information as the
address of the first chain link for the file,
the current chain link for the file, the address
of
the
current data
block,
the
fileid
information for the file. Figure 39 shows the
relationship between the AFT and other CMS data
blocks.
CMS ROUTINES USED TO ACCESS THE FILE SYSTEM
DMSACC is the control routine used to access a
virtual disk.
In conjunction with DMSACM and
DMSACF, DMSACC builds, in virtual s~orage, the
tables
eMS requires
for process~ng
files
contained on the disk. The list below shows the
logical flow of the main function of DMSACC.
DMSACC: Scans the command
whIch-disk is specified.
line
to
Looks up the address of the ADT
disk specified on the command line.
Q~§1!Q:
determine
for the
CMS input/output operations for disk, tape, and
unit record devices are always synchronous.
Disk and tape I/O is initiated via a privileged
instruction, DIAGNOSE,
whose function
code
requests CP to perform necessary error recovery.
control is not returned
to CMS until the
operation is complete, except for tape rewind or
rewind and unload
operations, which return
control immediately after
the operation is
started. No interruption is ever received as
the result of DIAGNOSE I/O. The CSM is stored
only in the event of an error.
Input/output operations to a card reader,
card punch, or printer are initiated via a
normal START I/O instruction. After starting
the operation, CMS enters the wait state until a
device end interruption is received from the
started device.
Because the I/O is spooled by
CP, CMS
does not
handle any
exceptional
conditions other than not ready, end-of-file, or
forms overflow.
CMS input/output operations to the terminal
may be either
synchronous or asynchronous.
output to the terminal is always asynchronous,
but a
program may wait for
all terminal
input/output operations to complete by calling
the console wait routine.
Input from the
terminal is usually synchronous but a user may
cause CMS to issue a read by pressing the
attention
key.
A
program
may
also
asynchronously stack data to be read by calling
the console attention routine.
~~§!CC:
Determines whether an extension to a
disk has been specified on the command line and
ensures that it is correctly specified.
182
IBM VM/370: system Logic and Problem Determination Guide
UNIT RECORD I/O PROCESSING
DMSIOW: Places
the symbolic
name of
the
Interrupting device in the PLIST and passes
control to the calling routine.
Seven routines handle I/O processing for CMS:
DMSRDC, DMSPUN, and DMSPRT handle the READCARD,
PUNCH, and PRINT commands and pass control to te
actual I/O processors, DftSCIO
(for READCARD and
PUNCH) or DMSPIO (for PRINT).
DftSCIO and DftSPIO
issue the SIO instructions that cause I/O to
take place.
Two other routines, DMSIOW and
DMSITI, handle synchronization processing for
I/O operations. Figure 50 shows the overall
flow of control for I/O operations.
DftSCIO: Checks for SEISE information and handle
I/O-errors, if necessary.
DMSCWR: Displays
console.
a
control
record
DftSSCI:
If
another
control
encountered, formats it via DMSSCI.
R~~£!]:
Displays
at
the
record
is
the new control record
at the
console.
!!~~l!~:
Closes
the
file
when
end- of- file
occurs.
DftSRDR: Issues a
card-reader.
CP CLOSE command to
close the
DMSRDC
DMSPUN
DMSPRT
DMSPUN: Ensures
that a
virtual punch
avaIlable; processes PUNCH command options.
DMSIOW
DMSSTT: Verifies the existence of the
returns its starting address.
DMSITI
is
file and
~~~R~]:
If requested, sets up a header record
and calls DMSCWR to write it to the console.
DMSBRD: Reads a block of data
buffer; continues reading until
filled.
~~~~lQ:
Figure 50. Flow
Processing
of control For Unit
Record I/O
into the read
the buffer is
Initializes areas to punch records.
DMSCIO: Issues the SIO instruction to punch the
contents of the buffer.
DMSCIO: Issues a call to DMSIOi to wait
completion of the punch I/O operation.
The following are more detailed descriptions of
the flow of control for the read, punch, and
print unit record control functions.
for
DMSIOW: Sets the wait bit on for the virtual
punch- device and loads the I/O old PSW from
NUCON. This causes CMS to enter a wait state
until the punch operation completes.
R~~!I!:
Y~~~R£:
Initializes block length and unit record
size.
Y~~£!Q:
Initializes areas to read records.
]~~£lQ:
Issues an SIO command to read a record.
DMSIOi: Sets the wait bit for the virtual card
reader and load the I/O old PSi from NUCON.
This causes CMS to enter a wait state until the
read I/O is complete.
DMSITI: Ensures that this interrupt is for
vIrtual reader. If not, the I/O old PSi
loaded, returning CMS to a wait state.
If
interrupt is for the reader, DMSITI resets
wait bit in the I/O old PSi and loads
causing control to return to DMSIOW.
the
is
the
the
it,
Ensures that this interrupt is for the
punch.
If not, the I/O old PSW is loaded
returning CftS to a wait state. If the interrupt
is for the punch, DMSITI resets the wait bit in
the I/O old PSW and
then loads the PSW,
returning control to DMSIOi.
name of
the
DMSIOW: Places
the symbolic
Interrupting device in the PLIST and passes
control to DMSCIO.
DMSCIO: Checks for SENSE information and handles
I/o-errors, if any.
DMSPUN:
Handles error
returns and
constants for the next punch operation.
DMSFNS: Closes the file and returns
the-command handler, DMSINT.
resets
control to
Section 2. Method of Operation and Program Organization
183
interpreted as ASCII control characters,
the following meanings:
Cl
Skip to channel 10 before print.
C3
Skip to channel 12 before print.
have
]~§E~!:
type of the
Determines the device
printer.
Checks out
the specified fileid.
Checks out the options specified on the PRINT
com.and line.
]~§§f!:
Verifies the existence of the
returns its starting address.
file and
The same characters, when interpreted as
machine control characters, have the following
meanings:
C1
DMSPRT: Determines the record size to be printed
and-sets up an appropriate buffer area via a
call to DMSFRE.
DMSFRE: Obtains
buffe~.
DMSPRT:
storage space to
Determines
whether
the
be used
file
to
be
Q~§~~~:
Reads a record; continues reading until
the buffer is filled.
When the buffer is
filled,
calls
DMSPIO to
issue
the
SIO
instruction to begin the print operation.
Issues the print SIO instruction
then calls DMSIOW to wait until the the
operation completes.
and
I/O
DMSIOW: sets the wait bit for the virtual
prInter device and load the I/O old PSW from
DUCOD. This causes CMS to enter a wait state
until the print operation completes.
Q~§!!!:
Ensures that the interrupt is for the
printer.
If not, the I/O old PSW is reloaded,
returning CMS to a wait state. If the interrupt
is for the printer, DMSITI resets the WAIT bit
in the I/O old PSW and loads that PSW, returning
control to DMSICW.
DMSIOW: places the symbolic name of the device
in-the last word of the PLIST and passes control
to DMSPIO.
]~§R1Q:
Performs channel testing and handles
errors.
TIO
instructions and
sense
SIO
instructions
are
issued during
the
test
processing.
These operations are synchronized
using DMSIOW and DMSITI in the manner described
above.
When the I/O completes successfully,
control returns to DMSPRT.
DMSPRT: Determines whether all file recorJs have
been printed. If so, control returns to the
caller. Otherwise, the address of the buffer is
updated
and
more
print
operations
are
performed.
CMS supports the use of ASCII control characters
and machine carriage control characters for the
printed output. Part of the CMS implementation
depends upon the fact that the set of ASCII
control characters has almost nothing in common
with the set of machine control characters.
There are two exceptions to this, the characters
X'C1' and X'C3'.
These two characters, when
184
then
skip to
channel
8
after
print.
C3
Do not write,
immediately.
but
skip
to channel
8
as a
p~Inted is a library member or an input file.
Q~§E!~:
= Write,
In printing lines containing carriage control
characters, CMS has the capability of operating
in two modes.
In the first mode,
which may be
called ASCII control
characters or machine
control characters of either type are recognized
and properly interpreted, except that the two
conflicting characters are always interpreted as
ASCII control characters. In the second mode,
which may be called machine-only, only machine
control characters are recognized, and the two
conflicting characters are treated as machine.
The DMSPIO function uses a bit in the plist
to indicate which of the two modes is in effect
for printing.
The PRINTL macro always uses ASA control
character or machine control character mode.
The PRINT command with the CC option always
runs in ASCII control character or machine
control character mode.
OS simulation output, which is used, for
example, by the MOVEFILE command, uses the RECFM
field in the DCB or in the FILEDEF command to
determine which mode is to be used. If FA, VA,
or UA is specified, then ASCII control character
or machine control character mode is used.
If
FM, VM, or UM is specified, then machine-only
mode
is used.
If
no control
character
specification is included with the RECFM, then
it is assumed that the output line begins with a
valid data character, rather than with a control
character, and single spacing is always used.
Figure 40 lists the CMS modules that process
interruptions
for
CMS.
CMS
modules
are
described briefly in "CMS Module Description."
SVC 9 interruption processing is described in
"Maintaining
an
Interactive
Console
Environment."
DISK I/O IN CMS
Files residing on disk are read and written
using DMSDIO.
nMSDIO has two entry points:
DMSDIOR, which is entered
for a read I/O
operation, and DMSDIOW, which is entered for a
write operation.
IBM VM/370: System Logic and Problem Determination Guide
is, this
segment must consist
only of
reentrant code, and may not be modified under
any circumstances.
This fact implies certain
system restrictions
for functions
which
require that storage be modified, such as the
fact that DEBUG breakpoints or CP ADS TOP
commands cannot be placed in this segment, in
a saved system •
The actual disk I/O operation is performed
using the DIAGNOSE code 18 instruction.
A
return code of a from CP indicates a successful
completion of the I/O operation.
If the I/O is
not successful, CP performs error recording,
retry, recovery, or ABEND procedures for the
virtual machine.
DMSDIO: Initializes
operations.
the CCW
to
DMSLAD: Obtains the address of
whIch-to read or write.
perform
read
the disk
from
]~2~JQ:
Determines the size of
read or written.
the record to be
~~2IB~:
to contain the
a record longer
Gets enough storage
record if the request is for
than 800 bytes.
DMSDIO: Reads records continually
rec~rds for the file have been read.
until
all
DMSFRE: Returns the buffer to free storage if
the-record was longer than 800 bytes.
~~2~!Q:
•
User program area (1'20000' to loader tables)
- User programs are loaded into this area by
the LOAD command. storage allocated by means
of the GETMAIN macro instruction is taken
from this area, starting
from the high
address of the user program.
In addition,
this storage area can be allocated from the
top down by DMSFREE, if not enough storage is
available in the low-core DMSFREE storage
area. Thus, the effective size of the user
program area is reduced by the amount of free
storage which has been allocated from it by
DMSFREE.
•
Loader tables
(top pages of storage)
- The
top of storage is occupied by the loader
tables, which
are required by
the CMS
loader. These tables indicate which modules
are currently loaded in the user program area
(and the transient program area after a LOAD
command). The size of the loader tables can
be varied by the SET LDRTBLS command.
Returns to the caller.
Free storage can be allocated
GETMAIN or DMSFREE macros.
DMSFRE handles requests for CMS free storage.
The sections of CMS storage have the following
uses:
•
•
•
•
DMSNUC (1'00000' to approximately 1'03000') This is the nucleus
constant area.
It
contains pointers, flags,
and other data
maintained by the various system routines.
LOW-core
DMSFREE
free
storage
area
(approximately 1'03000' to I'OEOOO')
- This
area is a free storage area, from which
requests from DMSFREE are allocated. The top
part of this area contains the file directory
for the system disk (SST AT).
If there is
enough room (as there will be in most cases) ,
the FREETAB table also occupies this area,
just below the SSTAT.
Transient prog~am area (I'OEOOO' to 1'10000')
- Because it is not essential to keep all
nucleus functions resident in storage all the
time, some of them are made "transient."
This means that when they are needed, they
are loaded from the disk into the transient
program area.
Such programs may not be
longer than two pages,
because that is the
size of the transient area.
(A page is 4096
bytes of virtual storage.)
CMS nucleus (1'10000' to 1'20000') - Segment
1 of storage contains the reentrant code for
the CMS nucleus routines.
In shared eMS
systems, this is the protected segment.
That
by means
of the
Storage allocated by means of the GETMAIN
macro is taken from the user program area,
beginning with the high address of the user
program.
storage allocated by means
macro can be taken from several
of the
DMSFREE
areas~
First, DMSFREE requests are allocated from
the low-address free storage area. If requests
cannot be satisfied from there,
they will be
satisfied from the user program area.
In addition, requests are further broken down
between requests for user storage and nucleus
storage, as specified in the TYPE parameter of
the DMSFREE macro.
These two types of storage
are kept in separate 4K pages. It is possible,
if there are no 4K pages completely free in low
storage, for no storage of one type to be
available in low storage, while there is storage
of the other type available there.
All GETMAIN storage is allocated in the user
program area, starting from the end of the
user's actual program. Allocation begins at the
location pointed to by NUCON pointer MAINSTRT.
The location MAIN8IGB in NUCON is the pointer to
the highest address of GETMAIN storage.
section 2. Method of Operation and Program organization
185
When the STRINIT macro is executed, hoth
MAINSTRT and MAINBIGB are initialized to the end
of the user's program, in the user program area.
As storage is allocated from the user program
area to satisfy GETMAIN requests, the MAINHIGB
pOinter is adjusted upward.
Such adjustments
are always in multiples of doub1ewords, so that
this
pointer is
always
on a
douhleword
boundary. As the allocated storage is released,
this pointer is adjusted downward.
The pointer MAINHIGH can never be higher than
FREELOVE, the pointer to the lowest address of
DMSFREE storage allocated in the user program
area. If a GETMAIN request cannot be satisfied
without extending
MAINHIGH ahove
FREELOVE,
GETMAIN takes an error exit, indicating that
insufficient storage is available to satisfy the
request.
The area between MAINSTRT and MAINHIGH may
contain
blocks of
storage
that are
not
allocated, and that are therefore available for
allocation by a GETMAIN instruction.
These
blocks are chained together,
with the first one
pointed to by the NUCON location HAIBLIST.
The format of an element on the GETMAIN free
element chain is as follows:
<--------
4 bytes
-------->
...--------_ _-----------------,
..
0(0)
I
1
I
4(4)
I
1
1
FREPTR pointer to next free
element in the chain, or 0
if there is no next element
..
I--~-----.-------.------------
FRELEN length, in bytes, of
this element
I
I
I
1
I
I
1-------------_._----------1
1
Remainder of this free element
1
The FREETAB free storage table is kept in
free storage, usually
just below the master
file directory for the system disk.
If there
was no space available there, then FREETAB was
allocated from the top of the user program area.
This table contains one byte for each page of
virtual storage.
Each such byte contains a code
indicating the use of that page of virtual
storage.
The codes in
this table are as
follows:
y~~]~~~~
(j):
If the page
~y~~~y~
The pointer FREELOVE is the pointer to the
lowest address of DHSFREE storage in the user
program area. As storage is allocated from the
user program area to satisfy DMSFREE requests,
this
pointer is
adjusted downward.
Such
adjustments are always in multiples of 4K, so
that this pointer is always on a
4K boundary.
As the allocated storage is released, this
pointer is adjusted upward when whole 4K pages
are completely free.
The pointer FREELOVE can never be lower than
MAIBHIGH, the pointer to the highest address of
GETMAIN storage. If a DMSFREE request cannot be
satisfied without
extending FREELOVE
below
MlINHIGB, then DMSFREE takes an error exit,
indicating
that
insufficient
storage
is
available to satisfy the request.
186
to user
(~):
If the page
is assigned to nucleus
storage.
!]!~~]]
is
(1): If the page
transient program area.
y~!]~~]]
(~):
If the page
part
is part of
of
the
the user
program area.
~!~~~~]
(~):
If the page is none of the above.
In these cases, the page is assigned to
system storage, system code, or the loader
tables.
Other DHSFREE storage pointers are maintained
in the DMSFRT control section, in NUCON. The
most important fields there are the four chain
header blocks.
Four chains of elements are not allocated to
be
associated with
DHSFREE storage:
The
low-storage nucleus chain, the low-storage user
chain, the high-storage nucleus chain, and the
high-storage user chain. For each of these
chains, exists a control block consisting of
four words, with the following format:
<
The pointers FREEUPPR and FREELOWE in NUCON
indicate the amount of storage which DMSFREE has
allocated from the high portion of the user
program area. These pointers are initialized to
the beginning of the system loader tables.
is assigned
storage.
4 bytes
----->
r
------------------.,
1
I
IPOINTER
pointer to the first
1
0(0) 1
free element on the chain, or
I
I
zero, if the chain is empty.
1
1--------------------1
I BUM - the number of elements on 1
4 (4) I
the chain.
I
1--------------------1
I MAX the value in this word is I
8(8) 1
the size of the largest free
1
1
element on the chain.
1
1-----·_---------------1
1 FLAGS- 1 SKEY - 1 ~rCODE -I Unused 1
12(C) 1 Flag
Istorage IFBEETAB 1
1
11.-_
byte
key
1 _ _code
1_ _ _ _- - - '1
_ _ _ _ _1
__
______
_____
These
uses:
POINTER
fields have
the
following meanings
and
This field points to the first element
on this chain of free elements.
If
there are no elements on this free
chain, then the POINTER field contains
a zero.
IBM VM/310: System Logic and Problem Determination Guide
BUM
This field contains
the nu mber of
elements
on
this chain
of
free
elements. If there are no elements on
this free
chain r then
this field
contains a zero.
MAX
This field is used for the purpose of
avoiding searches which will fail.
It
contains the sizer in bytes r of the
largest element on the free chain.
Thus r a search for an element of a
given size will not be made if that
size exceeds the MAX field.
FLAGS
<--------
-------->
0(0)
-,
I
I
I
POINTER pointer to the next
element in the free chain
I
I
I
SIZE -- size of this free
elelllent r in bytes
I
Remainder of this free element
I
I
I
1-------------------------1
4 (4)
I
I
I
1-------,------------------4
I
The following flags are used:
F LC LIi ( X' 80 ' )
Clean-up flag
This flag is set if the
chain must
be cleaned up.
This is
necessary in the following circumstances:
- If one of the two high-core chains
contains a 4K page that is pointed to by
FREELOWE r then that page can be removed
from the chain r and
FREELOWE can be
increased.
- All, completely non-allocated 4K pages
are kept on the user chain r by convention.
Thus r if
one of the
nucleus chains
(low-core or high-core)
contains a full
pager then this page must be transferred
to the corresponding user chain.
FLCLB(X' 40')
Clobbered flag - Set if the chain has been
destroyed.
When the user issues
a variable length
GETMAlli r the control program reserves 6 1/2
pages for CMS usage; this is a designed and set
value.
If the user wants more spacer for
example r for more directories, he should free up
from the high end of storage some of the
variable GETMAIN area.
As indicated in the illustration above, the
POINTER field points to the next element in the
chain r or contains the value zero if there is no
next element. The SIZE field contains the size
of this element r in bytes.
III elements within a given chain are chained
together in order of descending storage address.
This is done for two reasons:
1.
Because the allocation search is satisfied
by the first free element that is large
enough r the allocated elements are grouped
together at the top of the storage area r
and prevent storage fragmentation.
This is
particularly important
for high-storage
free storage allocations r because it is
desirable to keep FREEL OWE as high as
possible.
2.
If free
storage does
become
fragmented r the search causes as
faults as possible.
FL HC (X' 20 ' )
High-core chain - Set for both the nucleus
and user high-core chains.
FL Ii U ( X' 1 0 ' )
Nucleus chain - Set for both the low-core
and high-core nucleus chains.
FLPA (1'08')
Page available - This flag is set if there
is a full 4K page available on the chain.
Note that this flag may be set even if
there is no such page available.
SKEY
4 bytes
r
This one-byte field contains the storage
key assigned to storage on this chain.
TCODE This one-byte field contains the FREETAB
table code for storage on this chain.
Each element on
following format:
the
free
chain
has
sOllewha t
few page
As
a matter
of convention r
completely
nonallocated 4K pages are kept on the user chain
rather than the nucleus chain. This is because
requests fer large blocks of storage are made r
most of the timer froll user storage rather than
from nucleus storage.
Nucleus requests need to
break up a full page less frequently than user
requests.
the
I description of the algorithms which allocate
and release blocks follows.
The descriptions
are based
on the assumption
that neither
IREI=LOW nor AREI=HIGH was specified in the
DMSFREE macro call. If either was specified,
then
the algorithm
must be
appropriately
modified.
!11Q£!~!!Q Q2~] l]~~ 2~Q]!Q~:
When DMSFREE with
TYPE=USER (the default) is called r the following
steps are taken to satisfy the request. As soon
Section 2. Method of Operation and Program organization
187
as one of the
can terminate.
steps succeeds,
DMSFRE:
then processing
1.
Searches low-storage user chain for a block
of the required size.
2.
Searches the high-storage user
block of the required size.
3.
Extends high-storage user
into the user
program
FREELOWE in the process.
4.
For fixed requests, there is nothing more
to try.
For variable requests, DMSFRE puts
all available storage in the user program
area onto the high-storage user chain, and
then allocates the largest block available
on either the high-storage user chain or
the low-storage user chain. The allocated
block is not satisfactory, if it is not
larger then the minimum requested size.
ALLOCATING
NUCLEUS FREE
STORAGE: When
DMSFREE
3.
Nucleus
blocks.
4.
User variable storage requests.
(Variable
requests are no less efficient than fixed
requests,
if the
maximum block
size
requested can be allocated.)
5.
Fixed variable storage requests, if the
maximum block size requested cannot be
allocated.
fixed storage
request, for
large
STORAGE ALLOCATED BY g~I~A!]: storage allocated
by-the-GETMAii-macro instruction may be released
in any of the following ways:
A specific block of such storage may be
released by means of the FREEMAIN macro
instruction.
Searches the low-storage nucleus chain for
a block of the required size.
•
Gets free pages
from low-storage user
chain, if any are available, and removes
them to the low-storage nucleus chain.
The STRINIT macro
storage allocated
requests.
•
Almost all CMS commands call the STRINIT
routine.
Thus,
executing almost any CMS
command causes all GETMAIN storage to be
released.
Searches the highstorage nucleus chain for
a block of the required size.
4.
Gets free Fages from the high-storage user
chain, if they are available, and removes
them to the highstorage nucleus chain.
6.
Nucleus fixed storage requests, for small
blocks (less than one page in size).
•
3.
5.
2.
storage downward
area, modifying
are taken in an attempt to satisfy the request,
until one succeeds. DMSFREE:
2.
User fixed storage requests, any size.
chain for a
wlth-TYPE~NUCLEUS-Is-called:-the-following steps
1.
1.
Extends
high-storage
nucleus
storage
downward into
the user
program area,
modifying FREELOWE in the process.
For fixed requests, there is nothing more
to try. For variable requests, DMSFRE puts
all available pages from the user chains
and the user program area onto the nucleus
chains, and allocates the largest block
available cn either the low-storage nucleus
chains or the high-storage nucleus chains.
RELEASING STORAGE: When DMSFRET is called, the
block---beIng---released is
placed
on
the
appropriate chain.
At that point, the cleanup
operation is performed, if necessary, to advance
FREELOWE, or to move pages from the nucleus
chain to the corresponding user chain.
instruction releases all
by any previous GETMAIN
STORAGE ALLOCATED BY ~~~l~~: Storage allocated
by-the-DMSFREE-macro instruction may be released
in either of the following ways:
•
A specific block of such storage may be
released by means of
the DMSFRET macro
instruction.
•
Whenever any user routine or CMS command
abends
(so
that the routine
DMSABN is
entered), and the ABEND recovery facility of
the system 1S invoked, all DMSFREE storage
with TYPE=USER is released automatically.
Except in the case of ABEND recovery, storage
allocated by the DMSFREE macro is never released
automatically by the system.
Thus, storage
allocated by means of this macro instruction
should always be released explicitly by means of
the DMSFRET macro instruction.
Similar cleanup operations are performed,
when necessary, after calls to DMSFREE, as
well.
The system uses the DMSFRES macro instruction to
request
certain
free
storage
management
services. The options and their meanings are as
follows:
The types of DMSFREE request in decreasing order
of efficiency, are as follows:
188
•
INIT1--DMSINS calls this option to invoke the
first free storage initialization routine, to
IBM VM/370: system Logic and Problem Determination Guide
allow free storage requests to access the
system disk.
Before this routine is invoked,
no free storage requests may be made. After
this routine has been invoked, free storage
requests may be made, but these are subject
to the following restraints until the second
free
storage
management
initialization
routine has been invoked:
•
CHECK--This option can be called at any time
for system debugging purposes.
It invokes a
routine that performs a thorough check of all
free storage chains
for consistency and
correctness. Thus, it checks to see whether
any
free
storage
pointers
have
been
destroyed.
•
CKON--This option turns on a flag which
causes the CHECK routine described in the
preceding paragraph to be invoked each time
any call is made to DKSPREE or DMSPRET. This
can be useful to pinpoint a problem that is,
for
example,
destroying
free
storage
management pointers. Care should be taken
when using this option, because the CHECK
routine is coded to be thorough rather than
efficient. Thus, after the CKON option has
been invoked, each call to DMSPREE or DMSPRET
takes many times as long to be completed as
before. This can impact the efficiency of
system functions.
•
CKOPP--Use of this option turns off the flag
that was turned by the CKOB option, described
in the preceding paragraph.
•
UREC--This option is called by DMSABN during
the ABEND recovery process to release all
USER storage.
•
CALOC--This option is called by DMSABN after
the
ABEND
recovery
process
has
been
completed.
It invokes
a routine
that
returns, in
register 0, the
number of
doublewords of free storage that have been
allocated. This figure is used by DMSABN to
determine Whether ABEND recovery has been
successful.
All requests for user storage are changed
to requests for nucleus storage.
Only partial error checking is performed
by the DMSPRET routine. In particular, it
is possible to release a block that was
never allocated.
All requests that are satisfied in high
storage must be temporary, because all
high storage allocated is released when
the second free storage initialization
routine is invoked.
When CP's saved system facility is used,
the CMS system is saved at the point just
after the system disk has been accessed.
This means that it is necessary for DMSPRE to
be used before the size of virtual storage is
known, because the saved system can be used
on any size virtual machine. Thus, the first
initialization routine initializes DMSPRE so
that limited functions can be requested,
while the
second initialization
routine
performs the initialization
necessary to
allow the full functions of DMSPRE to be
requested.
IBIT2--This option is called by DMSINS to
invoke the second initialization routine.
This routine is invoked after the size of
virtual storage is known, and it performs the
initialization necessary to allow all the
functions of DMSPRE to be used.
The second
initialization routine performs the following
steps:
Releases
all storage
that has
allocated in the highstorage area.
been
In general, the following rule applies: system
storage is assigned the storage key of X'P',
while user storage is assigned the key of X'E'.
This is the storage key associated with the
protected areas of· storage, not to be confused
with the PSW or CAW key used to access that
storage.
The specific key assignments are as follows:
Allocates the PREETAB free storage table.
This table contains one byte for each
4096-byte page of virtual storage, and so
cannot be allocated until the size .of
virtual storage is known. It is allocated
in the low-address free storage area, if
there is enough room available.
If not,
then it is allocated in the higher free
storage area. Por a 256K virtual machine,
PREETAB contains 64 bytes;
for a 16
million byte machine, it contains 4096
bytes.
•
The BUCON area is assigned the key of X'P',
with the exception of a half-page containing
the OPSECT and TSOBLOKS areas, which has a
key of X'E'.
•
Pree storage allocated
up into user storage
The user storage has
X'E', while the nucleus
X'P'.
•
The transient
X'B'.
•
The CMS nucleus code has a storage key of
X'P'.
In saved systems, this entire segment
is protected by CP from modification even by
the CMS system, and so must be entirely
reentrant.
The PREETAB table is initialized, and all
storage protection keys are initialized.
All completely non-allocated 4K pages on
the nucleus free storage chain are removed
to the user chain.
Any other necessary
cleaning up operations are performed.
program
by DMSPREE is broken
and nucleus storage.
a protection key of
storage has a key of
area has
a
key
Section 2. Method of Operation and Program Organization
of
189
•
•
The user program area is assigned the storage
key of X'E', except for those pages which
contain Nucleus
DMSFREE storage.
These
latter pages are assigned the key of X'F'.
The
loader tables
are assigned
the key
The
explanation
of saved
system
nucleus
protection depends on the VSK, RSK, VPK and RPK:
of
X 'F'.
The CMS nucleus protection scheme protects the
CMS nucleus from inadvertent destruction by a
user program. This mechanism, however, does not
prevent a user from writing in system storage
intentionally.
Because a CMS user can execute
privileged instructions, he can issue a LOAD PSi
(LPSi)
instruction and load any PSi key he
wishes. If a user defeats nucleus protection in
this way there is nothing to prevent his program
froll:
•
Modifying nucleus code
•
Modifying a table or constant area
•
Losing files
directory
by
modifying
a
CMS
file
In general, user programs and disk-resident
CMS commands run with a PSi key of X'E', while
nucleus code runs with PSi key of X'O'.
There are, however, some exceptions to this
rule.
certain disk-resident CMS commands run
with a PSi key of X'O', because they need to
modify nucleus pointers and storage. On the
other hand, the nucleus routines called by the
GET, PUT, READ and iRITE macros run with a user
PSi key of X'E', to increase efficiency.
TWO macros, DMSKEY and DMSEXS, are available
for changing the PSi key.
The DMSKEY macro
changes the PSi key to the user value or the
nucleus value.
DMSKEY NUCLEUS
causes the
current PSi key to be placed in a stack, and a
value of 0 to be placed in the PSi key.
DMSKEY
USER causes the current PSi key to be placed in
a stack, and a value of X'E' to be placed in the
PSi key.
DMSKEY RESET causes the top value in
the DMSKEY stack to be removed and re-inserted
into the PSi.
It is a CMS requirement when a routine
terminates, that the DMSKEY stack must be empty.
This means that a routine should execute a
DMSKEY RESET macro instruction for each DMSKEY
NUCLEUS macro instruction and each DMSKEY USER
macro instruction executed by the routine.
The DMSKEY key stack has a maximum depth of
seven for each routine.
In this context, a
"routine" is anything invoked by an SVC call.
The DMSEXS
("execute in system mode")
macro
instruction is useful in situations where a
routine is running with a user PSi key, but
wishes to execute a single instruction with the
nucleus PSi key. The single instruction may be
specified as the argument to the DMSEXS macro,
and that instruction is executed with a system
PSi key.
1.
Virtual storage Key
(VSK) This is the
storage key assigned by the virtual machine
using the virtual SSK instruction.
2.
Real Storage Key (RSK) - This is the actual
storage key
assigned by CP to the 2K
page.
3.
Virtual PSi Key (VP~
- This is the PSi
storage
key assigned
by the
virtual
machine, by means of an instruction such as
LPSW (Load PSW).
4.
Real PSi Key
(RPK) This is the PSW
storage key assigned by CP, which is in the
real hardware PSi when the virtual machine
is running.
When there are no shared segments in the
virtual machine, then storage protection works
as it does on a real machine.
RSK=VSK for all
pages, and RPK=VPK for the PSW.
However, when there is a shared segment (as
in the case of segment 1 of CMS in the saved
system), it is necessary for CP to protect the
shared segment. For non-CMS shared systems, it
does this by, essentially, ignoring the values
of the VSKs and VPK, and assigning the real
values as follows:
RSK=O for each page of the
shared segment,
RSK=F for all other pages, and
RPK=F, always, for the real PSW.
The SSK
instruction is ignored, except to save the key
value in a table in case the virtual machine
later does an ISK to get it back.
For the CMS saved system, the RSKs and RPK
are initialized as before~ but resetting the
virtual keys has the following effects:
•
If
the
virtual machine
uses
an
SSK
instruction to reset a VSK, CP does the
following:
If the new VSK is nonzero, CP
resets the RSK to the value of the VSK; if
the new VSK is zero, CP resets RSK to F.
•
If the virtual machine uses a 2 : f P
instruction to reset the VPK
CP does the
following: If the new VPK is ero, CP resets
the RPK to the value of the VPK; if the new
VPK is zero, CP resets RPK to F.
•
If
the VPK=O
and
the RPK=F,
storage
protection may be handled differently. In a
real machine, a PSi key of 0 would allow the
program to store into any storage location,
no matter what the storage key.
But under
CP, the program gets a protection violation,
unless the RPK of the page happens to be F.
(~ther)
Because of this, ther&is extra code in the
CP program check handling routine. Whenever
a protection violation occurs, CP checks to
see if the following conditions hold:
The virtual m&chine running is the saved
CMS syste.,
running with
a shared
segment.
190
IBM VM/370: System Logic and Problem Determination Guide
The VPK = O. The virtual machine is
operating as though its PSi key is O.
The BSK of the page into which the store
was attempted is nonzero, and different
from the BPK.
could not be satisfied.
Begister 15 contains
this return code, indicating which error has
occurred. The codes below apply to the DMSFBES,
DMSFBEE and DMSFBET macros.
Code
1---
Error
DMSPREE -- Insufficient storage space is
available to satisfy the request for free
storage
In the case of a variable
request, even the minimum request could
not be satisfied.
2
DMSFREE or
DMSFRET
pointers destroyed.
3
DMSFBEE or DMSFBET
pointers destroyed.
4
DMSFBEE -- An invalid size was requested.
This error exit is taken if the requested
size is not greater than zero.
In the
case of variable requests, this error
exit is taken if the minimum request is
greater
than
the
maximum
request.
However, the error is not detected if
DMSFREE is able to satisfy the maximum
request.
5
DMSFBET -- An invalid size was passed to
the DMSFBET macro. This error exit is
taken if the specified length is not
positive.
6
DMSPRET -- The block of storage which is
being released was never allocated by
DMSFBEE. Such an error is detected if
one of the following errors is found:
If anyone of these three conditions fails to
hold, then the protection violation is reflected
back to the virtual machine.
If all three of these conditions hold, then
the BPK
(the real protection key in the real
PSi) is reset to the BSK of the page into which
the store was attempted.
EFFECT ON CMS:
In CMS, this works as follows:
CMS-keeps -Its system storage in protect key F
(RSK = VSK = F), and user storage in protect key
E (BSK = VSK = E) •
When the CMS supervisor is running, it runs
in PSW key 0 (VPK = 0, RPK = F), so that CMS
gets a protection violation the first time it
tries to store into user storage (VSK
RSK =
E). At that point, CP changes the BPK to E, and
lets
the
virtual machine
re-execute
the
instruction
which
caused
the
protection
violation.
There is not another protection
violation until the supervisor goes back to
storing into system-protected storage.
S~~I~J~IIQ~~
CN CMS: There are several coding
restrictions which-iust be imposed on CMS if it
is to run as a saved system.
F'.
This
restriction
also applies
to
I/O
instructions. If the key specified in the CCW
is zero, then the data area for input may not
cross the boundary between
two pages with
different storage keys.
CVEBHEAD: It can be seen that this system is
iiiost--liiefficient when "storage-key thrashing"
occurs -- when the virtual machine with a VPK of
o jumps around, storing into pages with
different VSK 's.
storage
Nucleus
storage
a. The block is
not entirely inside
either the
free storage area in low
storage or the
user program area
between FBEELOWE and FBEEUPPR.
The first and most obvious one is that CMS
may never modify segment 1, the shared segment,
which runs with a BSK of 0, although the VSK =
A less obvious, but
just as important,
restriction, is that CMS may never modify with a
single machine instruction
(except MVCL) a
section of storage which crosses the boundary
between two pages with different storage keys.
This restriction
applies not
only to
SS
instructions, such as HVC and ZAP, but also to
BS instructions,
such as STM, and
to BX
instructions, such as ST and STD, which may have
nonaligned addresses on the System/370.
An
exception is the MVCL instruction which can be
restarted after crossing a page boundary because
the registers are updated
when the paging
exception occurs.
User
b. The block crosses
a page-boundary
which separates a page allocated for
user storage from a page allocated for
nucleus type storage.
c. The block
overlaps another
block
already on the free storage chain.
7
DMSFBET
The address given for the
block being released is not a doubleword
boundary.
8
DMSFRES -- An illegal request code was
passed to the DMSPBES routine.
Because
all request codes are generated by the
DMSFBES macro, this error code should
never appear.
9
DMSFBE,
DMSFBET, or
DMSFBES
unexpected internal error occurred.
An
CMS uses the DMSPBES macro to request special
internal free storage management services. Use
of this macro by non-system routines causes
unpredictable results. The format is:
A nonzero return code, upon return from DMSPBES,
DMSFBEE or DMSFRET, indicates that the request
Section 2. Method of Operation and Program organization
191
r----------------------------------------------,
option should be used only by system
routines that should enter a user exit
routine.
IL______________________________________________
label I DMSPRES I
option
I
~
where 'option' is one of the following:
INIT1
Performs
the
CMS
initialization routine.
system
INIT2
Performs
the
CMS
initialization routine.
CtIECK
the
Invokes
a routine
that checks
validity of all current free storage
management pointers.
CKON
sets a flag that causes the
invoked for each call to
DMSPRET.
CKOPF
Turns off the above flag.
UREC
Assists AEEND recovery,
by releasing all
USER-type DMSFREE storage allocations.
CALOC
Assist ABEND recovery, by computing the
total
amount of
allocated
storage,
excluding the system disk MFD and the
FREETAE table.
system
NOSTACK
This option may be used with any of
the above options
to prevent the
system from saving the second byte of
the current PSi in a stack.
If this
is done, then no OMSKEY RESET need be
issued later.
RESET
The second byte of the PSi is changed
to the value at the top of the PSi key
stack,
and removed from the stack.
Thus, the effect of the last DMSKEY
NUCLEUS or USER or LASTUSER request is
reversed.
This option should may not
be used to reverse the effect of a
OMSKEY macro for which the NOSTACK
option was specified.
A DMSKEY RESET
macro must be executed for each DMSKEY
NUCLEUS, USER or LASTUSER macro that
was executed and that did not specify
the
NOSTACK option.
Failure
to
observe this rule results in program
abnormal termination.
first
second
CHECK to be
OMSPREE or
For a full discussion of t he meanings of
these
options,
refer to
"DMSFRE
Service
Routines. II
CMS uses the DMSKEY macro to modify the PSi
storage protection key so that the nucleus code
can store data into protected storage.
The
format is:
r-----------------------------------------------,
I [label]
DMS KEY I {NU CLEUS[ , NOS TACK] I
I
I
I USER[,NOSTACK]I
I
I
I
I LASTUSER[, NOSTACK] I
RESET}
IL _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
I _._
____________________ I
system commands running in user protect status
use the DMSEXS macro
to execute a single
instruction with a system protect key in the
PSW. This macro instruction can be used in lieu
of two DMSKEY macros. The format is:
r--------------------------------------------,
I [label] I DMSEXS _ _
I _op-code,operands
_ _._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I
L
~
The
op-code and
the
operands of
the
instruction to be executed must be given as
arguments to the DMSEXS macro.
For example, execution of the sequence,
~
NUCLEUS
USER
LASTUSER
192
The nucleus storage protection key is
placed in
the PSW,
and
the old
contents of the second byte of the PSi
is saved in a stack.
Use of this
option allows the program to store
into
system
storage,
which
is
ordinarily protected.
The user storage protection key is
placed in
the PSW,
and
the old
contents of the second byte of the PSW
is saved in a stack.
Use of this
option prevents
the program
from
inadvertently
modifying
nucleus
storage, which is protected.
The SVC handler traces back through
its system save areas for the active
user routine closest to the top of the
stack, and the storage key in effect
for that routine is placed in the PSi.
The old contents of the second byte of
the PSW is saved in a stack.
This
USING NUCON,O
DMSEXS OI,OSSFLAGS,COMPSWT
would cause the 01 instruction to be executed
with a zero protect key in the PSi.
This
sequence would turn on the COMPSiT flag in the
nucleus.
It would be reset with
DMSEXS NI,OSSFLAGS,255-COMPSWT
The instruction to
instruction.
be executed may be
Register 1 cannot be used in any
instruction being executed.
an EX
way in the
The following contains descriptions for: access
method support for non-CMS operating systems,
CMS simulation
of OS
functions, and
CMS
implementation of DOS/VS functions.
IBM VM/370: system Logic and Problem Determination Guide
The description of
parts:
An access method governs the manipulation of
data.
To make the execution of as generated
code easier under CMS, the processing program
must see data as as would present it.
For
instance, when the processors expect an access
method
to
acquire input
source
records
sequentially, CMS invokes its sequential access
method and passes data to the processors in the
format that the as access methods would have
produced. Therefore, data appears in storage as
if it had been manipulated using an as access
method.
For example, block descriptor words
(BDi), buffer pool management, and variable
records are maintained in storage as if an os
access method had processed the data.
The
actual writing to and reading from the I/O
device is handled by CMS file management.
The work of the volume table of contents
(VTOC) and the data set control block (DSCB) is
done by a master
file directory
(MFD) to
maintain disk contents and a file status table
(FST) fo'r each data
file.
All disks are
formatted in physical blocks of 800 bytes.
CftS continues to maintain the as format,
within its own format, on the auxiliary device,
for files whose filemode number is 4. That is,
the block and record descriptor words
(BDi and
RDi) are written along with the data. If a data
set consists of blocked records, the data is
written to and read from the I/O device in
physical blocks, rather than logical records.
CftS also simulates the specific methods of
manipulating data sets.
TO accomplish this simulation, CMS supports
certain essential macros
for the following
access methods:
•
BDAM (direct)--identifying a record by a key
or by its relative position within the
data set.
•
BPAM (partitioned)--seeking a named
within an entire data set.
•
BDAM/QSAM (sequential)--accessing a record in
a sequence relative to
•
VSAM
member
(~irect
or
sequential)--accessing a
record sequentially or directly by key
or address.
CMS support of as VSAM
files is based on DOS/VS access method
services and the virtual storage access
method (VSAM).
Therefore, the as user
is
restricted
to
those
services
available under DOS/VS AMS and VSAM.
CMS simulation of as and DOS includes support
for the virtual storage access method
(VSAM).
this
support
is in
three
•
A description of the access method services
program (AMSERV), which allows you to create
and update VSAM files.
•
A description of support for
under CMS/DOS.
•
A description of support for VSAM functions
for the CMS as simulation routines.
VSAM functions
The routines that support VSAM reside in
three discontiguous shared segments (DCSSs).
The CMSAMS DCSS, which contains the DOS/VS
AMS code to support AMSERV processing.
The CMSVSAM DCSS, which contains actual
DOS/VS VSAM code, and the CMS/VSAM as
interface program for processing as VSAM
requests.
The CMSDOS DCSS, which contains the code
that supports DOS requests under CMS.
Note:
DMSVSR,
which
performs
completion
processing for CMS/VSAM support, resides in the
CMS nucleus.
CREATING THE DOSCB CHAIN
The DLBL command creates
a DOSCB in CMS
free
specified in this DLBL
with the ddname parameter
a control block called
storage.
The ddname
command is associated
in the program's ACB.
·The DOSCB contains information defining the
file for the system. The information in the
DOSCB parallels the information written on the
label information cylinder of a real DOS SYSRES
unit, e.g. the name, and mode (volume serial
number)
of the data set,
its logical unit
specification, and its data set type (SAM or
VSAM). The anchor for this chain is at location
DOSFIRST in NUCON.
The CMS AMSERV com.and
invokes the .odule
DMSAMS, which is the CMS interface to the DOS/VS
access method services
(AMS) program.
Module
DMSAMS loads DOS/VS AMS code contained in the
CMSAMS DCSS by means of the L01DSYS DIAGNOSE
64.
The AMS code requires the services of
DOS/VS code that resides in the CMSVSAM DCSS so
that DCSS is also loaded via LOADSYS DIAGNOSE 64
when the VSAM master catalog is opened.
Figure
51 shows the relationship in storage between the
interface module DMS1MS and the CMSAMS and
CftSVSAM DCSSs.
section 2. Method of Operation and Progra. organization
193
CMSAMS DCSS
CMS
A-disk
AMSERV MODULE
[ALR IDCAMS
---I
I
IDCAMS:
AMS Root
I
~hase_ --.J
CMSVSAM DCSS
B-disk
for
OS or
DOS
User
Figure 51. Relationship in
CMSVSAM DCSSs
Storage Between
the CMS
The following is a general description of the
tMSAMS method of operation.
DMSAMS first determines whether the user is
in the CMS/DOS environment. If not, a SET DOS
ON (VSAM) command is issued to load the CMSDOS
segment and initialize the CMS/DOS environment.
In this case, DMSAMS must also issue ASSGB
commands for the disk modes in the DOSCB chain
created by the OS user's DLBL commands.
An
ASSGN is also issued for SYSCAT, the VSAM master
ca talog.
DMSAMS then issues the ASSGB command for the
SYSIPT and SYSLST files, assigning them to the
user's A-disk.
DLBL commands are then issued
associating these units with files on the user's
A-disk. Input to the AMSERV processor is the
SYSIPT file,
which has the filetype AMSERV.
Output from AMSERV processing is placed in the
SYSLST file, which has a filetype of LISTING.
DIAGNOSE 64 (LOADSYS) is then issued to load
the CMSAMS DCSS, which contains the DOS/VS AMS
code. A DOS/VS SVC 65 is issued to find the
address of the DOS/VS AMS root phase, IDCAMS.
When the SVC returns with the address of IDCAMS,
a branch is made to IDCAMS, giving control to
"live" DOS/VS routines.
IDCAMS expects parameters to be passed to it
when it receives control. DMSAMS passes dummy
parameters in the list labeled AMSPARMS.
After the root phase IDCAMS receives control,
the functions in the file specified by the
filename on the AMSERV com.and are executed.
194
Interface Module
DMSAMS and
the CMSAMS
and
In performing the functions requested in this
file, AMS may require execution of DOS/VS VSAM
phases located in the CMSVSAM DCSS. The CMSVSAM
DCSS is loaded when AMS opens the VSAM catalog
for processing.
On return from DOS/VS code, DMSAMS purges the
CMSAMS DCSS, and issues DLBL commands for the
SYSIPT and SYSLST files to clear the DOSCB's for
these ddnames.
Control is then passed to DMSVSR, which
purges the CMSVSAM DCSS. If the user progra.
was not in the CMS/DOS environment when DMSAMS
was entered, the SET DOS OFF command is issued
by DMSVSR.
Upon return from DMSVSR, DMSAMS
performs minor housekeeping tasks and returns
control to CMS.
ihen a VSAM function, such as an OPEB or CLOSE
macro, is requested from a DOS program, CMS
routes control through the CMSDOS ncss to the
CMSVSAM ncss, thus giving control to DOS/VS VSAM
phases. Figure 52 shows the relationships in
storage between the user program, the CMSDOS
DCSS, and the CMSVSAM DCSS. The description
below illustrates the overall logic of that
control flow.
IBM VM/370: System Logic and Problem Determination Guide
DOS VSAM
Program
DOS Transient
Area
CMSDOS DCSS
DMSDOS
$$BOVSAM
---OPEN ACBl
DMSBOP
-----
------CLOSE ACBl
CMSVSAM DCSS
IKOVOPEN
$$BCVSAM
----
DMSCLS
----
----
$$BACLOS
IKOVCLS
----
B-disk
for OS
or DOS
User
Figure 52. The Relationships in Storage Between the User Program and the CMSDOS DCSS and the CMSVSAM
DCSSs
CftS/DOS SVC HANDLING
ftodule DftSDOS handles all CMS/DOS SVCs. There
are four CftS/DOS routines that handle VSAM
requests: DMSDCS, DMSBOP,
DMSCLS, and DMSXCP.
Within DMSDOS, several SVC functions support
VSAft
requests.
These
are
described
in
"Simulating a DOS Environment Under CMS."
When DMSBOP is entered to process ACBs, it
checks to see if CMSVSAM is loaded. If VSAM has
not been leaded, DIAGNOSE 64 is issued to load
the CMSYSAM DCSS. DMSBOP then initializes the
transient work area and issues a DOS OPEN via
SVC 2 to bring the VSAM OPEN $$BOVSAM transient
into the DOS transient area.
When VSAM processing
completes,
returns to the user program directly.
DftSDOS VSAM processing involves handling of SVC
65 (CDLOAD), which returns the address of a
specified phase to the caller. DMSDOS searches
both the shared segment table and the nonshared
segment table
for the CMSDOS
and CMSVSA"
segments, because both could be in use. Both of
these segment tables contain the name of each
phase comprising that segment followed by the
fullword address of that
phase within the
segment.
During SVC 65 processing, DMSDOS checks to
see if the address of IKQLAB is being requested.
IKQLAB is the YSAM routine that returns the
label information generated by DLBLs and EXTENT
cards in DOS/VS systems.
If this is the case,
DftSDOS saves the address of IKQLAB in NUCON for
later use by DMSXCP.
If VSAM has not been loaded, a DIAGNOSE 64
(LOADSYS) is issued to load the CMSVSAM DCSS.
control
DMSCLS processing
is nearly
the same
as
processing for DMSBOP. When DMSCLS is entered,
it checks for an ACB to process. If there is
one, the
$$BCVSAM transient work
area is
initialized and SVC 2 is issued to FETCH the
VSAM CLOSE transient $$BCVSAM into the DOS
transient area.
When the VSAM CLOSE routines
complete processing, control returns to the user
program, as in the case of OPEN.
When DMSXCP processes an
EXCP request, it
determines if the request is from IKQLAB (i.e.
to read the SYSRES label information). If so,
the label information area record is filled in
from the appropriate DOSCB.
(DM SXCP determines
that the caller is IKQLAB by comparing the
address of the caller with the address stored in
NUCON by DMSDOS, as described above.)
section 2. Method of Operation and Program Organization
195
as user requests for VSAK services are handled
by DOS/VS VSAK code that resides in the CKSVSAK
DCSS. To access this code, as VSAK requests are
intercepted by the CKS
module DKSVIP, the
interface between the as VSAK requests and the
CKS/DOS and DOS/VS VSAK routines.
Because DKSVIP is in the CKSVSAK segment, it
is available only when that segment is loaded.
Kodule DKSVIB, which resides in the CKS nucleus,
is a bootstrap routine to load the
CKSVSAK
segment and pass control to DKSVIP.
DKSVIP receives control from VSAK request
macros in three ways: via SVC (e.g. OPEN and
CLOSE), via a direct branch using the address of
DKSVIP in the ACB, and via a direct branch to
the location of DKSVIP whose address is 256
bytes into the CMSCVT (CKSCVT is a CKS control
block that simulates the aS CVT control block) •
OS VSAM
Program
CMS Module
DMSSOP
OPEN ACBl
DMSSOP19
DMSVIP
DMSSOP20
CMSDOS DCSS
DOS Transient
Area
DMSDOS
$$BOVSAM
DMSBOP
CMSVSAM
DCSS
IKQVOPEN
DMSCLS
IKWVCLS
53. Relationship in Storage Between the User Program,
Routines, and the CKSDOS and CKSVSAM DCSSs.
The description below illustrates the
logic of that control flow.
overall
DKSVIP gains control from DKSSOP when an as svc
19, 20 or 23 (CLOSE TYPE=T) is issued. It also
gains control on return from execution of a VSAK
function, as described below.
DKSVIP performs
five main functions:
•
Initializes the CMS/DOS
VSAK processing.
•
Simulates an as VSAM OPEN .acro.
•
Simulates an as VSAM CLOSE macro.
•
Simulates
an
as
VSAM
control
block
.anipulation .acro (GENCB, KODCB, SHOWCB, or
TESTCB) •
environment for
• Processes as VSAK I/O macros.
196
B-disk
tor OS
or DOS
User
$$BCVSAM
DOSCLOSE
BALR 14,15
Figure
Figure 53 shows the relationships in storage
between the user program, the as simUlation and
interface routines,
and the CMSDOS and CKSVSAM
DCSSs.
DOSOPEN
BALR 14,15
CLOSE ACBl
This last technique is used by the code
generated from
the as VSAK
control block
manipulation macros
(GENeS,
SHOWCB, TESTCB,
That is, the address at 256 into CVT is
KODCB).
assumed to be that of a control block that is at
displacement X'12'
has the address of the VSAK
control block manipulation routine.
To ensure
that
DKSVIP
receives control
from
these
requests, the address of DKSVIP is stored at 256
bytes into CKSCVT.
However, until the CKSVSAM
segment is loaded, the address at CMSCVT+256 is
the address of module DMSVIB rather than the
address of DKSVIP.
The
address of DKSVIP
replaces that of DKSVIB when CKSVSAK is loaded.
Both
DKSVIB nd
DKSVIP
have pointers
to
themselves at 12 bytes into themselves to ensure
that this technique works.
as
the as
simulation and
J:!!:!!ig!i~i!!g :t.!!~ ~~'§L!1Q'§ ];;!!!,i!:Q!!'!!~'!!!
R!:Q£~22i!!g
I/S AMF \\-'
Interface
!QI
.Q.§ !'§A~
DKSVIP gets control when the first VSAK .acro is
encountered in the user program. Initialization
processing begins at this time. The CMSDOS DCSS
is loaded by issuing the command SET DOS ON
(VSAK). ASSGN commands are also issued at this
ti.e according to the user-issued DCBL's as
indicated in
the DOSCB chain.
Once this
initialization completes, DMSVIP processes the
VSAM request.
After the initialization, DKSVIP first checks
to determine which VSAM
function is being
requested, OPEN, CLOSE, or a control block
manipulation macro.
For OPEN processing, the DOSSVC bit in NUCON is
set on and control passes to DMSBOP via SVC 2.
Once the CKS/DOS routines
are in control,
IBK VK/370: system Logic and Problem Determination Guide
execution of the VSAM fUnction is the same as
for the DOS VS1~ functions described above.
On return from executing the OPEN routine,
the address of another entry point to D"SVIP, at
label DMSVIP2, is placed in the ACB for the data
set just opened, the DOSSVC bit is turned off,
and control is passed to D"SSOP, which returns
to the user program. D"SVIP2 is the entry point
for code that performs linkage to the VSA" data
.anagement phase IKQVSM. This is done after the
first OPEN because it is assumed that, once
opened, the user performs I/O for the phase,
e.g. a GET or PUT operation.
When the linkage routine is entered, the
DOSSVC bit is set on and control is given to the
VSA" data management routine IKQVS". On return
from IKQVSM DMSVIP turns off the DOSSVC bit and
returns control to the user program.
(Refer to
Simulate as VSA" I/O Macros in this section.)
If an error return is provided for TESTCB,
the address of DMSVIP4 is SUbstituted in the
PLIST.
This allows DMSVIP to regain control
from VSA" so that the DOSSVC bit can be turned
off. The error routine is then given control
after the address is returned to the PLIST.
DftSVIP simulates the as GET, PUT, POINT, EBDREQ,
ERASE, and CHECK I/O macros.
First, the OS request code in register 0 is
mapped to a DOS/!S request code.
The RPL or
chain of RPLs 1S rearranged to DOS format
(unless that has already been done) •
If there is an ECB address in the OS BPL, a
flag is set in the new DOS RPL and the ECB
address is saved at the end of the RPL.
For CLOSE processing, the DOSSVC bit is set on
and control is passed to the CMS/DOS routine
D"SCLS via SVC 2. As in the case of OPEN, once
control passes to the CMS/DOS routine, execution
of the VSA" function is the same as for the DOS
VSAM functions described above.
On return from executing the VS1" CLOSE, the
DOSSVC bit is turned off and control passes to
D"SSOP, which returns to the user program.
Asynchronous I/O processing is simulated by
setting active exit returns inactive in the user
EXLST. The exception to this is the JBNAD exit
which need not be set inactive since it is not
an error exit.
Setting error exits to be
inactive prevents VSAM from taking an error
exit, thus allowing such an exit to be deferred
until a CHECK can be issued for it.
The DOS
IKQVS".
macro is then
issued via a
BALB to
DOS error codes returned in the RPL PDBK
field that do not exist in as are mapped to
their OS equivalents= If the user has specified
synchronous process1ng, this return code is
passed unchanged in register 15.
D"SVIP simulates the GENCE, "ODCB, SHOWCB, and
TESTCB control block manipulation macros.
GENCB PROCESSING:
When a GENCB macro is isstied
;ith-BLK;ics--or BLK=EXLST specified, the GENCB
PLIST is
passed unmodified to
IKQGEN for
execution. If GENCB is issued with BLK=RPL and
BCB=address specified, the PLIST is rearranged
to exclude the ECB specification, because DOS/VS
does not support BCB processing.
The GENCB
PLIST is then passed to IKQGEN for execution.
~Q~£~,
SHOWCB, AND
TESTCB ~~Q£~~~!!~:
When
MODCB, SHOWCB: or-TESTCB-is--issued, the OS ACB,
RPL, and EXLST control blocks are reformatted,
if necessary, to conform to DOS/VS formats.
For "ODCB and SHOWCB, the requests are passed
to IKQT"S for processing.
When "ODCB is issued
with EXLST= specified, ensure that the exit
routines return control to entry point D"SVIP3.
For TESTCB, check for any error routines the
user may
have specified.
If the
TESTCB
specified RPL= and IO=CO~PLETE, a not equal
result is passed to the user. All other TESTCD
requests are passed to DOS and the new PSW
condition code indicates the results of the
test.
Por asynchronous processing, return codes are
cleared before return and any exit routines set
inactive are reactivated in the EXLST.
Also,
all ECEs are set to WAITING status.
CHECK PROCESSING: For CHECK processing, return
-in-the--RPL FDBK field are checked to
determine the results of the I/O operation.
If
there is an active exit routine provided for the
return code, control is passed to that routine.
Also, all WAITING EeBs are posted with an
equivalent completion code.
codes
If no active exit routine is provided or if
the exit routine returns to VSAM, the return
code is placed in register 15 and control is
returned to
the instruction
following the
CHECK.
Two
types of
support
for error
routine
processing are provided in DMSVIP. Entry point
DMSVIP3 provides support for user exit routines;
entry point DMSVIP4 provides support for EBET
error returns.
Section 2. Method of Operation and Program Organization
197
M~]~
EXIT ROUTINE PROCESSING: DMSVIP provides
support-for--OS-YSAM--I/o-error exits at entry
point DMSVIP3.
At this entry point the DOSSVC
bit is turned off and the user storage key is
restored.
The address of the user routine is recovered
from VIp·s saved exit list (either the primary
exit list in the work area or the overflow exit
list, OEXLSA).
Control then passes to the appropriate exit
routine.
If the routine is one that returns to
VSAM, the DOSSVC flag is set ON and VSAM
processing continues.
DMSVIP can save the addresses of up to 128
exit routines
during execution of
a user
program.
ERET ERROR ~~YI!!] g~~~I~~l!Q: DMSVIP provides
support-for os VSAM ERET exit routines used in
conjunction with the TESTCB macro. This support
is located at entry point DMSVIP4. At DMSVIP4,
the DOSSVC bit is turned off and the user
storage key is restored.
The address of the
ERET routine is recovered from the work area and
control passes to that routine.
The ERET
VSAM.
COMPLETION
PROGRAMS
routine may
PROCESSING
not return
FOR
OS
These functions are simulated to yield the
same results
as seen from
the processing
program, as specified by
OS program logic
manuals.
However, they are supported only to
the extent stated in CMS documentation and to
the extent necessary to successfully execute OS
language processors.
The user should be aware
that restrictions to OS functions as viewed from
OS exist in CMS.
Certain TSO Service routines are provided to
allow the Program Products to run under CMS. The
routines are the Command Scan and parse Service
Routines and the Terminal I/O Service Routines.
In
addition the
user
'must provide
some
initialization as documented in TSO TMP Service
Routine initialization.
The OS functions that
CMS simulates are shown in Figure 54.
control to
AND
DOS
VSAM
When an OS or DOS VSAM program completes,
control is passed to
module DMSVSR, which
"cleans up" after VSAM.
DMSVSR can be called
from three routines after OS processing:
•
DMSIRT, if
processing completes
without
system errors or serious user errors.
•
DMSEXT, if the user program is used
of an EXEC file.
•
DMSABI, if there are system errors or
user program abnormally terminates.
After DOS VSAM processing
is called by DMSDOS.
When in a CMS environment,
a processor or a
user-written program is executing and utilizing
Os-type functions, OS is not controlling this
action, CMS is in control. Consequently, it is
not OS code that is in C~S,
but routines to
simulate, in terms of CMS, certain as func~ions
essential to
the support
of OS
language
processors and their generated code.
TSO macros that support the use of the terminal
monitor program
(TMP)
service routines are
contained in TSOMAC MACLIB. The macro functions
are as described in the TSO TMP documentation
with the exception of PUTLI.E, GETLINE, PUTGET,
and TCLEARQ.
Before using the TSO service routines, the
calling
program
performs
the
following
initialization:
1.
Stores the address of the command line as
the first word in the command processor
parameter list (CPPL) •
The TSOGET macro
puts the address of the CPPL in register
1.
2.
Initializes CMS
macro.
3.
Clears the ECT field that
address of the I/O work area
4.
Issues the STACK macro
to define the
terminal as the primary source of input.
as part
the
comFletes, DMSVSR
DMSVSR issues an SVC 2 to execute the DOS
transient routine $$BACLOS.
$$BACLOS first
checks for any OPEl VSAM files. If any are open,
SVC 2 is issued to $$BCLOSE (DMSCLS)
to close
the files.
If there are no open files or if all ACB·s
have been closed, $$BACLOS issues SVC 2 to
$$BEOJ4, an entry point in DMSVSR. At $$BEOJ4, a
PURGESYS
DIAGBOSE 64 is issued to purge the
CMSVSAM DCSS. DMSVSR then checks to see if an as
program has completed processing. If this is the
case, the SET DOS OFF command is issued and
control returns to the caller.
storage using
the STRINIT
contains the
(ECTIOWA).
Most of the simulated supervisory OS
blocks are contained in the following
control blocks:
control
two CMS
CMSCVT simulates the communication vector table
(CVT). Location 16 contains the address
of the CVT control section.
198
IBM VM/370: system Logic and Problem Determination Guide
SYC
Nuaber
00
01
02
03
04
05
06
07
08
09
10
11
\ 13
"1.\14
18
19
20
21
22
23
24
25
35
40
41
42
44
46
47
48
51
56
\. 57
60
62
63
64
68
69
93
\. 94
~96
-.
OS ftacro
Punction
Siaulation
Routine
IDAP
WAIT
POST
BXIT
GETftAIN
PREEMAIN
LINK
ICTL
LOAD
DBLBTE
GETftAIN/
PRBBMAIB
GETPOOL
TIMB
ABEND
SPIB
BLDL/PIND
OPBN
CLOSE
STOW
OPENJ
TCLOSE
DEYTYPE
TRKBAL
WTO/WTOR
BXTRACT
IDENTIFY
ATTACH
CHAP
TTIMER
STIftER
DEQ
SNAP
ENQ
FREEDBUF
STAE
DETACH
CHKPT
RDJFCB
SYNAD
BACKSPACE
GET/PUT
READ/WRITE
NOTE/POINT
CHECK
TGET/TPUT
TCLEARQ
STAI
DMSSVT
DftSSYB
DftSSVN
DftSSLB
DftSSMN
DftSSMN
DftSSLN
DftSSLB
DftSSLN
DftSSLB
DMSSMN
access voluaes
Waits for an I/O coapletion
Posts the I/O coapletion
Returns from linked phase
conditionally acquires user free storage
Releases user-acquired free storage
Links control to another load phase
Deletes, then links control to another load phase
Reads another load phase into storage
Deletes a loaded phase
Manipulates free user storage
DftSSftN
DftSSVT
DftSSAB
DftSSVT
DftSSVT
DftSSOP
DMSSOP
DftSSVT
DftSSOP
DftSSOP
DMSSVT
DftSSVT
DftSSVT
DMSSVT
DftSSVT
DftSSVT
DftSSVT
DMSSVT
DftSSVT
DftSSVT
DftSSVT
DMSSVT
DftSSVT
DMSSVT
DftSSVT
DftSSVT
DMSSVT
DftSSVT
DftSSVT
DMSSQS
DftSSBS
DMSSCT
DftSSCT
DftSSVB
DMSSVN
DMSSVT
siaulates an SVC10
Gets the time of day
Terainates processing
Processes program interruptions
Manipulates simulated partitioned data files
Activates a data file
Deactivates a data file
ftanipulates partitioned director1es
Activates a data file
Temporarily deactivates a data file
Obtains device-type physical characteristics
Effective NOP
Communicates with the terminal
Effective NOP
Adds entry to loader table
Effective LINK
Effective NOP
Accesses or cancels timer
Sets timer interval and timer exit routine
Effective NOP
Dumps specified storage areas
Effective NOP
Releases a free storage buffer
Allows processing program to decipher abend condition
Effective NOP
Effective NOP
Obtains information from FILEDEP command
Handles data set error conditions
Backs up to the beginning of the previous record
Manipulates data records
Manipulates data blocks
Accesses or changes relative track address
Tests ECB for completion and errors
Terminal processing
Clears input queue
Adds or deletes an attention exit level
I
I
-------------------------------Reads or writes direct
Pigure 54. OS Punctions that CftS Simulates
CMSCB
allocated
from system
free
storage
whenever a PILEDEP command or an OPEN
(SYC 19) is issued for a data set. The
CftS control block consists of the CMS
file Control block (PCB) for the data
file management under CftS, and simulation
of the job file control block
(JFCB),
input/output block (lOB), and data extent
block (DEB). The name of the data set is
contained in the FCB, and is obtained
from the FILEDEF argument list, or from a
predetermined file name supplied by the
processing problea program.
CftS also utilizes portions of the supplied data
control block
(DCB) and the data event control
block (DECB).
The TSO control blocks utilized
are the command program parameters list (CPPL),
user profile table (UPT), protected step control
block (PSCB), and environment control table
(ECT) •
CftS provides a number of routines to simUlate
certain operating system
functions used by
programs such as the Assembler and the FORTRAN
and PL/I compilers. Some of the SVC simUlation
routines are located in
the disk resident
transient module DftSSYT. Whenever one of the
SVC routines in DMSSVT or is invoked, that
routine is loaded into the transient area. The
following
paragraphs
describe
how
these
simulation routines work.
section 2. ftethod of Operation and Program Organization
199
!Q!~-§!£_~:
Writes and reads the source code
spill file, SYSUT1, during language compilation
for PL/I Optimizer and ANSI COBOL Compilers.
WAIT-SVC 1: Causes the active task to wait until
one--of-more event control blocks (ECBs)
have
been posted.
For each specified ECB that has
been posted one is subtracted from the number of
events specified in the WAIT macro. If the
number of events is zero by the time the last
ECB is checked control is returned to the user.
If the number of events is not zero after the
last ECB is checked and the number of events is
not greater than the number of ECBs, the active
task is put into a wait state until enough ECBs
are posted to set the number of events at zero.
When the event count reaches zero the wait bits
are turn off in any ECBS that have not been
posted and control is returned to the user.
If
the number of events specified is greater than
the number
of ECBs the
system abnormally
terminates with an error message.
All options
of WAIT are supported.
~Q§!=§!£_~:
Causes the specified event control
block (ECB) to be set to indicate the occurrence
of
an event.
This
event satisfies
the
requirements of a WAIT macro instruction. All
options of POST are supported.
The bits in the
ECB are set as follows:
~~!
o
1
2-7
.§~!!!!!g
0
1
Value of specified completion code
EXIT-SVC 3: This SVC is for CMS internal use
only:--It-is used by the CMS routine DMSSLN to
acquire an SVC SAVEAREA on return fron an
executing program that had been given control by
LINK (SVC 6), XTCL (SVC 7) or ATTACH (SVC 42).
GETMAIN-SVC 4: Control is passed to the GETMAIN
entry--point- in the DMSSMN storage resident
routine. The mode is determined:
VU, VC, EC.
A call is made to GETBLK to obtain the block of
storage.
Control
blocks of
two fullwords
precede each section of a vailable storage:
(1)
the address of the next block, (2)
the size of
this block. The head of the pointer string is
located at the words MAIRSTRT - initial free
block, and MAINLIST - address of first link in
chain of free block pointers. All options of
GETMAIN are supported.
FREEMAIN-SVC 5:
Releases
a block
of free
block is part of segmented
storage,
a control block of two fullwords is
placed at the beginning of the released area.
Adjustment is made to include this block in the
chain of available areas.
All options of
FREEMAIN are supported.
~torage:---If-the
LINK-SVC 6: Program transfer is controlled by
the--nocleus routine, DMSSLR.
The LINK macro
causes program control to
be passed to a
designated phase. If the COMPSWT bit within the
byte OSSFLAGS is on, loading is done by calling
LOADMOD to bring a CMS MODULE file into storage.
If this
flag is off, dynamic
loading is
initiated by calling LOAD.
A GETMAIR is issued
to obtain enough storage so that the loader
200
(DMSLDR) may relocate the phase in storage. A
chain of link request blocks is built to record
the old SVC PSW, and the location and size of
the phase storage area. If the routine is
already in storage, determined by scanning the
load request chain, no LOAD or LOADMOD is done.
Control is passed directly to the routine. CMS
ignores the DCB and HIARCH! options; all other
options of LINK are supported.
XCTL-SVC 7: XCTL first deletes the current phase
from ~torage. Processing then continues as for
LINK-SVC 6,
as previously
described.
CMS
ignores The DCB and HIARCH! options; all other
options of XCTL are supported.
bQ!Q-§!£_§: Control is passed to DMSSLN8 located
in DMSSLN when a LOAD macro is issued. If the
requested phase is not in storage, a LOAD or
LOADMOD is issued to bring it in.
Control is
then returned to the caller. CMS ignores the
DCB and HIARCHY options; all other options of
LOAD are supported.
~~b~I~=~!£_2:
Control is passed to DMSSLN9
located in DMSSLN when a DELETE macro is issued.
Upon entry, DELETE checks to see whether the
module specified was loaded using LOADMOD or
dynamically loaded by LOAD or INCLUDE.
If it
was loaded by LOAD MOD control is returned to the
user.
If
it was dynamically
loaded, the
responsibility count is decremented by one and
if it reaches zero, the storage is released
using FREEMAIN,
and control is returned to the
user.
All options of DELETE are supported.
Code 4 is returned in register 15 if the phase
is not found.
~1~~!lML~~~~~A!M-S!£_jQ:
Control is passed to
the SVC 10 entry point in DMSSMN.
Storage
management is
analogous to SVC 4
and 5,
respectively.
All
options of
GETMAIN and
PREEMAIN are supported.
Subpool specifications
are ignored.
~ll~QQ1:
Gets control via an OS
IECQBFGI.
IECQBPGI allocates an
storage using GETMAIN, sets up a
block" in the free storage, stores
the buffer control block in the
returns control to the caller.
LINK macro to
area of free
buffer control
the address of
DCB, and then
l!~I=§!£_jj:
This routine (TIME)
located in
DMSSVT receives control when
a TIME macro
instruction is issued.
A call is made
(by SIO
or DIAGNOSE)
to the RPQ software chr6nological
timer device, X'OPF'. The real time of day and
date are returned to the calling program in a
specified form: decimal (DEC)
binary (BIN), or
timer units
(TU). All options of TIME except
MIC are supported.
ABEND-SVC 13:
This routine
(DMSSAB)
receives
controI--when either an
ABEND macro or an
unsupported OS/360 SVC is issued.
If an SVC 13
was issued with the DUMP option and either a
SYSUDUMP or SYSABEND ddname had been defined via
a call tD DMSPLD ~ILEDEP), a SNAP (SVC 51)
specifying PDATA=ALL is issued to dump user
storage to the defined file.
A check is made to
see if there are any outstanding STAE requests.
If not, or if an unsupported SVC was issued,
DMSCWR is called to type a descriptive error
message at the terminal. Next, DMSCWT is called
to wait until all terminal activity has ceased,
IBM VM/370: System Logic and Problem Determination Guide
and then, control is
passed to the ABEND
recovery routine. If a STAE macro was issued, a
STAE work area is built and control is passed to
the STAE exit routine. After the exit routine
is complete, a test is made to see if a retry
routine was specified. If so, control is passed
to the retry routine.
Otherwise, control passes
to DMSABN unless the task that had the ABEND was
a subtask.
In that case, the resume'pSW in the
link block for the subtask is adjusted to point
to an EXIT instruction (SVC 3). The EXIT frees
the
subtask, and
the
attaching task
is
redispatched.
SPIE-SVC 14:
This
routine
(SPIE)
receives
control-when a SPIE macro instruction is issued.
When it gets control, SPIE inserts the new
program interruption control area (PICA) address
into the program interruption element
(PIE).
The program interruption element resides in the
program interruption handler
(DMSITP). It then
returns the address of the old PICA to the
calling program, sets the program mask in the
calling program's PSW, and
returns to the
calling program.
All options
of SPIE are
supported.
~1R1Ll!!R1IIE~_Ql=2!~_1~:
SVC to entry points
in DMSSOP.
If an os disk is specified, DMSSVT
branches and links to DMSROS. See BLDL and FIND
under description of BPAM routines in DMSSVT.
STOW-SVC 21: See STOW under description of BPAM
routines-In DMSSVT.
~R~!L~R~!~=2!~_12L~~:
OPEN simulates the data
management function of opening one or more
files.
It is a nucleus routine and receives
control from DMSITS when an executing program
issues an OPEN macro instruction.
The OPEN
macro causes an SVC to DMSSOP. DMSSOP simulates
the OPEN macro. The DISP and RDBACK options are
ignored by CMS; all other options of OPEN and
OPENJ are supported.
~1Q2ILI~1Q2~=2!~_~QL~J:
CLOSE and TCLOSE are
simulated in the nucleus routine DMSSOP.
It
receives control whenever a CLOSE or TCLOSE
macro instruction is issued.
The CLOSE macro
causes an SVC to DMSSOP.
DMSSOP simulates the
CLOSE macro.
CMS ignores the DISP option; all
other
options
of CLOSE
and
TCLOSE
are
supported.
~~!IXg~=§!~_~~:
This routine (DEVTYPE), located
in DMSSVT, receives control when a DEVTYPE macro
is issued.
Upon entry, DEVTYPE moves Device
Characteristic Information for the requested
data set into a user specified area, and then
returns control to the user.
All options of
DEVTYPE are supported.
IRK~!~=2!~_~2:
DMSSVT.
~IQL~IQ~=2!~_J2:
TRKBAL
is
a
NOP
located
in
This routine (WTO), located in
DMSSVT, receives control when either a WTO or a
iTOR macro instruction is issued. For a WTO, it
constructs a calling sequence to the DMSCWR
function program to type the message at the
terminal.
(The address of the message and its
length are provided in the parameter list that
results from the expansion of the WTO macro
instruction.)
It then calls the DMSCWT function
program to wait until all terminal I/O activity
has ceased. Next, it calls the DMSCWR function
program to type the message at the ter.inal and
returns to the calling program.
All options of
WTO and
WTOR are
supported except
those
concerned with multiple console support.
Por a WTOR macro instruction, this routine
proceeds as described for WTO.
However, after
it has typed the message at the terminal it
calls the DMSCRD function program to read the
user's reply from the terminal. When the user
replies with a message, it moves the message to
the buffer specified in the WTOR parameter list,
sets the completion bit in the ECB, and returns
to the calling program.
~!l~!~l=§!~_~Q:
This routine (EXTRACT), located
in DMSSVT receives control when an EXTRACT macro
is issued. Upon entry, EXTRACT clears the user
provided answer area and returns control to the
user with a return code of 4 in register 15.
IDENTIFY-SVC 41:
Located in
DMSSVT,
this
routIne-Creates a new load request block with
the requested name and address if both are
valid. The new entry
is chained from the
existing load request chain. The new name may
be used in a LINK or ATTACH macro.
ATTACH-SVC 42:
Located in
DMSSLN,
ATTACH
operates-rike a LINK
(SVC 6), with additional
capabilities. The user is allowed to specify an
exit address to be taken upon return from the
attached phase; also, an ECB is posted when the
attached phase has completed; and a STAI routine
can be specified in case the attached phase
abends. The DCB, LPMOD, DPMOD, HIARCHY, GSPV,
GSPL, SHSPV, SHSPL, SZERO, PURGE, ASYNCH, and
TASKLIB options are ignored; all other options
of ATTACH are supported. Because CMS is not a
multitasking operating system, a phase requested
by the ATTACH macro must return to CMS.
~~AR=~!£_~~:
CHAP is a NOP located in DMSSVT.
TTIMER-SVC 46: Checks to ensure that the value
Ii-the--timer (hex location 50) was set by an
STIMER macro. If it was, the value is converted
to an unsigned 32 bit binary number specifying
26 microsecond units and is returned in register
o. If the timer was not set by an STIMER macro
a zero is returned in register 0, after setting
register 0, the CANCEL option is checled. If it
is not specified, control is returned to the
user. If it is specified, the timer value and
exit routine set by
the STIMER macro are
cancelled and control is returned to the user.
All options of TTIMER are supported.
~Il~]]=~!£_~l:
Checks to see if the WAIT option
is specified. If so, control is returned to the
user. If not, the specified timer interval is
converted to 13 microsecond units and stored in
the timer
(hex location
50) •
If a timer
completion exit routine is specified, it is
scheduled to be given control after completion
of the specified time interval.
If not, no
indication of
the completion of
the time
interval is scheduled.
After checking and
handling any specified exit routine address,
control is returned to the user. All options of
STIMER are supported.
The
TASK option is
treated as though the REAL option had been
specified.
section 2. Method of operation and Program organization
201
RIQ:~!~_!~:
DEQ is a HOP located in DftSSVT.
SIAP-SVC 51:
Control is passed to SlAP in
iiiissVT-;iien a SlAP .acro is issued. SlAP fills
in a PLIST with a beginning and ending address
and calls DftPEIEC. DftFEXBC du.ps the specified
storage along with the registers and low storage
to the printer.
Control is then returned to
SlAP and SlAP checks to
see if any more
addresses are specified. It continues calling
DftPEXBC until all the specified addresses have
been du.ped to the printer.
Control is then
returned to the user. The DCB, SDATA, and PDATA
options are ignored by CftS; all other options of
SRAP are supported.
J!g=SV£_~§:
ERQ is a lOP located in DftSSVT.
FRBEDBUF-SVC 51:
This
routine
(FREEDBUF)
locatea--lii--iiftSSVT receives
control when a
FREEDBUF macro is issued.
Upon entry, FREEDBUF
sets up the correct DSECT registers and calls
the FREEDBUF routine in DftSSBD. This routine
returns the dyna.icallyobtained buffer (BDAft)
specified in the DECB to the DCB buffer control
block chain.
Control is then returned to the
DftSSVT routine which returns control to the
user.
All the
options
of PREEDBUF
are
supported.
§!!I~!£_§Q:
This routine (STAE)
located in
DftSSVT receives control when a STAE macro is
issued. Upon entry, STAE creates, overlays or
cancels a STAE control block (SCB) as requested.
Control is then returne~ to the user with one of
the following return codes in register 15:
Code
00-08
1t~gll!llg
An SCB is successfully created,
overlaid or cancelled.
The user is atte.pting to cancel or
overlay a non-existent SCB.
o
r-----------------,
4
t---
.,
lexit address
I
8
1-------"'------------\
CHKPT-SVC 63:
DMSSVT:-----
CHKPT
is
is
a
a
NOP
NOP
located
in
located
in
RDJFCB-SVC 64: This routine (RDJFCB)
receives
control--;hen a RDJFCB macro instruction is
issuedw When it gets control, RDJPCB obtains
the address of the JFCB from the DCBEXLST field
in the DCB and sets the JFCB to zero. It then
reads the simulated JPCB located in CftSCB that
was produced by issuing a FILEDEP into the
closed area.
RDJFCB calls the STATE function
program to determine if the associated file
exists.
If it does, RDJFCB returns to the
calling program.
If the file does not exist,
202
~I!!R=~!£_§~:
Located in DMSSVT, SYNAD attempts
to simulate the functions SYRADAF and SYRADRLS.
SYNADAF expansion includes an SVC 68 and a
high-order byte in register 15 denoting an
access method. SYNAD prepares an error message
line, swap save areas and register 13 pointers.
The message buffer is 120 bytes:
bytes 1-50,
84-119 blank; bytes 51-120,
1205 INPUT/OUTPUT
ERROR nnn OR FILE: "dsna.e";
where nnn is the
CftS RDBUF/WRBUF error code.
All the options of
SYRAD are supported.
SYNADRLS expansion includes SVC 68 and a high
order byte of X'FF' in register 15.
The save
area is returned, and the message buffer is
returned to free storage.
BACKSPACE-SVC 69: Also in DftSSVT.
For a tape,
i--BSi-coiiana--is issued to the tape.
Por a
direct access data set, the CftS write and read
pointers are decremented by one. Control is
passed to BACKSPACE in DftSSVT when a BACKSPACE
macro is issued. BACKSPACE decrements the read
write pointer by one and returns control to the
user. No physical tape or disk adjustments are
made until the next READ or WRITE macro is
issued.
All the options
of BACKSPACE are
supported.
!§I!L!RQ!=§!£_~]:
Located
in DftSSVN,
this
routine receives control when a TGET or TPUT
macro is issued.
It is provided to support TSO
service routines needed by program products.
TGET reads a terminal line; TPUT writes a
ter.inal line. The return code is zero if the
operation was successful and a four if an error
was encountered.
TCLEARQ is located in DftSSVN
and causes the terminal input queue to be
cleared via a call to DESBUF. At completion a
return is made to the user.
Iparameter list address
I
____ .J
12 '
DETACH
Rote: The switch set by the RDJFCB is tested by
the FORTRAI object-time direct-access handler
(DIOCS) to determine ~hether or not a referenced
disk file exists.
If
it does not, DIOCS
initializes the direct access file.
J£LI!~2=§1£_2!:
10 or pointer to next SCBI
DETACH-SVC 62:
DMSSVT:------
BDJFCB sets a switch in the DCB to indicate this
and then returns to the calling program. RDJFCB
is located in DftSSVT. All the options of RDJFCB
are supported.
~J!X=§l£_~§:
Located in DKSSVT, STAX gets and
chains a CMSTAXE control block for each STAX SVC
issued with an exit routine address specified.
The chain is anchored by TAXEADDR in DMSNUC. If
no exit address is specified the most recently
added CftSTAXE is cleared from the chain. If an
error occurs during STAX SVC processing, a
return code of eight is placed in register 15.
The only option of STAX which may be specified
is 'EXIT ADDRESS'.
Sn;!LR!!! :
descr iption.
]IJ~L!]!!J:
See
the
DlISSQS
prolog
for
OS RBAD and WRITE macros branch and
link to DMSSBS. DMSSBS branches and links to
DftSSEB and, if the disks is an OS disk, DMSSEB
branches and link to DMSROS.
See DMSSBS for
description.
IBM Vft/310: System Logic and Problem Deter.ination Guide
!QI~LRQ!!!L~!!~l!IE~_fl:
os NOTE, POINT, and
FIND (type c) macros branch and link to entry
points in DMSSCT. If the disk is an as disk,
DMSSCT branches and links to DMSROS. See DMSSCT
for descriptions.
f~~£!:
See the DftSSCT prolog for description.
Notes on using the as simulation routines:
•
CftS files are physically blocked in 800-byte
blocks, and logically blocked according to a
logical record length.
If the fi1emode of
the file is not 4, the logical record length
is equal to the DCBLRECL and the file must
always be referenced with the same DCBLRECL,
whether or not the file is blocked.
If the
fi1emode of the file is 4, the logical record
length is equal to the DCBBLKSI and the file
must always be referenced with the same
DCBBLKSI.
•
When writing CftS files with a fi1emode number
other than four, the as simulation routines
deblock the output and write it on a disk in
unblocked records.
The simulation routines
delete each 4-byte block descriptor word
(BDW) and each 4-byte record descriptor word
(RDW) of variable length records.
This makes
the
OS-created
files
compatible
with
CMS-created files and CMS utilities.
When
CMS reads a CftS file with a fi1emode number
other than four, CftS blocks the record input
as specifies and restores the BDW and RDW
control words of variable length records.
If the CftS fi1emode number is four, CMS does
not unblock or delete BDWs or RDWs on output.
CMS assumes on input that the file is blocked
as specified and that variable length records
contain block descriptor words and record
descriptor words.
•
•
To set the READ/WRITE pointers for a file at
the end of the file, a FILEDEF command must
be issued for the file specifying the ftOD
option.
A file is erased and a new one created if the
file is
opened and
all the
following
conditions exist:
The OUTPUT or
specified.
OUTIN
option
of OPEN
is
The TYPE option of OPEN is not J.
The dataset organization option of the DCB
is not direct access or partitioned.
A FILEDEF command has not been issued for
data set specifying the ftOD option.
•
The results are unpredictable if two DCBs
read and write to the same data set at the
same time.
ACCESS COftftAID 11Q!: The module DftSACC gets
control -fIrst- when you invoke
the ACCESS
com.and.
DMSACC
verifies
parameter
list
validity and sets the necessary internal flags
for later use. If the disk you access specifies
a target
mode of
another disk
currently
accessed, DMSACC calls DftSALU to clear all
pertinent information in the old active disk
table. DMSACC then calls DMSACF to bring in the
user file directory of the disk.
As soon as
DMSACF gets control, DMSACF calls DMSACM to read
in the master file directory of the disk.
Once
DMSACM reads
the label of the
disk, and
determines that it is an OS disk, DMSACM calls
DMSROS (ROSACC) to complete the access of the OS
disk.
Upen
returning from
DMSROS,
DMSACM
returns immediately to DMSACF,
bypassing the
master file directory logic for CMS disks.
DftSACF then checks to determine if the accessed
disk is an OS disk.
If it is an OS disk, DMSACF
returns immediately to DMSACC, bypassing all the
user file directory logic for OS disks. DMSACC
checks to determine if the accessed disk is an
OS disk; if it is, another check determines if
the accessed disk replaces another disk to issue
an information message to that effect. Another
check determines if you specified any options or
fi1eid and, if you did,
a warning message
appears on the terminal. Control now returns to
the calling routine.
~!11~11 £Q~~!!~
FLQ]: DMSFLD gets control first
when you issue a CMS FILEDEF command. DMSFLD
adds, changes, or deletes a FILEDEF control
block (CMSCB) and returns control to the calling
routine.
LISTDS COMMAND l~Qj: The module DMSLDS gets
control -fIrst- when you invoke
the LISTDS
command.
DMSLDS
verifies
parameter
list
validity and calls module DMSLAD to get the
active disk table associated with the specified
mode.
DMSLDS reads all format 1 DSCB and if you
specified the PDS option and the data set is
partitioned, DMSLDS calls DKSROS (ROSFIND)
to
get the
members of the data
set.
After
displaying the DSCB (or DSCB) on you console,
DMSLDS returns to"the calling routine.
~Q!JIILJ £~AAA!~
l~Qj: The
module DftSMVE gets
control first when you issue a CftS ftOVEFILE
command. DMSMVE calls DMSFLD to get an input
and output CMSCB and, if the input DftSCB is for
a disk file, DMSMVE calls DMSSTT to verify the
existence of the input file and get default DCB
parameters in absence of CMSCB DCB parameters.
DMSMVE uses OS OPEN, FIND, GET, PUT, and CLOSE
macros to move data from the input file to the
output file.
After moving the specified data,
control returns to the calling routine.
~~I~!
gQ~~J!]
ILO!: The module DMSQRY gets
control first
when you
invoke the
QUERY
co.mand."
DMSQRY
verifies
parameter
list
validity and calls DMSLAD to get the active disk
table associated
with the
specified .ode.
DMSQRY displays all the information that you
requested
on
your console.
When
DMSQRY
finishes,
control returns
to the
calling
routine.
RELEASE COMMAND FLOW: The module DMSARE gets
control fIrst--when- you
invoke the RELEASE
command.
DMSARE
verifies
parameter
list
validity and checks to determine if the disk you
want to release is accessed.
If the disk you
want to release is currently active, DMSARE
calls DMSALU to clear all pertinent information
section 2. Method of Operation and Program organization
203
associated with the active disk.
DMSALU first
checks the active disk table for any existing
CftS tables kept in free storage. If the disk
you want to release is an as disk, DMSALU does
not find any tables associated with a CMS disk.
If the disk is an as disk, DMSALU releases the
as FST blocks (if any) and clears any as FST
pointers in the as file control blocks. DMSALU
then clears the active disk table and returns to
DftSARE.
DMSARE then clears the device table
address for the specified disk and returns to
the calling routine.
STATE COMMAND I~Q!: The module DMSSTT gets
control--first
when you
invoke the
STATE
command.
DMSSTT verifies the parameter list
validity and calls module DMSLAD to get the
active disk table associated with the specified
mode.
Upon return from DMSLAD, DMSSTT calls
DMSLFS to find the file status table
(FST)
associated with the file you specified.
Once
DMSLFS finds the associated FST, it checks to
determine if the file resides on an as disk.
If
it does, DKSLPS calls DMSROS (ROSSTT)
to read
the extents of the data set. Upon return from
DMSROS, DMSLPS returns to DMSSTT.
DMSSTT then
copies the PST (or OS FST)
to the FST copy in
statefst and returns to the calling routine.
DKSACC MODULE: Once Df:lS ACC determines that the
disk--you--want to access is an as disk,
it
bypasses the routines that perform 'LOGIN UFD'
and 'LOGIN ERASE'.
If the disk you want to access replaces
disk,
message DMSACC7241
appears at
terminal.
an as
your
If you specified any options or fileid in the
ACCESS command to an as disk, a warning message,
DKSACC230W, appears to notify you that such
options or fileid were ignored. DKSACC returns
to the calling routine with a warning code of
4.
Y~~!£l
MODULE: DKSACF verifies that the disk you
want to--access is an as disk and, if it is,
exits immediately.
DKSACK KODULE: DKSACK saves the disk label and
VToc-address-in the ADT block if the disk is an
as disk.
DMSACK checks to determine if a
previous access to an as disk loaded DMSROS.
If
not, DKSACK calls DKSSTT to verify that DMSROS
text exists.
Upon successful return froa STATE,
DKSACK loads DMSROS text into the high storage
area with the same protect key and calls the as
access routine
(ROSACC) of DMSROS to read the
format 4 DSCB of the disk. Upon successful
return from DMSROS, control returns to the
callin,g routine.
Any other errors are treated
as general logon errors.
If the disk is an as disk,
the as FST blocks (if any) to
free storage.
DMSALU clears the as FST pOinter
in all active as file control blocks, decrements
the DMSROS usage count and, if the usage count
is zero, clears the address of DKSROS in the
nucleus area.
DMSALU also calls DKSFRET to
returns to
occupies.
free storage
which DMSROS
DMSARE KODULE: DKSARE ensures that the disk you
want--to-relase is an as disk.
DKSARE calls
DKSALU to release alIOS FST blocks and, if
necessary, to free the area DMSROS occupies.
Upon return from DKSALU, DKSARE clears the
common CMS and as active disk table.
•
DSN
If you specify the parameter DSN as
'1', FILEDEF displays the message DKSFLD220R
to request you to type in an as data set name
with the format Q1.Q2.QN. Q1, Q2, and QN are
the qualifiers of an as data set name. If
you specify the parameter DSN as Q1.Q2.QN,
FILEDEF assumes that Q1, Q2, and QN are the
qualifiers of an as data set name, and stores
the qualifiers with the format Q1.Q2.QN in a
free storage block and chains the block to
the FCB.
•
CONCAT -- If you specify the CONCAT option,
FILEDEF assumes that the specified FILEDEF is
unique unless a filedef is outstanding with a
matching ddname, filename,
and filetype.
This allows you to specify more than one
FILEDEF for a particular ddname. The CONCAT
option also sets the FCBCATKL bit in the FCB
to allow the as simulation routine to know
the FCB is for a concatenated MACLIB.
•
KEKBER -- If you specify the member option,
filedef stores the member name in FCBKEKBR in
the FCB to indicate that the as simUlation
routine should set the read/write pointer to
point to the specified BPAK file member when
OPEN occurs.
DKSLDS MODULE: DMSLDS saves the return register,
sets--itselj-with the nucleus protection key,
clears the dsname key, and initializes its
internal flag.
DMSLDS verifies parameter list validity. The
data set name must not exceed 44 characters, and
the disk mode
(the last parameter before the
options)
must be valid.
DMSLDS joins the
quailifiers with dots (.) to for. valid data set
names. If you specify the data set name as a
question mark
(1), DKSLDS prompts you to enter
the dsname in exactly the same form as the
dsname which appears on the disk.
DKSLDS calls DKSLAD to find the active disk
table block.
If you specify filemode as an
asterisk
(*), DKSLAD searches
for all ADT
blocks.
If
you specify
the filemode
as
alphabetic, DKSLAD finds only the ADT block for
the specified filemode.
If
you specify
the
dsname
(which
is
optional), DKSLDS sets the channel programs to
read by key.
If you did not specify a dsname,
DKSLDS searches the whole VTOC for format 1
DSCBS and displays all the requested information
contained in the DSCB on your console.
If you
specify the format option, the RECFK,
LHECL,
BLKSI, DSORG,
DATE, LABEL, FKODE, and data set
naae appear on you console; otherwise, only the
FKODE and data set naae appear.
DMSALU
~QYY11:
204
IBM VK/370: system Logic and Problem Determination Guide
D~SFRET returns
the area
If you specify the PDS option, DKSLDS calls
the 'find'
routine (rosfind) in DKSROS to read
the .ember directory and pass back, one at a
time, in the fcbmembr field of CKSCB the name of
each member of the data set. This occurs if the
data set is partitioned.
to an OS disk. The ROSSTT routine searches
for the correct FCB which a previous FILEDEF
associated with the data set.
If the DOS
environ.ent is active, ROSSTT locates the
correct DOSCB
that defines a
data set
described by a previous DLBL.
If ROSSTT
finds an active FST,
control p~sses to
ROSSTRET; otherwise, ROSSTT
acqu1res the
dsname block, places its address in the FCB,
and moves the dsname in the FCB to the
acquired block.
ROSSTT
acquires an FST
block, chains it to the FST chain, and fills
all general fields (dsname, disk address, and
disk mode).
BOSSTT now reads the for.at 1
DSCB for
the data set and
checks for
unsupported options (BDAM, ISAM, VSAM, and
read protect).
After processing finishes, DKSLDS resets the
nucleus key to the same value as the user key,
puts the return code in register 15, and returns
to the calling routine.
~QQY~~:
DKSLFS verifies that the PST
searched for has an OS disk associated
with it. DKSLFS calls the DKSROS state routine
(ROSSTT) to verify that the data set exists and
CKS supports the data set attributes.
Upon
return from
DKSROS, a return code
of 88
indicates that the data set was not found, and
DKSLDS starts the search again using the next
disk in sequence.
Any other errors, such as a
return
code
80,
cause
DKSLFS
to
exit
i.mediately.
A return code of 0 from DKSROS
indicates that the data set is on the specified
disk.
From this point on, execution occurs
co.mon to both CKS and OS disks.
DKSLFS
being-
Errors pass control back to the calling
routine with an error code. ROSSTT groups
together all the extents of the data set (by
reading the for.at 3 DSCB if necessary) and
checks them for validity.
ROSSTT bypasses
any user labels that .ay exist and displays a
message to that effect.
Next, ROSSTT moves
the
DSCB1
BLKSIZE,
LRECL,
and
RECFM
parameters to the OS FST and passes control
to rosstret.
Q~§~!~ ~~QY1~:
If you specify the PDS option and
the input 1S from a disk,
DKSKVE sets the
FCBKVPDS bit and issues an OS FIND macro before
opening an output DCB to position the input file
at the next member.
DKSKVE then stores the
input member name in the output CMSCB for use as
the output filename. After reaching end-of-file
on a member, the message DMSMVE2251 appears,
DMSKVE closes the output DCB, and passes control
to find the next member.
After moving all the
members to separate CMS files, movefile displays
message DKSMVE226I, closes the input and output
DCBS, and
returns control to
the calling
routine.
•
•
ROSACC Routine -- ROSACC gets contr.ol from
DMSACM after DMSACM determines that the label
of the disk belongs to an OS disk.
The
ROSACC routine reads the format 4 DSCB of the
disk to further verify the validity of the OS
disk. ROSACC updates the ADT to contain the
address of the high extent of the VTOC (if
the disk is a DOS disk) or the address of the
last active format 1 DSCB
(if the disk is an
OS disk), and the number of cylinders in the
disk. If the disk is a DOS disk, ROSACC sets
a flag in the ADT.
Information messages
appear to notify you that the disk was
accessed in read-only mode.
If the disk is
already accessed as another disk, another
information message appears to that effect.
Finally ROSACC zeroes out the ADTFLGl flag in
the ADT, sets the ADRFLG2 flag to reflect
that an OS disk was accessed, and returns
control to the calling routine.
ROSSTT Routine -- Verifies the existence of
an OS data set and verifies the support of
the data set attributes.
Note: Within the ROSSTT description, any
reference to FCB or CMSCB i.plies a DOSCB if
DOS is active.
ROSSTT gets control from DMSSTT after
DMSSTT determines that the STATE operation is
•
ROSSTRET Routine -- If the disk is not a DOS
disk, rosstret passes control back to the
caller. If the specified disk is a DOS disk,
rosstret fills in the OS FST BLKSIZE, LRECL,
and RECFM fields that were not specified in
the DSCB1. If the CMSCB fields are zero,
rosstret defaults the.
to BLKSIZE=32760,
LRECL=32670, and
RECFM=U.
Control
then
returns to the calling routine.
•
ROSRPS Routine
ROSRPS reads the next
record of an OS data set. Upon entry to the
ROSRPS entry point, ROSRPS calls CHKITNT and,
if the current CCHHR is zero, SETITNT to
ensure the CCHHR and extent boundaries are
correctly set.
ROSRPS then calls DISKIO
and, if necessary, CHKSENSE and GETALT to
read the next record. If no errors exist or
an unrecoverable error
occurred, control
returns to the user with either a zero (I/O
OK) or an 80 (I/O error) in register 15. If
an unrecoverable error occurs, ROSRPS updates
the CCWS and buffer pointers as necessary and
recalls CHKITNT and DISKIO to read the next
record.
•
ROSFIND Routine -- ROSFIND sets the CCHHR to
point to a member specified in FCBMEMBR or,
if the FCBMVPDS bit is on, sets the CCHHR to
point to the next member higher than FCBHEMBR
and sets a new member name in FCBMEMBR.
Upon entry at the ROSFND entry point, ROSFND
sets up a CCW to search for a higher member
name if the FCBMVPDS bit is on, or an equal
member name if the FCBMVPDS bit is off. It
then calls SETITNT, DISKIO and, if needed,
CHKSENSE and GETALT to read in the directory
block
that
contains
the
member
name
requested. After reading the block, it is
searched for the requested member name. If
the member name is not found, an error code 4
returns to the calling routine. If an I/O
error occurs while trying to read the PDS
block, an error code 8 returns to the calling
routine.
If the member
name is found,
section 2. Method of Operation and Program Organization
205
TTRCRVRT is called to convert the relative
track address to a CCBB and pass the address
of the member entry to the calling routine.
•
ROSNTPTB Routine -- ROSRTPTB gets the current
TTR, sets the current CCBBR to the value of
the TTR, and backspaces to the previous
record.
Upon entry at the ROSNTPTB entry point,
ROSNTPTB checks to determine if a NOTE,
POINT, or BSP operation was requested.
If register 0 is zero, ROTE is assumed. The
note routine calls CBRCNVRT to convert the
CCBB to a relative track and returns control
to the calling routine with the TTR in
register O.
If register 0 is positive upon entry into
DMSROS, POINT is assumed and ROSRTPTB loads a
TTR from the address in register 0 and calls
TTRCNVRT and SETXTNT to convert the TTR to a
CCRRR. Then control returns to the calling
routine.
If register 0 is negative upon entry into
DMSROS, BSP
(BACKSPACE)
is assumed.
The
backspace code checks to determine if the
current position is the beginning of a track.
If not, the backspace code decrements the
record number by one and control then returns
to the calling routine.
If the current
position is the beginning of a track, the
backspace code calls CBRCRVRT to get the
current CCBB. The backspace code then calls
rdcnt to get the current record number of the
last record on the new track, calls setxtnt
to set the new extent boundaries, and returns
control to the calling routine.
•
HOTE Routine -- Upon entry to note, DMSSCT
checks to determine if the DCB refers to an
OS disk. If it does, DMSSCT calls DMSROS
(ROSHTPTB) to get the current TTR. Control
then returns to the user.
•
POINT Routine -- upon entry to point, DMSSCT
checks to determine if the DCB refers to an
os disk. If it does, DMSSCT calls DMSROS
(ROSNTPTB) to reset the current TTR, calls
CKCOHCAT and returns control to the calling
routine.
•
CKCONCAT Routine -- Upon entry to CKCONCAT,
DMSSCT checks to determine if the PCB MACLIB
COHCAT bit is on. If it is on, DCBRELAD+3
sets the correct os PST pointer in the PCB
and returns control to the calling routine.
If the PCB M~CLIB COHCAT bit is off, control
returns to the calling routine.
•
•
206
PIHD (type_C) Routine -- If the DCB refers to
an OS disk, DMSSCT calls DMSROS (ROSNTPTB) to
update the TTR and control returns to the
calling routine.
BOBROUTR Routine -- If the PCB OS bit is on,
control passes to OSBEID. Otherwise, if no
special I/O routine is specified in PCBPBOC,
control passes to BOB2 in DMSSEB.
•
OSREAD Routine
DMSSEB calls DMSROS to
perform a read or write and then control
passes to EOBRETRN which, in turn,
passes
control back
to DMSSBS.
DMSSBS passes
control back to the routine calling the read
or write macro operation.
~~~~g~ ~Q~~~~ -- If the
MICLIB CONCAT option is
on in the CMSCB. OPEN checks the MICLIB names ion
the global list and fills in the addresses of OS
FSTS for any MACLIBS on OS disks. The CMSCB of
the first MACLIB in the global list merges and
initializes CMSCBS.
If the CMSCB refers to a data set on an OS disk,
DMSSOP checks to ensure that the data set is
accessible and the DCB does not specify output,
BDAM, or a key length. If any errors occur,
error message DMSSOp036E appears and DMSSOP does
not open the DCB. DMSSOP fills them in from the
OS PST for the data set.
If the CMSCB fcbmembr field contains a member
name (filled in by FILEDEP with the member
option), DMSSOP issues an OS PIND macro to
position the file pointer to the correct member.
If an error occurs on the call to the FIND
macro, error message DMSSOP036E appears and
DMSSOP does not open the DCB.
•
BSP
(backspace)
Routine
Upon entry,
backspace checks for the PCB os bit.
If it
is
on, the
BSP
routine calls
DMSROS
(ROSNTPT~ to
backspace the TTR and control
returns to the calling routine.
•
PIID (type_D) Routine -- Upon entry to find,
the find routine checks the PCB OS bit. If
it is on, the FIND routine takes the OS FST
address from the CMSCB or, if the CONCAT bit
is on, from the global MACLIB list. The PIND
routine then calls DMSROS (ROSFIND)
to find
the member name and TTR. DMSROS searches for
a matching member name or, if the PCBMVPDS
option is specified, a higher member name.
If the DMSROS return code is 0 or 8, or if
the PCBCATML bit is not on, control returns
to the calling routine with the return code
from DMSROS.
If the return code is 4 and the
PCBCATML bit
is on,
DMSSVT checks
to
determine if all the global MACLIBS were
searched. If they were, control returns to
the calling routine with the DMSROS return
code. If they were not, DMSSVT issues the
PIND on the next MACLIB in the global list.
•
BLDL Routine--BLDL list
DATA
=
PP
LL NAME TTR KZC
If the DCB refers to an OS disk, the BLDL
routine fills in the TTR, C-byte and data
field from the os data set.
•
SEARCB Routine -- The search routine ensures
that any OS disk currently active is included
in the search order of all disks currently
accessible.
•
DISK Routine -- The disk routine displays the
status of any or alIOS disks using the
following form:
IBM VM/370: system Logic and Problem Determination Guide
'MODB(CUU):
(HO. CYLS.), TYPB R/O - OS.'
DMSSTT MODULB -- DMSSTT verifies that the disk
being- searched is an OS disk. DMSSTT calls
DMSLFS to get the FST associated with the data
set. Upon return from DMSLFS, DMSSTT checks the
return code to ensure that CMS supports the data
set attributes. A return code of 81 or 82
indicates that CMS does not support the data set
and message DMSSTT229B occurs to that effect.
DMSSTT then clears the FST copy with binary
zeros,
and moves
the filename,
fi1etype,
fi1emode, BLKSIZE, LRECL, RBCFM, and flag byte
to the FST copy.
From this point on, com. on
code execution occurs for both CMS and OS
disks.
procedures from the procedure library
(via the
PSBRV co.mand)
or
displaying the procedure
library (via the DSERV co •• and) •
CMS/DOS does
cylinder.
IHITIALIZIHG DOS
CONTROL COMMAHDS
not support the
IHD
standard label
PROCESSING
DOS
SYSTEM
Initialization
of
the
CMS/DOS
operating
environment requires the setting of flags and
the creation of certain data areas in storage.
Once initialized, these flags and data areas may
then be changed by routipes invoked by the
system control commands.
Five modules are described in this section:
•
CHRCHVRT Routine
The CHRHCVRT routine
converts a CCHH address to a relative track
address.
•
DMSSET Activates
the CMS/DOS
control blocks to
be
CMS/DOS processing.
•
CHKSEHSE Routine -- CHKSEHSE checks sense
bits to determine the recoverabi1ity of a
unit check error if one occurs.
•
DMSOPT sets or resets compiler execution-time
options.
•
•
CHKXTHT
Routine
CHKXTHT
checks
to
determine if the end of split cylinder or the
end of extent occurred~ and, if so, updates
to the next split cylinder or extent.
DMSASH Relates
units.
•
•
•
DISKIO Routine -- DISKIO starts I/O operation
on a CCW string via a DIAGHOSB X'20'.
•
GETALT Routine -- GETALT switches reading
from alternate track to prime track, and from
prime track to alternate track.
•
•
RDCHT Routine -- RDCHT reads count fields on
the track to determine the last record number
on the track.
SETXTNT Routine -- SETXTNT sets osfstend to
the value of the end of the extent and, if a
new extent is specified, sets CCHHR to the
value of the start of the extent.
SIMULATIHG A DOS EHVIROHMENT UHDER CMS
CMS/DOS is a functional enhancement to CMS that
provides DOS installations with the interactive
capabilities of
a VM/370
virtual machine.
CMS/DOS
operates
as
the
background
DOS
partition;
the other
four partitions
are
unnecessary, since the CMS/DOS virtual machine
is a one-user machine.
CMS/DOS provides read access to real DOS data
sets, but not write or update access. Real DOS
private
and
system
relocatable,
source
statement, and core-image libraries can be read.
This read capability is supported to the extent
required to support the CMS/DOS linkage editor,
the DOS/PLI and DOS/VS COBOL compilers, the
FETCH routine, and the RSERV, SSERV, and ESERV
commands. Ho read or write capability exists for
the DOS procedure library, except for copying
logical
to
physical
DMSLLU Lists the
assignments
physical units.
of
CMS/DOS
DMSDLB Associates a DTF with a
for CMS/DOS processing.
logical unit
~~~~~I--!Bi!i~li~iDg
~D~i~~B~B!
units
environment
used during
!h~
DMSSET
initializes
the
environment as follows:
CMS/DOS
operating
•
Verifies that the mode,
a DOS formatted disk.
if specified, is for
•
Stores appropriate data in the SYSRES LUB and
PUB.
•
Locates and loads the CMS/DOS discontiguous
shared
segment.
Saves
(in HUCON)
the
addresses of the two major CMS/DOS data
blocks, SYSCOM, BGCOM,and the address of the
CMS/DOS
discontiguous
shared
segment
(CMSDOS) •
•
Sets the DOSMODE and
in NUCON.
•
Assigns (via ISSGB) the SYSLOG
as the CMS virtual console.
DOSSVC bits in DOSFLAGS
logical unit
The CMS/DOS operating environment is entered
when the CMS SET DOS ON command is issued,
invoking the module DMSSET.
section 2. Method of Operation and Program Organization
207
Data
Areas
Prepared
Initialization
for
Processing
During
CBS/~
Several data areas are
prepared for processing
during initialization. The main CMS data area,
NUCON, is modified to contain the addresses of
two DOS data areas, SYSCOM and BGCOM.
The
SYSCOM
DSECT is
the
DOS
system
communications region. It consists mainly of
address constants, including the addresses of
the AB option table, the PUB ownership table,
and the FETCH table.
It also includes such
information as the number of partitions (always
one for CMS/DOS) and the length of the PUB
table.
The
BGCOM
DSECT
is
the
partition
communication
region.
It
includes
such
information as the date, the location of the end
of supervisor storage, the end address
of the
last phase loaded, the end address of the
longest phase loaded,
bytes used to set the
language translator and supervisor options, and
the addresses of many other DOS data areas such
as the LUB,
PUB, NICL, FICL, PIB, PIB2TAB, and
the PCTAB.
The LUB
and PUB tables are
also made
available during initialization. The LUB is the
logical unit block table.
It acts as an
interface between the user's program and the
CMS/DOS physical units. It contains an entry
for each symbolic device
available in the
system.
Each of the symbolic names in the LUB is
mapped into an element in the PUB, the physical
unit block table.
The PUB table contains an
entry for each channel and device address for
all devices physically available to the system
and also contains such information as device
type code, CMS disk mode, tape mode setting, and
7-track indicator.
Two bits are set in DOSFLAGS in NUCON,
DOSMODE and DOSSVC. DOSMODE specifies that this
virtual machine is running
in the CMS/DOS
operating environment. DOSSVC indicates whether
OS or DOS SVCs are operative in the operating
environment.
If DOSSVC is set, DOS SVCs are
used; otherwise, OS SVCs are operative.
SETTING OR RESETTING SYSTEM ENVIRONMENT OPTIONS
Once the CMS/DOS environment is initialized, the
flags
and
control
blocks
set
during
initialization can be modified and manipulated
to perform the functions specified by commands
entered at the console.
This section describes
the modules that set and reset the system
environment options.
That is, they set those
options that control compiler execution and that
control
the configuration
of logical
and
physical units in the system.
208
The CMS/DOS
OPTION command
invokes module
DMSOPT, which sets either the default options
for the compiler or the options specified on the
command
line.
The
nonstandard
language
translator options switch and the job duration
indicator byte are altered.
Options are set
using two control words located in the partition
communication region
(DGCOM). Bits in bytes
JCSW3 or JCSW4 are set, depending on the options
specified.
Module DMSASN is invoked when the ASSGN command
is entered. DMSASN first scanS the command line
to ensure that the logical unit being assigned
is valid for the physical unit specified (for
example, SYSLOG must be assigned to either the
virtual console or the vi~tual printer). Once
the command line is checked, PUB and LUB entries
are
modified
to
reflect
the
specified
assignment.
For the PUB entry,
the device type is
determined
(via DIAG 24) and the device type
code is placed in the PUB. other modifications
are made to the PUB depending on the specified
assignment. The LUB entry is then mapped to its
corresponding PUB.
The function of DMSLLU is to request a list of
the physical units assigned to logical units.
It
performs this
function by
referencing
information located in the CMS/DOS data blocks,
specifically SYSCOM, LUB, and PUB. Another data
block, the next in class (NICL) table is also
referenced.
The information on the
command line is
scanned and the appropriate items are displayed
at the user's console. If an option
(EXEC or
APPEND) is specified, an EXEC file is created
($LISTIO EXEC Al) to contain. the output.
If
EXEC is specified, any existing $LISTIO EXEC Al
file is erased and a new one is created.
If
APPEND is specified, the new file is appended to
the existing file.
DMSDLB is invoked when the CMS/DOS DLBL command
is entered. DMSDLB associates a DTF (Define The
File) table filename with a logical unit. This
function is performed by creating a control
block called a DOSCB, which contains information
defining a DOS file used during job execution.
DLBL is valid only for sequential or VSAM disk
devices.
IBM VM/370: System Logic and Problem Determination Guide
This
information
parallels
the
label
information written on a real DOS SIs RES unit
under
DOS/VS.
The
DOSCB
contains
such
information as the name, type, and .ode of the
referenced dataset, its device type code, its
logical unit specification, and its dataset type
(SA" or VSA").
A DOSCB is created for each file specified by
the user during a terminal session. The DOSCBs
are chained to each other and are anchored in
NOCON at the field DOSFIRST. The chain remains
intact for the entire session, unless an ABEND
occurs or the user specifically clears an entry
in the the DOSCB chain.
A given DOSCS is
accessed when an OPEN macro is issued from an
executing user program.
The overall
follows:
logic
flow for
DMSDLB
is
as
1.
Scans the command line to ensure that any
options entered are valid (i.e.
anything
to the right of the open parenthesis).
2.
Processes the first operand
(ddname or *).
When ddname is specified, loop through the
DOSCB chain to find a matching ddname. If
none is found, DMSDLB calls DMSFRE to get
storage to create a new DOSCB for this
file.
The old copy of the DOSCB is then
saved so that, in case of errors during
processing, it can be retrieved intact.
The new copy of the DOSCB contains updates
and DOSCB replaces the old copy if there
are no errors.
3.
The mode specification is checked to ensure
that it is a valid mode letter; if the file
is a CMS file, the mode letter must specify
a CMS disk.
If DSN has been specified, the
mode letter must be for a non-CMS disk.
4.
Process each option
appropriately.
5.
If EXTENT or MULT is specified, a separate
block of free storage
is obtained to
contain information about the extent, for
example, a block is obtained to contain the
DOS data set name.
5.
on
the command
the type of DTP specified, i.e. the table
generated by a unit record DTF macro is slightly
different than the table generated by a DTl disk
.acro.
live routines are invoked to perform OPEN
functions, DMSOPL, DMSOR1, DMSOR2,
D"SOR3, and
D"SBOP. DMSCLS performs the CLOSE function.
Depending on the type of OPEN macro issued from
a user program, one
of five CMS/DOS OPEN
routines could be invoked.
OPENR macros give
control to D"SOR1 and, depending on the DTl type
specified, DMSOR2 or DMSOR3 may be invoked.
These three routines (DMSOR1,DMSOR2, and DMSOR3)
request the relocation of a specified file.
D"SOPL is invoked by the DOS/VS compilers when
they need access to a source state.ent library.
These routines are mainly interface routines to
D"SBOP,
which performs the main function of
opening the
specified file.
Each
of the
routines calls DMSBOP.
D"SBOP is the C"S/DOS routine that simulates
the DOS/VS OPEN function. The basic function of
D"SBOP is the initialization of DTF tables, i.e.
setting fields in specified DTFs for use by the
DOS/VS LIOCS routines.
When a DOS problem program is compiling, a
list of DTFs and ACBs is built.
At execution
time, this list is passed to DMSBOP. The logic
flow of D"SBOP is as follows:
1.
Scans the list of DTF and ACB addresses,
handling each iteam in the list in line.
When the OPEN macro expands, register
points to the name of the $$B transient to
receive control ($$BOPEN)
and register 0
points to the list of DTF/ACB addresses to
be opened.
2.
When an ACB is encountered in the table,
control is passed directly to the VSA" OPEN
routine, $$BOVSAM.
The VSAM routine is
responsible for
opening the
file and
returning control to DMSBOP.
3.
When a DTF is encountered in the
DMSBOP itself handles the OPEN:
line
Check for errors.
If there are errors, any
blocks created during processing are purged
and an error message is issued.
If there
are no errors, restore the old block, which
has been
modified to
reflect current
processing, and return control to DMSITS.
PROCESS C"S/DOS OPEN AND CLOSH FUNCTIONS
The CMS/DOS
OPEN routines are
invoked in
response to DOS OPEN macros. They operate on
DTF
(define the file) tables and ACB
(access
method control block) tables created when the
DTFxx and
ACB macros are issued
fro~
an
executing user program. These tables contain
information such as the LOG unit specification
for the file, the DTF type of the file, the
device code for the file,
and so forth.
The
information in the tables varies depending on
table,
a.
For reader/punch files
(DTFCD), the
OPEN bit in the DTF table is turned
on.
b.
For printer files
(DTFPR), if two
IOAREAs are specified, the IOREG is
loaded
with
the address
of
th~
appropriate IOAREA.
Next,
the PUB
index byte associated with the logical
unit specified in the DTF is checked to
ensure that a physical device has been
assigned and the PUB device code is
then analyzed. The OPEN bit in the DTF
table is then turned on.
c.
For console files
logic is required.
(DTFeN),
no
section 2. Method of Operation and Program Organization
OPEN
209
d.
e.
f.
4.
5.
For tape files (DTFMT), the PUB device
type code must specify TAPE. If an
IOREG is specified
(for output tapes
only), the address of the appropriate
IOAREA is placed in it.
For input
files, there is separate processing for
tapes with standard label, nonstandard
label, and no label. For output tapes,
both tape data files and work tape
files are treated as no label tapes.
For disk files (DTFxx), the LUB is
verified to ensure that the logical
unit has been assigned.
A check is
made to ensure that the DOSCB exists
for the DTF filename.
For disk output
files, the address of the appropriate
IOAREA is placed in IOREG. For disk
~nput files, the existence
of the file
1S verified via a call to DMSSST.
Also, EXTENT information is initialized
and the OPEN bit is posted.
DTFDT and DTFCP are separate DTF types
that could describe any of the above
devices.
After all files in the table have been
opened, DMSBOP returns
control to the
problem program via SVC 11.
If errors are encountered during DMSBOP
processing, an error message is issued and
return is .ade via SVC 6.
The
CMS/DOS routine
that processes
CLOSE
requests is DMSCLS, whose logic is analogous to
that of DMSBOP, the OPEN
routine described
above: when CLOSE expands, register 1 pOints to
$BCLOSE and register 0 points to the list of
DTF/ACB addresses. The same table containing
DTFs and ACBS used to open files is also used to
close those files.
Each entry in the table is
processed as it occurs, with control passing to
a VSAM CLOSE routine ($$BCVSAM) when an ACB is
encountered. The OPEN bit is then turned off.
PROCESS
COMMANDS
CMS/DOS
EXECUTION-RELATED
CONTROL
The DOS/VS FETCH function is simulated by eMS
modules DMSFET and DMSFCH. The main control
block used during a FETCH operation is FCHSECT,
which contains addressing information required
for I/O operations.
The
FETCH command
line invokes
module
DMSFET. This module first validates the command
line and issues a FILEDEF for the DOSLIB file.
It then issues a FILEDEF for a DOSLIB file.
DMSFET then issues a DOS SVC 4, which invokes
the module DMSFCH to perform the actual FETCH
operation.
DMSFCH first determines where the phase to be
fetched resides.
The search order is private
core-i.age library, DOSLIB, system core-image
library.
If the phase is not found in any of
these libraries, DMSFCH assumes that the FETCH
is for a phase in a system or private core-image
library. To find a DOSLIB library member, OS
OPEN and FIND .acros are issued
(SVC 19 and
18) •
When the member is found~ OS READ and CHECK
.acros are issued to read the first record of
the file
(the member directory). This record
contains the number of text blocks and the
length of the member.
All addressing information
is stored in
FCHSECT and the text blocks that the phase are
read into storage. If the read is from a CMS
disk, issue the OS READ and CHECK macros to read
the data.
If the read is fro. a DOS disk, first
determine whether this is the first read for the
DOS discontiguous shared segment
(DCSS).
If
this is the case, CCW information is relocated
to ensure that the DCSS code is reentrant. For
all reads for a DOS disk, a CP READ DIAG
instruction is issued.
When the entire file is
read, it is relocated (if it is relocatable) •
If a DOSLIB is open, close it using an OS SVC
20 and return control to DKSFET.
DMSFET then
checks to see whether START is specified and, if
so, an SVC 202 is issued for the CMS START
co •• and to execute the loaded file.
When
control
DMSITS.
all
FETCH processing
is complete,
returns to the CMS com.and handler,
The CMS/DOS FETCH and DOSLKED commands simulate
the operation of the DOS/VS fetch routines and
the DOS/VS Linkage Editor.
The three CMS
.odules that perform this si.ulation are:
•
DMSFET--Provide an interface to interpret the
DOS FETCH co •• and line and execute the phase,
if START is specified on the co.mand line.
•
DMSFCH--Bring into storage a specified phase
from a system or private core-image library
or fro. a CMS DOSLIB library.
•
DMSDLK--Link edit the relocatable output of
the CMS/DOS language translators to create
executable progra.s.
210
CMS simulation of the DOS/VS Linkage Editor
function
directly
parallels
the
DOS/VS
i.plementation of that function.
For detailed
infor.ation on the logic of the function, see
the publication I!Q~L!~ Li!!k.Ag~ Igi.:t2I. 1l2gi£,
Order No. SY33-8556.
Note that the .odules comprising the DOS/VS
Linkage Editor are prefixed by the letters IJB
and are separate CSECTs.
ILL of these CSECTs
have counterparts contained within the one CMS
.odule, DMSDLK. They are treated as subroutines
IBM VM/370: System Logic and Problem Determination Guide
within that
.odule, but perform
the same
functions
as
their
independent
DOS/VS
counterparts and have been named using the sa.e
naming conventions as for the DOS/VS CSECTs.
Por exaaple, the IJBESD CSECT in DOS/VS is
paralleled
by the
CMS DMSDLK
subroutine
DLKESD.
A brief dscription of the logic follows. The
CMS/DOS DOSLKED command
invokes the module
DMSDLK, which is entered at subroutine DLKINL.
DLKINL performs initialization and is later
overlaid by the text buffer and the linkage
editor tables. DLKINL starts to read from a
DOSLNK file and processes ACTION statements, if
there are any.
On encountering the first non-ACTION card (or
if there is no DOSLNK file), the main flow is
entered. Depending on the input on the DOSLNK
or the TEXT file, records from either of those
files aay be read or records from a relocatable
library may be read.
The type of card image
read determines the subroutine to which control
is given for further processing.
An ENTRY card indicates the end of the input
to the linkage editor. At this point, a map is
produced by subroutine DLKMAP. DLKRLD is then
entered to finish the editing of object modules
by relocating the address constants. If the
phases
are to
be relocatable,
relocation
information is added to the output on the
DOSLIB.
Updating of the DOSLIB library is
performed by DLKCAT using the OS STOW macro.
A significant deviation from DOS/VS code is
the use of OS macros, in some instances, rather
than DOS/VS macros. To take advantage of CMS
support of partitioned data sets, the OS OPEN,
PIND, READ, CHECK, and CLOSE macros are issued
rather then their DOS/VS counterparts.
SIMULATE DOS SVC PUNCTIONS
All SVC functions supported for CMS/DOS are
handled by the CMS
module DMSDOS.
DMSDOS
receives control from DMSITS
(the CMS SVC
handler) when that routine intercepts a DOS SVC
code and finds that the DOSSVC flag in DOSFLAGS
is set in NUCON.
DMSDOS acquires the specified SVC code from
the OLDPSW field of the current SVC save area.
using this code, DMSDOS computes the address of
the routine where the SVC is to be handled.
state.ent describing how
performed.
the
SVC function
is
SVC 0: IICP
Handled by aodule DMSICP ••• reads
froa-CMS--or DOS/VS formatted disks.
CCls are
converted to appropriate CMS I/O requests, for
example, RDBUP/IRBUF, CARDRD/CARDPH. The CCB is
posted
(indicating I/O completion)
using CMS
return information. If a non-zero return code is
returned, a CANCEL is performed.
I/O re~uests
to DOS disks are handled using CP DIAGNOSE
instructions.
1: lET£H
Handled by DMSFCH ••• loads a
problem program phase into core and executes it,
if execution is requested. For details on how
FETCH works, see the section "Bring a Phase into
Storage for Execution: DMSFET and DMSFCH."
§!~
SVC
2: PETCH
Handled
by DMSPCH ••• loads
a
iii$B~TransIent phase into core and executes 'it,
if execution is requested. For details on how
FETCH works, see the section "Bring a Phase into
Storage for Execution: DMSFET and DMSFCH."
svc 4: l~I£H
Handled by DMSFCH ••• loads a
problem program phase into user storage and
executes it, if execution is requested.
Por
details on how FETCH works, see the section
"Bring a Phase into storage for Execution:
DMSFET and DMSFCH."
§I£ ~: ~!£~~ -- Handled by DMSDOS ••. provides the
user with a way of altering bytes 12 through 23
of the partition communication region (BGCOM).
Checks to ensure that the specified field is
correct length and then moves the information to
the specified field.
SVC 6: £!!£¥
Handled by DMSDOS ••• cancels a
efts/Dos seSS10n. Processing depends on value in
register 15 on entry; if above 256 the request
is from a system program. If below 256, request
is from a user program. Processing continues
with control passing to EOJ code, described
below.
§!£ 1: !!II
Handled by DMSDOS ••• informs
system programs to wait for a system event to
take place before processing can continue. WAIT
is an effective NOP for CMS/DOS.
~!~~:
Handled by DMSDOS ••• temporarily returns
control to a problem program. The address of
the problem to which control is being passed is
contained in register o. This address is stored
in the SVC save area OLDPSW field and control is
passed to the CMS SVC handler (DMSITS).
2: Handled by DMSDOS ••• returns control to
system program (i.e. a user program has been
given control, as in the case of SVC 8, and must
return control
to the
system routine,
a
$$$$E-Transient routine, that called it) •
~!£
Many CMS/DOS routines
(including DMSDOS) are
contained in a discontiguous shared segment
(DCSS).
Most SVC codes are executed within
DMSDOS, but
some are in
separate modules
external to DMSDOS.
If the SVC code requested
is external to DMSDOS, its address is computed
using a table called DCSSTAB; if the code
requested is executed within DMSDOS, the table
SVCTAB is used to compute the address of the
code to handle the SVC.
SVC 11: Handled by DMSDOS ••• returns control to a
problem
program
from a
$$$$-B
transient
routine. Uses the SVC save area OLDPSW field to
return to the calling program.
~!£ 1~:
The items below show the SVCs supported by
CMS/DOS simulation routines,
the name of the
macro that invokes a given SVC code, the CMS
module that executes the code,
and a brief
Handled by DMSDOS ••• resets flags in the
linkage
control
byte
of
the
Partition
Communication Region
(BGCO!)
to zero; also,
provides the user the capability to use a mask
to set the value of this same byte.
In both
section 2. Method of Operation and Program organization
211
cases, the SVC routine that handles the request
performs an AND operation to accomplish the
function.
~!~
1~:
EOJ -- Handled by DMSDOs ••• normally
terminates--execution of
a problem program.
Clears control blocks and resets control words.
SVC 16: Handled by DMSDOS ••• establishes linkage
with or terminates linkage to a user's program
check routine.
Locates
the appropriate PC
option table entry.
If contents of register 0
is zero, terminates linkage: stores a zero into
the routine address field of the PC option
table.
If register 0 is non-zero, the address
of the PC routine and the save area address is
passed to the STIlT macro.
If a STXIT PC
routine is already active, the complement of the
new routine address is placed in the PC option
table; if no STIlT PC routine is active, both
the new routine address and the save area
address are placed in the PC option table.
SVC 11: Handled by DMSDOS ••• provides supervisory
~upport for the exit macro.
Locates appropriate
PC option table entry
and restores user's
registers and PSi. Stores the address of the PC
routine in the PC option table and returns to
the next sequential address in the interrupted
program.
~!~
~§: Handled
by DMSDOS ••• validates address
limits. Checks the limits passed in registers 1
and 2 and either returns control to the caller
or writes an error message.
SVC 33: COMRG-- Handled by DMSDOS ••• provides
the -address--of
the partition communication
region (BGCOM). Returns the address of BGCOM in
register 1.
SVC 34: Handled by DMSDOS ••• supports the GETIME
.aero: Updates the date field in the partition
communications region (BGCOM).
11: Handled by DMSDOS ••• establishes linkage
to or terminates linkage from a user's abonormal
termination routine.
Locate the
AB table
entry.
If
register
0
ccontains
zeros;
terminates linkage: if the AB routine is active,
stores zeros into the routine address field of
the AB option table.
If the AB routine is not
active, stores zeros into both the routine
address field and the save area field of the AB
option table.
~!~
If register
0 is
non-zero, establishes
linkage: passes the address of the AB routine
and the save area address to the STIlT AB macro.
If STilT AB is active, the complement of the AB
routine address is stored in the AB option
table.
If STIlT AB is not active, both the
address of the new AB routine and the address of
the save area are placed in the option table.
SVC 40: POST -- Handled by DMSDOS ••• signals the
completion-of a system event.
~!~
~Q:
Handled by DMSDOS ••• issues an error
message and terminates the command. Issued by a
LIOCS routine when that routine is requested to
perform a function it could not perform.
212
-- Handled by DMSDOS ••• used by
obtain scratch storage; also, obtains
storage for a relocatable VSAM routine.
Storage
is obtained from the user free storage area and
the address of the storage is returned in
Register 1.
SVC 61:
Q~j!!~
SVC 62:
FREEVIS -- Handled by DMSDOS ••• returns
by a GETVIS.
Address of the
be returned is pointed to by Register
~~iM-~o
s~orage obtained
area to
1.
§J: Q~~ -- Handled by DMSDOS ••• VSAM uses SVC
63 to ensure that system resources are updated
serially, so that two or more attempts to modify
the same data at the same time do not succeed.
A table of counters (RURTBL)
is kept for system
resources.
These counters are posted when a
request is made for system resources. If a
resource is already in use# a return code of
eight is placed in gister O. If the resource is
available, a zero is returned in Register o.
~!~
~!£
64: RELEASE -- Handled
SVC iij to-release a system
USE SVC.
The appropriate
decremented by one each
released.
by DMSDOS ••• VSAM uses
resource obtained via
counter in RURTBL is
time a resource is
§2: £~~QA~
Handled by DMSDOS ••• loads a
relocatable VSAM phase into storage unless that
phase has already been loaded.
~!£
If an anchor tatle is available,
it is
searched for the phase. If the phase is found,
its load point,
entry point, and length are
returned
in
registers
0,
1,
and
14,
respectively, and register 15 contains zeros.
If the phase is not found in the anchor
table, DMSFCH is called to search for it. If
the phase is found in the discontiguous shared
segaent, return is made to the requestor as
above.
If the phase was found,
but not loaded,
storage is ontained for it via the GETVIS SVC.
DMSFCH is called again to load the phase into
the storage just obtained. An anchor table is
then built in the user area (unless one already
exists) and return to the caller is then made as
described above.
SVC
66:
RUNMODE
BandIed
by
problem program
is running in real or virtual mode.
Register 0
contains zero on return if the program is
running in virtual mode.
~~~Dos •• :determines-ihether the
~!~ 1~:
SECTVAL -- Handled by DMSDOS ••• used by
VSAM I/O routInes to obtain a sector number for
3330 or 3340 devices.
The appropriate sector
value is calculated from input supplied in ser
registers 1 and O. The sector number (from 0 to
121) is returned in register O.
Certain DOS SVCs are treated as no-ops by
CMS/DOS and other DOS/VS SVCs are not supported.
These are listed below.
IBM VM/310: system Logic and Problem Determination Guide
SVCS TREATED AS NO-OP BY C!S/DOS
SVC
10:
18:
20:
22:
24:
35:
36:
41 :
42:
52:
67:
68:
71 :
85:
86:
87:
PROCESS C!S/DOS SERVICE COMMANDS
Action
sets-timer interval
STXIT (IT)
Establishes linkage to OC
Seizes (interruption enable/disable)
Sets timer interval
Holds a track
Frees a track
Dequeues a resource
Enqueues a resource
Returns
re.aining
timer
interval
(Register 0 is also cleare~
PFIX, fixes pages in real storage
PFREE, frees pages in real storage
SETPFA
RELPAG
FCEPGOUT
PAGEIN
l!Q1 §Y~~Q~I!.!2 ~! ~lI~L12Q§: The following
SVCs cause an error message to be generated and
are treated as a CANCL (SVC 6).
§!£§
SVC Action
-3:
Forces
dequeue
Sets switches in BGCO!
Heads queue and executes channel program
Returns from user's IT
Loads phase header
Issues HIO
special HIO
Returns from user's MR
!ultiple WAITM support
waits for a QTAM element
Posts a QTAM element
Reserved for IB! use
Initializes a subtask
Terminates a subtask
Reserved for IBM use
External unit checks record
Emulator interface
OLTEP in supervisor state
Multiple WAITF support
Fetches a CRT trans
Reserved by IBM
Returns phase header
Reserved by IBM
Frees real page frames
Gets real page frames
Gets or frees PUB of POWER device
Makes POWER dispatchable
Interface between JCL and supervisor
Interface between EOJ and supervisor
EREP and CRT I/O areas address
REALAD
VIR TAD
GETCBUF/FREECBUF
SETAPP
Fixes pages in real storage for restart
Initializes for recording of RMSR I/O
error
71: TRANSCSW
18: Reserved for IBM use
79: Reserved for IBM use
80: Reserved for IBM use
81 : Reserved for IBM use
82: Reserved for IBM use
83: Reserved for IBM use
84: Reserved for IBM use
88 and up:
Reserved for IBM use
13 :
15:
19:
23:
25:
27:
28:
29:
30:
31:
32:
38:
39:
43:
44:
45:
46:
47:
48:
49:
51:
53:
54:
55:
56:
51:
58:
59:
60:
69:
10:
72:
13:
14:
16:
DMSSRV--Copies books from a system or private
source state.ent library to a specified output
device.
DMSPRV--Copies DOS procedures from a DOS system
procedure library to a specified output device.
DMSRRV--Copies modules from a
relocatable library
to a
device.
system or private
specified output
DMSDSV--Lists the directories of
system libraries.
DOS private or
DMSDSL--Deletes me.bers
(phases) of a DOSLIB
library; compresses a DOSLIB library; lists the
members (phases) of a DOSLIB library.
ESERV--De-edits, displays or punches, verifies,
and updates edit assembler macros from the
source statement library.
TER!INATE PROCESSING THE CMS/DOS ENVIRONMENT
DMSBAB--Gives control to an abnormal termination
routine once linkage to such a routine has been
established via the STXIT AB macro.
DMSITP--Processes
exits.
program interrupts
and
SPIE
DMSD!P--Simulates the
$$BDUMP and
$$BPDUMP
routines; issues a CP DUMP command directing the
dump to an offline printer.
PERFORM MISCELLANEOUS CMS FUNCTIONS
CMS BATCH FACILITY
The CMS Batch Facility is a function of CMS. It
provides a way of entering individual user jobs
through an active CMS machine from the virtual
card reader rather than from the console.
The
batch facility reissues the IPL command after
each job.
The eMS Batch Facility
consists of two
modules: DMSBTB,
the bootstrap
routine
(a
nonrelocatable CMS module file)
and DMSBTP, the
processor routine
(a relocatable CMS text file
that runs free storage).
GENERAL OPERATION OF DMSBTB
The
bootstrap
module, DMSBTB,
loads
the
processor routine DMSBTP and the user exit
routines BATEXIT1 and BATEXIT2 (if they exist)
into free storage.
DMSBTB
first ensures
that DMSINS
(CMS
initialization) has set the BATRUN and BATLOAD
Section 2. Method of Operation and Program Organization
213
flags on in the CMS nucleus constant area
indicating that either an explicit batch initial
program load command has been issued or that the
CMSBATCH command has been issued immediately
after initial program load has taken place. If
not r error message DMSBTB101E is typed and the
batch
console
returns to
a
normal
CMS
interactive environment. STATE (DMSSTT) is then
called to confirm the existence of the processor
file DMSBTP TEXT.
If the file does not exist r
error message DMSTBT100E is typed and the batch
console
returns
to
the
CMS
interactive
environment.
Using the "state" copy of the file status
table (FST) for DMSBTP r DMSBTB computes the size
of DMSBTP TEXT file by multiplying the logical
record length by the number of logical records
(no DS constants). A free storage request is
made for the size of DMSBTP and the address of
the routine is then stored at ABATPROC in the
NUCON area of the CMS nucleus.
The existence of the user exit routines is
determined by STATE. If they exist r their sizes
are included in the request for free storage.
The free storage addr~ss is translated into
graphic hexadecimal format and the CMS LOAD
command is issued to load the DMSBTP TEXT file
into the reserved free storage area.
The user
exit routines r
BATEXITl TEXT and BATEXIT2 TEXT
are also loaded at this time.
If these files do
not exist r
an unresolved external reference
error code is returned by the loader, but is
ignored by DMSBTB because these routines are
optional. If an error
(other than unresolved
names) occurs r error message DMSBTB101E is typed
and the batch console
returns to the CMS
interactive environment.
The loader tables are
searched for the
address of the ABEND entry point DMSBTPAB in the
loaded batch processor.
When the entry is
found r its address and that of entry DMSBTPLM
are stored
in ABATABND
and the
ABATLIMT
respectively, in the NUCON area of the CMS
nucleus. If the ABEND entry point is not found
in the tables r error message DMSBTB101E is typed
and the batch console
returns to the CMS
interactive environment.
The BATLOAD flag is set off to show that
DMSBTP has been loaded, the BATNOEX flag is set
on to prevent user job execution until DMSBTP
encounters a IJOB card and finally, control is
returned to the com.and processor DMSINT.
If an error message is issued r DMSERR is
called to type the message r and the BATRUN and
BATLOAD flags are set off before control is
returned to CMS.
This allows the normal CMS
interaction to resume.
GENERAL OPERATION OF DMSBTP
The batch processor module DMSBTP simulates the
function of the CMS console read module DMSCRD.
This is accomplished by issuing reads to the
virtual card reader, formatting the card-image
record to
resemble a
console record
and
returning control to CMS to process the command
214
(or data)
request. DMSBTP also performs reads
to the console stack if the stack is not empty,
checks for and processes the IJOB card, ensuring
that it is the first record in the user jOb r
traps all
CP commands to
maintain system
integrity and
performs job
initialization,
cleanup, and job recovery.
upon receiving control, DMSBTP checks the
BATCPEX flag in NUCON. If the flag is set on,
control was received from DMSCPF and a branch is
made to the CP trap routine to verify that the
command is allowable under batch. The function
of that routine is described' later. If the
BATCPEX flag is off, control was received from
DMSCRD (console read module) and DMSBTP checks
for finished reads in the real batch console
stack.
If the number of finished reads is not
zero, control is returned to DMSCRD to process
the real console finished (stacked) reads. If
the number of finished reads is zero, a record
is read from the batch virtual card reader into
the CARD buffer via an svc call to CARDRD
(DMSCIO).
The record in the CARD buffer is
typed on the console via the WRTERM macro.
If
the BATMOVE flag is set on
mOVEFILE executing
from the console), the records in the file are
not typed on the console.
The record in the reader buffer is scanned to
compute its length with trailing blanks deleted.
It is then moved to the CMS console read buffer
and the computed length
is stored in the
original DMSCRD parameter list r whose address is
passed by DMSCRD when
it initially passes
control to DMSBTP.
If the first user record is not a IJOB card,
error message DMSBTP105E is typed and normal
cleanup is performed with the BATTERM flag set
on. This flag prevents another initial program
load, since it is not needed at this time.
Reads to the card reader are then issued until
the next IJOB card is found.
If the first record is a IJOB card, DMSBTP
branches to its IJOB card processing routine
which calls DMSSCNN via a BALR. A check is made
for the existence of the userid and account
number on the card. If the fields exist, a CP
diagnose 'QC' is issued to start accounting
recording for that userid and account number.
If an error is returned from CP denoting an
invalid userid, or if the userid or account
number fields were missing on the IJOB card,
error message DMSBTP106E is typed and normal
cleanup is performed with the BATTERM flag set
on.
The jobname, if provided on the IJOB card, is
saved and a message is issued via SVC to inform
the source userid that the job has started. The
spooling devices are closed and respooled for
continuous output, a CP QUERY FILES command is
issued for information purposes and the implied
CP function under CMS is disabled and the
,protection feature set off via SVC calls to SET
(DMSSET). The BATPROF EXEC is executed via an
SVC to EXEC. The BATNOEX flag, which is set by
DMSBTB to suppress user job execution until the
IJOB card is detected, is set off. The BATUSEX
flag is set on (for DMSCPF) to signal the start
of the actual user job, and a branch is taken to
read the next card from the reader file (user
job) .
IBM VM/370: system Logic and Problem Determination Guide
After reading the IJOB card, DMSBTP continues
reading and checks for a 1* card, a ISET card,
or a CP command. If a card is none of these,
DMSBTP passes control back
to the command
processor DMSINT for processing of the command
(or data).
If a 1* card is read and it is the first card
of the
new job, it
is assume to
be a
precautionary measure and thus ignored by DMSBTP
which then reads the next card. If it is not
the first card a check is made for the BATMOVE
flag.
If the flag is on, the 1* card indicates
an end-of-file
condition for
the MOVEPILE
operation from the console (reader)
and is
consequently translated to a null line for the
MOVEPILE command.
If the BATMOVE flag is not on, the 1* card is
and end-of-job indicator and an immediate branch
is taken to the end-of-job routine for cl~anup
and reloading of CMS batch.
When a CP command
is encoutered DMSBTP
branches to a routine that first checks a table
of CP commands allowable in batch.
If the
command is allowed, a check is made for a reader
or other spool device in the command line. If
the CP command is allowed but would alter the
status of the batch reader or any spooling
device or certain disks, or if the command is
not allowed at all, error message DMSBTP107E is
typed, and the next card is read.
If the CP command is LINK, the device address
is stored in a table so that DMSBTP can detach
all user disk devices at the end of the job.
A CP DETACH command is examined for a device
address corresponding to the system disk, the
IPL disk, the batch 195 work disk or any spool
device. If the device to be detached is any of
these, error message DMSBTP107E is displayed and
the next card is
read.
Otherwise,
DMSBTP
returns control to DMSINT
(or DMSCPF is the
BATCPEX flag is set on)
for processing of the
command.
When a ISET control card is encountered, the
card is checked for
valid keywords, valid
integer values
(less than or equal to the
installation default values), and if an error is
detected, error message DMSBTP108E is typed. An
abnormal termination message is also sent to the
source userid and the job is terminated with
normal cleanup performed. If the control card
values are valid, the appropriate fields are
updated in the user job limit table DMSBTPLM and
the next card is read.
If DMSBTP detects a "not ready" condition at
the reader,
a message is typed at the console
stating that batch is waiting for reader input.
DMSBTP then issues the WAITD macro to ,ait for a
reader interrupt.
When first detecting the
empty reader, DMSBTP calls the CP accounting
routines via a CP diagnose '4C' to charge the
wait time to the batch userid.
If a hard error i~ detected at the
DMSBTP sends an "intervention required"
to the system console and branches
abnormal terminal routine and waits
reader,
message
to its
for an
interruption for the reader by issuing the WAITD
macro.
When a 1* card is read (with the BATMOVE flag
off) or when the end-of-file condition occurs at
the reader, DMSBTP branches to the cleanup
routine which sends the source userid a message
stating
that the
job
ended normally
or
abnormally
(if cleaning upa fter an abnormal
termination) and turns off the BATUSEX flag (for
DMSCPF) to signal the end of the user user job.
CONWAIT (DMSCWT) is called via SVC to allow any
console 1/0 to finish, the spooling devices are
clos~d (including
the console), and all disks
that were made available by issuing the CP LINK
command are returned by issuing the CP DETACH
command.
DMSBTP then relinquishes control by issuing
the CP IPL command with the PARM BATCH option
which loads a new CMS nucleus and the next job
is started when CMS attempts its first read to
the console.
A branch is made to the CMSBTP routine when
DMSBTP itself detects an 110 error at the
reader.
However, the primary purpose of the
routine is to receive control not only from
DMSABN when there is an abnormal termination
during the user job, but also from DMSITE,
DMSPIO, and DMSCIO when a user job exceeds one
of the batch job limits (BATXLIM flag is on).
This routine, entry point DMSBTPAB, calls the CP
DUMP routine via SVC and then branches to the
cleanup routine which reloads CMS Batch and
treat the remainder of the current job as a new
job with no IJOB card. This has the effect of
flushing the
remainder of the
job.
This
technique is used because batch must keep its
reader
spooled "continuous."
Entry
point
DMSBTPAB is also used by the CMS commands that
are disabled in CMS
batch.
In this case
(BATDCMS flag set on), an error message is
displayed and control returned to CMS.
When a CP command is called via an SVC in
DMSBTP, the CMS CP module (DMSCPF) is acutally
called to issue the DIlGNOSE instruction to
invoke the CP command. DMSBTP calls DMSCPF by
issuing a direct SVC 202 or by issuing the
LINEDIT macro with the
CPCOMM option that
generates an SVC 203.
OTHER CMS MODULES MODIFIED IN CMS BATCH
Several CMS modules check whether CMS batch is
functions
running;
and,
if
so,
perform
associated with batch operation.
These are
shown in the following list:
~ggul~
DMSINI
DMSINS
DMSLDR
DMSCRD
DMSITE
DMSPIO
Function Performed for CMS Batch
passes-batch-parameters-to Dftsiis.
Uses batch IPL parameters to reload
CMS Batch.
Loads DMSBTP into free storage.
Passes control to DMSBTP to read from
the reader
rather than
from the
console.
Accounts for virtual time used by
ABEND if over limit.
batch job
Accounts for number of lines printed
by batch job
ABEND if over limit.
section 2. Method of Operation and Program Organization
215
DMSCIO
DMSABN
DMSERR
DMSMVE
DHSSET
DHSRDC
DMSCPF
DMSFLD
DM SDSK
Accounts for number of cards punched
by batch job -- ABEND if over limit.
Passes control to batch ABEND routine
in DMSBTP.
Passes control to batch ABEND routine
instead of entering
disabled wait
state.
Turns the BATMOVE flag on and off
allows batch to treat moved blanks as
data.
Disabled if batch
running,
except
during batch initialization.
Disabled if batch running.
Distinguishes
between
CP
command
issued by user and by batch.
Disallows
reader
device
specification.
Disk load not allowed in batch.
USE OF THE ANNOTATED FLOW DIAGRAM
The following text sections, which describe each
major CP function, are annotated flow diagrams.
These diagrams, consisting of logic labels and
commentary, describe the general flow and use of
CP logic modules and their relationship to other
modules ~hile performing a specific function or
task.
The annotated flow
diagrams do not
contain references to error messages, abnormal
termination conditions, or most control block
field labels. This avoids complexity and makes
the general logic of CP and its related tasks
more
understandable
to
the
user.
With
"understandability" as the
key, obtuse and
complex logic that is used for obscure and
seldom used functions is not described.
Also
the flow diagram does not indicate or describe
every entry point encountered in a function.
Nor do the diagrams illustrate the innumerable
times that commonly used modules are utilized.
DMKFRE and DMKCVT, the obtaining and returning
of free storage and the number base conversion
modules are such
examples.
Annotated flow
diagrams
are
arranged
by
function
and
subfunction.
Titles for these functions and
subfunctions also precede annotated flow text
and labels. The text in the charts is prefixed
by underscored and capitalized entry points and
labels. Entry points are indicated by 7 or 8
characters; the first three characters are DMK.
Labels are indicated by prefixing with a comma
and the six-character module identification.
Note: annotated flow diagrams are not to be
construed to be trace material. The dynamics of
CP operations preclude the use of the annotated
flow diagrams, as they are shown in this manual,
as traces of CP functions.
VM/370 CP INTERRUPTION PROCESSING
SVC INTERRUPTIONS - PROBLEM STATE
.Q~~E'§!'§!
Entry for SVC interruptions from problem or
supervisor states.
For proble. mode and
216
ADSTOP (SVC X 'B3'), the overlaid instruction
is replaced
DMKCFMBK
---Console function mode is entered.
DMKPSASV
---por-problem state SVC 76 (X'4C')
check for
valid parameter passing.
DMKVERD, DMKVERO
---netermIne--the operating SCP used in the
virtual
machine
by
examining
passed
parameters in RO and R1.
DMKPSA, SVCVER
-invalid
parameter
passing,
error
recording is not performed.
DMKIOEVR
---The-SVC is reflected back to the user.
DMKIOFVR
---on-correct parameter reflection~ record the
error.
DMKTRCSV
---The-DMKTRC module is called if TRACE SVC was
invoked.
DMKPSA, REFSVCB
---Por Ec--iiiode machine or page 0 not in real
storage. Per results of TRACE activity, go
to the DMKDSPCH; if not successful, go to
DMKDSPB.
DMKPRGRF
---j~-tracing not active, flag
user as being in
instruction wait state and reflect the SVC
back to the user.
DMKPSASV
---jf-the virtual machine is in BC mode and page
o is in real storage, generate and store an
old SVC PSi. Then fetch the new SVC PSi.
DMKDSPB
---j~-wait state is
not indicated, store user's
new PSi in RUNPSW, restore registers and
dispatch via LPSi.
---Por
SVC INTERRUPTIONS - SUPERVISOR STATE
DMKPSASU
---Entry is for a system failure and is a SVC 0
or SVC 4 ABEND condition.
DMKDMPDK
---Perform partial or full real storage dump.
DMKCKPT
---Checkpoint the system.
DMKCPINT
---Perform an automatic IPL if indicated
!H!!H~12! , ~.!£1!!HS
Entry via SVC 8 provides linkage to a called
routine in R15
DMKPTRUL
---j~-called routine is not resident, page it in
and return control to the caller by loading
the SAVERTN into the old PSi and then load
the old PSi. The callers addressability,
SAVEAREA address and
return address are
maintained in a new SAVEAREA.
DMKPSA, SVCRET
---Entry--vIi-svc 12 return control from the
called routine to the calling routine and
restores address ability via R12 and R13.
DMKPGSUL
---j~--a nonresident
module
unlock page to
return it to DASD device.
DMKPSA, SVCRLSE
---Entry--vIi--svc 16 to release the current
SAVEAREA used by SVC 8 and 12. Return to
caller.
IBM VM/370: System Logic and Problem Determination Guide
DMKPSA, SVCGET
---Entry-vi;--svc 20 to
Return to caller.
obtain a
new SAVEAREA.
the class and code, branch to the appropriate
data collection routine.
Class Code
---00---
EXTERNAL AND CLOCK INTERRUPTION REFLECTION
97
98
99
DMKPSAEX
---Entered via the interruption key on system
console, adjust accounting to charge for
supervisor overhead.
If problem mode, ATTN
interruption, update the virtual machine PSi
from the external old PSi.
DMKPSA, EXTBUTTN
---jiit to-dispatcher, if there is no logged-on
operator, or the operator is disconnected, or
there is no active terminal.
If the operator
was logged on and the external interruption
key was pressed, disconnect the operator's
terminal
.Q~!Hl£!£~
Clear all console requests.
DMKSCNRD
---If-the device is a terminal or graphic device
issue HIO to the real device
DKKDSPCH
---EiIt-to the dispatcher.
DMKPSA, EXTBUTTN
---Por 3104/3105, convert resource identifier
for the NCP terminal for the index able entry
into the NICBLOK for the associated VMBLOK
then
.Q~!H~!!!!!2
Reset all BTUs.
DMKDSPCH
---Exit-to the dispatcher.
!2!!!H~2A ,
JAI!t!I!2
Upon location
X'80' timer
interruption,
indicate the user end of the time slice by
storing flag in the VMBLOK's VKOSTAT.
DKKDSPCH
---EiIt-to dispatcher.
DKKPSA, EXTTIMER
---upon -cpu--tImer interruption, VKTLEVEL in
VKBLOK as a real CPU timer interruption.
DMKTMRVT
---sImulate the interruption.
DMKDSPCH
---EiIt-to the dispatcher.
DMKPSA, EXTCKC
---Upon clock-comparator interruption reflection
!2!!~2£!!I.Q
Use the
printer to unchain
TRQBLOK. Call DKKSTKIO.
DMKSTKIO
---stack the block.
DKKDSPCH
---EiIt-to dispatcher.
the
active
o
1
2
3
2
2
3
4
4
5
6
7
8
0
0
0+1
o
0
2
Function
perfori- timer driven
system
clock and counter recording
MONITOR tape header record
MONITOR tape trailer record
MONITOR suspension due to tape
busy
Begin console read
Console output
End Console read
Console sleep
Drop user from queue
Add user to queue
Add user to eligible list
User statistics
Instruction simulation
DASTAP
Device statistics header
DASD seek channel program
Device statistics
and system
counters
Each
collection
routine
calls
buffer
management for space for the collected dat~.
If the MONITOR tape is busy MONITOR activity
is suspended. If not busy call DMKSTKCP
---to-stack a CPEXBLOK for the event to call the
scheduler.
DMKMON, EXIT2
---iestore--ill registers
to their previous
values prior to the MONITOR CALL.
Load the
old program check PSi to resume processing.
PROGRAM INTERRUPTION PROCESSING
!HUg~!!§!!
For a program interruption received while in
supervisor mode
(indication of CP module
error) and INTRDR+1 does not indicate MONITOR
CALL (X'40') exit to DMKPRG, CPERROR
---Send ABEND-message to the system operator.
DMKDMKPK
---Dump-storage and initiate IPL
DMKPRGIN
---por-supervisor state and MONITOR CALL save
registers in in DMKPRGPR
DMKPRGKI
---Do--BoNITOR
CALL interruption
processing
(DMKMON) •
!2!!~R!H~ , R!!~2I!I
MONITOR INTERRUPTION PROCESSING
DKKMONTI
---Par-monitor requests, with an operation code
of X'AF', increment TOD with DMKPRGTI value
and insert in TRQBLOK.
DMKSCHST
---Insert the block in the request block chain.
DMKMONTI
---collect Monitor timer driven date for the
enabled classes. On the successful decode of
For paging exception X'11' and EC mode with
DKKVATEX
---Translation on, process the exception.
DMKPRGIM
---por-paging exception, x '11' and EC mode with
DMKVATPF
DMKVATPF
---Translation
off,
and enabled
for
1/0
interrupts and PAGEX on, process the pseudo
page fault
DMKPRG, PAGEXCP
---Por all-other page fault conditons go to
DMKPTRAN
!2!1~~.!!!!!!
Bring in the page from the auxiliary device.
DMKDSPCH
---Eiit-to dispatcher.
Section 2. Method of Operation and Program Organization
217
DMKPRG, PRNSTAT
---Por segment- exception X'10' with EC
and translation on
DMKVATSX
---process the exception.
mode on
unsupported instruction operand codes and
DIAGNOSE '83' function codes that are not a
multiple of 4.
~IlK~!!§, ~R§§!~!
For the segment exception, X'10' does not
follow the above parameters; process it as an
addressing exception.
Y!HU~~§,
:£~A.!'§I!
Process X'12' translation exceptions.
DMKPRG, PRG01
---Par privileged or operational exception of a
virtual machine in supervisor mode, examine
ITRPR+l if X'Ol' or '02' call DMKPRVLG
---to-process the exception.
DKKPRV, DKKPRGSM
---Por virtual--machines in problem mode, store
the users new program PSi in VMBLOK VMPSi.
DKKPSASV
the program interrupt occurs and the
users page 0 is not resident or the virutal
machine is in EC mode, paging is performed
tKKDSPB
---Check the new PSi.
DKKPRVLG
---ValIdate the privileged operation indicated
in VMINST+2 and perform the service.
---When-
Code
XI 08'
X'09'
X'44'
X'80'
X'82'
X'9C'
X'9D'
X'9E'
X'9F'
X'AC'
X'AD'
X'Bl'
X'B202'
X'B203'
X'B204'
X'B206'
X'B207'
X'B208 '
X'B209'
X'B20A'
X'B20B'
X'B20D'
X'B6'
X'B7'
X'BA'
X'BB'
Q~~!:~!i2!!
SSK - Set storage key
Insert storage key
EX - Execute instruction
SSM - Set system mask
LPSi - Load PSW
SIO - Start I/O
TIO - Text I/O
HIO - Halt I/O
TCH - Text Channel
STNSM - Store, then AND system mask
STOSK - Store, then OR system mask
LRA - Load real
STIDP - Store CPU ID
STIDC - Store channel ID
SCK - Set TOD clock
SCKC - Set TOD clock comparator
STCKC - Store TOD clock comparator
SPT - Set CPU timer
STPT - Store CPU timer
SPKA - Set PSW key from address
IPD - Insert PSi key
PTLB - Purge TLB
STCTL - Store control registers
LCTL - Load control registers
CS - Compare and swap
CDS - Compare double and swap
DKKHVCAL
---On--privileged operations of DIAGNOSE X'83'
and the associated function code, perform the
service.
Q!H~!!Q
Execute privileged I/O operations of SIO,
HIO, TIO and TCH.
DMKT"RTH
---Perform privileged operations related to TOD
clock, TOD clock comparator and the CPU
timer.
CTCA OPERATIONS BETiEEN TWO VIRTUAL MACHINES
DKKVIOEX
---Virtual I/O operation is reflected to DMKVCA,
the channel adapter module, for processing.
DMKVCAST
---Por-SIO, check if the CTCA is coupled. If
not coupled, call DKKDIASK.
DKKDIASM
---sIiiuIate return status.
D"KVCA, VCRSTART
---P~r a---coupled
CTCA,
analyze operations
resulting in X-side (read) and Y-side (write)
of the data transfer opera tion.
DMKVCA, VCASIOB
---Detected-Interruptions are presented to users
via stacked IOBLOKS and DMKSTKIO.
DMKVCATS
---cTci-TIO activity is determined by examining
Y-side information to determine mode and
activity.
DMKVCASH
---cTci-HIO and HDV is processed by determining
the conition code to present and whether the
Y-side should be notified.
DMKVCARD
---CTci-process results from RESET xxx or SYSTEM
RESET commands. The CTCA status is reset but
the CTCAs are not uncoupled.
DKKVCARS
---Uncoupling CTCA is achieved in the VDEVBLOK
(VDEVNRDY flag) idle CTCA plus an invoked
DETACH xxx or user LOGOFF.
Return to calling
routine.
SCHEDULING I/O FOR CP AND THE VIRTUAL MACHINE
Yl1~!Q'§2!!
Entered via SVC. Entry pOint indicate a CP
I/O event as indicated in the IOBLOK.
For
start request, increment the SIO count in the
RDEVBLOK and start the device if it is
available.
If not (device busy or already
scheduled) queue the IOBLOK and return the
operation to the caller.
Yll!!Q§2!
Entered via SVC.
Entry point indicates
virtual
machine
initiated
I/O
event.
Preserve VMBLOK address in R11, turn off
IOBCP bit in the IOBLOK, add 1 to SIO count
in the VDEVBLOK (or RDEVBLOK).
Process the
SIO if there is any available path to the
device. If not, queue the IOBLOK and return
the operation to the caller.
Y!!!.F~§'§ll
Program interruption is reflected back to the
user
on
invalid
instruction
operands,
218
IBf! V"/370: system Logic and Problem Determination Guide
STANDARD DASD I/O INITIATED VIA DIAGNOSE
DMKDGDDK
---Perform simple
disk I/O of
a standard
format.
Entry is via DMKHVC code X'18'.
DMKSCNVU
---FInd-device related to SIO cuu address.
DMKFREE
---illocate storage for IOBLOK and RCWTASK.
DftKGDDK
---BuIld and check the CCW string.
DftKVIO, VIOHIO
---For HIO,-check for dedicated channel, CE, CU,
or device busy condition, and subchannel busy
and set appropriate condition codes.
DftKVIO, VIOTCH
---Check-far-dedicated selector or busy channel
and check for pending abnormal interruption
and set appropriate condition code.
!l~~!Q~2!
Execute I/O.
On completion, post condition
code
(and error return code in R15,
if
detected) •
DftKDSPCH
---Eilt-to dispatcher.
GENERAL I/O OPERATION INITIATED VIA DIAGNOSE
DftKGIOEX
---Perform general I/O operation.
Entry is via
DftKHVC code 20.
DftKSCNVU
---Find-device related to SIO cuu address.
DMKFREE
---illocate storage for the IOBLOK.
DMKCCWTR
---BuIld the read CCW list.
!H!!!OS.Q!
Queue the I/O request for execution.
DftKGIO, DIAGRTN
---On-interruption return, check status.
DMKUNTFR
---If-no problem encountered,
free storage used
for CCW string and IOBLOK.
DMKGIO, DIAGRTN
---Reflect-the-condition code and return code to
the user.
DftKDSPCH
---jilt-to dispatcher.
DftKUNTRN
---On-returned error condition, convert real CSW
to virtual CSW and set in user's page O.
DMKGIO, GIOEXT
---Eilt vIa-sic 12.
VIRTUAL MACHINE I/O INSTRUCTION
INTERRUPTION REFLECTION
SIftULATION AND
DftKVIOIN
---Entry from DftKDSP to process the reflected
virtual interruption.
DMKSCNVU
---Locate the VCHBLOK, VCUBLOK, and VDEVBLOK.
DMKVIOIN
---Analyze blocks and reflect condition code to
user.
If condition code equals 1
(cc= 1) ,
save status from the real device (if real
device) and DMKUNTFR.
DMKUNTFR
---Translate and store CSW in user's page O.
DMKVIO, VIOCC1
---On-TIO-or-HIO, free the device and set CC=1.
DMKFRET
---Fret storage for the IOBLOK.
DMKDSPCH
---jilt-to dispatcher.
VIRTUAL CONSOLE SIMULATION
DMKVIOEX
---Entry for virtual console activity comes from
the SCP
stored in
the user's
virtual
machine.
The program's generated CCWs and
data are reflected to the attached terminal
used by the virtual machine operator.
DMKVCNEX
---Locate and move non-TIC CCWs from the users
virtual storage to a VCONCTL block.
DMKVCN, GETCCW
---Update--cii and CSW in respective control
block.
DMKVCN, VCNRD
---For read- operation, build a read console
buffer VCONBUF for the input to be read from
the terminal.
Q~!2~!!m.
DMKIOEX
---Entry from
DMKPRV to simulate
I/O per
VMBLOK's VMIST field.
!l~!!!Q, !!Q2!Q On detected SIO, call DMKSCNVU
---To-locate VCHBLOK, VCUBLOK, and VDEVBLOK for
the cuu called per SIO instruction.
DftKVIOEX
---Determine
device
availability
and
set
condition code accordingly.
Q~!!Q~.Q'!
If the operation is warranted,
operation.
!H1!!!Q, !!Q!!Q
schedule the
For
TIO, check
device status,
pending
interrupts, and set appropriate condition
codes.
Execute
the
read
operation
and
call
DMKVCHEX.
DMKVCNEX
---set--return
address in
VCONCTL VCNRDRET
field.
DMKVSPVP
---spool console activity if SPOOL CONSOLE START
specified.
DMKDSPCH
---EiIt-to dispatcher.
wait for completion.
DMKVCN VCNWR
---Calculate and obtain free storage (VCONBUF)
necessary
for
the
write
to
console
operation.
DMKVCN, VCNMDAT
---Translate-and bring in user's data page and
move it into VCONBUF.
section 2. Method of Operation and Program Organization
219
~~!!Q"§2~
!H1K2£!~±
Write data to user's terminal.
DKKDSPCH
---'Eilt-to dispatcher.
DKKVCN, VCNSHCN
---oi-a -sense-operation, set CE and DE in the
virtual PSW.
Reflect the PCI flag in the PSW
if the PCI flag was set in the CCW. set the
IL flag if warranted.
Kove the sense data
from the
VDEVBLOK to
user storage
as
designated by the CCW.
Update VDEVBLOKS
VDEVCSW to reflect status and count.
.!!!U~!£!,
!£!££1
On
completion
of
I/O
operation,
set
appropriate status for command reject, not
ready protection check, incorrect length,
channel program check.
set appropriate CC
and CSW in users page O. Otherwise post
pending
interruption status
in
VKBLOK,
VCHBLOK, VCUBLOK and VDEVBLOK.
DKKVCN, FLAGTEST
---If-command-chaining, process the next ccw.
I:KKDSPCH
---Exit-to dispatcher.
LOCAL GRAPHIC I/O AND INTERRUPTION PROCESSING
Issue the SIO.
DKKDSPCH
---ialt-for the response.
DKKGRA, RDINT
---Ei- t~e--Interruption response, go to the
return processing address in the TRQBLOK
extension
TRQBCRT.
For
read
return,
determine function key
action and write
response
(if appropriate) via KEYTBL.
On
response of CE and
DE go to auxiliary
processing address and execute the processing
routines:
CONRETBF - completion of a write CONTASK
RDKINT
- completion of a buffer read
GRFCFK
- execute console function
SETREJ
- set no accepted timer
SETKOR
- set more ••• timer delay
SETWNG
set 10 second clear warning
RDEXIT
clear buffers after PF keys
STRTREAD - set read status
NOCTL
- process next CONTASK or go idle
DMKGRA, RDATA
---Process--read response of data plus ENTER
key.
DMKCNSED
---ialt-and modify length count. Move data to
caller's buffer.
Jl1!1S~£l!~±
Schedule
rewri te
inhibited) •
~!H~~!U!1B!
Entry for local graphic device enable and
disable function (from DKKCPVEN and unstacked
CPEXBLOK).
Invoking
CP
ENABLE/DISABLE
commands, start or
terminate local 3270
display
(and supported print devices)
and
3066 console activity.
DKKFREE
---Performs enabling function.
Gets storage for
IOBLOK and TRQBLOK generation.
DKKGRB, LOGUSER
---Porm and-wrIte out the logo at the screen.
DKKGRB, ATTNINI
---unsolIcltedattention
for
RDEVBLOK
(enabled) •
DKKBLDVK
---Bulla LOGON VKBLOK for logon process.
~!!~£I1!!H~
Enter console
input.
function
mode
for
terminal
~~K!Q§2~
Schedule request to clear screen preparatory
to logon.
DKKDSPCH
---'EiIt-to dispatcher to wait for interruption.
successful logon per the next interruption
begins the operation of building the user's
virtual machine.
DKKGRAIN
---Local 3270 display and 3066 interruption
entry from dispatcher.
I!1!!§£1!.~!l
From the IOBLOK, locate the real device
blocks related to the interruption. Analyze
IOBLOK CSW and condition code and the I/O
operation to determine read/write sequential
action. For unit error, retry 10 times (if
applicable).
If recovery fails,
log off.
For ATTN interruptions, attempt to log on the
new
user
if unsolicited
ATTN
occurs.
Otherwise, set up for READ CCW string.
DKKFREE
---Get-storage for function and build CONTASK,
IOBLOK, TRQBLOK.
220
to
screen
(unless
Q~!HQ'§2!!
Perform start I/O.
DKKDSPCH
---iilt-to dispatcher.
Q~!~!!n!£
Entry point to process CONTASKS queue for
local 3270 and 3066 devices.
DKKFREE
---Get-storage for IOBLOK and TRQBLOK.
DKKGRB, BLDCCWS
---iiecute-CENTASK, if appropriate. If not DMKDSPCH
---'Eilt-to dispatcher.
LOCATE AND VALIDATE AN ISAM READ SEQUENCE
Qn!!.§111!!
Entry from DKKCCW modules to locate and
modify an ISAK CCW string_
using the IOBLOKs
IOBCAW locate the RCWTASK.
Check for the
ISAK read CCW.
DMKISK, CHKRD
---Check--for the correct
ISAK sequence as
follows:
1.
2.
3.
4.
5.
6.
The last CCW in the RCWTASK is a TIC.
This RCWTASK points to the ne~t RCWTASK
with a minimum of 2 CCWs.
The first modified
CCW is in real
storage.
The last byte of the ISAK read overlays
the operation code of the first CCW in
the next RCWTASK.
The TIC in the RCWTASK is to the next
RCWTASK's first CCW.
The date address of the first CCW in the
next RCWTASK is the same address of the
ISAK read+1 as it is in real storage.
IBK VK/370: System Logic and Problem Determination Guide
D!KFREE
---storage obtained for seven double words save
block.
D!KISft, CHKTSK2
---institute--the ISAft
read modification as
follows:
1.
2.
3.
4.
5.
Set the read to point to the save block
data area.
Set the CP TIC to point to the .odified
CCW in the same block.
Set the modified CCW
(seek head) in the
save block to point to the save block
data area.
Set the CP TIC in the save block to
return to the RCWTASK following the
modified (seek head) CCW.
Set the search CCW in the RCWTASK to
point to the data area in the same
block.
DOUBLE WORD SIVE BLOCK
r-----1
1
1
1
1
1
1
.
Read Address
1 (2) TIC Address
Unused
Read Data. Area
I
1(3)
Modified CCW
1---------------------TIC to RCWT AS K
1 (4)
1
1
1
1
Real Read CCW
-,
1
1
1
1
1
---I
1
DMKIOS, IOSSIO
---set the--subchannel path busy and chain the
active IOBLOK from the RDEVBLOK.
DftKIOS, IOSSIO
---Locate-caller's CAW and issue the SIO. Check
SIO completion. Returned condition code sets
sequel action.
cc=O indicates successful
start; cc=l, ccw
stored, initiate sense
operation; cc=2, busy condition, retry or
requeue IOBLOK;
cc=3, fatal
error (not
operational, stack the IOBLOK and return to
caller.
DftKIOSHA
---Entry point for haltin9 a device. If device
is not active, return to caller.
If IOBLOK
active, reset the IOBLOK to halt the device
and mark the device reset in RDEVBLOK.
DftKIOS, lOS lOKI
---If-the-channel path is busy with a burst .ode
operation, stack the IOBLOK to halt the
operation when the
channel path becomes
available. Return to caller.
1
1
1
1
1
Real TIC CCW
________________________________
-J1
L
D!KISM, CHKTSK2
---Return-tO-DMKCCW module via SVC 12
DftKIOSIN
---Entry from I/O new PSW. Check old PSW.
If
problem mode, save CPU status in the VKBLOK.
DMKSCNRN
---Locate
RCHBLOK, RCUBLOK,
RDEVBLOKs
for
interruption unit.
1HU~'!!Q~£
SCHEDULING CP AND VIRTUAL !ACHINE I/O OPERATIONS
AND INTERRUPTION HANDLING
~~K!Q~2R
Entry to process CP generated I/O. Flag the
IOBLOK as a CP generated event. Initiate I/O
if path to real device is free (available).
If not, queue the IOBLOK and return to
caller.
.!H~Kl;Q.22.!
Entry to process IIO for virtual machine I/O
operations.
ftARK
IOBLOK
as
not
CP
initiated. Save VMBLOK address.
If path to
the VDEVBLOK or the VDEVBLOK is busy queue
the IOBLOK and return to caller.
DftKIOS,IOSTATDV
---i~avarlable status, start the I/O and return
to caller.
Process
dedicated
channel
interruption
condition. If control unit end or channel
available interruption occurs,
restart the
operation, if interruption does not occur
stack it.
DftKIOSIN
---If--the IOBLOK is not active on RDEVBLOK
interruption, call DKKIOS.
DMKIOS, IOSENSE
---Schedule---sense
operation, then
go
to
dispatcher.
DKKIOS, IOSRSTRT
---Por PCi--or-CE interruptions, copy and stack
the IOBLOK •
DMKCNSIN
---Process PCI or CE interruptions, if related
to local graphic device or nondedicated TP
line.
DftKIOS, DOSENSE
---Por split-seek complete interrupt, rechain
the seek and reschedule operations.
DMKSTKIO
---stack IOBLOK and restart any units freed by
the interruptions.
DMKDSPCH
---Exit-to dispatcher.
DMKIOS, IOBSTART
---if-ItO-request has not been reset, save the
address of the active IOBLOK and set device
busy. If the device is being reset, unflag
scheduled device and scheduled control unit.
stack the IOELOK and restart the device.
section 2. Method of Operation and program Organization
22\
TERMINAL CONSOLE I/O
3215, AND OTHBRS
CONTROL, START/STOP, 3210,
DMKCNSBN
---Per-unstacked CPEXBLOK, on enable or disable
function, check current status of the current
real device and set flag in RDEVFLAG. Build
CON TASK and IOBLOK.
:Q~KIQ§2~
Issue SIO for enabling
and check return.
DMKDSPCH
---jiIt-to dispatcher.
or disabling function
:Q1H~£NS!£
Entry from DMKQCO module.
Build I/O CCi
string as defined by the console device
type.
Also select the proper line code to
interface
with
the device.
place
in
CONTASK.
For output CONTASK determine the
correct translation
table applicable
to
terminal communications (DMKTBL).
To append
proper control character to the data stream
for the particular device type, refer to the
following labels:
• DMKCNS, IBCWTTY
TeletypewrIters
• DMKCNS, IBC2741
2741~-3767-----
•
•
1050~-1051-----
DMKCBS, IBC3210
3210~-3215-----
DMKCRS, IRCFIlIIS
---Attempt-to--start I/O by halting the current
operation, if the operation is a 'prepare'
CCW or
the input is
a read
and the
forthcoming output
is a
priority write
CON TASK.
DMKPREE
---Get-storage to build IOBLOK, if needed.
DMKCRSIN
---Set-return address in IOBIRA.
start I/O.
If busy condition
build
CPEXBLOK
and
queue
execution.
DMKDSPCH
---EiIt-to dispatcher.
:QJ!!£2!U~1
Process completed output contask.
:Q~~£1!§'!!!
Interpret
interruption
status
and
CCW
residual count for input CON TASK completion.
DMKCN S, CNINCT
---Validate--Input data and control characters
and translate to EBCDIC from line code.
DMKTRMID
---Attempt to identify, if applicable, the line
code
identification;
PTTC/EBCD
or
correspondence.
DMKCNSED
---Perform line editing of the input buffer.
DMKCNS, CNSRT41
---Prepare--and issue control CCis to request
status information from the terminal.
DMKCNSIN, CNSCTAK
---por-contral-task interruption return, examine
the interruption status according to control
task function:
• DMKCNS, CNSTAK
Reset-cont~or-task.
•
DMKCNS, IBC1050
:QJ!K!Q§2~
assume an attention interruption and build a
'prepare' ccw for the 2741.
DMKCNS, CNSLOGF
---Por unIt-Check and timeout condition - logoff
the virtual machine and re-enable the line.
DMKCNS, CNSRTRY
---Por data--check and other conditions, retry
the previous operation.
DMKCNS, CNSCTID
DevIce identIfIcation.
• DMKCNS, CNSCTPR
Attention-sIgnal.
DMKCNS, CNSCTPR
---wrIte--'VM/370
Online'
interpretation
of
response determines retry,
or build new
CONTASK and execute or stack or process next
CONT ASK.
:Q~!,g£.!!]!
Process completed CONTASK requests.
If no
tasks remain for the terminal, set IOBLOK's
IOBIRA to DMKCNSIN and link the IOBLOK to the
user.
DMKDSPCH
---jiIt-to dispatcher.
encountered
for
later
CONSOLE SCHEDULING
:QJ!!2£!!!!:Q
SVC entry to build CONTASK for
Set the input buffer to zeroes.
DMKFREE
---Get-storage to build CONTASK.
:Q~~£!§!!,
£~§~~A~
For
an
active
input
task
halted,
RDEVPLAG=RDEVHIO to process priority output
task.
DMKPREE
---SuIid COBTASK for reverse break CCws.
DftKCRS, CNSBREAK
---Move -the-Input CORTASK following the last
priority write output COBTASK on the chain.
DftKCNS, CBSIOUC
---Por unIt-check with intervention required,
222
:Q~!2£!,
input data.
§!2Y§Y§
Stack CONTASK on RDEVBJJOK,
if RDEVCON was
zero.
If not, exit
to the appropriate
interrupt handler per RDEVTYPC and RDEVTYPE
or DMKSPCH
---jiIt to dispatcher.
:QJ!!2£!!1
SVC entry to build CONT1SK for output data.
strip trailing blanks from output message,
IBM VM/370: system Logic and Problem Deteraination Guide
.o~ify byte
count and determine real device
destination.
DftKFREE
---Get-storage to build output CONTASK.
.!HUS.2C N,
!!!~2£!
Update CON TASK CCW message byte count for the
message text, terminal
and line control
information and (i~ appropriate) time sta.p.
DMKCVTDT
---if--time stamp required, get the value for
CONDATA area.
DftKVSPVP
---Spool console message, if VDEVFLAG=VDEVCSPL.
.!2.ftK2CN,
~R§'~A.ll
.!H1K2~~,
!AK!!!~R
If message data
X115 1 , create a
line.
contains carriage returns,
separate CONTASK for each
On first CONTASK Or priority CONTASK, enqueue
on
chain from
RDEVBLOK in
appropriate
location,
then
call
related
interrupt
handler.
!tt!K2~.I, !!!!~!!~
If NORET or DEFRET specified, build and stack
CPEXBLOK to alert the interruption handler
and return via EXIT SVC otherwise go to
specified interruption handler.
!H~KQ~.I1Q
Entry via SVC to disconnect and logoff a
virtual machine as a result of transmission
line failures. place the virtual machine in
a wait state, VftRSTAT=VftCFWAIT.
DMKSCHDL
---ilter virtual machine to unrunnable state.
DKKFREE
---Get- storage for message
for the system
operator •
.!2~!~~~!!~,
~~!2£.I!!~, ].ft!£!~]~, ]~K2!2!~
Fill in message variables.
DMKSCNR, DKKSCNRD, DftKCVTBH, DftKSYSNK
---FIll in-message varlables.-------~~K2£!!!1
Send the
operator.
~!1!2~~,
user
disconnect
message
~§'~2~!!Q
to
Build TRQBLOK, if needed, for 15
delay, schedule it, and exit via SVC.
the
minute
]~K2£!, ]~£11Q2
After time elapse, TRQELOK is unstacked and
VHOSTAT is set to VftKILL for inevitable
DMKUSOFF logoff operation.
DKKDSPCH
---ExIt-to dispatcher.
3704/3705 INTERRUPTION HANDLER
!H~!!Hm!£
Entry via
DMKQCN or
via CPEXBLOK
for
3704/3705 resource initialization.
Locate
the NICBLOK and check resource avaiability.
~~KR!~,
1!~!1.!!!!
~.ftKRNH,
~!2~!2!
!H1!!! NH,
~!2!!.I2
For resource
CONTASK save
DKKQCNET.
unavailable, set
area and return
RC=12 in
task via
For resource available, set CONTASK values
per input and output task requirements.
Kove CONTASK
chain.
]~K!!!M, !!!!~l!!!l
from RDEVBLOK chain
to NICBLCK
DftKRNHIC, RNEXLST
---Search the--SICBLOKS for CONTASKs to be sent
to 3704/3705, build and chain for output.
DftKRNH, RNCHAIB
---Perform---necessary
function
for
each
resource.
~11!!Q2Q!!
Start ou tput I/O opera tions.
DKKRNH, RBICHBl
---Return-via-a7.
DftKRBHND
---Entry via SVC to schedule resource control
tasks •
DKKRNH, RBHBDTK
---Bulld--control CONTASK and enqueue it for
execution.
DKKRNH, STKCPEX
---For NORET--specified, build
and stack a
CPBXBLOK to perfor. SVC exit.
DftKRNH, RNDEXIT
---ittempt-to-start output via GOTO DKKRNHIC.
DKKRNH, RBFDI sc
---Entry-for-3704/3705 recovery.
DKKBLDR
---Load the 3704/3705, if it was not previously
loaded.
~~K~R!
Get
storage
to
build
CKPBLOK
(telecommunications
control
block),
if
necessary.
DMKRNH, RNSBITS
---Record-actIve line and enabled terminal flag
bits.
]~!2£!]~
Clear CONTASK chains.
]~!2£~1:.Q
Force disconnect to all active users.
DMKNLDKP
---DUMP-the 3704/3705.
DKKNLDR
---Reload the named program.
Q!1!!!!~!m
I IPL
On
complete'
resources.
DKKFRET
---Release the CPEXBLOK.
signal,
reenable
~11!~§.f£!!
Exit to dispa tcher.
DftKRNHIN
---Entry via IOBLOK to perform input and output
interruption processing.
DKKRNK, RNIOBRR
---por Input--process
failure.
Analyze the
failure and if related to the 3704/3705 and
not to a particular resource, either retry or
dump and reload.
DKKRNH, READBUF
---jnterpret---response codes
for each
BTU
received and
schedule necessary
control
operations.
DKKRBH, CKPRBAD
---Generate-response to a read error.
DKKRNH, CKPWRITE
---Generate-response to a write error.
DKKRNH, CKPCONT
---Generate-response to a contact task error.
DKKRNH, COMDISC
---Generate--response
to a
disconnect task
error.
DKKRNH, COMCNTL
---Generate-response to a control task error.
Q~!!!!~, !!!~.Q1.!1:
Generate response to a unsolicited read.
On 3704/3705 available
condition, search
NICLIST and build an IOBLOK if required.
~~!2£!]~
Return completed CONTASKs.
section 2. Method of Operation and Program Organization
223
DMKRNH, RNSTART
---Attempt-te-restart the 3704/3705.
DMKDSPCH
---Exit-to the dispatcher.
R§.§!!!!!
!!~!i!Q~,
Process POLL
conditicn.
SIO
on a
no
CONTASK
queued
!!~!i!.Q~.2]
~!HH!!!J1'!!!
Entry via IOBLOK to perform input and output
interruption processing.
DMKRNH, SCHREAD
---on- output:- examine
Interrupt status per
IOBLOK values and if ATTN, build and start a
read CCW sequence.
!!!HH~!!!!,
!!!!IQ!B!~
If unit check and fatal, dump and reload the
3704/3705.
DMKRNH, RNOREAD
---I~pend[ng-iTTN cleared via SIO
]~!s'IQ'§.2B
Reschedule write operations.
DMKRNH, RNSLOWDN
---I~
unit---exception,
set
reschedule rejected CONTASKs.
RDEVSLOW
and
!!~!s'.2CN!!l!
Return only CONTASKs
without CONRESP or
CONSPLT set.
Retain
others until final
response is received.
I:MKRNH, RN START
---Attempt-to-restart the 3704/3705.
DMKDSPCH
---EiIt-to dispatcher.
HANDLING
LINES
REMOTE
3270 WITH
I:MKRGBEN
---Entered when
the
command is issued.
BINARY
NETWORK
SYNCHRONOUS
ENABLE/DISABLE
~~!i!BJ1!J1!
Get storage
for the
necessary CONTASK,
IOBLOK, and if applicable, BSCBLOK.
DMKRGB, LINESUP
---set up-requIred CCWS and control data in the
CONTASK for tasks.
These tasks include:
enabling
the
binary
synchronous
line,
enabling a device, LOGO messages, screen
formatting,
and
disable line
or device
(logoff) •
~~!s'!!!!!l~
For logon function build logon VMBLOK.
.!HHSIQ~.Q]
Start line I/O or device I/O, for
condition.
DMKRGB, RGFTASK
---Per busy--condition, build CPEXBLOK
to caller.
DMKRGAIN
---Entry from DKKIOS,
examine line interruption
condition. Discard any of the :following and
go to the dispatcher:
nonbinary synchronous
line,
copied
IOBLOK,
unsolicited
interruption, bisync line fl.agged not-in-use,
non-terminal class device.
!!~!i!!'§~,
fA.1A1~!!
!!~!i!!§A,
!!!.§A.§!A
For IOBFATAL
condition or
any
condition code, free all related
IOBLOK, IOERBLOK, and BSCDLOK.
non-zero
CONTASK,
Log off all affected users on that line.
DKKMSWR
---send message to the system opera tor.
DMKDSPCH
---EiIt-to dispatcher.
DMKRGAIN
---j~-IIne or terminal response
did not fall in
the previous category, process via TP code
branch. The code in the fifth byte of the
ending ccw or IOBCSW-8.
TP Code
Function
TPOO---Errer-Handling CCW
TP01
Enable/disable function
TP02
Write EOT (sequence prior to polling
and addressing)
TP03
write polling or addressing characters
TP04
Handle station's status and sense
message
Read response to addressing
TP05
write response to text
TP06
TP07
NO-OP following POLL command
unit exceFtion condition
TP08
(timeout)
A11 reset commands
TP09
TP10
Read/write text
Read response to text
TP 11
DKKDSPCH
---Exit-to'the dispatcher •
not busy
and exit
DMKRGBIC
---Entry from DMKDSP.
On a not available line
condition, exit to dispatch.
For available
line,
process the associated CONTASKs by
queueing the
related resource
from the
NICBLOK.
224
Process selection SIO on available resources
and
not in
control
mode per
NICBLOK
conditions and the CONTASK CONSTAT field.
DMKDSPCH
---ExIt-to dispatcher.
DKKBSCER
---Entry via DKKIOS and SVC 8 to process errors
related to the binary synchronous line unit
check and channel error conditions.
On first
error pass, move the IOERBLOK pointer from
the IOBLOK to the RDEVBLOK, reset retry and
fatal flags, set the ERP flag and call
DMKFREE.
DKKFREE
---~;t-free
storage for a work area for retry
CCws.
IBK VM/370: System Logic and Problem Determination Guide
DMKBSC, NOTPIRST
---ona-not--iIrst
error condition, test for
unrecoverable error condition. Unrecoverable
errors include:
program check, protection check, chaining
check, equipment check, interface control
check and channel control checks. If one of
these,
notify the system operator.
Rese~
flags, initiate error recording and
DMKPREE
---Free IOERBLCK.
!H1K!OS2~
Go back to scheduler.
DMKRGP, UNITCK
--~na1yze--TP code, sense data CSW
count and retry count to determine
IOBPATAL flag setting.
residual
retry or
REAL STORAGE ALLOCATION AND PAGE MANAGEMENT
DMKPTRAN
---Enter via the TRANS MACRO per paging request
as
determined
by DAT
created
program
interrupt (page or segment exception).
DMKPTR RESTART
---Return-to-Ca11er, if virtual address in R1 is
beyond range of user's directory specified
storage si ze.
DMKPTR, ADDROK
---Check--page residency via LRA
(LOAD REAL
ADDRESS) operation.
DMKPTR, TESTLOCK
---For resldent- page, lock page in storage (if
appropriate) •
DMKPTR, GETRADD
---s;t real--address in R2, make PAGTABLE entry
valid. Set cc=O and exit to caller.
DMKPTR, INTRAN
---For page-- not resident
but in
transit
(SWPTABLE, SWPPLAG), place virtual machine in
locate mode.
Locate CPEXBLOK for the real
page requested and chain another CPEXBLOK
with a return address of TRANRETN, to the
same chain.
DMKPTR, TRANRETN
---iiter-page--Is no longer in transit, restore
registers
and
return
to
RESTART
for
processing.
DMKPTR, GETPAGE
---Rec1aIms-a-page on PREELIST (CORETABLE).
DMKPTR, DOlO
---For page-that is not in storage, do setup to
read in the page.
DMKPTR, CKDEPER
---For DEFER-option passed in R2, build CPEXBLOK
to return to user after page is in storage.
DMKPTR, PAGIN
---ifter-the-page is read into storage DMKPAGIO
process, place its CORTABLE entry into the
user's page list then remove the user from
the wait state and update the lock count (if
required).
DMKPTR, GETRADD
---set reaI--address in R2, make PAGTABLE entry
valid. Set cc=O and exit to caller.
DMKPTRPR
---Per-the caller's code in R2, obtain a page
frame DMKPTR, GETPREE
---Obtain-page-frame via CORTABLE reference then
exit to caller.
DMKPTRPE
---Entry via CPEXBLOK, check page availability
via flush list (DMKPTRPL), if none available
steal a user's page.
!H1!H~l!i,
.§11ECl
The SELECT routine is entered to replenish
the PREELIST from the flush list or user's
pages that have not been referenced.
DMKPTRPT
---Process pages to be returned by chaining them
to the PREELIST. On page returns DEPER page
requests are processed first.
DMKPTRLK
---Iii-locking a page in Real Storage (addre.ss in
R2), add 1 to lock count; if previously
locked,
and exit
to
caller.
If
not
previously locked, unchain the CORTABLE entry
from the user's page list and set the lock
count to 1.
DMKPTRUL
---To-unlock a locked page, reduce Lock ountby 1
and exit. If the lock count is now equal to
zero, place CORTABLE entry on user's page
list prior to exiting from routine.
READING/WRITING
STORAGE
A
DASD
PAGE
TO/PROM
VIRTUAL
DMKPGAGT
---Entered via SVC call to read in DASD page
into storage.
DMKPGTPR
---Release DASD
space that
was previously
occupied by this virtual storage page.
DMKRPA, RESIDENT
---Reiove--resIdent page frames from the user
list.
DMKPTRPT
---Place these page frames on the free list.
Q1Us~g!, ~~Q~l!!~l!
Update the SWPTABLE with disk address in RO.
DMKPTRAN
---Bring the page into storage.
DMKPRA, EXIT
---Put rear-storage address of the virtual page
is passed back to the caller in R2.
DMKRAPT
---Entered via SVC call to write out a page to
DASD storage.
DMKPTRAN
---Locate the page to be moved and lock it.
DMKPRAPT
---store all registers in CPEXBLOK and flag
CPEXRO as a write request.
DMKPAGIO
---Write the page.
l!1!!Sg~!,
IQ]II!
Decrement page wait count.
take user out of page wait.
If zero results,
Section 2. Method of Operation and Program Organization
225
DMKPTRUL
---Unlock the page frame.
Return to caller.
!H1EY!IA~
Entry via BALR when an EC mode virtual
machine needs a shadow table generation and
update or purge operation.
DMKVATMD
---Get--storage to create shadow table, Flag
VMBLOK to show shadow table existance.
DMKVATBC
---Free-shadow page, segment and copy segment,
when user leaves Ee mode or alters CR o.
DMKVATRN
---Entry to perform third level to first level
translations and third level translations to
second level address translations. Use TRANS
macro to access virtual segment and page
tables to get the virtual page into real
storage.
DMKVATLA
---usIng the TRANS macro to access the virtual
segment and page tables, pass the resulting
page and displacement to DMKPRVLG.
DMKVATPX
---Invoked by DMKPRGIN when a paging exception
is received for an EC mode virtual machine.
DMKVAT, SETUPEX
---Perfor;--set up operation and develop page
table address.
DMKPTRAN
---Get-the page.
Dt!KVATPX
---Update the shadow table.
DMKVATSX
---Invoked by Dt!KPRGIH when a segment exception
is received for an EC mode virtual machine.
Dt!KVAT, SETUPEX
---Perform-setup operation, then invalidate the
shadow page table or if none exists, allocate
a new shadow table and set it invalid.
DMKVATPF
---jntered via Dt!KVATPG from DMKPRG to simulate
pseudo page fault interrupts when a paging
exception occurs with pseudo page faults
interrupts enabled.
Dt!KPTRAN
---BrIng in the DASD page.
Dt!KPRGSM
---Reflect program check X'14' to the user.
DMKVAT, PAGRES
---When the--page becomes resident in storage.
Build the PGBLOK, set high order bit in the
translation exception address field,
DMKDSPGH
---jilt-to dispatcher.
DASD page and place it in Rl. Return to
caller.
DMKPGTRPR
---intry-to deallocate DASD page used for paging
and Spooling.
Via RDEVBLOK
locate the
RECBLOK and reset appropriate bit in the
RECBLOKs RECMAP and adjust the member of DASD
pages in use.
If all the pages on the DASD
cylinder have been deallocated, deallocate
the cylinder. Exit to caller.
DMKPGTSR
---intry to release a group of DASD pages no
longer needed for spool file use.
Per Rl,
find RECBLOK and dummy RECBLOKs and reset the
RECMAP bits as
specified.
Free related
RECBLOKS, if complete deallocation occurs.
DMKPGTCG
---Entry for allocation of enough DASD spool
space to record a 3704/3705 dump.
Scan
RDEVBLOK and associated ALOCBLOK for enough
contiguous available space to record the
dump. When found, flag cylinder as allocated
and build and chain the required RECBLOKs.
DMKPGTVG
---iiMKPGT contains an intel:nal table, PAGET1!,BL,
in which the allocation of page frames for
the CP paging VMBLOK is kept.
The PAGETABL
is scanned for a zero bit denoting the page
frame is available.
The page is marked
allocated by setting the bit to one and the
address of the page frame is returned to the
caller in
Rl.
If no page
frames are
available, a CPEXBLOK is built and queued to
the deferred request chain.
DMKPGTVG
---E;try to release a page of virtual storage.
Check the chain of deferred requests.
If
there are none, reset the page bit in the
PAGETBL to
0 and exit to
the caller.
otherwise, give
the page to
the first
requestor in the deferred chain and stack his
CPEXBLOK for the dispatcher.
SHARED SEGMENT STORAGE MARAGEMERT
Dt!KVMIPS
---j;try via DMKPRT because
a shared page
(address in R2) has been detected by CPo The
virtual machine (VMBLO~ that caused the page
alteration has its named system released.
The original page swap tables are copies.
DMKRt!SG
---ihe-running virtual machine is informed of
the share page violation.
DMKVMASH
---Entered via DMPDSP/BALR, the shared page
table are
examined for hardware change bit
being on.
The resulting condition code is
reflected to the caller.
ILLOCATIOR IND DEILLOCATIOR OF DASD SPACE
TEt!PORIRY DISK STORAGE MANAGEMENT
DMKPGTPG
---intry to search and allocate a DASD page for
paging/spooling.
Dt!KPGTSG
---~e;rch
appropriate
RECBLOK
chain
for
available DASD page.
If none found, locate
next available cylinder and construct a new
RECBLOK, calculate address of the allocated
226
Dt!KTDKGT
---Entry to
allocate temporary
disk space
(T-disk).
With RO equal to the number of
cylinders required and R1 equal to the device
type, locate RDEVBLOK and related ALOCBLOK's
ALOCMAP.
If no allocation space is to be
found, return to caller with 0 in RB.
If
IBM Vt!/370: system Logic and Problem Determination Guide
allocation is successful, flag ALOCMAP, with
X'AA' as allocated and put first cylinder
address in Rl and RDEVBLOK pointer in RS and
return to caller.
DMKDSPCH
---ExIt-to caller.
Q~~f§~l~
Entry to examine user's page tables for a
named system. Locate segment table and check
each page table header for a named system.
If found, set cc=O; if not, set cc=2 and
return to caller.
PAGING I/O SCHEDULER
DMKPAGIO
---intry to initiate page I/O activity. Using
preformatted IOBLOK from IOBSTACK, fill in
the CCWs with DASD opcode and values derived
from CPEXBLOK swap table and core table.
Chain the CPEXBLOK on the in-transit queue.
DMKPAG, GETRDEV
---plnd the-Paging RDEVBLOK.
DMKPAG, FINDIOB
---search--ioBLOKs seeking the same cylinder
address.
If found,
chain the
channel
programs together with TICs.
DMKDSPCH
---EiIt-to the dispatcher.
DMKPGSPS
---intry to release storage containing a named
system passed by the caller. Search the page
tables looking for a header equal to the
named system. If found, release the swap and
page tables and build new ones, if the
address range still lies within the user's
virtual storage size.
~~!fA§, 2Q~Y~R!Q
DMKFREE
---intry to obtain a block of storage, validate
input doubleword request (RO).
DMKFRE, FREESUB
subpooI
size
reque~t,
index
into
SUBTABLE.
For correct S1ze block found,
remove block from chain and put the address
of the block in Rl. Return to caller.
DMKFRE, FREE02
subpool size not found condition get next
large subpool size. Remove block from chain,
put address in Rl and return to caller.
DMKFRE TRYSPLIT
---Por subpool-that cannot honor request, start
search a
30 doubleword
end for
block
requirement.
When a block is found, split
block (if necessary) and give caller address
of his portion in Rl and chain the remainder
to the appropriate subpool size.
Return to
caller.
DMKFRE, CLEARSAV
---1£- no--block can be found to honor user
request, call
DMKPTRFR
---Petch a page from the dynamic paging area.
Chain
it to
the
free storage
chain.
Processing then continues.
See entry DMKFRE,
FREESUB.
If no IOBLOKs with
found -
some cylinder address are
R~!!Q~2~
Start the I/O operation.
DMKDSPCH
---ExIt-to the dispatcher to await interrupt.
DMKPAG, UNTRANS
---upon Interrupt return, unchain the CPEXBLOK
from the intransit queue.
DMKSTPCP
---stack all deferred requests for execution.
DMKPAG, UNSTACK3
---Return-iOBLOK to IOBSTACK or free it.
DMKPAG, OVERHEAD
---Calculate-paging load and store it, the TOD,
and other values in PSA.
DMKDSPCH
---Eilt-to dispatcher.
RELEASE VIRTUAL STORAGE PAGES
DMKPGSSS
---Entry to release partial virtual storage.
Per Rl (address of first page to be released)
and R2 (address of last page to be released)
set partial entry flag.
R~!fi~~Q
Entry to check for
shared segments and
decrement usage count.
Some registers and
flag full entry condition. Examine VMSHRSYS
for shared segments.
If so, decrement use
count. On 0 use count unchain the SHRTABLE
from the active list.
DMKPGS, CKCLEAR
---On- NOCEAi-exit to caller.
If not, store
number of release pages in RB.
DMKPGS, PAGOUT2
---Locate-page- and swap tables for the segment
to be released and index to the entry for the
first page.
DMKPTRAN
---inItIate paging,
and when
paging stops
release the page frame.
DMKPGS, NEXTPAGE
---a-value:-----
FREE STORAGE MANAGEMENT
---oi-
---Por
DMKFRERS
---Entry to return all sub pool blocks to the
free
storage
chain
per
the
SUBTABLE
reference, as each sub pool block is released,
its address and length are placed in Rl and
R2 respectively.
Branch and link to FRETOS
to return the block to the free storage chain
(DMKFRELS) •
Repeat action
through
all
subpools.
Return to caller.
DMKFRET
---Entry to restore block to subpool or free
storage.
Per
RO and
Rl
(number
of
double words to be released and and address of
the first double word, respectively), the
subpool sized block is
returned to the
appropriate subpool.
Update the pointer in
the SUBTABLE.
DMKFRE, FRET21
---1£- subpool size block being returned' is
within the dynamic paging area, process as a
block of more than 30 doublewords.
Section 2. Method of Operation and Program Organization
227
D~KFRE, FRET20
---SIocks--larger than 30 doublewords to be
returned are merged into the free storage
chain indicated by D~KFRELs.
D~KPTRFT
---Restore page to dynamic page area; if a
complete page is alloted, blocks belonging to
the dynamic paging area can be built.
D~KFRE, FRET03
---Return--a-block of storage to free storage
chain by merging into the chain storage
addresses in an ascending order of sequence.
Return to caller.
CP INITIALIZATION AND
TER~INATION
PROCEDURES
DMKCPI, NPSWS
---iocate--an available primary or alternate
system console (PSA values).
DMKCPI, NOTCHNG
---SuIld-u;er-directory page list per DHKSYSUD.
DMKLOGOP
---iog-on the system operator.
DMKCPI, STARTSYS
---iorce--iiOii--iiucleus modu.les
to DASD page
device.
DMKIOEFL
---inItIalize error recording cylinders.
DMKNLDR
---Auto load 3704/3705; if appropriate.
DMKCPVAE
---Enable 270X lines, if appropriate.
DMKPTRUL
---ijiilock CPI as initialization is complete.
DHKDSPCH
---iwaIt interrupts.
D~KCKPT
---InItial entry point to load the system after
loading the first module, DMKCKP, from the
system residence volume.
Check CPID in PSA
for startup method.
DMKSAVRS
---i~r--CPID eqaal to
not warm or not CPCP,
insert COLD and load the nucleus.
Then
branch
to
DMKCPINT,
to
perform
CP
initialization.
.!H1!£!fl
!Q:!~!!~
ON CPID=WARM or CPCP, halt and drain all I/O
devices and remember enabled terminals.
DMKCKP, NEXTCH
---DMKRSPCV-to validate warm start cylinder.
DMKCKP, CLOCKOK
---save accou;ting data, log message, SDFBLOKs
and enabled terminals and lines on checkpoint
cylinders.
DMKCKP, CHKOS
---save spool records allocation and spool hold
queue blocks on checkpoint cylinder.
D~KCKP, SHUTSYS
---if-normal--shutdown indicated, issue message
to system operator and load disabled wait
state code X'008'.
D~KCPIlU
---Entry
point
to
perform
system
initialization.
DMKCPI, KEYLOOP
---DeteriiiIne--real
storage size,
initialize
CORTABLE,
Allocate
free
storage
and
initialize system paging tables
DMKCPI, CPIHIP
---Check-vIa-BIO for online and ready status of
all DMKRIO generated devices.
DMKCPI, CPISTCAW
---Read -volume-labels and aatch to RDEVBLOK,
RDEVSER.
DMKCIP, DMPALLOC
---Allocate-dump file to systea device.
DMKCPI, ALOCLF
---suild-allocation block for CP-owned devices.
DMKCPI, MICTEST
---Test -for--virtual
machine assist feature
availability If available,
build MICBLOK and
link to VMMICRO.
228
DMKWRMST
---Entry from DMKCPI
initialization.
Check
R2=01, if so go to DMKWRN, WARMCLR for cold
start. Check Warm start cylinder for 8 byte
XFFs identifier.
DMKWRM, ENABLERT
---jf-enable--records on, warm start cylinder,
enable appropriate RDEVBLOKs.
DMKWRM, EN370S
---if-warm-;tart record indicates, set flag for
auto load of the named Nep program.
DMKWRM, ENR3270
---inable-bInary synchronous lines by clearing
NICBLOK Offline flag, (if appropriate)
DMKWRM, ACNTRT
---iuIld--ACiiBLOK,
load it with warm start
cylinder data and chain it.
DMKWRM, WARMLOG
---SuIld-buffer and load it with the saved log
message.
DMKWRM, WARMSPL
---i'Uild--SPPiioKS and fill with appropriate
printer, punch and reader spool data.
DMKWRM, WAR HOLD
---suIld-SHQSLOK and move hold queue record data
to the new block and chain it to the hold
queue chain.
DMKWRH, . WARMCLR
---Clear-i-bites of record 1 on the warm start
cylinder. Check CPID again.
DMKCKSWH
--~Por--CPID=CKPT or FORCE,
reconstruct spool
checkpoint records.
DMKCKSIN
---ior-CPID=NOT CKPT or NOTFORCE, initialize the
checkpoint cylinders.
DMKCKSPL
---pIles in the systems spool hold queue are
added to the checkpoint cylinder.
DMKWRM, GETDISK
---Read iii-the-remainder of warm start data.
.!HUS£.f~2!!
Entry paint results from involing CP SHUTDOWN
IBM VM/370: System Logic and Problem Determination Guide
command.
Close
active spool
files for
callers or operator console.
DflKCPS, DASDCH
---vIa -RDEVBLOK,
locate and
record
DASD
statistical data.
DflKCPS, DASDCHI
---Put cpcp-Into CPID to denote shutdown.
DflKDMPRS
---set--up CAV, CCVs and issue IPL to system
residence device to reinitialize CPo
DMKCKPT
---save spooling and accounting data.
DMKMONSH
---stop-monitor tape activity.
DflKCPI SHUTSYS
---sense-shutdown flag, issue DftKCPI961V, enter
disable wait state code X'006'.
Entry occurs via ABENDOOO condition or by
pressing system console RESTART button. Save
PSA values. Determine if dump is full or
just CP portion.
DftKDMP, DftPftSG
---Pormat-and- issue ABEND message to operator
and transfer to DMKDKP and DMPDASD.
!HHUH1g, Ql1fQ!'§Q
Write out a defined amount of storage or all
storage to selected DASD device.
DMKDftP, DSKEND
---Place-sendIng record number and the system
file number in the dump file SFBLOK.
DMKDMP, RECSRCH
---Chain--dump-file RECBLOKs to RDEVBLOK, and
link dump file SFBLOK onto the system reader
chain.
DftKDSP RESTART
---Restart-the system on warm start indication.
DftKDftP, DMPTAPE
---Dump -cP--storage or
all storage to the
selected Tape
Drive per
specified tape
parameters.
DftKDftD RESTART
---Restart--the
system, if
warm start
is
indicated.
DftKDMP, DftPPRT
---Dump -cP--storage or
all storage to the
selected printer.
DftKDftS RESTART
---Restart--the
system, if
warm start
is
indicated.
DftKCFMBK
---Send-read CCVs to the terminal for LOGON or
DIAL response.
DMKTRMID
---On-response determine translate tables to be
used.
DMKFKBK
---valIdate command and transfer to DftKLOGON.
DKKLOGON
---LOGON command execution.
DftKDIAL
---DIal access linkage to multiaccess system.
Ql1!s'yQS
Via user directory access, validate user
logon
eligibility.
On
acceptance
of
eligibility,
that
is
the
successful
completion of logon,
build and allocate
control blocks and linkages for the user's
virtual machine.
DMKCFGIP
---Par-the IPL of a named saved system, the name
is verified and resources are checked for
availability.
virtual storage is set up with
the saved system via SVAPTABLE, SEGTABLE,
SHRTABLE updates.
For the IPL of device
address, the IPL simulator is loaded in the
user's storage.
DMKVKIPL
---user's page 0, set console address,
IPL
device address, VMBLOK flags 1PL device type
and class and user CAV.
Read in 24 bytes
from the CTCA, reader, DASD or tape unit into
the user's virtual location zero. The CCW
pointer is now set to the 1PLCCW at virtual
location X'8' and the program is loaded.
Ql1!S!l1!,
!E!!QQ!!~
For IPL STOP, the virtual machine is placed
in console function mode to allow change to
nucleus name and apparent storage size before
continuation.
DMKVftI, LOADNOW
---IPL address-is inserted in X'02' if BC mode,
or X'BA', if EC mode. The user's CAV and
registers are restored and control is given
to the user by loading the current PSW at
virtual location O.
VIRTUAL ftACHINE INITIALIZATION AND TERMINATION
DftKCRSII
---Entered via interruption fro. a console or
terminal
(not
displays)
device.
If
appropriate, determine and store device type
in the RDEVBLOK.
Vrite the Vft/370 online
• essage.
Sets
up to
receive attention
interruption.
DftKBLDVft
---On--attention interruption, build skeleton
VftBLOK for LOGONxxx.
DMKUSOLG
---Entry is the result of user invoking LOGOFF.
Set
flags in
VMBLOK indicating
logout
operation.
DftKUSO, US006
---Retain--lIne communication, if HOLD operand
specified.
Ql1!s'y'§Q,
'y'§QQ~
Adjust return address to not run the user.
DMKUSOPP
---set-VMBLOK flags •
DftKTRCRD
---Called to reset tracing.
DMKPERT
---Called to reset tracing.
section 2. ftethod of Operation and Program Organization
229
DItKACOTIt
---iccounting called to co.pute the connect time
for the LOGOPP .essage.
J2!U~.Q£Jjl
Write the .essage to the user.
DItKSCHDL
---Called to alter userdispatch status.
DItKCFPBB, DItKGSPO
---Reset the-virtual .achine.
DItK'ATBC
---Release shadow tables (if any).
DftKSCHBT
---Dequeue clock comparator request (if any).
DftKBLDBL
---Release seg.ent tables, page and swap tables
related to the user.
J2ftK!!SO,
.!l§Q.2~
Via DItKFBBT return user 'ItBLOKs to free
storage.
DftKUSO, US093
---Por ~he- system
operator,
clear
and
reinitialize the 'ltBLOK.
DltKFBBT
---Return all other virtual machine control
blocks to free storage.
DftKACOPF
an accounting card for the user.
DftKUSO, US098
---Pree LOGOFP .essage area.
Exit to do free
storage maintenance.
Exit
to DltKCFIt or
DltKDSPCH.
DftKUSOFL
---Entry is the result of the invoked FOBCE
co •• and.
DftKSCNAU
---Locate userid 'ltBLOK.
DftKUSOFL
---set--'ltKILL in 'ftBLOK, build CPEXBLOK and
stack it for dispatcher.
DltKDSPCH
---upon-CPEXBLOK execution, process as at LOGOPP
entry DltKUSOPF.
DftKUSODS
---Entry from an invoked CP DISCONN command.
set disconnected 'ltDISCK in 'ftOSTAT.
truncations
allowable
COftNBEGO.
nalles, and
of co.mand
starting
abbreviations,
The for.at of the table entry is:
Co •• and name
8
Class mask
2
Abbreviation count
2
Routine address
4
DftKCFIt, CONFFIND
---ifter--a-cOiiand match has been made, the
privilege class of the command is matched
with the user's privilege class, 'ltCLEVEL in
the 'ltBLOK.
DltKCPIt, CONFCALL
---The last--4-bytes of R command contain the
address of the routine that processes the
command.
Figure 55 is a list of all CP commands and
the associated processing modules.
---Punch
r
COllmand
AUTOLOG
LOGIN
LOGON
DIAL
ATTACH
ATTN
ADSTOP
ACNT
BEGIN
BACKSPAC
CHANGE
CLOSE
COUPLE
DISPLAY
DCP
DEFINE
DETACH
DISCONN
DISABLE
DltCP
DRAIN
DUltP
ECHO
EXTERNAL
ENABLE
FLUSH
FOBCE
FREE
HALT
HOLD
INDICATE
IPL
LINK
LOADBUF
LOADVFCB
LOCATE
LOCK
LOGOFF
LOGOUT
1t0NITOR
ItESSAGE
ItSG
!H~!2£!l!1
Send disconnect message to user.
]ftK!!§Q~§
Increment return address to DltKCFIt by 4 to
prevent
a return
read
to the
user's
terminal. Clear 'ltTERIt field to indicate the
user terminal is disconnected.
]!1K2£!l!1
Send message to system operator informing him
of user disconnect status. Exit to DftKCFIt.
CONSOLE FUNCTION (CP COftltAND) PROCESSING
DltKCFltBK
---Entry used
when the ATTENTION
key (or
equivalent)
is
pressed once
or
twice
(according to the ,It or CP status) to allow
the user to direct a line of input data for
CP command processing. Set 'ltPCWAIT and VltCF
bits in VltBLOK indicating wait state and
console function mode.
DltKPREE
---suIlds an 18 doublevord CONBUP buffer for the
read operation.
DltKSCNPD
---Matches the 8-byte command name against the
names,
the
table
of
matching command
230
the
at
Figure
55.
IBIt Vlt/370: System Logic and Problem Determination Guide
----_._--------,
Entry Label
I
DftKLOGON
DltKLOGON
DltKLOGON
DftKDIAL
DltKVDBAT
DltKCFMRQ
DItKCPVAC
DltKCPVAC
DltKCFMBE
DltKCSOBS
DltKCSUCH
DItKCSPCL
DltKDIACP
DItKCDBDI
DltKCDBDC
DftKFENIN
DltK'DBDE
DltKUSODS
DltKVPVDS
DltKCDBDM
DltKCSODB
DMKCDBDU
DItKftSGEC
DltKCPBEX
DltKCPVEN
DltKCSOFL
DltKUSOFL
DItKCSPFR
DltKCPVH
DltKCSPHL
DltKTHIEN
DltKCFGIP
DltKLNKIN
DltKCSOLD
DMKCSOVL
DltKCFDLO
DMKCPVLK
DltKUSOLG
DltKUSOLG
DltKMCCCL
DltKMSGMS
DltKMSGMS
------------'
CP Commands and Their
Entry Points (Part 1 of 2)
Module
-,
COlllland
Entry Label
NETWORK
NOTREADY
ORDER
PURGE
QUERYl
READY
REPEAT
REQUEST
RESET
REWIND
SYSTEM
SAVESYS
SET
SHUTDOWN
SLEEP
SPACE
SPOOL
STORE
START
STCP
TAG
TERMINAL
TRACE
TRANSFER
UNLOCK
VARY
WNG
WARNING
DMKBETWK
DMKCPBNR
DMKCSUOR
DMKCS'UPU
DMKCFMQU
DMKCPBRY
DMKCSORP
DMKCFMRQ
DMKCPBRS
DMKCPBRW
DMKCPBSR
DMKCFGSV
DMKCFSET2
DMKCPVSH
DMKCFMSL
DMKCSOSP
DMKCSPSP
DMKCDSTO
DMKCSOST
DMKCDSCP
DMKCSTAG
DMKCFTRM
DMKTRACE
DMKCSUTR
DMKCPUVL
DMKCPVRY
DMKMSGWN
DMKMSGWN
DMKCFM
DMKCFM
*CP
DISPATCHING AND SCHEDULING
DMKDSPA
---Entry for fast reflection activity.
Perform
user (PSA RUNUSER) accounting and determine
validity of fast reflection by examination of
DMKDSTAT values.
DMKDSP, RUNTIME
---no-user--accounting, then load the remaining
tille slice.
!1~!!12E, 2]!~YA!I!~
Build the PSW, then
with LPSW RUNPSW.
lMajor operand decode of QUERY is by a
scan table at QRYLIST in DMKCFMQU.
Depending on the operand match, DMKCQP,
DMKCQG, or DMKCQR· are called.
The respective entry points are
DMKCQPRV,
DMKCQGEN, and DMKCQREY.
2Major operand decode (except for PFnn)
is contained by the scan table starting
label SETSTART in DMKCFSET.
L________________________________________
---J
Figure
55.
CP Commands and Their
Entry Points (Part 2 of 2)
Read in the terminal input command line.
DMKCFMAT
---On-NULL data and ATTN key indication, post
attention interrupt pending
in VDEVBLOK,
VCUBLOK and VCHBLeK.
Return to run the
v irtual machine.
I
dispatch virtual machine
DMKDSPB
---Entry to dispatcher when the user's
been external to DMKDSP.
DMKDSP, CKPSW
---Verify-the PSW change.
!1~!!12E,
Y!2!A£E
Unstack any pending interrupts for
(if enabled).
DMKDSPCH
---Go-to the dispatcher.
PSW has
the user
Module
!1~K2£!!!m
" !H1E£!:1!S2
tille value (siaulation of virtual aachine
stop button depression) the VMBLOKs VMSLEEP
bit is set. The terminal console keyboard is
now inactive until the user hits an ATTENTION
key or the SLEEP command times out.
On receipt of CP comllands ATTN or REQUEST,
process
the
same
as
previous
entry,
DMKCFMAT.
DMKCFM
---On-receipt of * (asterisk) return to DMKCFMBK
to set up another read. If console spooling
is enabled, all console input and output
including comllents are spooled for printer
output.
DMKCFMBE
---oi--receipt of BEGIN, simulate the start
button on the virtual machine (If optional
address is supplied with BEGIN command the
supplied address is
substituted for the
location counter address).
DMKCVTHB
---Convert this address to binary notation.
DMKCFMSL
---on-receipt of the SLEEP command or SLEEP with
DMKDSPCH
---Normal dispatch entry after each interrupt
handler has finished processing, and after
each CPEXBLOK, I/O
request and external
interrupt has been serviced.
DMKDSP, RUNTIME
---For CPSiATOS=CPRUN, stop charging time to old
virtual machine, start charging time to new
virtual machine.
DMKDSP, WAITIME
---Por CPSTATUS=CPWAIT, if old virtual machine
was not CP start charging CP with wait time.
DMKDSP, PROCWAIT
---via vNTLEvEL, allocate time to appropriate
virtual machine time category.
!11!!!2J2f, !!!2I!£E
For nonrunnable virtual machine,
DMKDSP, DISPATCH.
!2!1E!2J2f, !!!2!!£E
For
runnable
user,
check
interruptions for the following:
• DMKDSP, CKPEND
per-interruptIon (VMPERPND).
Pseudo page faults (VMPGPND)
External interruptions
• DMKDSP, UNSTIO
I/o-interruptIons.
go to entry
pending
Section 2. Method of Operation and Program Organization
231
•
~~!Q~g, ~lQ~~£~~
I/O
interruptions
are
reflected
by
swapping user PSWs and storing the unit
address and status in low storage.
DMKDSP, NOTRACZA
---Clear-the-pending bit in the VMBLOKs.
DMKDSP, CKPSW
---Validate-the PSW.
DMKVATBC
---Par-virtual machine leaving EC Mode, clean up
the shadow tables.
DMKVATftD
---Par-virtual machine in BC mode and entering
translate mode, initialize shadow tables.
DMKDSP, DSPMSG
---For PSW--Invalid, send
error message to
virtual machine, and place user in CP mode.
If disconnected and invalid PSW, log off
user.
DMKDSP, DISPATCH
---netermIne--If virtual
machine is allowed
additional execution.
If not, use DMKSCHDL
entry.
DMKDSP CKCPSTAK
---Process--a--stacked IOBLOK
or TRQBLOK as
indicated
via DMKDSPRQ.
The new
user
IOBUSER/TRQBUSER is time stamped and a branch
is made to IOBIRA/TRQBIRA.
Y!1!Q§!!,
£!£!!~lH2
YI1!Q§!!,
£!g~.rJ,g1!
If system extending search CPEXBLOK for exit
address of DMKPTRPD, DMKPTRPE, or DMKPTRPP.
If none found load a wait state.
If not extending, unstack first CPEXBLOK.
The new virtual machine is time stamped and
branch taken to CPEXADD.
DMKDSP, CKUSER
---Load last-virtual machine with remaining time
slice if
applicable.
Load
the highest
priority user in the dispatch queue, if
available and applicable. If not enter the
wait state to await an interruption.
~!lK§£!!Y1
Entry to modify the user's status.
If the
user has the wait bit on in his running
status
(VMRSTAT) q
the
user
is
not
dispatchable or unqueue before the user's
time slice has ended, the user has set
favored execution option, or the user is not
eligable for Q1.
DMKSCH, CKCPWAIT
---net ermine-the running or not running of the
real timer per VMBLOKs VMRSTAT, VMTLEVEL
val ues.
DMKSCH, CKRSTAT
---Process--virtual machine, if currently not
runnable.
DMKSCH, CKRUN
---Process---virtual
machine,
if
currently
runnable.
DMKSCH, CKWRITING
---idd runnable-virtual machine to active queue
232
from eligible list search.
DMKDSP, CKCPSTAK.
Return
to entry
R.!tJS§£!!§!
Set a clock comparator interrupt request.
RI1!~£!!Rl
Reset a clock comparator interrupt request.
QI1!.§£!!I1Q
Set up a request block for midnight
change.
DMKSCH80
---Process a real interrupt timert"equest.
date
Q!!!~£!!£g
Process a real CPU timer interrupt.
SPOOOLING VIRTUAL DEVICE TO REAL DEVICE
DMKVSPEX
---Entry from DMKVIO to initiate SIO on a
spooling device that is available
{not busy
and no interruptions pending}.
DMKVSP, OPEN
---netermIne if output device
needs to be
opened.
DMKSPLOV
---i~-ies, build message control blocks: SPBLOK
and VSPCTLBLOK.
DMKPGTVG
---~btain
a virtual buffer; the address is
stored in VSPVAGE.
DMKPGTSG
---~btiIn a DASD page; the address is stored in
VSPDPAGE.
DMKVSP, BUILDCTL
---Assigo-i-spoolid and the other user, record,
and device values plus DMKCVTDT.
DMKCVTDT
---issIgns the time stamp and date and stores it
in SPBLOK.
DMKVSP, PRTCONT
---Generate-TAG record at the start of the spool
data buffer.
DMKVSP, CCWOK
---i~ter-cci- validity check, data and CCis {if
appropriate} are moved to the work buffer.
Trailing blanks are truncated and when the
buffer is full, it is written out to the DASD
slot.
DMKVSPVP
---~n-console spooling, the following occurs:
1. Skip to channell every 60 lines.
2. write out the system console, spool file
buffer every 16 lines.
3. Place the system console in a pseudo
closed state for checkpoint recovery in
the event of system failure.
DMKVSP, LASTCCW
---When --all-- CCWS
are
processed,
post
interruption pending to the VDEVBLOK, VDEVCSW
and return control to the user.
IBM VM/370: system Logic and Problem Determination Guide
DMKVSFCO
---intry via CP CLOSE cOllmand. If device busy,
defer close operation by building CPEXBLOK,
stack it and exit to dispatcher.
DMKVSP, PRTEOF
---on-devlce--not busy, write final buffer page
to DASD storage.
DMKSPLCV
---Queue closed virtual printer or punch spool
file, queued to the read spool output device
or transfer the file
to another user's
virtual reader. Also update the SFBLOK with
number
of
copies
printed/punched,
distribution code,
hold status, and file
owner ID.
If VSPXBLOK with TAG data exists
for the spool device, copy the TAG data to
the TAG record in the first spool file data
buffer.
DMKSPL, TXTXFR
--I£a iispooled to" file, queue to the end of
the reader file chain.
Otherwise, chain the
SFBLOK to the designated real spool printer
or punch.
DMKCKSPL
---Checkpoint the new spool file block.
DMKSPL, SETPEND
---io~ a-iispooled to" file find a virtual reader
with the proper class and in the ready state
with
no active
file,
and no
pending
interrupts. Then build an IOBLOK with IOBIRA
of DMKVIOIN.
DMKSTKIO
---stack the IOBLOK.
~11~~ PL, ~~I!!lB!~
Exi t to DMKVSP.
DMKSPL, TSTHOLD
---io~ not-iisi~oled to" files and not in user or
system hold, find printer or punch with the
proper class.
Then build an IOBLOK with
IOBIRA of DMKRSPEX.
DMKSTKIO
---Stack the IOBLOK.
DMKSPL, TSTHOLD
---iiit to-DMiisp.
DftKVSP, OPENRDR
---Entry--to--open a
spool input file.
If
VDEVSPL=O the file needs to be opened. Build
VSPLCTL block and a work buffer. Search the
systea reader file chain per PSA linkage
ARSPRD for a file with appropriate user and
class.
~IIK!'§~, '§EIl~!~
On file found condition, place first DASD
page address in VSPLCTL, VSPDPAGE. Obtain a
virtual buffer and retain its address in the
VSPLCTL block.
DftKVSP, READER
--Cbeck-the-CCWs for validity, move and expand
the data back to its original size and the
data is moved from the work buffer to user's
virtual storage.
~~K!'§~, iRi~QY!1
On BOF, set
to caller.
SFBBOP bit in SFBLOK
and return
DMKVSPCR
---Por--CLOSE operation requested via console
command and the device is busy, initiate a
delayed close by constructing and stacking
the CPEXBLOK for the CLOSE.
DMKVSP, RDREOP
---ior normal-end-of file and VDEVSPLG indicates
continuous read.
DMKVSP, OPENCONT
---Locates-the-next file and continue reading.
DMKVSP, LASTPILE
---ior last-fIle, post end status in RDEVBLOK.
DMKVSP, FILECLR
---ior HOLD--status file
(VDEVSFLG=VDEVHOLD),
call DMKCKSPL.
DMKCKSPL
---Checkpoints the file.
DMKVSP, FILECLR
---Unchain-the-file (except hold files) from the
reader queue and call DMKSPLDL.
DMKSPLDL
---Delete the file.
DftKVSP, DVICECLR
---To-clea~-the-device, call DMKRPAGT.
~IIKi~!~1
Releases the storage page.
DMKPGTVR
---Releases the virtual buffer.
DMKFRET
---Releases storage for the work
VSPLCTL block.
buffer
and
SPOOLING TO THE REAL PRINTER/PUNCH OUTPUT DEVICE
DftKRSPEX
---intry from the dispatcher when an IOBLOK is
unstacked with and interrupted for spooling
unit record device.
IOBRADD points to the
RDEVBLOK RDEVTYPC input or output class.
DMKRSP, RSPLOUT
---i£- RDEVSPOL indicates an available spool
device (not active),
DMKFREE
---Get-storage for a work buffer and build a
RSPLCTL block and link it to RDEVBLOK.
DMKRSP, PRNXTPIL
---search-prInter and punch SFBLOK chains for
corresponding device and class.
On a found
condition, unchain the block, put its address
in RSPSFBLK.
DftKSEPSP
---i£--called, provides separators for output
pages or cards.
DftKRSP, PROCESS1
---Brlng-firs~spool data DASD page to the work
buffer and convert CCW addresses to real
device addresses.
~l1JS1.Q~.Q.B
Start the spool device.
DMKRSP, PRNXTPAG
---Repeat-the-process until done.
DMKRSP, REPEAT
---Reprocess-- and reaccess
the buffer,
if
aultiple copies are specified.
DftKCKSPL
---Checkpoint records the change to COPY count.
DMKSPLDL
---Delete the file on coapletion (unless HOLD
specified) •
section 2. Method of Operation and Program Organization
233
DBKRSP, PRRITPIL
--~ocate-the-next spool file to process.
DftKRSP, PRTIDLE
---processIng--for the device is complete as
there are no .ore SPBLOK, for this device or
the device was drained.
DBKPRET
---Release work
area and
co.pleted IOBLOK
storage.
DftKDSPCB
---ixit-to the dispatcher.
SPOOLIHG TO THE REAL IHPUT DEVICE
DftKSPLOR
---issuiie there
is no
active file
being
processed on the real input file reader. The
spooling operator
has issued
the START
co.mand to the device to 'open' the reader.
DftKSPL, BUILDCTL
---auild-RSPLCTL and SPBLOK.
DftKPGTVG
---set-virtual buffer and place its address in
RSPVPAGE.
!HUifGT1a~
Get DASD buffer and place its address
SPBSTART and RSPDPAGE, linke together
pointers.
in
b~
!1!!!!Q~,g~
start the reader.
]~!i!1SP£]
Await the interruption.
!1~!R~f, RQ~~~II!Q
Check that the first card in the buffer is
the userid header. If so, proceed.
DftKRSP RDRCARDS
---preload-the-buffer with CCWs.
!1~!i!Q~2R
IssUe the 510
(SIO's of 42 cards per buffer
load).
DMKRSP, RDRSIO
---Write-the--buffer to the DASD slot.
Repeat
until EOP detected.
DMKSPLCR
---Close the file on EOP. Queue the file on
reader spool chains.
DMKCKSPL
---iaa--the spool reader file block to the
checkpoint cylinder data.
DftKSPL, RDRPEND
---1f- the-file owner is logged on, and his
virtual reader is available, an IOBLOK is
constructed with device end pending DftKSTKIO
---Stacks it.
DftKRSP, RDREXIT4
---Release-storage for virtual buffer, RSPLCTL
and the SPBLOK.
DMKDSPCB
---EiIt-to the dispatcher.
SPOOL PILE DELETION
DftKPLDL
---wIth R7
not equal to zero,
place the
specified SPBLOK on the delete chain anchored
to DMKRSPDL.
234
DBKCKSPL
---Delete the SPBLOK fro. checkpoint cylinder
data.
DBKSPLDL
---Assuie the delete routine is not running,
build a CPEXBLOK to call DBKSPLDR.
DBKSPLDR
---sets- the
DELSW=X'80'
(delete
routine
active).
DBKSTKCP
---Stacks it and exits to caller.
DBKSPLDR
---on-unstacking the CPEXBLOK, if the SPBLOK is
a system dump file, calls DBKDRDDD.
DBKDRDDD
---Deallocates DASD buffers.
DftKSPL, NEITSPB
---Par coiplete allocation chains of RECBLOKS,
call DBKPGTSR
DftKPGTSR
---deallocate DASD buffer an.d return to storage
held by the dummy RECBLOKs.
DBKSPL, DELSTART
---Por Incoiplete allocation RECBLOK chains,
deallocate by calling DftKPGTSD.
DftKPGTSD
---Deallocates a page at a time via SPBSTART and
the IOBLOK until the last page is reached.
DftKPRPT
---Delete the SPELOK, then go to DftKSPL and
NEXTSPB.
DftKSPL, NEITSPB
---if-the-delete queue is not empty, process the
next SPBLOK an identical manner.
Continue
until all SPBLOK deletions are complete then
call DMKPRET.
DMKPRET
---Delete the IOBLOK.
DBKDSPCB
---iiit-to the dispatcher.
RECOVERY BANAGEBENT SUPPORT OPERATION
DMKIOEPL
---Entry from CP initialization module to set up
pointers
to
VM/370
error
recording
cylinders.
DMKIOGP1
---ihe-STIDP instruction store CPU version and
model in CPUID of PSA.
DMKIOG, ISSUEIRS
---Check--attached
channels.
If
standalone
channel on the 165 or 168 the address of the
logout routines are stored in the DftKCCB
module.
DBKIOG, CBARGEID
---Set u~-~ointers for machine check and channel
check record area and extended logout areas.
DBKIOG, PASTDAVE
---DetermIne-the 901 full and 1001 full capacity
of designated error recording cylinders and
store the amount in DftKIOEMX and DMKIOERI
respectively.
DftKIOG, PIRDREC
---Check-first- records on each cylinder of the
error recording cylinders for proper format.
If invalid. reformat. If valid but clear,
store pointer value in PSA as the first
available slot for error record* If valid but
IBft Vft/370: System Logic and Problem Determination Guide
used, search for first unused slot and store
its value in PSA.
DMKIOG, CYlFULL
a--cylInder full condition, inform the
operator, and continue.
DMKIOEFl
---Turn-off the recording in progress switch and
exit to caller.
---on-
hardware recovery is not active process as in
DftKftCH, ftCHSYSIl.
DMKftCH, ftCHiAIT
---Par TOn-damage, load PSi, enter wait state.
Q~!~~li,
~~liR~~l!
If the TOD is not damaged, the address of the
TOD is saved for accounting purpose andDMKDMPRS
---Dumps and initiates system restart.
Process the Machine Check Interruption
DMKMCHIN
---Entry via
the machine
check PSi
upon
detection of an unrecoverable and nonfatal
CPU or storage error.
Disable soft machine
recording store logout area on the machine
check and channel check recording cylinders.
The system is enabled for hard machine checks
with a pointer to the termination routine.
DMKMCH, ERHARD for virtual user store status
in VMBlOK.
DMKMCH,
MCHSYSIl for system
damage timing
facility or
uncorrectable
retry, multibit storage error post system
operator message, flag system as terminated.
place wait state code, if first hard error,
record it. If the fault occurred in problem
state, terminate the active virtual machine.
DMKMCH, SOFTSTG
---Par corrected ECC or CPU retry, update soft
error count and record the error and dispatch
the virtual machine.
DMKMCH, MCHSKIP
---Par mUltIbIt storage error in problem mode,
exercise storage location to clear up or flag
as unavailable (permanent error).
DMKMCH, ftCHCHANG
---On- an-altered page condition, the virtual
machine is reset, otherwise, the error is
recorded
and
the
virtual
machine
is
redispatched.
DMKftCH SPFTEST
---storage-key failure.
Exercise the 2K page
key. If CP area and solid error condition
process as DMKftCH, ftCHSYSIl,
intermittient,
restore the key and go to the dispatcher. If
key failure and in virtual machine area if
permanent error, mark page as unavailable,
terminate the user. If intermittent condition
refresh the key and dispatch the virtual
machine.
DftKMCH, VIRTERft
---on-condItIons that cause the terminated or
reset. The error is recorded, and both the
user
and
the operator
receive
status
.essages. Per the termination flag, VftBlOK,
the user is logged off and control returns to
the dispatcher or is reset via DMKCFPRR.
DftKCFPRR
---iIrtual storage is released, the virtual
machine is flagged dispatchable and placed in
console function mode.
DMKftCH, TERM
---on- a-hard machine check while handling a
• achine check, the machine check new PSi is
loaded with a wait state PSi and the current
PSi is enabled for hard machine checks.
DftKftCH, ftCHTERft2
---Locate-the-system or the user's VftBlOK.
DftKftCH, MCHTERft3
---On- second--hard machine
check error, or
machine check handler is
not active or
DMKCCHIS
---Entry via DMKIOS via CSi channel error
DMKFREE
---Obtain storage and build a CCHREC block and
if IOBlOK and RDEVBlOK
exist,
build an
IOERBlOK.
DMKCCH, CCHIOERl
---Store-the--CCHREC address, it length and the
CSi in the IOERBlOK
DMKCCH, CCHDEPND
---Call -appropriate
channel error
analysis
module.
Analyze channel logout data for
validity.
DMKCCH, SCNEND
---Record--the error on the error recording
cylinder, if appropriate
DMKCCH, CPTERM
---Terminate-CP if the PSA's terminate flag is
set.
DMKCCH, CCHiAIT
--~he SEREP--code
(X'OF') is placed in the
interruption code of the machine check new
PSi. The I/O old PSi, CSi, and CAi are
restored.
Checkpoint is set up by moving
'CPCP' into 'CPID'. The TOD clock is saved
and a wait state PSi is loaded to place the
system in a disabled wait state.
DMKCCH, SCNEND
---Unless-termination is established, return to
DMKIOS for recovery.
DMKERO
---Entry via DMSPSA as a result of SVC 76
detection. Check parameters passed in RO and
Rl.
DftKFREE
---obtain storage for a rdcord buffer for the
user error record
DMKVER, BUFFUl
---usIng--valId record type (from the buffer)
branch to an appropriate routine to format
that particular record type.
Q~!!~R,
!IBJQ
Using RDEVBlOK, VDEVBlOK and VMBlOK, convert
virtual data to real values and place in
record •
DMKIOERV
---Record the error.
DftKDSPCH
---EiIt-to dispatcher
Section 2. Method of Operation and Program organization
235
USER DIRECTORY ROUTINES
DMKUDRFU
---Entry after
CP detected
LOGON command.
DMKSYSPL points to the directory. Determine
length of userid, if valid call DMKLOCKQ.
12!H~1Q£!S~
Lock the directory in storage.
DMKODR, NXTPAGE
---Bring-in-each directory page and return each
page {and clear the buffer} until a UDIRBLOK
match occurs or directory's last page is
detected.
DMKUDR, FINDUSER
---On- useria-found move UDIRBLOK to caller's
area.
121HS1.Q£!~
Unlock the directory in storage
DMKUDR, EXITCCO
---Return-to-caller
DMKUDRFD
---Entry from calling routine
to find the
addressed
{cuu} device ODEVBLOK in users
directory and move it to the caller. Via
UMACBLOK locate the ODEVBLOKs.
DMKUDR, FINDDEV
---Check-user-device address is the same as in
the ODEVBLOK. Search the chain until match or
end of chain occurs.
DMKODR, DEVFOUND
found-condition, post condition code 0 in
users VMPSi.
---Par
.!H1!!!12!Um
Entry from calling routine
to read the
UDEVBLOK addressed into the caller's buffer
using the DASD and the user displacement from
the UMACBLOK bring in the buffer page to
storage. Determine if the virtual directory
page address
(UDBFVADD) exists in the user
directory buffer blocks. If not callDMKPGTVG
---and-get a virtual page
DMKRPAGT
---por-DASD address does not match the UMACBLOK,
point to the DASD page and bring in the
virtual buffer page.
Move UDEVBLOK into
callers area and set cc=O in VMPSi. Return to
caller.
buffer page list,
post fatal message, set
cc=3 and return to caller.
DMKODR, ENDLIST
---swap the--new virtual buffer page list with
the old list.
Anchor
the new list to
DMKSYSPL.
DMKODR, FBETLIST
---If- there-was a previous buffer page list,
free it.
Save the start of
the user
directory pointer in DMKSYSOD, and return to
caller with a CC=O in the VMPSi.
SAVE THE 3704/3705 CONTROL PROGRAM IMAGE PROCESS
DMKSNCP
---Entry from DMKHVC and DIAGNOSE code 50. Per
the system VMELOK, locate the DMKRNTBL. The
CCPARM virtual address is contained in R1 of
the DIAGNOSE instruction.
DMKSNC, NAMECHK
---Hatch---via- search
CCPARM; CCPNAME
with
DMKRNTBL entries.
DMKSNC, SIZECHK
---verify-niso-space requirements for 3704/3705
control program and resource data. The volume
required to save {NCPVOL} as indicated in the
NCPTBL entry must be:
available and mounted on the system, on a
Cp-owned and supported paging device.
DMKSNC, SVRESDAT
---save -resource data on the NCPVOL device •
CCPARMs supplies the starting address and
size parameters for this write operation.
DMKSNC, SVNCPIM
---save -3704/3705 control
program image on
NCPVOL device.
CCPARMS also provides the
parameters for this similar operation.
DMKSNC, SAVEFINI
---store--cc;O--on no
errors and return to
caller.
SPOOL FILE CHECKPOINT AND RECOVERY
!H1~!!!H!!t!
Entry to return a virtual page used as a
buffer.
Determine if UDBFBLOK contains a
virtual buffer page pOinter
(ODBFVADD). If
not, exit with CC=l set in the VMPSi. If a
buffer exists,
check to see if
it is
resident; if it does, clear it to zeros.
DMKPAGT
---Return the real page to the system.
!!~!!!~!!!!
Return the virtual page to the system
DKKUDRRV
---set-cc=O and return to caller
!!~!!!!!!!~!
Entry from DMKDIRCT or DKKCPINT to build page
buffers for each UDIRBLOK.
DMKFREE
---~et-storage for the virtual buffer page list
DMKODR, GETVPAGE
---Call DHKP~TV~ and DKKRPAGT to get the virtual
and real buffer Save the virtual buffer
address in the page list.
DMKUDR, FRETLIST
---incountered--I/O error,
free the virtual
236
DMKCKSIN
---Entry
from
CP initializer,
DMKCPI
to
initialize the checkpoint cylinders.
Per
DMKSYSCH, get
a virtual
page for
the
checkpoint cylinder and set up the device
code in the system residence device.
In
addition set up local data areas such as
pages per cylinder and checkpoint cylinders.
DMKCKS, CKSIN1
---Loop through each SFBLOK in the system and
checkpoint it in a slot on the checkpoint
cylinder. Then loop through each remaining
slot and mark it empty.
DMKCKS, CKSIHS
---Place-the-map delimiter of the last non-empty
slot in the map.
DMKPTROL
---Unlock the map page.
DMKCKS, CKSIN5
---Return-to-caller.
IBM VM/370: System Logic and Problem Determination Guide
. DMKCKSPL
---Entry from any routine that adds, deletes,
changes, the status of closed spool files.
Lock the routine, or waits until it becomes
unlocked.
Bring the map page into storage
and set up the device code of the system
residence volume.
!H!JS£JS~, l!QQ~~!H2
If the change is applicable to a SHQBLOK
(hold queue block) make appropriate change on
the checkpoint cylinder.
DMKCKS, CKSPLl
---1£- the-change is applicable to a SFBLOK,
either add, change, or delete it on the
checkpoint cylinder.
DMKCKS, CKSPL5
---1£- the--change affects a spooling device
RDEVBLOK,
(for example, a START or DRAIN
com.and issued) mark the
change on the
checkpoint cylinder.
DMKCKS, CKSEXIT
---Unlock-the--routine. Unlock the page map and
exit to caller.
DMKCKSWM
---Entry
via
DMKCPI
during
reinitialization process whenever the records
for
closed
spool
data
need
to
be
reconstructed. Get a virtual page for the map
of the checkpoint cylinder and set up the
device code of the system residence volume •
In addition, set up local data areas.
DMKCKS, CKSWM2B
---Par slots-having real device entries, set or
reset the RDEVDISA and RDEVDRAN and move in
the
checkpointed
device
classes
into
RVDEVCLAS.
DMKCKS, CKSWM2G
---Par slots-containing spool hold queue block,
chain this to the SHQ chain.
DMKCKS, CKSWM3
---Get storage for SFBLOK space and set flags
depending on its last checkpoint activity.
DMKCKS, CKSWM4
---If-the--file SFBLOK was active, chain it to
the appropriate printer, reader, or punch
chain.
DMKCKS, CKSWM5
---Allocate-the DASD buffers of the spool file
by reading each buffer to determine the next
one and then allocate this page.
DMKCKS, CKSWM6E
the-duip spool file, the buffers are
allocated sequentially from the beginning to
the end.
DMKCKS, CKSWM9
---Set uP-the map delimiter for the end of
non-empty slot; then set up a new spool file
identity (spoolid)
higher than
existing
numbers. Return to DMKWRM.
---Por
VM/370
section 2. Method of operation and Program Organization
237
In this section, Figures 56 through 61 show how
the RSCS routines interact with each other
functionally.
Figure 56 shows all of the RSCS
coaponents at an overview level.
Figure 57
through 61 show the parts of the individual
coaponents.
DMTSML
REX Task
,
"-
sse
Line
"-
.-----..'B
sse
Line
Supervisor Routines
~------------------~-------------------------------
Figure 56. Overview of RSCS Program Organization
238
IBM VM/370: System Logic and Problem Deteraination Guide
]
DMTVEC
DMTSTO
Fixed
Storage
Values
Reserve
Main
Storage
DMTMAP
DMTWAT
Variable
Storage
Work Area
Suspend
Dispatching
for an
Executing Task
DMTAKE
Accept and
Respond to GIVE
Requests; Calls
DMTQRQ
DMTQRQ
Reserve or
Release
Supervisor
Queue Elements
<:=:-
<==
~
DMTASK
Initiate, Terminate and Query
Tasks; Calls
DMTQRQ
DMTPST
Signal
Completion of
an Event in
the System
~
DMTSVC
'---'
,....-DMTASY
Initiate and
Terminate
Asynchronous
Exits; Calls
DMTQRQ
External (Console)
Interrupt
DMTEXT
DMTGIV
Process an
External
Interrupt
Present GIVE
Requests;
Calls DMTQRQ
and DMTPST
--
DMTIOMIN
Process an
I/O Interrupt
110 Inter
-
--
'"~
-------
-------
-
~
~
~
)
DMTIOMRQ
Request I/O
Service; Calls
DMTQRQ and
DMTPST
~
DMTSIG
Asynchronously
ALERT Another
Task; Calls
DMTPST
"I;
.I'--
'\r---
7
DMTDSP
All
Task-Level
Programs
Resume Execution of a Task;
Enter a System
WAIT State
WAIT
Suspend
Execution
of a Task
A
<"
n
I [I
Figure 57. Program organization for the ftultitasking Supervisor
Section 2. ftethod of Operation and Program Organization
239
REX Task
DMTCRE
Line Driver Tasks
Create System
Service and
Line Driver
Tasks.
AXS Task
I
DMTAXS
.......
~
~
~
VM/370
Spool
File
System
......
rE!
IE
Virtual
Machine
~
I DM~::J- 7
'"
DMTMGX
DMTREX
.....
- Build the
Final Message
Element.
-Transmit File
Message
...
..,--
Requests
_ Handle Program
Check Interrupts
• Handle Console
I/O
- Terminate System
Service and Line
Driver Tasks
DMTCMX
Process Commands:
• Execute DMTCMX
Commands
• Pass Command
Elements to
AXS and Line
Drivers for
Execution.
.A
~
\
~~~
Console
Supervisor Routines
Figure 58. Program Organization for REX system Service Tasks
240
BSC Line
¢:;
_ Handle all REX
Process Messages:
/-7
VM/370
Virtual
Machine
I
.A
IBM VM/370: System Logic and Problem Determination Guide
I DMT~
/BSC Line
AXS Task (Module DMTAXS)
CMDPROC
•
•
•
Reorder Files
by Recording
the TAGs queued
to a Given Line
Driver
Purge Files
From RSCS
Change the
Attributes
Associated with
an RSCS File
Open and Close
Input and
Output Files
REX Task
I
I
I
I
DMTMSG
AXSCYCLE
ACCEPT:
• Files Spooled
by Other Tasks
• Order, Change
Purge Command
Elements
• Requests to
Open and
Close VM/370
Spool Files.
DMTMGX
DMTREX
DMTCRE
I
DMTCMX
I
I
!
I
Line Driver
Tasks
BSC
Line
BSC
Line
I
Accept Files
from VM/370
Spool System
Supervisor Routines
Figure 59. program Organization for the AXS System Service Task
Section 2. Method of Operation and Program Organization
241
$PRTN1
RJE:
Process Print
File Records
and Send Them
to VM/370.
I"-\r--
$URTN1
RJE:
Process
Punch File
Records and
Send Them to
VM/370.
;L-
\r-
$TPGET
$JRTN1
HOST:
Process Job
File Records
and Send Them
to VM/370.
~
'--~
Receive Data
from BSC Line
I"-via COMSUP;
VAllocate Tanks
to I nput Processors
COMSUP
Control Communications on the BSC
Line; Send and
"- Receive:
\
\
$CRTN1
HOST and RJE:
Scan RSCS
Control
Records and
Perform
Control
Functions.
<
--
y
\
\
;L-
\r-
./ • Data Streams
\
/
\
\
Control Input/
Output Processors
by Means of
the Commutator
Table and Task
Control Tables
;L"\,--
HOST:
Pass Commands ds
to DMTCMX
$RRTN1
HOST and RJE:
..
Receive
Records from
VM/370 Spool
System and
Transmit. them
Via $TPPUT
I---
~
}
v
CMDPROC
E1
-.J
Module
External Beferences (Labels and Modules)
n
3:
0\
en
I:MSOVS
EGPB15
BO
SVCOUNT
NUCON
Rl
SVCSECT
OVAPP
R12
'IPPSVO
OVBPP
RD
TYPFLAG
OVP10N
R14
Vl!SIZE
OVSAPT
R15
ICOUBT
OVSHO
R3
IGPBO
OVSON
R4
XGPBl
ABATABIID ABATLIMT BATFLAGS BATLSECT BATNOEI
Bl
Bl0
B13
B11
B12
Ba
B9
BATPBTC
B14
BATPBTL
B15
BATBUN
B2
BATILIK
B3
BATXPBT
B4
CAW
B5
CSW
B6
NUCON
B7
DMSPIIT
AACTPBEE AACTLKP
R14
B15
AFTIC
R2
APTBP
R4
APTSECT
RS
APTWP
B6
DMSPRT
ADMSPIOC AFIIIIS
R1S
B2
ARDEUP
R3
ASTATE
B4
AEBASE
R12
AFINIS
R14
ASISBEF
R1S
I:MSPUN
ADTID
B14
ADTSECT
B15
DMSQRI
ADTCIL
ADTRUM
FCBDD
NOIMPCP
Rl1
SI SRAMES
ADTDTA
ADTSECT
FCBDEV
NOIMPEI
B12
TIMCCi
I:MSRDC
-=
3:
"-
ASVCSECT CUBBSAVE EPPBS
OVSSO
OVSTAT
BPPBS
B5
B6
R1
XGPB15
EGPBS
BGPRS
Ra
EGPBO
RGPBa
SSAV!
(.oJ
-.J
0
DMSPIO
00
en
~
en
t"4
0
0
F65535
NUCON
BEGSAV3
BO
Bl
Bl1
INSTALID NUCON
B6
BS
RO
B1
Rl
Ba
Rl0
R9
Rll
R12
R13
R14
AWRBUF
R2
BGCe!!
R3
LUBPT
NUCON
PUBADR
PUBCUU
PUBPT
AFINIS
B2
ABDBUF
B3
ASTATE
B4
PVSPSTAD NUCOR
B5
B6
BO
B1
Bl
Ba
Bl0
B9
Bll
R12
STATEFST
R13
ADTFDOS
AEITSECT
FCBDSNAM
ROPAGBEL
R13
TIMCHAR
ADTFLG 1
AFVS
PCBDSTIP
ROBDITIK
R14
TITLIBS
ADTPLG2
AIRTBTBL
FCBPIBST
NOSTDSYN
B15
ADTFLG3
ALDBTBLS
PCBRUK
RUCOR
R2
ADTFBO
AOUTRTBL
FCBSEC'!
OPTPLAGS
R3
ADTFBOS
ASYSBEF
FCBTAPID
PBFPOPF
R4
ADTFBW
AUSABBV
FVSECT
PBOTPLAG
RS
ADTPSTC
CMSSEG
!!ACLIBL
REDERRID
R6
ADTID
DUD
MISPLAGS
BO
R1
ADTM
DTADT
MSGPLAGS
Rl
Ba
ADTKX
EXTSECT
NOABBBEV
Rl0
R9
ABATABRD AEBASE
Rl0
Bl1
AFIRIS
R14
ASCANN
B15
ASTATEi
R2
AWBBUF
B3
BATDCMS
R4
B.ATPLAGS BATFLAG2 BATRUN
RS
R6
R7
RUCOR
RS
BO
R9
Rl
I:MSBRE
AERASE
R3
AFIIIS
B4
ARDBUF
R5
AWRBUP
B6
RUCOR
R1
BO
Rl
Rl0
R12
B13
R14
R15
B2
DMSBNM
AACTLKP
ATIPSBCH
RUCOI
R5
ADTCHBA
AUPDISK
BEGSAVl
R6
ADTFLGl
EBBIT
BO
R7
ADTFRO
EBBCODl
Bl
B8
ADTPBi
ERSFLAG
Bl0
B9
ADTPTIP
PSTM
Bl1
STATEFST
ADTM
FSTN
R12
UFDBUSI
ADTSECT
PSTSECT
B13
PSTT
B14
FVSECT
B1S
FVSEBASO PVSEBASl FVSEBAS2
B2
B3
B4
ADTCIL
FCBDSRAM
FILEBUPP
OSFSTBLK
OSPSTNTE
R10
URD
ADTDTA
PCBDSTIP
FILEBITE
OSPSTCHB
OSPSTNIT
R 11
VAB
ADTFDOS
PCEFIBST
FILENAME
OSPSTDEK
OSFSTBPK
R12
ADTFLGl
PCBIOSi2
FILEBEAD
OSFSTDSK
OSPSTRSi
B14
ADTPLG2
PCBLBECL
LOC
OSPSTDSI
OSFSTTRK
R15
ADTPLG3
PCBMVPDS
RUCOR
OSPSTERD
OSPSTTIP
B2
ADTPROS
FCBREIT
OPSECT
OSPSTEI4
OSFSTUMV
R3
ADTM
PCBOP
OSADTDSK
OSPSTPLG
OSFSTIRO
R4
ADTSECT
FCBOSDSN
OSADTFST
OSPSTPM
OSFSTITN
RS
CSi
FCBOSFST
OSADTVTA
OSFSTFVF
PO
R6
DTAD
FCBPROC
OSADTVTB
OSFSTLRL
PS
R1
I:MSPRV
~
::I
~
~
t1
0
b"
....,
CD
B
'='
CD
cT
•.....
::I
~
cT
.....
0
G'l
~
(I)
DMSBOS
0
I
b"
CD
....,
t1
0
en
en
RO
Bl
R10
!:tI
CD
::I
s::
.....
CD
I
cT
n
(I)
t1
~
~
\,Q
.....
0
s::
....,
t"4
DKSLFS
cT
CD
II
3:
FCBBLKSZ
FCBBECFM
OSPST
OSFSTLTH
BO
Ra
FCBDSMD
FCBSECT
OSPSTALT
OSFSTMVL
Rl
R9
HI
CD
t1
CD
t:S
0
CD
!!odule
External References (Labels and ftodules)
DftS RRV
AERASE
IUCOI
R3
DftSSAB
APGftSECT CURRSAVE DEBDCBAD PCBDD
FCBFIRST PCBSECT
Rl
R10
Rl1
R13
R14
R12
RS
R9
SCBPTR
SCBSAV12 SCBWCRK STAEBIT
DMSSBD
DA
FCBOP
KEYTBLBO
RS
DATAEID
FCBSECT
OPSECT
R6
DECAREA
FCEXTENT
PS
R7
DECKYADR
IHADECB
RO
R8
DECLBGTH
IOBIN
Rl
R9
DMSSBS
AOPSECT
FCBCOUT
FCBXTENT
PREVIOUS
R6
DA
FCBDEV
IHADEB
PS
R8
DECAREA
FCEDSMC
IHADECB
RO
TAPEDEV
DECDCBAD
FCBDSNAft
IOBBCSW
Rl
TAPELIST
tftSSCN
BALRSAVE CftlDLIST IUCON
R7
R8
CftSSCR
BUPPLOC
HOLDFLAG
R2
TABLII
DECLTH
ITEM
R3
TRUICOL
DftSSCT
ADMSBOS
FCBIOSi
IOBCSi
R14
tftSS EB
ADftSBOS
FCBCASE
PCEPROC
IOBICFLG
R13
TAPE SIZE
APIIIS
CSPST
R4
ASTATE
ASYSREP AiRBUP
OSPSTDSK OSFSTXTI PUBPT
RS
R6
R7
BGCO!!
RO
RS
DOSDD
Rl
R9
DOSDEV
Rl0
DCSDSK
R 11
DOSCP
R12
DOSOSPST DOSSECT
R1S
R14
LIIKLAST LOC
R1S
R2
STAIBIT
IUCOl
R3
PGftOPSi
R4
PGMSECT
RS
DECRECPT
IOBIOFLG
R10
TBLLNGTH
DECSDECB DECTYPE
KEYCHNG KEYCOUT
Rll
B12
VAR
DftSSBS
DftSSBSRT FCBBYTE
KEYLBGTH KEY lAME KEYOP
R14
R1S
R2
FCBITEM
KEYSECT
R3
FCBKEYS
KEYTBLAD
R4
DECIOBPT
FCBINIT
IOBEECBP
R11
TAPEMASK
DECLNGTH
PCBITEM
IOBBFLG
R12
TAPEOPER
DECSDECB
FCBMODE
IOBIN
R13
UND
DECTYPE
FCEOP
IOBIOFLG
R14
VAR
DMSSBD
PCBOS
IOBOUT
R1S
DMSSEB
FCBPDS
NUCCIf
R2
FCBBUFF
FCBREAD
OPSECT
R3
FCBBYTE
FCBSECT
OSIOTYPE
R4
FCBCATML
FCBTAP
PO
RS
RO
Rl
1112
R14
R1S
R2
R3
B4
RS
R6
DMSGIO
LIBELOC
R4
TWITCH
EDCB
BUfttOC
RS
UTILFLAG
EDftSK
PTRl
R6
VERCCLl
PLAG
PTR2
R7
VERLEN
FLAGLOC
RO
R9
PLAG2
Rl
SAVCNT
PMODE
R11
SAVEAR
FBAME
R12
SCLlW
PV
FTYPE
R13
R14
SCRBUPAD SCRPLGS
AOPSECT
FCBITEft
IOBICPLG
R1S
CMSOP
FCBOP
IOEOUT
R2
DA
FCBOS
ftACDIRC
R3
DlCCCBAD
FCBCSPST
MACLIBL
R4
DECIOBPT
PCEPDS
NUCON
RS
DECSDECB
PCEB13
OPSECT
R6
FCBCATML
PCB SECT
PS
R7
FCBCLOSE
FCBTAP
RO
R8
FCBCOUT
FILEUME
Rl
R9
FCEDEV
IHADEE
Rll
SAVER14
FCEDSNAft PCBINIT
IHADECE IOEBFLG
R12
R13
AOPSECT
FCECCUT
FCBPRPU
IUCON
R14
TSOATCNL
BLK
FCBDEV
FCBREAD
OPSECT
R1S
TSOFLAGS
CMIDLINE
FCBDSftD
FCBRECL
PRINTLST
R2
UND
COBBDCNT
FCBDSTYP
FCEB13
PS
R3
VAR
CONBDCOD
FCBIIIT
PCB SECT
PUlfCHLST
RS
CONREAD
FCBIO
FCBTAPID
RDEUFF
SAVER 14
CONiREUP
FCBIOSi
FXD
RDCCW
TAPEBUFF
CONWRCNT
FCBITEM
IHADECB
RDCOUNT
TAPECOUT
CONiRCOD
FCEMCD!
IOBBCSi
BEADLST
TAPEDEV
CONiRITE
FCEOP
IOBBECBC
RO
TAPELIST
FCBBUFF
FCEOPCB
IOEBECBP
Rl
TAPEftASK
LUBPT
R2
RETRYBIT RO
R6
R7
GIOPLIST
R1S
SCRPLG2
FCEEYTE
FCEOS
IOEIN
Rll
TAPEOPER
n
r+
~.
0
=
3:
0
P-
en
CD
n
3:
til
DMSSEG
DMSEDC
DMSSCT
DMSEDI
DftSSEB
DMSEXT
DftSSLN
DMSGIO
DMSSftN
DftSLGT
DMSSCP
DftSLIB
DMSSQS
DftSLSB
DMSSVI
DMSLSY
DMSSVT
DMSOLD
DMSSAB
DftSSED
DMSSES
DMSSCR
c
.....
CD
I
rt
0
I
W
t"4
t:::I
CD
.....
t1
CD
n
~
tT
~.
n
r+
0
t1
~.
CD
CIl
t1
0
CIl
CIl
~
CD
HI
CD
t;
~
""'"
""'"
CD
=
n
CD
N
...,j
Module
External References (Labels and Modules)
("")
:3
co
til
tftSSET
<
3:
"
W
...,j
0
til
Io.c:
DftSSLN
en
c+
(\)
s
t-I
0
ADTFLG2
BATHOEI
LOCCNT
NUCKEY
Rll
SYSCODE
VMSIZE
\oJ.
0
ADftSFRT
BATDCMS
FREELOil
NORDYMSG
RO
R8
UPTSiS
ADTDTA
BATFLAGS
JCSi3
BORDYTIM
Rl
R9
USERCODE
ADTRANS
DMSSMNSB
LINKLAST
SUBICT
AFINIS
DUMCOM
LINKSTRT
SUBFLAG
AF'S
DYLD
LOCCNT
SVCSECT
ASTATE
ALDRTBLS ALIASENT AFGMSECT ARDBUF
DYLIBO
DYMBRNM DYNAEND FREELOiE FRSTLOC
OSRESET OSSFLAGS PGMSECT
MODLIST NUCON
TBINT
ATSOCPFL AUSRAREA BALRSA'! BGCOM
f!AINLIST f!AINSTRT MISFLAGS NUCON
R14
R15
R2
B3
COD!203 COMPSiT
OSSFLAGS OSSMNU
R4
R6
DMSSOP
EITSECT
NOHIPCP
PROTFLAG
RS
TSOBLKS
ASVCSECT AUSRAREA COftPSiT CURRSAVE DMSOLD
LASTLMOD LASTTMOD LDRFLAGS
FVSECT
F65535
STRTADDR
PBFTSYS PBFUSYS PBOTFLAG SCBPTB
I-'
(\)
I
c+
0
t-I
III
1:1"
(\)
I-'
n
H
CURRSAVE EGPRl
EGPR15
PPEND
BELPAGES RO
R7
R8
R9
EOCADR
Rl
SSAVE
FREELOWE LOCCNT
Rl0
R12
MAINBIGB
R13
en
en
~
(\)
ADTSECT
BLK
DMSSCTNP
FCBDCBCT
FCBKEYS
FCBBECFM
IOBIOFLG
OPSECT
Rl
R8
AERASE
CMSCVT
DI"ISSQSGT
FCBDD
FCBLRECL
FCBRECL
IOBNITAD
OSFST
Rl0
R9
AFINIS
Cf!SNAf!E
DMSSQSPT
FCBDE'
FCBMEMBR
FCBSECT
IOBSTART
OSFSTBLK
R11
SAVERl
AFTFST
CURRSAVE
D~SSQSUP FCBELKSZ
FCBDSK
FCBDSMD
FCBMODE FCBMVPDS
FILEBYTE FILEMODE
JFCBIND2 JFCElUSK
OSFSTCHR OSFSTLRL
R12
R 13
SA'ER15 TAPEDEV
AFTIC
DA
FCBBUFF
FCBDSNAft
FCBOP
FILENAME
JFCDSORG
OSFSTRFM
R14
TAPELIST
AFTIN
DEBDCBAD
FCBBYTE
FCBDSTYP
FCEOS
FILEREAD
JFCK!YLE
OSIOTYPE
R15
TAPEftASK
AFTPFST
DEBDEBID
FCBCASE
FCBFIRST
FCBOSFST
FILETYPE
JFCLIMCT
PLIST
R2
TAPEOPER
DEBTCEAt
FCBIOiR
IOESTART
R13
tP.lSSCTCE
FCBITEM
IOBUPD
R14
DI"ISSCTCK
FCBOF
LOC
R15
DMSSEB
FCBPVMB
NUCON
R2
FCBBUFF
FCEREAD
OPSECT
R3
FCBBYTE
FCBSECT
OSIOTYPE
R4
FCBCLOSE
FID
PREVIOUS
R5
FCBCOUT
IHADEB
PS
R6
FCBDEV
IOBECB
RO
R7
FCBDSMD
IOEECBPT
Rl
UND
FCBINIT
IOBIN
Rl0
VAR
RELPAGES RO
Rl
R12
R14
R15
R2
BGCOM
RO
DOSDD
Rl
DOSDEV
Bl0
DOSDSR
R12
DOSOP
R14
DOSOSFST DOSS!CT
R15
R2
LUBPT
R3
R15
R2
R3
R4
R5
R6
R9
BLK
FCBIOSi
IeBOUT
R12
en
tMSSRT
ASCANO
R3
ASTRINIT FREELOiE MAINHIGH MISFLAGS NUCON
R4
R6
R5
0.
tMSS RY
IERISE
NUCOi
R4
AFIBIS
OSFST
R5
ISTATE
ASYSREF AiRBUF
OSFSTtSK OSFSTITN PUBPT
R9
DMSSSK
NUCON
RO
Rl
0
1:1"
I-'
(\)
S
t::I
(t)
c+
(t)
H
III
....c+
0
AC~SCVT
AFTADT
CMSOP
~
d
\oJ.
(\)
0
0.
d
I
ADTIUCi
AUPDISK
DI"ISSCTCK
FCBCCUT
FCBITEM
FCBRDR
IOB!ND
NUCCli
RO
R7
AOPSECT
FCBIORD
IOBIOFLG
Rll
H
~
CPULOG
NOABBREV
PRFPOFF
R4
TIMINIT
ADTFRO
ASTATE
DMSSCTCE
FCBCON
FCBIOSi2
FCBPROCO
IOBDCBPT
MACLIBL
QS
R6
DMSSQS
It:!
\oJ.
CftSVSAM
ftISFLAGS ftSGFLAGS
PPEND
PIBPT
R3
R2
TIMCBAR TIMER
C~SSEG
ADTFLGl
AOSRET
DMSSBS
FCBCLOSE
FCBIOSi
FCBPROCC
IBADEB
MACDIRC
PS
R5
AOPSECT
DEBOFATB
FCBCLEA'
FCBINIT
FCBPROC
F6
LOC
PREVIOUS
R4
VAR
0.
II
:3
CMSDOS
MAINBIGB
OPTFLAGS
R15
TIMCCi
HI
AACTLRF
AFT SECT
DEBOFLGS
FCBCATML
FCBFORM
FCBPDS
FID
JFCOPTCD
PO
R3
UND
~
IDTSECT
BGCOM
LUBPT
NUM
R14
SYSREF
ADEVTAB
ASYSREF
FREELOiE
BOPAGREL
REDERRID
R7
UPTMID
0
DMSSMI
I.Q
III
ADTFDOS
BATFLAG2
JCSi4
NOVMREAD
Rl0
SOBl
USERKEY
ADTM
BATRUN
LTK
NUCON
R12
SYSNAMES
ABATABND
AS TATE
FRDSECT
HOlftPEI
PUBPT
R6
UPSI
V~SIZE
R12
R14
R8
(\)
H
(\)
~
0
(\)
eodule
External References (Labels and eodules)
EHSSTG
AEXTSECT
CORESIZE
EOCADR
NUCON
R12
SCBWORK
ALDRTBLS
CURRSAVE
EITSECT
OLDPSW
R13
SSAVE
ANCHENDA
DHSLGTA
FREELOWE
OPTNBYTE
R14
STIHEXIT
ANCHSECT
tHSSHNCF
IJBBOX
OSSFLAGS
R15
SYSCOft
ANCHSIZ
DeSSeNCN
LIRKLAST
osselu
R2
TAIEADDR
APGHSECT
DHSSHNRP
LIRKSTRT
PDSSECT
R3
USAVEPTR
ASTATEIT
DHSSftNTS
LOCCNT
PGftSECT
R4
ATSOCPPL
DYLD
HACDIRC
PICADDR
R5
AUSRAREA
DYLIBO
HACLIBL
PPEND
R6
BALRSAVE
DYHBRNH
HAlliHIGH
RELPAGES
R7
BGCOH
EGPR12
!UIBLIST
RO
R8
CODE203
EGPR14
HAIBSTRT
Rl
R9
COepSiT
EGPR15
ftISFLAGS
Rl0
SCBPTR
DftSSTT
AACTLKP
AFTSECT
FSTFBWI
Rl
STATERO
ADTFLGl
AFTWRT
FSTft
Rl0
ADTFLG2
DftSLAD
FSTSECT
R12
ADTFRO
DftSLADW
FVSFSTAD
R13
ADTFROS
DftSLFS
FVSFSTDT
R14
ADTFRW
DHSLFSW
FVSFSTft
R15
ADTH
FSTFAP
FVSFSTN
R2
ADTftX
FSTFAR
NUCON
R3
ADTSECT
FSTFAW
OSFST
R4
AFTADT
FSTFB
OSFSTFLG
R5
AFTFLG
FSTFRO
OSFSTFft
B6
AFTFST
FSTFROX
REGSAV3
R9
AFTRD
FSTFRW
RO
STATEFST
DftSSVI
AEITSECT
LOC
R12
TIMINIT
AOPSECT
LSTFINRD
R13
TSOATCNL
COBRDBUF COBRDCRT CONREAD CONSTACK CORWRBUF CORWRCRT CONiRITE CURRSAVE EXTSECT FCBSECT
RUCON
RUftFIRRD RUftFRDiR OPSECT
OSSFLAG.S PERDREAD PERDiRIT PS
RO
Rl
R14
R2
83
R4
R15
R5
R6
R8
STlftEIIT TlftCHAR
TSOFLAGS
FSTFINRD
Rl0
TlftER
tftSSVT
ADftPEXEC
CMBDLIlIIE
DECSDECB
DftSSLN6
DHSSQS
FCBCATHL
FCBHVPDS
FILE-RAftE
KEYBAftE
RUCON
Rl
R8
WAITLIST
ADHSROS
CftSBAftE
DIAGTlftE
DHSSLI7
DHSSVI
FCBCOUT
FCBOF
FILETYPE
KEYOP
OPSECT
Rl0
R9
AERASE
AEXTSECT
CHSOP
• CftSTAXE
DIRNAftE DIRPTR
DHSSLR8 DftSSLI9
DftSSVRl DftSSVN2
FCBDD
FCBDEV
FCBOS
FCBOSFST
IHADEB
IHADECB
KEYSECT KEYTABLE
OSIOTYPE OSRESET
Rll
R12
SCBPTR
STIHEXIT
AOPSECT
CORRDCNT
DHSLGT
DHSS!HI
DftSSVI93
FCBDSK
FCBPDS
IHAJFCB
KEYTBLAD
OSSFLAGS
R.13
TAIEADDR
IftSSYN
AFIIIS
R2
ARDBUF
R3
ASTATE
R4
ROSTDSYR NOCOR
R6
R7
IUSIBRV
B5
APGftSECT
CORREAD
DHSLSB
DftSSftRl0
DftSSVR94
FCBDSNAe
FCBSECT
IOBIN
KEYTBLRO
PDSBLKSI
R14
TAXEDEF
APIE
CONWRBUF
DHSSAB
DftSSftR4
DOSDD
FCBDSTYP
FCBTAB
IOBIOFLG
KEYTYPE
PDSDIR
R15
TAIEEIIT
ARDBUF
CONiRCRT
DftSSBDFR
DHSSftN5
DOSIEXT
FCBFIRST
FCBXTENT
JFCBftASK
LIRKSTRT
PDSSECT
R2
TAIELNK
OPTFLAGS RO
R8
ASTATE
CORiRITE
DftSSBS
DHSSOP
DOSSECT
FCBFORft
FILEBUFF
JFCLRECL
LOC
PGftSECT
R3
TBLLIG:rH
ATFINIS
CORESIZE
DftSSCT
DftSSOP19
DuePLIST
FCBINIT
FILEBYTE
KEYCHNG
LOWSAVE
PLIST
R4
TEHPBYTE
AUPDISK
CURRDATE
DftSSLB
DftSSOP20
EXTSECT
FCBIOSi2
FILECOUT
KEYCOOT
HACDIRC
PREVIOUS
R5
TlftER
AiRBUF
CURRSAVE
tftSSLR3
DftSSOP22
FCBBUFF
FCBITEH
FILEITEft
KEYFORft
ftlCLIBL
PS
R6
VAR
CHNGBYTE
DATAEND
DftSSLR42
DftSSOP23
FCBBYTE
FCBKEYS
FILEftODE
KEYLIGTH
REiBLKS
RO
R7
VftSIZE
Rl
Rl1
R12
R14
R15
(")
3:
en
CD
DHSTIO
ADEVTAE
R12
ATAB!ID
R13
CC
R14
eSi
R15
DEVADDR
SILl
DEVlUSC
DEVNAHE
DEVSECT
DEVSIZE
NUCON
80
Rl
Rll
en
::z
DeSTHA
DftSLIB
R7
RO
R8
Rl
R9
Rl0
R11
R12
R14
R15
R2
R3
R4
R5
86
Po
DeSTPD
CSi
R6
NUCOI
R7
RO
R8
81
89
Rl0
Rll
R12
R14
R15
R2
R3
R4
R5
0
0
r+
1-'0
I:'
.
~
.....
CD
I
r+
0
I
W
t-t
III
t:I
.....
CD
1'1
0
1-'1'1
0
r+
0
1'1
1-'CD
en
tr
CD
(")
en
en
~
(I)
HI
CD
1'1
(I)
tv
I:'
1.0
(I)
~
0
'"0
CD
Module
External References (Labels and Modules)
tMSTPE
AACTLKP
DEVMISC
FSTSECT
R2
c::
3:
"
ADEVTAB
DEVIAME
PSTT
R3
AEBASE
DEVSECT
PSTiP
R4
APIBIS
DEVSIZE
PVSECT
R5
APTFST
PSTD
IUCOI
R6
n
3:
til
AFT SECT
PSTDBC
RO
B7
APVS
PSTPCL
Rl
R8
ASTATE
PSTPV
Rl0
R9
ATABEBD
PSTIC
Rll
UfDBUSY
0
DMSTQQ
00
til
"'
label
Count
(")
References
a:
N
\0
W
t:I
0
(l)
~
\0
label
Count
n
References
tI:
til
~
<
tI:
'"w....,
0
til
J<
en
rT
(1)
EI
t""
0
\Q
~.
0
I»
l:I
0.
~
H
0
t:7'
.....
(1)
EI
t:;
(1)
rt
(1)
H
....l:I
EI
I»
rt
....
0
l:I
en
....
~
0.
(1)
DftSSftHSB
D!SSftITS
DftSSftll0
DftSSftl4
tftSSftl5
DftSSOP
DftSSOP19
DftSSOP20
tftSSOP22
D!SSOP23
tftSSQS
DftSSQSGT
tftSSQSPT
DftSSQSUP
tftSSTGAT
DftSSTTR
DftSSVH
DftSSVll
tftSSVH2
DftSSVI93
DftSSVH94
D!SSVT
tftSVSR
D!SICP
DOSBLKSZ
DOSBUFF
tOSBUFSP
DOSBITE
DOSCBlt
DOSCOUT
tOSDD
DOSDDCAT
tOSDEV
DOSDSK
tOSDSftD
DOSDSHA!
[OSDSTIP
DOSDU!
DOSEID
DOSEISIZ
tOSEIT
DOSEITCT
DOSEITCI
000001
000001
000001
000001
000001
000002
000001
000001
000001
000001
000002
000001
000001
000001
000001
000001
000002
000001
000001
000001
000001
000001
000001
000001
000005
000011
000002
000014
000002
000002
000023
000006
000017
000006
000027
000008
000001
000012
000001
000006
000004
000002
000004
D!SSLH
DftSSTG
D!SSVT
D!SSVT
DftSSVT
D!SSEG
D!SSVT
DftSSVT
D!SSVT
DftSSVT
DftSSEG
DftSSOP
D!SSOP
D!SSOP
DftSFHC
D!SlFS
D!SSEG
DftSSVT
DftSSVT
DftSSVT
DftSSVT
D!SSEG
DftSFHC
DftSDOS
D!SBOP
D!SBOP
DftSDLB
D!SICP
D!SDLB
DftSICP
DftSAft S
DftSDLB
DftSAft S
DftSDLB
D!SA!S
D!SCLS
D!SDLB
DftSAftS
D!SDLB
DftSDLB
DftSBOP
D!SBOP
D!SICP
t""
I»
t:7'
(1)
.....I
rT
0
I
DftSSVT
tI:
0
0.
~
.....
(1)
D!SSVT
n
H
0
til
til
l:I:l
(1)
D!SSVT
H1
(1)
H
(1)
l:I
0
(1)
DftSICP
D!SICP
DftSICP
DftSBOP
DftSCLS
DftSDLB
DftSDLK
DftSDSV
DftSOPL
DftSBBV
DftSBOP
D!SDLK
D!SBOP
DftSDLB
DftSDLB
DftSBBV
D!SDLB
D!SICP
DftSDLK
DftSSRV
DftSVIF
DftS RBV
DftSICP
D!SICP
DftSSBV
DftSVIP
DftSICP
D!SBOP
DftSDLB
DftSVIP
D!SICP
DftSSRV
DftSSVT
DftSVIP
DMSICP
Ul
(!)
0
r+
~.
0
t:I
.
W
~
~.
11
CD
0
M-
0
11
Label
Count
References
DOSEITNO
DOSEITTB
DOSFOBfil
DOSIBIT
DOSITE!!
DOSJCAT
DOSREIT
DOSOP
DOSOSDSI
DOSOSFST
DOSPEBfil
DOSBEAD
DOSSAVE
tOSSECT
DOSSERSE
tOSSYS
DOSTAPID
tOSUCAT
DOSUCBAl!
DOSVOLNO
DOSVOLTB
tOSWOBK
DOSYSIII
DOUBLE
DSKAD
tSKADB
DSKLII
DSKLOC
DSKLST
DSYl!
DTAD
tTADT
DTAS
tUALBOS
DUMCOl!
I:UMPLIST
DYLD
DYLIBO
DYl!BBBM
I:YBAEBD
EDCB
EDCBENt
EDCBLTB
000009
000007
000006
000013
000007
000006
000011
000034
000007
000009
000002
000009
000006
000028
000008
000002
000002
000006
000007
000011
000007
000004
000015
000021
000002
000006
000066
000010
000020
000002
000029
000022
000003
000008
000004
000002
000012
000004
000005
000004
000005
000001
000002
DfilSAfilS
DfilSAfilS
Dl!SBOP
Dl!SBOP
DfIlSICP
Dl!SDLB
DfilSAl!S
DfIlSBOP
DfilSDLB
DfIlSBOP
DfIlSDLB
DfIlSICP
DfIlSICP
DfilSAfilS
Dl!SICP
Dl!SBOP
DfIlSICP
Dl!SBOP
DfilSEOP
Dl!SAMS
DMSAl!S
DMSICP
DfilSAfilS
Dl!SDIO
Dl!SLIO
Dl!SACF
Dl!SLIO
DMSACF
Dl!SACF
DMSLSY
Dl!SACC
Dl!SACl!
DMSAMS
DMSEDC
DMSSLI
DMSDBG
Dl!SLDB
DMSSLB
Dl!SLIB
Dl!SLDB
Dl!SEDC
Dl!SEDI
DMSEDI
DfilSDLE
DfilSDLB
DfilSVIP
DMSVIP
DfilSICP
DMSICF
Dl!SDLB
DMSICP
DfIlSBOP
DfilSDLK
DfIlSICP
Dl!SDLB
DfilSCLS
DfIlSRBV
DfIlSDLB
DfIlSSBV
DMSOPL
Dl!SICP
DfIlSSVT
Dl!SDLK
Dl!SBBV
DfIlSSBV
DMSICP
DfilSBOP
DMSCLS
Dl!SDLB
DfIlSDLK
DMSDSV
DfilSDLB
Dl!SDLE
Dl!SDLB
DfIlSDLE
DMSICP
DMSVIP
DMSVIP
DfIlSICP
DfIlSICP
DfIlSBOP
DMSCLS
DMSDLB
DfIlSVIP
DMSICP
DMSACl!
DMSAUD
DMSEBS
Dl!SACl!
DfilSACM
DMSAUD
DMSAUD
DfilSEBS
DMSEBS
DfIlSFBS
DMSFBS
DMSl!OD
DfilSMOD
DfilSACM
Dl!SASB
DMSAl!S
Dl!SAUD
DMSABE
DMSDIO
Dl!SASB
DMSQBY
DPISDIO
Dl!STQQ
Dl!SVIP
DfilSICP
Dl!SOPL
DMSBBV
DMSSBV
DMSSVT
DMSFOB
DPISINS
DPISQBY
DfIlSBOS
DMSVIP
Dl!SICP
DfilSOPL
n
DMSSVT
DMSLIO
Dl!SSTG
DMSSLB
DMSOLD
DMSEDI
DPISOLD
DMSSTG
Dl!SSLR
DMSEDI
DMSSLB
DMSSTG
t:I:
Ul
t'"I
~
t:T
(1)
DMSGIO
DPISSCB
~
I
r+
0
I
t:I:
0
~
~
~
(1)
n
11
0
en
en
~.
CD
!:d
en
CD
....,
'"
(1)
(1)
11
I,Q
(J1
t:I
0
CD
I\.)
\0
Label
Count
n
Beferences
lJI:
U'l
0'\
<
lJI:
"w
.,.J
0
00
U'l
~
[J1
rT
CI>
iii
t-t
0
....
IQ
0
PI
1:1
~
ttl
t1
0
t:I"
....CI>
Ell
c;,
(1)
r+
(1)
t1
Ell
....1:1
PI
....rT
0
1:1
Cil
....s::
~
(1)
EDCT
EDLIlII
IDftSK
EDBET
EDiOBK
EFPBS
1!GPBS
EGPBO
IGPBl
EGPBll
IGPB12
EGPB14
IGPB15
EGPB2
EBDBLOC
ElIIDCDADB
EBDTABS
ElIITADB
ERTRAftE
EOCADB
EBBIT
EBBL
EBDSECT
ERllBl
ERllBD
ERll SBI
EBllSBl
ERllTI
EBl2Cft
ERl2DI
ERl2DT
ERl2PR
ERl2SI
ERLET
lRftESS
ERROft
ERPAS 13
ERPBlA
ERPCS
ERPFl
ERPl2
EBPBDB
!RPLET
000026
000013
000003
000003
000001
000004
000021
000062
000037
000002
000003
000009
000034
000006
000003
000006
000004
000008
000005
000006
000006
000001
000002
000002
000003
000005
000003
000002
000004
000001
000001
000002
000001
000001
000002
000002
000001
000002
000001
000013
000012
000001
000001
DftSEDI
DftSEDI
Dft SSCB
DftSEDI
DftSEDI
DftSITS
DftSABlII
DftSDLB
DftSLDB
DftSITS
DftSSTG
DftSITS
DftSITS
DftSITS
DftSEDI
DftSLDB
DftSEDI
DftSLDB
DftSLDB
DftSDftP
DftSACl
DftSEBB
DftSERB
DftSEBB
DftSERR
DftSEBB
DftSERR
DftSEBB
DftSEBR
DftSEBB
DftSERR
DftSERR
DftSERR
DftSEBR
DftSERR
D!SEBR
DftSERR
D!SERB
D!SERR
D!SERR
DftSERR
DftSEBR
DftSERB
t-t
PI
t:I"
Df5SEDI
....CI>I
DftSEDI
rT
0
DftSOYS
DftSBSC
DftSlLD
DftSSftR
DftSITS
DftSITS
tlftSSTG
DftSOVS
DftSSftB
DftSEDI.
DftSLSE
DftSEDI
DftSOLI:
DftSLSB
DftSSftR
DftSEBS
DftSCVS
DftSOVS
I
lJI:
0
~
s::
....
CI>
n
DftSSTG
t1
0
[J1
[J1
DftSOLD
~
CI>
~
DftSOLD
DftSSTG
DftSBRft
CI>
t1
CI>
1:1
0
(I)
til
CD
n
....r+0
t:I
Label
Count
References
ERPNOft
ERPSBA
ERPTIA
ERRCODE
ERRCODO
ERRCODl
ERRET
ERRNOft
ERSAVE
ERSBD
ERSBF
ERSBL
ERSECT
ERSFA
ERSFL
ERSFLAG
ERSFLST
ERSSZ
ERTEIT
:ERTPL
ERTPLA
ERTPLL
ERTSIZE
:ERTl
ERT2
ESD1ST
ESIDTB
EXADD
EIAftLC
EXAftLG
EIECFLAG
EIECRON
EIENACiB
EXENADtR
EILEODF
EXLEODL
EILEODP
EILEVEL
BILJRN
EILJRNL
BILLEN
ULLERF
EILLERL
000001
000004
000003
000063
000009
000017
000035
000002
000007
000013
000010
000005
000001
000004
000005
000050
000002
000002
000004
000004
000006
000008
000002
000008
000013
000007
000040
000008
000005
000006
000003
000004
000009
000002
000004
000001
000001
000006
000002
000004
000009
000004
000001
DftSERR
DftSERR
DftSERR
DftSDIO
DftSACft
DftSACF
DftSITS
DftSINT
DftSERR
DftSERR
DftSERR
DftSERR
DftSERR
DftSERR
DftSERR
DftSERS
DftSERR
DftSERR
DftSERR
DftSERR
DftSERR
DftSERR
DftSERR
DftSERR
DftSERR
DftSLDR
DftSLDR
DftSEXC
DftSDBG
DftSDBG
DftSEIC
DIISEIC
DftSVIP
DftSVIP
DftSVIP
DftSVIP
DftSVIP
DIISEXC
DftSVIP
DftSVIP
DftSVIP
DftSVIP
DftSVIP
DftSERS
DftSRNft
DftSRNft
DIISOLD
DftSOLI:
DftSEIT
n
3:
til
t-I
DftSEXT
I»
~
CD
...,
t
r+
0
t
3:
0
~
~
W
...,
....0
CD
t1
t1
0
CD
n
n
r+
rn
rn
....
!:C
rn
CD
0
t1
CD
CD
I-h
t;
CD
f\..)
\0
..J
:::s
n
(I)
....,
I.C
Label
count
References
n
13
til
(X)
MSINS
DMSLGT
DMSOPT
DMS RNM
DMSSQS
DMSTPE
DMSAUD
DMSCPF
DMSFCH
DMSINT
DMSLIB
DMSORl
DMSROS
DMSSRT
DMSTRK
DMSARX
DMSCRD
DMSFCH
DMSITE
DMSLIO
DHSRNE
DM SSVN
DMSASM
DMSCW R
DMSFLD
DMSITI
DMSLSB
DMSRNM
DMSSVT
DMSASN
DMSDEG
DMSFNS
DMSITP
DMSLST
DMSSAB
DMSTIO
DMSAUD
DMSDIO
DMSFOR
DMSITS
DMSMOD
DMSSBS
DMS'tPE
DMSBAB
DMSDLB
DMSGIO
DMSLAD
DMSMVE
DMSSCR
Df'lSTRK
n
CD
en
CD
0
t+
.....
0
1:1
W
Label
Count
References
R14
002863
R~5
004744
R2
003449
B3
003494
Df!SABN
DnSBAB
DnSCRD
Dl!SEDX
DnSGRH
DMSITS
D8SLLO
Df!SOVR
DftSRRV
DMSSRT
DKSTRK
Df!SABN
Df!SBAB
D8SCRD
DnSEDI
DnSGRN
DHSITS
Df!SLLO
DHSOR 1
Dl!SROS
DeSSQS
DeSTPE
D!SACC
DHSBOP
DeSCWR
DeSERS
DHSBDI
DMSLAF
DMSHDP
Df!SPUN
Df!SSCT
DMSSVT
DMSICP
DeSABN
DHSBAB
DHSCRD
DHSERS
DMSlNA
DHSLBT
DHS8VE
DHSRNE
DHSSHN
Df'ISTPD
D!SACC
D8SBOP
DnSCWR
DMSERS
D8SHtI
Df!SLAD
D8SLOA
Df!SOVS
Df!SSAE
Df!SSRV
DKSTYP
Df!SACC
Df'ISBOP
D8SCWR
DnSERS
DnSBDI
DMSLAD
Df!SLOA
Df'ISOVR
DeSRRV
Df!SSRT
Dl!STBK
Df!SACF
D8SBRD
DeSDBD
Df!SEIC
Df!SBDS
DMSLEe
DMSMOD
DeSQBY
Df!SSEB
DeSSYN
DMSZAP
DMSACC
DHSBOP
D8SCWB
DHSEIC
DHSINI
DMSLDR
D8SNCP
DHSRNM
DI'!SSOP
DMSTPE
DftSACF
D8SBRD
DnSCWT
D8SEIC
DKSHDS
Df!SLAF
Df!SLSB
Df!SPlO
Df!SSBD
Df!SSSK
DKSOPD
Df!SACF
Df'ISBRD
Df!SCWT
DnSEXC
Df'ISHDS
Df!SLAF
DHSLSB
Df'ISOVS
DMSSAB
Df'ISSRV
Dl!STYP
Df!SACf'I
DeSBSC
DKSDBG
Dl!SEIT
D8SlNA
Dl!SLBT
DMSMVE
DMSRDC
DMSSET
DeSTMA
nnSAce
D8SBSC
Df'ISDBD
DKSEIT
DKSIHA
D8SLBf!
Df!SLST
Df!SPHT
DKSSBS
Df!SSTG
Df'ISVIB
Df'ISACK
Df'ISESC
Df'ISDBD
DMSEIT
Df'ISINA
Df!SLBf!
Df!SLST
Dl!SPIO
DKSSBD
DeSSSK
DeSOPD
Df'ISALO
DKSBTB
DeSDlO
Df!SFCB
DeSINI
tMSLDB
DeSNCP
DMSRNE
DeSSf!N
DMSTPD
D8SALO
DnSBTB
D8SDBG
DnSFCH
DKSlHI
D8SLBT
Dl!SLSY
Df!SPRT
Df!SSCN
Df!SSTT
Df!SVIP
Df!SALO
D8SBTB
Df'ISDBG
DnSFCH
Df'ISIHl
Df!SLBT
Df!SLSY
Dl!SPNT
DHSSBS
DeSSTG
DMSVIB
D8SA8S
DeSBTP
DHSDLB
DKSFET
Des INK
DMSLDS
DeSOLD
DeSRNe
Dessop
Df!STPE
DnSA!S
DnSBTP
Df'ISDlO
DKSFET
DKSINK
Df!SLDR
Df!Sf!DP
Df!SPRV
Df'ISSCR
Df!SSVN
Df!SVPD
Df!SAf'IS
Df'ISBTP
Df'ISDlO
DMSFET
Df'ISlNf'I
Df!SLDR
Df!SHDP
Dl!SPRT
Df'ISSCN
DeSSTT
Dl!SVlP
DHSARE
DeSBiR
D!SD!P
Df!SFLD
Des INS
DMSLFS
DKSOPL
DMSROS
Df!SSQS
DMSTRK
DnSARE
DKSBWR
Df'ISDLB
DKSFLD
Df!SlHS
Df!SLDS
Df!Sf!OD
DMSPON
Dl!SSCT
DMSSVT
Df!SVSR
DMSARE
Df'ISBWR
Df'ISDLB
Df'ISFLD
Df!SINS
Df!SLDS
Df'ISf'IOD
DMSPRV
DHSSCR
DeSSVN
DeS'IPD
DHSARN
DMSCAT
DHSDOS
Dl!SFNS
DKSlNT
Dl!SLIO
DHSOPT
D.MSRRV
Df!SSRT
DMSTYP
Df!SARN
D!SCAT
DKSDOS
DKSFNS
Dl!SlHT
Df!SLFS
DKSl!VE
Df!SQRY
Df'ISSEB
Df!SSYN
Df!SICP
Df'ISARN
Df'ISCAT
Df'ISDOS
DMSFNS
Df'ISlNT
Df! SLFS
Df!Sf'IVE
DHSPON
Df'ISSCT
DeSSVT
Df'ISVSR
Df'ISARI
DKSClO
D!SDSK
Dl!SFOR
DMSIOW
DMSLKD
DMSOR 1
DKSSAB
DeSSRV
DMSOPD
Df!SARI
DnSClO
DKSDSK
DKSFOR
Df!SIOW
Df!SLGT
Dl!SNCP
Df!SRDC
DKSSET
DnSTlO
DMSZAP
DnSARI
Df'ISClO
DnSDSK
DMSFOR
DMSlOW
Df'ISLGT
Dl!SNCP
DHSQRY
Df'ISSEB
DHSSYN
DeSICP
DeSASH
D8SCIT
DHSDSL
DHSGIO
DMSITE
DKSLLU
DeSPlO
Dl!SSBD
DeSSSK
DKSVIB
DnSASK
DnSClT
Dl!SDSL
DKSGIO
DKSITE
Df!SLlB
Dl!SOLD
Df!SRHE
DKSSMN
Df!STKA
D!SASN
DKSCLS
DKSEDC
DKSGLB
DKSITl
Df!SLlO
Dl!SOPT
Df!SRNM
DMSSOP
Df!STPD
DeSAOD
D8SCPF
Dl!SEDI
DKSGND
DKSlTP
DeSLKD
Dl!SOR3
DftSROS
DeSSQS
DMSTPE
DnSASf!
Df'ISClT
DnSDSL
DHSGlO
Df!SITE
DMSLlB
Dl!SOLD
DHSRDC
DeSSET
DHSTIO
Df'ISZAP
DHSASN
D8SCLS
DMSEDC
DHSGLE
DMSlTP
DMSLOA
DMSPNT
DMSSES
DMSSTG
DeSVIP
DMSASN
Df!SCLS
Df'ISlDC
DMSGLB
DKSITl
Df!SLlO
Dl!SOPL
DeSRNE
DHSSMN
DMSTl!A
DMSAOD
DeSCPF
DMSEDI
DnSGND
DMSlTP
DMSLKD
Dl!SOPT
DeSRNK
Dessop
Df'ISTPD
DHSAOD
DKSCPF
Df!SEDl
DHSGND
DMSlTS
DMSLSB
DeSPRT
DMSSCN
DMSSTT
DMSVPD
DeSBAB
DMSCRD
D8SEDX
Df!SGRN
DeSLAD
DMSLST
DMSPBV
DMSSCR
DeSSVN
DMSVSR
DMSACF
D8SBRD
DMSDBD
DHSEIT
DMSINM
DHSLDS
D8S0LD
DHSROS
DI'!SSQS
DHSTRK
DMSACK
DeSBSC
tKSDBG
DHSFCB
DMSINS
DMSLFS
DMSOPL
DHSRRV
DMSSRT
DHSTYP
DeSALO
DeSBTB
D8SDLB
D8SFET
DMSINT
DMSLGT
Df'I SO VR
DMSSAB
Df!SSRV
DltSOPD
DMSAHS
DHSBTP
D8SDHP
DMSFLD
DMSlTE
DKSLlO
DMSOVS
DMSSBD
DMSSSK
DMSVIB
DHSARE
DeSBWR
DHSDOS
DMSFOR
DMSlTl
DHSLKD
DMSPlO
DMSSBS
DMSSTG
DltSVIP
DKSARN
DHSCAT
DMSDSK
DMSGLB
DKSlTP
Df'ISLLO
DMSPRT
DHSSCN
DHSSTT
DMSVPD
D8SARI
DMSClO
DHSDSL
DMSGND
Df'ISlTS
Df'ISLSB
Df'ISPRV
DMSSCR
DMSSVN
DMSVSR
DHSASM
DHSClT
DHSEDC
DMSGRN
DMSLAD
DMSLST
DMSPON
Df'ISSCT
Df!SSVT
Dlt SXCP
DHSASN
DMSCLS
DMS EDI
DMSHDI
DHSLAF
DMSKDP
DMSQBY
DHSSEB
DMSSYN
DltSZAP
DMSAOD
DMSCPF
DMSEDI
DMSHD~
DMSLBM
DMSMOD
DMSRDC
DHSSET
Df!STI'lA
n
3:
en
t-'
I»
t:1'
CD
I-'
I
t+
0
I
3:
0
/:lI
~
t:='
.....
I-'
CD
t1
CD
(')
t+
rJl
rJl
0
0
t1
.....
CD
t1
0
!:tI
CD
rJl
Ht
W
t:S
CD
t;
CD
~
w
0
CD
w
~
Label
Count
References
('l
:I:
til
C
R4
002780
<
:I:
"
w
..,.J
0
til
'<
til
cT
(!)
RS
002930
e
t'"4
0
I.Q
1-"
n
III
=
0...
'"0
H
0
R6
002486
R7
002318
0'
~
(I)
e
I:'
(I)
cT
(I)
H
e
1-"
=
III
cT
.....
0
=
en
c
1-"
0...
(!)
DI!SABH
DMSBAB
DMSCRD
DMSEDX
DMSHDI
DI!SLAF
DI!SMDP
DMSQRY
DMSSET
DMSTMA
DMSABN
DMSBAB
DMSCiR
Dl'lSERS
Dl'lSHDI
DMSLAF
DMSMOD
Dt!lSQRY
Dt!lSSET
DMSTPD
Dt!lSABN
Dl'lSBAB
DMSDBD
DMSEXT
DMS1NS
DMSLGT
Dt!lSOVR
DMSSAB
DMSSTG
DMSVPD
Dl!SABN
DMSBOP
DMSD10
DMSFET
DMSIOi
DMSLIB
DMS FRT
DMSSCT
DMSTYP
DMSACC
DMSBOP
DMSCWR
DfilSERS
DMSHDS
DMSLBM
DMSI!OD
DMSRDC
DMSSMN
DMSTPD
DMSACC
Dl'lSBOP
DMSDBD
DMSEXC
DMSHDS
DMSLEM
DMSMVE
Dt!lSRDC
Dt!lSSOP
DMSTPE
DMSACC
DMSBOP
DMSDBG
DMSFCH
DMSINT
Dt!lSLKD
DMSOVS
DMSSBD
Dl!SSTT
DMSVSR
DMSACC
Dl!SBRD
DMSDLE
Dl!SFLD
DMSITE
DMSLKD
DMSPUN
DMSSET
Dl'lSUPD
DI!SACF
DfilSBRD
DMSDBD
DMSEXC
DMSINA
DMSLBT
DMSMVE
DMSRNE
DMSSOP
DMSTPE
DMSACF
DMSBRD
DMSDBG
DMSEXT
DMSINA
DMSLBT
Dt!lSNCP
DMSRNE
DMSSQS
DMSTRK
DMSACF
DMSBRD
DMSDIO
DMSFET
DMSIOi
Dt!lSLLU
DMSPIO
DMSSBS
DMSSVN
Dl!SXCP
Dl!SACF
Dl!SBSC
DMSDMP
DMSFNS
DMSITI
DMSLLU
DMSQRY
DMSSMN
DMSVIP
DMSACM
DMSESC
tMSDBG
DfilSEXT
DI!SIN1
tMSLDR
DI!SNCP
DMSRNM
DMSSQS
DMSTRK
DMSACM
tMSBSC
DMSD10
DMSPCH
DMSIN1
DMSLDR
Dt!lSCLD
DMSRNM
DMSSRT
DMSTYP
DMSACM
DMSBSC
DMSDLE
DMSPLD
DMSITI
I:MSLOA
DMSPNT
DMSSCN
Dl'ISSVT
DMSZAP
DMSACM
Dl!SBTP
DMStOS
DMSFOB
DMS1TP
DMSLSB
DMSRDC
DMSSOF
DMSVPD
DfilSALU
DMSBTB
DMSDIO
DMSFCH
DI!SINM
DMSLDS
DMSOLD
DfilSROS
DMSSRT
DMSTYP
DMSALU
DfilSBTB
DMSDLB
DMSFET
DMSINM
DMSLDS
DMSOPL
DMSROS
DMSSRV
DMSUPD
DMSALU
Dt!lSBTP
DMSDMP
DMSFNS
Dt!lS1TP
DMSLSB
DMSPRT
Dl!SSCR
DMSSYN
Df!SAMS
DMSBTP
DMSDLB
DMSFET
DMS1NS
DMSLFS
DMSOPL
DMSRRV
DMSSRV
DMSUPD
DMSAMS
Dl'lSBTP
Dt!lSDt!lP
DMSFLD
DMSINS
Dl'lSLFS
Dt!lSOR1
DMSRRV
DMSSSK
DMSVIB
DMSAMS
DMSBiR
Dt!lSDOS
DMSFOR
DMSITS
DMSLST
DMSPUN
Dl!SSCT
DMSTl!A
DMSBWR
DMS DMP
DMSFLD
DMSINT
DMSLGT
DMSOVR
DMSSAB
DMSSSK
DMSVIP
DMSARE
DfilSBiR
DMSDOS
DMSFNS
DMSINT
DMSLGT
Dt!lSOVR
DMSSAB
DMSSTG
DMSVIP
DMSARE
DMSC10
DMSDSK
DMSGND
DMSLAD
DMSMOD
DMSQRY
DMSSET
DMSTPD
DfilSARN
DMSCAT
DMSDOS
DMSFOR
DM SlOW
DMSLIO
DMSOVS
DMSSBD
DMSSTG
DMSVPD
DMSARN
DMSCIO
DMSDSK
DMSFOR
DMS10i
DMSLIB
DM SOVS
DMSSBD
DMSSTT
DMSVPD
DMSARN
DMSCIT
DMSEDC
DMSGRN
DMSLBM
DMSMVE
DM SRDC
DMSSMN
DMSTPE
DfilSARX
DMSCIO
DMSDSK
DMSGIO
DMSIT1
DMSLKD
DMSPIO
DMSSBS
DMSSTT
DMSVSR
DMSARX
Dl'lS CIT
Dt!lSDSL
DMSGIO
DMSIT1
Dl'lSLKD
DMSPIO
DMSSBS
DMSSVN
DMSVSR
DMSARX
DMSCLS
DMSEDI
DMSHDI
DMSLBT
DMSNCP
DMSRNE
Dl'lSSOP
DMSTRK
DMSASM
DMSCIT
DMSDSL
DMSGLB
DMSITP
DMSLLU
DMSPNT
DMSSC·N
DMSSVN
DMSXCP
DMSASM
DMSCLS
DMSEDC
DMSGLB
DMSITP
DMSLLU
DMSPNT
DMSSCN
DMSSVT
DMSXCP
DMSASM
DMSCPF
DMSEDX
DMSHDS
DMSLDR
DMSOLD
DMSRNM
Dl!SSQS
Dl!STYP
DMSASN
DMSCLS
DMSEDC
DMSGND
DMSITS
DMSLSB
DMSPRT
DMSSCR
DMSSVT
DMSZAP
DMSASN
DMSCPF
Dt!lSEDI
DMSGND
DMSITS
DMSLSB
DMSPRT
DMSSCR
DMSSYN
DMSZAP
DMSASN
DMSCRD
DMSERS
Dl'lSINA
DMSLDS
DMSOPL
Dt!lSROS
DMSSRT
DMSUPD
DMSAUD
DMSCPF
DMSEDI
DfilSGRN
DMSLAD
DMSLST
DMSPUN
DMSSCT
DMSSYN
DMSALU
DMSBiR
DMSDSK
DMSGLB
DMS1TS
Dl!SLST
DMSRNE
DMSSQS
DMSVSR
DMSAMS
Dl!SCIO
DMSEDC
DMSGRN
DMSLAD
DMSMOD
DMSRNM
DMSSTG
DMSXCP
DM.SARE
DMSCIT
DMSEDI
DMSHDI
DMSLBM
DMSMVE
DMSROS
DMSSVT
DMSZAP
Dl'lSARN
DMSCLS
DMSEDX
DM SEDS
DMSLBT
DMSOLD
DMSRRV
DMSSYN
DMSARX
DMSCPF
DMSERS
DMS1NA
DMSLDR
DMSOPL
DMSSAB
DMSTMA
DMSASM
DMSCiR
DMSEXC
DMSINI
DMSLDS
DMSOVR
DMSSED
DMSTPD
DMSASN
Dl!SDBD
DMSEXT
DMS1NS
DMSLFS
DMSOVS
DMSSCN
DMSTPE
DMSAUD
Dl'lSDBG
DMSFCH
DMS1NT
DMSLGT
DMSP10
DMSSCB
DMSTRK
DI!SA~E
DMSAUD
DMSCRD
DMSEDX
DMSGRN
DMSLAD
DMSLST
DMSPUN
DMSSCT
DMSTMA
DMSAUD
DMSCiR
DMSEXC
DMSIII1
Dl'lSLFS
DMSOR1
DMSRRV
Dl'ISSSK
Dl!SV1P
t'"4
III
0'
(I)
~
I
M"
0
I
3:
0
0...
~
~
(I)
n
H
0
til
til
~
(I)
I-tt
(I)
H
(I)
=
n
(I)
en
CD
n
....0
t1"
CI
.
W
Label
Count
References
R8
001983
R9
001779
SAVCNT
SAVCWD
SAVEADT
SAVEAR
SAVERl
SAVER14
SAVER15
SAVEXT
SAVEl
SAVE2
SAV67
SCAW
SCBPTR
SCBSAV12
SCBWORK
SCLNO
SCRBUFAD
SCRFLGS
SCRFLG2
SDISK
SEARCH
SEEK
SEEKADR
SENCCW
SENSB
SEQ NAME
000004
000021
000002
000010
000042
000013
000002
000002
000020
000003
000006
000003
000014
000004
000008
000002
000002
000033
000015
000004
000035
000036
000001
000002
000002
000004
DMSABN
DMSBAB
DMSCWR
DftSEXC
DMSINM
DMSLLU
DMSPUN
DMSSET
DP.lSTYP
DMSACC
DMSBOP
DMSDLB
DMSFOR
DMSITS
DP.lSMVE
DMSSAB
DMSTMA
DMSEDI
DMSEDI
DMSDIO
DMSEDC
DMSSOP
DMSSCT
DMSSOP
DMSITE
DftSDBD
DMSDBG
DMSLDR
DMSITE
DMSITP
DMSSAB
DMSSAB
DP.lSSCR
DMSEDX
DMSEDI
DMSEDI
DP.lSINI
DMSINI
DPISI NI
DMSDIO
DP.lSDIO
DMSDIO
DMSEDI
DMSACC
DMSBOP
DMSDBD
DftSEXT
DMSIOW
DftSLSB
DMSQRY
DMSSMN
DMSUPD
DMSACF
DMSBRD
DP.lSDOS
DMSGlID
DMSLAD
DMSNCP
DMSSBD
DMSTPD
DMSSCR
DPlSACF
DMSBRD
DMSDBG
DftSFCB
DMSITI
DMSLST
DMSRDC
DMSSOP
DP.lSVIP
DMSACP.I
DMSBSC
DMSDSK
DMSGRN
DMSLBM
DP.lSOLD
DMSSCR
DMSTPE
DMSACPI
DMSBSC
DMSDIO
DMSFLD
DMSITP
DMSMOD
DMSRNM
DMSSSK
DMSVSR
DMSALU
DMSBTP
DMSEDC
DMSBDI
DMSLBT
DP.lSOPL
DMSSCT
DMSTRK
D8SALU
DMSBTB
DMSDLB
DftSFNS
DMSITS
DMSMVE
DMSROS
DMSSTG
DP.lSXCP
DMSAMS
DMSBWR
DMSEDI
DMSBDS
DMSLDR
DP.lSPIO
DMSSET
DMSTYP
DMSSLN
DMSSTG
DMSSVT
D8SAftS
DMSBTP
DMSDOS
DMSFOR
DP.lSLAD
DMSNCP
DMSRRV
DMSSVN
DP.lSZAP
DP.lSARE
DMSCIT
DftSEDX
DP.lSINA
DMSLDS
DMSPRT
DMSSMN
DMSUPD
DftSARE
DMSBWR
DP.lSDSK
DMSGLB
DMSLBM
DP.lSOLD
DftSSAB
DMSSVT
DftSARN
DMSCIO
DMSDSL
DMSGRN
DMSLBT
DMSOPL
DP.lSSBD
DMSSYN
DPISARX
DMSCIT
DMSEDC
DMSBDI
DftSLDR
DMSOVR
DMSSBS
DMSTMA
DftSASP.I
DMSCLS
DMSEDI
DMSBDS
DftSLDS
DMSOVS
DMSSCN
DMSTPD
DMSASlI
DMSCPF
DP.lSEDX
DftSINA
DftSLFS
DMSPIO
DMSSCT
DftSTPE
DMSAUD
DMSCRD
DMSERS
DMSINI
DMSLGT
DMSPRT
DMSSEB
DPlSTRK
DMSARN
DMSCLS
DMSERS
DMSINI
DMSLFS
DMSPUN
DMSSOP
DMSVIP
DMSARX
DMSCRD
DP.lSEXC
DMSINS
DMSLGT
DP.lSQRY
DMSSRV
DMSXCP
DP.lSASM
DMSCWT
DMSEXT
DftSINT
DMSLKD
DMSRDC
DMSSSK
DMSZAP
DMSASN
DMSDBD
DftSFCB
DMSIOW
Dft SLSB
DMSRNM
DMSSTG
DP.lSAUD
DP.lSDBG
DMSFLD
DP.lSITI
DftSLST
DftSROS
DMSSTT
DMSBAB
DPiSDIO
DftSFNS
DP.lSITP
DMSftOD
DMSRRV
DMSSVT
DMSSCR
DMSSEE
DMSDBG
DMSOLD
DMSSAB
DMSSTG
DMSSCR
DP.lSSCR
DMSSCR
n
1:1:
U')
t"4
~
t:1'
CD
.....
I
t1"
DMSFNS
DMSEDX
0
I
1:1:
0
s:lI
c:
.....
t:I
CD
1'1
n
....
CD
n
t1"
0
11
....
CD
en
-
1'1
0
en
en
~
CD
HI
CD
11
CD
w
t:I
VI
CD
n
..
w
Label
Count
n
References
0(
0\
<
0(
"w
..
....J
0
til
IoocI
en
rT
CD
iii
1:"4
0
\.Q
~.
n
PI
I:'
~
Itj
t1
0
t:l"
1-1
CD
iii
t='
CD
("t
CD
11
iii
~.
I:'
PI
("t
~.
0
I:'
en
~
~.
~
CD
til
SERSAV
SERTSEC
SERTSW
SETLIB
SETSEC
SIG BAL
SILl
SIZE
SKEY
SOBl
SPARES
SPEC
SPIESAV
SSAVE
000002
000003
000003
000002
000002
000053
000205
000022
000003
000002
000015
000189
000002
000056
SSAVElIlXT
SSAVEPRV
SSAVES2
STACKAT
STACKATL
STAEBIT
STAESAV
STAIBIT
STARS
START
STATEFST
STATERO
STATERl
STIMEXIT
STOPAT
STRTADDR
STRTNO
SUBACT
SOBFLAG
SOBINIT
SOBSECT
SVCAB
SVCOPSi
SVCOUNT
SVCSECT
SVEARA
SVEPSi
000004
000008
000003
000001
000005
000003
000002
000002
000001
000022
000022
000002
000005
000009
000002
000030
000005
000003
000024
000001
000004
000008
000020
000003
000010
000008
000008
DMSEDI
DMSEDI
DMSEDI
DMSLIB
DMSINI
DftSACft
DMSINI
DftSFRE
DMSFRE
DftSOPT
DMSEDI
DMSLDR
DMSINT
DMSABN
DMSSTG
DftSITS
DMSITS
DftSITS
DftSEDI
DMSEDI
DMSSAB
DMSINT
DMSSAB
DMSINT
DMSLDR
DMSALU
DftSBRD
DMSDSK
DMSITE
DMSDBG
DMSFET
DMSEDI
DMSEDX
DMSABN
DMSFNS
DMSABN
DMSFRE
DMSITS
DMSOVS
DMSCIT
DMSBAB
DMSBAB
1:"4
PI
t:l"
CD
1-1
I
("t
DftSEDI
D1!SINS
0
DMSERS
DftSTIO
I
tI:
0
~
~
1-1
CD
DftSSET
DMSEDX
DftSLGT
DftSLIB
DMSOLD
DMSBSC
DftSDBG
DMSDLB
n
11
0
DftSERR
DftSFLD
DftSFRE
DMSITP
DftSITS
DftSLDR
DftSOVS
DftSSMN
en
en
~
CD
HI
CD
11
CD
I:'
n
CD
DMSLSB
DMSBRD
DftSSTT
DMSERS
DMSSTG
DMSERS
DMSfNS
DMSSVN
DMSSVT
DMSITS
DMSLDR
DMSINT
DMSEDX
DMSSLN
DMSfNS
DMSI!M
DMSINT
DMSFRE
DMSDOS
DMSDOS
DMSBDS
DMSITP
DMSITP
DMSINT
DMSPUN
DMSRNft
DMSSTT
DMSLOA
DMSLSB
DMSMOD
DMSOLD
DMSSLN
DMSIRT
DMSMOD
DMSSLN
DMSI!T
DMSOVR
DMSOVS
DMSSLN
en
CI)
(')
rT
1-"
0
Label
Count
Beferences
SVEPSW2
SVEBOF
SVEBOO
SVEBOl
SYEB09
SVLID
SYLIDW
SYLFS
SiTCH
SiTCHSIV
SIMTIBLE
SI8TBG
SISADDB
SISCODE
SISCOM
SISLINE
SISNIME
SISRIMES
000009
000005
000020
000002
000011
000002
000001
000002
000001
000002
000003
000004
000003
000005
000018
000001
000006
000022
SISBEF
SISTE8ID
SISUTl
TIBLIN
ilBS
TIIEIlt
'IIIEKSGL
TIIEBSAY
'IIPEBUFF
TAPECOUT
'IAPEDEV
TAPELIST
TlPE8lSK
TAPEOPEB
'IIPESIZE
TIPEl
'IIPE4
TAXEIDtB
'IIXEDEF
TIXEEXIT
'IAXEEXTS
TAXEFBEQ
lAXEICL
000004
000005
000024
000016
000017
000002
000001
000002
000001
000002
000003
000003
000003
000007
000002
000002
000002
000008
000001
000002
000001
000004
000002
D8SBlB
DMSBIB
DMSBIB
DMSBAB
DMSBIB
DMSLAD
DMSLID
DMSLFS
D8SlCM
D8SIRT
DMSDBG
DMSDBG
DMSINI
DMSFBE
DMSBIB
DMSDLK
DMSBTP
D8SlMS
D8SVSB
D8SINS
D8SINI
D8SLDB
D8SEDI
D8SEDI
D8SCIT
DKSCIT
DMSCIT
D8SSEB
DMSSEB
D8SSBS
D8SSBS
D8SSBS
D8SSBS
D8SSEB
D8SASN
D8SASN
D8SCIT
D8SSVT
D8SCIT
D8SCIT
D8SCIT
D8SCIT
D8SDOS
DMSDOS
D8SDOS
DMSITP
D8SDOS
DMSITP
D8SSET
DMSBOP
DMSDOS
DMSFET
D8SITP
D8SSTG
DMSINS
DMSBOP
DMSBTP
DMSDOS
D8SEDX
DMSEXC
D8SITP
D8SLOI
D8SINS
D8S0LD
D8SSCB
D8SEDX
DMSSET
D8SSEE
D8SSEB
D8SSEB
D8SSEB
D8SS0P
D8SS0P
D8SS0P
D8SS0P
DMSINS
DMSINT
DMSITS
DMSQBI
D8SSET
DMSYIB
n
3:
en
D8SSTG
D8SSVT
D8SSVT
~
PI
0CI)
I--'
I
rT
0
I
t:I
=-0
W
0,.
C
I--'
~
1-"
11
CI)
(')
("t-
0
11
1-"
CI)
en
CI)
n
11
0
00
oo
l:tI
CI)
HI
CI)
11
CI)
W
..A
..,J
t:I
(')
CI)
w
Label
count
Beferences
TlIEIOWS
TlIELI!IR
TlIEBTNl
TlIESTAT
TAIETAIE
TlIETSCF
TBENT
TBLCT
TBLLNGTB
TBLREF
TCODE
TEftPBYTE
TEftPST
TEMPTAB
TIC
UMBUF
TIMCCW
UMCHAR
TIMER
TIMINIT
TIN
TftPLOC
TOOBlG
TOUT
TPFERT
'lPFNS
TPFROl
'lPFSYO
TPFUSR
'lBKLSAVE
TRNCODE
TRUNCOL
TSOATCNL
TSOBLKS
TSOFLAGS
TSYM
TVERCOL 1
TVERCOL2
Ti ITCH
TITDIRC
TXTLlBS
'lYPE
TYPEAD
TYPFLAG
000002
000004
000002
000003
000002
000002
000024
000017
000005
000016
000001
000003
000008
000002
000053
000013
000005
000012
000015
000010
000007
000008
000003
000008
000003
000009
000002
000005
000011
000004
000001
000015
000018
000001
000019
000005
000002
000001
000087
000008
000004
000092
000001
000034
DftSCIT
DftSCIT
DftSCIT
DMSCIT
DftSCIT
DMSCIT
DftSlCft
DftSLDB
DftSSBD
DftSLDB
DftSFRE
DMSSVT
DftSLDB
DMSEDl
DMSINl
DMSINM
DMSITE
DMSINS
DftSIN S
DMSINS
DMSEDI
DMSLDR
DftSDIO
DMSEDI
DftSITS
DMSITS
DftSITS
DftSITS
DMSDBG
DeSTQQ
DMSFRE
DMSEDl
DMSClT
DeSSET
DMSClT
DeSDBG
De SEDI
Des EDl
DMSEDI
DMSGLB
DeSGLB
DeSLGT
DMSLIO
DeSDBG
(1
3:
til
CD
<
3:
"
w
....,j
0
til
'<
en
r+
CD
a
1:-1
0
....
I.Q
(1
~
='~
tt:1
H
0
tr
.....
CD
iii
t::j
('0
r+
('0
H
iii
....
='~
....0c+
='
(j)
....
~
~
('0
I:'"'
~
DMSSVT
t:T
CD
.....
I
c+
0
DftSBTB
DftSLIE
DftSSVT
DftSLIE
DftSFET
DftSOLD
DftSGND
DftSLDB
DftSLOA
DftSftDP
DMSftOD
DMSOLD
DftSSLN
I
3:
0
Q..
~
.....
DMSOLD
CD
(1
H
0
DftSOLD
en
rn
!:tl
('0
DftSQRY
DftSINT
DftSINT
DMSINT
DftSEDX
DftSLSE
DMSSET
DeSIOW
DMSIOW
DMSlOW
t-h
DMSlTE
DMSITE
DMSITE
DMSQRY
DMSSET
DM SSET
DMSSET
DMSSVN
DMSSVN
DMSSVN
DMSSVT
H
CD
='
(1
('0
DftSOLD
Desovs
i)ftSITP
DMSITS
DMSLDR
DftSEEX
DMSCRD
DMSSCR
DMSITE
DMSITI
DMSITS
DMSSEE
DMSSVN
DftSCRD
DeSITE
DMSITI
DMSITS
DMSSEE
DMSSVN
DeSEDX
DeSLDR
DMSLGT
Des LIE
DMSSCR
DeSLGT
DeSLIB
DMSLIO
DeSLIE
DMSCRY
tMSLOA
DMSOLD
DMSITP
DMSlTS
DMSLDR
DMSOVS
DMSLSB
('0
tt.I
CD
0
..,.ri"
0
::s
w
.
..,.
tj
t1
CD
0
ri"
0
..,.t1
CD
en
Label
Count
References
TYPFLG
TYPLIN
TYPLIST
UE
UFDBUSY
000004
000040
000007
000001
000030
UND
UNPACK
UPBIT
UPSI
UPTftID
UPTSWS
USARCODE
USAVEPTR
USAVESZ
USERCODE
USERKEY
UTILFLAG
VAR
VERCOL 1
VERCOL2
VERLEN
VMSIZE
000017
000010
000005
000004
000002
000002
000002
000023
000002
000004
000010
000017
000027
000006
000003
000006
000037
VSTRANGE
IiAIT
WAITLIST
iiAITLST
iAITRD
iAITSAVE
iORKFILE
iRBIT
iRCOUNT
iRDATA
WRITE
iRITEl
WRTKF
iTRDCNT
XAREA
XCOUNT
XGPRO
XGPRl
XGPR15
XPSi
000001
000028
000002
000003
000004
000006
000005
000008
000001
000022
000028
000007
000003
000002
000001
000001
000002
000001
000002
000013
DftSEDI
DftSLIO
DftSITE
DftSCIT
DftSABN
DftSITI
DftSROS
DftSLIO
DftSACft
DftSS-ET
DftSSET
DftSSET
DftSFRE
DftSITS
DftSITS
DftSFRE
DftSFRE
DftSSCR
DftSROS
DftSEDI
DMSEDI
DMSEDI
DftSAMS
DftSSET
DMSITI
DMSCIT
DMSDBG
DftSCRD
DftSDBG
DftSCIT
DftSOLD
DftSACC
DftSGIO
DftSINI
DftSINI
DftSINI
DftSDIO
DftSDBG
DftSEDI
DftSOVS
DftSOVS
DftSOVS
DftSOVS
DftSDEG
DftSACC
DftSITP
DftSSBS
DftSACF
DftSITS
DftSSEB
DftSACft
DftSRNft
DftSSOP
DftSAUD
DftSTPE
DftSSQS
DftSBTP
DftSBWR
DftSAUD
DftSDSK
DftSSBS
DMSSCR
DftSSEB
DftSSOP
DftSSQS
DftSSVT
DftSSCR
DftSBRD
DMSSVT
DftSEWR
DMSVIB
DftSDBG
DftSDOS
DftSFRE
DMSINI
DftSSVT
DftSCiR
DMSINS
DMSITI
DftSDEG
DMSIOi
DftSEiR
DMSDSK
DftSDIO
DftSDSK
DftSERS
DftSFNS
DftSITE
DftSBDI
DftSBDS
DftSINS
DftSLDR
DftSOVS
DftSSTG
DftSSET
DftSSET
DftSSBD
DftSEDX
DftSEDX
DftSEDX
DftSBOP
DMSSSK
DftSCiT
DMSTPE
n
3
Ul
t:-I
I»
t1'
CD
~
I
IT
0
I
3
DMSITI
0
s::lI
~
.....
CD
n
11
0
en
en
!:t1
CD
H'I
CD
11
CD
w
::s
\0
CD
....
0
W
tv
label
Count
References
o
<:
3:
"
W
...,J
o
00
en
1004
en
rt
CD
B
n
13
en
XRSAVE
XXXCiD
XYCNT
XYFIAG
YAREA
YDISK
YYDDD
ZONEl
ZONE2
000003
000043
000008
000003
000001
000002
000003
000011
000016
DftSDIO
DftSEDI
DftSEDI
DftSEDI
DMSEDI
Dl!SIBI
DKSIBS
Dl!SEDI
DftSEDI
~
~
tT
(I)
.....
I
rt
o
I
::1:
DftSEDX
DftSEDX
o
~
c:
.....
CD
n
t1
o
o
en
en
~
CD
I-+J
CD
~
....
o
~
t:S
~
I'tI
t1
o
tT
.....
CD
S
t='
CD
rt
CD
t1
....EI
::I
~
....ort
t:S
en
....c:
~
CD
!:O
t1
CD
::I
o
CD
Module
Name
Entry
Points
DMKACO
DMKACOB
Dl!KACODV
Dl!KACOFF
Dl!KACOPU
DMKACOQU
DMKACOTM
DMKBLD
DMKBLDEC
DMKBLDRL
Dl!KELDRT
DMKBLDVM
Attributes, Function
Pageable.
Provides
additional
accounting
function at logon time (for installation use).
Builds an account card tuffer for
a VDEVBLOK.
Creates account card buffer for a
VMBLOK.
Punches queued up accounting cards.
Queues up account card buffers for
output on a real device.
Creates a connect and usage time
message for a user.
Pageable.
Allocates storage for a virtual
ECBLOK and the two TRQBLOKS required for a virtual machine with
the BCMOD! option, and initializes
these blocks.
Releases real segment, page, and
swap tables to free storage.
Creates and initializes segment,
page, and swap tables as a function of
virtual storage size,
which is part of the process of
building a user's virtual machine.
Creates and partially initializes
a VMBLOK for a virtual machine,
identified by its terminal real
device block.
Module
Name
Entry
Points
DMKBOX
DMKBOXHR
DMKBSC
DMKESCER
DMKCCH
Dt!KCCBIS
DMKCCHNT
DMKCCBRT
DMKBOX
DMKBOXBX
tn
CD
o
c+
~.
o
t:I
W
t:!
~.
t1
CD
o
o
c+
t1
~.
CD
[J1
Pageable.
Provides the VM/370 or user logo
(header) for printed output.
Loge for initial screen display
and header separator for printer
spoel files.
DMKCCW
-----------,
Attributes, Function
Installation header reference.
Resident.
Bisync line error processing.
Examines the error conditien
resulting from a unit check or
channel error that occurred while
executing a CP generated bisync
line channel program. If the error is uncorrectable, DMKMSi is
called to notify the operator.
After return from DMKMSi, the original channel program is terminated and the fatal flag is set in
the IOELOK.
If the error is correctable, the channel program is
re-executed up to a maximum of
seven retries.
Resident.
Operates with the I/O interrupt
handler to schedule a device dependent error recovery procedure
when a channel data check, control
check, or interface control check
is detected.
Entry from DMKIOS when a channel
check occurs when storing a CSi
after a SIO.
Entry from DMKIOINT when a channel
check occurs on an I/O interrupt.
Entry from DMKIOE to allow error
messages to be printed.
Resident.
Invokes an internal
subroutine
(CNTRLSUB) to obtain control bytes
(seek
• _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _- - - J
___________________
_ _ _ _data)
_____
DMKCCiSB
In
II'tI
13
10
It::I
10
ltot
I~
I~
hz:
I~
Ittl
h<
II'tI
10
,.
,~
,~
It::I
,~
I ttl
I~
In
,~
10
I ttl
h<
r---
r
I Module
I Name
DMKCCW
(cant. )
Entry
Points
DMKCCiTC
DMKCCiTR
DMKCDB
DflKCDEDC
DflKCDBDI
DMKCDBDM
DflKCDBDU
DMKCDS
DMKCDSCP
DMKCDSTO
DMKCFC
DflKCFCMD
DMKCFCSL
DMKCFCBE
Attributes, Function
Searches previous (external) RCi
chains and resolves the address of
the RCi task if found.
Takes the list of virtual CCis associated with the user's SIO and
translates it into a real CCi list.
Pageable.
Processes DISPLAY, DCP, DUMP, and
DMCP commands.
Executes the DISPLAY co.mand to
display real storage locations.
Displays
virtual storage
locations, storage keys, general
registers, floating-point registers, PSi, CAi, and CSW at the
terminal.
Dumps the contents of the specified real storage locations en the
virtual printer spool file.
Dumps the contents of the specified virtual storage locations,
registers, PSi, and storage keys
on the virtual printer spool file.
---------------------------------------------,I
Module
lame
Entry
Points
DMKCFC
(cant. )
DflKCFCQU
DflKCFCRQ
DMKCFD
DftKCFDAD
DftKCFDLO
DMKCFG
DflKCFGSV
DMKCFft
Pageable.
Processes STORE and STCP co.mands.
stores
data into real storage
(STCP command) •
stores data into virtual storage
eSTeRE command}.
DMKCFftAT
Pageable.
Gets the address of the routine
that
processes the CP ccnscle
function that was requested.
Processes a CP console function.
Processes the SLEEP command.
Processes the BEGIN command.
DflKCFflEN
DftKCFftBK
Attributes, Function
Processes the QUERY command.
Presents an attention interruption
to the virtual machine to simulate
a real request key interruption.
Pageable.
Processes LOCATE and ADSTOP
co.mands.
stops virtual machine at specified
address (ADSTOP command) •
Displays address of real device
blocks, or VMBLOK and/or virtual
device blocks (LOCATE command).
Pageable.
Saves a system's virtual storage
space, including registers and PSi
as they currently exist, in Fage
form, on a DASD device. The name
of the system and the DASD location at which it is to be saved is
defined in tftKSVS.
Resident.
Processes the SLEEP, BEGIN, QUERY,
and REQUEST commands. Also processes DIAGNOSE code 8. Its scans
the co.mand line and goes to the
required module.
Posts an attention interrupt pending for the virtual machine.
Puts the terminal in console function (CP) mode (ATTN key pressed
twice). Scans the command line
and goes to the co.mand handling
routine.
Entered when DIAGNOSE code 8 is
executed. Scans the command line
and goes to the co.mand handling
routine.
I
..--
Module
Nallle
Entry
Points
DMKCFP
Df!KCFPII
Dl!KCFPIP
Df!KCFPRD
Dl!KCFPRR
DMKCFPRI
DMKCFS
Dl!KCFSET
Df!KCFT
DftKCFTRft
..--
Attributes, Function
Pageable.
Simulates the operator's console
for the virtual machine.
Entry from DftKLOG to process IPL
command (logon).
Entry from DMKCFft to process IPL
command.
Handles virtual device reset for
other CP routines.
Handles system resets for ether CP
routines. Resets the virtual machine.
Releases an IOBLOK when called by
DftKILD.
Pageable.
Processes the CP SET command.
Entry point for SET command processor.
I Module
I Bame
Entry
Points
DMKCKS
DftKCKSPL
DMKCKSIN
DMKCKSiM
DMKCNS
Pageable.
Processes user's terminal eptions.
Entry point for the TERftINAL command processor.
DMKCBSED
DMKCBSEN
DMKCKP
DftKCKPT
til
CD
n
....r+
o
I'
.w
....t::It1
CD
n
r+
o
....
CD
t1
en
Pageable.
Saves pertinent data when a check
point occurs.
Retrieves accounting data from the
VftBLOK, VD!VELOK, and unpunched
accounting cards.
It retrieves
accounting information fer dedicated devices, saves the system
log messages, and saves all control blocks for spool files. The
data is written on the SYSiARft cylinder of the IPL pack.
Df!KCKP is loaded and executed by
DMKDftP or initial program load.
DMKCBSIC
Df!KCNSIB
DftKCPB
Df!KCPBEX
Attributes, Function
Pageable.
Performs checkpoint processing.
Performs a checkpoint on any alterations in the spool file set up
to allow the recovery routine to
get them if warm start fails.
Initializes the check point cylinder after a successful warm start
from the standard recovery procedure or after a cold start.
Recovers previously check pointed
spool file information. This information includes all open print
or punch files in existence at the
tillle the system went down or was
shutdown. All open spool files
are put in user hold status.
Resident.
Real console terminal manager.
Edits the input line for the following characters: escape, line
end, line delete, and character
delete.
Enables or disables a low-speed
terllinal line.
Entered from DMKQCB to initialize
read
and
write CCWs for the
COB TASK built by DMKQCB.
Interruption
return
point and
handler for terminal I/C.
Pageable.
Simulates the operator's console
for the virtual lIachine.
Processes the EXTERBAL co •• and to
present an external interruption
to the virtual machine.
r------------- .---------------------------------------------,
Module
Name
I tIl
It'!:!
It'"i
Il:t!
II:IiI
lioz'J
It'!:!
11:0
It'!:!
12:
1(')
It'!:!
(')
r,j
3:
0
0.0
c:
n
.....
::I
0
....0rt
W
CD
I
rt
I
t'"i
~
tr
....
~
H
CD
CD
.....
(')
0
H
0
en
en
rt
....
H
(t)
en
0
l:t!
(t)
t-h
(t)
H
W
~
(t)
::I
0
(t)
w
~
n
Module
External References (Labels and Mod ules)
DMKCCi
ACORETEL
CLASURI
DftKFRET
F16
IOBFLAG
LOCK
RCiINVL
RDEVSADN
R6
SAVEiRK2
TYP2311
VDEVDED
VDEVTYPE
VMSIZE
APTHLK
CLASURO
DMKISl'lTR
F2
IOBLOK
PCIF
RCiIO
RO
R7
SAVEiRK9
TYP2314
VDEVDIAL
VDEVUC
XPAGNUft
BALRSAV!
CORFLAG
DMKPTRAN
F240
IOBftI SC
PSA
RCiISAM
Rl
R8
SILl
TYP2955
VDEVERAB
VDEV231B
XRIGHT16
BALR2
CORSHARE
DftKPTRFR
F3
IOBMISC2
RCiADDR
RCWPRT
Rl0
R9
SKIP
TYP3210
VD1!VFLAG
VDEV 231T
XRIGHT24
BALR3
CORSiPNT
DMKFTBUL
F4
IOBRELCU
RCWCCRT
RCiRCRT
R 11
SAVEAREA
SiP FLAG
TYP3217
VDEVIOER
VMBLOK
X2048BND
BRING
COR TABLE
DMKSYSRM
F4095
IOBSIZE
RCiCCi
HCiREL
R12
SAVE REGS
TEMPR10
TYP3330
VDEVPOSN
VMCLASSF
ZEROES
CC
CPSHRLK
DMKUHTRS
F4096
IOBSTAT
RCiCHT
RCiSHR
R13
SAVERl
TEl'1PR14
TYP3340
VDEVRDO
VftCLEVEL
CD
CPSTAT2
DftKVftAPS
F1
IOBiR1P
RCiCOMRD
RCiTASK
R14
SAVER 10
TEl'1PR15
TYP3350
VDEVREAL
VftDVSTRT
CLASDASD
Cl
PFS
F8
IOERBLOK
RCiCTL
RCiVCAi
R15
SAVER12
TEMPR2
TYP3410
VDEVRELR
VMISAM
CLASGHAF
DEFER
FTREXTSN
F9
IOERDATA
RCiFLAG
RCWVCRT
R2
SAVER2
TEMPR3
TYP3420
VDEVRSRL
VMOSTAT
CLASSPEC
DMKD1SSD
F1
IDA
IOEREXT
RCiGEI
RCi2311
R3
SAVER8
TYPURSUP
TYP3705
VDEVSAS
VMPSTAT
CL1STAPE
DMKDIASft
FlO
IOBCAi
IOERLER
RCWH!AD
RDEVBLOK
R4
SAVER9
TYP1442R
VDIVBLOK
VDEVSTAT
VftSEG
CLASTERM
DMKFREE
F15
IOBCYL
IOERSIZE
RCiHftR
RDEVFTR
R5
SAVEiRK 1
TYP2305
VDEVBRD
VDEVTYPC
VMSHR
BRING
DMKFRET
F2
R14
SAVEiRK4
VMNEiCRO
BUFFER
DMKPTRAN
F24
R15
SAVEiRK5
VMOSTAT
BUFNXT
DMKQCRiT
F3
R2
SAVEiRK6
Vl'1PSTAT
Cl
DMKSCNFD
F4
R3
SAVEiRK8
VMPSi
DEFER
DMKSYSRM
F4096
R4
VMBLeK
VMRSTAT
DMKCVTBD
DMKVATAE
F6
R5
VMECEXT
VMSEG
DMKCVTBB
DMKVSPR'I
RORET
R6
VMESTAT
VMSHR
DMKCVTDB
ECBLOK
PSA
R1
VftEXTCM
VftSI ZE
Dl'1KCVTFP
EXTCRO
RO
R8
VMFPRS
VMVCRO
DMKCVTHB
FFS
Rl
R9
VMGPRS
VMV310R
DftKDMPTR
Fl
Rl0
SAVEAREA
VIHNVPAG
XPAGBUM
DMKERMSG
F15
R11
SAVEiRK 1
VMINVSEG
XRIGHT 16
DMKFREE
F16
R13
SAVEiRK2
VMLOGOFF
ZEROES
Il'1KCDS
ACORETBL
CPEXR15
DMKPTRAN
EXTCCTRQ
PAGCORE
R5
SiPTRANS
YftINVSEG
ZEROES
BLANKS
CPEXR5
DftKPTRiQ
EXTCPTftR
PAGIBVAL
R6
TEMPR14
YMBEiCRO
BRING
CPEXR1
DMKQCBiT
EXTCRO
PSA
R7
TEMPR15
VftPSTAT
CORFLAG
CPEXSIZE
DftKSCHFD
EXTftODE
RUNUSER
R8
TRABftODE
VftPSi
CORPGPNT
DEFER
DMKSYSRM
F1
RO
SAVEAREA
TRQELOK
VMSI ZE
CORSHARE
DMKCVTBH
DftKTRCIT
F15
Rl
SAVER2
TRQBVAL
VMTIMER
CORSiPRT
DMKCVTDB
DftKTRCPB
F16
Rll
SAVEiRK 1
VftBLOK
VftTRBRIB
CORTABLE
DftKCVTHB
DftKVATAB
F2
R13
SAVEiRK2
VftECEXT
VftTRCTL
CPEXADD
Dl'1KERftSG
DMKVATBC
F4
R14
SAVEiRK3
VMESTAT
VftUSER
CPEXBLOK
Dl'1KFREE
DMKVATftD
F5
R15
SAVEiRK4
VMEXTCft
VftVCRO
CPEXFPBT
DftKPAGIO
DMKVftACF
F6
R2
SAVEWRK5
VMFPRS
VftV310R
CPEXRO
DMKPSACC.
DftKVftAPS
F8
R3
SAVEiRK8
YftGPRS
iAIT
CPEXR14
DMKPSASC
ECBLOK
NORET
R4
SiPFLAG
VftIBVPAG
XPAGHUM
IftKCFC
ATTN
Df!KCFMWU
Df!KCPVLK
DMKCSOST
DMKDEFIN
DMKQCNiT
FFS
RO
SAVERl
VMCLASSB
VMRSTAT
BLANKS
DMKCFSET
DftKCPSRY
DftKCSOVL
Df!KDIACP
DftKSCHRT
F1
Rl
SAVER2
VMCLASse
VMSLEEP
DftKCDBDC
DMKCFTRf!
Df!KCPSSH
DftKCSPCL
Df!KDIAL
DftKSCHST
F2
Rll
SAVEiRK2
VMCLASSD
Vf!TERM
DftKCDBDI
Df!KCPBEX
DftKCPVUL
DMKCSPFR
DftKERftSG
DftKSCHFD
F3
R13
SAVEiRK4
VMCLASSE
VMTRBRIB
DMKCDBDft
Df!KCPBNR
DMKCQGEN
D!!IKCSPHL
Df!KFREE
DMKTHIEN
F4
R15
SYSTEM
Vf!CLASSF
VMTRCTL
DMKCDBDU
Df!!END
VMCLASSE
VMMLEVEL
VMVIRCF
CLASGRAF
DMKSCBRT
RO
R8
VCHBLOK
VDEVSTAT
VMCLASSF
CLASTERM
DMKSCNFD
Rl
R9
VCBCUINT
VMELOK
VMCLASSG
VMOSTAT
WAIT
CPEIADD
DMKSTKCP
Rll
SAVEAREA
VCHCUTBL
VMCF
VMCLASSB
VMPEND
CPEIBLOK
DMKVIOMK
R12
SAVER 11
VCUADD
VMCFREAD
VMCPiAIT
VMPRIDSP
CPEIREGS
EDIT
R13
SAVER2
VCUBLOK
V-MCFRUN
VMCUSTRT
VMPSW
AVMREAL
DMKBLDRT
DMKQCNSY
ECBLOK
IOBIOER
IOERSIZE
RO
R7
VCHELOK
VCUACTV
VDEVBLOK
VDEVFLAG
VMBLeK
VMIOPND
VMPXINT
XINTBLOK
CBBWAIT CBIELOK CBICNCT CBIFLAG CLASGRAF CLASSPEC CLASTERM CLASURI CLASURO CUE
DELPAGES DMKBLDRL
DMKDIADR DMKDSPCB DMKFREE DMKFRET DMKIOSHA DMKIOSQR DMKLOCKD DMKLOCKQ DMKFERT DMKPGSPO DMKPGSPP DMKPTRPW
DMKSCHRT DMKSCNVU DMKSTKCP DMKSTKIO DMKTRCPE DMKUNTFR DMKVATBC DMKVCARD DMKVDREL DMKVIOMK DMKVSPCO DMKVSPCR
EXTCCTRQ EITCPTMR EITCRO
EITCR14 EITCR 15 EITCR2
EITCR4
FFS
IOBCAi
IOBFLAG 10BBIO
10EHVC
IOBIRA
IOBLINK 10BLOK
IOBMISC IOBlUSC2 lOB RES
10BSIZE 10BSPEC IOBTIO
IOBUSER 10ERBLOK IOEREXT
KEEPSEGS NEWPAGES NEWSEGS OLDVMSEG PGBLOK
PGBSIZE PGPNT
PSA
RDEVAIOB RDEVATT RDFVELOK RDEVIOER
R14
Rl
R10
Rll
R12
R13
R15
R2
R3
R4
R5
R6
R9
SAVEAREA SAVEWRK6 SAVEiRK8 TRQBFPNT TRQBLOK TBQBVAL TYPCTCA TYP3210 TYP3215 VCHADD
R8
VCBBUSY VCBCEDEV VCHCEPND VCHCUINT VCHCUTBL VCHDED
VCHSTAT VCONCTL VCONRBSZ VCONRBUF VCONWESZ VCONWBUF
VCUAED
VCUHLOK VCUBUSY VCUCEPND VCUCHBSY VCUCUEPN VCUDVINT VCUDVTBL VCUINTS VCUSTAT VDEVADD VDEVAUCR
VDEVBUSY VDEVCCW 1 VDEVCFLG VDEVCBAN VDEVCHES VDEVCON VDEVCSW VDEVCUE VDEVDED VDEVDIAL VDRVBNAB VDEVFEED
VDEVINTS VDEVIOE VDEVIOER VDEVNRDY VDEVPEND VDEVREAL VDEVSFLG VDEVSPL VDEVSTAT VDEVTYPC VDEVTYPE VDEVUC
VMCHSTRT VMCHTEL VMCUSTRT VMDSTAT VMDVSTRT VMECEIT VMESTAT VflEXWAIT V'HDLE
VMINVPAG VMIOACTV VM IOINT
V!HOWAIT VMKILL
VMLOGOFF VMMICSVC VMNOTRAN VMOSTAT VMPAGEX VMPEND
VMPGPND VMPGPNT VMPStAT V~PSW
VMRSTAT VMSEG
VM no
VMTRBRIN VMTRCTL VMUSER
VMSIZE
VMSTOR
V~VCRO
VMVTERM VMV370R WAIT
XINTEXT XINTSI ZE XINTSORT XRIGBT24 ZEROES
DMKCFP
til
CD
n
ri-
~.
O
='
w
.
'='
~.
t1
CD
n
t+
0
t1
~.
CD
Ul
W
~
w
V~SYSOP
V~MSTMP
VMVTERM
n
I"tl
3:
0
~
~
I-'
CD
I
ri-
0
I
~
I»
tT
CD
I-'
n
t1
0
Ul
Ul
!::tI
CD
HI
CD
t1
CD
='
n
CD
w
.c::
.c::
Label
External Beferences (Labels and Mod ules)
DPIKCFS
lCOBETEL
CPMICON
DKKFBEE
DPIKSCHBT
EDIT
IBMBIT2
8ICSIZE
BDEVSTAT
R3
SAVEWBR7
VMBLOK
VMISAM
VMPISVC
VMSTMPI
ASYSLC
CPSTAT2
DMK1BET
DMKSCH80
EITCCTBQ
IB8BLOK
ftICVPSi
BDEVSYS
R4
SIVEiBK8
VMCFBUN
VMftACCON
VPI8TEIT
VMSTOR
AVMBEAL
DMKBLDEC
DlilKIOEIB
DPIKSCIAU
EITCPTBQ
IBPIBYT 1
MICWOBK
BDEVTYPC
R5
SYSLOCS
VMCLISSA
VMMADDB
VPI8360
VMTLEVEL
BLAIKS
DBKCFPBB
DlIIKMCHAR
DPIKSCIFD
EITSIZE
IBMBYT2
1II0DFLAGl
BD!VTYPE
R6
TEMPSAVE
V8CLASSB
VMMCODE
VPINOTBAN
VMTON
BUFCNT
DPIKCVTBH
DPIKPICH!S
DPIKSCNBD
F1
IBlH'LG
MOD1BETY
BDEVUSEB
B7
TBQEIBA
VPICLASSC
VMMCB6
VPIOSTAT
V8TRQBLK
BUFFEB
DPIKCVTDB
DMKPTBBC
DPIKSCNBU
BUFNIT
DPIKCVTDT
DlIIKPTBBL
DlilKSYSDT
12
F3
IBPILftT
IBPIOB
NOAUTO
NOBET
BO
Bl
B8
B9
TBQBLOK TRQBSIZE
VPICLASSD VMCLASSE
VPIMFE
VMIUCBO
VMPAGEI VMPFUNC
VMUPRIOR VMUSER
CLASTlPE
DKKCVTHB
DKKPTRRU
DKKSYSDi
F4
IBPIBLADD
PSA
Rl0
SAVEABEA
TBQBUSER
VPICLASSF
VMMICSVC
VMPSTAT
VMVCRO
CLASUBO
DKKDMPAU
DMKQCNBD
DPIKSYSLG
F5
IBKSIZE
BDEVBLOK
R 11
SAVEWRKl
TYPPBT
VPICLASSG
VMIHPISG
nlPSi
VMV370R
COB FLAG
DMKDMPDV
DKKQCNWT
DPIKSYSLi
F7
KCHABEA
BDEVDED
R13
SAVEiBK2
UCASE
VPICLEVEL
VMMLEVEL
VMQLEVEL
VMWNGON
COBBSV
DKKDPIPSi
DMKSCHAP
DlilKSYSBV
F8
MICBLOK
BDEVDISA
R14
SAVEiBK3
VMADSTOP
VKECEIT
VMMLINED
VMBON
I40FPS
COBTABLE
DKKDSPNP
DrIKSCHAU
DMKSYSTK
IBPIAND
KICCBlG
BDEVFLAG
R15
SAVEWBK4
VKAEI
VMESTAT
VKPILVL2
VMBPAGl
ZEROES
CPlUCAVL
DMKEBKSG
DKKSCHPG
ECBLOK
IBMBIT 1
KICBSEG
BDEVIRM
R2
SAVEWRK5
VPIAEIP
VM HIPRI
VMPISGON
VMSEG
ASYSLC
Pl
RDEVAPLP
Rl0
SAVEiBKl
VMTLDEL
CLASGBAF
F2
BDEVATOF
Bl1
SYSLOCS
VMTLEBD
CLASSPEC
P255
BDEVBLOK
R13
TYPBSC
VPITBMID
CLASTEBM
F4095
RDEV1LAG
R14
TYPTTY
VMVTERPI
DMKCVTBH
NICAPL
BDEVLLEN
R15
TYP3277
I40FFS
DKKCVTDB
NICATOP
BDEVNICL
R2
VMBLOK
ZEBOES
DKKERKSG
NICBLOK
RDEVPSUP
R3
VKDVSTRT
DMKSCNFD
NICFLAG
RDEVTFLG
R4
VMKCPENV
DftKSCNVD
NICLLEN
RDEVTKCD
RS
VMKLEVEL
DKKSYSCD
NICPSUP
RDEVTYPC
R6
VMPISTKP
DKKSYSES
NICSIZE
RDEVTYPE
R7
VMTCDEL
DMKSYSLD
NICTKCD
RO
R8
VKTERM
DMRSYSLE
PSA
Rl
SAVEAREA
VMTESCP
ACNTBLOK
ARSPPB
CLASUBI
DMKBSPCV
DPIRSYSCi
NICDISB
PSA
BDEVAIOB
BDEVLICP
RECftlI
B15
SFBFIBST
SHQBSIZE
TYP3330
VDEVDED
VPICUSTBT
ACBTCCi
ASYSLC
CLlSUBO
D8KRSPDL
DMKSYSBM
NICENlB
BCHAtD
BDEVAUTO
BDEVPIAI
RECPNT
B2
SFBFLAG
SILl
TYP3340
VDEVEITB
VPIDIST
ACNTDlTl
ASYSVM
CPCBEGO
DMKBSPHQ
DPIKSYSTP
NICFLlG
BCHBLOK
BDEVBLOK
BDEVMDL
RECSIZE
B3
SPBFLAG2
SKIP
TYP33S0
VDEVFLAG
VPIDVSTBT
lCNTNEIT
ATTN
CPID
DMKBSPID
DftKSYSiK
NICLGBP
BCHCUTBL
BDEVCLAS
BDlVNCP
RECUSED
R4
SPBLAST
STABTIME
TYP370S
VDEVSFLG
VftLOGON
ALARM
BUSY
CSi
DMKBSPPB
DKKTMRPT
NICLINE
BCUAtD
BDEVCUA
BtEVNICL
RSPLCTL
B5
SPBLOK
SYSLOCS
UC
VDEVSPL
VMPNT
ABIOCC
CAW
CUE
DMKRSPPU
FTB3SPIB
IICSIZE
BCUBLOK
RDEVDED
BDEVBECS
RSPSPBLK
B6
SFBORIG
TYPBSC
USEBCABD
VDEVSTAT
VPIBSTAT
ABIOCE
CC
CO
DMKBSPBt
IITPB
NICSTAT
BCUCHA
BDEVDISA
BDEVSEP
RO
R7
SFBPNT
TYPPRT
VCHBLOK
VDEVTDSK
VPIUSEB
ABIOCT
CE
C2
DMKSAV
IITTIO
NICTEBPI
BCUDVTBL
BDEVDISB
RDEVSPL
Bl
R8
SPBPUBGE
TYPPUN
VCHCUTBL
VDEVTYPC
VSPLCTL
ABIOCU
CLASDlSD
C3
DKKSAVBS
IONPSW
NICTYPE
BCUPBIPIE
RDEVDBAN
BDEVSTAT
Bl0
B9
SFBBECER
TYP230S
VCUBLOK
VDEVTYPE
VSPSFBLK
ABIODV
CLASGBAF
DE
DKKSYSCK
IOOPSW
OWNDLIST
BCUSUB
BDEVENAB
BDEVTYPC
B 11
SFBCLAS
SPBBECS
TYP2314
VCUDVTBL
VDEVIFEB
VSPIBLOK
ARIOPR
CLASSPEC
DEVCABD
DMKSYSDT
IPLPSi
OiNDBDEV
RCUTYPE
BDEVPLAG
BDEVTYPE
B12
SFBCOPY
SFBSIZE
TYP3210
VDEVBLOK
VMBLOK
VSPIIUSB
ARIOPU
CLASTAPE
DMKOPBWT
DMKSYSLG
NICBLOK
PBNPSi
BDEVACNT
BDEVFTB
RECBLOR
R13
SFBDATE
SFBSTABT
TYP3277
VDEVCLAS
VMCHSTBT
ABIOBD
CLASTERK
DMKBSPAC
DPIKSYSOC
NICDISA
PBOPSW
RDEVADD
RDEVLCEP
RECCYL
R14
SFBDIST
SF BUSER
TYP3284
VDEVCOPY
VKCBTBL
:.:
:3
CCC
IFCC
RTCODES
SAVEWRK9
CCBCMDV
IGBLAME
RO
TERMSYS
CCHUSV
CCHDAV
CCEDI
CCHLOG80 CCHRCV
CCHREC
IGTERMSQ IGVALIDB IBTERCCB IOELPNTR IOERBLOI'( PSA
R15
R2
R13
B14
Rl
R12
TIOCCH
ALARM
DMKFRET
Rll
SAVEAREA
BLANKS
DMKPTRAN
R12
SAVBRO
BRING
DMKQCNWT
R13
SAVBR1
BUFCNT
DMKSYSRM
R14
SA VBR2
BUFFER
ERRMSG
R1S
SAVER3
BUFINLTH
F2
R2
SYSTEM
BUFSIZE
F255
R3
VMBLOK
DEFER
DFRE'!'
DMKCVTBD DMKEMAOO DMKBMBOO DMKFREE
Rl
R10
RO
BaRET
OPERATOR PSA
R8
R4
R5
R6
R7
R9
XRIGBT 16
ATTN
RO
R7
BUSY
Rl
R8
CAi
R10
R9
CC
Rll
SILl
CD
R12
SKIP
CE
B13
Sl!
CSW
R14
UC
CUE
R15
UE
ACORBTBL
FREERO
R13
TRACCURR
AFREE
FREERl
R14
TRACEND
ASYSVM
FREER14
R1S
TRACFLGl
AVl!RBAL
FREER1S
R2
TRACSTRT
BALRSAVE
FREESAVE
R3
TRAC67
CORPGPNT
Fl
R4
IPAGNUl!
DMKGIO
BRING
DMKUNTRN
IOBMISC2
R12
VDEVBLOK
VMACTDEV
VMRSTA'I
CLASDASD
IL
IOBSIZE
R13
VDEVBUSY
VMBLeK
CLASTAPE
IOBCAi
IOESTAT
R15
VDEVCBAN
VMCOME
CSi
IOBCC3
IOERBLOK
R2
VDEVCSW
VMDVSTRT
DEFER
IOBCSi
IOBRCSW
R4
VDEVDBD
VMESTAT
DMKGRF
ALARl!
CDC
CONPARl!
CPEXSIZE
DMKCVTBB
DMKRr-OCN
Fl
IOBEBP
IOBSTAT
LOGBCLD
RI;>EVBLOK
RDEVIOER
Rl
R8
TYP3066
VMCF
VMQSTAT
ARIODV
CE
CONPJI1T
CPID
DMKDSPCB
DMKSCHRT
F255
IOBFATAL
IOBUNSL
NOBET
RDEVCON
RDBVLOG
R10
R9
TYP3277
VMCFWAIT
VMRSTAT
ASYSVl!
CBC
CONRESP
DE
DMKFREE
DMKSCHST
F256
IOBFLAG
lOB USER
NOTIME
RDEVCORD
RDBVMORE
R11
SAVEAREA
TYP3284
VMDVSTRT
VMSYSOP
ATTN
CLASGRAF
CONRETN
DEFER
DMKFRET
DMKSCNRD
F3
IOBIOBR
IOERBLOK
PRGC
RDEVCPNA
RDEVRBAD
R12
SAVERO
UC
VMGENIO
VMTLEND
BLANKS
CONACTV
CONRSV3
Dl!KBLDVPI
DMKIOERR
DMKSCNRU
F4
IOBIRA
IOERCSi
PRIORITY
RDEVCTL
RtEVRUN
R13
SAVER2
UCASE
VMLOGOFF
VMTTIME
DMKEIG
<
3:
........
w
..
-..J
0
tMKERM
til
'<
Ul
c+
CD
Dl!KFMT
EI
~
COMPFES
RTCODEO
R3
COMPSEL
RTCCDEl
R4
COMPSYS
BTCODB2
R9
IOOPSW
R4
CSW
FFS
RTCODE3 RTCODE4
SAVEAREA SAVEWRKl
PROPSW
R5
PSA
R6
DB
R2
ICNPSW
R3
Dl!KFRE
COR TABLE C2
F4096
PSA
RS
R6
XTNDLOCK
Dl!KCPE
RO
R7
DPlKDSPNP Dl!KPTRFR DMKPTRFT DMKSYSRM
R 11
Rl0
R12
Rl
R8
SAVESIZE TEMPSAVE
B9
PI
~
P.
td
Ii
DMKCCWTR
IOBFATAL
IOERDATA
RS
VDEVFLAG
VMBXTCM
DMKDSPCH
IOBFLAG
IOEREXT
R6
VDBVIOB
VMEXWAIT
DMKFREE
IOBHVC
IOERSIZE
R7
VDEVIOER
VMGPRS
DMKFRET
IOBIOER
PSA
R8
VDEVPEND
VMIOCNT
DMKIOSQV
IOBIRA
RO
R9
VDBVPOST
VMIOiAIT
DMKPTRAN
IOBLIIK
Rl
SAVEAEBA
VDEVSTAT
VMLOPRI
DMKSCNVU
IOBLOK
R10
SAVER2
VDEVTYPC
VMPSW
DMKUNTFR
IOBMISC
Rll
UE
VDEVUC
VMQLEVEL
0
EI
I::j
CD
BRING
CONADDR
CONSTAT
DPIKBOXBX
DMKIOEST
DMKSTKCP
F5
IOBLINK
IOEBDAT!
PRTC
RDEVCUA
RDEVSTAT
R14
SILl
UE
VMLOGON
VMVTERM
BUFCNT
CONCCil
CONSYNC
DPIKCFMAT
DMKIOSQR
DMKSYSNM
F8
IOBLOK
IOEREIT
PSA
RDEVDED
RDEVTFLG
R15
SYSTEM
VCONCTL
VMMCPENV
XINTBLOK
BUFFER
CONCCi2
CONTASK
DMKCFMBK
DMKMSiR
DMKTBLGR
IFCC
IOBMISC
IOERFLG3
RCUBLOK
RDEVDISA
RDEVTMCD
R2
TEMPSAVE
VCONRBSZ
VMMLEVEL
XINTCODE
BUFINLTH
CCNCCi4
CONTSIZE
DMKCFMEN
DMKPTRAN
DMKTBLUP
INHIBIT
IOBRADD
IOERNUM
RCUDVTBL
RDEVDISB
RDEVTRQ
R3
TRQBIRA
VCONRBUF
VMMLINED
XINTNEXT
BUFSIZE
CONCNT
CONTSKSZ
DMKCNSED
DMKQCNCL
Dl!KTBMZI
INTREQ
IOBRCNT
IOEROVFL
RDEVACTV
RDEVENAB
RDEVTYPC
R4
TRQBLOK
VCORRCNT
VMOSTAT
XINTSIZE
CC
CONDATA
CPEXADD
DMKCPIEM
DMKQCNET
Dl!KTEMZO
IOBCAi
lOBS ENS
IOERREAD
RDBVAIOE
RDBVFLAG
RDEVTYPE
R5
TRQBSIZE
VDEVBLOK
VMPA2APL
XINTSORT
CCC
CONESCP
CPEXBLOK
DMKCVTBD
DMKQCNTO
EDIT
IOBCOPY
IOBSIZE
IOERSIZE
RDEVAIRA
RD!VHIO
RDEVUSER
R6
TRQBUSER
VDIVCON
VI1PFUNC
XTNDLOCK
CD
CONOUTPT
CPEIRO
DMKCVTDB
DIHiQCNiT
Fa
IOBCSW
IOBSPEC
LOGDROP
RDEVAPLP
RDEVHOLD
RO
R7
TRQBVAL
VMBLOK
VMPXINT
ZEROES
c+
Ii
....
EI
~
PI
....
c+
0
~
G:l
....p.'='
(!)
c+
0
I
t-'
PI
C'
(!)
I--'
()
Ii
0
~
CD
HI
(!)
Ii
CD
~
C'
I--'
CD
(!)
'='
I--'
CD
I
Ul
Ul
0
....n
\Q
0
p.
n
CD
en
CD
0
r+
1-'0
t:J
W
c;,
1-'11
CD
0
r+
0
11
1-'(1)
en
W
V1
w
f'!odule
External References (Labels and Modules)
I:MKHVC
BLANKS
DMKCFGCL
DMKPTRAN
rOBCAW
RCWADDR
R12
TEMFR8
VMEXTCM
VMPSW
BRING
DMKCFMBK
DMKSCNVU
IOBCSW
RCWCCW
R13
TYPBSC
VMEXWAIT
VMQSTAT
CCC
DMKCFMEN
DMKTMRPT
rOBLOK
RCWCTL
R14
TYP3277
YMGPRS
VMRSTAT
CDC
DMKCVTDT
DMKUNTFR
rOBRADD
RCWPNT
R15
UC
VMINST
VMSLEEP
CE
DMKDGDDK
DMKVIOEX
IOBSIZE
RCWTASK
R2
UE
VlUCWAIT
VMSTOR
CHC
DMKDSPCH
Fl
NICBLOK
RDEVBLOK
B3
VDEVBLOK
VMMCODE
VMTERM
CLASGRAF
DMKFREE
F16
NICGRAF
RDEVNICL
R4
VDEVIOB
VMMLEVEL
VMTRl'IID
CLASTERM
DMKFRET
F256
NICSIZE
RDEVTYPC
RS
VMBLOK
VMMTEXT
VMTTIME
CFUID
DMKGIOEX
F4
NICTYPE
RDEVTYPE
R6
VMCF
VMNOTRAN
VMVIRCF
DE
DMKHVDAL
F4095
PCI
RO
R7
VMCFWAIT
Vl'IOSTAT
VMWSCHG
DEFER
DMKPGSSS
F60
PRGC
Iil
R8
VMCOMND
VMPA2APL
XPAGNUM
DMKCCWTC
DMKPRGSM
IFCC
PRTC
Rl0
R9
VMDVSTRT
VMPRIDSP
DMKCCWTR
DMKPSASP
IL
PSA
R11
TEMPR6
VMESTAT
VMPSTAT
DMKHVD
ACCTACNO
CLASSPEC
DMKDRDSY
DMKUDRDS
IPUADDIi
RDEVTYPC
R6
TYP3340
VDEVSTAT
VMESTAT
XRIGHT24
ACCTBLOK
CLASTERM
DMKFREE
DMKUDRFU
NICBLOK
RDEVTYPE
R7
TYP3350
VDEVTYPC
VMEXTCM
X2048BND
ACCTDIST
CLASURI
DMKFRET
DMKUDRRD
BICGRAF
RO
R8
UDBFBLOK
VDEVTYPE
VMGPRS
ACCTLENG
CLASURO
DMKIOEFM
DMKUDRRV
BICLLEN
Rl
R9
UDBFSIZE
VMACCOUN
VMINST
ACCTUSER
CPUMCELL
DMKPSASP
FFS
NICSIZE
Rl0
SAVEAREA
UDBFVADD
VMACCUNT
VMPA2APL
ACNTBLOK
CPUVERSN
DMKPTRAN
FTR35ME
NICTYPE
Rll
SAVERO
UDIRBLOK
VMELOK
VMPSTAT
ACNTCODE
DEFER
DMKRPAGT
F2S6
PSA
R13
SYSIPLDV
UDIRDISP
VMCLASSA
VMPSW
ACNTDATA
DMKACOQU
DMKSCNRU
F3
RDEVBLOK
R14
TYPBSC
UDIRUSER
YMCLASSB
VMQSTAT
ACNTNUM
DMKCPEID
DMKSCNVD
F4
RDEVCODE
R15
TYP230S
UMACACCT
VMCLASSC
VMTERM
ACNTSIZE
DMKCPVAA
Dl'IKSCNVU
F409S
RDEVFTR
R2
TYP2319
UMACBLOK
VMCLASSE
VMTRMID
ACNTUSER
DMKCVTDB
DMKSNCP
F4096
RDEVLLEN
R3
TYP3210
VDEVBLOK
VMCLASSF
VMUSER
ERING
DMKDRDER
I:MKSYSER
F60
RDEYMDL
R4
TYP3277
VDEVDED
VMCLEVEL
VMVTERM
CLASGRAF
Df'!KDRDMP
DMKSYSRM
F8
RDEVNICL
RS
TYP3330
VDEVREAL
VMDVSTRT
XPAGNUM
DMKIOC
CLASDASD CLASTERM OERDEVSB OBRDEVTN OERRECN OBRSHOBR OBRSWSN
RDEVCUA RDEVMDL RDEVSADN RDEVTMCD RDEVTYPC RDEVTYPE RO
R9
SAVEAREA TYP2305 TYP2311 TYP3330 ZEROES
PSA
R12
RCUBLOK
R13
RCUTYPE
R4
RCU2701
R5
RCU2?02
R6
RDEVBLOK
B8
DMKIOE
CCC
CPEXBEGS
DMKICFST
ERRIOER
F7
IOERELOK
IRMBLOK
OBRCSiN
OBRSWSN
RDEVMDI
R2
SDRCTRS
TYP3330
XOBRT3
COBCCW3
DMKFREE
ERRBLOK
ERRVOLID
IOBIOER
IOERPNT
IRMOR
OBRLSKN
PSA
Rl0
R9
TNSREC
VMBLOK
CCNDATA
DMKFRET
ERRCCNT
FTREXTSN
IOBLOK
IOERSIZE
IRMRLADD
OBRPGMN
RDEVBLOK
R 11
SAVEAREA
TNSSNSl
VMCLASSF
CONDCNT
DMKIOFCl
ERRCCW
Fl
IOBRADD
IOERVSER
IRMSIZE
OBRRECN
RDEVCTRS
R12
SAVEREGS
TNSSWS3
VMCLEVEL
CPEXADD
DMKIOFIN
ERRCORR
FlO
IOBSTAT
IRMAND
NORET
OERSDRCT
RDEVFTR
R13
SAVERl
TNSVOLID
VMUSER
CPEXBLOK
DMKIOFM 1
ERRHEADR
F2S5
IOBUSER
IRMBITl
OBRCORL
OBRSENSN
RDEVIOER
R14
SDRBLOK
TYP2305
XOERFLAG
CPEXFPNT
DMKIOFOB
ERRIOB
F'4
IOERADR
IRMBIT2
OERCPIDN
OBRSNSCT
RDEVIBM
R15
SDRBSIZE
TYP3211
XOBRT 1
CDC
CPEXSIZE
DMKIOFVR
ERR KEY
F8
IOERCEMD
IRMBYTl
OBRCUAIN
OBRTAPSN
RDEVSER
R3
SDRFLAGS
TYP3340
XOBR010
CLASDASI:
CPUID
DMKIOGFl
ERRl'IIOB
IFCC
IOERCSW
IRMBYT2
OBRCU APR
OBRURSNS
RDEVSTAT
R4
SDRLNGTB
TYP33S0
XOBR1S0
CLASGRAF
DMKCCHRT
DMKIOGF2
ERRMIOER
IOBCP
IOERDATA
IRMFLG
OBRDDCNT
OBRVOLN
RDEVTYPC
R5
SDRSERT
TYP3410
XOBR180
CLASSPEC
DMKCFMBK
DMKQCNWT
ERRPARM
IOBFATAL
IOEREXT
IRMLMT
OBRFCCWN
OBR3211S
RDEVTYPE
R6
TNSCPIDN
TYP3420
XOBR512
CLASTAPE
DMKCFPRR
DMKSTKCP
ERRSDR
IOBFLAG
IOERFLG2
IRMLMTCT
OBRHAN
OBR33SNS
RO
Ii?
TNSDEVAD
TYP3S0S
ZEROES
CLASTERM
DMKDSPCE
DMKSYSTZ
ERRSIZE
IOBHVC
IOERLEN
IRMMAXCT
OBRKEYN
OER3420S
Rl
R8
TNSKEYN
UC
n
t'Ij
3
0
~
c=
~
CD
I
r+
0
I
t"'I
I»
tr'
CD
~
n
11
0
en
en
~
CD
I-h
CD
11
CD
::s
0
(1)
w
(J1
~odule
External References (Labels and
DMKIOF
BRING
CDC
CPEXSIZE CPOID
~od ules)
n
ItI
.c:
3:
c:;
::I
"'w
...,J
0
til
'<
til
rt'
(1)
a
~
0
I.Q
.....
t~KIOG
I:'
j;lI
I'd
ti
0
b"
I-'
(1)
a
tj
(1)
rT
(t)
ti
a
.....
I:'
~
rt'
.....
0
I:'
Cl
c
.....
j;lI
(1)
CLASTAPE CLASTERM CLASURI
DMKFREE DMKFRET DMKIOCVT
D~KIOERP DMKIOERQ DMKIOESQ
ERRCCi
ERRCONT ERRCORR
F15
F255
F4
IOERPNT IOERREAD IOERVSER
OBRIORTY OBRKEYN OBRLSKN
OBR33SNS PSA
RCUBLOK
RDEVTYPC RDEVTYPE RECCCPD
R13
R14
R15
SDRCTR S SDRCUA
SDRFLAGS
TNSCPIDN TNSDEVAD TNSKEYN
TYP2501 TYP2520R TYP2540R
TYP3505 V~BLOK
VMUSER
CLASURO
DMKICECQ
DMKIOEVQ
ERRIOB
F7
LCCK
OBRPGMN
RCUTYPE
BECFLAGl
R2
SDRFLCT
TNSREC
TYP2700
XOBRFLAG
CPEXBLOK
DMKIOEFS
DMKPGTVG
EBBICER
IOBFATAL
OERCCRL
OBRRECN
RCu2701
RECNXT
R3
SDRLNGTH
TNSSNS 1
TYP2741
XOBRT 1
CPEXFPNT CPEXREGS
r:~KIOEIQ DMKIOEMP
DMKPG'IVR DMKP'IRAN
EBRKEY
ERRMIOB
IOERADR IOERBLOK
CBRCPIDN OBRCSiN
OBRSDRCT OBRSDRSH
RCU2702 RDEVELOK
RECPAGFL
RECPAG
R4
R5
SDRMAX
SDROVFiK
TNSSiS3 TNSVOLID
TYP3066 TYP3210
XOBRT3
XOBR010
CPEXR6
DMKIOEMQ
DlIKPTRUL
EBRMIOER
IOERCSi
OBBCUAIN
OBRSHOBR
RDEVCTRS
RECPAGIU
R6
SDRPRMCT
TYPTTY
TYP 3211
XOER150
0
j;lI
d
I-'
(1)
I
rT
0
I
t-'
~
b"
(1)
I-'
n
11
0
en
en
l:O
(1)
C'l
~
CL!SD!St CLASGR!F CLASSPEC
CPUVERSN DEFER
DMKERMSG
D~KICElIS DMKICE~X DMKIOENI tMKIOENQ D~KICEOP
D~KRPAGT DMKRPAPT DMKST~CP EBRBLOK
ERRCCNT
ERRP!RM ERRSDR
ERRVOLID FFS
FTREXTSN
IOERDAT! IOEREXT IOEBFLG3 IOERLEN IOEROVFL
OBRCUAPR OBRDDCNT OBRDEVTN OBRFCCiN OBRHAN
OBRSNSCT OBRSSDRl OERSiSN OBRT EMP OERVOLN
RDEVCUA RDEVFTR RDEVMDL RDEVSADN RDEVTMCD
BO
R1
Rl0
Rll
R12
R7
R8
R9
SAVEAREA SDRELCK
SDRRDEV SDRSHRT SDRSIZE SDRSIZEl SYSTEM
TYP1050 TYP1403 TYP1443 TYP2305 TYP2311
TYP3330 TYP3340 TYP 3350 TYP3410 TYP3420
IOBR180 XOBR512 ZEROES
DMKIOS
ARIOCH
DMKCCH60
DMKPGTVG
MCDAMLEN
NOMODEL
RECPAGFL
R3
TYP2305
ARIOCT
DMKEIG80
DMKPGTVR
MCHAREA
PSA
RECPAGFM
B4
TYP 3330
ADSPCH
CLAS'IAPE
CUE
DMKGRFIN
FTRRPS
IOBCSW
IOBRADD
IOBUNSl
PCI
RCHSEL
RCUSHRD
RDEVDED
RDEVSTA2
R2
TEMPR14
VDEVIOCT
VMTESIO
ASYSVM
CLASTERM
CO
DMKIOERR
FO
IOBCYL
IOBRCAW
IOBUSER
PRGC
RCHSTAT
RCUSTAT
BDEVtISA
RDEVTYPC
R3
BRING
DMKERMSG
DMKPTRAN
MCHFIX
RCHBLOK
RECPAGFR
R5
TYP 3340
ATTI
CLASURI
C8
DMKRGAI N
Fl
IOBERP
IOBRELCU
IOEVADt
PRTC
RCHTYPE
RCOSUB
RDEVFIOE
RDEVTYPE
R4
TIl~E Ii
TR!CBEF
VDEVREAL VMBLOK
VMTTIME YO
CHANID
DMKFREE
DMKRPAGT
MCHMODEL
RCHTYPE
RECPAGIU
R6
TYP3350
CPEXSIZE
DMKIOEES
DMKRPAPT
MCNPSi
RCH370
RO
R8
VMBLeK
CPUID
CPUMCELL
DMKIOE~P DMKIOEMS
DMKSCNRU DMKSEV70
lWDEFLAG MODEL 135
RDEVBLOK RDEVCODE
Rl0
Rl
R9
SA VEAREA
iAIT
CPUMODEL
DMKIOEMX
DMKSII60
MODEL145
RDEVTYPE
Rl1
SAVEREGS
CPUVERSN
DMKIOENI
DMKSYSER
MODEL155
RECCCPD
R12
SAVEiRK2
DEFER
DMKIOEOP
ECSiLOG
MODEL158
RECFLAGl
R13
S AVEiRK3
DMKCCHCF
DMKMCHAR
F7
MODEL 165
RECFLAG2
R14
SAVEiBK7
DMKCCHMX
DMKMCHBL
IOELPNTR
MODEL168
RECNXT
R15
SYSIPLDV
DMKCCHSZ
Df!KMCHRD
LOCK
MODEQUIT
RECPAG
R2
SYSTEM
BUSY
CLASORO
DE
DMKRNHIN
IFCC
IOBFATAL
IOBRES
IOERBLOK
PSA
BCH370
RCUTYPE
RDEVFLAG
RDEVUSER
R5
TRACCURR
VMESTAT
Y2
CAW
CPCREGO
DMKBSCER
DMKRSPER
IL
IOBFLAG
IOERSTRT
IOERCCW
QUANTOMR
RCUADD
RDEVADD
RDEVFTR
RUNUSER
R6
TRACEND
VMEITCM
Y4
CC
CPCREG8
DMKCCHIS
DMKR SPEI
INTREQ
IOBFPNT
IOBSIOF
IOERCSi
BCHADD
RCUBLOK
BDEV AlOE
RDEVIOCT
RO
R7
TRACFLGl
VMFPRS
Y6
CDC
CPEIBLOK
DMKCNSIN
DMKSCNRU
IOBBPNT
IOBHVC
IOBSNSIO
IOEREXT
RCHEMX
RCUCHA
RDEVBLOK
RDEVLIOB
Rl0
R9
'IRACSTRT
VMIDLE
CE
CPEIR13
DMKDASER
DMKSTKCP
IOBCAW
IeBIOER
IOBSPEC
IOERLEN
RCHBUSY
BCUDISA
RDEVBUCH
RDEVQCNT
Rl1
SAVEAREA
TRAC05
VMIOiAIT
CHC
CPEXSIZE
DMKDASRD
DIHSTKIO
IOBCC 1
IOEIRA
IOBSPLT
IOERSIZE
RCHDISA
RCUFIOB
RDEVBUSY
RDEVRACT
R12
SAVER11
TYPESC
VMPSi
CLASDASD
CPSTATUS
DMKDSPCH
Df!KTAPER
IOBCC2
IOELINK
IOBSTAT
lOOPS Ii
RCHFIOB
BCUPRIME
RDEVCONC
RDEVSCED
R13
SILl
TYPCTCA
VMR STAT
CLASGRAF
CPiAIT
DMKFREE
DMKTRCSI
IOBCC3
IOBLOK
IOBTIO
MNCLSEEK
RCHMPX
RCUQCNT
RDEVCUA
RDEVSKUP
R14
SKIP
UC
VMTMOUTQ
CLASSPEC
CSi
DMKFRET
DMKVIOIN
IOECP
IOBPAG
IOEUC
MNCOCYL
RCHQCNT
RCUSCED
RtEVCYL
RDEVSTAT
R15
SM
VtEVBLOK
VMTRCTL
CCC
CPEXADD
DMKCCHNT
DMKSCHDL
INTTIO
IOBHIO
IOBSIZE
IOERDATA
RCHBLOK
RCUBUSY
RDEVATT
RDEVIOER
Rl
R8
TRACFLG2
VMGPRS
HI
(1)
11
(1)
I:'
C'l
(1)
~odule
External References (Labels and Modules)
t~KISM
CD
IOBIUSC
R12
VMBLOK
DMKFREE
PSA
B13
DMKPTRAll DMKPTRUL DMKUNTIS 1"16
BCiCCllT RCiCCi
RCile
RCiPNT
B14
B15
B2
R3
DMKLDOO
DMKCPE
R5
DMKPSA
R6
R7
RO
R8
Rl
R9
BLANKS
DMKLOCR
DMKVDREL
INHIBIT
R15
SAVEiRR1
UDBFVADD
UDEVMODE
VCHDED
VMLOGON
BUFFER
DMKLCCKD
DMKVDSLK
NORET
R2
SAVEiRK2
UDEVADD
UDEVPASR
VCHSTAT
VMOSTAT
BUFINLTH
DMKQCllBD
EDIT
PSA
R3
SAVEiRK4
UDEVBLOK
UDEVR
VDEVBLOK
VMPSiDCT
BUFNXT
DMKQCNiT
ERRMSG
BDliBLOK
R4
SAVEiRK5
UDliDED
UDEVRELN
VDliFLAG
VMRSTAT
BUFSIZE
DMKSCNAU
FFS
RDEVTYPC
R5
SAVEiRK6
UDEVDISP
UDEVSTAT
VDEVRDO
VIWSER
tMKLllK
tn
(I)
0
..,.c+
0
1:1
.
w
D~KWRM
1"2
RCiRCNT
R4
F4
BCiTASK
R5
F8
RCWVCAi
B6
IDA
BO
R7
IOBCn
Rl
R8
IOBIRA
Rl0
B9
IOBLOK
Rl1
SAVEAREA
Bl0
R12
R13
R14
R15
B2
R3
R4
CLASDASD
DMKSCNFD
FTR2311E
RDEVTYPE
R6
SAVEiRK7
UDEVFTR
UDEVTDSK
VDEVREAL
VMVIRCF
DMKCVTBD
DMKSCllLI
FTR2311T
RO
R7
SAVEiRK8
UDEVLINK
UDEVTYPC
VDEVRELN
ZEROES
DMKCVTBH
DMKSCNVN
F1
R1
R8
SAVEiRK9
UDEVLKDV
UDEVTYPE
VDEVTYPC
DMKCVTHB DMKEPSiD
D~KSCllVS DMKSCNVU
F15
F2
Rl0
R 11
SAVEAREA
R9
TYP2311 TYP2314
UDEVLKID UDEVLM
UDEVVSER UDEVi
VDEVTYPE VDEVUSER
DMKERMSG
DMKUDBFD
F4095
R12
SAVERETN
UCASE
UDEVLONG
UDIRBLOK
VMBLOK
DMKFREE
DMKUI:RFU
1"7
R13
SAVER 11
UDBFBLOK
UDliLR
UDIRDISP
VMCOMND
D~KFRET
DMKFRET
R14
DMKSTKCP DMRSYSLB
B15
R2
DMKLOC
ASYSLC
BALRSAVE BALR14
CPEXADD
LOCKBLOK LOCKNAME LOCKNEXT LOCKQUE
R3
R4
R5
R6
CPEIBLOK CPEIFPNT CPEIREGS CPEXSIZE DMKDSPCH DMKFREE
LOCKSIZE PSA
RO
Rl
Rl0
R12
R7
B8
R9
SYSLOCS
DPlKLOG
ABIODC
CPMICAVL
DMKFREE
DMKSCNVN
DMKUDRBD
IOBUSEB
NICUSEB
BDEVSER
B13
SAVER11
TYP1052
ASYSVM
DMKBLDRT
DMKQCBWT
DMKSYSDi
DMKVDSDF
MICSIZE
BDEVADD
BDEVTYPC
B3
SAVEiBK2
UDEFVADD
UDEVTYPC
UMACCLEV
UMACRT
VDEVAUCB
VMCHCNT
VMFBMI
VMMLEVEL
VMRlAL
VMTLDEL
VMVTIME
ARIODV
CPSTAT2
DMKFRET
DMKSCNVU
DMKUDBRV
MICBLOK
NOBET
RDEVSIZE
B14
SAVER2
TYP2305
UDEV~ODE UDEVSIZE
UMACBLOK UlUCBMX
UMACLEND UMACNSVC
VCUADD
VCUBLOK
VMBSIZE VMCF
VMDVCNT VMDVSTRT
VMMFE
VMMICBO
VMPSTAT VPlPSW
VMTEBM
VMTESCP
VMUSEB
VMVCRO
ASYSLC
DMKACON
DMKLIKSE
DMKSYSCK
DMKUSOFF
MICCBEG
OPEBATOB
BDEVSTAT
B15
SAVEB9
UDBFBLOK
UDEVSTAT
UMACCDEL
U!UCOPT
VCUSIZE
VMCFBEAD
VMECEIT
VMMICSVC
VMPSiDCT
VMTIMEON
VMVIRCF
ASYSOP
DMKBLDEC
DMKQCNSY
DMKSYSDT
DMKVDSAT
MICBSEG
PSA
BDEVSYS
B2
SAVEiBK 1
UDBFSIZE
UDEVTDSK
UMACCLA
UMACPBIB
VDliADD
VMCFiAIT
VMESTAT
VMMIMSG
VMQSTAT
VMTIMEB
VMVTERM
BLANKS
DMKBLDV~
DMKSCHDL
DMKSYSLG
FFS
MICVPSi
RDEVAIOE
BDEVTYPE
B4
SAVEiBK8
UDEVADD
UDEVTYPE
UMACCOBE
UlUCVROP
VDEVBLOK
VMCHSTRT
VMFSTAT
VftMLINED
VMRON
V~TLEND
VMV370B
BUFCNT
DMKCFGII
DMKSCHBT
DMKSYSLi
1"1
MICiOBK
BDEVBLOK
BDEVUSEB
B5
SYSLOCS
UDEVBLOK
UDEVVSER
UMACDIS'I
VCHADD
VDEVCFLG
VMCLEVEL
VMISAM
VMMLVL2
VftBSTAT
VftTLEVEL
VftiNGON
BUFFER
DftKCQRFI
DMKSCH80
DMKSYSMA
1240
NEiPAGES
RDEVDED
BUIUSEB
B6
TEMPSAVE
UDEVDED
UDIBELOK
UMACDVCT
VCHELOK
VDEVCON
VMCOMND
VMKILL
VftMSGON
VMSEG
VftTftOUTQ
VRALOC
BUFNIT
DMKCVTBD
DMKSCNAU
DMKSYSMU
F4095
IEWSEGS
BDEVDISA
BO
B7
TRQBIRA
UDEVDISP
UDIBDISP
UMACECOP
VCHSIZE
VDEVSIZE
VMCUCNT
V~LOGON
VMMSVC
VMSIZE
VftTON
iAIT
DMKUDRRV
1"8
R14
SAVEB2
UDBFSIZE
UDEVLi
VCHBLOR
VMKILL
BUFSIZE CLASDASD CLASSPEC CLASTERM
DMKCVTBH DMKCVTDT DMKEPSiD DMKERMSG
DMKSCNFD DMKSCNBD DMKSCNRU Df!KSCNVD
D~KSYSIM DMKSYSTI DMKSYSTM DMKUDBFU
1"7
INHIBIT IOBLOK
1"8
NICELOK NICFLAG IHCPSUP NICSIZE
BDEVFLAG BDEVNICL BDEVOiN RDEVPSUP
Bl
Bl0
Bll
B12
B8
SAVEABEA SAVEBETN
B9
TRQELOK TRQESIZE TRQBUSER TYPBSC
UDEVLIIIlK UDEVLKDV UDliLKID UDEVLONG
UDIBPASS UDIBUSEB UMACACC UMACACCT
UMACES
UIUCIPL UMACISAM UMACLDEL
VCONCTL VCONBBSZ VCOIllBBUF VCONBCNT
VfUCCOUIIl VMACNT
VMACOUNT VMBLOK
VMCUSTBT VMDELAY VMDISC
VMDIST
VMIUCCCN VMMCODE VMMCPENV VMMCB6
VMftTEIT VMM360
VftOSTAT VMPNT
VMSLEEP VMSTOR
VMSYSOP VMTCDEL
V~TRMID
VftTRQELK VMTTlftE VMUPBIOB
ZEBOES
n
~
3:
0
~
s::
I-'
(1)
I
c+
0
I
t:-t
PI
tr
(I)
..,.t:='
I-'
t1
n
(I)
0
c+
0
..,.t1
(1)
til
t1
0
til
til
!:I:I
(1)
HI
(1)
t1
W
U'I
U'I
CI)
1:1
0
(I)
w
U1
n
Module
External References (Labels and Modules)
DMKPlCC
ACORETBL
DASDCL
DPlKPRGMI
F4
PlOBATRB
PERFCL
R 11
SCBEDCl
TRQBVAL
ASYSVPI
DEFER
DMKPBGTI
F4095
PlOICeM
PSA
R13
SILl
USERCL
BLANKS
DMKCVTDB
DMKPTRAB
F60
MONCTEEl
RDEVBLOK
R2
SPROFCL
VMBLOK
ERING
DMKCVTHB
DMKPTRFR
F8
MOBDVLST
RD:EVDED
R3
SYSTEM
VMUSER
CC
DMKERMSG
DMKQCBiT
IOBCAW
MONDVNUM
RDEVDISA
R4
TBUSY
ZEROES
CFSTOP
DMKFREE
DMKSCHRT
IOBLOK
MONFLAGl
RDEVFLAG
R5
TRACCURR
ACORETBL
CPEXADD
DMKDSPCB
F6
NORET
R12
SiPCBG1
VPlESTAT
YO
ALARM
CPEXBLOK
DPlKERPlSG
F8
OPERATOR
R13
SiPCBG2
VMEXTCM
Y2
ASYSVPl
CPEXSIZE
DMKFRE!
IRTftC
PAGCORE
R14
SiPFLAG
VPlEXiAIT
Y4
AVMREAL
CPID
DMKIOEftC
MCCPUID
PAGINVAL
R15
SiPKEYl
VMFPRS
Y6
CORBPBT
CPUID
DMKOPRiT
MCFXDLOG
PROBMODE
R2
SiPKEY2
VPlGPRS
ZEROES
CORDISA
CPUVERSN
DPlKPGSPO
PlCBEK
PSA
R3
TIPlER
VPlIRVPAG
ALABM
Rl0
SAVER11
ASYSVPI
DATE
R 11
R12
TEMPSAVE TODATE
I'd
0'1
3:
<
3:
"w
...,J
0
00
til
"<
CLASTAPE
DMKFRET
DPIKSCHST
IOBfUSC
MONNEXT
RDEVSTAT
R6
TRACEFLG
CORCP
DMKMOBMI
DPlKSCNFD
IOBSIZE
MOBSIZE
RDEVSYS
R7
'IRACSTRT
CCRFLAG
DMKMONSH
DPlKSCBRU
ICBUSER
MONUSER
RDEVTYPC
R8
TRQBIRA
CORTABLE
DMKMONTH
ERROR
LOCK
BORET
RDEVUSER
R9
TRQELOK
CPCREG8
DMKMOITI
F-FS
MBBBDLEN
PAGECUR
BO
SAVEAREA
TRQBSIZE
CPEXSIZE
DMKPRGC8
Fl
PlOBAIOB
PAGEND
Rl
SA VEiRKl
TRQBTOD
C8
DPlKPRGMC
F3
PlOBARDB
PAGEBXT
Rl0
SAVEiRK3
TRQBUSER
CD
E!I
DMKMCH
t'"4
0
....0
I.Q
III
::t
P.
I'd
t1
0
tT
.....
CD
E!I
~
CD
r+-
CD
t1
E!I
....
::t
III
....r+0
::t
G"l
....a
p.
CD
DPlKMID
a
.....
CD
I
r+-
0
I
t-t
III
tT
CD
.....
til
r+-
0
p.
CORFLAG
cO
DMKPTRFT
PlCRPSi
QUABTUPlR
R4
TRACCURB
VPlKILL
CORFPNT
C13
DPlKQCNiT
PlCOLDPi
RECOVRPT
R5
TRACEND
VPlOSTAT
CORIOLCK
C3
DPlKSCNFD
PlCOPSi
RUBUSER
R6
TRACFLGl
VMPSi
CORPGPBT
C7
DftKSTKCP
PlCPROGID
RO
R7
TRACSTRT
VMRSTAT
DMKCVTDT DPIKERMSG DftKQCNiT DftKSCBST DMKSYSDi DMKSYSTI RORET
R4
R5
R13
R2
B3
R7
R6
VftTTlftE
TRQBLOK TRQEVAL VPlBLOK
VMMLEVEL VftMSGOB VftPNT
CORSiPBT
DMKCFMBK
DftKSYSCK
PlCREC
Rl
B8
TRAC04
VMTPlOUTQ
CORTABLE
DMKCFPRR
FFS
PlCRECORD
Rl0
R9
TRARftODE
VMTTlft!
CPCREGO
DftKDPlPRS
F255
ftCRECTYP
Rl1
SAVEAREA
VftBLOK
VMUSER
PSA
B8
RO
B9
R1
SAVEAREA
n
11
0
til
til
!:O
CD
t-I)
CD
11
CD
::t
0
CD
til
(1)
0
r+
1-'0
~
w
Module
External References (Labels and Mod ules)
DMKMON
ALOCBLOK
CONCNT
CS
DftKERftSG
DMKPRGTI
DftKPBVLP
DftKPTRCS
DMKSCBAL
DMKSYSOC
Fl
IOBftISC
MNCODAS
KNOOO
ftN097CPU
MN099TOD
MN20XQ1N
MN202PGR
MN400IOC
MN400UID
MN600DLN
MN700QCH
MNS02PGi
HONDVlST
PAGENXT
RCUADD
RDEVDISA
Rl1
SAVEAREA
VMBLOK
VMPNCH
VMUSER
ALOCMAX
CONTASK
DASDCL
DMKFREE
DftKPRVCD
DftKPRVLB
DftKPTBFC
DMKSCHCT
DMKSYSOW
F3
IOBftISC2
ftNCODASH
MNOOOIIT
MN097CBS
ftNl0X
MN20XQ2E
ftN202PNC
MN400LEN
HH400UPR
HN600BDR
MH700QCU
MNS02PRB
MOIDVNUft
PAGEiAIT
RCUBLOK
RDEVFLAG
R12
SPROFCL
VMCRDS
VMPNT
VftVTIftE
ALOCUSEI
CORCP
DE
DftKFRET
DMKPBVCE
DftKPBVftN
DftKPTRFF
DftKSCBNl
DMKVIOCI
F4
IOBSIZE
ftNCOSUS
{!NOOOLEN
ftN097DAT
ftNl0XADD
PlN20XQ2N
PlH202PBI
ftN400LIN
ftH400VTI
HH600HLN
MN700QI:V
ftNS02iID
ftOIFLAGl
PERFCL
RCUCHA
RDlVIOCT
R13
SUSPEID
VftEPRIOB
VMPSTAT
VftiSPROJ
ARIOCB
COBFLAG
DftKCPEID
DftKBVCDI
DMKPRVCH
DftKPRVftO
DftKPTRFN
DMKSCBN2
DftKVIOCT
F4095
IOBSTAT
MNCOSYS
MNOOOPPA
MN097LlN
ftNl0XLEN
MN20XSWS
HN202PST
MN400PDK
MI400iSS
MN600MAX
ftN700UID
MN802iIO
IWNFLAG2
PGREAD
BCUDVTBL
RD:EVPREF
R14
TBUSY
VIHNST
VMPSi
ZEROES
ARIOCT
COBFPNT
DftKCVTDT
DftKIOSCT
DMKPRVCP
DftKPRVftS
DMKPTRFT
DftKSCBPU
DMKVIOCW
II:LEiAIT
IOERSIZE
ftNCOTB
ftNOOOPPC
ftN097LEV
MN10XUID
ftl20XUID
HN202REF
ftN400PDR
MN500
MN600NUM
MNS02CLH
MNS02iPG
MONIlXT
PGiRITE
RCUPRIME
RDEVQCNT
B15
TBQBLOK
VMICCNT
VMQL1!VEL
ARIOCU
COR TABLE
DftKDSPAC
DftKIOSQR
DMKPRVCS
DftKPRVNC
DftKPTRFO
DftKSCHQl
DftKVIOHD
IOBCAW
IONTWAIT
MNCOTT
MNOOOPRB
ftN097TIM
PlNl0YCNT
ftN20XWSS
HN202RES
MN400PGR
MN 500INS
MH600SER
MNS02CN'I
MONA lOB
ftONSAVE
PROBTlftE
BCUQCNT
RDEVSER
R2
TRQBSIZE
VftLINS
VftQPRIOR
ABIODV
CPCBEGS
DftKDSPBC
DftKPAGCC
DMKPRVCT
DftKPRVPB
DftKPTBPR
DftKSCHRT
DftKVIOHI
IOBCSi
IPLPSi
MNCOUSER
MNOOOPSI
MN097UID
MN10YIO
ftN20YTTI
MN203LEN
PlN400PGW
ftN500LEH
MN600TY
MNS02CTR
ftONARDB
ftONSIZE
PROPSi
RCUSUE
RDEVSKUP
R3
TRQBTOD
VftLOGON
VftQl
ASYSVft
CPEXADD
DftKDSPCC
DftKPAGPS
DftKPRVDI
DftKPRVPE
DftKPTRRC
DftKSCHST
DMKVIOSF
IOBCYL
P1NBHDLEN
MNHCLASS
MNOOOQ1E
MN09S
ftll0YLEN
MN20YVTI
HN204LEN
ftN400PNC
ftN5000VH
ftH700
MNS02DEV
MONATRB
ftONSUSCK
PSA
RCUTYPE
RDEVSTAT
R4
'IRQBVAL
VftPAGES
VftBDINQ
CC
CPEXBLOK
DftKDSPCB
DftKPRGCT
DMKPRVEK
DMKPRVPT
DMKPTRRF
DMKSCHW1
DPlKVIOSI
IOBFATAL
ftNCLDAST
MNHCODE
MNOOOQ2E
ftN09SLEN
MI2 BSV1
PlN202APR
ftN204PRI
MN400PST
MN500UID
MN700ADD
ftlS02DLN
HONCLASS
ftON SUSCT
PSASVCCT
RDEVADD
RDEVSYS
R5
TRUN
VftPDISK
VftRSTAT
CFSTOP
CPEXRO
DftKDSPCK
DMKPRGCS
DftKPRVEP
DMKPRVRR
DMKPTRSC
DMKSCHW2
DMKVIOTC
IOBFLAG
P1NCLPERF
MNHDR
ftNOOOWID
MI09SUID
MI20X
MN202CRD
MN4RSV1
ftN400QLV
MH500VAD
MN700CCY
MNS02NAU
ftO·NCLOCK
MONTIINT
RCHADD
RDEVALLI
RDEVTYPC
R6
UC
VftPDRUft
VftSTEALS
CLASDASD
CPEXSIZE
DftKDSPIT
I:ftKPRGGR
DftKPRVIK
DftKPRVTC
DftKPTRSS
DftKSTKCP
DPlKVIOTI
IOBIOER
ftNCLSYS
MNBDRLEI
MNOOOWIO
MN099
ftN20XNPP
MN202IOC
MN400
ftN400RES
MN600ADD
MN700CYL
MNS021PP
eONCODE
ftONUSER
RCBBLOK
RDEVBLOK
BO
R7
UE
nlPGREAD
VftTERM
CLASTAPE
CPUII:
DftKDSPNP
DftKPBGMC
DMKPRVIP
DftKPRVTE
DftKPTRSW
DftKSYSND
EBROR
IOBIBA
P1NCLUSER
MNBRl!CSZ
ftNOOOiPG
MN099CNT
PlN20XQNPI
MN202LEN
ftN400CRD
ftN400RST
MN600CNT
MH700DIR
MNS02HUM
eOlcoe
PAGECUR
RCBCUTBL
RDEVCUA
R1
RS
USERCL
VftPGRINQ
VMTTIME
CONADDR
CUE
DMKDSPPT
DMKPBGMI
DftKPRVLC
DMKPSANX
DftKPTRUL
DftKSYSNft
,FO
IOBLOK
ftNCODA
ftNBTOD
ftl097
ftN099LEN
HI20XQ1E
ftN202LIH
MN400IHT
MH400TTI
HH600DEV
MN700LEH
ftHS02PGR
HONCTEBl
PAGEND
RCHQCNT
RDEVCYL
Rl0
R9
VftAEX
VftPGiRIT
VMUPRIOB
DMKMSG
ALARlI
DftKSCNFD
R15
SAVEiRK4
VMOSTAT
ASYSOP
Fl
R2
SAVEiRK6
VftPNT
BLANKS
F2
R3
SAVEiRKS
VftR STAT
BUFFER
F3
R4
VftBLOK
VftTTlftE
BUFNXT
NORET
R5
VftCLASSA
VMUSER
DftKCVTDB
NOTlftE
R7
VftCLASSB
Vl!iNGON
DMKCVTDT
PRIORITY
RS
VftCLEVEL
XRIGHT16
DftKERMSG
PSA
R9
VMDISC
DftKFREE
RO
SAVEAREA
VlIKILL
DftKFRET
R1
SAVERll
VlILCGOFF
DftKQCNRD
Bl0
SAVER2
Vl!ftLEVEL
DftKQCNiT
Rll
SAVEiRKl
VftftLINl!D
Dl!KSCNAU
R13
SAVEiRK2
VftMSGON
ALARM
F20
IOERCSW
IOERPEND
Rl0
SAVERO
ASYSOP
F4
IOERDASD
IOERSTRT
R11
SAVER11
CCC
F6
IOERDATA
NOBET
R12
TYP3340
CDC
FS
IOERDEC
NOTHIJE
R13
UCASE
CLASI:ASD
F9
IOERETRY
OPERATOR
R2
VMBLOK
DftKCVTBH
IFCC
IOERFLGl
PSA
R3
VMDISC
DMKFREE
INTREQ
IOERIGN
RDEVBLOK
R4
VMOSTAT
DftKFRET
IOBLOK
IOERIGNR
RDEVCLAS
R5
VlIJTERlIJ
DlIKQCNRD
ICBRADD
IOERIND3
RDEVDED
R6
VMTTIlIJE
DftKQCNiT
IOERACT
IOERIND4
RDEVIOFR
R7
VMUSER
DftKSCNRN
IOERADR
IOERINFO
RDEVST AT
RS
ZEROES
EDIT
IOIRELOK
IOERLEN
RO
R9
FlO
IOERCNCL
IOERNUft
Rl
SAVEAREA
DMKMSW
("l
I'tj
tJ:
0
~
c=
~
(1)
I
r+
0
I
1:"4
~
IT
t:='
1-'t1
CD
0
r+
0
t1
1-'CD
til
w
(JI
...J
(1)
~
(1
t1
0
en
en
!:C
(1)
HI
CD
t1
(1)
~
0
(1)
w
U'1
Module
External References (Labels and Modules)
n
I"Cj
ex>
tMKNEM
-<
tl'IKNES
3:
"w
~
0
Ul
'<
til
r+
(l)
e
t"4
0
IQ
.....
tMKNET
0
~
l:I
0.
I"d
t1
0
t:r
~
RO
Rl
R12
R13
R15
B2
R3
CLASSPEC
DMKFREE
FFS
NICLBSC
RCBBLOK
RDBVDISA
RDEVPDLY
RDEVUSER
R7
SAVEWRK8
R4
CLASTERM
DMKFRET
Fl
NICLlNE
RCBCUTBL
RDEVDISB
RDEVPTTC
RDEViAIT
R8
SAVEWRK9
R5
til
SAVEAREA SAVERO
0
e:lI
ARlOCU
CSWLIiCF
DftKRlORN
HICCIBM
HICSTAT
RDEVBASE
RDBVlRM
RDEVTBTU
R15
SAVEiRKl
VMBLOK
ARIODV
CTBMLTB
DftKRHBHD
NICDISA
NICSiEP
RDBVBLOK
RDEVLHCP
RDEVTCTL
R2
SAVEWRK2
VMOSTIT
ASYSVM
DMKCVTEB
DMKRNBTR
HlCEHAB
NICTYPE
RDBVCON
RDEVMAX
RDEVTftCD
R3
SAVEWRK3
Vf'lTTlf'lE
BLANKS
tMKCVTDB
DMKSCNFD
HICEPAD
NICUSER
RDIVCTRS
RDUftDL
RDEVTYPC
R4
SAVEWRK4
VMUSER
CACTLTR
DMKCVTBB
Df'lKSCNRD
HIC!PMD
NCRET
RtEVCUA
RDEVNICL
RDEVTYPE
R5
SAVEWRK5
VMVIRCF
CDlSPLY
DMKERMSG
DMKSCNRU
HICFLAG
PSA
RDBVDED
RDEVNRDY
RDEVUSC8
R6
SAVEWRK7
IRlODV
DMKEBf'lSG
DftKRGBEN
NlCDISA
NlCSIZE
RDEVENIB
Rl1
SAVER2
VMCLASSB
ASYSVM
DMKFBEE
DftKRlORN
NICDISB
IiICSTAT
RDEVFLAG
R13
SAVER9
VMCLISSC
BLANKS
DMKFRET
DftKRNBND
NICENAB
NICTELE
RDEVLHCP
R14
SA VEiRK 1
VMCLASSt
CACTLIN
DMKIOESR
DftKSCNFD
NlCEPAD
NlCTERM
RDEVMAX
R15
SAVEWRK2
VMCLASSE
CDCTLIN
Df'lKNESDS
DMKSCNRD
NlCEFf'lD
NICTYPE
RDEVNICL
R2
SAVEWBK3
VMCLASSF
CLASSPEC
Df'lKNESEP
F255
NICFLAG
NlCUSER
RDEVNRDY
R3
SAVEWRK4
VMCLASSG
CLASTERft
DMKHESBD
F3
NICGRAF
NORET
RDEVRSVD
R4
SAVEWRK5
VMCLEVEL
CONCCW3
DMKHESPL
F4
NICLBSC
PSA
RDEVSTAT
R5
SAVEWRK7
VMOSTAT
CCNSYSB
DMKHESTB
F4095
NICLGRP
RDEVBLOK
RDEVTYPC
R6
SAVEWRK8
VMSTKO
CONTACT
DftKHESWH
F60
HICLINE
RDEVCTRS
RDEVUSER
R7
SA VEWRK9
VMUSER
CBESIMD
DMKHLDMP
F8
HlCNAME
RDEVDED
RO
B8
TEMPSAVE
VftVlRCF
DMKCVTBB
DftKNLDB
HICBLOK
NICRSPL
RDEVtlSA
Rl
B9
VMBLOK
ZEROES
DMKCVTHB
DMKQCNWT
NlCCIBM
NICSESN
RDEVDISB
Rl0
SAVEAREA
VMCLASSA
ABORT
CCPRSTAT
DMKCVTBB
DMKPTRUL
DMKSCIiVS
F4
IOBFLAG
IOBSPEC
NCPPNT
HICSWEP
RDEVAIOB
RDEVFICB
RDEVRCVY
Rll
SAVEAREA
SFBCOPY
SFBRECSZ
TYPUNDEF
VMBLOK
ADDSFB
CCPRSTEP
DMKCVTDT
DMKQCHCL
DMKSCHVU
F4096
10BFPHT
IOBSTAT
NCPSTART
IHCTEBf'I
RDEVATT
RDEVFLAG
RDEVRSVD
R12
SAVER11
SFBDATE
SFBSIZE
TYP2314
VMTTIME
ARSPRD
CCPRSTYP
DMKCVTHE
DMKQCHRD
DMKSTKlO
F5
IOBIOER
IOETIO
NCPTBL
NICTYPE
RDEVAUTO
RDEVFTR
RDEVSTAT
R13
SAVEB2
SFBDIST
SFBSTART
TYP3330
Vf'lUSER
ASYSVM
CCPSIZE
DMKDSPCB
DMKQCNTO
DMKSYSDU
F8
IOBIRA
IOBUSBR
NCPVOL
NlCUSER
RDEVBASE
BDEVIRf'I
RDEVSTA2
R14
SAVEWRKl
SFBDUMP
SlBT!ME
TYP3350
X40FFS
BLANKS
CCPTEP
DMKERMSG
DMKQCNWT
DMKVDREL
IL
IOBLCK
IOERBLOK
NICELCK
NOAUTO
RDEVELOK
RDEVLCEP
RDEVTFLG
R15
SAVEWBK2
SFBFILID
SFBTYPE
TYP3705
BRlHG
CCPTPEP
DMKFREE
DMKRHBlN
EDIT
lHTREQ
IOBMISC
IOERDATA
NICCIBM
HORET
RDEVCODE
RDEVLHCP
RDEVTMCD
R2
SAVEWRK3
SFBFLAG
SFBUSER
UC
CC
CCPTYPE
DMKFRET
DMKRHTBL
ERRMSG
10BBPNT
IOBMISC2
IOERETN
NlCEPAD
OPERATOR
RDEVCUA
RDEVMAX
RDEVTYPC
R3
SAVEWRK4
SFBFNAME
SILl
UCASE
CCPARM
CDC
DMKIOSQR
DMKRPAGT
FFS
10BCAW
IOBRADD
IOEREXT
HlCEPMD
PSA
RDEVDED
RDEVMDL
RDEVTYPE
R4
SA VEWRK5
SFBFTYPE
SM
VCUBLOK
CCPENTRY
CLASSPEC
DMKPGTCG
DMKRPAPT
FTRTYP 1
IOBCCl
IOBRCAW
IOERSlZE
NICFLAG
RCUBLOK
RDEVDISA
RDEVNCP
RDEVUSER
R5
SAVEWBK6
SFBLAST
SYSTEM
VCUDVTBL
CCPMAXID
CUE
DMKPGTSD
DMKRSPID
FO
IOBCC3
IOBRCHT
IPLREQ
HICHUIE
RCUDISA
RDEVEHAB
RDEVHICL
RDRCBN
R6
SAVEWRK7
SFBLOK
TEMFSAVE
VDEVADD
CCPNAf'lE
DEFER
DMKPG'IVG
DMKSCJiJFD
Fl
10BCP
IOBRES
LOCK
NICPSUP
BCUDVTBL
RDEVEPDV
RDEVNRDY
BO
R7
SAVEWRK8
SFBORIG
TYPBSC
VDEVBLOK
CCPPSlZE
DMKCFPBI
DMKPGTVR
DMKSCHRD
F256
10BCSW
IOBRSTRT
NCPNAME
NICSIZE
RCUSTAT
RDEVEPLH
RDEVOWN
Rl
R8
SAVEWRK9
SFBPNT
TYPlBMl
VDEVDIAL
CCPRESID
DMKCKSPL
DMKPTRAN
DMKSCHRU
F3
IOBFATAL
IOBSIZE
NCPPAGCT
NlCSTAT
RDEVADD
BDEVEPMD
RDEVPTTC
Rl0
R9
SFBCLAS
SFBRECNO
TYPPRT
VDEVFLAG
CONCCW3
DMKlOES R
F255
NICLTRC
RCUBLOK
RDEVENAB
RDEVRCVY
RO
R9
TYPBSC
CONDATA
DMKQCNCL
F3
NlCPSUP
RCUtISA
RDEVEPDV
RDEVRSVD
Rl
SAVEAREA
TYPTTY
CONSYSR
tMKQCNTO
F4
NICQPHT
RCUDVTBL
RDEVEPLN
RDEVSADN
R10
SAVER 11
iYPUNDEF
CONTASK
DMKQCNWT
F4095
NICSESH
RCUSTAT
RDEVEPMD
RDEVSLOi
Rl1
SAVER2
TYP2700
CSWLMEP
DMKRGBEN
NlCBLOK
NICSIZE
RDEVADD
RDEVFLAG
RDEVSTAT
R13
SAVER9
TYP3705
t:I
(I)
rt'
(l)
t1
EI
.....
l:I
~
r+
...,.
0
l:I
(j')
~
.....
0.
(l)
DMKNLD
(I)
I
r+
0
I
t"4
~
t:r
(I)
~
n
t1
0
en
en
(l)
e
~
~
I:tI
(l)
H\
(I)
t1
(I)
l:I
0
(l)
til
(I)
0
....0
("t
::I
.
~odule
External Beferences (Labels and l!odules)
I:l!KOPB
CLASGRAF CPUID
ALARl!
CAi
CC
CD
Rl
RDEVElOK RDEVCORD RDEVTYPC RDEVTYPE RO
R8
SILl
TYP3066 UC
XRIGBT16
CPUVERSN CSi
B14
R10
DMKRIOCN DlIKBIODV FFS
R1S
R2
R3
NOAUTO
R4
PSA
BS
tMKPAG
ACORETEL
CPEXR7
DMKSYSOi
IOBCYL
OiNDRDEV
R10
R9
Vl!BLOK
ALARl!
DMKCVTBB
FTR70l!B
IOBFATAL
PAGELOAD
R 11
SILl
Vl!TTIME
ARIODV
DMKDSPCB
Fl
IOEFLAG
PAGERATE
R12
SKIP
XTBDLOCK
CPEXADD
DMKIOSQR
F4
IOBLOK
PGiAITPG
R1S
SiPDPAGE
CPEXELOK
DMKOPRiT
FS
IOEl!ISC
PSA
R2
SiPFLAG
CPEXEPNT
DM·KPTRFF
F8
IOBPAG
RDEVBLOK
R3
SWPTRANS
CPEXFPNT
DMKPTRRQ
IL
IOBRADD
RDEVFTR
R4
TYP230S
CPEXl!ISC
DMKPTRSS
ICEEPNT
IOBSIZE
RDEVlIDL
R5
TYP2314
CPEXRO
DMKPTRiQ
IOBCAi
IOBSTAT
RDEVTYPE
R6
TYP3330
CPEXR 11
DMKSCNRD
IOBCP
IOBUSER
RO
R7
TYP3340
CPEXRS
DMKSTKCP
IOECSW
OWNDLIST
Rl
R8
TYP3350
DMKPER
VMBLOK
VMPEND
VMPERPNt Vl!TRCTL
Vl!TRPER
I:MKPGS
ACORETBL
DELPAGES
F15
Rl
R9
SHRBPNT
SWPTAELE
Vl!BLOK
VMSIZE
ASYSVl!
DHKBLDRL
F4
R10
SAVEAREA
SHRFPNT
SiPVlI
VHESTAT
VMSTOR
AVMREAL
Dl!KBLDRT
F4096
Rll
SAVERl
SHRNAME
SiPVPAGE
VMINVPAG
Vl!TIl!ER
CORBPNT
Dl!KDSPNP
F8
R13
SAVER2
SHRSEGCT
TR!XANSI
VMLOGOFF
VMTREXT
CORCFLCK
DMKFRET
KEEPSEGS
R14
SAVEiRK 1
SHRSEGNM
TREXIN 1
VlINSHR
XPAGNUP.I
CORFLAG
Dl!KPGTPR
NEiPAGES
R15
SAVEiRK2
SBRTABLE
TREXNSI
VMOSTAT
CORFPNT
Dl!KPTRAN
BEiSEGS
R2
SA VEiRK3
SHRTSIZE
TREXT
Vl!PAGES
CORIOLCK
Dl!KPTRFT
OLDVl!SEG
R3
SA VEWRK4
SBRUSECT
VMABLOK
Vl!PGWAIT
CCRPGPNT
Dl!KPTRPW
PAGCORE
R4
SAVEiRK7
SWPCYL
VMADSTOP
Vl!PSTAT
CORRSV
Dl!KPTRRC
PAGINVAL
RS
SAVEWRK9
SiPFLAG
VIUFPNT
VMRSTAT
CORSBARE
Dl!KPTRSC
PAGREF
R6
SEGPAGE
SWPKEYl
Vl!A:t1AME
VHSEG
CORTABLE
FFS
PSA
R7
SEGPLEN
SiPRECl!P
VMASIZE
Vl!SHR
DEFER
FO
RO
R8
SEGTABLE
SiPSHR
VMASSIST
VMSHRSYS
tMKPGT
ALARl!
CPEXSIZE
F4
RDEVFIOB
RECSIZE
R5
TYP33S0
ALOCBLOK
CPID
IOBCYL
RDEVFLAG
RECUSED
R6
VMBLCK
ALOCMAP
DMKCKP
IOBFPNT
RDEVFTR
RO
R7
Vl!PDISK
ALOCl!AX
Dl!KDSPCB
IOBLOK
RDEVPAGE
Rl
R8
VMPDRUl!
ALOCUSED
DlIKFRBB
NORET
RDEVPNT
Rl0
R9
ARIODV
DMKFRET
OPERATOR
RDEVPREF
R11
SiPCYL
ASYSVM
DMKQCNiT
OWNDLIST
RDEVRECS
R12
SiPDPAGE
EALRSAVE
DHKSTKCP
OiNDRDEV
RDEVTYPE
R13
SWPFLAG
BALRO
DMKSYSOi
PSA
RECBLOK
R14
SiPRECMP
BALRl
FFS
RDEVALLN
RECCYL
R1S
TYP230S
BALRS
FTR70MB
RDEVBLOK
RECMAP
R2
TYP2314
CP!XADD
Fl
RDEVCODE
RECHAX
R3
TYP3330
CPEXBLOK
F3
RDEVCYL
RECPNT
R4
TYP3340
tMKPRG
BRING
DMKPBVLG
INTPRL
RO
R7
TRANMODE
VMEXTClI
VMPSTAT
YO
CPABEBD
DMKPTRAN
INTSVCL
Rl
R8
TREXADD
VMEXWAIT
VMPSW
Y2
CPCREGO
DMKQCNiT
l!ONCLASS
Rl0
R9
TREXINTC
VMFPRS
VMRSTAT
Y4
CPCREG8
DMKTRCPG
MONCODE
R11
SVCNPSi
TREXINTL
VHGPRS
VMSHADT
Y6
CO
DMKVATPF
NORET
R12
SVCOPSi
TREXPERA
VMIOPBD
HISVCPND
C8
DMKVATPX
PERADD
R13
TEMPR14
TREXPERC
VMIOiAIT
VMTMOUTQ
DEFER
DMKVATSX
PERCODE
R14
TEMPR15
TREXPSW
VMOSTAT
VMTRBRIN
DMKCFl!BK
ECBLOK
PRNPSW
R1S
'HMER
TBEXT
VMPAGEX
VMTRCTL
DMKDMPDK
EXTPERAD
PROBMODE
R2
TRACCURR
VMBLOK
VMPEND
VMTREXT
DMKDMPGR
EXTPERCD
PROPSW
R3
TRACEND
VMCFRUN
HIPERCM
VMTRPER
DMKDSPB
FFS
PSA
R4
TRACFLGl
Vl!CFWAIT
VMPERPND
YMTRPRG
tMKDSPCH
Fl
QUANTUMR
RS
TRACSTRT
VHECEXT
VMPRGIL
VMTTIHE
DMKPERIL
INTPR
RUNUSER
R6
TRAC03
VHESTAT
VMPRGPND
VMY370R
CC
Dl!KFREE
F2
IOEFPNT
PAGEiAIT
R13
SiPCODE
CORTAELE
Dl!KFRET
F3
IOBIRA
PGSRATIO
R14
SiPCYL
C1
I'\j
3
0
PI
~
.....
CD
I
("t
0
I
t-4
W
P'
tj
....
t1
.....
(I)
H
0
0
("t
0
H
....
t:1'
(I)
C1
en
en
!:tI
(I)
CD
HI
CD
H
W
U1
::I
en
(I)
\0
0
CD
w
0'\
~odule
n
External References (Lahels and Modules)
~
0
3
tMKPRV
<
3:
"
..
w
~
0
til
Io.cj
lJl
r+
(1)
EI
0
IQ
1-"
0
'"
t:I
p..
~
H
0
t:r
.....
(1)
EI
t::;I
r+
(I)
H
51
1-"
::s
'r+"
1-"
0
::s
G'l
c
1-"
p..
(1)
CHANID
DMKPllGSM
EITCRO
F7
R10
R9
VCHBMI
VMGPRS
VMPIINT
CPCREGO
DMKPSAFP
EITCR9
INTPR
R11
SWPFLAG
VCHSEL
VMINQ
VMREAL
CPOID
DMKPSASP
EITMODE
INTPRL
R12
SiPKEY1
VCHTYPE
VMINST
VMllSTAT
CPOMCELL
DMKPTRAN
EITPERAD
MNCLINST
R13
SWPSHR
VMBLOK
VllINVFAG
VMRON
CFOVERSN
DMKTMRTN
EITSHCRO
MNCOSIM
R14
TEMPSAVE
VMCHSTRT
VMINVSEG
VMSEG
CO
DMKTRCPE
FFS
PERGPRS
R15
TRANMODE
VMCHTBL
VMIOINT
VMTRBRIN
C1
DMKTRCPV
F15
PERSALT
R2
TREICR9
VMDSP
VMNEWCRO
VMTRCTL
DEFER
DMKVATAB
F16
PROBMODE
R3
TREIINTC
VPlDSTAT
VMPEND
VMTIlEIT
DMKDSPA
DMKVATEI
F240
PROPSi
R4
TREIIN 1
VMECEIT
VMPERCM
VMTRPER
ACORETEL
CPCREG8
DMKDSPE
DMKT.I'lRVT
F4095
PRCBMODE
Rl
SAVERETli
TRACFLG1
HlDISC
VMPERPND
VMTREXT
ZEROES
APAGCP
CRESIMD
DMKDSFCH
DMKTBCIT
F60
PSASVCCT
R10
SAVER12
TRACSTRT
VMDSTAT
VMPSW
VMTRMID
ASYSOP
CSW
DPlKFREE
DMKTRCPE
F8
QOAHTUMR
R11
SAVER13
TRAC01
VMESTAT
VMQSEND
VMTRSVC
ASYSVM
CUE
DMKFRET
DMKTRCSV
INTEl
RDIYBASE
R12
SAVER2
TRAC02
VMEITCM
VMRSTAT
VMTSEND
BRING
cO
DMKPRGRF
DMKV!RD
INTEXF
RDEVELOK
R13
SAVESIZE
TREnN 1
VMEXiAIT
VMSEG
VMTTIME
BOSY
C1
DMKPTRAN
DMKVERO
INTSVC
RDEVFLAG
R14
SA VEiRK2
TREIT
VMFPRS
VPlSHR
iAIT
CLASGRAF
C8
DMKPTRUL
EIOPSW
INTSVCL
RDEVHIO
R15
SPI
TRQBBPNT
VMGPRS
VMSYSOP
XPAGNOM
CLASTERM
DEFER
DMKQCNCL
EITMODE
LOCK
llDEVNICL
R2
SVCNPSi
'IRQBFPNT
VMINST
VMTERM
XRIGHT24
CORFLAG
DFRET
DMKQCNWT
FFS
NICBLOK
RDEVTYPC
R3
SVCOPSi
TRQBLOK
VMMCR6
UITLEVEL
X2048BND
COR SHARE CORTABLE CPABEND CPCREGO
DMKCFMBK DMKCVTEH DMKDMPDK DMKDMPGR
DMKRNHND DMKSCHTQ DMKSCNRD DMKSTKIO
F1
F15
F2
F240
NICNAME NICSIZE NICUSER NORET
RDEVUSER llUNPSi
RUNOSER RO
R8
R4
SAVEAREA SAVENEIT
SYSTEPI
TIPlER
TRACCORR TRACEND
TRQBVAL VMADSTOP VPlBLOK
HICPOTMR
VMMICSVC VMMSVC
VMCSTAT VMPEND
VPlTMOUTQ VMTPlRIHT VMTRBRIN VMTRCTL
yO
Y2
Y4
Y6
ACORETBL
CORFREE
CPEXR13
DMKFRETR
FFS
PAGINVAL
R14
SAVERO
SAVEiRK9
SWPSHR
VMPGiAIT
ZERCES
ARIODV
CORICLCK
CPEIR2
DMKPAGIO
FO
PAGREF
R15
SAVER 1
SWPALLOC
SWPTRANS
VMPGWRIT
ASYSVPI
COBLCNT
CPEXR7
DMKPAGQ
Fl
PGREAD
R2
SA VER 11
SWPCHGl
SWPVPAGE
VMPSTAT
AVMREAL
CORPGPNT
CPEIR9
DMKPGTPG
F4
PGiRITE
R3
SA VER12
SiPCBG2
SYSTEM
VMRPAGE
BALRSAVE
CORRSV
CPEISIZE
DMKFGTFR
F4095
PSA
R4
SAVER13
SiPCODE
TIMER
VMRSTAT
BALRO
CORSHARE
CPSTAT
DMKQCNWT
F4096
RDEVBLOK
R5
SAVER2
SiPCYL
TYP2305
VMSEG
BALR2
CORSiPNT
Cl
DMKSCHDL
F8
RDEVTYPE
R6
SAVER3
SiPDPAGE
VMBLOK
VMSIZE
ERING
CORTABLE
DEFER
DMKSCHN 1
IOERETN
RO
R7
SAVER7
SWPFLAG
VMESTAT
VMSTEALS
CORBPHT
CPEIADD
DMKCFMBK
DMKSCHN2
LOCK
Rl
R8
SAVEiRKl
SWPKEY 1
VMINVPAG
VMTIMER
CORCFLCK
CPEXBLOK
DMKDSPCH
DMKSTKCP
NCRET
Rl0
R9
SAVEiRK2
SiPKEY2
VMNDCNT
VMTTIME
DMKDSFB
DMKVATLA
F4
PSA
R5
TREINSI
VMESTAT
VMPERPND
VMTRPRV
DMKDSPCH
DMKVATRN
F5
RONCRO
R6
TREIPERA
VM:EITCM
VMPRGIL
VMVCRO
DMKHVCAL
DMKVIOEI
F6
RO
R7
TREIT
VMEITPHD
VMPSTAT
VMv310R
0
p,.
C
.....
(I)
I
r+
0
I
t-I
'"
t:r
(I)
.....
0
DMKPSA
~
(I)
BRING
DMKFERIL
ECBLOK
F60
R1
R8
VCHBICK
VMEIWAIT
VMPSW
WAIT
tMKPTR
CORCP
CPEXFPNT
DMKDSPNP
DMKSYSOW
OiNDLIST
Rl1
SAVEAREA
SAVEiRK3
SiPRECMP
VMPAGES
VMiCNT
CORFLAG
CPEXMISC
DMKFR!E
DMKSYSRM
OiNDRDEV
R12
SAVEREGS
SAVEWRK5
SiPREFl
VMPGREAD
XPAGNUM
CORFPNT
CPEIRO
DMKFRET
DMI'
Df!KRNH
It:J:I
11:>1:1
It"'I
Df!KSPL
Df!KSPL
Df!KUSO
DMKSPL
DftKRSE
DMKCKP
DMKCKP
DPIKHVD
DMKWRft
DMKRSE
DMKCKP
DMKCKP
DPIKHVD
DMKWRM
Df!KWRf!
DPIKHVD
DMKWRft
DMKELE
DMKMCH
DPIKCCW
Df!KPAG
DMKCDS
DMKFGS
Df!KCFS
DMKPSA
DMKNLD
DMKQCN
DMKSPL
Df!KUSO
DMKVSf
EPlKVCA
DMKWRM
DMKVER
DMKCKP
DMKOPR
DMKCNS
DMKPAG
DPlKCPI
DMKFGT
DPlKCQP
DMKQCN
DMKMON
Df!KTDK
DMKTDK
Df!KPGT
DMKMON
DlilKTEK
Df!Kf!ON
DMKPSA
DMKTRC
DMKPGT
DMKVDB
DMKVDB
DMKTDK
DMKPGT
DMKVDE
DMKPGT
DMKTDK
DMKVDE
DMKCPI
DMKCPI
DMKCKF
DMKSCN
DMKCPS
DMKCPS
DMKCPI
DMKCPV
DMKCPV
DMKCPS
I
11-3
10
I
Iar:
10
It!
Ie:
DMKWRM
It-'
ItltI
In
I~
10
Itn
Itil
I~
Df!KCPI
DPIKPTR
DMRCPV
DMKRPA
DMKCSO
DPIKSCH
DMKDGD
DMKSPL
DMRDf!P
DMKUDR
EMKEDM
DMKUNT
ItltI
DMKFRE I~
ItltI
DMKVMA 1=
ItltI
HZ:
In
Itill
Df!KDAS
DMKRGE
DMKDf!P
DMKRNH
DMKERM
DPIKRSP
DMKGRF
DMKSAV
DMKIOG
DMKEEft
DMRCQP
DMKMON
DftKlOG
DMRDlA
DMKSCN
DMKMON
DMKMON
DMKSSP
DMKSCN
Dl!IRNES
DMKMCH
DMKUDR
DMKPlID
DMKVCN
DMKMSG
DMKVER
DMKVDB
DMKVDE
DMKVDE
DMKCQP
DMRCQP
DMKCPV
n
I'd
DMKSSP
DMKSCN
DlIIKSSP
DMKVCH
t-'
I»
t:J'
CD
....,
t+
0
I
:z
0
~
c::
..,.0
1'1
CD
n
rt
0
1'1
..,.
CD
en
....CD
n
1'1
0
en
en
=
CD
.....
~
W
-....J
w
1'1
CD
:::s
n
CD
w
-.J
01::
Label
Count
References
ARIODV
000045
D!!KACO
DMKDRD
D!!KUDR
DMKCKP
DMKACO
D!!RCKP
DMKACO
D!!RCRP
DMKCKS
D!!KCKS
DMKACO
D!!KCPI
DMKACO
D!!KDIA
DftKNES
D!!KUSO
Dl'IKCPC
DftKBSE
DftKBLD
D!!KCCi
DMKQCN
D!!KCPI
DMKCPI
DMKSCB
DMKVAT
DMKVAT
DMKCPI
D!!KVCA
DMKCCi
DMKCCW
DMKCNS
DMKCPI
DMKCNS
Df!lKCDS
DMKCSU
Df!lKCCIII
DMKVDB
DMKCPI
DMKCCW
D!!KDGD
DftKPRG
DMKTMR
DMKRGA
DMKESC
D!!KRGA
n
'"'='
t-t
<:
:.
w
"
-.J
0
til
'<
til
r+
(D
EI
t-t
ARIOPR
ARIOPU
ARIORD
ARSPAC
ARSPPR
ARSPPU
ARSPRD
ASYSLC
ASYSOP
ASYSVl'I
000004
000008
000004
000003
000011
000009
000025
000022
000014
000098
0
....
I.Q
0
ATTN
000055
I»
::s
p.
'"'='
t1
0
b"
...,
(D
&I
t::J
(D
r+
(I)
t1
....
II
::s
I»
....r+0
t:S
AVMREAL 000025
BALRSAVE 000077
BALRO
EALR 1
BALR 11
EALR12
BALR13
fALR 14
BALR15
EALR2
BALR3
fALR6
BALRS
EALR9
BLANKS
000005
000021
000001
000001
000001
000008
000001
000027
000007
000005
000005
000004
000121
BLKMPI
ERING
000002
000134
Cil
....c:
~
(I)
fSCAUSER 000004
BSCBLOK 000005
BSCCNT
000009
DMKCPV
DMKPAG
DMKCQP
DMKPGT
DMKCKP
D!!KLOG
DMKVDB
DMKSPL
DMKCSO
DMKCKS
D!!K!!CN
DMKWRM
DMRCRS
DMKCQG
D!!KCQG
DMKBLD
D!!KCPS
DMKBLD
DMKDRI:
DftKNET
DMKVDB
DMKCPft
DftKSSP
DMKCPG
DftKCPM
DMKRNH
D!!KPGT
DMKCVT
DMKCQG
DMKCQR
DMKCQR
DMKCPS
DMKLOG
DMKCQR
DMKCSF
Dl'IKCSP
DMRCPT
DMKMSG
DMKCRF
DMKEDM
Dl'IRPGS
Dl'IKVl'IA
D!!KCNS
DMKVIO
DftRCPS
DMKCPI
DftKSCN
DMRCSP
D!!RCSU
DMKCST
D!!KCKP
D!!KMSi
D!!RCNS
Dl'IKPRE
DMKPGT
DMKCSU
DMKSPL
DMKCSU
D!!KLOC
DMKPSA
DMKCPB
Dl'IKGRP
Dl'IKPSA
D!!REDM
DMKUSO
Dl'IRDl'IP
Dl'IKLOG
D!!KQCN
DMKCPI
D!!KIOS
Dl'IKPTR
DMKSPL
DftRDDR
DMKVMI
DMKCPV
DPlKCPV
DMKUNT
DMKDIR
DMKDMP
DftKPBE
DMKCSO
DMKVAT
DftKMCH
DMKCVT
DMKVCA
DMKPGT
D!!RSCN
DMKVI:B
DMKVDS
DMKLOC
DMKVAT
DMRVCA
DMRVDB
DMRCPI
Df!lKCIIIS
DMKCPI
DMKPGT
DMKVCA
DMKCPC
DMKDIA
D!!KRGA
DMKVDS
D!!KVIO
DMKCDB
D!!KDRD
DftKPRV
Df!lKTRC
DMKRGB
DMKRGA
DMKCVT
DMKSCB
DftKVDB
DMKSCN
DMKD!!P
DftKVCA
D!!RPTR
DMKSCN
DftKCPD
DMKERM
DMKRNB
DMKVSP
DMKCPM
DMKGRP
DMKRSP
DMKCPS
DMRHVC
DMKSCB
DMKCDS
DMKDSP
DftKPSA
Df!lKUDR
D!!RCPD
D!!KFRl'I
D!!KFTR
Dl'IKVAT
DMKCPG
DMKGIO
DftRRGA
DftKVCH
DMKCP~
DMKDSP
Dl'IKNLD
Dl'IKVDR
DftKCKP
DftKVCA
DftKCPP
DMKCBS
DMKSCH
DMKPTR
DftKDIA
Df!lKRGB
DMKCPI
D!!KNES
DMKCPS
DMKNET
D!!KCCB
DMKGRP
DMKVCB
DMKCSO
DMKCKP
DMKCSO
DMKCQR
DMKPTR
DMKCSO
DMKSCN
DMKDIA
DMKSPL
DMKD!!P
DMKSSP
I»
b"
...,
(D
I
r+
0
DMRSPL
I
:3
0
p.
DMRUSO
...,
Dl'IKDRD
Dl'IKUDR
DMKUSO
DMKCPS
Dl'IKLOG
Dl'IKRGA
D!!KNLD
Dl'IKUSO
D!!KVCB
DMKCPV
D!!RMCC
Dl'IKRNH
D!!KSPL
D!!KUSO
DMKVSP
(D
DMKCQP
Dl'IKftCB
Dl'IKSCll
D!!KCSO
Dl'IKl'IID
Dl'IKSPL
DMKDAS
DMKl'ION
DPlKTHI
DMKDSP
DMKPMT
DMKGRP
DftKIOS
DftKRNB
~
n
t1
0
til
til
l:O
(D
I-h
(D
t1
DftKPGS
DMKDIA
DMKVMA
DMKPTR
D!!KPRE
DftKRPA
DMKLOC
DMKSCH
DMKPGT
DMKVIO
DMKPTR
DftKTMR
DftKVCA
DMKVftA
DMKCNS
DMKLNK
Dl'IKSPL
Df!lRCPB
DMKLOG
DMRTHI
DMKCQG
DMKMCC
Dl'IKTRC
D!!KCQP
DMKMSG
DMKUDR
Dl'IKCQR
DMKNES
DMKUSO
DMKCSO
DMKNET
DMKVCA
DMKCSP
DMKNLD
DMKVCN
DMKCKS
Dl'IKGRP
DMKRGB
DMKVCN
DMKCNS
D!!KHVC
DftKRPA
Df!lKVER
DMKCPB
DMKHVD
DMKRSP
DftKVIO
DMKCPI
D!!KIOF
D!!KSCH
DftKVftA
DMKCPV
DMKIOG
DftKSEP
DMKVSP
DMKCSO
D!!K!!CC
DftKSNC
Dl'IKWRl'I
DMKCST
D!!KNLD
Dl'IKSPL
(D
::s
0
(D
til
CD
0
....0
Label
Count
References
ESCCOPY
BSCECCi1
ESCECCi2
BSCEBQ
ESCETB
BSCFLAG
ESCFLAG 1
BSCIGB
ESCIBDE!
BSCLINE
ESCLOG
BSCOPIED
ESCPCCi 1
BSCPCCi2
ESCPCCi3
BSCPCCi4
ESCRCVI:
BSCREAD
ESCREGEB
BSCRESF
ESCRROBB
BSCRSTRT
ESCRVI
BSCSCAli
ESCSCCi 1
BSCSCCi2
ESCSCCi3
BSCSEL
ESCSENI:
BSCSENSE
ESCSIZE
BSCSIZE1
ESCSIZE2
BSCSPTR
ESCTMRQ
BSCTSTRQ
ESCUCOPY
BSCUECCW
EUFCNT
BUFFER
000009
000004
000004
000004
000005
000040
000008
000004
000006
000002
000005
000004
000004.
000002
000003
000006
000008
000024
000003
000028
000006
000002
000003
000007
000006
000005
000003
000012
000005
000015
000002
000004
000001
000015
000006
000002
000006
000003
000027
000107
BUFIN
000003
DMKRGA
Dl!KRGA
DMKRGA
Dl!KRGA
DMKRGA
Dl!KRGA
DMKRGA
Dl!KRGA
DMKRGA
Dl!KRGB
DMKRGA
DMKRGA
DMKRGA
DMKRGA
DMKRGA
DMKRGA
DMKRGA
Dl!KBSC
DMKRGA
Dl!KBSC
DMKRGA
Dl!KRGA
DMKRGA
Dl!KRGA
DMKRGA
DMKRGA
DMKRGA
Dl!KRGA
DMKRGA
Dl!KEGA
DMKRGA
DMKRGA
DMKRGB
DMKRGA
DMKRGA
DMKRGA
DMKRGA
DMKRGA
DMKCFM
DMKCDB
DMKLOG
DMKCPI
~
t:I
.
W
....t:I
t1
CD
0
r+
0
....
t1
CD
en
DMKRGE
DMKRGB
DMKRGB
DMKRGE
DMKRGB
DMKRGA
DMKRGA
DMKRGB
DMKRGB
DMKRGB
DMKRGE
DMKRGB
DMKRGB
DMKRGB
DMKRGE
DMKRGB
DMKRGE
Dl!KRGE
n
I'tI
t-t
DMKCFS
DMKCFG
DMKMSG
DMKVCB
DMKCPI
DMKCFM
DMKRGA
DMKCST
I:MKCFS
Df!KRSF
DMKERM
DMKCPI
Df!KSCN
I:MKGRF
DPIKCSO
DMKLOG
DMKCSP
DMKRGA
DMKCST
DMKRSP
DMKCSU
DMKVCN
DMKERM
III
DMK GRF
DMKLNK
t:r
CD
I-'
I
~
o
•
3:
o
~
C
I-'
CD
n
t1
o
en
en
!::tj
CD
Ht
CD
t1
w
-..J
U1
CD
t:I
o
CD
w
-..J
label
Count
References
n
I'd
0'1
EUPINLTH 000018
BUPNXT
000026
~
::I:
"w
-..J
BUPSI ZE
EUSOUT
BUSY
000026
000005
000044
0
til
Ioc:I
en
rt-
CACTDEV
CACTLIB
CACTLTR
CAW
000002
000002
000002
000073
CC
000845
(1)
II
f:"I
0
....0
IQ
CCC
000041
CCCPUID
CCDES!!D
CCDEVTYP
CCHADDE
CCHANlt
CCHCAV
CCHCHNL
CCHCMDV
CCHCNTB
CCHCPU
CCHCUA
CCHDAV
CCHDI
CCHHIO
CCHINTE
CCHINTPC
CCHLOG!t5
CCHLOG60
CCHLOG70
CCHLOG80
CCHRCV
CCHREC
(CHSIOE
CCHSIZE
000001
000003
000001
000001
000006
000001
000012
000010
000005
000003
000002
000010
000003
000002
000001
000007
000002
000001
000001
000002
000003
000005
000002
000002
PI
t:J
Cl.I
I'd
t1
0
t:r
~
(I)
•
0
CI)
rt-
(I)
t1
II
....
t:J
~
....
rt0
='
en
....
~
Cl.I
CI)
DMKCPft
DMKCDB
DftKVCN
DMKCPM
DMKRNH
DMKCKP
DMKVIO
D!!KBliH
DftKNET
D!!KIlES
DftKCCH
DMKVftI
DMKACO
D!!KD!!P
DftKRSE
DMKVDB
DMKBSC
D!!KESP
DftKCCH
D!!KDIA
DMKCCH
D!!KCCH
DMKCCH
DMKCCH
DMKSEV
D!!KEIG
DMKSEV
DMKSEV
DftKCCH
DMKEIG
DftKEIG
DMKCCH
DftKCCH
DMKSEV
DMKCCH
DMKSIX
DMKSEV
DMKCCH
DMKCCH
DMKCCH
DMKCCH
D!!KCCH
f:"I
DftKERM
DMKCFG
DMKGRP
DMKCPM
DMKINK
DMKC:fS
DMKRGA
DMKCPI
tftK RGB
DMKCSO
DMKCSU
DMKlliK
DMKCPI
DMKRSE
DMKCBS
DMKVMI
DMKERM
DMKGRP
DMKLNK
DMKLOG
DMKRGA
DMKRSP
PI
DMKLOG
DMKMSG
DMKRSP
DMKSCli
t:r
(1)
~
DMKCPI
DMKDDR
DftKDIR
DMKDMP
DMKFMT
DMKIOS
I
rt-
DMKPSA
DMKRliH
DMKSSP
DMKVCA
0
I
:.:
0
Cl.I
....
~
DMKRBH
D!!KRBH
DftKCKP
DftKCBS
DMKCPI
DMKDftP
DMKPMT
DftKIOS
DMKOPR
DftKSAV
DftKSSP
DMKTRC
DMKVIO
DftKBSC
DMKPMT
DMKRSP
DMKVMI
DftKCCH
D!!KSlV
DftKCCW
DMKGRP
DMKSAV
DMKVSP
D!!KCNS
DMKTAP
DMKCKF
DMKIOS
D!!KSEF
DMKWRM
DMKCFI
DMKUBT
D!!KCNS
DftK!!CC
DMKSPL
DftKCPI
DMKMOB
DMKSSP
DftKCSO
DMKBLD
DftKTDK
DMKDAS
DMKCPR
DMKUCB
DMKDDR
DMKPAG
DMKUCS
DftKDGD
D!!KRGA
DMKUDR
DMKDIA
DMKRGB
DMKVCA
DMKDIR
DMKRNH
DMKVCN
D!!KDAS
DMKEIG
DMKGRF
DMKHVC
DMKIOE
DMKIOS
D!!KMSW
DMKRSE
(1)
n
t1
0
en
til
=
(1)
tit
(1)
t1
(1)
t:J
D!!KRBH
0
(1)
DMKSIX
DMKS!V
DMKSIX
DMKSIX
DftKSIX
DMKSEV
DMKSEV
DMKSIX
- DMKSIX
DMKSIX
DMKEIG
DMKEIG
DMKEIG
DMKSEV
DMKSIX
tn
CD
(1
....1+
0
t:S
w
Label
Count
References
CCBSIZE 1
CCBSBSB
CCBSTG
CCBTIO
CCBUSV
CCPADDB
CCPARft
CCPEBTllY
CCPftAXID
CCPNUIE
CCPPSIZE
CCPBESID
CCPROGID
CCPRSTAT
CCPRSTEP
CCPRSTYP
CCPSIZE
CCPTEP
CCPTPEP
CCPTYPE
CCRECTYP
CD
000002
000001
000004
000002
000005
000001
000004
000001
000001
000003
000005
000002
000003
000001
000001
000001
000003
000002
000001
000003
000002
000099
CDC
000038
CDCTLlli
CDISPLY
CE
000001
000001
000077
CFSTOP
CBANID
CBBATTJ
CBBCENT
CBBCNTL
CBBEOFL
CBBBIO
CBBftNOP
CBBlO70
CBBRDBK
CBBREAD
CBBREST
CBBSIZE
000006
000003
000013
000003
000002
000014
000015
000005
000020
000007
000008
000012
000003
DftKCCB
DftKCCB
DftKSEV
DftKCCB
DftKEIG
DMKSNC
DftKNLD
DftKNLD
DftKNLD
DMKliLD
DftKNLD
DMKliLD
DftKCCB
DMKliLD
DftKNLD
DMKNLD
DftKNLD
DMKliLD
DftKNLD
DMKliLD
DftKCCB
DftKCCW
DftKRGB
DftKBSC
DMKRSE
DftKliET
DftKNES
DftKCKP
DMKRSE
DftKCPS
DftKIOG
DftKVCA
DMKVCA
DMKVCA
DftKVCA
DftKVCA
DMKVCA
DftKVCA
DMKVCA
DMKVCA
DMKVCA
DMKDIA
DMKSIX
DMKSEV
DMKSIX
DMKSNC
DftKSNC
DMKSNC
DftKSNC
DftKCBS
DftKSSP
DftKCCB
DMKRSP
DftKDAS
DftKTAP
DftKCNS
DftKTAP
DMKDDR
DftKUNT
DftKDAS
DftRUNT
DftKDGD
DftKVCA
DftKGRF
DftKDIA
tMKVCN
DMKBYC
DMKDIR
DftKVMI
DMKIOE
DMKFftT
DMKVSP
DMKIOF
DftKGRF
DftKISM
DftKOPR
DftKRGA
DftKIOS
DftKftSW
DMKNLD
DftKRNB
DftKCNS
DMKRSP
DMKftCC
DftKPRV
DftKCPI
DMKSAV
DMKftON
DMKtDR
DMKSSF
DMKDIA
DMKYCA
DMKDIR
DMKVCN
DftRDftP
DMKVIO
DMKFMT
DftKVlH
DMKGRF
DftKVSP
DMKHVC
DftKIOS
DMKRGA
n
to
DMKYIO
t-'
~
0CD
~
DMKVCA
I
1+
0
I
=-0
~
d
~
....t:1
CD
H
CD
n
(1
H
1+
0
H
en
en
0
....
l:I:1
en
Ht
CD
CD
CD
H
w
...,J
...,J
CD
t:S
(1
CD
w
ooJ
CD
Label
Count
n
References
I"tj
t"4
<
or:
w
"
ooJ
0
VI
I<
en
cT
CD
B
1:-1
0
IQ
~.
0
PI
=
0.
~
H
0
tr
....
(1)
iii
t:::I
CD
("t
(I)
H
e
~.
t:I
PI
("t
~.
0
t:I
en
CI
~.
0.
(I)
CHBWAIT
CHBWEOP
CHBWRIT
CHC
CBGRDV
CBGSFB
CBGSBQ
CBIBLOK
CBICfilDE
CBICfilDT
CBICNCT
CBIDATN
CBIFLAG
CBIIDAi
CBINCCW
CBIOTBH
CBIPKEY
CBIRCNT
CBISTAT
CBIYADD
CBYBLOK
CHYCfilDB
CBYCfilDT
CBYCNCT
CBYDATN
CBYFLAG
CBYIDAi
CBYNCCi
CBYOTBR
CBYRCNT
CBYSTAT
CBYIADD
CKCMASK
CKPBITS
CKPBKSZ
CKPBLOK
CKPNAME
CKPRfilAX
CKPSIZE
CLASDASD
000014
000002
000009
000014
000002
000012
000004
000013
000010
000014
000009
000005
000057
000004
000012
000009
000005
000010
000020
000007
000005
000001
000003
000004
000006
000032
000001
000004
000001
000005
000003
000005
000001
000003
000001
000004
000003
000002
000003
000108
DMKCFP
Dl'lKYCA
DMKVCA
DMKBSC
DfilKCSO
DfilKCKS
DMKCSP
DMKCFP
DMKVCA
Dl'lKVCA
DMKCFP
DMKYCA
DMKCFP
DMKVCA
DMKVCA
Dl'lKCQG
DJ!IIKVCA
Dl'lKVCA
DMKVCA
Dl'lKCQG
DJ!IIKDIA
Dl'lKVCA
DMKVCA
Dl'lKVCA
DMKVCA
Dl'lKVCA
DMKVCA
Dl'lKVCA
DMKDIA
Dl'lKVCA
Dl'lKVCA
Dl'lKDIA
DMKCPI
Dl'lKIiNB
Dl'lKRNB
DMKENB
DMKRNB
DMKHHB
DMKRNB
DflKACO
DMKDIR
Dl'lKSCN
~
DMKVCA
tr
....
(1)
DMKCNS
'DMKGRF
DfilKHVC
DfilKIOS
DMKRNB
DMKRSE
DfilKTAP
I
DMKUNT
cT
0
DMKCSP
DMKWRM
DfilKCQG
DfilKCSU
DfilKDfilP
DMKRSP
DMKDIA
DMKVCA
DMKVIO
DfilKSPL
I
DMKVSP
D:
0
0.
CI
....
CD
n
DMKYCA
DMKVCA
H
0
DMKVIO
[II
en
!:O
Dl'lKDIA
DJ!IIKVCA
(1)
Hl
(1)
H
CD
Dl'lKDIA
DMKVCA
=
DJ!IIKVCA
0
CD
DMKVCA
DMKWRM
DJ!IIKWRM
DMKWRM
DMKWRM
DMKCCW
DIHDMP
DMKSSP
DMKCKP
DMKEDM
DMKTRC
DMKCPI
DMKGIC
I:MKVCE
DMKCPS
DMKIOC
DMKVDB
DMKCPV
DMKIOE
DMKVDR
DMKCQG
DMKIOF
DMKVDS
DMKCQP
mUIDS
DMKVER
Dl'lKCQR
DMKLNK
Dl'lKVIO
Dl'lKDDR
DMKLOG
DMKVfH
DMKD:EF
Dl'lKl'lON
DMKDGD
Dl'lKl'lSW
label
Count
CLAS GRAF 000060
CLASSPEC 000061
CLASTAPE 000064
CLASTERl!I 000138
CLASUR1
CLASURO
til
(1)
0
rT
...,.
0
I:l
.
W
t:I
...,.
t;
(1)
0
rT
0
t;
...,.
(1)
[Il
Cl!IDREJ
CNTLBTU
COMPFES
COfilPSEL
COMPSYS
CONACTV
CONADDR
CONCCW 1
CONCCW2
CONCCW3
CONCCW4
CONCNT
CONCNTL
CONCOMND
CONDATA
CONDCNT
CONDEST
CONESCP
CONEXTR
CONFLAG
CONLABEL
CONOUTPT
CONPABM
CONPNT
000076
000058
000010
000005
000009
000015
000006
000028
000032
000083
000037
000034
000030
000069
000024
000008
000081
000031
000004
000021
000001
000006
000029
000031
000109
000091
References
DlUCCW
Dl!IKD1R
DMKTRC
DMKBLD
D!!KBVD
DMKUSO
Dl!IKCCW
DMKG10
Dl!IKBLD
DMKCQP
DMK10E
DMKUSO
DMKCCW
Dl!IKDEF
DMKTRC
DMKCCW
Dl!IKDEF
Dl!IKVCH
DMKCNS
DMKRNH
DUEIG
DfilKE1G
DMKCCB
DfilKCNS
DMKCNS
DMKCNS
Dl!IKCNS
DMKCNS
Dl!IKCNS
Dl!IKCNS
DMKCNS
DMKCNS
DMKCNS
DMKD1A
Dl!IKIiNB
Dl!IKCNS
DMKRBB
Dl!IKCN S
DMKBGA
DMKCNS
D!!KCNS
DPlKCNS
Dl!IKCFl!I
D!!KEDl!I
DMKUSO
DMKCCW
D!!K1OE
DMKVCH
DMKCFS
DMK10E
DMKCCW
DMKCQR
Dl!IK1OF
DMKVCH
DMKCFP
DMKD1R
DfilKVCH
DfilKCFP
Dl!IKD1R
Dl!IKVDR
DMKD1A
Dl!IKCFP
Dl!IKGRF
DMKVCB
DMKCFP
DMK10F
Dl!IKVDB
DMKCKP
DMK10F
DMKCFM
DMKCSP
DMK10S
DMKVCN
DMKCKP
Dl!IKDRD
DMKVDR
DMKCFS
DMKDMP
DMKVDS
DMKRNB
Dl!IKCFT
I:MKBVC
DMKVCN
Dl!IKCFT
DMK10S
Dl!IKVDR
DMKCPB
DMK1CS
DMKCFP
DMRCST
DMKLOG
DMKVDR
DMKCPB
DMKEDM
DMKVDS
Dl!IKCKP
DMKEDfiI
DMKV1C
DfilKRSF
Dft.KSEV
DfilKSEV
Dl!IKE1G
DfiKGRF
Dl!IKGRF
Dl!IKGRF
Dl!IKGRF
DfilKD1A
Dl!IKGRF
DMKGBF
DMKQCN
DMKRNH
Dl!IKD1A
DMK10E
DKK51X
Dl!IKS1X
DfilKSEV
DMKRGA
DMKftON
DMKBGA
DfilKBGA
DfilK10E
DfilKRGA
DMKl!ION
DfilKBGA
DMKRBB
DftKQCN
DMKRGE
DMKRGB
Dl!IKNES
Dl!IKBGB
DMK(;CN
I:MKRGB
Dl!IKGBF
DMKBGA
DMKGRF
DMKRGA
DMKRNH
DMKRGB
DMKGRF
DMKGRF
DMKEDM
Dl!IKCKP
DMKHVD
DMKVDS
Dl!IKCKP
DMKLOG
DMKVDS
DMKCP1
Dl!IKl!ICC
DMKCFT
Dl!IKDDR
Dl!IKNES
DMKVDS
Dl!IKCPS
Dl!IKHVD
DfilKV10
Dl!IKCPB
DMKHVD
DMKVSP
DfilKVCN
Dl!IKCP1
DMK10E
DMKV10
DMKCPB
DMKNES
DMKV10
DMKCPS
DMKMON
DMKCKP
DMKDFF
DMKNET
DMKV10
DMKCQG
DMK10F
DfilKVl!I1
DfilKCPS
DMK10F
Dl!IKCPS
DMK10F
Dl!IKCPV
DMK10S
D!!KCQG
DMKOPR
D!!KCQP
DMKPSA
Dl!IKI:EF
DMKQCN
Dl!IKD1A
Dl!IKSSP
DMKCQG
Dl!IKBET
DMKVM1
DMKCQG
Dl!IKSSP
Dl!IKCBS
DMKD1A
DMKPSA
Dl!IKWRl!I
Dl!IKCQP
Dl!IK1OS
Dl!IKVSP
DfilKCQG
Dl!IK1OS
DMKCQP
D!!KNLD
DMKWRl!I
Dl!IKCQP
DMKVCH
DMKCPB
DMKD1R
DMKQCN
DMKCQR
Dl!KQCN
DMKDEF
Dl!IKRBB
Dl!IKD1A
DMKSCN
Dl!IKD1R
DMKTRC
D!!KCQR
DMKVDB
D!!KCP1
Dl!IKEDM
D!!KRGA
DPlKDDR
DMKVDR
DMKCPS
DMKHVC
DMKSCB
DMKDl!IP
Dl!IKVDS
DMKCPV
DMKHVD
DMKSSP
Dl!IKVl!I1
DMKCQG
Dl!IK1OC
DMKTRC
Dl!IKCSO
DfilKRSE
Dl!IKCSP
DMKRSP
DMKCST
Dl!IKSCN
Dl!IKCSU
DfilKSPL
Dl!IKSSP
DMKCQP
Dl!IKRSE
Dl!IKCSO
Dl!IKRSP
Dl!IKCSP
Dl!IKSCB
Dl!IKCST
DMKSSP
DMKTRC
DftKRGA
Dl!IKRNH
DMKBNH
DMKNET
DftKRGB
DftKRBH
DfilKBGA
DMKRGB
DMKRGA
Dl!IKBNH
Dl!IKBGB
DMKBNH
Dl!IK1OE
Dl!IKRNH
DMKNES
DMKQCN
DMKRGA
DMKRGE
DMKRNB
DMKVSP
DMKBNB
DMKRGB
DMKRNB
n
I'd
t"'4
AI
0-
D!!KQCN
DMKQCN
DMKGRF
D!!KRGE
DMKRGA
DMKQCN
DMKRNB
DMKRGB
D!!KRGA
(j)
~
DMKRNH
DMKRGB
I
DMKRNH
rT
0
I
3:
0
p.
~
~
(1)
n
t;
0
[Il
[Il
!::tI
(1)
Hi
(1)
w
"-oJ
\D
t1
(j)
I:l
0
(1)
w
c:o
Label
count
CORRESP
CORRETR
CORRSV3
CORRTAG
CORRTBY
CONSPLT
CONSBID
CONSTAT
CONSYNC
CONSYSR
CORTACT
CONTASK
CONTCMD
CONTSIZE
CONTSKSZ
CONUSER
CORBPRT
CORCFLCK
CORCP
CORDISA
CORFLAG
000017
000030
000022
000003
000012
000014
000013
000126
000005
000040
000003
000119
000027
000036
000016
000012
000020
0000 17
000010
000002
000056
CORFLUSB
CORFPNT
CORFREE
CORIOLCK
CORLCN'I
CORPGPNT
CORRSV
CORSBARE
CORSiPNT
CORTABLE
000001
000052
000003
000012
000008
000034
000008
000014
000019
000087
CPABERD
CPCREGO
CPCREG8
CPEX
CPEIADD
000009
000018
000019
000009
000045
n
R.eferences
'"
1:"4
0
c::
3:
"w
..
...,J
0
til
Io.oC:
en
en
r+EI
1:"4
0
IQ
1-'-
n
I»
::l
j;lo
'"
t;
0
...,
tT
en
EI
t::I
en
en
("t
1"1
•
1-'::l
I»
("t
1-'0
::l
en
-=
1-'j;lo
en
D~KCRS
DMKCRS
DMKGRF
DMKRRH
DMKCNS
DMKCNS
DMKRRH
DMKCNS
DMKCNS
DMKDIA
DPlKliET
DMKCNS
DPlKRNH
DMKCNS
Df!KCRS
DMKCNS
DMKMCB
DMKBLD
DMKCPI
DMKEDM
DMKELD
DMKPSA
DMKEDM
DMKBLD
DPlKCPI
DMKMCB
DPlKBLD
DMKBLD
DMKCFS
DMKCCi
DMKBLD
DMKBLD
DMKPlON
DMKDMP
DMKCKP
DMKCPS
DMKDSP
DMKACO
DPlKPAG
DMKVMA
DMKGRF
DfIIKGRF
DMKQCR
DMKQCR
DMKQCN
DMKRGB
DMKRGA
DMKRGA
DMKRGB
DPlKRGE
I»
tT
DMKRRH
DMKRRB
en
...,
I
("t
DPlKRRH
DMKQCN
0
I
3:
DMKRNH
0
j;lo
DMKGRF
DMKGRF
DMKNES
DPlKRRH
DMKEDM
DfIIKQCR
DMKQCN
DMKNET
DMKRGA
DMKRGB
DMKRNH
DPlKRGE
DMKRNH
DMKRNB
DMKGBF
DMKPlON
DMKRES
DMKQCN
DMKRGA
DMKGBF
DPIKEDM
DfIIKQCN
DMKPGS
DMKCPI
DfIIKDMP
DMKMCH
DfIIKCCi
DMKPTR
DMKQCN
DMKGRF
DMKRGA
DMKPTR
DMKCPV
Dl'!IKEDM
Df!KRGA
DMKQCN
DMKRGE
DMKRPA
Df!KFGS
DMKMCC
Df!KRGE
DfIIKRGA
DMKRNB
DMKSCH
Df!KPTR
DMKMON
DMKRRH
DMKRGB
DMKRRH
DMKUDR
DMKRPA
DMKPTR
DMKSCH
DfIIKCDS
DMKRPA
DfIIKCFS
DMKSCB
DMKCPI
DPlKVMA
DMKCPV
DPlKDMP
DMKEDM
Df!KMCC
DMKMCB
DMKMOR
DMKPGS
DfIIKCPI
DMKEDM
DMKPGS
DMKPTR
DMKCDS
DfIIKPGS
DMKCDS
DfIIKCCW
DMKCCW
DMKPAG
DMKEDM
DPlKCPI
DMKIOS
DPlKVCA
DMKCDS
DfIIKPGT
DMKVSP
DMKCPV
DMKPTR
DMKPTR
DMKDPlP
DPIKEDM
Dl'!IKMCH
DfilKMOR
DMKPGS
DMKPTR
DMKRPA
DMKSCH
DMKUDR
DMKRPA
DPIKSCH
DMKDGD
DMKPTR
DMKEDl'!I
DMKCDS
DMKCDS
DMKPGS
DMKPRG
DMKDSP
DMKMCC
DMKFRE
DMKSCE
Dl!KFGS
DMKCPI
DPlKCFS
DMKPSA
DPlKFSA
DMKIOS
DMKMCR
DMKMCB
DMKPGS
DMKPTR
DMKRPA
DMKUDR
DfIIKUNT
DMKVfIIA
DPlKPSA
DMKDGD
DMKCPI
DMKPTR
DMKPTR
DMKEDM
DMKCPV
DMKRPA
DMKSCE
DMKMCH
DMKDGD
DMKSCH
Dl!KVl'!IA
DfIIKPTR
DMKDMP
DMKUDR
Dl!KRPA
DMKEDM
DMKURT
DMKnlA
DMKFRE
DMKVMA
DMKMCC
DMKMCB
DMKPRG
DMKPRG
DMKPSA
DMKPRV
DMKPSA
DPlKTMR
DMKTRC
DMKVAT
DMKCFM
DMKPTR
DMKCPV
DMKQCN
DMKDIA
DMKRGA
DMKDSP
DKKRGB
DMKGRF
DPlKRNH
Dl'!IKIOE
DKKRPA
DMKIOS
DPlKRSP
DKKLOC
DPIKSPL
DMKMCH
DKKUSO
...,
-=
en
n
DMKRGB
i'1
0
DMKRNH
en
en
!XI
en
HI
en
1"1
en
::l
n
DMKMCH
DKKMON
DKKVCA
en
Label
Count
CPEIBLCK 000088
en
(1)
n
....
ri"
0
1:1
W
....t:I
1"'1
(1)
n
ri"
0
1"'1
....
(1)
en
CPEIBPNT
CPEXFPNT
CPEIPllSC
CPEXREGS
CPEIRO
CPEIR 1
CPEIR10
CPEXR 11
CPEXR12
CPEIR 13
CPEIR14
CPEXR15
CPEIR2
CPEIR3
CPEIR5
CPEIR6
CPEIR7
CPEIRa
CPEIR9
CPEISIZE
000006
000033
000006
000009
000025
000001
000001
000005
000004
000004
000001
000001
000005
000001
000003
000005
000003
000001
000002
000057
CPlD
CPftICAVL
CPPllCOli
CPRUN
CPSHRLK
CPSTAT
CPSTATUS
CPSTAT2
CPOlD
CPOLOG
CPOPICELL
CPUftODEL
CPOVERSN
CPiAlT
CRESCliiD
CRESDQ
CRESERL
000031
000007
000009
000002
000007
000001
000012
000019
000028
000001
000003
000002
000011
000008
000001
000001
000002
References
DPIKACO
DftKftCH
DPlKSTK
DPlKDSP
DftKCDS
DMKFAG
DftKCFft
DMKCDS
DftKVSP
DMKDSP
DftKDSP
DMKCPV
DMKIOS
DPlKCDS
DftKCDS
DPlKPTR
DftKVftA
DMKCDS
DftKlOF
DftKCDS
DftKVSP
DPlKPTR
DftKACO
DMKlOS
DftKRSP
DMKCCH
DftKCFS
DMKCFS
DftKDSP
DftKCCi
DftKPTR
DPlKCPI
DMKCCi
DftKCCH
DftKCPl
DMKBVD
DftKCPl
DMKCPl
DftKCPI
DMKIiNH
DftKDlA
DftKRliH
D8KCDS
DPlKftON
DPIKOSO
DPlKPAG
DPlKDSP
DMKPTR
DMKCPV
DMKCPS
DKKCFK
DMKPAG
DMKVCA
DMKSTK
DMKlOE
DMKCPS
DPlKFGT
DPlKVDB
DKKCPi
DMKPTR
DPlKVftA
DPlKDlA
DftKQCN
DftKVSP
DPlKDSP
DftKRGA
DMKGRF
DMKRGB
DMKlOE
DPlKRNH
DMKIOF
DftKRPA
DPlKlOS
DMKRSP
DPIKIOF
DPlKLOC
DPlKPAG
DMKPTR
DftKRPA
DftKSTK
DftKVCA
DPlKVSP
DPlKDSP
DMKGRF
DMKlOE
DMKMON
DMKIOF
DMKPAG
DMKLOC
DMKPTR
DMKQCN
DMKRGA
DMKSPL
DMKRPA
DMKUSO
DMKVCA
DftKVDB
DMKVMA
DMKPAG
DMKQCN
DMKPTR
DMKUSO
DMKOSO
DMKVDB
DMKVSF
DMKVCA
DftKCPS
DftKPlON
DMKVDB
DftKCPS
DftKCPV
DMKPGT
DPlKVftA
DftKCVT
DftKDlA
DftKPTR
DftKVSP
DftKDMP
DftKDSP
DMKQCN
DMKGRF
DMKRGA
DPlKlOE
DftKRGE
DMKlOF
DMKRNB
DMKlOG
DMKRPA
DMKGRF
DMKMCH
DMKPGT
DftKiRM
DMKDGD
DftKIOF
DftKDSP
DftKlOG
DMKLOG
DMKftCH
DMKMON
DPIKOPR
DftKPRV
DMKSSP
DMKLOC
DftKSPL
DMKVMA
DPlKPAG
DPlKPAG
DftKPTR
DftKCDS
DPlKLOC
DftKSPL
DPlKCKP
DMKCPl
DMKCPI
DMKCFft
DMKftCC
DftKOSO
DPlKCNS
DMKLOG
DMKCQR
DMKDGD
DMKDSP
DPlKDSP
DftKCFS
DPlKCPI
DPlKlOS
DftKCPl
DftKBVC
DMKIOG
DMKlOG
DMKHVD
DftKDSP
DMKPRV
DMKCPl
DMKPlCH
DMKVCA
DPlKCPI
DMKDSP
DPlKCQR
DftKIOE
DMKVER
n
to
t-'
DMKlOF
DMKlOS
tMKIOG
DftKVCA
DMKftCH
DMKOPR
DMKPRV
DMKSSP
~
0(1)
.....
I
r+
0
I
3
0
~
c=
.....
(1)
n
1"'1
0
en
en
~
(1)
HI
(1)
1"'1
(1)
W
CD
...
1:1
n
(1)
w
.J
W
='
0
CD
.:::
tv
Label
Count
References
R6
002567
DMKBLD
DMKCFT
DMKCSP
DMKEDl!I
DMK10S
DMKNET
DMKRSE
DMKTMR
DMKVER
DMKACO
DMKCFS
DMKCSO
Dl'IKDS P
DMKISM
DMKIiET
DMKRPA
DMKTHI
DMKVER
DMKACO
DMKCFT
DMKCS P
DMKEDM
Dl'IKIOS
DMKNES
DMKRGA
DMKTAP
DMKVCN
DMKACO
Dl'IKCNS
DMKDAS
DMKFRE
DMKLNK
DMKPAG
DMKRSP
DMKTH1
DMKVDS
Dl'IKBLD
DMKACO
DMKCFS
DMKCST
DMK10C
DMKMSG
DMKIiNH
DMKTHI
(1
t'tj
.:::
<
3:
""
l.rJ
0
til
Ioc:I
[Jl
R7
002858
r+CD
II
t"'4
0
....
0
I,Q
I»
=
Po
R8
002093
t'tj
t1
0
0-
~
CD
iii
~
CD
r+-
CD
R9
002001
t1
II
....
=
....
I»
rt'
0
ts
Gl
....c:
Po
(1)
SA VCREGS 000007
SAVEAREA 000143
DMKVDS
DMKBSC
DMKCKP
DMKCST
DMKERM
DMKISM
DMKNLD
DMKRSP
DMKTRC
DMKVIO
DMKBLD
DMKCFT
DMKC SP
DI1KEDI1
DMKLDOOE
DMKNLD
DMKR SE
DMKTMR
DMKVIO
DMKBLD
DMKCKP
DMKCST
DMKERM
DMKISM
DMKNET
DMKRGE
DMKTDK
DMKVDE
DHKBLD
DHKCPI
DMKDDR
DMKGIO
DMKLOC
DMKPGS
DMKSAV
DMKT MR
DMKVER
DMKCPG
DMKBLD
DMKCFT
DMKCSU
DMK10E
DMKl'iSW
DMKRPA
DMKTRA
DMKVER
DMKCCB
DMKCKS
DMKCSU
DMKFMT
DMKLDOOE
DMKPAG
DMKSAV
DMKUDR
Dl'IKVMA
DMKBSC
DKKCKP
DMKCST
DMKERM
DMKLNK
DMKPAG
DMKRSP
DMKTRC
DMKVMA
DMKBSC
DMKCKS
DMKCSU
DMKFMT
DMKLDOOE
DHKNLD
DMKRNH
DMKTHI
DMKVDR
Dl'IKBSC
DMKCPS
DMKDGD
DMK GRF
DMKLOG
DMKPGT
DMKSCH
DMKTRA
DMKV10
DMKCCW
DMKCBS
DMKCVT
DMKFRE
DMKLNK
DHKFGS
DMKSCH
DMKUNT
DMKVM1
DMKCCB
DMKCKS
DMKCSU
DMKFMT
DMKLOC
DMKPGS
DMKSAV
DI1KUDR
DMKVSF
DMKCCH
DMKCNS
DHKCVT
DMKFRE
DMKLNK
DMKCPR
DMKRSE
DMKTMR
DMKVDS
DMKCCH
DMKCPV
DMKDIA
DMKHVC
DMKMCC
DMKPRG
DMKSCN
Df'IKTRC
DMKVMA
DMKCDB
DMKCPB
DMKDAS
Dl!IKGIO
DMKLOC
DMKPGT
DMKSCN
DMKUSO
DMKVSP
DMKCCW
DMKCNS
DMKCVT
DMKFRE
DMKLOG
DMKPGT
DMKSCH
DMKUNT
DMKWRM
DMKCCW
DMKCPB
DMKDA S
DMKG10
DMKLOC
DHKPAG
DPlKRSP
DMKTRC
DMKVER
DMKCCW
DMKCQG
DMKD1R
DMKHVD
DMKMCH
DMKPR V
DMKSEP
DMKUDR
Df'IKVMI
DMKBSC
DMKCK S
DMKDAS
DMK IOF
DMKNEM
DMKRSE
DMKTRC
DMKVMA
DMKCCH
DMKCNS
DMKDEF
DMKIOG
DMKNES
DMKRSP
DMKTRM
DMKCCW
DI1KCPB
DMKDGD
DMKIOS
tMKNE'I
DMKSEP
DMKUDR
I:MKWRM
D~KVSF
DMKCDS
DMKCPI
DMKDDR
DMKGRF
DMKLOG
DMKPRG
DMKSEP
DMKV AT
DMKWRM
DMKCDB
DMKCPB
DMKDAS
DMKG10
DMKMCC
DMKPRG
DMKSCN
DMKUSO
DMKCFC
DMKCPS
Dl!IKDEF
DMKHVC
DMKMCC
DMKPRV
DMKSNC
DMKVCA
DMKCFD
DMKCPV
DMKDGD
DMKHVD
DMKMCH
DMKPTR
DMKSPL
DMKVCB
DMKCFG
DMKCQG
DMKDIA
Dl!IKIOC
DMKM1D
DHKQCN
DMKSSP
DMKVCN
DMKCFM
DMKCQP
DMKDl!IP
DMKIOE
DMKMOB
DHKRGA
DMKT AP
DMKVDB
DMKCFP
DMKCQR
DMK DRD
DMKIOF
DMKMSW
DHKRGB
DMKTDK
Dl!IKVDR
DMKCFS
DMKCSO
DMKDSP
DMKIOG
DMKBES
DMKRNH
DMKTB1
Dl'IKVDS
DMKCDS
DMKCP1
DMKDDR
DMKGRF
DI1KI1CH
DMKPRV
DMKSEP
DMKVAT
DMKCFC
DMKCPS
DMKDEF
DMKBVC
DMKIHD
DMKFTR
DMK SNC
DMKVCA
DMKCFD
DMKCPV
DMKDGD
DMKBVD
DMK110N
Dl'IKQCN
DMKSPL
DMKVCB
DMKCFG
DMKCQG
DMKD1A
DMK10E
DMKMSG
DMKRGA
DMKSSP
DMKVCN
DMKCFM
DMKCQP
DMKDMP
DMKIOF
DMKMSW
DMKRGB
DMKTAP
DMKVDB
DMKCFP
DMKCQR
DMKDRD
DfiIK lOS
DMKNES
DMKRNH
DMKTDK
DMKVDS
DMKCDB
DMKCPI
DMKDDR
DMKGRF
DMKLOG
DHKPGS
DMK SA V
DMKT RM
DMKVIO
DMKCI:B
DMKCQP
DMKDMP
DMK10C
DMKMID
DMKPTR
DMKSEV
DMKUNT
Df'IKVSP
DMKCDS
DMKCPV
DMKDEF
DMKBVC
DMKMCC
DHKPGT
DMKSCH
DMKUDR
DI1KVMA
DHKCFG
DMKCQR
DMKDRD
DMKIOE
DMKMON
DMKQCN
DMKSIX
Dl'iKUSO
DMKWRM
DMKCFD
DMKCPV
DMKDGD
DMKHVD
DMKMCH
DHKPRG
DMKSCN
DMKUNT
DHKVSP
DMKCFM
DMKCSO
DHKDSP
DMKIOF
DMKMSG
DMKRGA
Df'IKSNC
DMKVAT
DMKCFG
DMKCQG
DMKDIA
DMKIOC
DMKMID
DHKPRV
DMKSEP
DMKUSO
DMKWRM
DMKCFP
DMKCS P
DMKEDM
DMK10G
DMKMSW
DMKRGB
DMKSPL
DMKVCA
DMKCFM
DMKCQP
DMKDMP
DMKIOE
DMKMOB
DMKPSA
DMKSNC
DMKVAT
DMKCFP
DMKCQR
DMK tRD
DMKIOF
DMKMSG
DMKFTR
DMKSPL
DMKVCA
DMKCFS
DMKCSO
DMKDSP
DHKIOG
DHKMSW
DI1KQCN
DMKSSP
DMKVCH
DMKCFS
DMKCST
DMKE1G
DMKIOS
DMKNES
DMKRBH
DMKSSP
DMKVCH
DMKCKP
DMKCSU
DMKERM
DMK1SM
DMKNET
DMKRPA
DMKTAP
DMKVCN
DMKCKS
DMKCVT
DMKFMT
DMKLDOOE
DMKNLD
DMKRSE
DMKTDK
DMKVDB
DMKCtB
DMKCPS
DI1KD1A
Df'IKI SM
DMKNLD
DMKSEV
DMKUNT
DMKCDS
DMKCPV
DMKDRD
DMKLNK
DMKPGS
DMKSIX
DMKUSO
DI1KCFC
Df'IKCQG
DMKEIG
DMKLOG
DMKFSA
DMKSNC
DMKVAT
DMKCFD
DMKCQP
DMKERM
DMKI1CC
DMKPTR
DMKSPL
DMKVCA
DI1KCFG
I:MKCQR
DMKG10
DMKMCH
DMKQCN
DMKSSP
DMKVCH
DMKCFI1
DMKCSO
DMKGRF
DMKMID
DMKRGA
DMKTAP
DMKVDB
DMKCFP
DMKCSP
DMKHVD
DMKMON
DMKRGB
DMKTDK
DMKVDR
~
III
0CD
~
I
r+-
0
I
3:
0
Po
~
~
CD
(1
t1
.:>
[Jl
[Jl
l:C
CD
HI
CD
t1
CD
=
0
CD
Label
Count
SA VENEIT
SAVEREGS
SA VERETN
SAVERO
000004
000032
000031
000049
SAVERl
000042
SAVER10
SAVERll
000013
000059
SAVER12
SAVER13
SAVER2
000014
000003
000148
SAVER3
SA VER4
SAVERS
SA VER6
SAVER7
SA VER8
SAVER9
SAVESIZE
SAVEWRK 1
000006
000001
000007
000008
000()O2
000022
000007
000008
001001
SAVEWRK2 000552
SAVEWRK3 000138
til
CD
n
....
t+
0
::I
W
....'='
t1
CD
n
t+
0
t1
....
CD
en
SAVEWRK4 000170
References
D~KPSA
D~KCCW
DftKCFC
DMKCNS
DMKRGA
DMKBLD
DMKRPA
DMKCCW
DMKACO
DMKLOG
DftKVCH
DMKCCW
DftKPSA
DMKBLD
DMK!RM
DMKQCN
DftKVDS
DMKERft
DftKTRC
DftKCFG
DMKCFG
DMKPTR
DMKELD
DMKCCW
DMKCPI
DftKBLD
DftKCQG
DMKLOG
DMKSEV
DMKVDS
DMKACO
DMKCPS
DftKIOG
DPlKSNC
DMKVDB
DMKACO
DMKDIA
DMKTHI
DMKCCH
DMKCQR
DMKPGS
DMKCPV
DMKCFG
DftKCQG
DMKRNH
DftKCCW
DMKTDK
DMKS!P
DMKELD
DMKMID
DMKVDE
DMKDGD
DMKPTR
DMKCCW
DMKGIO
DMKRGA
DMKVMA
DftKPTR
DMKCQP
DftKCPB
DMKCQP
DMKRSP
DMKCFC
DMKTRC
DMKVCA
DMKCFM
DMKMSG
DMKVMA
DMKPSA
DftKVAT
DftKCDS
DMK GRF
DMKRGB
DftKVSP
DftKQCN
DMKTRC
DMKDRD
DMKSPL
DMKCCW
DMKLOG
DMKFRE
DMKCCH
DMKCQP
DMKMCC
DMKSIX
DMKVER
DMKBLD
DftKCPV
DftKLNK
DMKSPL
DMKVDR
DMKCCH
DMKDRD
DMKTRC
DMKCDB
DMKCSO
DMKQCN
DMKVCA
DMKSNC
DMKCKS
DMKNES
DMKPSA
DftKCCW
DftKCQR
DMKMSG
DMKSNC
DMKVMA
DMKCCH
DMKCQG
DMKLOG
DMKTAP
DMKVDS
DMKCDS
DMKIOG
DMKUNT
DMKCDS
DMKCSP
DMKSNC
DMKDGD
DMKIOE
D~KDIA
D~KLNK
DMKDRD
DMKTDK
DMKCNS
DMKVCA
DMKIOG
DMKLOG
DMKERft
DMKTRC
DMKCQP
DMKVDS
DftKPSA
DMKGRF
DMKUDR
DMKERM
DMKVSP
DMKRSP
DftKFTR
DMKHVD
DMKVAT
DMKICE
DftKSEP
DllKUSO
DftKftSW
DMKVCA
DMKPGS
DMKVAT
DftKV AT
DftKNEft
DMKVSP
DMKPTR
DftKCQR
DMKSNC
DMKCKS
DMKVAT
DMKVCH
DMKCPS
DMKMSW
DftKVCA
DftKPTR
DftKVER
DMKQCN
DMKQCN
DMKRIH
DMKCPV
DMKNES
DMKCQG
DMKNLD
DMKCQP
DftKPTR
DMKCSU
DftKQCN
DMKtAS
DftKSPL
DMKDIA
DftKTHI
DMKIOS
DftKUSO
DMKLIK
DMKVCA
DMKFTR
DftKVAT
DMKVCA
DftKVER
DftKCFC
DMKLNK
DMKRNH
DMKWRft
DMKVAT
DftKCFM
DMKLOG
DMKRPA
DftKCKS
DMKMSG
DMKSNC
DMKCNS
DMKNES
DMKTRA
DftKCQP
DMKNET
DMKTRC
DftKDEF
DMKNLD
DftKUDR
DftKDGD
DMKPGS
DftKVAT
DMKDIA
DMKPSA
DftKVCH
DftKDRD
DMKPTR
DMKVDB
DMKDIA
DMKNET
DMKSEP
DlIKSPL
DMKSPL
DMKTDK
DMKVDR
DMKVDS
DMKVSP
DMKCDE
DMKCSO
DMKNES
DMKCFD
DMKCST
DMKNLD
DMKTRA
DftKCFG
DMKCSU
DMKPGS
DMKTRC
DftKCFS
DMKDEF
DMKPTR
DMKUNT
DftKCFT
DMKDIA
DMKQCN
DMKUSO
DftKCKS
DMKDRD
DMKRPA
DMKVCA
DMKCPS
DMK!IG
DMKRSE
D~KSPL
DMKCDS
DMKCSP
DMKNET
DMKTHI
D~KVCH
DMKCPV
DftKLNK
DMKSEP
DMKVDB
DMKWRM
DMKCCW
DMKCQP
DftKMSG
DMKTDK
DMKVER
DMKCFD
DMKMCC
DMKUSO
DMKCFC
DMKCST
DMKTRC
DMKCDE
DMKCQR
DMKNES
DMKTHI
DMKVMA
DMKCFG
DMKNES
DMKVCA
DMKCFD
DMKCSU
DMKVCA
DMKCDS
DftKCSO
DMKNET
DMKTRA
DMKVSP
DMKCFS
DMKNET
DMKVDB
DMKCFG
DMKDEF
DMKVDB
DMKCFC
DftKCSP
DftKNLD
DMKTRC
DMKWRM
DMKCKS
DMKNLD
DMKVDR
DMKCFS
DMKDIA
DMKVDR
DMKCFD
DMKCST
DMKPGS
DMKUDR
DMKCFG
DftKCSU
DftKPSA
DMKUNT
DMKCFS
DftKD!F
DftKP'IR
DMKUSO
DMKCKS
DftKDIA
DftKQCN
DMKVCA
DMKCPB
DMKDRD
DftKSEP
DMKVCH
DMKCPS
DMKPGS
DMKVDS
DMKCKS
DMKLNK
DMRVDS
DMKCPV
DMKPTR
DMKVER
DMKCPB
DftKMSG
DMKVER
DMKCQG
DftKQCN
DMKVMA
DMKCPS
DMKNES
DMKWRM
DMKCQP
DMKSNC
DMKWRM
DMKCPV
DMKNET
DMKDEF
DMKTAP
D~KPTR
DMKCQG
DMKNLD
n
to
~
PI
t7'
CI)
.....
I
t+
0
I
IX
0
~
c:
.....
CI)
n
t1
0
en
en
!:O
CD
HI
CD
t;
CI)
.c::
IV
c..n
t:I
n
CD
-=
~
Label
Count
References
n
"tl
0\
SAVEWRK5 000148
c:;
:I:
"
SA VEiRK6 000148
w
...,J
0
SAVEWRR7 000066
til
SA VE iRK8 000229
I.e;
en
rT
CD
e
SAVEiRK9 000116
t'"4
0
I.Q
1-'0
S»
I:'
PI
"tl
H
0
tr
1-1
CD
e
~
CD
rT
(1)
H
•
1-'I:'
S»
rT
1-'0
I:'
en
Q
1-'PI
CD
SA VFPRES
SAVGREGS
SAVKEYS
SAVPSW
SAVTABLE
SCHEDCI
SDRBLOK
SDRBS12E
SDRCTRS
SDRCUA
SDRFLAGS
SDRFLC'I
SDRLNGTH
SDRI1AX
SDROVFWK
SDRPRMCT
SDRRDEV
SDRSHR'I
SDRS1ZE
SDRS1ZEl
SEGPAGE
SEGPLEli
SEGTAELE
SFBCLAS
SFBCOPY
SFBDATE
SFBD1ST
SFBDOMf
000002
000003
000002
000002
000002
000001
000006
000001
000014
000002
000005
000004
000008
000003
000006
000004
000002
000007
000001
000001
000033
000011
000015
000025
000018
000009
000018
000008
DMKCCH
DMKCST
DMKUNT
DMKACO
DMKDEF
DMKVDB
DMKACO
DMKNES
DMKACO
DMKCSP
DI1KSPL
DMKACO
DMKLNK
DMKVCA
DMKCFG
DMKCFG
DMKCFG
DMKCFG
DMKCFG
DMKMCC
DMK10E
DMK10E
DMK10E
D"KIOF
DMK10E
DMK10F
DMK10E
DMKIOF
DMKIOF
DMK10F
DMK10F
DMK10E
DMK10F
DMK10F
DMKBLD
DMKBLD
DMKBLD
DMKCKF
DMKCKP
DMKCKF
DMKCKP
DMKCKS
DMKCDB
DMKCSU
DMKVDB
DMKCCH
DPlKD1A
DMKVDR
DPlKCCH
DMKNET
DMKCCH
DMKCSU
DMKTRC
DMKCCH
DMKN!S
DMKVDB
DMKCDS
DMKDEF
DMKVER
DMKCDB
DPlKDRD
DMKVDS
DMKCFD
DMKNLD
DMKCDB
DMKDEF
DMKVMA
DMKCCW
DMKNET
DMKVDR
DMKCFD
DMKDIA
DMKVMA
DMRCFG
DPlKLNK
DMKVMA
DMKCFG
DMRFGS
DMKCDS
DMRD1A
Dl'IKCFG
DMKLNK
DMKCFS
DMKNES
DMKCKS
DMKNET
DMKCPB
DMKN1D
DMKCQG
DMKPTR
DMKCQP
DMKSEP
DMKCSO
DMKSNC
DMKCSP
Dl'IKTRC
DMKCFM
DMKMSG
DMKVSP
DMKCFS
DMKSEP
DMKCFP
DMRLNR
DMKCFP
DMKNLD
DMKWRM
DMKCKS
DMKTRA
DMKCFS
DMKLOG
DMKCKS
DMKPTR
DMKCQP
DMKSNC
DMKCSO
DMKTH1
DPlKCSP
DMRTRC
DMKCST
DMKUNT
DMKCSO
DMKVCA
DMRCSO
DMKTRC
DMRCKS
DMKMSG
DMKCST
DMKVDS
DMKCPV
DMKNES
DMKDEF
DMKVER
DMRCQG
DMKNET
DMKDIA
DMRVMA
DMKCQP
DMKNLD
DMK10G
DMKiRM
DMKCQR
DMKSEP
DMKLNK
DMRCFG
DMKNLD
DMRVDS
DMKCKS
DMKPGS
DMKVER
DMKCPS
DMRPTR
DMKVMA
DMKCSP
DPIKSEP
DKKCSO
DMKSEV
DI1KDEF
DMKS1X
DMRDGD
DMKSIIC
DMKD1A
DMKTRC
DMKEIG
DMKOIIT
t""I
ll>
tr
CD
1-1
I
c+
0
I
3:
0
PI
DMKCSO
DMRSNC
~
1-1
CD
n
H
0
en
en
!:tI
CD
Ht
CD
H
CD
::;:I
0
CD
DMKIOF
DMKIOF
DMK10F
DMK10F
DMKIOF
DMKCP1
DMKPGS
DMKPGS
DMKCQG
DMKCRS
DMKCQG
DMKCQG
DMKCQG
DMKPGS
DMKVMA
DMKVMA
DMKCQR
DMKCQG
DMKDKP
DMKCSP
DMKDMP
DMKVMA
DMKCSP
DMKCSC
DMKNLD
DMRCSO
DMKDRD
DMKC SU
DMKCSO
DKKSEP
DMKNLD
DMKNLD
DMKDRD
DMKDBD
DKKSPL
DMKSEP
DMKSPL
DMKNLD
DMKNLD
DMKWRM
DMKSPL
DMRVSP
DKKBSP
DKKRSP
DMKSEP
DMKSPL
DKKSPL
DMKVSP
Label
Count
000014
SFBEOF
SFBFILID 000035
~FBFIRST
SFBFLAG
SFBFLAG2
SFBFNAME
SFBFTYPE
SFBHOLD
SFBINUSE
~FBLAS'I
SFBLOK
000002
000090
000032
000012
000003
000011
000013
000036
000067
SFBMISCl 000003
~FBNOHID 000010
SFBOPEN 000007
000012
~FBORIG
000055
SFBPNT
SFBPURGE 000005
SFBRECER 000031
SFBRECNO 000017
~FBRECCK 000003
SFBRECS 0000 1"8
SFBRECSZ 000006
SFBREQUE 000007
SFBRSTRT 000008
SFBSHOLD 000016
~FBSIZE
000037
SFBSTART 000056
SFBTICER 000001
SFBTIM E 000009
SFBTYPE 000014
SFBUHOLD 000018
SFBUSER 000039
CJ:l
CD
0
M-
....
0
t:'
.
SHQBLCK
SHQESIZE
SHQFLAGS
SHQPNT
SHQSHOID
000011
000011
000001
000001
000005
References
DMKCKS
Dl'.IKCKS
DMKWRM
DMKCKF
DMKCKP
DPlKVSF
DMKCKP
DMKCQG
DMKCQG
DMKCSP
DMKCKS
DMKCKP
DMKCKP
DPIKILD
DMKVSP
DMKCS P
DMKCKS
DMKCKP
DMKCKP
DMKVSP
DMKCKP
DPlKCKP
DMKCKS
Dl'.IKCSO
DMKCKP
DMKl/LD
DMKCSO
DMKCKS
DMKCQG
DMKCKP
DKKCKP
DMKRSP
DMKCKS
DMKCQG
DMKCKS
DMKCKP
Dl'.IKSPL
DPlKCKS
DMKCKP
DPlKCS P
DMKCSP
DPlKCQR
DMKDRD
DMKCQG
DMKVSP
DMKCSP
DMKiiRM
DMKCST
DPlKCSU
DPlKDl'.IP
DMKDRD
DPIKIUD
D~KRS
P
DMKSEP
DMKSPL
DPlKVSP
DMKCQG
DMKCQR
DMKCSO
DPlKCSP
DMKCSU
DMKDRD
DMKNLD
DMKRSP
DMKSPL
DMKUSO
DMKCSO
DMKCSU
DMKRSP
DMKVSP
DMKCQR
DMKDMP
DMKCPI
Dr'IKSEP
DMKCSF
DMKNLD
DMKRSP
DMKRSP
tMKSEP
DKKSEP
DMKSPL
DMKSPL
DMKVSP
DKKWRM
DMKCSF
DMKDRD
DMKCQG
DMKSPL
DMKCSU
DPlKNLD
DMKCQR
DMKUSO
DMKDRD
DMKRSP
DMKCSO
DPlKVSP
DKKUSO
DMKSPL
DMKCSP
DPlKWRPI
DMKVSP
DMKVSP
DMKCST
DKKWRK
DMKCSU
DMKDMP
DMKDRD
DMKEDPI
DMKVSP
DMKVSP
DMKCQG
DMKCQG
DPlKWRl'l
DMKCSU
DPlKCQR
DMKNLD
DPlKCST
DMKRSP
DMKCSU
DMKSEP
DKKDMP
DPlKSPL
DMKDRD
DMKEDM
DMKNLD
DPlKRSP
DMKSPL
DKKCSO
DMKNLD
DKKDRD
DPlKRSF
DKKRSP
DPIKSEP
DPIKSPL
DPlKVSP
DMKVSP
DPlKWRPI
DMKRSP
DKKVSP
DMKSPL
DMKSEP
DMKCSO
DMKDMP
DMKCPI
D!H(SFL
DPlKVSP
DMKWRM
DKKSPL
DPlKCSF
DKKDRD
DMKCST
DPlKWRM
DMKCSU
DMKEDM
DMKDMP
DMKRSP
DPlKNLD
DMKDRD
DKKSPL
DPlKRSP
DMKNLD
DMKSPL
DMKRSP
DMKUSC
DKKSPL
DKKWRPI
DKKVSP
DMKDMP
DKKDRD
DMKCQR
DPlKCQG
DMKNLD
DMKNLD
DMKCSF
DMKCQR
DMKSEP
DPlKRSP
DPlKCSU
DPlKCSP
DMKSPL
DPIKSPL
DMKDRD
DMKCST
DMKVSP
DMKVSP
DKKRSP
DMKCSU
DKK SPL
DPlKDRD
DMKVSP
DMKEDl'.I
DMKIUD
Dl'.IKRSP
DKKSEP
DMKCSP
DMKCSP
DPlKSPL
DMKWRPl
Dl'.IKWRM
D~KSPL
DMKCKS
Dl'.IKWRM
DMKCKS
DMKCSP
DMKNLD
DKKSPL
DMKCQG
DMKCKS
DMKCKS
Dl'.IKRSP
DMKSPL
DMKDRD
DMKCPI
DMKCKS
DMKWRM
DPlKSPL
DK-KCKS
DMKCQG
DMKRSP
DMKC1{S
DPIKSPL
DMKRSP
DMKRSP
DMKCQR
DMKCKS
DPlKCKS
DMKCQG
DMKDMP
DPlKCQG
DMKCPI
Dl'.IKVSP
DPlKCQR
DMKCKS
n
."
1:"4
~
t:I"
CD
J-I
I
DPlKCSP
DMKSPL
M0
I
::JI:
0
W
~
j:;:
t:::I
....
11
CD
CD
11
0
0
c+
0
11
....
CD
en
J-I
n
en
en
!:tJ
CD
HI
CD
11
~
~
""'"
CD
t:'
0
CD
.;:
tv
Label
Count
References
n
"'C
CD
c;
::I:
"
w
...,J
0
II
C/)
'<
en
r+
(D
EI
SBQUSER
SHRB P5'I
SHRFPNT
SHBNAME
SBRPAGE
SHRSEGCT
SHRSEGNft
SBBTABIE
SBRTSIZE
SHROSECT
SIGMASK
SILl
000007
000006
000017
000018
000013
000009
000013
000024
000003
000009
000001
000896
~
0
I.Q
.... "
0
III
1:1
Pol
ttl
H
0
0"
......
(D
EI
t::j
(D
r+
(D
H
EI
.... "
1:1
III
r+
.... "
0
1:1
Cil
~
.... "
Pol
(D
SIOCCH
SKIP
000002
000138
Sf!
SPLIRK
SPRITPIG
SPPREPAG
SPRECloe
SPRMISC
SPROFCl
SPSIZE
STARTIPlE
SUSPENI:
SVCNPSii
SVCOPSi
SiPALLCC
SiPCHGl
SiPCHG2
SiPCODE
SiPCYL
SiPDPAGE
SiPFLAG
000022
000009
000023
000013
000015
000002
000003
000012
000011
000006
000008
000034
000006
000006
000006
000003
000009
000006
000074
SiPKEYl
SiPKEY2
SiPPAG
000013
000003
000002
DftKCKS
Df!lKCFG
DMKCFG
DMKCFG
DftKCFG
DPlKCFG
DPlKCFG
DPlKCFG
DPlKCFG
DPlKCFG
DMKDSP
DMKACO
DMKDIR
DMKRSE
DMKVCN
DPlKCCH
DMKACO
DMKIOS
DltKVSP
Df!KCNS
DPlKCKS
DMKCKS
DftKDRD
DftKCKS
Df!KRSP
DftKf!CC
Df!KRSP
DPlKCKP
DMKPlON
DPlKCPI
Df!KPRG
DPlKFTR
DMKCFG
DMKCFG
Df!KPAG
DMKCFG
DftKPAG
DPlKELD
DftKRPA
DPlKCFG
DftKftCH
DPlKELD
DftKCQR
DPlKPGS
DftKPGS
DPlKPGS
DMKCSP
DMKVMA
DMKVPlA
DPlKVftA
~
DPlKSFL
III
tr
(D
......
I
r+
0
DPlKPGS
DftKPGS
DPlKPGS
DftKPGS
DPlKPGS
DPlKVftJ
DMKVMA
DPlKVPlA
DMKVftA
DPlKVftA
DPlKBSC
DMKDf!P
DMKRSP
DftKVDB
DPlKCCW
DMKFMT
DMKSAV
DMKVDR
DMKCKP
Df!KGRF
DMKSFP
DPlKVPlI
DMKCNS
DPlKIOS
DMKSPL
DPlKVSP
DPlKCPB
DMKMCC
DMKSSP
DMKWRM
DPlKCPI
DMKNLD
DMKTAP
DMKCSO
DPlKOPR
DPlKTDK
DPlKDAS
DPlKPAG
DPlKUCE
tMKDDR
DPlKRGA
DMKUCS
DMK tGD
DPlKRGB
DMKUDR
DMKDIA
DMKRNH
DMKVCA
DMKCCW
DMKPIG
DMKCKP
DMKRSP
DMKCNS
DMKSAV
DPlKCSO
DMKSEP
DMKCST
DMKSPL
DMKDAS
DMKTAP
DMKDDR
DMKUNT
DMKDIA
DMKVCA
DltKDMP
tMKVCN
DMKDBD
DMKVtB
DMKFMT
DMKVMI
Df!KCPI
DPlKDRD
DftKDBD
DftKRSP
DPlKRSP
DMKFMT
DMKRSP
DftKRSP
DMKVSP
DMKVSP
DMKIOS
DPlRSFL
DMKVSP
DMKNLD
DMKVSP
DMKPSA
DMKRSE
DMKVIO
DMKVIH
DPlKf!OI
DPlKSPL
DPlKCPI
DMKVSP
DMKCQR
I
tI:
0
Pol
~
......
(D
n
H
0
en
en
!:tI
(D
HI
(D
H
(D
DMKPRG
DPlKPSA
DPlKVMA
DMKCPI
DeKCPI
DftKP'IR
DftKCPI
Df!KPGT
DftKCCW
DMKVMA
DPlKftCH
DMKPTR
DMKVftA
t:I
0
(D
DPlKWRM
DeKPSA
DMKTRC
DPlKTRC
DeKeCH
DPlKPlCH
DMKFTR
DPlKPTR
Df!KPAG
DMKPTR
DftKCDS
Df!KPGS
Df!KPG'I
DMKPTR
DPlKRPA
DPlKCFG
DftKCPI
DPlKDGD
DMKMCH
DftKPGS
DPlKPRV
DMKPTR
DPlKFAG
DIIKPGS
DMKPGT
DMKPRV
DMKPTR
til
CD
0
("i-
I-'0
='
w
Label
Count
References
SiPRECftP
SiPREF1
SiPREF2
SiPSHR
SiPTABLE
SiPTRAliS
SiPV!!
SiPVPAGE
SIBCLOG
SISCIL
SISHRSEG
SISIPLDV
SISLOCS
SISBAftE
SISPAGCT
SISPAGlli
SISPAGNft
SISPNT
SISSEGLN
SISSIZE
SISSTART
SISTBL
SISTEM
000009
000003
000003
000008
000017
000011
000005
000004
000001
000002
000003
000012
000019
000047
000003
000009
000016
000003
000004
000002
000002
000003
000123
SISV1DDR
SISVOL
'lBUSI
TE!!PRO
'lEftPRl
TEftPR10
TEMPR14
TEMPR 15
'lEftPR2
TEMPR3
'lEMPR4
TEftPR5
'lEftPR6
TEftPR7
'lEftPR8
TEftPSAVE
000005
000005
000010
000015
000005
000002
000016
000006
000016
000013
000007
000004
000004
000002
000002
000136
DftKBLD
DftKPTR
DftKPTR
DftKCFG
DftKBLD
DftKCDS
DftKBLD
DftKPGS
DftKCPI
DftKCFG
DftKCFG
DftKCKS
DftKACO
DftKCFG
DftKCFG
DftKCFG
DftKCFG
D!!KCFG
DftKCFG
DftKCFG
DMKCFG
DftKCFG
DMKCFC
DftKIOF
D!!KSHC
DftKCFG
DftKCFG
DftKCPS
D~KCNS
DftKVSP
DftKCCi
DftKCCi
DftKCCW
DftKCCi
DMKCCi
DMKCPI
DMKCPI
DftKHVC
DftKRGA
DftKHVC
DftKCFS
DftKCCR
DftKPGS
DftKPGT
DftKFTR
DftKRPA
DftKVftA
DftKPGS
D!!KED!!
DftKPAG
DftKED!!
DftKPTR
DftKPRV
DftKPGS
DftKPTR
D!!KPGS
DftKVftA
DftKPTR
DftKVJ!A
DMKRPA
DftKVftA
DftKRPA
DMKV!!A
D!!KVftA
DMKCPI
DftKBLD
DMKDMP
DftKCFS
DMKHVD
DftKCFT
DMKIOG
DftKCKP
DMKWRM
DftKLOC
DftKLOG
DMKUDR
DftKUSO
DftKCFG
DftKIOG
DMKSPL
DftKCKS
DftKMCC
DMKSSP
DftKCNS
DMKNLD
D!!KUDB
D!!KCPE
DMKPSA
DMKVCH
DMKCPI
DMKPTR
DMKVSP
DMKCPV
DMKRGA
DMKiRft
DMKCSO
DMKRGB
DMKCST
DftKRNB
DMKftCC
DftKCPI
D!!KMON
DMKVCA
DftKVSF
DftKCDS
DftKCDS
DftKCPI
DMKCPI
DMKCSU
DftKVCA
DftKCPI
DMKCPI
DMKCSP
DftKCSU
DMKSAV
DMKIOS
DftKFRG
DftKCSU
DftKBGA
DMKVCA
DMKSAV
DMKVCA
DMKVCA
DMKDRD
DMKRPA
DftKERft
DMKRSP
DMKGRF
DftKSEP
DftKPRG
DMKRGA
DftKRGB
n
It:!
t-t
III
tr
CD
I-'
DftKCNS
DftKRGA
DMKCPI
DMKRGB
DMKCQR
DMKRRB
DMKCVT
DMKSA V
DftKFRE
DftKSCH
DMKGRF
DMKVIO
DMKLOG
DftKMID
DftKNET
DftKNLD
DftKPRV
t
("i-
0
t
::.:
0
PI
c::
I-'
'='
1-'-
CD
I'i
CD
0
(')
("i-
0
H
1-'CD
C/l
H
0
en
en
!:tI
CD
HI
CD
H
.;=
CD
='
tV
0
\0
CD
~
w
Label
Count
Heferences
n
1'0
0
c::
IZ
"w
-..J
0
til
'<
en
r+
(1)
•
t-'
0
I.Q
"".0
I»
I:'
p.,
ItJ
H
0
t:r
......
CD
•
t:I
(I)
r+
CD
H
•"".
I:'
I»
r+
"".0
I:'
Cil
c:
"".
~
(I)
TEHMSYS
'lIMER
TIOCCH
'lISCPIDN
TISDEVAD
'lliSKEYli
TNSREC
'lNSSNS1
TNSSWS3
'lliSVCLID
TODATE
'lRACBEF
THACCURR
'lRACEFLG
TRACENt
'IHACFLGl
TRACFLG2
'IRACSTRT
TRACOA
'IRACOC
TRACOD
'IHACOl
THAC02
'lHAC03
TRAC04
'lHAC05
TRAC08
'I8AC09
THAC10
'IRAC 11
TRAC67
'IRAIUWDE
TREXAI:I:
'IREIAISI
TREXBRAN
'IREXBUFF
TREXCCW
'IHEXCH9
TREXCSW
'IREICTI
TREXCTL 1
'IREICTI2
000009
000021
000012
000002
000024
000005
000006
000006
000018
000004
000013
000003
000040
000006
000020
000011
000008
000021
000001
000001
000001
000001
000002
000002
000001
000001
000001
000001
000001
000001
000002
000020
000004
000005
000012
000004
000006
000003
000006
000004
000002
000007
DMKCCB
D!KCPI
DMKCCB
DMKIOE
DMKIOE
DMKIOE
DMKIOE
D!KIOE
DMKIOE
D!KIOE
DMKCPI
DMKCIS
DMKCNS
DMKCPI
DMKCNS
D!KFHE
DMKCNS
D!KCNS
DMKDSP
D!KI:S P
DMKVIO
D!KPSA
DMKPSA
DMKFRG
DMKMCH
DMKIOS
DMKSCH
Dl!KSCH
DMKDSP
Dl!KBNB
DMKFRE
DflKCDS
DMKPRG
Dl!KPGS
DMKTRA
DflKTRC
DMKTRA
Dl!KtS P
DI!K'IRA
DMKTRA
DMKTRC
DMKT He
DMKEIG
DMKDSP
DMKEIG
DMKIOF
DMKIOF
tMKIOF
DMKIOF
D!KIOF
DMKIOF
D!KIOF
DMKCYT
DMKIOS
DMKCPI
DMKMCC
DMKCPI
DMKIOS
DI!KDSP
DMKCPI
DMKSEV
DMK lOS
DMKSEV
D!KSIX
Dl'!KMCH
D!KSIX
DMKPHG
DMKPSA
DMKPTR
1:"'4
I»
b"
CD
Dl'!KSCH
......
I
r+
0
I
3:
0
p.,
c:
......
(1)
D!KDMP
DMKVIO
DMKDSP
DMKED!
tMKMID
Dl!KFHE
DMKIOS
tMKMCC
Dl'!Kl'!CB
tMKPRG
DMKPSA
DMKRNB
DMKSCB
DMKDSP
DMKMCH
DMKIOS
DMKDSP
DMKFRE
DMKPHG
DMKBiH
DMKFRI
DMKIOS
DMKPSA
DMKVIO
DMKIOS
DMKMCB
DMKSCB
DMKPHG
DMKPSA
DMKHNB
DMKSCH
DMKYIO
DMKMCC
DPlKMCB
Dl'!KPRG
DPlKPSA
tPlKRliB
I:MKSCH
n
H
DIH
o
rt
o
....
t1
n>
en
I
---------------------------1
controlling sUFervisor task and to-I
This routine is the
gether with DBTCftX, DBTftGX, DftTSYS, Dft7COft, DftTftSG, andl
DftTCRE make up the REX supervisor task.
I
Performs the initialization for the DftTREX task.
I
ftonitors a list of synch locks when looking for work fori
DftTBEX to perform.
I
Processes program checks.
I
Entered when RSCS initialization fails. Issues the in-I
itialization failure message, dumps the contents of mainl
storage, types any remaining messages, and loads a diS-I
abled wait state PSW.
I
Scans the function table and calls the aFFropriatel
routine based on that code (either DftTCftX or tftTftGX).
I
Deactivates the link tatle entry.
I
Writes messages.
I
Terllinates a specified task.
I
Becemes the task code for a task in the Frocess ofl
termination. Looks for any outstanding I/O for the
terminating task.
If any outstanding I/O is found,
issues HIO and waits for completion. When all I/O is
completed, it termin-ates the task.
DftTSIG
Performs a task alert exit for a requesting task.
DMTSML
DftTSML
Functions as an RJE work station into a remote system
using the MULTI-LEAVING transmission protocol.
It can
also function as a host to a remote Frogrammable work
station supporting a System/370, System/3, Model 20,
1130, or a 2922.
Initializes various parameters needed by DMTSftL. Saves
the link table address, initializes output tags, and
constructs the sign-on card from information in the
operand field of the START command.
Perforas the enable sequence on the communications line,
analyzes the response received, and, if the resFonse is
correct, writes the line connected message •
This is the alert exit entered by DftTSIG. Two tasks may
alert this line driver:
•
DMTBEX--When a command has been entered fer pro-I
Processing by the DftTS!L line driver.
I
• DftTAXS--When DftTAXS must asynchronously notify
I
DftSftL that a file has arrived for transmission.
I
ISIO
o
....rt
Function
DMTSIG
SMLINIT
n>
I
ASYIEIIT
----I
r-I Module
I Name
D~TS~L
Entry
Foints
&START
(cont.)
&CTRNl
&FBTN1
&URTNl
&JRTll
&USREXIT
&PRTNl
AXSGET
V~DEBLOK
BEADPREP
TODEECt
&iRTNl
CMDPROC
I
I
I
I
I
I
l
MSGPROC
Function
------------------------------------
This is the supervisor routine for DMTSML. The co •• utater cycles while looking fer a routine to enter until
all co.mutator entries are closed. It then waits for a
synch lock list to be posted.
Dequeues tasks from its task queue and performs the
action requested by the control record in the degueued
task.
Dequeues tasks from its task queue, obtains a new output
spoel device, if needed, fro. DMTAXS, and sends the task
to a virtual printer.
Dequeues tasks from its task queue, obtains a new output
spool device, if needed, from DftTAXS, and sends the task
to a virtual punch.
Dequeues tasks from its task queue, obtains a new output
spoel device, if needed, from DftTAIS, and sends the task
to a virtual device.
Validates the ID card in the front of decks read in from
a remote card reader.
Reads in files from the VM/370 spool file syste.,
deblocks the files into 132 byte records, and issues
a call to PUT to block the record into a transmission
buffer.
This routine is the interface to DMTAIS.
It gets files
ready to transmit and purges these files when transmission is co.~lete.
This is the deblock routine for the Vft/370 Fage spool
buffers. It returns the deblocked record in
the
RDTTDTA1 buffer.
provides, one record after the other, the separator and
header for print files and the header card fer punch
files.
Converts System/370 TOD to EBCDIC data and time.
writes received messages to the RSCS operator, if in
RJE mode.
Passes commands to DftTREI for execution, if
in BOST mode. These commands or messages are dequeued
from console TCT.
Executes commands passed to it in the CfttRESP buffer
after an alert from DMTREI indicating a ce.mand was
entered.
Entered when the MSGECB is posted by this task's asynChronous exit indicating messages are in the message queuel
for this task. These messages are unstacked frem the I
message queue by repeated calls to GftSGREQ and queuedl
for transmission.
I
r---------------------------------Entry
I Module
I
Name
DMTSML
(cont. )
Points
MSG
&TPGET
COMSUP
CERROR
DMTSTO
Reserves pages of free storage for use by calling task
programs. Task programs free storage pages by clearing
the associated map byte to zero in the main storage map.
DMTSVC
DMTSVC
This module is the MSOP interrupt handler and receives
control directly when an SVC interrupt occurs.
DMTSYS
DeTSYS
DMTVEC
DeTVEC
DMTWAT
D"TWAT
The common system control information area that is
shared by all task level functions of RSCS.
All instal-I
lation variable informaticn used by an RSCS system isl
reflected in the assembly of this module. This modulel
is the only module that must be assembled as part of ani
RSCS system generation.
I
Describes the fixed address stcrage utilization fori
MSOP, beginning at main
storage
address
X'200'.1
System/370 architecture defies the first 512 bytes ofl
main storage and MSOP uses this area as it is defined. I
This area is not included in the DMTVEC module tol
facilitate initial system loading. This area is ini-I
tialized by DMTIB I at IPL tim e.
I
I
Called directly from task prcgrams by a EAL instruction. I
It ~rovides event synchronizaticn by means of suspendingl
a task's execution until some specified event is sig-I
naIled complete by another process in the syste..
I
tn
CD
r+-
1-'-
o
::s
1-'-
t;
CD
n
c+
o
t;
1-'CD
Ul
to writes messages on the operator's console.
I
Scans lines and tests for delimiter characters.
I
Takes a line and packs it into a teleprocessing buffer. I
When the buffer is filled, it is queued onte OOiBOF fori
processing by COMSOP.
I
Deblocks received telecommunications buffers into tasksl
and queues the task onto the appropriate processors I
TCTTASK queue.
I
Processes all I/O on the communications line.
It deque-I
ues TP buffers from OOTEU! for transmission and queuesl
received TP buffers onto the &IREOF queue for deblocking I
by TPGET.
I
Analyses all errors on the communications line. The appropriate corrective action is taken depending on the
on the type of error.
DMTSTO
n
t:1
I
I
Function
----------------------------------------------------------------1
Prepares and sends requests to the specialized task REX I
PARP-GET
&TPPUT
.w
I
_______________---J
11:0
ItIl
llodule
External References (Labels and llodules)
DllTAKE
ACTIVE
DISPATCH GIVEADDR GIVEE
R12
R14
R13
R15
TASKIUllE TASKiEXT TASKQ
TGREGl
GIVENAME GIVENEI7 GIVENID
R4
R2
B3
TGREG1S TREQLOCK
ACTIVE
IOEXITQ
R13
TAREA
ALERTQ
IOID
R14
TASKE
DISPATCH
lONE IT
R1S
TASKID
FREEE
LIllEC
R3
TASKiEXT
ACTIVE
Rl
TGREG1S
ALERTQ
R12
ASYNCODE ASYNE
R14
B13
ALEBTIlEQ
LACTIVE
POSTBEQ
R1S
SFBFILID
SFEUHOLD
TAGINTOD
TASKE
ASYBBEQ
LACTTNllE
PBCGADDR
B2
SFBFLAG
SVECTORS
TAGINVll
TASKSAVE
COfilDSECT
LALERT
ROUTDEST
R3
SFBFLAG2
TAG
TAGLEB
TCOfil
CSi
LFLAG
ROUTE
R4
SFBFNAfilE
TAGELOCK
TAGLINK
TLINKS
DE
LINKID
ROUTNEIT
RS
SFEFTYPE
TAGCLASS
TAGNAfilE
TROUTE
DEVCODE
LINKLEN
BCUTSIZE
R6
SFEINUSE
TAGCOPY
TAGREIT
TTAGQ
DEVCUU
LINKTABL
RO
R7
SFELOK
TAGDEV
TAGPRIOR
TYPPRT
GIVEREQ GLINKREQ GPAGEREQ
LPEBDIBG LFOINTEB LRESERVD
III
Rl0
Rl1
R8
R9
SFECLAS
SFEORIG SFERECNO SFBRECSZ
7AGDIST TAGFLAG TAGFLAG2
TAGRECLN TAGRECNft TAGTOLOC
7IPPUR
TYP1403 TIP2540P
tllTCfilX
ALERTREQ
LACTClSl
LIIKIEi
R11
SFESHOlD
TAGLIRK
COfilDSECT
lACTDRVR
lINKTAEL
R12
SFEUHOLD
TAGNAftE
DEVCODE
LACTIV!
LPFllDIIG
R13
SVECTORS
TAGREIT
DEVCUU
LACTLINE
LPOINTER
R14
TAG
TAGPRIOR
DftTCBE
LACTTRllE
LRESERVD
R1S
TAGELOCK
TAGBECNfiI
DliTCREDA
LDEFCLS 1
LTAKEN
B2
TAGCLASS
TAGTOLOC
DftTfilGI
L£EFDRVR
LTRALL
R3
TAGCOPY
TAGTOVM
DfilTREICI
LDEFLIRE
LTRERR
R4
TAGDIST
TCOft
DfilTREIID GLINKREQ GTOD!ECD
LDEFTNfilE LDRAIH
LFLAG
LHCLD
filAIBfilAP ~AINSIZE BO
Rl
RS
R7
R6
R8
TAGFLAG TAGID
TAGIBLOC TAGINTOD
TLIHKS
TPORTS
TTAGQ
IOTABLE
LIIKID
Rl0
R9
TAGIRVM
DfilTCOll
ACTIVE
DISPATCH LACTTlHll LIBKID
R11
R12
R13
B14
SVECTCBS TAREA
TASKE
TASKID
filAINfilAP
R4
TGREGO
ftAIHREQ
RS
TGREG 1
Rl0
R9
TPSi
In
Itil
DMTASK
DfilTASY
DllTAIS
!XTQ
IOSUBQ
R2
TASKNAfilE
FREEID
filAINfilAP
R4
TASKQ
ASYNEXIT ASYNID
R1S
R2
FREENEIT
filAINSIZE
RS
TASKSAV!
GIVEQ
RS
GIVE RID
R6
PCSTREQ QREQ
SVECTORS TAREA
GIVEADDR
filPIIOQ
B6
TASKSTAT
GIVEE
POSTREQ
R7
TGREGO
GIVENEIT
QREQ
B8
TGREG13
ASYNNFIT ASYNTASK DISPATCH EITQ
R4
R3
SVECTOIlS TAREA
LINKLEB LINKTABL LMSGQ
R2
R3
R1S
TASKNAllE TASKNEIT TASKQ
13
Rl
TASK!
R11
TASKID
GIVEBID
RO
B9
TGREG1S
GIVBQ
Rl
SBLIOQ
IOE
I
1t-3
R12
10
SVBCTORS I
IOEXITQ
TASKE
QREQ
TASKID
GTODEBCD
LSPABE
R12
SIBCOPY
SFBREQUE
TAGID
TAG TOVll
TYP3211
Itj
Ie:
It"t
ItIII
1t'"4
I~
IOTABLE
LTAK!N
R13
SFEtATE
SFBSHOLD
TAGINDEV
TAGTYPE
iAITR!Q
D~TBEIHC
llAIHSIZE RO
R6
II7
TGREG1S TGREG2
10
Rl
R8
TLIRKS
RO
TGREGO
ItEI
1t:ri2
It"t
In
11:0
10
LACTCLSl len
llAINftAP ItIl
R14
11:0
SFEDIST ItIII
II'ld
SFETYPE Itill
11:0
TAGINLOC ItzJ
TAKEREQ 1!Zl
In
leu
1:0
til
n
en
::I:
0
Q.
til
....c:
CD
0
CD
0
t:S
0
....t+
w
I
t+
I
t'"4
III
tr
....t:::I
11
CD
0
t+
0
11
....
CD
en
.&::'
0\
lJ1
....CD
n
11
0
en
en
1:0
CD
HI
CD
11
CD
t:S
0
CD
~
'"'"
Module
"
w
~
til
n
til
ENDCSW
R15
TGIlEGO
IOREQ
R2
TGREGl
IOTABLE
R3
TGBEG2
LACTDRVR LACTTNME LINKTABL MAINMAP
B4
B5
116
B7
TYP2314 WAITBEQ
ACTIVE
TASKID
lIMBe
LOCKLIST NEWPSW
BO
Bl
TASKNEXT TASKQ
TASKSAVE TASKSTAT TGBEGO
R15
TGBEGl
R2
'lPSi
R3
WAITING
R4
ACTIVE
R14
ASYNCODE ASYNE
1115
R2
NEWEXT
TASKE
OLDEXT
BO
TASKS AVE TGRlGO
Bl
TGREG14
UITGIV
ACTIVE
R12
TASKC
GIVENAME GIVENEX'l GIVENID
DISPATCH GIVEADDR GIVEE
B4
113
R14
B15
B2
R13
TASKSAVE TGIlEG15 TREQLOCK
GIVEQ
GIVEBID
SVECTORS TABEA
POSTBEQ
TASKE
QIlEQ
TASKID
BO
Rl
TASKNAME TASKNEXT
tMTINI
CAW
DMTMAPCE
OLDIO
B4
TASKSAVE
CC
DMTREXVL
QBEQ
B5
TASKSTAT
CE
FREEE
QUEUE
R6
TIMER
CLASDASD
FREEN EXT
BO
B7
TYP2314
CLASTERM
FBEEQ
Rl
B8
TYP3210
CSW
IOTABLE
Rl0
B9
TYP 3330
DE
IPLCCW 1
R 11
SILl
TYP3340
tEVCODE
IPLPSW
B12
SVECTORS
iiIT
DEVCUU
MAINMAP
B13
TASKE
DISPATCH
MAINSIZE
R14
TASKID
DMTCBEDA
MCHEK
B15
'lASKNAME
tMTIOMIN
NEWEXT
R2
TASKNEXT
tMTIOM
ACTIVE
DISPATCH
IOTABLEA
R15
TABEA
ASYNCODE
ENDCSW
MPXIOQ
R2
TASKE
ASYNE
ENDSENS E
NEWIO
R3
TASKlt
ASYNEXIT
IOADDB
OLDIO
B4
TASKSAVE
ASYNNEIT
IOE
PCI
B5
TGREGO
ASYNTASK
IOEXITQ
POS'l'REQ
R6
'lGBEG14
BUSY
IOID
PROGADDB
SELIOQ
TPSi
CAW
ION EXT
QREQ
SENSING
UC
CE
IOSBCHAN
BO
SENSREQ
tMTLAX
ASYNREQ
B2
WAITREQ
CLASTERM LACTIVE
B3
R4
LINKID
B7
LIRKLEN
R8
LINKTABL RO
Rl
B9
SVECTORS TLIRKS
IMTMGX
ALERTREQ COMDSECT DMTMSG
Rl0
B12
B13
SVEC'lOBS TCOM
TLINKS
DMTNPT
ASYNBEC
LDRAIN
Rl
R8
TAGINTOD
TYFFUII
BUSOUT
LERRCNT
B10
R9
TAGINVM
TYP2700
CC
LPLAG
Bl1
SILl
TAGLIBK
TYP3210
CMDREJ
LHOLD
R12
SKIP
TAGNAME
UC
COMDSECT
LIRKID
R13
SPLINK
TAGBEXT
UE
IMTPST
RO
Rl
R14
TASKE
TASKSTAT WAITING
DMTQRQ
PBEEE
PBEEID
PREENEXT FREEQ
DMTCRE
<
3:
External References (Labels and Mod ules)
DMTDSP
....,J
CC
CE
MAINSIZE RO
SILl
SICCCND
CUE
DE
R1
R12
SVICTORS TABEA
DEVCOD!
R14
TASKBEQ
SVECTOBS TABEA
MAINREQ
R9
TASKE
til
(t)
EI
I.Q
.....
ASYNEXIT ASYliNEXT ASYNTASK DISPATCH EXTQ
SVECTOBS 'lAREA
R4
SSAVE
R3
B13
TPSW
I»
t::I
0-
.....
(t)
EI
t:I
rr
(t)
H
EI
.....
t::I
I»
~
.....
0
t::I
en
I»
t:r
(t)
.....
n
H
DMTMAPME
NEWIO
R3
TASKQ
en
en
!:tI
(t)
HI
(t)
H
(t)
0
t:r
(t)
I
~
0
(")
I'd
H
I
~
'<
1:"4
0
.....
(t)
0
DMTEXT
rr
0
0!:i
0
en
3:
!:i
.....
0(t)
LACTLINE LPLAG
R5
R6
DMTREXHC GIIBKREQ LACTIVE
B14
R15
B2
Rl
EQCHK
LIRKTAEL
B14
SPRECNUM
TAGBECNM
WAITREQ
R14
CHAliDONE
IOS'lAT
Rl
SIOCOND
CSW
IOSUBQ
B12
SM
DE
IOSYNCH
R13
SSAVE
DEVCUU
IOTABLE
R14
SVECTOBS
1112
TPORTS
B14
TYPBSC
R15
TYP2700
LACTTRME LPLAG
B3
B4
LIRKID
RS
LINKTABL PMSGREQ
B6
R7
RO
R8
Rl
R9
GIVEREQ
LTOCNT
R15
SVECTORS
TAGTOLOC
GMSGBEQ
LTBALL
B2
'lAG
TAGTOVM
GPAGEREQ
LTREBB
R3
TAGDEV
TASKE
GTODEBCD
LTRIIS'CRT
R4
TAGDIST
TASKSAVE
IOBEQ
POSTBEQ
R6
TAGIBDEV
TLINKS
LACTLIBE
RO
B7
TAGIRLOC
TYPPRT
R15
SVECTORS
INTREQ
FMSGREQ
R5
TAGID
'lCOM
t::I
(")
(t)
f!odule
External References (Labels and Modules)
DMTREI
ACTIVE
DMTSYSND
IOTABLEA
LOCKLIST
R15
TASKNAME
TPORTS
DMTSIG
ATTN
DMTSISRT
LACTIVE
MAINSIZE
R3
TASKQ
TVECTORO
COMDSECT
DMTSYSTQ
LACTLINE
MPXIOQ
R4
TASKREQ
TIP3210
ALERTQ
ACTIVE
SVECTORS TAREA
ASYNE
TASKE
ASINEXIT ASINNEIT ASYNTASK DISPATCH RO
TASKNAME TGREG15 TGREG2
tMTSML
ASINREQ
IOTAELE
POS'IREQ
R5
TAGID
TLINKS
CC
LACTLINE
PROGADDR
R6
TAGINDEV
TIPPBT
CCC
LDRAIN
RO
R7
TAGINLOC
TYPPUN
CD
LERRCNT
Rl
RS
TAGINTOD
TYP2700
COMDSECT
LFLAG
Rl0
R9
TAGINVM
TYP3210
DEVCUU
LHOLD
Ell
SILl
TAGLINK
UC
ENDCSW
LINKID
R12
SKIP
TAGNAME
UE
DMTSTO
ACTIVE
TASIUD
DISPATCH MAINMAP
TGREG1
TGBEG15
RO
Rl
R14
tMTSVC
ACTIVE
TGREGO
NEWPSW
TGREG13
OLDSVC
TPSi
HO
B13
DMTSYS
LINKIED
BOUTSIZE TAGLE!
tMTVEC
DMTAKE
DMTWA'I
DMTASK
DMTDSP
D5TGIV
DMTIOMRQ DMTMAPMS tMTMAPQE D5TMAPQU DMTPST
tMTWAT
ACTIVE
DISPATCH LOCKLIS'I Rl
TASKS'IAT WAITING
R14
B15
ASYNBEQ
DMTSISPT
LACTDRVR
MAIN MAP
R2
TASKNEIT
TPSW
NEiSVC
TGBEG14
DMTASY
CSi
ENDCSi
LACTTNME
NEiPBOG
R5
TASKSAVE
UE
DEVCODE
GMSGREQ
LDEFDRVR
CLDPROG
SELIOQ
TASKSTA'I
WAITING
DEVCUU
IOADDR
LFLAG
POSTREQ
SILl
TCOM
WAITREQ
DISPATCH
IOE
LHALT
PROGADDR
SSAVE
'IGREGO
Df!TC1'lX
IOID
LIMBe
RO
SVECTORS
TGREG12
D5TCCMVC
IONEIT
LINKID
Rl
TAKEREQ
TGREG13
DMTCRE
IOREQ
LINKLEN
R12
TAREA
TGREG2
tMTMGI
IOSINCH
LINKTABL
R13
TASKE
TGREG4
DMTSYSLK
IOTABLE
L5SGQ
R14
TASKID
TLINKS
RB
R14
R15
R2
R3
GIVEREQ
LINKTABL
R13
SPLINK
'IAGRECNM
i AITREQ
GMSGREQ
LTOCNT
R14
SPRECNUM
TAGTCLOC
GPAGEREQ
LTRALL
R15
SVECTORS
TAGTOVM
GTODEBCD
LTRERR
R2
TAG
TASKE
IOREQ
LTRNSCNT
R3
TAGDEV
TASKSAVE
IOSINCH
PMSGREQ
R4
TAGDIST
TCOM
R15
R2
R3
R4
SVECTORS TAREA
R14
E15
SSAVE
SVECTORS TABEA
R2
R3
R4
R5
TASKE
TASKE
TASKSAVE
DMTQRQ
DMTSIG
DMTSTO
R6
SVECTORS TASKE
~
til
(')
til
3
til
(I)
0
0.
....
C
0
r+
(I)
1:1
r+
0
1-'0
.
I
I
W
~
~
tj
....
1-'1'1
t:1'
(I)
(I)
(')
0
r+
0
1'1
1'1
0
1-'(I)
en
en
en
~
(I)
HI
(I)
~
1'1
(I)
0\
I:'
.,.J
0
(I)
Label
count
Beferenct=.:.
ACTIV!
000030
ILEBTQ
ILEBTBEQ
ISYICOIE
ISYIE
ASYIEXIT
lSYIID
ASYIIEIT
000003
000005
000004
000011
000005
000002
000011
000006
000006
000001
000001
000001
000006
000087
000001
000001
000004
000004
000001
000005
000001
000006
000026
000001
000006
000013
000008
000015
000001
000001
000001
DftTIKE
DeTilT
DftTISK
DeTIIS
DftTISY
DeTASY
DftTISY
DI!TASY
DftTISY
DI!TAXS
DftTISY
DftTBEX
DftTIPT
DeTIOft
DftTIII
DeTCBE
DftTSPlL
DeTSI!L
DPlTCBE
DI!TIOI!
DftTIII
DI!TIII
DftTIPT
DI!TIXS
DftTIXS
DI!TCRE
DftTIXS
DI!TAXS
DftTIXS
DftTAKE
DftTVEC
DftTVEC
DftTVEC
ISYIBE~
ASYITASK
ITTI
EOSOOT
BUSY
CIW
CC
CCC
CD
CE
CHIIDCIiE
CLISDASD
CLISTEBI!
CfttBEJ
COftDSECT
CSW
CUE
IE
DEVCODE
IEVCUU
DISPITCH
IftTIKE
DftTISK
tftTASY
I!XI
M
In
len
DftTISK
DeTISY
DeTcce
DftTISY
DeTCftl
DftTEXT
DeTEXT
DftTEXT
DftTSIG
DPlTftGX
DftTIOft
DftTIOft
DPlTIOft
tftTSIG
DeTSIG
DI!TEXT
DPITLAX
DftTEXT
DPlTIOft
DeTIPT
DPlTIOft
DPITSIG
tftTBEI
DPITSIG
DeTDSP
DPITEIT
DeTGIV
tPlTIOPl
DeTBEI
DPITSIG
DPITSTO
DPlTSVC
II:""
1>1tJ:!
ItzJ
IL-'I
I
I~
10
I
13
10
I~
Ie:
IL-'I
It:o€I
DPlTSftL
In
I!XI
10
IUl
IUl
DftTIOI!
neTI))I
DeTIPT
DPITINI
DPlTIOPl
teTseL
I!XI
ItIEl
II'll!
It:o€I
I!XI
ltv
12:
In
ItIEl
DeTLAX
DftTCftX
DPlTIII
DI!TftGX
DftTIOft
tftTIPT
DftTBEI
DeTREX
DftTSftL
DI!TCBE
DftTCI!X
DftTCftl
DeTASK
DeTIII
DI!TCB!
DftTIII
DftTASY
DftTICI!
tftTIII
DftTICft
tftTCOe
DftTBEX
DeTBEX
DeTEXT
DI!TSftL
DftTGIV
Dft'IIII
DPlTICft
DPITBEX
DPITSIG
DftTSTO
DPlTWIT
!XI
Ul
n
Ul
L-'I
l»
Ul
CD
0
r+
"""
t:S
0
W
~
"""
1'1
e;,"
CD
~
I
r+
0
I
3
0
~
c:
~
CD
0
n
1'1
0
1'1
en
CD
r+
0
CD
"""
[/)
~
0\
\D
[/)
!XI
CD
HI
CD
1"1
CD
t:I
0
CD
-=
...,J
Label
count
References
DKTCtU
IKTCOKVC
DKTCRE
IKTCRltA
DKTDSP
IKTGIV
DKTIOKHI
DKTIOKRQ
DKTfIlAPeE
tKTftAPKS
DKTKAPQE
DKTIUPCU
tKTfIlGX
DKTKSG
tftTPST
DftTQRQ
I:KTREXCH
DftTREXHC
tftTREXID
DftTREXYL
IftTSIG
DftTSTO
DftTSISLK
D!lTSISllD
tftTSISPT
DKTSISRT
tftTSISTQ
DftTiAT
EIDCSW
EIDSERSE
EQCBK
EXTQ
FREEE
FREEID
FREEHEXT
FREEQ
GIYEADtR
GIYEE
GIYEBAKE
GIVEHEIT
GIVEBlt
GIVEQ
GIVEREQ
GIVERID
000001
000001
000003
000003
000001
000001
000001
000001
000001
000001
000002
000001
000010
000001
000001
000001
000001
000004
000001
000001
000001
000001
000001
000001
000001
000001
000001
000001
000014
000001
000001
000004
000008
000002
000009
000005
000004
000013
000003
000014
000005
000005
000018
000002
DKTEEX
DKTREX
Dl!TCKX
DKTCKX
DKTVEC
DKTVEC
Dl!TIHI
DKTVEC
Dl!TINI
DKTVEC
DKTINI
DKTYEC
DKTCftX
DKTeGX
DftTVEC
DftTYEC
DftTCftX
DKTCKX
DflTCftX
DKTIHI
DftTYEC
DKTYEC
DftTREX
DKTEEX
DftTREX
DKTEEX
DKTREX
DftTYEC
DflTCRE
DKTIOfl
DftTHPT
DKTASK
DflTASK
DKTASK
DftTASK
DKTIBI
DftTAKE
DKTAKI
DKTAKE
DPlTAKE
DftTAKE
DKT AKE
DfilTAXS
DKTAKE
!%I
til
n
0
c:
:I:
"
w
...,J
0
til
'<
til
ri"
(1)
B
tr
0
I.Q
!J.
n
I»
t:J
s:lI
~
tot
0
tr
....,
(1)
B
0
(1)
ri"
(1)
tot
•
!J.
t:J
I»
ri"
!J.
0
t:J
en
c:
!J.
p..
(I)
til
t"'I
~
Dl!TREX
DKTIHI
tr'
....,
(1)
,
0,
rio
:I:
0
p..
I:l
....,
DKTVEC
(1)
n
DftTREX
tot
0
til
til
~
tttttttt tttttttt
(all others)
tttttt
vvvvvv EX xxxxxxxx zz vvvvvv mnem xxxx xxxxxxxx
For an executed instruction, where zz (see preceding explanation of
symbols) is nonzero, the mnemonic for the executed instruction is given
as if the zz byte had been put into the instruction with an OR
opera tion.
vvvvvv mnem xxxxxxxx xxxx
506
VM/370: system Logic and Problem Determination Guide
vvvvvv mnem xxxxxxxx
***
vvvvvv iot code
!LQ
!~1EBBgR%!g~
==)
==)
tttttt
tttttt
(First line given only if "CSW" vas specified):
CSW V vadd xxxxxxxx xxxxxxxx R radd yyyyyyyy yyyyyyyy
*** vvvvvv I/O vadd ==) tttttt CSW xxxx
~B!~fB IBA£~:
(ALL option selected)
Entry for 'branch from' instruction
vvvvvv mnem xxxxxxxx
tttttt
Entry for 'branch to' instruction
==)
vvvvvv mnem xxxxxxxxxxxx
section 4. Diagnostic Aids
507
CP real machine debugging is reserved for Class C users (system
programmers) and Class E users (system analysts). CP has facilities to
examine data in real storage (via the DCP and DMCP commands) and to
store data into real storage (via the STCP command).
There is no
facility to examine or alter real machine registers, PSW, or storage
words.
Remember, real storage is changing even
to examine and alter it.
as you issue the CP commands
system programmers and analysts may also want to use the CP internal
trace table. This table records events that occur on the real machine.
508
VM/370: System Logic and Problem Determination Guide
Use the DCP command to display the contents of real storage locations at
the terminal.
If an invalid operand is entered, the DCP command terminates.
However, any previous valid operands are processed before termination
occurs. The format of the DCP command is:
r
---------------------~
I
I DCP
1
1
I
1
1
1
1
1
1
1
1
1
1
I
I
I
1
1_______ _
L
Lhexloc1
Thexloc 1
hexloc1
r
r
"
L
.I
I
I
r
,
I
I~!Q
L
L.I.I
ILhexIOC111{-}1 hexloc2 I 1
1Thexloc 11 1 : 1 ~!!.Q
1 1
1 hexloc 11 1
L
.I
1
.Q
11
1
1
I{. lIbytecount I
1
I
1
I I
,
1 hexloc21
1 lHH!
1
L
,r
specifies the first storage location to be displayed. If
hexloc1 is the only operand, it specifies the only storage
location to be displayed.
If hexloc1 is not specified, L
or T must be specified and the display begins with storage
location o.
If hexloc1 is specified and L or T is not
specified, the display is in hexadecimal.
T specifies
that an EBCDIC translation is to be included with the
hexadecimal display. L specifies that the display is to
be in hexadecimal only.
If hexloc1 is followed by a
period and is not on a fullword boundary, it is rounded
down to the next lower fullword.
o
r
r
.I
specifies that a range of locations is to be displayed.
To display
the contents
of one
or more
storage
locations by specified storage address location the "-"
or ":" must be used. The hexloc2 operand must be 1- to
6-hexadecimal digits;
leading zeroes
need not
be
specified.
In addition, The hexloc2 operand must be
equal to hexloc1 and it should not exceed the size of
real storage.
If END is specified,
real storage from
hexloc1 through the end of real storage is displayed.
If
hexloc2 is not specified, END is the default. Note that
this occurs only if "-" or ":" follows the first
operand.
,
{.}Ibytecountl is a hexadecimal integer designating
the number of
I ~!~
1 bytes of real
storage
(starting with the
byte at
L
.I
hexloc1) to be displayed on the terminal. The sum of
hexloc1 and the bytecount must be an address that does
not exceed the size of real storage.
If this address is
not on a fullword boundary, it is rounded up to the next
higher fullword.
The bytecount operand must be a value
of 1 or greater and may not exceed six hexadecimal
digits.
Section 4. Diagnostic Aids
509
Normally, a user will or should define the
locations of storage in the following manner:
dcp
dcp
dcp
dcp
dcp
beginning
and
ending
Lhexlocl-hexloc2
Thexlocl-hexloc2
hexlocl:hexloc2
hexlocl.bytecount
hexlocl:hexloc2 hexlocl.bytecount
Note that no blanks can be entered between the limit or range symbols
(: or - r . )
or any of the operands except for the blank or blanks
between the command name and the first operand.
1
blank is also
required between each set of operands when more than one set cf operands
are entered on one com.and line.
However, if a blank immediately follows the designated type character
(T or L), DCP displays all of real storage. If the next operand is
either a colon
(:), a hyphen (-), or a period (.) followed by a blank
character,
the system again defaults to a display of all storage
locations as this operand assumes a second set of operands.
Blanks separate operands or sets of operands if more than one
operand is entered on the same command line.
Blanks should not occur on
the right or left of range or length symbols, unless it is intended to
take the default value of the missing operand defined by the blank.
~2!~:
The following are
displays.
dcp 1
dcp t
dcp dcp
dcp
dcp
dcp
dcp
dcp
dcp
.
The following
embedded blanks:
dcp 1
examples of DCP entries that
11:
t:
1•
t•
displays all
dcp
dcp
dcp
dcp
dcp
00:
l-end
t-end
O-end
of storage
produce full storage
dcp
dcp
dcp
dcp
dcp
three times
t:end
t:end
O:end
1.end
O.end
because of
the
.t
Requested locations are displayed in the following format:
xxxxxx
=
wordl word2 word3 word4 [key]
*EBCDIC translation*
where xxxxxx is the real storage location of wordl.
"wordl" is
displayed (word aligned) for a single hexadecimal specification.
Up to four words are displayed on a line. If required, multiple
lines are displayed.
The EBCDIC translation is displayed aligned
to the next lower 16-byte boundary if Thexloc is specified.
Nonprintable characters display as a ".".
If the location is at a
2K page boundary, the key for that page is also displayed. The
output can be stopped and the command terminated by pressing the
ATTN key (or its equivalent).
510
VM/370: system Logic and Problem Determination Guide
Use the DMCP command to print the contents of real storage locations on
the user's virtual spooled printer.
The output format is eight words
per line with EBCDIC translation.
Multiple storage locations and ranges
may be specified.
To get the output printed on the real printer, the
virtual spooled printer must be terminated with a CLOSE command.
The
format of the DMCP command is:
r
, ,
-,
, r
I
r
I
I r
hexloc2 I I [ *d umpid ]
I
I DMCP
I I Lhexloc 1
I
I IThexlocl II : I lH!.Q
I
I I
L
J
I
I
I I hexloc 1 II
I
Q
I
I I
II
I
I
.1'1
I L
I
I
I
I
I
I
I
r
I
I {. } I bytecoun t I I
I
I
I
I
I
I
I
I~!Q
I I
L
L
J
.I
LI __________________________________________________________________
----J
I
"{-}I
,
,
Lhexloc1
Thexloc1
hexlocl
specifies the first storage location to be dumped. If
hexloc1 is the only operand, it specifies the only
storage location to be dumped.
If hexlocl is not
specified, L or T must be specified and dumping starts
with storage location O.
An EBCDIC translation is
included with the dump contents.
If hexlocl is followed
by a period and is not on a fullword boundary, it is
rounded down to the next lower fullword.
o
r
,
is a range of real storage locations to be dumped.
To dump to the end of real storage, hexloc2 may be
specified as END or not specified at all, in which case
END is assumed by default.
-.. } I hexloc21
{
I END
I
L
r
.I
,
{.}Ibytecountl is a hexadecimal integer designating
the number of
I END
I bytes of
real
storage
(starting
with
the
byte
L
.I
at hexlocl) to be typed at the printer.
The sum of
hexloc1 and the bytecount must be an address that does
not exceed the size of real storage. If this address is
not on a fullword boundary, it is rounded up to the next
higher fullword.
If the "." is used for a range, hexloc2
is defined as the number of hexadecimal storage locations
(in bytes) to be dumped starting at hexloc1. If hexloc2
is specified as a length in this way, it must have a
value such that when added to hexlocl it will not exceed
the storage size.
*d umpid
is specified for identification purposes. If specified,
it becomes the first line printed preceding the dump
data.
Up to 100 characters with or without blanks may be
specified after the asterisk prefix.
If dumpid is
specified, hexloc2 or bytecount must be specified.
The
asterisk (*) is required to identify the dumpid.
section 4. Diagnostic Aids
511
Normally, a user would define beginning and ending dump locations in the
following manner:
dmcp Lhexloc-hexloc
-- or -dmcp hexloc.bytecount
Note that there are no blanks between length or range symbols (: or or.) or between any of the operands except for the blank(s) between
the command and the first operand. A blank is also required between
each set of operands when more than one set of operands are entered.
Note, only one period (.), colon (:), dash (-) or no delimiter may be
used within each set of operands.
If,
however, a blank immediately
follows the designated type
character, the default dump starting and ending locations are assumed to
be the beginning and/or end of virtual storage. Similarly, if the range
or length symbol separates the first character from a blank or END, all
of real storage is dumped.
!2~~:
Blanks separate operands or sets of operands if more than one
operand is entered on the same command line. Blanks should net occur on
the right or left of the range or length symbol, unless it is intended
to take the default value of the missing operand defined by the blank.
Thus, all of the following produce full storage dumps.
dmcp 1
dmcp t
dmcp dmcp
dmcp
.
dmcp
dmcp
dmcp
dmcp
dmcp
1t1:
t:
1.
Each of the following
embedded blanks:
dmcp
dmcp
dmcp
dmcp
dmcp
t.
00:
o.
I-end
dmcp
dmcp
dmcp
dmcp
dmcp
produces three
t-end
O:end
l.end
l.end
O.end
full
dumps
because of
the
dmcp 1 • t
dmcp - • •
!2~~:
In cases where multiple storage ranges or limits are specified on
one command line and the line contains errors, command execution
successfully processes all correct operands to the encountered error.
The encountered error and the remainder of the command line is rejected
and an appropriate error message is displayed.
As the dump proceeds, the following message appears at the terminal
indicating that the dump is continuing from the next 64K boundary:
DUMPING LOC hexloc
where "hexloc" is the segment
such as 020000, 030000, 040000.
(64~
address for
If the user signals attention on the terminal
is displayed, the dump ends.
the dump continuation,
!Ail~
the above message
COMMAND COMPLETE
indicates normal completion of the dump.
512
VM/370: System Logic and Problem Determination Guide
Use the LOCATE command to find the addresses of CP control
associated with a particular user, a user's virtual device, or
system device.
The control blocks and their use are described
VM/370: Data Areas and Control Block Logic.
The format of the
command is:
blocks
a real
in the
LOCATE
----,
I
I
r
I
I
LOCate
userid [Vaddr]}
{ raddr
L
--I
userid
is the user identification of the logged on user. The address
of this user's virtual machine block (VMBLOK) is printed.
vaddr
causes the virtual channel block (VCHBLOK), virtual control
unit block (VCUBLOK), and virtual device block
(VDEVBLOK)
addresses associated with this virtual device address to be
printed with the VMBLOK address.
raddr
causes the real channel block (RCHBLOK), real control unit
block
(RCUBLOK),
and the real device
block
(RDEVBLOK)
addresses associated with this real device address to be
printed.
VMBLOK
xxxxxx
VMBLOK
VCHELeK
xxxxxx
VCUBLOK
xxxxxx
xxxxxx
RCHBLOK
RCUBLOK
RDEVBLOK
xxxxxx
xxx xxx
xxxxxx
VDEVBLOK
xxxxxx
section 4. Diagnostic Aids
513
Use the MONITOR command to initiate or terminate the recording of events
that occur in the real machine. This recording is always active after a
VM/370 IPL (manual or automatic). The events that are recorded in the
CP internal trace table are:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
External interruptions
SVC interruptions
Program interruptions
Machine check interruptions
I/O interruptions
Free storage requests
Release of free storage
Entry into scheduler
Queue drop
Run user requests
start I/O
unstack I/O interruptions
storing a virtual CSW
Test I/O
Halt device
unstack IOBLOK or TRQBLOK
NCP BTU (Network Control program Basic Transmission Unit)
Use the trace table to determine the events that preceded a CP system
failure.
The format of the MONITOR command for tracing events in the
real machine is:
.
,
r
I
MONitor
IL _ _ _ _ _
STArt CPTRACE}
{ STOP CPT RACE
I
I
------I
START CPTRACE
starts the tracing of events that occur on the real machine.
The events are recorded on the CP internal trace table in
chronological order.
When the end of the table is reached,
recording continues at the beginning of the table, overlaying
data previously recorded.
STOP CPTRACE
terminates the internal trace table event tracing.
Event
recording ceases but the pages of storage containing the CP
internal trace table are not released.
Tracing can be
restarted at any time by issuing the MONITOR START CPT RACE
command.
COMMAND COMPLETE
The MONITOR command was processed successfully.
514
VM/370: System Logic and Problem Determination Guide
Use the QUERY command to request system status and machine configuration
information.
(For 3704 or 3705 Communication controllers and remote
3270 resources see the Class A and B NETWORK command.)
Not all operands
are available in every privilege class.
Operands available to the specified privilege classes
The format of the Class A and E QUERY command is:
---------------------------------------,
}
I
r
I
are given below.
Query
I
IL_ _ _ _ _ _ _ _
PAGing
PRIORity userid
{ SA,Ssist
I
-------1
PAGING
displays the current system paging activity.
PRIORITY userid
displays the current priority of the specified
userid. This is established in the VM/370 directory
but can be overridden by the SET PRIORITY nn
command.
SASSIST
displays the current status of the Virtual Machine
Assist feature for the VM/370 system.
PAGING nn, SET mm, RATE nnn/SEC INTERVAL=XX:xx:xx
nn
specifies the percentage of time the
page wait during this time interval.
mm
is the
system paging activity
index
(threshold
value). This value affects the paging rate and degree
of multiprogramming that VM/370 tries to attain. The
value mm is normally 16.
nnn/SEC
is the current CP paging rate in pages per second.
XX:XX:XX
is the time interval
PAGING commands.
between the
system was
issuance of
section 4. Diagnostic Aids
in
QUERY
515
userid PRIORITY
= nn
nn is the the assigned priority of the
lower the value, the higher the priority.
specified user.
The
SASSIST
ON or OFF is indicates that the virtual
is enabled or disabled from the system.
Machine Assist feature
The format of the Class B QUBRY command is:
r----------------------------------------------------------------------,
,
r
Query
DAsd
TApes
LINES1
UR
GRaf
ALL
l
1.!£li!!i! I
IOFFline I
IFREe
I
I ATTach I
IALL
I
L
.J
!
DAsd volid
TDsk
STORage
raddr
SYStem raddr
DUMP
I
I
11Query LINES is not effective for 3704/3705 resources unless thel
I 3704/3705 is operating in 2701, 2702, 2703 Emulation Program
(EP) I
I mode. For 3704/3705 Communications Controllers operating in Networkl
I Control Program (NCP) or Partitioned Emulator Program (PEP) mode usel
I the NETWORK QUBRY command.
I
L___________
--'
DASD
displays the real addresses of disk or drum devices.
TAPES
displays the real addresses of magnetic tape units.
LINES
displays the real addresses of communication lines.
UR
displays the real addresses of unit record dev:ices (card
reader, card punches, printers) •
GRAF
displays the locally attached display devices.
ALL
(used as a first operand)
size of real storage.
DASD volid
displays the active or free
volume.
516
displays all devices
and the
status of the specified DASD
VM/370: System Logic and Problem Determination Guide
TDSK
displays all the currently allocated temporary disk space
(TDSK) from all available system owned volumes assigned
to virtual machine users.
STORAGE
displays the size of real storage.
raddr
displays
address.
SYSTEM raddr
displays the userid, virtual address, and access mode of
virtual disks which reside on the specified channel and
control unit address raddr belonging to logged on users.
DUMP
displays at the operator's terminal the type of device
and device address of the unit designated to receive
abnormal termination dumps.
ACTIVE
displays the status of only the active devices within the
group specified. This is the default. Active devices do
not include devices that are "free" or "offline".
An
active device is one that is in use by a user or the
system.
OFFLINE
displays only the devices in an "offline" status within
the group specified. An offline device is one that is
not available for access by any user or the system.
FREE
displays all the devices that are not currently in use by
the system or a user on the system. Free devices do not
include "offline" devices.
A free device is one that is
not in use by a user or the system.
ATTACH
displays all the
on the system.
device.
ALL
(as the second operand) displays the status of all
devices within the group specified.
The status is typed
in the order of "active", "free" and "offline" and is
equivalent to the response from entering
the
status
of the
device
at
the
specified
devices that are dedicated to any user
An attached device is also an active
QUERY type ACTIVE
QUERY type FREE
QUERY type OFFLINE
Produces the same results as if the following commands vere issued:
QUERY
QUERY
QUERY
QUERY
QUERY
QUERY
STORAGE
UR
LINES
DASD
TAPES
GRAF
section 4. Diagnostic Aids
517
DASD raddr ATTACH TO userid vaddr
is displayed if the real device specified by raddr is attached
to a user's (userid) virtual machine at virtual address vaddr.
DASD raddr CP SYSTBM volid nnn
is displayed if the real device designated by raddr is allocated
to the system for use as user's minidisks. nnn is the number of
active user's minidisks on the physical disk and volid is the
volume serial number of the real disk.
DASD raddr CP OWNED volid nnn
is displayed if the real device designated by raddr is used by
the system for paging and spooling activity.
nnn is the number
of active user's minidisks
(if any) on the physical disk and
volid is the volume serial number of the real disk.
TAPE raddr CP SYSTEM
is displayed if the real tape device designated
attached to CP for its exclusive use.
by raddr
is
TAPE raddr ATTACH TO userid vaddr
is displayed if the real tape device designated by raddr is
attached to a user's (userid) virtual machine at virtual address
vaddr.
PRT}
{STARTED \
{ PUN raddr DRAINED f SYSTEM CLASS
RDR
= a.. •
STARTED}
raddr { DRAINED SYSTEM
is displayed for each unit record
for spooling activity.
518
SEP }
{ NOSEP
device assigned to -the system
raddr
is the real device address (cuu).
DRAINED
indicates that the device is not currently available
for processing.
A START command must be issued to
activate the device.
V8/370: System Logic and Problem Determination Guide
STARTED
indicates that
activity.
the device
a...
specifies the classes serviced by the output device.
Up to four classes may be serviced by an output
device.
No blanks or commas are allowed between
classes.
NOSEP
indicates
option.
the
SEP
indicates
option.
the device
device
is available
was
started
was started
for spooling
with
the
NOSEP
without the
NOSEP
Note: The separator (SEP) option applies to printer
output where the edge of the fanfo1ded continuous
forms are heavily printed. This indicates to the
spooling operator the beginning and end of adjacent
spool files.
PRT} raddr ATTACH TO userid vaddr
PUN
{ RDR
is displayed if the device
machine at vaddr.
is
attached to
a user's
virtual
If the unit record device is currently active with a spool file, the
following additional response is also given:
PRT }
{ PRINTING}
{ PUN raddr t PUNCHING userid FILE
RDR
raddr
READING
userid FILE
file RECDS
norecs COpy
nn a typ
file
userid
is the name of the spool file owner.
file
is the spool file spoo1id number.
norecs
is the total file logical record count.
nn
is the number of copies remaining for output, where 01
indicates the last copy.
a
is the spool file class.
typ
is the originating device type (PRT, PUN, CON).
LINE} raddr LOGON AS userid
{ CONS
indicates that the user represented by userid is currently
logged on at the terminal located at the address raddr.
section 4. Diagnostic Aids
519
LINE
raddr ATTACH TO userid vaddr
indicates that the communication line at raddr is attached to
the virtual machine represented by userid at virtual address
vaddr.
GRAF raddr LOGON AS userid
indicates that the user represented by userid is currently
logged on at the terminal located at real address raddr.
GRAF raddr ATTACH TO userid vaddr
indicates that the display device at real
attached to the virtual ~achine represented
virtual address vaddr.
This command produces
following format:
a
response for
each
address raddr is
by userid at the
offline
device
in
the
type raddr OFFLINE
Multiple responses are displayed in the following format:
type raddr OFFLINE,
Note: In the above responses the term type
following device types:
1.IE§!
DASD
TAPE
LINE
RDR
PRT
PUN
GRAF
CONS
CTCA
CTLR
DEV
refers to one or more of the
~~~!!!!!g
Direct access device
Magnetic tape units
Communication line
Card reader
Line printer
Card punch
Graphics device
Console
Channel to channel adapter
3704/3705 communications controller
Any other device
This command produces a response for each device that is
offline in the following format:
not active or
type raddr :FREE
520
VM/370: System Logic and Problem Deteraination Guide
Por unit record devices the response is:
type raddr DRAINED
Note:
devIce.
This
response implies that
no spool
files are queued
for this
Por communication devices the response is:
ENABLED }
type raddr { DISABLED
For DASD devices with mounted volumes the response is:
type raddr {FREE }
volid
Multiple responses are displayed in the following format:
type raddr FREE,
The command response is given in
depending upon the device status.
either the "active" or
"free" format
This command displays all the currently allocated user TDSK space from
all available system-owned volumes. One entry of the following format
is produced for each TDSK:
use rid vaddr nnn
use rid
is the virtual machine identification.
vaddr
is the user's virtual device address.
nnn
is the number of cylinders allocated.
!Q!~:
If the operator does a QUERY to any real device or group of
devices (such as QUERY DASD) the following message occurs for all
devices in a not-ready status and the CPU alarm rung:
type raddr INT REQ
section 4. Diagnostic Aids
521
STORAGE
=
xxxxxK
displays the size
bytes.
of real storage (xxxxx) in
The response to this command depends upon
raddr.
multiples of 1024
the type of device located at
See the QUERY DASD, TAPES, UR, GRAF, and LINES responses.
This command requests the number of user minidisks residing on the
physical disk located at raddr. The response for each minidisk is given
in the following format:
userid vaddr mode,
userid is the identification of the user who owns the minidisk.
vaddr
is the virtual address by which
minidisk.
the user refers
to the
mode
is the type of access the user has: either R/O or R/W, or
nnn for the number of cylinders of TDSK space allocated.
type raddr DUMP UNIT {CP }
ALL
indicates that the device of device type "type" located at raddr
is the system dump unit.
522
VM/370: System Logic and Problem Determination Guide
The format of the Class D QUERY command is:
--------,
r
r
Query
,
Files [CLass c] luseridl
I *
I
.J
L
,
,
Reader
rr
Printer II ALL
I [userid ]1
PUnch
II CLass al
I
.J
IL
I
I spoolid
I
L
HOld
.J
_______________________________----J
FILES
displays the number of spooled input and output files.
The
Class D user receives the total count in the system. Files
that are currently being processed are not included in the
totals.
CLASS c
displays only the spool files of the specified class.
CLASS is omitted then all spool classes are examined.
use rid
displays only the spool files owned by the specified userid.
If userid is omitted then spool files owned by all users are
examined.
*
displays only the spool files of the logon user who issued the
QUERY command.
READER
RDR
displays basic information concerning reader spool files.
PRINTER
PRT
displays basic information concerning printer spool files.
PUNCH
PCH
displays basic information concerning punch spool files.
!Q~~:
If
The basic information displayed is:
userid of the owner of the spool file.
If exam~n~ng files
for a specific user (userid option), the userid indicates
the originator of the spool file.
•
spool file spoolid number
•
Class and originating device type
•
Number of logical records in the file
•
Number of copies specified for the file
•
File hold status
HOLD
displays a list of users
HOLD command.
whose output
is being held
by the
ALL
displays additional information for all spool files examined.
Section 4. Diagnostic Aids
523
displays additional information for the specified spool file.
The spool identification (spoolid) is a VM/370 generated
sequential nu~ber assigned to each spool file.
spoolid
The additional information displayed is:
• Date and time the file was created
• Filename and filetype of the file (if any)
• Distribution code of the file
~~E~X 111~~
[CLass c] [userid]
FILES: {=~n} RDR, { '=~n } PRT, { :~n} PUN
displays the total number of spool files in the system,
particular class, or for a particular userid.
of a
,
r
,
I ALL
I
I Class a I [userid]
L
J
spoolid
I
I
I
I
I
J
Basic Information
r
v
,
.---Additional Information--,
V
v
v
r
OWNERIDl FILE CLASS RECDS CPY HOLD IDATE TIME
NAME
use rid
file a typ norecs nn stat Imm/dd hh:mm:ss name
TYPE
type
L
,
DIST I
code I
J
Only one file is listed for a QUERY READER, QUERY PRINTER, or
QUERY PUNCH command if the spoolid operand is specified.
The DATE, TIME, NAME, TYPE,
and DIST information
only when the following commands are issued:
is displayed
QUERY {READER } {ALL . }
PRINTER
spoo11d
PUNCH
1!h!g:~:
userid
is the identification of the user who owns the file.
file
is a unique, system assigned number which
VM/370 to identify the file.
a
is the spool file class.
is used by
lOWNERID heading the title line for the spool file data is altered to
ORIGINID when the userid operand is used. In that event, ORIGINID
represents the originator of the file.
524
VM/370: system Logic and, Problem Determination Guide
typ
is the originating
RDR) •
device type
norecs
is the number
file.
nn
is the number of copies specified for the file.
no effect for reader files.)
stat
is the file hold status and is either
of logical
(PRT,
records
PUN, CON,
contained in
or
the
(Has
NONE - no hold
USER
user hold
mm/dd
is the date the file was created in month/day.
hh:mm:ss
is the actual time of the
hours:minutes:seconds.
filename
is the filename assigned to the file (if any).
If the
file has a 24-character data set name
(dsname), only
20 characters are displayed.
These characters extend
from the "name" field through the "type" field.
filetype
is the filetype assigned to the file (if any).
distcode
is the distribution code of the file.
creation of
the file
in
HOLD : {NO } RDR, {NO } PR T, {NO } PUN
nnn
nnn
nnn
userid -{
~~~~
PRT
PUN
, •••
The first response displays the total number of files within the
system which are retained in the SYSTEM HOLD status. The second
response indicates the type of hold (if any) for any user in the
system for which HOLD is in effect. The user who issues QUERY
HOLD may receive, depending upon the status of his spooled
files, the first response, the
second response, or both
responses.
section 4. Diagnostic Aids
525
The format of the Class A, B, C, D, E, F, and G QUERY command is:
r-------------------------------------------------------------g
J
,
I Query
I {LOGmS
I
I
I
Names
I
I
I
user~
[userid ]
I
L
----JI
I __________________________________________________________________
I
userl.d
LOGMSG
displays the log messages of the day.
NAMES
displays a list of all the users logged on and the real
address of the line to which each is connected.
If the user
is disconnected,
DSC is displayed
instead of the line
address.
USERS
displays the number of logged on users and the number of users
dialed to other virtual machines. If use rid is specified, the
userid and device address of the user's terminal are displayed
if he is logged on. If the specified user is not logged on, a
message to that effect occurs. Use the USERS operand if the
userid is the same as an operand (or its minimum truncation)
of the QUERY command.
Note: It is possible for the number of users logged on as
indIcated by the 'NAMES' operand to differ from the number
logged on as indicated by the 'USERS' operand. The number of
users in the process of logging on and logging off accounts
for this difference.
userid
displays the userid and the device address of the user's
terminal if he is logged on.
If the user is not legged on, a
message to this effect occurs.
*
logmsg text line
*
109ms9 text line n
logmsg additional text lines
All lines (both those with and without an asterisk)
message fil~ are displayed.
526
VM/370: System Logic and Problem Determination Guide
in the log
userid - {DSC }'
raddr
userid - {DSC }, •••
raddr
Lists all logged on users.
If the user is currently connected,
the real address to which he is connected is displayed (raddr).
If he is not connected to the system, DSC is displayed.
nnn USERS, mmm DIALED
nnn
is the total number of logged on users.
mmm
is the total number of users logically attached
DIAL command to virtual machines.
via the
Note: The term DIALED means that the line is not available to CP because
It-Is logically attached to a logged-on user and is a part of that
user's virtual machine operation.
userid - raddr
displays the real address
connected.
(raddr) to which the specified user is
section 4. Diagnostic Aids
527
Use the STCP command to alter the contents of real storage.
The real
PSi or real registers cannot be altered with this command. The format
of the STCP command is:
r---------------------------------------------------------------------,
I STCP
I { { hexloc} hexword1 [hexword2 ••• ] }
I
I
I
LI
I
I
I
I
I
I
Lhexloc
Shexloc
hexdata
____________________
~
hexloc
Lhexloc
stores the data given in hexword1 [hexword2 ••• ] in successive
fullword locations starting at the address specified by
hexloc. The smallest group of hexadecimal values that can be
stored using this specification is one fullword.
Data is
aligned to the nearest fullword boundary. If the data being
stored is less than a fullword (8-hexadecimal digits), it is
right-adjusted in the word and the high order bytes of the
word are filled with zeros. Either specification
(hexloc or
Lhexloc) may be used.
Shexloc
stores the data given in hexdata in the address specified by
hexloc without word alignment. The shortest string that can
be stored is one byte (2-hexadecimal digits).
If the string
contains an odd number of characters, the last character is
not stored. An error message occurs and the function ends.
hexword
specifies up to 8-hexadecimal digits.
If less than eight
digits are specified, the string is right justified in a
fullword and left-filled with zeros.
If two or more hexwords
are specified, they must be separated by at least one blank.
hexdata
specifies a string
embedded blanks.
of two or more hexadecimal
digits with no
STORE COMPLETE
528
VM/370: System Logic and Problem Determination Guide
Use the DASD Dump Restore (DDR) program to dump, restore, copy, or print
VM/370 user minidisks. The DDR program may run as a standalone program,
or under CMS via the DDR command.
The DDR program has five functions:
1.
Dumps part or all of the data from a DASD device to tape.
2.
Transfers data from tapes created by the DDR dump function to a
direct access device. The direct access device must be the same as
that which originally contained the data.
3.
Copies data from one device to another of the same type. Data may
be reordered, by cylinder, when copied from disk to disk. In order
to copy one tape to another, the original tape must have been
created by the DDR DUMP function.
4.
Prints selected parts of DASD and tape records
EBCDIC on the virtual printer.
5.
Displays selected parts of DASD and tape records in hexadecimal and
EBCDIC on the terminal.
in hexadecimal and
TO generate the VM/370 starter system from the distribution
standalone RESTORE function must be used.
tape, the
INVOKING DDR UNDER CMS
The format of the DDR command is:
r----------I
I
I
I
I
DDR
I [fn
I
I
---------------.-------------.,
r
,
ft Ifml
I.! I
L
]
.J
L
section 4. Diagnostic Aids
529
r
,
fn ft Ifml
1* I
L
~
is the identification of the file containing the control
no
file
statements for
the
DDR
program.
If
identification is provided, the DDS program attempts to
The filemode
obtain control statements from the console.
defaults to * if a value is not provided.
!Qi~:
If you use the CMS DDR command, CMS ignores the SYSPRINT control
statement and directs the output to the CMS printer OOE.
INVOKING DDR AS A STANDALONE PROGRAM
To use DDR as a standalone program, the operator should IPL it from a
real or virtual IPL device as he would any other standalone program.
Then indicate where the DDS program is to obtain its control statements
by responding to prompting messages at the console.
Note: Be aware that DDR when run as a standalone program does not have
error recovery support.
However, when DDR is invoked in CMS, in a
virtual machine environment, the I/O operation is performed by CP (CP
has built-in error recovery facilities).
DDR CONTROL STATEMENTS
DDR control statements describe the intended processing and the needed
I/O devices. I/O definition statements must be specified first.
All control statements may be entered from either the console or the
card reader. Only columns 1 to 71 are inspected by the program.
All
data after the last operand in a statement is ignored.
An output tape
must have the DASD cylinder header records in ascending sequences;
therefore, the extents must be entered in sequence by cylinder. Only
one type of function -- dump, restore, or copy -- may be performed in
one execution, but up to 20 ~tatements describing cylinder extents may
be entered. The function statements are delimited by an INPUT or OUTPUT
statement, or by a null line if the console is used for input. If
additional functions are to be performed, the sequence of control cards
must be repeated.
If you do not use INPUT or OUTPUT control statements
to separate the functions you specify when the input is read from a card
reader or CMS file,
an error message
(DMKDDR702E)
is displayed.
However, the remainder of the input stream will be checked for proper
syntax, but no further DDR operations will be performed.
only those
statements needed to redefine the I/O devices are necessary for
subsequent steps. All other IIO definitions remain the same.
To return to CMS, enter a null line (carriage return) in response to
the prompting message (ENTER:). To return directly to CP, key in #CP.
The PRINT and TYPE statements work differently from other DDR control
statements in that they operate on only one data extent at a time. If
the input is £rom a tape created by the dump function, it must be
positioned at the header record for each step. The PRINT and TYPE
statements have an implied output of either the console (TYPE) or system
printer (PRINT). Therefore, PRINT and TYPE statements need not be
delimited by an INPUT or OUTPUT statement.
530
VM/370: System Logic and Problem Determination Guide
I/O DEFINITION STATEMENTS
The I/O definition statements describe the tape, DASD, and
devices used while executing the DASD Dump Restore program.
An INPUT or OUTPUT statement describes each
The format of the INPUT/OUTPUT statement is:
tape and DASD
printer
unit used.
r--------------------------------------------------~------------------,
I
I INput
I OUTput
I
I
I
I
I
I
IL __._
I
I
I
I
I
I
I
I
I
I
I
I
I
L.I
I
QE:th2!!§ :
I
r
1r
,r'
I
ISKip nn I IMOde 6250 I IREWindl
I
I~~!E
Q I IMOde 1600 I IQ!J~~~I
I
L
.I
I MOde
800 I I LEave I
I
L
. I L.I
_ _____________________________
--1I
r,
cuu
type
Ivolserl
laltapel
[(options ••• )]
INPUT
indicates that the device described is an input device.
OUTPUT
indicates that the device described is an output device.
cuu
is the unit address of the device.
type
is the device type (2314, 2319, 3330, 3330-11, 3340-35,
3340-70, 3350, 2305-1,
2305-2, 2400, 2420, or 3420)
(no
7-track support for any tape devices). Specify a 3410 device
as a 3420, a 3340-70F as a 3340-70, and a 3333 as a 3330.
Specify a 3350 that is in 3330-1 or 3330-11 compatibility mode
as a 3330 or 3330-11. Specify a 3344 as a 3340-70, and
specify 3350 for a 3350 operating in native mode (as opposed
to compatibility mode).
Note:
The DASD Dump Restore
(DDR) program, executing in a
vIrtual machine, uses
I/O DIAGNOSE 20 to
perform I/O
operations on tape and DASD devices. DDR under CMS requires
that the device type entered agree with the device type of the
real device as recognized by VM/370. If there is a conflict
with device types, the following message is issued:
DMKDDR708E INVALID OPTION
However, if DDR executes standalone in a virtual machine, DDR
uses DIAGNOSE 20 to perform the I/O operation if the device
types agree. If the device types do not agree, error message
DMKDDR708E is issued.
volser
is the volume serial number of a DASD device.
If the keyword
"SCRATCH" is specified instead of the volume serial number, no
label verification is performed.
al tape
is the address of an alternate tape drive.
section 4. Diagnostic Aids
531
~Q~~:
If multiple reels of tape are required and "altape" is
not specified, DDR types the following at the end of the reel:
END OF VOLUME CYL xxx HD xxx, MOUNT NEXT TAPE
After the new tape is mounted, DDR continues automatically.
forward spaces nn files on the tape.
nn is any number
up to 255. The SKIP option is reset to zero after the
tape has been positioned.
SKIP nn
o
r
,
MODE 162501 causes all output tapes that are opened for the first
116001 time and at the load point to be written or read in
I 8001 the specified density.
All subsequent tapes mounted
L
~ are
also set to the specified density.
If no mode
option is specified, then no mode set is performed and
the density setting remains as it previously was.
REWIND
rewinds the tape at the end of a function.
UNLOAD
rewinds and unloads the tape at the end of a function.
LEAVE
leaves the tape positioned at the
the end of a function.
end of the
file at
!~!~:
When the wrong input tape is mounted, the message DMKDDR709E
is displayed and the tape will rewind and unload regardless of
options REWIND, UNLOAD, or LEAVE being specified.
Use the SYSPRINT control statement (in the standalone DDR virtual
machine only)
to describe the printer that is to print data extents
specified by the PRINT statement. It also can print a map of the
cylinder extents from the DUMP, RESTORE, or COpy statement. If the
SYSPRINT statement is not provided, the printer assignment defaults to
ODE.
CMS ignores the SYSPRINT statement when you invoke DDR as a
command under CMS, and CMS always directs the output to OOE. The format
of the SYSPRINT control statement is:
r
I
L
cuu
SYsprint
------------------,I
-------------------------------------------------
cuu
-~
specifies the unit address of the device.
The function statements tell the DDR program what action to perform.
The function commands also describe the extents to be dumped, copied, or
restored.
The format of the DUMP/COPY/RESTORE control statement is:
532
VM/370: System Logic and Problem Determination Guide
r----------------------------------------------------------------------,
I
I r
,
I
I
DUmp
I Icyl1 [To] [cyl2 [Reorder] [To] [cyI3]] I
I
I
COpy
I ICPvol
I
I
I
REstore I 1111
I
I
I
I INUcleus
I
I
--'I
IL _____________________________________________________________________
I L
-'
DUMP
requests the program to move data from a direct access volume
onto a magnetic tape or tapes. The data is moved cylinder by
cylinder. Any number of cylinders may be moved. The format
of the resulting tape is:
Record 1: a
volume header
descrIbing the volUmes.
record,
consisting
of
data
Record 2: a track header record, consisting of a list of count
fields to restore the track, and the number of data records
written on tape. After the last count field the record
contains key and data records to fill the 4K buffer.
!!~£QIg
3: track
records -packed
truncated.
data
into
records, consisting of
4K blocks,
with the
key and data
last record
Record 4: either the end-of-volume (EOV) or end-of-job (EOJ)
traIler- label. The end-of-volume label contains the same
information as the next volume header record, except that the
ID field contains EOV. The end-of-job trailer label contains
the same information as record 1 except that the cylinder
number field contains the disk address of the last record on
tape and the ID field contains EOJ.
COpy
requests the program to copy data from one device to another
device of the same or equivalent type. Data may be recorded
on a cylinder basis from input device to output device. A
tape-to-tape copy can be accomplished only with data dumped by
this program.
RESTORE
requests the program to return data that has been dumped by
this program. Data can be restored only to a DASD volume of
the same or equivalent device type from which it was dumped.
It is possible to dump from a real disk and restore to a
minidisk as long as the device types are the same.
cyl1 [TO] [cyl2 [REORDER] [TO] [eyI3]]
only those cylinders specified are moved, starting with the
first track of the first cylinder
(cyI1), and ending with the
last track of the second cylinder (cyI2). The REORDER operand
causes the output to be reordered, that is, moved to different
cylinders, starting at the specified cylinder (cyI3) or at the
starting cylinder (cyl1)
if "cyI3" is not specified.
The
REORDER operand must not be specified unless specified limits
are defined for the operation; the starting and, if required,
ending cylinders (cyl1 and cyl2) must be specified.
CPVOL
specifies that cylinder 0 and all active directory and
permanent disk space are to be copied, dumped,
or restored.
This indicates that both source and target disk must be in CP
format, that is, the CP Format/Allocate program must have
formatted them.
section 4. Diagnostic Aids
533
ALL
specifies that
cylinders.
the
operation
is to
be
NUCLEUS
specifies that record 2 on cylinder 0, track 0 and the nucleus
cylinders are dumped, copied, or restored.
address~
performed
all
•
Each track must contain a valid home
cylinder and track location.
•
Record zero
characters.
•
Flagged tracks are treated just as any other track for all 2314,
2319, 3340, and 2305 devices.
That is,
no attempt is made to
sUbstitute the alternate track data when a defective primary track is
read. In addition, tracks are not inspected to determine whether
they were previously flagged when written.
Therefore, volumes
containing flagged tracks should be restored to the same cylinders of
the volume from which they were dumped. The message DMKDDR715B occurs
each time a defective track is dumped, copied or restored, and the
operation continues.
•
Flagged tracks for 3330 and 3350 devices are handled automatically by
the control unit and may never be detected by the program.
The
program may detect a flagged track if, for example, no a.lternate
track is assigned to the defective primary track. If a flagged track
is detected by the program, the message DMKDDR715E occurs and the
operation terminates.
must
not
contain more
than
containing
on
eight
key
the real
and/or
data
INPUT 191 3330 SYSRES
OUTPUT 180 2400 181 (MODE 800
SY SPR INT OOF
DUMP CPVOL
INPUT 130 3330 MINIOl
DUMP 1 TO 50 REORDER 51
60 70 101
This example sets the density to 800 bpi, then dumps all pertinent
data from the voluae labeled SYSRES onto the tape that is mounted on
unit 180. 1£ the program runs out of space on the first tape, it
continues dumping onto the alternate device
(181).
A map of the dumped
cylinders is printed on unit OOF while the program is dumping. When the
first function is coaFlete, the volume labeled MINIOl is dumped onto a
Its cylinder header records are labeled 51 to 100. A map of
new tape.
the dumped cylinders is printed on unit OOF. Next, cylinders 60 to 70
are dumped and labeled 101 to 111. This extent is added to the cylinder
map on unit OOF. When the DDR processing is complete, the tapes are
unloaded and the program stops.
If cylinder extents are being defined from the console, the following
is displayed:
ENTER CYLINDER EXTENTS
ENTER:
534
VM/370: System Logic and Problem Determination Guide
For any extent after the first extent, the message
ENTER NEXT EXTENT OR NULL LINE
ENTER:
is displayed.
The user may then enter additional extents to be dumped, restored, or
copied. A null line causes the job step to start.
~Qt~:
When a cylinder map is printed on the virtual printer (OOF as in
the previous example) a heading precedes the map information. Module
DMKDDR controls the disk, time and zone printed in the heading. Your
installation must apply a local modification to DMKDDR to insure that
local time, rather than GMT (Greenwich Meridian Time), is printed in the
heading.
Use the PRINT and TYPE function statement to print or type (display) a
hexadecimal and EBCDIC translation of each record specified. The input
device must be defined as direct access or tape. The output is directed
to the system console for the TYPE function, or to the SYSPRINT device
for the PRINT function. (This does not cause redefinition of the output
unit definition.) The format of the PRINT/TYPE control statement is:
------------------,
r
I
I
I
I
cyll [hhl [rrl]] [To cy12 [hh2 [rr2 ]]] [(options ••• [)]] I
I
I
2.E!12.!!§:
[ Hex] [ Graphic] [Count]
I
PRint
TYpe
I
L
cyll
is the starting cylinder.
hhl
is the starting track. If present, it
operand. The default is track zero.
rrl
is the starting record. If present, it must follow the hhl
operand. The default is home address and record zero.
TO cy12
is the ending cylinder. If more than one cylinder is
printed or typed "TO cy12" must be specified.
hh2
is the ending
operand.
The
cylinder.
rr2
is the record ID of the last record to print.
the last record on the ending track.
must follow
the cyll
to be
track. If present, it must follow the cy12
default is the last track on the ending
The default is
HEX
prints or displays a hexadecimal representation
record specified.
GRAPHIC
prints or displays
specified.
an EBCDIC translation of
of each
each record
section 4. Diagnostic Aids
535
COUNT
prints or displays
specified.
only the count field
for each record
PRINT 0 TO 3
Prints all of the records from cylinders 0, 1, 2, and 3.
PRINT 0 1 3
Prints only one record, from cylinder 0, track 1, record 3.
PRINT 1 10 3 TO 1 15 4
prints all records starting with cylinder 1, track 10, record 3, and
ending with cylinder 1, track 15, record 4.
The example in Figure 63 shows the information displayed at the
console (TYPE function) or system printer
(PRINT function) by the DDR
program. The listing is annotated to describe some of the data fields.
DMKDDR725R
ORIGINAL INPUT DEVICE WAS (IS)
LARGER THAN OUTPUT DEVICE.
DO YOU WISH TO CONTINUE? RESPOND YES OR NO:
~!E!~~~!!2~:
RESTORE function - The number of cylinders on the original
DASD input unit is compared with the number of cylinders on
the output device.
COpy function - The input
than the output device.
Qeg£~!Q£ 1£~iQ~:
RESTORE function
yes or no.
DMKDDR711R
device contains
more cylinders
The operator must determine if the COpy or
is to continue.
The response is either
VOLID READ IS volid2 [NOT volidl]
DO YOU WISH TO CONTINUE? RESPOND YES NO OR REREAD:
volidl - The volume serial number from the input or output
control statement; volidl is displayed only if it
was entered.
volid2 - is the volume serial number from the VOLl label on
the
DASD device
specified
by the
control
statement.
~1§!gm
!£!iQll: The system waits for a response.
If you respond "yes", the operation will continue.
If you respond "no", and the input is from cards or a eMS
file, the
program is terminated after
scanning the
rema~n~ng
statements for syntax.
Otherwise, the next
statement is solicited from the console.
536
VM/370: System Logic and Problem Determination Guide
If you respond "reread", the
again.
volume specified will be read
]Qig: A new volume may have been mounted in the interim.
y§g£
DMKDDR7l6R
A£i!Q~:
Respond "yes", "no", or "reread."
NO VOLl LABEL FOUND FOR volser
DO YOU WISH TO CONTINUE? RESPOND YES NO OR REREAD:
E!El~n~iiQ~:
The program was unable to find a record with
the key of VOLl
on cylinder 0 track 0 and was not able to
read record 3 on cylinder 0 track 0 for the specified
volume serial number (volid).
The volume serial number is
displayed only if specified in the INPUT or OUTPUT control
statement.
~y§t~~ ~£t!2~:
The system waits for a response.
If you respond "yes", the system will continue with the job
steps.
If you respond "no" and the input is from cards or a CMS
file, the program will be terminated after scanning the
remaining statements for syntax.
Otherwise, the next
statement will be solicited from the console.
If you respond "reread", the program will attempt to reread
the specified device.
Q§~£ !£i!~n:
DMKDDR717R
Respond to the message as indicated.
DATA DUMPED FROM volidl TO BE RESTORED to volid2
DO YOU WISH TO CONTINUE? RESPOND YES NO OR REREAD:
J2~El~!!~iiQ~:
volidl
- The volume serial number of the input tape.
volid2
-- The volume serial number of the output DASD
device that is to receive the data from volidl.
21§igm
!£iiQ~:
The system waits for a response.
If you respond "yes". the restore function will continue.
If you respond "no" and the input is from cards or a CMS
file, the program will be terminated after scanning the
remaining statement for syntax.
Otherwise, the correct
statement will be solicited from the console.
If you respond "reread", the input tape will be backspaced
to the start of the file,
and the volume header label will
be reread.
User Action:
If the wrong input tape is mounted, replace
the-tape--and respond REREAD.
Otherwise,
respond in the
appropriate manner.
ENTER CYLINDER EXTENTS
ENT ER:
This message is
tErminal.
received only if you are entering
input from your
section 4. Diagnostic Aids
537
END OF VOLUME CYL xxx HD xx, MOUNT NEXT TAPE
DDR continues processing,
reel.
after
the mounting
of
the next
tape
dumped.
The
RESTORING volser
volser
is the volume serial number
RESTORE operation has begun.
of
the disk
COPYING volser
volser
is the volume serial number described by the
The COpy operation has begun.
input unit.
DUMPING volser
volser
is the volume serial number described by the
The dumping operation has begun.
input unit.
PRINTING volser
volser
is the volume serial number described by the
The PRINT opration has begun.
input unit.
END OF DUMP
The DUMP operation has ended.
END OF RESTORE
The RESTCRE operation has ended.
END OF COpy
The COPY operation has ended.
END OF PRINT
The PRINT operation has ended.
END OF JOB
All specified operations have completed.
ENT ER:
Prompts input from the terminal.
A null line (Press the Enter key
or equivalent)
causes control to return to CMS, if the virtual
machine is in the CMS environment.
538
VM/370: system Logic and Problem Determination Guide
110I11~ Addr~ss
R"~nrd
0
ro -;,h;:;:" I::;h ;;;;- :;/e,:- -
-+--__
Re,'llrd I
A-_-_~
I
I
?
is
•
•
_
l
A he"ding is "rinled conlaining Ihe
dala lellglh rr"m Ihe enlllli field firsl in
d~dll1;11.
then in hexadecimal
The dala is Ihell prinled in hex"decinwl
wilh g,aphic lllier"re'"'i,,n 10 thc right
~'~n~
I
I
___ J
040961000 DATA LENGTH _ - - - - - - - - -
00000 0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
SUPPRESSED CHARACTERS SAME AS ABOVE.
No'e: nala Lenglh field repeated
in heading.
1st lIalfllf-+----II_CYL 019 HD 00 REC 002 COUNT 0013000b02 OOM
Rl'f..'ord
~
....,IfI,.
02472~DATA LENGTH
..
00000 0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
SUPPRESSED CHARACTERS SAME AS ABOVE.
ABOVE RECORD WRITTEN USING RECORD OVERFLOW
0
r::;--------,
0
I'
L
Ilome Address
Record 0
2nd lIalf uf
Re..:ord 2
This stalemenl indicales Ihat Ihis pori ion
of Rc(oru 2 was written uSlIlg the Wrtte
Special Count. Key, and Data command. Thc
remainder of.Record .2 is fOllnd on the next
-.:,ck.:,:he':::
I
re~ a~7RceordO~ .J
CYL 019 HD 01 HOME ADDRESS 0000130001 RECORD ZERO 0013000100 00 0008 00000000 00000000
.
CYL 019 HD 01 REC 002 COUNT 0013000102 00 0658-01624 0658 DATA LENGTH
00000 0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
SUPPRESSED CHARACTERS SAME AS ABOVE.
e-
~
G
Record J
I
---1---_ CYL
019 HD 01 REC 003 COUNT 0013000103
I
I
-.- - - -
I r I he key lengl h field is not lero
•
•
- - -
~_ _ _ _ _ _ _ _
;Y
.,
I
I
A heading is prinled conlaining Ihe key lenglh
firsl in decimal. then ill hexadecimal.
The key is Ihell prinled ill hexadecimal wilh
graphic inle'prelal,oll 10 the nght(nol shown here). ..J
80 OF80
00128 0080 KEY LENGTH _--~----
00000 0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
SUPPRESSED CHARACTERS SAME AS ABOVE
0396B OF80 DATA LENGTH
00000 0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
SUPPRESSED CHARACTERS SAME AS ABOVE.
Record"
--+----
CYL 019 HD 01 REC 004 COUNT 0013000104 00 0000
G)
END OF FILE RECORD
re--------,
I
I
L
Figure 63. Annotated Sample of Output from
of the DDR Program
Whellever 11ll' dala !ellglh I,eld
an end-of-file priliis lIext
IS
lero
I
I
_ _ _ _ _ _ _ ....I
the TYPE and PRINT Functions
section 4. Diagnostic Aids
539
A wait state is produced by one of the following modules:
DMKCCH
DMKCKP
DMKCPI
DMKDMP
DMKMCH
DMKPAG
DMKSAV
DMKWRM
When a wait state occurs, the Program status Word (PSW)
the operator's console in the following format:
is displayed at
xxyyyyyyzzzzzwww
xxyyyyyy is the left half of the program
either:
status word.
This half may be
03yyyyyy
Valid
work.
OOyyyyyy
system wait caused by an error condition.
wait condition.
The system
is waiting
for
zzzzzwww is the right half of the program status word.
The wait state
code is found in the right half of the PSW when the CPU is in
the wait state.
The wait state code, www, indicates the error
condition.
wait
fQQ~
~!El~~~t!2~
The machine
check handler
Probable hardware error.
found
an
unrecoverable
failure.
002
The channel
check handler
probable hardware error.
found
an
unrecoverable
failure.
003
A system failure
performed.
004
This wait state code is loaded by DMKDMP when a console,
or an
output device is not operational, or when a console or output
device produces an inexplicable error status.
Probable hardware
error.
005
DMKCPI could not find an
operational
console.
Probable hardware error.
006
This is a normal wait when a system shutdown is completed.
007
A program check, a machine check, or
found by the checkpoint program.
008
Checkpoint and system shutdown are complete.
If the system is
running under an alternate console, error messages DMKCKP910I,
DMKCKP911w, DMKCKP960I, and DMKCKP9611 are not displayed.
009
An error
001
condit~on
occurred
before
a
valid
warm
primary
or
a permanent I/O
start
alternate
error was
occurred that prevents a warm start.
If the system is running under an alternate console,
messages DMKCKP9101 and DMKCKP911W are not displayed.
540
was
VM/370: System Logic and Problem Determination Guide
error
OOA
A machine check occurred while DMKSAV was attempting to
restore a page image copy of the nucleus on a SYSRES
probable hardware error.
OOB
A machine check occurred before initialization was complete.
OOC
An attempt was made to IPL from a disk that did not contain a
system. Thus, the wait state code OOC entered on disk by the
Format/Allocate program is encountered.
OOD
.The machine size defined during system generation is greater than
the real machine size, or a hardware error has occurred which
inhibits VM/370 from using the required storage.
OaF
Hardware errors are being received on VM/370 paging device(s).
The wait state that causes this code is preceded by message
DMKPAG415E
save or
device.
CONTINUOUS PAGING ERRORS FROM DASDxxx
010
The SYSRES device, on which DMKSAV is attempting to write a page
image copy of the nucleus, is not mounted or not ready.
all
An unrecoverable error, other than a machine check, occurred while
DMKSAV attempted to write a page image copy of the nucleus on the
SYSRES device.
012
The normal wait state code loaded
loading the nucleus.
by DMKSAV when it has completed
Section 4. Diagnostic Aids
541
Figure 64 lists the CP ABEND, their cause and required action.
------'----------------------------------,
r
ABEND
Code
Action
Reason for ABEND
I
I
Verify that general
register 8
points to an RDEVBLOK for a terminal.
If it does not, there is
probably an error in the calling
program.
Identify the calling
program by means of the return
address and the base register in
the save area
pointed to by
general register 13. Then, attempt to identify the source of
the incorrect RDEVBLOK address.
BL DOO 1
Register 8 should contain a pointer to the
RDEVBLOK for the user's
terminal.
This routine
(DMKBLDVM)
attempts to
create
and partially
initialize a VMELOK for
a user. DMKBLDVM abnormally
terminates
if
general register 8 does
not contain a pointer
to the user.
BLD002 I
I
I
I
pages
are being reExamine the dump and determine
why the page was released without
leased but
the page
the page invalid bit turned on.
invalid bit is not on
in the page table entry.,
CFG010 I
I
I
1
,
DMKCFGCL was called to
perform an unsupported
function.
The function
request may be found in
SAVEWORK1, byte 2.
supported values are:
X' 01'
LOAD SYS
X'02'
FIND SYS
X' 04'
PURGE SYS
,
I
I
1
1
CK SOO 1
The map for
dynamic
checkpoint has not been
allocated prior to a
call to DMKCKSPL.
I
,
,
I
,
,
CKS002
The spool file identification in the map and
on the checkpoint cylinder do not match.
-----------------------------------------------------1
1
I
I
,
Identify the caller by the return
address and base register in the
SAVEAREA pointed to by register
13 to identify the source of the
unsupported function request.
I
,
,
I
CKS003 1 No function
was speci, fied in the call to
, DMKCKSPL.
I
,
I
I
,
1
1
1
I
1
1
1
The map should be allocated via a
call to entry points DMKCKSIN or
DMKCKSWM fro~ DMKWRM. Check that
DMKWRM does, in fact, call one of
these entry points and that they
do allocate a map.
In this case,
(1) DKKCKSWM or
DMKCKSIN did not set up the map
properly, (2) a call to DMKCKSPL
caused the mismatch, or
(3) the
SFBLOK was released but the' map
was not updated.
Check location SAVERTN in the
save area pointed to by general
register
13.
This indicates
which
routine called DMKCKSPL
with insufficient data.
1----------------------------,-------
1 CKS004 I A spool file to be de- , The SFBLOK for the file should
1
I leted cannot be found , have been queued previously on
,
, on the system printer, , either the printer, punch, or
I
, punch, or reader file 1 reader file chain by DKMCKSWM
I
I chains.
, when performing a CKPT start.
I
'
, Check for an error in this logic.
L
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _- - - '
Figure 64.
542
CP ABEND Codes
(Part 1 of 15)
VM/370: System Logic and Problem Determination Guide
-,
r
ABEND
Code
Reason for ABEND
I
I
Action
CPIOOl
The RDEVBLOK for ·the
DASD
on
which
the
SYSRES volume is mounted cannot be located,
or the IPL volume is
not the SYSRES volume.
The SYSRES volume is
specified
in
the
SYSRES
macro in the
DMKSYS module.
Verify that the volume serial
number on the SYSRES volume from
which the IPL was attempted, is
the same as that specified in the
field DMKSYSVL. If the volume
serial number is not the same, it
may have been altered by the CLIP
utility. Or, the image of the
same nucleus saved on the SYSRES
may have
been partially
destroyed and the SYSRES specification altered. Load or restore
the nucleus from a backup copy
to the SYSRES volume and try
to IPL again.
CPI002
A valid system directory file could not be
located.
Display the volume labels for all
owned volumes. If the volumes do
not contain an active directory
pointer, run DMKDIR
(the standalone directory
program) to recreate the system directory on an
owned
volume.
If an
active
directory pointer is present in
at least one volume label, verify
that the device on which the volume is
mounted is online and
ready before trying to IPL the
system.
CPI003
The system TOD clock is
not operational.
Call IBM for hardware
to fix the clock.
CVTOOl
The system TOD clock is
in error or is not operational.
DRDOOl
The device code index
in the compressed DASD
address for the system
dump file points to an
RDEVELOK for an invalid
DASD. The valid DASDs
are 2305 series, 3330
series,
3340 series,
3350 series or 2314/
2319.
DSPOOl
During I/O
interruption, unstack and reflection,
DMKSCNVU
could not locate all of
the virtual
control
blocks for the interrupting unit.
Figure 64.
support
I
Verify that the contents and or- I
der of the owned list have not I
been altered since the dump was I
taken. If these fields have not I
been altered, the SFBLOK for the I
dump file may have been destroyed. I
The owned list is specified by I
the SYSOWN macro in the
DMKSYS I
module.
I
I
I
The integrity of the user's vir- I
tual I/O configuration has prob- I
ably
been violated. The unit I
addresses or indexes in the vir- I
tual control blocks are in error, I
or the virtual configuration has I
been
altered by ATTACH/DETACH I
while I/O was in progress.
Check I
for a devi~e reset failure in I
DMKCFPRD.
________ -JI
CP ABEND Codes (Part 2 of 15)
section 4. Diagnostic Aids
543
r
-,
ABEND
Code
Reason for ABEND
Action
---------------------------------DSP002
The dispatcher (DMKDSP)
Most likely, a free storage viois attempting to dis1ation has occurred. First look
patch a virtual re1oat the DMKPRV and DMKVAT modules.
cate user whose shadow
Examine the real, virtual, and
segment tables or virshadow
translation tables for
tua1 extended control
consistency of entry size and
register 0 are invalid.
format.
Also compare page and
segment size.
DSP003
The interval timer was
not incremented properly.
This is most likely a hardware error.
The
dispatcher tests
for interval timer errors
and
abnormally
terminates if such an
error occurs. Results
would be unpredictable
if CP continued
when
the interval timer was
in error.
Check the timer fields in real
storage. The value of the real
interval timer is at real storage
location X'50'. The dispatcher
loads the value of the real interval timer in real storage location x'54' when a user is dispatched. The value of the real
interval timer is loaded into
real storage location X'4c' when
an interrupt occurs. If the value
stored
at X'4C' is not
less
than the value stored at X'54',
the dispatcher abnormally terminates. Check the routines that
control the value of the time
fields at
X'4C',
X'50', and
X'54'.
DSP004
While tracing SIOs or
I/O
interrupts,
the
virtual dev ice was detached.
NOw,
the
VDEVBLOK
cannot
be
found.
Examine the operator's console
sheet and the user's terminal
sheet to see who detached the
device.
Warn the
person
responsib1e that devices should not
be detached during I/O tracing.
FREOOl
The size of the block
being returned (via GR
0)
is less
than or
equal to o.
Using FREER14 and FREER12 in the
PSA, identify the
CP
module
releasing the storage. Check for
an error in calculating the size
of the block or for a modification to the stored block size for
variable-size blocks.
FRE002
The address of the free
storage
block
being
returned
matches the
address of a block already
in
the
free
storage chain.
Identify the program returning
the storage by means of the return address and base registers
(FREE14 and FREE12 in DMKFRE's
save area in PSA). The most common cause of this type of failure
is a module that returns a free
storage block but fails to clear
a pointer to the block that has
been saved elsewhere. All modules that return blocks via a
call
to DMKFRET should first
verify that the saved pointer is
nonzero;
after
returning the
block, any saved pointers should
be set to zero.
Figure 64.
544
CP ABEND Codes (Part 3 of 15)
VM/370: System Logic and Problem Determination Guide
I
I
I
I
I
I
I
I
I
I
I
r----------------------------------------------------------------------,
ABEND I
I
Code
I
Reason for ABEND
I
Action
FRE003
The address of the free
storage
block
being
returned overlaps the
next lower block on the
free storage chain.
A free storage pointer may have
been destroyed.
Also, the module
releasing the lower (overlapped)
block may have returned too much
storage. Examine the lower block
and determine its use and former
owner. Or, identify the program
returning the storage by means of
the return
address and
base
registers
stored
(FREER14 and
FREER12 in DMKFRE's save area in
PSA). The most common cause of
this type of failure is a module
that returns a free storage block
but fails to clear a pointer to
the block that has been saved
elsewhere.
All modules that return blocks via a call to DMKFRET
should
first verify that the
saved pointer is nonzero; after
returning the block, any saved
pointers should be set to zero.
FRE004
The address of the free
storage
block
being
returned overlaps the
next higher block on
free storage chain.
A free storage pointer may have
been destroyed.
Also, the module
releasing the higher (overlapped)
block may have returned too much
storage, or the module may be
attempting to release storage at
the wrong address.
FRE005
A module is attempting
to release storage in
the
resident
VM/370
nucleus.
A module is probably attempting
to release location O. Check for
the module picking up a pointer
to the free storage block without
first testing the pointer for O.
Use FREER14 and FREER12 in the
PSA to identify the module.
FRE006
A module is requesting
a block
of
storage
whose size
(contained
in GR 0) is less than
or equal to zero.
Using FREER14 and FREER12 in the
PSA, identify the module. Check
for an error in- calculating the
block size. Improper use of the
half word
instructions ICM and
STCM can cause truncation of high
order bits that results in a calculation error.
FRE007
A module is attempting
to release a block of
storage whose address
exceeds
the size of
real storage.
A free storage pointer may have
been destroyed.
Attempt to identify the owners of the free storage blocks adjacent to the one
containing the pointer that was
destroyed. Check for moves and
translation where initial counts
of zero have been decremented to
minus 1, thus
generating
an
executed length code of X'FF', or
an effective length of 256 bytes.
Figure 64.
CP ABEND Codes (Part 4 of 15)
section 4. Diagnostic Aids
545
r-----------------------------------------------------------------------,
ABEND
1
1
1
Code
1
Reason for ABEND
FRE008
The address of the free
storage
block
being
returned
matches the
address of the first
block in the subpool
1 for that size.
1
-----------------------------1
FRE009 1 The address of the free
1 storage
block
being
1 returned matches
the
1 second
block in the
1 subpool for that size.
1
1
1
1
Action
I
1
1
1
1
1
1
1
I
1
Identify the program returning
the storage by means of the return address and stored base registers
(FREER14 and FREER12 in
DKKFRE's save area in the PSA).
The common cause of this type of
failure is a module that returns
a free storage block but fails to
clear a pointer to the block that
has been saved elsewhere.
All
modules that return blocks via a
call to DMKFRET should
first
verify that the saved pointer is
nonzero;
after
returning the
block, any saved pointers should
be set to zero.
---------------------------------FRE010
FREO 11
I
-----------1
A program is attempting
to extend free storage
while storage is being
extended.
This can be
caused by I/O interruptions
or
channel
programs
involving
channels
other
than
channel o.
If the
storage requests that
caused the ABEND are due to channel activity, place the device
involved on channel 0,
which is
disabled during free storage extension.
A CP
module has attempted
to return a
block of storage that
is in the user dynamic
paging area.
Identify the program returning
the storage by means of the return address and stored base registers
(FREER14 and FREER12 in
DMKFREE's save area in the PSA).
The common cause of this type of
failure is a module that returns
a free storage block but fails to
clear a pointer to the block that
has been saved elsewhere. All
modules that return blocks via a
call to
DMKFRET should first
verify that the saved pointer is
nonzero;
after
returning the
block, any saved pointers should
be set to zero.
1
1
1
1
1
1
I
1
1
-----------------------------------------------------1
HVD001 1 The user pointed to by I The RDEVBLOK for the SYSRES de- I
I GR 11 issued a DIAGNOSE 1 vice was probably destroyed, or a 1
I instruction while at- I volume with the same serial num- I
1 tempting
to format the 1 ber as the SYSRES volume was I
I I/O
error,
channel I mounted.
If a volume with the 1
1 check, or machine check 1 same serial number was mounted, I
1 recording
areas:
the 1 check the ATTACH processing in 1
1 SYSRRS
device type is 1 the DMKVDB routine.
1
1
unrecognizable.
1
L _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ - I1
Figure 64.
546
CP ABEND Codes
(Part 5 of 15)
VM/370: System Logic and Problem Determination Guide
--------,
r---------------------------------------ABEND 1
1
1
Code
1
Reason for ABEND
1
Action
1
----------------------------10S001
The caller is trying
The 10BLOK may have been returned
to
reset
an active
10BLOK from the RCHBLOK
queue, but that 10BLOK
contains
an
invalid
address.
(via DMKFRET)
or
destroyed.
Verify that the 10BLOK was valid
and use the 10BLOK and RDEVBLOK
to determine the last operation.
10S002
DMK10S is attempting to
restart an 10BLOK from
the RCHBLOK queue, but
that 10BLOK
contains
an invalid address.
10S003
DMK10S is attempting to
remove an 10BLOK from a
queue, but that 10BLOK
contains
an
invalid
address.
Register 2 points to the RCHBLOK,
RCUBLOK, or RDEVBLOK from whose
queue the 10BLOK is being removed. Register 10 points to the
10BLOK. Use the
CP
internal
trace table to determine which
module called DMK10S twice to
start the same 10BLOK.
NLD001
During execution of a
NETWORK DUMP command,
or during an automatic
dump of a 3704 or 3705,
VM/370 detected that it
had not allocated sufficient
DASD
spool
space to contain the
information
from the
3704 or 3705. The MODEL
operand of the RDBV1CE
macro
describing the
3704 or 3705 was not
specified
correctly.
VM/370 determines the
storage size of a 3704
or 3705 by the model
specified
on
the
RDBV1CE macro.
Correct the RDEV1CE macro specifying the 3704 or 3705, reassemble the DMKR10 module, and regenerate the VM/370 CP nucleus with
the corrected module.
1---------
1 PGS001 1 The user page
count in
l i t h e VMBLOK
(VMPAGES)
1
1 became negative.
---------1
A module has attempted to release 1
more pages than it originally re- 1
ceived. The
module that last 1
called DMKPGS is probably the 1
module in error.
- - - - J1
1
1
L________________________________________
1
1
Figure 64.
CP ABEND Codes (Part 6 of 15)
section 4. Diagnostic Aids
547
r--------------------·---------------·---------------------,
ABEND
Code
I
I
Reason for ABEND
I
I
Action
PGT001
The number of cylinders
in use stored in the
allocation
block
(ALOCBLOK) is less than
the maximum
but the
DMKPGT module was unable to find available
cylinders.
Inspect the chains of paging and
spooling allocation blocks anchored at RDEVPAGE and RDEVRECS
on the RDEVBLOK for the device in
question,
and
verify that a
cylinder
allocation
block
(RECBLOK) exists for each cylinder marked and allocated in the
ALOCBLOK.
If RECBLOKs for some
cylinders are
missing, it is
possible that the bit map in the
ALOCBLOK has been destroyed.
If
all cylinders are accounted for,
the updating of the count field
is in error.
PGT002
The
count of
pages
in a page
allocation
block (RECBLOK) is less
than the maximum but
the DMKPGT module was
unable to find available pages.
If the RECBLOK in question is in
use for paging, then locate a
SWPTABLE entry for each page allocated on the cylinder. However,
if the cylinder is in use for
spooling, it is possible that the
RECBLOK
itself
has been destroyed or that the updating of
the use count is faulty.
PGT003
The
DASD
page slot
being released is not
marked allocated.
Identify the module attempting to
release the page by means of the
caller's return address and base
register stored in BALR14 and
BALR12 in the BALRSAVE save area
in PSA.
Locate
the
source
(control block or SWPTABLE entry)
of the DASD address being released to verify that they have
not
been
destroyed.
If the
DASD page is in a spool file, it
is possible that the file or the
RECBLOK chain has been incorrectly checkpointed and warmstarted
after a system shutdown or a
system crash.
PGT004
The dummy RECBLOK indicating
the
spooling
DASD pages on the cylinder that are to be
released
contains
a
page count greater than
the number of pages allocated
on the cylinder.
The spool file pointers may have
been destroyed while the file was
being processed, or the allocation chain may be in error.
A
cold start may be necessary. If
feasible,
use
the DASD dump
restore program to print the DASD
areas containing
the affected
file, and try to locate the incorrect pointers.
Figure 64.
548
CP ABEND Codes (Part 7 of 15)
VM/370: system Logic and Problem Determination Guide
I
I
r----------------------------------------------------------------------,
I
I
I
I ABEND
I Code
I
PGTOO5
I
Reason for ABEND
A module is trying to
release
a DASD page
slot on a cylinder for
which no page allocatio,n
block
(RECBLOK)
exists.
1--------------------PGT006
The last DASD page slot
in a RECBLOK has been
deallocated but the bit
representing the cylinder in the
cylinder
allocation
block
(ALOCBLOK) is not currently set to one, indicating that the cylinder was not allocated.
I
Action
Use BALR14 and BALR12 in the
BALRSAVE
area of the PSA to
identify the module attempting to
release the page. Verify that the
DASD cylinder address is valid
for the device in question. If it
is and the rest of the DASD address is valid, verify that the
cylinder is in the dynamically
allocatable area.
If these restrictions are met, the DASD page
must have been used by more than
one user.
I The ALOCBLOK has probably been
I destroyed, or the chain pointer
I in the RDEVBLOK is in error.
I
I
I
I
I
I
I
PGT007
A module is trying to
release a page of virtual storage in use by
the VM/370 control program that has not been
marked allocated.
Use BALR14 and BALR12 in the
BALRSAVE area of the PSA to identify the module attempting to release the page.
Locate the control block containing the virtual
page address that is being released~
It is possible that the
address has been destroyed, or a
pointer to a virtual page has
been retained after the page was
destroyed.
PGT008
The system's
virtual
storage buffers
have
been exhausted because
of an excessive number
of open spool files.
Request users to close all spool
files that are no longer active.
PRGOOl I Program check
I tion)
in the
I program.
(opera- I Examine the ABEND dump.
In parcontrol I ticular, examine the old PSi and
I identify the module that had the
program check.
Program check
(privi- I
leged operation) in the I
control program.
I
---I
Program check (execute) I
in the control program. I
I
Program check
(protec- I
tion)
in the control I
program.
I
---------------------------------1
PRG002 I
I
I
1--------
I PRG003 I
I
I
I
I PRG004
I
LI _ _ _ _ _ _ _
Figure 64.
----------
.J
CP ABEND Codes (Part 8 of 15)
Section 4. Diagnostic Aids
549
r---------------------·-------------------------------------,
1 ABEND 1
I
1
1 Code
1
Reason for ABEND
1
Action
1
I
Examine the ABEND dump. In par1 PRG005
Program check (addressticular, examine the old PSi and
1
ing)
in the
control
1
1 program.
1 identify the module that had the
------------------------1 program check.
PRG006 1 Program check (specifi- 1
1 cation)
in the control I
1 program.
1
I
PRG007
Program check (data) in 1
the control program.
1
--I
PRG008
program check
(fixed- I
point overflow)
in the I
1 control program.
1
-----------------------1
PRG009 1 program check
(fixed- 1
I point divide)
in the 1
1 control program.
1
I
PRGO 10
program check (decimal 1
overflow)
in the con- I
trol program.
1
--I
PRGO 11
program check (decimal 1
divide) in the control I
1
1 program.
1
1---------------------1
1 PRG012 1 program check (exponen- 1
1
1 tial overflow) in the 1
1
1
1 control program.
1
1 PRG013
program check (exponen1
tial underflow) in the
1
1 control program.
1
1
1
1
---------------------1
PRG014 1 Program check (signifi- 1
1 cancel in the control 1
1 program.
1
1
program
PRG015
check 1
(floating-point
di- 1
vide in the
control 1
program.
1
-----1
PRG016
Program check (segment) 1
1 in the control program. 1
1------------------1
I PRG017 1 Program check (paging) 1
1
I in the control program. 1
1
--------1
1 PRG018
1
1
11 PRG019
1
L1
Program check (transla- 1
tion)
in the control 1
program.
1
1
Program check (special 1
operation) in the con- 1
trol program. ______________________
1
_
------'
Figure 64.
550
CP ABEND Codes (Part 9 of 15)
VM/370: System Logic and Problem Determination Guide
r--------------------------------------------------------------------,
ABEND 1
1
1
Code
Reason for ABEND
1
Action
1
1
-------------------------------------------------1
PRG254 1 A translation specifi- 1 If the set of translaticn tables 1
1
1
1
1
1
cation
exception has
been
received for a
virtual machine that is
not in extended control
mode.
1
1
1
1
1
pointed to by RUNCR1 is correct,
a hardware failure has occurred,
possibly with
dynamic address
translation. Otherwise, call IBM
for software support.
1
1
1
1
1
---------------------------------------------1
PRG255 1 A PER
(program
event 1 Retry the program causing the er- 1
recording) has been re- 1 ror; if the problem persists,
for a virtual 1 call IBM for software support.
1 machine that is running 1
PER disabled in 1
1 with
1 its virtual PSi.
1
------------------------------------PSA001
No free
storage
is
Try to identify the extreme load
available
for
save
condition that caused the probareas.
lem. Verify that a routine has
not
requested
an
inordinate
amount of storage. If the storage
requests are valid and the problem occurs regularly, alter the
DMKCPI module to allocate more
than six pages of free storage
per 256K bytes of storage.
1
1
1 ceived
1
1
1
1
1
1
1
1
1
1
1
1
1
I
1
I
1
1-----------------------------------------------------1
PSA002
The 'PSi Restart'
conExamine the resulting ABEND dump
1
1
I
1
1 sole
1 for a dynamic picture of the sys- 1
key was pressed
1
1 and caused this ABEND.
l i T h e operator normally
1
1 takes this action when
1
1 an un usual sys tem con 1
1 di tion
occurs, such as
loop or slow
1
1 a system
1
1 machine operation.
1
1 tem's status.
1
I
1
1
1
1
1
1
1
I
1
1
I
1------------------------------------------------1
1 PSA003 1 An
1
I
1
1
unrecoverable DASD 1 Check the unit address in the I/O
I/O error occurred on a I old PSi to find the paging device
1 paging device.
1 in error. This is a hardware erI
1 ror.
Call
IBM
for
hardware
1
1 support.
1
1------------------------------
1
1
1
1
1
1
1
1
1
I
PTR001 1 A segment exception or 1 Inspect the contents of control
1 translation
specifica- 1 registers 0 and 1, and the format
table pointed to
I tion has occurred while 1 of the segment
LOAD REAL 1 by CR 1. One or more of these
1 executing a
1 ADDRESS (LRA)
instruc- 1 tables and registers may contain
1 tion in the DMKPTR mod- 1 invalid
data.
If
CR 1
is
1 ule.
1 invalid, check the contents of
l i t h e VMBLOK pointed to by GR 11,
1
1 especially the address in the
1
1 VMSEG field.
1-----1 PTR002 1
1
Figure 64.
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
---------------------------1
attempting 1 Use BALR14 and
BALR12 in the 1
A program is
l i t o unlock a page frame
I
I whose address exceeds
l i t h e size of real storI
1 age.
L
1
1
I BALRSAVE area of the PSA to iden-
1
1 tify the module attempting to un- 1
1 lock the page frame.
Check for 1
1 the source of the invalid ad- 1
__________________________________________
- - - - J1
1 dress.
CP ABEND Codes (Part 10 of 15)
section 4. Diagnostic Aids
551
r-------------------------------------------------------------------,
1 ABEND 1
I
1
1 Code
1
Reason for ABEND
1
Action
1
1------------------------------------------------------1
I PTR003 1 A program is attempting 1 Use BALR14 and
BALR12 in the 1
1
I to unlock a real stor- 1 BALRSAVE area of the PSA to iden- 1
1
1 age page frame whose 1 tify the module attempting to un- 1
1
1 COR TABLE entry is not I lock the page frame. Check for 1
1
I flagged as locked.
1 the source of the invalid ad- I
I
1
I dress.
I
I------------------·---~---------------------------I
1 PTR004 1 The lock count in the
I
1 CORTABLE entry for the
1
1 page frame being unI
1 locked has been decre1
1 mented to a value that
I
1 is less than O.
1 Check the routines that update I
I the lock count field and CORTABLE I
I entry.
1
1
I
1
1
I
I
-----1
count in
A module attempted to release 1
PTR005
The user page
the VKBLOK (VKPAGES) is
negative.
PTR007
DMKFRE requested a page
for fixed free storage
but DMKPTR determined
that
there
were no
pages left in the dynamic paging area.
more pages than it originally received. The
last module that
called DKKPTR is probably the
module that caused the error.
1
I
I
1
Examine the dump for one of the
following conditions:
1. Excessive
amounts
of free
storage have been allocated by
CP
and
not released
via
DKKFRET. Look for blocks of
identical data and determine
which modules built that data.
2. A block of storage greater
than 4096 bytes was requested.
Requests for large blocks of
free storage require contiguous pages from DKKPTR and as
a result have a higher probability of failure than requests for one page or less.
If possible, change the application to reduce the size of
storage requests. otherwise,
schedule the application when
storage is less fragmented.
----------------------------------------------1
PTR008 1 A CORTABLE entry on the
1 free list points to a
(page table
1 valid PTE
1 entry), but the page is
1 allocated.
1 Pages on the free list should not I
valid PTEs.
Examine the I
determine which module I
1 called DKKPTRFR. The module that 1
1 called DKKPTRFR probably contains 1
1
I an error.
I
------------------------------------I
PTR009
The count of the number
The field DMKPTRSC contains the I
of
resident
shared
number of resident shared pages I
pages was incorrectly
and the field DKKDSPNP contains 1
decremented making the
the number of pageable pages. I
count now less
than
DKKDSPNP must always be greater I
zero.
than DMKPTRSC. Check the routines I
that
update these two
count 1
fields.
L________________________________________________________
.__________JI
Figure 64.
552
1 contain
I dump to
CP ABEND Codes (Part 11 of 15)
VM/370: System Logic and Problem Determination Guide
r--------ABEND I
Code
1
Reason for ABEND
-------------------------------------,
I
1
1
I
Action
--------------------------------------------------1
PTR010 I The count of the number 1 The field DMKPTRRC contains the I
1 of resident
reserved I number
of
reserved
pages. I
I
I
I
I
DMKPTRRC must always be less than
DMKDSPNP. Check the routines that
update
these two count fields
(DMKDSPNP and DMKPTRRC) •
1
I
1
1
A CORTABLE entry to be
placed on the free list
points to a valid PTE
(page table entry), but
the page is allocated.
An abend occurs trying
to honor a deferred reI quest.
I
Pages to be put on the free list
should not contain valid PTEs.
Examine the dump to determine why
the page was not marked invalid
before the call to DMKPTRPT.
I
I
I
1
I
1
pages was incorrectly
decremented so that the
count is now less than
zero.
------------------------------PTR011
----------1
1
1
1
I
I
1
---------------------------------------------------1
PTR012 1 A CORTABLE entry to be 1 Pages to be put on the free list I
I placed on the free list
I points to a valid PTE
I (page table entry), but
1 the page is allocated.
should not contain valid PTEs.
1 Examine the dump to determine why
I the page
was not marked invalid
1 before the call to DMKPTRPT.
I
I
I
I
I
I--------------~-------------------------I
I PTR013 1 DMKPRE requested a page 1 Examine
1
for fixed free storage
but there were no DASD
page
slots
left to
write out the selected
page.
1
1
I
1
I
1
1
1
1
1
1
1
I
I
1
I
1
I
the dump to determine
what was using all the
TEMP
space. Excessive space may be
consumed by large spool files or
not enough TEMP space exists for
paging.
I
1
The reflected
device
IPL to restart the system. If the
status in the CSW is
problem persists, call IBM for
not supported for cersystem support.
tain 3270 remote device
and line protocol I/O
operations.
Specifically, the returned CSW
contains a device status other than CE, DE,
and UE; and, the ending
ccw contains an embedded teleprocessing code
of 02, 03, or 06.
1----------------------1
1 RGA002 I The
status
flag 1
1
I BSCPLAG in the BSCBLOK I
I
I indicates a condition 1
1
1 that is not valid for a I
1
I 3270 line reset func- I
1
I tion
(Teleprocessing I
1
1 code 09).
I
RGA001
1---------------------------------------------------1
1 RNH001 1 An unrecoverable
I/O I Retry. If the problem persists, I
1
I error occurred during I ensure that the 3704/3705 and
1
1 read or write for the I channel hardware are functioning
1
1 3704 or 3705. status I correctly.
program I
1
I indicates
I
1L____________________________________________________________
I failure.
Figure 64.
1
I
1
I
I
~
CP ABEND Codes (Part 12 of 15)
section 4. Diagnostic Aids
553
r---------------------------------------------------------------------,
ABEND I
I
I
Code
I
Reason for ABEND
Action
I
1
---------------------------------------------------------1
RNH002 1 A response that should 1 Verify that the 3704/3705 NCP is 1
I not occur was received
1 from
the
3704/3705
I control program.
I
I operating
correctly.
Use the
I NETWORK TRACE command to deter1 mine the exact cause of the reI sponse.
RPAOOl
The
virtual
address
supplied to DMKRPAGT is
outside of the virtual
storage
being referenced.
RPA002
The virtual
address
supplied to DMKRPAPT is
outside of the virtual
storage
being referenced.
The virtual storage belongs either to the user whose VMBLOK is
pointed to by GR 11 or, if GR 2
in the SAVEAREA indicates a PARM
of SYSTEM, to the system VMBLOK.
Identify the calling program by
means of the return address and
base
register
saved in the
SAVEAREA pointed to by GR 13. If
the virtual address was obtained
from the system's virtual storage, examine the virtual page
allocation routine, DMKPTRVG. If
the virtual
page refers to a
user's storage, attempt to identify the routine that has generated the incorrect address. Verify that the VMSIZE in the relevant VMBLOK reflects the correct
storage size for the system or
user being referenced.
RPA003
The user page count in
the VMBLOK became negative.
A module has attempted to release
more pages than it originally
received. The module that last
called DMKRPA is probably the
module in error.
SCHOOl
The total
number of
interactive users plus
batch
users
in the
scheduler's
queue is
less
than
zero.
A
counter was
probably
decremented incorrectI lYe
1
The field SCHNl is the count of
the number of interactive users
and the field SCHN2 is the count
of the number of batch users.
Check the routines that update
these two count fields (SCHNl and
SCHN2) to determine why their sum
was negative.
I
1
I
1
-----------------------------------------------------1
SCNOOl 1 The VDEVLINK chain is 1 IPt to restart.
If the problem I
I invalid.
A VDEVBLOK 1 persists, examine the VDEVBLOKs 1
I has a link
field that 1 in the link chain as well as the 1
to
another lone whose link field points into 1
I points
I VDEVELOK
associated I the chain but is not in the I
I with the
same
real I chain. Determine what the owner I
1 device.
The
first 1 of the VDEVBLOK was doing at the 1
I VDEVBLOK is not pointed 1 time.
1
1 to by any ot her link I
I
I field in the chain.
I
____________________________________________
- ___________---------1I
Figure 64.
554
CP ABEND Codes (Part 13 of 15)
VM/370: System Logic and Problem Determination Guide
r--------------------------------------I
I
---,
1 ABEND
I Code
I
Reason for ABEND
I
I
I
Action
verify that GR 8 points to a
RDEVBLOK for a CP-owned volume.
If it does not, the error may
originate in the calling program.
Identify the caller by the return
address and base register in the
SAVEAREA pointed to by GR 13, and
try to identify the source of the
incorrect RDEVBLOK address. If
the RDEVBLOK is valid, it may be
that the cylinder number passed
is incorrect. The VDEVELOK for
the device for which the T-disk
was defined may have been destroyed. If the cylinder number
appears valid, examine the allocation record on the real volume
by running DKKFKT (VM/370 Format
program),
invoking the ALLOCATE
option without allocating any new
space. If the output shows that
deallocated cylinder falls within
an area defined for T-disk allocation, the ALOCBLOK chained to
the RDEVBLOK may be destroyed.
TDK001
A program is attempting
to deallocate a cylinder of T-disk space for
which
no
cylinder
allocation
block
(ALOCBLOK) exists.
TDK002
A program is attempting
to
deallocate cylinder(s) of T-disk space
that are not marked allocated.
UDR001
The user directory module is looping trying
to read all of
the
UDIRBLOK page buffers
from the directory device. Or, a directory
containing over 10,816
I users was loaded.
Use the DASD Dump Restore program
to print the UDIRBLOK page buffers from the directory device.
Determine if the chain pointers
are valid.
list
I has an invalid format.
I
I
I
IPL to restart.
If the problem
persists, check the SYSOWN macro
in DMKSYS for validity.
If the
macro is good, print the dump and
examine ito
I VDR003 I The DASD link chain is
I invalid. In the case of
I
I minidisks, attaching a
I
I mini disk that points to
I
I an RDEVBLOK whose count
I
I of users is already zeI
I ro causes this ABEND.
I
I V10002
DMKSCNVU was unable to
I
locate all of the virI
tual I/O control blocks
I
for the virtual unit
I
address associated with
I
the
interrupt
just
1
stacked.
I
1PL to restart.
If the problem
persists, examine the
RDEVSYS
flag. If the RDEVSYS flag is off,
the problem is especially serious; print and examine the dump.
Examine the VDEVBLOK and RDEVBLOK
checking the link chain.
1-------------------------1 VDB002 I The system-owned
I
I
I
I
1-----1
Verify that the unit address in
the field IOBVADD in the IOBLOK
pointed to by GR 10 is valid for
the user who initiated the I/O.
The field IOBUSBR contains the
address of the user's VKBLOK.
If
the address is valid, the integrity of the user's virtual I/O
L----------------------------------------------------------------------~
Figure 64.
CP ABEND Codes (Part 14 of 15)
section 4. Diagnostic Aids
555
r-----------------------------'--------------------------,
I ABEND
I Code
I
I
Reason for ABEND
I
I
Action
1---------------------------------------------------------.;...
I VI0002 I
(cont.)I
I
I
I configuration has probably been
I been destroyed. If the address is
1 not valid, the IOBLOK has been
1 altered, or was built incorrectly
I in the first place.
1
1
1
1
I
VI0003
1
I
DMKICS has returned an
IOBLOK
indicating
a
condition code of 2 was
received from the START
I/O for the operation.
1
Condition code 2 should never be
returned to the virtual I/O interrupt handler.
Its presence
indicates either a failure in the
I/O supervisor (DMKIOS), or that
the status field in the IOBLOK
I (IOBSTAT) has been destroyed.
--------------------------------------------------1
VMAOOl I DMKVMASH was called to
any
shared
1 check if
1 pages were altered. A
I VMABLOK associated with
1 a shared named system
I could not be found.
I
VMA002
I Examine BALR14 for the address of 1
I the module that issues the call. I
I The probable cause of error is
I that the VMBLOK has been overI laid. Examine the CP trace taI ble entries and determine when
I the VMBLOK was overlaid~
DMKVMA was
called to
make a shared
named
system unshared.
However, the SHRTABLE associated
with
the
shared page that was
changed could not be
I located.
I
The SHRTABLE may have been overlaid or the shared page that was
changed was altered by another
virtual machine. If the SHRTABLE
was not overlaid find out which
virtual
machine
altered the
shared page and why it was not
detected.
1
I
I
I
I
I
I
1
I
I
1
I
I
1
--,----------------------------------------------1
VMA003 I A
shared
page
was
and a named
I changed
I system
could not be
for the virtual
I found
I machine.
I
I A shared page was alterd by anI other virtual machine and went by
I undetected.
Investigate
system
I routines
that could allow the
I undetected alteration of a shared
I page.
1---------------------------------I VMA004 I A shared
page
was
1
I changed and the corres1
I ponding VMABLOK could
1
I not be found.
I
I
I
I
I
I
I
I
----------1
I A shared page was altered by 1
I another virtual machine without I
I being detected. Investigate the I
I system routines that could allow I
I an
undetected alter ation of a 1
I
1
I shared page.
1
1----------------------------------------------------1
1 VSPOOl I The virtual
spooling I Verify that the unit
address I
1
I manager could not 10- I (IOBVADm in the IOBLOK is valid. 1
I
I cate all
virtual con- I If the address is valid, the in- I
I
I trol blocks
for an in- I tegrity of the virtual I/O con- 1
I figuration has probably
been de- 1
I
I terrupting unit.
1
I
1 stroyed.
If the address is not 1
1
I
I valid, the IOBLOK has been al- 1
1L
1
1 tered or was built incorrectly.
________________________________
._ _ _ _ _ _ _ - 'I
Figure 64.
556
CP ABEND Codes
(Part 15 of 15)
VM/370: System Logic and Problem Determination Guide
~g~~i~g
Functional error occurred executing
the command for which the user is
responsible,
or the user failed to
supply all the necessary conditions
for executing the command;
or, end of
file or end of tape occurred
(where
applicable) •
If a condition arises during execution of a
command which types out a Warning, Error, Severe
or Terminal error message,
the command passes a
nonzero return code in register 15.
These
return codes have the following values:
~ggDiDg
The user did not specify all the
conditions to execute the command as
intended but these conditions did not
prevent the command from completing
execution. However, the results are
unpredictable.
HC
88:
HC
100: I/O errors,
occurred.
A C"S system restriction prevented
command execution, or the requested
function is an unsupported feature, or
the device requested is unsupported.
or serious
device errors
HC
8:
Device errors for which a
warning
message is issued, or errors have been
introduced into the output file.
HC
104: A
HC
12
Errors in input file.
RC
RC
20:
Invalid character in fileid. The valid
characters are 0-9, a-z, A-Z, at-sign,
pound sign, dollar sign.
256: All unexpected errors for which
system
is responsible,
that
Terminal messages.
HC
24:
The user did not specify
line correctly.
HC
28:
Error occurred while trying to access,
or manipulate a user's files.
For
example: file not found.
RC
32:
The user's file(s)
is not in the
expected format, or the user's file(s)
does
not
contain
the
expected
information.
HC
36:
Error occurred involving the user's
devices for which he is responsible.
For example: disk is read-only.
the command
functional error occurred during
command execution for which the syste.
is responsible.
the
is,
If command execution generates no Warning,
Error, severe or Terminal error messages, the
return code passed in register 15 is zero.
Commands which invoke program products pass
to the user the return code passed by the
program in register 15.
os simulation routines
indicate return codes within the text of the
messages.
Commands or functions of commands
passed to CP pass the return code passed by CP
in register 15.
section 4. Diagnostic Aids
557
Code Error
--S-(DMSFRET) An invalid size was passed to the
DMSFRET macro.
This error exit is taken
if the specified length is not positive.
A nonzero return code upon return from DMSFRES,
DMSFREE or DMSFRET indicates that the request
could not be satisfied.
Register 15 contains
this return code, indicating which error has
occurred.
The codes below apply to the DMSFRES,
DMSFREE and DMSFRET macros, described on the
following pages.
~Qg~
1
(DMSFREE or DMSFRET) User storage pointers
destroyed.
3
(DMSFREE or
DMSFRET)
pointers destroyed.
558
a. The block is not entirely inside either
the low-core free storage area or the
user program area between FREELOWE and
FREEUPPR.
b. The block crosses a page boundary that
separates a page allocated for USER
storage from a
page allocated for
NUCLEUS storage.
Error
(DMSFREE)
Insufficient storage space is
available to satisfy the request for free
storage.
In the case
of a variable
request, the minimum request could not be
satisfied.
2
4
6 (DMSFRET) The block of storage that is being
released was never allocated by DMSFREE.
This error occurs if one of the following
errors is found:
Nucleus
storage
(DMSFREE) An invalid size was requested.
This error exit is taken if the requested
size is not greater than zero.
In the
case of variable requests, this error exit
is taken if the minimum request is greater
than the maximum request. However, the
error is not detected if DMSFREE is able
to satisfy the maximum request.
c. The
block overlaps
another
block
already on the free storage chain.
7 (DMSFRET)
The address
being
released is
boundary address.
given for the block
not a
doubleword
8 (DMSFRES) An illegal request code was passed
to the DMSFRES
routine.
Because the
DMSFRES macro generates all codes, this
error code should never appear.
9
(DMSFRE, DMSFRET,
internal error.
'M/370: System Logic and Problem Determination Guide
or DMSFRES)
unexpected
ABEND RECOVERY
When the abend recovery routine is entered, it
types out the abend message, followed by the
line 'CMS', to indicate to the user that he may
type in his next command.
At this
point, there
available to the user.
are
two
options
First, he may type the DEBUG command.
In
this case,
DMSABN passes control to DMSDBG, to
make the facilities of DEBUG available to him.
DEBUG's PSW and registers are as they were at
the time that the abend recovery routine was
invoked. From DEBUG, the user may alter the PSi
or registers, as he wishes, and type GO to
continue processing, or type RETURN to return to
DMSABN, so that abend recovery can continue.
The second option available is to type in any
other command. If this is done, DMSABN performs
its abend recovery function and passes control
to DMSINT to execute the command that has been
typed in.
The abend recovery function consists
following steps:
of the
1.
The SVC handler, DMSITS, is reinitialized,
and all stacked save areas are released.
2.
"FINIS * * *" is invoked by means of SVC
202, to close all files,
and to update the
user file directory.
3.
If the EXEC interpreter (EXECTOR module) is
in storage, it is released.
~acros
4.
All link blocks allocated by the OS
simulation routine DMSSLN are freed.
5.
If VSAM or Access Method Services are still
active, call DMSVSR for cleanup.
6.
All FCB and DOSCB pointers are zeroed
7.
All user storage is released.
8.
The amount of system free storage that
should be allocated is computed.
This
figure is compared against the amount of
free storage that is actually allocated.
If the two are equal, then storage recovery
can be considered successful.
If they are
unequal, then a message is sent to the
user.
~ut.
There are certain times, such as when the SVC
handler's pointers are modified, that the system
can neither continue processing nor try to
recover.
In these cases, DMSERR with the option
HALT=YES is specified to cause a message to be
typed out, after which a disabled wait state PSi
is loaded.
In CP mode, the programmer can examine the
PSi, whose address field contains the address of
the instruction following the call to the DMSERR
macro. He can also examine all the registers,
which are as they were when the DMSERR macro was
invoked.
Figure 65 lists the CMS ABEND codes and
describes the cause of the ABEND and the action
required.
Section 4. Diagnostic Aids
559
r--------------------------------------------------------,
I ABEND I Module I
I Code I
Name
I
Cause of ABEND
I
I
I
I
Action
1-------------------------------------------------1
I 001
I
I
I
I DMSSCT
I
I
I
I
I
I
I
The problem program encountered an input/output error
processing
an os macro.
Either the associated DCB
did not have a SYNAD routine specified or the I/O
error
was
encountered
processing
an
OS CLOSE
macro.
Message
DMSSCT120S
indicates the possible
cause of the error.
Examine
the
error
1 message and take the
1 action indicated.
I
I
I
I
I
1
I
1
1
1
1
I
1
1
1
1 034
I
I
I DMSVIP 1 The problem program encoun- 1 Refer to the ~Q~L!~ I
1
1 tered an I/O error while 1 H~2~~~2
R~fe!~~£~, 1
1
1 processing a VSAM action I Order No. GC33-5379, 1
1
I
1
I
I
I
1
1
I
I
I
I
I
I
I
I
I
I
1
I
1
I
I
1
1
1
1----------------------------------------------------1
OCx
I macro
I to determine the cause 1
1
under
DOS/VS for
which there is no OS equi1 valent.
An internal error
1 occurred in a DOS VSAM rouI tine.
1
DMSITP
The specified hardware exception occurred at a specified location. "x"
is
the type of exception:
ox
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F
of the VSAM error.
I
I
I
I
1
Type DEBUG to examine
the PSW and registers
at the time of the
exception.
!I.E~
IMPRECISE
OPERATION
PRIVILEGED OPERATION
EXECUTE
PROTECTION
ADDRESSING
SPECIFICATION
DECIMAL DATA
FIXED-POINT OVERFLOW
FIXED-POINT DIVIDE
DECIMAL OVERFLOW
DECIMAL DIVIDE
EXPONENT OVERFLOW
EXPONENT UNDERFLOW
SIGNIFICANCE
FLOATING-POINT DIVIDE
1-------------------------------------I OFO
I
I DMSITS I Insufficient free storage
I
I is available to allocate a
I
I save area for an SVC call.
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
1
I
I If
the
ABEND
was
I caused by an
error in
I the
application pro-
I gram, correct it; if
I not, use the CP DEFINE
1 command
to increase
I the
size of virtual
1 storage and then reI start CM S.
I
1--------------------------------------1
I OF1
I DMSITS 1 An invalid half word code is I Enter
DEBUG and type I
I GO.
Execution conti- I
I
I
I associated with SVC 203.
I _ _ _._______________________________________________________
I
I
I nues.
L
- 'I
Figure 65.
560
CMS ABEND Codes (Part 1 of 3)
VM/370: System Logic and Problem Determination Guide
r-------------------------------1 ABEND 1 "odule 1
Cause of ABEND
1
1 Code 1
1
DMSITS
1
1
1
1
1
1 OF2
1
Action
The C"S nesting level of 20
has been exceeded.
-------1
None. ABEND recovery 1
takes place when the 1
next cOllmand is en- 1
1 tered.
1
1
1
1
1
1----------------------------------------------1
1 OF3 1 D"SITS 1 C"S SVC
(202 or 203) in- 1 Enter DEBUG and type 1
1
1
1 struction was executed and 1 GO. Control returns to 1
1
1
1 prov~s~on was made for an 1 the point to which a 1
would 1
1
1
1 error return from the rou- 1 normal return
1
1
1
1
1
1 OF4
1
1
1 tine processing
1 call.
the
1 have been made.
1
SVC
1
1
--------------------------1
key stack over- 1 Enter DEBUG and type
1 GO.
Execution conti1 nues and the D"SKEY
1
1
1 macro is ignored.
1------------- 1
1 OF5 1 D"SITS
The D"SKEY key stack under- 1
1
1
1 flowed.
1
1
1
1
1
1 OF6
1
D"SITS
The D"SKEY
flowed.
1----------------------1
1
1
1
1
1
--------1
1 DMSITS 1 The DMSKEY key stack was
1
1 not empty when
control re1
1 turned from a command or
1
1 function.
1
1
1 OF7
1
1
DMSFRE
1
1-----1 OF8
1 D"SFRE
1
1
1
1
1
1
1
Enter DEBUG and type
GO.
Control returns
from
the command or
function as if the key
stack had been empty.
Occurs
when
TYPCALL=SVC
When a system ABEND
(the default) is specified
occurs r use DEBUG to
in the DMSFREE or DMSFRET
attempt recovery.
.acro.
1
1
1
1
1
1
1
1
1
1
----------------------1
Occurs when TYPCALL=BALR is 1 When a system ABEND 1
specified in the D"SFREE or 1 occurs r use DEBUG to 1
1 attempt recovery.
1
1 DMSFRET "acro devices.
1------------------------------------------1
1 101
1
1
1
1
1 104
1
1
1
1 DMSSVN 1 The wait count specified in
1
1 an OS WAIT .acro was larger
1
1 than the
nu.ber of EeBs
1
1 specified.
DMSVIB
1
1
1 155
1 D"SSLN
1
1
1-------
1
1
1
1
1
1
1
1
1
1
1_______
1 15A
1 DMSSLN
1
1
1
1
1
I
1
1 Examine the
program
1 for
excessive wait
1 count specification.
1
1
1
1
1
1
The OS interface to DOS/VS
See the additional er- 1
VSAM is unable to continue
ror message accollpany- 1
execution of the problem
ing the ABEND message r 1
program.
correct the error r and I
1 reexecute the progra m. 1
---------------------------1
1 See the last LOAD"OD 1
(D"SMOD) error message 1
1 for error description. 1
1 In the case of an I/O I
1 error r
recrea te the I
1 module. If the module I
1 _
is _missing,
create
__
_____
_ _ _it.
_ 0_11
Error during LOAD"OD after
an OS LINK r LOAD r XCTL r or
ATTACH. The compiler switch
is on.
Severe error during load
(phase not found)
after an
OS LINK r
LOAD r
XCTL r
or
ATTACH. The compiler switch
1 is on.
1
1 See
last
LOAD error
(D"SLIO)
for
1 the error description.
1 In the case of an I/O
1 error,
recrea te the
1 message
1
I
I
I
1
1
L-----------------------------------------------------_________________
J
Figure 65.
C"S ABEND Codes (Part 2 of 3)
section 4. Diagnostic Aids
561
r----------------------------------------------------------------------,
ABEND I Module I
II Code
I Name I
Cause of ABEND
1I
Action
1I
1----------------------------------------------------------------------1
I 15A
1
1
1 text
deck or TXTLIB. 1
I cont·1
1
1 If either is
I
1
I
I crea te it.
missing, 1
I 174
I
I DMSVIB I The as
interace to DOS/VS 1 See the additional er- I
1
1 VSAM is unable to
continue I ror message accompany- 1
I
I-----.------------------------------.-----------------------------1
I
I
1 execution
I
I
1
I
1 program.
I
I DMSVIB
1 The
of
the
problem I ing the ABEND message, 1
I correct the error, and 1
I reexecute the program. I
1------------------------------_·_------------------------I
I
177
as
interface
to DOS/VS I See the additional ercontinue 1 ror message accompanythe problem I ing the ABEND message,
I correct the error, and
I reexecute the program.
I
I
I DMSVIP I VSAM is unable to
I
I
1
I
I
I
1 execution
I program.
I
1 240
I
I DMSSVT
1
I NO work
area was
1 in the
parameter
1
I
I an as RDJFCB macro.
1
I
1
I
I
I
the as XDAP macro 1 unsupported XDAP macro I
been issued
by the I or for SVC O.
I
I problem program.
I
I
1 704
I
1
1
1
1 DMSSMN
I
1
1
1
1
I
I
1
1
1 705
1
1
I
1
1
1
1
1
1 (SVC 5) was issued specify- 1 that it specifies
1 ing
the L operand.
This 1 release of only
1 operand is not supported by 1 area at a time.
1 CMS.
1
the
one
1
1 SVC 4,
re-
I
1 issued that
of
I
I
1
1
1---------------------------------_·_--------------------I
provided 1 Check RDJFCB
list for 1 cation.
specifi- I
1
I
1
1--------------------------------_·_-----------------------1
1 400
I DMSSVT 1 An invalid or unsupported I Examine
program for I
I form of
I has
1-----------------------------_·_-------------------An as GETMAIN macro (SVC 4)
WaS issued specifying the
LC or LU operand. These
operands are not supported
by CMS.
1
1
1
1
1
Change the program so
that
it
specifies
allocation of only one
area at a time.
1---------------------------------------------------------------------1 DMSSMN 1 An
as
FRBEMAIN
macro 1 Change the program so
1---------------------------------------------------------------------1 DMSSMN 1 An as GETMAIN macro
(804 - 1 Check the program for
1 804
1 80A
1
1
SVC 10)
was
requested eil i t h e r zero bytes of storage,
1
I or more storage than
was
1
1 available.
1 available,
increase
1 the size of the virtu-
I
1
1 al machine and retry.
1 90A
1
I
1
I
1
SOA -
I
1 a
valid
GET MAIN
1 quest. If more storage
1 was requested than was
1-------------------------------------·-------------------------------1
1 905
1 DMSSMN
An as FREEMAIN macro (90S - 1 Check the program for 1
SVC 5, 90A - SVC 10)
was
issued specifying an area
l i t o be released whose ad1
I
dress was not on a doubleword boundary.
1
1
1 a valid
FREEMAIN re- 1
1 quest; the address may 1
1 have been
incorrectly 1
1 specified or modified.
'I
1
1
1-------------------------------------·-------------------------------1
1 A05 I DMSSMN
An as FREEMAIN macro (A05 - 1 Check the program for I
1 AOA
I
1
1
SVC 5, AOA SVC 10)
was 1
issued specifying an area 1
l i t o be released which over- 1
1
I
laps an existing free area. I
a valid FREEMAIN re- I
quest;
the
address 1
and/or length may have 1
been incorrectly spec- I
modified.
I _ified
__ _ _ _ _ _
_ _ _ _or
___
_ _ _ _ _ _ _ _ _ - '1
1L _ _ _ ._ I
Figure 65.
562
CMS ABEND Codes (Part 3 of 3)
VM/370: System Logic and Problem Determination Guide
------------------------------,
r---
I Message
I Code
DMTAXS1011
DMTAXS1021
DMTAXS103E
DMTAXS1041
DMTAXS1051
DMTAXS1061
DMTAXS1071
DMTAXS108E
DMTAXS5201
DMTAXS5211
DMTAXS5221
DMTAXS5231
DMTAXS524E
DMTAXS525E
DMTAXS526E
DMTAXS6401
DMTCMX0011
DMTCMX0031
DMTCMX2001
DMTCMX201E
DMTCMX202E
DMTCMX203E
DMTCMX204E
DMTCMX205E
IGenerated
lat Label
ITAGPEND
IACCEPEND
IACCEPURG
ICLOOSCAN
I
ICLOIPURG
IFILSTRY
10PENPOOF
IUNPECHEK
10PENRDER
ICHANGE
ICHANHO
ICHANNOH
ICHANSCAN
IORDBNEXT
ICHANGE
IORDBCHEK
IPURGCHEK
ICHANGE
10RDECHEK
I PURGCHEK
ICHANGE
IORDBCHEK
IPURGCHEK
IPUBGDONE
ICMXFINXT
ICMXM003
ICMXLGOT
ICMXHIT
ICMXLGOT
ICMXMISS
IDEFNOLNK
I MSGNOLNK
IA1FLKGOT
IA1FSTOW
ICHALKGOT
I L2FLKGOT
IQYOFILE
I QYOFNULL
ICHALKGOT
I CHANTBRM
ICHASCAN
IFLUMORE
ILOTERM
IL1TERM
IQYTOOMCH
IOYOFILE
IQYOLINK
I QYOSYSTM
IROSCAN
ICHACLASS
ICHACOPY
Message Text
FILE
FILE
FILB
FILE
I
I
--_·-----1
'spoolid' ENQUEUED ON LINK 'linkid'
I
'spoolid' PENDING FOR LINK 'linkid'
I
'spoolid' RBJECTED -- INVALID DESTINATION ADDRESS
SPOOLED TO 'userid2' -- ORG 'locid l' (' userid 1')
mm/dd/yy hh:mm:ss
FILE 'spoolid' PURGED
FILE 'spoolid'MISSING -- DEQUEUED FROM LINK 'linkid'
nn PENDING FILES FOR LINK 'linkid' MISSING
SYSTEM ERROR READING SPOOL FILE 'spoolid'
File 'spoolid' CHANGED
FILE 'spoolid' HELD FOR LINK 'linkid'
FILE 'spoolid' RELEASED FOR LINK 'linkid'
LINK 'linkid' QUEUE REORDERED
FILE 'spoolid' ACTIVE -- NO ACTION TAKEN
FILE 'spoolid' IS FOR LINK 'linkid' -- NO ACTION TAKEN
FILE 'spoolid' NOT FOUND -- NO ACTION TAKEN
nn FILE(S) PURGED ON LINK 'linkid'
FREE STORAGE = nn PAGES
LINK 'linkid' EXECUTING: (command line)
RSCS
INVALID COMMAND 'command'
INVALID LINK 'linkid'
INVALID SPOOL FILE ID 'spoolid'
INVALID KEYWORD 'keyword'
CONFLICTING KEYWORD 'keyword'
.J
Section 4. Diagnostic lids
563
r-----------------------------·-----------------------------,
I Message
I Code
DHTCMX205E
(cont.)
DMTCMX206E
DMTCHX208E
DMTCMX3001
DMTCMX301E
DMTCMX302E
DHTCMX303E
DMTCMX304E
DMTCMX5401
DMTCHX5411
DMTCMX542E
DMTCMX543E
DMTCMX544E
DMTCMX5501
DMTCMX551E
DMTCMX 552E
DMTCMX5601
DMTCHX561E
DMTCMX6511
DMTCMX6521
IGeneratedl
lat Label I
CHAHOLD
CHANOHOL
CHAPRIOR
FLUKEYWD
LCTKEYWD
ROCLASS
ROKEEP
ROLINE
ROT ASK
ROTYPE
CHACLASS
CHACOPY
CHADIST
CHANAME
CHAPRIOR
LOHOLD
LOTRACE
IL1FLKGOT
I QUERY
IROCLASS
I ROCLMULT
IROKEEP
IROLINE
I ROTASK
IROTYPE
IDISCONN
I MSGNOLNK
IMSGNOUSR
ICMXALRDY
ICMXALRDY
I MSGNOLNK
ICMD
I LOFLKGOT
L1FLKGOT
L2FLKGOT
MSG
CMXALRDY
DEFLKNEW
DEFLKNEW
DEFINE
DEFNEXT
DEFNOLNK
DEFLKNEW
DELDELET
DELETE
DELETE
DISCHARG
DISCONN
QY1STAT
IQY1SNOD
I
IQY1DEF
I QY lQUEUE
I QY lINACT
IQY2STAT
IQY2STAT
IQY2RSS
I
DMTCMX6631 IQY2VNOH
I
DM TCMX 6531
DMTC MX6541
DMTCMX6551
DMTCMX6601
DMTCMX6611
DMTCMX6621
564
I
I
Message Text
INVALID OPTION 'keyword'
'option'
INVALID USER 10 'userid'
ACCEPTED BY TASK
REJECTED BY TASK
LINK 'linkid' IS
LINK 'linkid' IS
'task'
'task' -- PREVIOUS COMMAND ACTIVE
NOT DEFINED
NOT ACTIVE
REJECTED BY TASK 'task' NOT RECEIVING
NEW LINK 'linkid' DEFINED
LINK 'linkid' REDEFINED
LINK 'linkid' ACTIVE -- NOT REDEFINED
LINK 'linkid' NOT DEFINED
LINK LIMIT REACHED
LINK 'linkid' NOT DEFINED -- LIMIT REACHED
LINK 'linkid' NOW DELETED
LINK 'linkid' ACTIVE -- NOT DELETED
LINK 'linkid' HAS A FILE QUEUE -- NOT DELETED
RSCS DISCONNECTING
USERID 'userid' NOT RECEIVING
LINK 'linkid' INACTIVE
LINK 'linkid' ACTIVE 'type' 'vaddr' c (HOINOH) (DRINOD)
(TRAITREINOT)Q=m P=n
LINK 'linkid' DEFAULT 'task' 'type' 'vaddr' c R=m
LINK 'linkid' Q=m P=n
FILE 'spoolid' 'locid' 'userid' CL a PR mm REC nnnnnn
FILE 'spoolid' INACTIVE ON LINK 'linkid'
FILE 'spoolid' ACTIVE ON LINK 'linkid'
FILE 'spoolid' ORG 'locid' 'userid' mm/dd/yy hh:mm:ss
zzz TO 'locid' 'userid' VIA 'linkid'
FILE 'spoolid' PR am CL a CO nn (HOINOH) DI 'distcode',
NA (' fn ft' I' dsname')
VH/370: System Logic and Problem Determination Guide
--------'
r--------------------------------------------·--------.,
IGeneratedl
I
I Message
I Code
lat Label I
Df'lTCMX664E IQY2RSS
I QY2STAT
IQY2VM
IQY2VNOH
DMTCMX6101 IQYSYACT
DMTCMX6111 IQYM611
DMTCMX6121 IQYSYNEXT
DMTCMX613I.IQYM613
DMTCMX1001 ISTALNGOT
DMTCMX101E ISTACREAT
I
DMTCMX102E ISTACREAT
DMTCMX103E
I
STACREAT
DMTCMX104E
STACREAT
DMTCMX105E
STACRERR
DMTCMX106E
STACRERR
DMTCMX101E
STACRERR
DMTCMX108E
STACRERR
DMTCMX109E
STACRERR
DMTCMX110E STAMAXER
DMTCMX150E STANOTCL
DM TCMX151 I ICMXALRDY
I
DMTINI402T IINIEXIT
DMTINI401R ASKQUEST
DMTINI408R IPLDISK
DMTINI409R NUCCYLN
DMTINI410R IPLZERO
DMTINI431S WRERROR
DMTINI419E BINERR1
DMTINI480E DECERRl
RDORWRT
DMTINI481E IPLZERO
DMTINI482E BADIPLD
DMTINI483E NUCCYLN
DMTNPT010E IOERRPRT
DMTNPT108E VMSGET
DMTNPT1411 NPTEINIT
DMTNPT 1421 NPTEINIT
DMTNPT1431 LINEDIS2
ILINEDROP
DMTNPT1441 IPUTOPEN
I
DMTNPT1451 I PUTCLS 1
I
DMTNPT1461 IGETGOT2
DMTNPT1411 I GET PURGE
DMTNPT 1491 ITRPRT
I
DMTNPT190E I VMSPl
DMTNPT5101 IGTBKMSG
DMTNPT511E ISBKFWDN
Message Text
I
FILE 'spoolid' NOT FOUND
LINK 'linkid' ACTIVE -- LINE 'vaddr' (HOINOH)
LINK 'linkid' INACTIVE
NO LINK ACTIVE
NO LINK DEFINED
ACTIVATING LINK 'linkid' 'task' 'type' 'vaddr'
NO SWITCHED LINE AVAILABLE -- LINK 'linkid' NOT
ACTIVATED
LINE 'vaddr' IS IN USE BY LINK 'linkidl' -- LINK
'linkid2' NOT ACTIVATED
DEV 'cuu' IS NOT A LINE PORT -- LINK 'linkid' NOT
ACTIVATED
LINE 'vaddr' CC=3 NOT OPERATIONAL -- LINK 'linkid' NOT
ACTIVATED
DRIVER 'type' NOT FOUND ON DISK 'vaddr' -- LINK
'linkid' NOT ACTIVATED
FATAL ERROR LOADING FROM 'vaddr' -- LINK 'linkid' NOT
ACTIVATED
DRIVER 'type' FILE FORMAT INVALID
LINK 'linkid' NOT
ACTIVATED
VIRTUAL STORAGE CAPACITY EXCEEDED
LINK 'linkid' NOT
ACTIVATED
TASK NAME 'task' ALREADY IN USE -- LINK 'linkid' NOT
ACTIVATED
MAX (nn) ACTIVE -- LINK 'linkid' NOT ACTIVATED
LINK 'linkid' ALREADY ACTIVE
NO ACTION TAKEN
LINK 'linkid' ALREADY ACTIVE -- NEW CLASS(ES) SET AS
REQUESTED
IPL DEVICE READ I/O ERROR
REWRITE THE NUCLEUS? Y OR N
IPL DEVICE ADDRESS = ccu
NUCLEUS CYL ADDRESS = nnn
ALSO IPL CYLINDER O? Y OR N
IPL DEVICE WRITE I/O ERROR
INVALID DEVICE ADDRESS - REENTER
INVALID CYLINDER NUMBER - REENTER
INVALID REPLY - ANSWER YES OR NO
IPL DEVICE ERROR - REENTER
NUCLEUS OVERLAYS CMS FILES - RECOMPUTE
ERROR cuu SIOCC cc CSW CSW SENSE sense CCW ccw
SYSTEM ERROR READING SPOOL FILE 'spoolid'
LINE 'vaddr' READY FOR CONNECTION TO LINK 'linkid'
LINK 'linkid' LINE 'vaddr' CONNECTED
LINK 'linkid' LINE 'vaddr' DISCONNECTED
RECEIVING: FILE FROM 'locid1' ('namel') FOR 'locid2'
('name2')
RECEIVED: FILE FROM 'locid1' ('namel') FOR 'locid2'
('name 1')
SENDING: FILE 'spoolid' ON LINK 'linkid', REC nnnnnn
SENT: FILE 'spoolid' ON LINK 'linkid'
LINK 'linkid' LINE ACTIVITY: TOT= mmm; ERRS= nnn;
TMOUTS= ppp
INVALID SPOOL BLOCK FORMAT ON FILE 'spoolid'
FILE 'spoolid' BACKSPACED
NO FILE ACTIVE ON LINK 'linkid'
----'
Section 4. Diagnostic Aids
565,.
r--~------------------------------------
I Message
I Code
DMTNPT5701
DMTNPT571E
DMTNPT5801
DP!TNPT581E
DP!TNPT5901
DP!TNPT591E
DP!TNPT6001
DMTNPT6101
DP!TNPT6llI
DMTNPT612E
DMTNPT750E
DMTNPT7521
DMTNPT801I
DMTNPT8021
DMTNPT8031
DMTNPT8l0E
DMTNPT811E
DMTNPT902E
DMTNPT903E
DMTNPT904E
DMTNPT9051
DMTNPT934E
DMTNPT936E
DMTREXOOOI
DMTREX0021
DMTREX080E
DMTREX090T
DHTREX091T
DMTSML070E
DMTSML108E
DMTSML1411
DMTSML 1421
DMTSML1431
DMTSML 1441
DMTSML1451
DMTSML1461
DMTSML1471
DMTSML1491
DMTSML 1701
DHTSML190E
DMTSML5101
DMTSML511E
DHTSML5301
DMTSML5701
DHTSML571E
DMTSML5801
DHTSML581E
DMTSML5901
DHTSML591E
566
IGeneratedl
lat Label I
SETDRAIN
SETDRERl
GETFLUSH
SETFLUSH
GETFLSHE
SETFREE
SETFRER1
GDGODNE
SETHOLD
GETFILE
SETHLDIP!
GETFILE
SETHLDE1
SETSTRT1
SETSTART
SETTR 1
SETTR2
SETTRACE
SETTRE1
SETTRE2
CONFoCKl
SPASS
SGNERR
NPTGETX
PUTCLOSE
GETGOTl
REXICGOT
TERLHIT
TERLHIT
REXPTERM
REXITERM
IOERRPRT
VMSPGET
ISIO
SIGNOK
EOJ
JOUTPUT
PCONT
UOUTPUT
JCLOSE1
PCLOSE
UCLOSE
RLOCl
RDEOF
TRPRT
WGET2
VMSPl
RDBKMSG
SBKFWDN
SETCMD
SETDRAIN
$USRNPUN
SETDRERl
RDFLUSH
SETFLUSH
RDFLSHER
SETFREE
SETFRERl
Message Text
LINK
LINK
FILE
FILE
'linkid' NOW SET TO DEACTIVATE
'linkid' ALREADY SET TO DEACTIVATE
'spoolid' PROCESSING TERMINATED
'spoolid' NOT ACTIVE
LINK
LINK
FILE
LINK
'linkid' RESUMING FILE TRANSFER
'linkid' NOT IN HOLD STATUS
'spoolid' FORWARD SPACED
'linkid' TO SUSPEND FILE TRANSMISSION
----,
I
I
LINK 'linkid' FILE TRANSMISSION SUSPENDED
LINK 'linkid' ALREADY IN HOLD STATUS
LINK 'linkid' ALREADY ACTIVE -- NO ACTION TAKEN
LINK 'linkid' STILL ACTIVE -- DRAIN STATUS RESET
LINK 'linkid' ERROR TRACE STARTED
LINK 'linkid' TRACE STARTED
LINK 'linkid' TRACE ENDED
LINK 'linkid' TRACE ALREADY ACTIVE
LINK 'linkid' TRACE NOT ACTIVE
NON-SIGNON CARD READ ON LINK (linkid)
PASSWORD (password) on LINK (linkid) IS INVALID
SIGNON KEYWORD (keyword) INVALID
SIGNON OF LINK 'linkid' COMPLETE
ID MISSING ON LINK 'linkid' -- INPUT FILE PURGED
NO REMOTE PUNCH AVAILABLE ON LINK 'linkid' -- FILE
'spoolid' PURGED
RSCS (VER v, LEV 1, mm/dd/yy) READY
LINK 'linkid' DEACTIVATED
PROGRAM CHECK -- 'linkid' DEACTIVATED
PROGRAM CHECK IN SUPERVISOR -- RSCS SHUTDOWN
INITIALIZATION FAILURE - RSCS SHUTDOWN
I/O ERROR -- SIOCC -- CSW -- SENSE -- CCW
SYSTEM ERROR READING SPOOL FILE 'spoolid'
LINE 'vaddr' READY FOR CONNECTION TO LINK 'linkid'
LINK 'linkid' LINE 'vaddr' CONNECTED
LINK 'linkid' LINE 'vaddr' DISCONNECTED
RECEIVING: FILE FROM '10cid1' ('namel') FOR '10cid2'
(' name2')
RECEIVED: FILE FROM 'locidl'
(' name 2 ')
('namel') FOR '10cid2'
SENDING: FILE ~spoolid' ON LINK 'linkid', REC nnnnnn
SENT: FILE 'spoolid' ON LINK 'linkid'
LINK 'linkid' LINE ACTIVITY: TOT= mmm; ERRS= nnn;
TMOUTS= ppp
FROM 'linkid': (MSG message text)
INVALID SPOOL BLOCK FORMAT ON FILE 'spoolid'
FILE 'spoolid' BACKSPACED
NO FILE ACTIVE ON LINK 'linkid'
COMMAND FORWARDED ON LINK 'linkid'
LINK 'linkid' NOW SET TO DEACTIVATE
LINK 'linkid' ALREADY SET TO DEACTIVATE
FILE 'spoolid' PROCESSING TERMINATED
FILE 'spoolid' NOT ACTIVE
LINK 'linkid' RESUMING FILE TRANSFER
LINK 'linkid' NOT IN HOLD STATUS
VM/370: System Logic and Problem Determination Guide
r----------I Message
I Code
DMTSML6001
DMTSML6101
DMTSML6111
DMTSML612E
DMTSML750E
DMTSML 7521
DMTSML8011
DMTSML8021
DMTSML8031
DflTSML810E
DMTSML811E
DMTSML901E
IGeneratedl
lat Label I
RDGODNE
SETHOLD
ALLHLD
SETHLDIM
SETHLDE1
SETSTRT 1
SETSTART
SETTR1
SETTR2
SETTRACE
SETTRE1
SETTRE2
SMLIERR1
DMTSML902E MC7ERR
DMTSML903E MC7A
DMTSML9051 IMC7B
DMTSML906E ISMLIERR2
I
DMTSML934E IJCLOSE
DMTSML935E IRDNOHLD
I
Message Text
FILE 'spoolid' FORWARD SPACED
LINK 'linkid l TO SUSPEND FILE TRANSMISSION
LINK 'linkid' FILE TRANSMISSION SUSPENDED
LINK 'linkid' ALREADY IN HOLD STATUS
LINK 'linkid' ALREADY ACTIVE -- NO ACTION TAKEN
LINK 'linkid' STILL ACTIVE -- DRAIN STATUS RESET
LINK 'linkid' ERROR TRACE STARTED
LINK 'linkid' TRACE STARTED
LINK 'linkid' TRACE ENDED
LINK 'linkid' TRACE ALREADY ACTIVE
LINK 'linkid' TRACE NOT ACTIVE
INVALID SML MODE SPECIFIED -- LINK 'linkid' NOT
ACTIVATED
NON-SIGNON CARD READ ON LINK (linkid)
PASSWORD (password) ON LINK (linkid) IS INVALID
SIGNON OF LINK 'linkid' COMPLETE
INVALID SML BUFFER PARAMETER -- LINK 'linkid' NOT
ACTIVATED
ID CARD MISSING ON LINK 'linkid' -- INPUT FILE PURGED
LINK 'linkid' IN RJE MODE -- PRINT FILE 'spoolid'
____________________ - - - - - J
PURGED
section 4. Diagnostic lids
567
The SVCTRACE command records information for
all SVC calls. When the trace is terminated,
the information recorded up to that point is
printed at the system printer.
In addition, several CMS commands produce or
print load maps.
These load maps can locate
storage areas while debugging programs.
DEBUGGING WITH CMS
This section describes the debug tools that CMS
provides. These tools can be used to help you
debug CMS or a problem program.
In addition, a
CMS user can use the CP commands to debug.
Information that is often useful in debugging is
also
included.
The
following topics
are
discussed in this section:
•
•
CMS debugging commands
DASD dump restore program
CMS provides two commands that
debugging: DEBUG and SVCTRACE.
execute from the terminal.
are useful in
Bot h commands
The debug environment is entered whenever:
•
•
•
The DEBUG command provides support for debugging
programs at a terminal.
The virtual machine
operator can stop the program at a specified
location and examine and alter virtual storage,
registers, and various control words. Once CMS
is in its debug environment, the virtual machine
operator can request the various DEBUG options.
However, in the debug environment, all of the
other CMS commands are considered invalid.
Any DEBUG subcommand may be entered if CMS is
in the debug environment and if the keyboard is
unlocked. The following rules apply to DEBUG
subcommands:
1.
No operand should be longer than eight
characters. All operands longer than eight
characters are left justified and truncated
on the right after the eighth character.
2.
You must use the DEFINE subcommand to
create all entries in the DEBUG symbol
table.
3.
The DEBUG subcommands can be truncated.
The following is a list of all valid DEBUG
subcommands and their minimum truncation.
The DEBUG command is issued
A breakpoint is reached
An external or program interruption occurs
CMS does not accept other commands while in
the debug environment.
However, while in the
debug environment, the options of the DEBUG
command can:
•
DEBUG
set breakpoints
(address stops)
that stop
program execution at specific locations.
Minimum
2!!!!£2!!!!gng
BREAK
CAW
CSW
DEFINE
DUMP
GO
GPR
HI
ORIGIN
PSW
RETURN
SET
STORE
Display the contents of the CAW
(channel
address word), CSW (channel status word), old
PSW
(program status
word), or
general
registers at the terminal.
•
Change the contents of the control words
(CAW, CSW and PSW) and general registers.
•
Dump all
printer.
•
Display the contents of up to 56 bytes
virtual storage at the terminal.
•
store data in virtual storage locations.
•
Allow an origin or
base
specified for the program.
•
Assign symbolic
loca tions.
or part of
virtual storage
at the
of
I
address
to
be
Truncation
----BR---CAW
CSW
DEF
DU
GO
GPR
HI
OR
PSi
RET
SET
ST
X
One way to enter the debug environment is to
issue the DEBUG command. The message
DMSDBG7281 DEBUG ENTERED
names to
specific
storage
•
Close all open files and 1/0 devices
update the master file directory.
•
Exit from the debug environment.
,568
and
appears at the terminal. Any of the DEBUG
subcommands may be entered.
To continue normal
processing, issue the RETURN subcommand.
Whenever a program check occurs, the DMSABN
routine gains control. Issue the DEBUG command
at this time if you want CMS to enter its debug
environment.
VH/370: System Logic and Problem Determination Guide
Whenever a breakpoint
is encountered,
program check occurs. The message
a
DMSDBG728I DEBUG ENTERED
BREAKPOINT II AT XXXXX
appears on the terminal.
Follow the same
procedure to
enter subcommands
and resume
processing as with a regular program check.
An external interrupt, which occurs when the
CP EXTERNAL command is issued, causes CMS to
enter its debug environment. The message
DMSDBG728I DEBUG ENTERED
EXTERNAL INTERRUPT
appears on the console.
Any
subcommands may be issued. To
debug
environment
after
interruption, use GO.
of the DEBUG
exit from the
an
external
While CMS is in its debug environment, the
control words and low storage locations contain
the debug program values.
The debug program
saves the control words and low storage contents
(X'OOI Xll001) of the interrupted routine at
loca tion X I CO '.
Breakpoints should be set after a program is
loaded, but
before it
executes.
When
a
breakpoint
is
encountered
during
program
execution,
execution stops
and the
debug
environment is entered. Iou can then use the
other DEBUG subcommands to analyze the program
at that particular point.
Registers, storage,
and control words can be examined and altered.
After you finish analyzing the program at this
point in its execution,
issue the GO subcommand
to resume program execution.
Breakpoints are
set before
the program
executes.
They
are
set
on
instruction
(halfword) boundaries at locations that contain
operation codes. After setting all the desired
breakpoints, issue the RETURN subcommand to exit
from the debug environment.
Then issue the CMS
START command to begin program execution.
The first operand of the BREAK subcommand
(id) assigns an identification number (0-15) to
the breakpoint. If the identification number
specified is the same
as a currently set
breakpoint, the previous breakpoint is cleared
and the new one is set.
The following is a detailed discussion of the
possible DEBUG sUbcommands.
Use the BREAK subcommand to set breakpoints
which stop execution of a program or module at
specific
instruction
locations,
called
breakpoints.
Issuing
the BREAK
subcommand
causes a single breakpoint
to be set.
A
separate BREAK subcommand must be issued for
each breakpoint desired.
A
maximum of 16
breakpoints (with
identification numbers
0
through 15)
may be in effect at one time; a~y
attempt to set more than 16 breakpoints 1S
rejected.
The format of the BREAK subcommand
is:
..--------
I BReak I id {Symbol}
I - -_ _ _ _
I __
hexloc
L
-----------------,I
id is a decimal number, from
identifies the breakpoint.
The second operand of the BREAK subcommand
(symbol
cr hexloc)
indicates the
storage
location of the breakpoint.
If the operand
contains any nonhexadecimal
characters, the
DEBUG symbol table is searched for a matching
symbol entry.
If a match is
found, the
breakpoint is
set at the
storage address
corresponding to that symbol,
provided that the
storage address
is on an
even (halfword)
boundary.
If no match is found in the DEBUG
symbol table (and the
operand is a valid
hexadecimal number), the
second operand is
treated as the hexadecimal representation of the
storage address.
When the second operand is a
valid hexadecimal number, this number is added
to the program origin. If the resulting storage
address is on a half word boundary and is not
greater than
the userls
virtual machinels
storage size, the breakpoint is set •
I
----------'
0
to 15,
which
symbol
is a name assigned to the storage location
where the breakpoint is set. The symbolic
name must be previously assigned to the
storage address using the DEF subcommand of
the DEBUG command.
hexloc
is the hexadecimal storage location (relative
to the current origin) where the breakpoint
is set.
When the debug program sets a breakpoint, it
saves the contents of the halfword at the
location specified by the second operand of the
BREAK subcommand. This halfword is replaced by
B2Ex, where x is the hexadecimal equivalent of
the identification number, specified in. the
first operand of the BREAK subcommand.
The
storage location specified for a breakpoint must
contain
an operation
code.
It is
your
responsibility to see that breakpoints are set
only at locations containing operation codes.
After breakpoints are set and during program
execution, the value B2EO
through B2EF is
encountered at a location where an operation
code should appear. A program check occurs
because all values B2EO through B2EF are invalid
operation codes and control is transferred to
Section 4. Diagnostic Aids
569
the debug environ.ent.
DEBUG recognizes the
invalid operation code as a breakpoint.
The
original operation code replaces the invalid
operation code, and a message
DMSDBG728I DEBUG ENTERED
BREAKPOINT yy AT xxxxxx
appears at the terminal.
"yy" is the breakpoint
identification number and 1XXXXX is tbe storage
address of the breakpoint.
After the message is
displayed, the keyboard is unlocked to accept
any
DEBUG
subcommands except
RETURN.
A
breakpoint is cleared when it is encountered
during program execution.
It is your responsibility to ensure that
breakpoints are set only at operation code
locations.
Otherwise, the breakpoint is not
recognized; data or some part of the instruction
other than the operation code is overlaid.
Thus, errors may be generated if breakpoints are
set at locations that do not contain operation
codes.
INVALID OPERAND
This message indicates that the breakpoint
identification number specified in the first
operand is not a decimal number between 0 and
15 inclusive, or the second operand cannot be
located in the DEBUG symbol table and is not
a valid hexadecimal number.
If the second
operand is intended to be a symbol, a DEl
subcommand must have been previously issued
for that symbol; if not, the operand must be
a valid hexadecimal storage location.
INVALID STORAGE REFERENCE
The location indicated by the second operand
is uneven (not on a halfword boundary) or the
sum of the second operand and the current
origin value is greater than the virtual
machine's virtual storage
size.
If the
current origin value is unknown, it may be
reset to the desired value by issuing the
ORIGIN subcommand.
MISSING OPERAND
The minimum
supplied.
number of operands has
TOO MANY OPERANDS
The following error messages may appear
entering the BREAK subcommand.
570
while
you entered more than two operands.
VM/370: System Logic and Problem Determination Guide
not been
Use the CAW subcommand anytime the virtual
machine is in the debug environment. Issue the
CAW subcommand to check that the command address
field contains a valid CCW address, or to find
the address of the current CCW so that you can
examine it.
Issuing the CAW subcommand causes
the contents of the CAW (channel address word),
as it existed at the time the debug environment
was entered, to appear at the terminal. The CAW
located at storage location X'48' is saved at
the time the debug environment is entered and
displayed on the terminal whenever the CAW
subcommand is issued. If the subcommand is
issued correctly, the contents of the CAW are
displayed in hexadecimal representation at the
terminal.
The format of the CAW subcommand is:
r-
I
,
CAW I
I
L _____________________________________________ -J
Bits
contents
The--protection
key for
all commands
associated with START I/O. The protection
key in the CAW is compared with a key in
storage whenever a reference is made to
storage.
4-7
This field is not
binary zeros.
8-31
The command address field (::ontains the
storage
address
(in
hexadecimal
representation) of the first CCW (channel
command word) associated with the next or
most recent START I/O.
0=3-
used and
must contain
The three low-order bits of the command
address field must be zeros for the CCW to be on
a doubleword boundary.
If the CCW is not on a
doubleword boundary or if the command address
specifies a location protected fron fetching or
outside the storage of a particular virtual
machine, START I/O causes the status portion of
the CSW to be stored with the program check or
protection check bit on. In this event, the I/O
operation is not initiated.
The CAW subcommand has no operands.
The format of the CAW is:
-,
r
I KEY I 0000 I
Command Address
L ______________________
I
.J
o
3 4
7 8
The following error message
entering the CAW subcommand.
may appear
while
31
TOO MANY OPERANDS
An operand was entered on the command line;
the CAW subcommand has no operands.
Section 4. Diagnostic Aids
571
Use the CSW subcommand any time the virtual
machine is in the debug environment. Issue the
CSW
subcommand whenever
an I/O
operation
abnormally terminates.
The status and residual
count information in the CSW is very useful in
debugging. Also, use the CSW to calculate the
address of the last executed CCW (subtract 8
bytes from the command address to find the
address of the last ccw executed).
Issuing the
CSW subcommand causes the contents of the CSW
(channel status word), as it existed at the time
the debug environment was entered, to appear at
the terminal.
The CSW indicates the status of
the channel or an input/output device, or the
conditions
under
which an
I/O
operation
terminated. The CSW is formed in the channel
and stored in storage location X'40' when an I/O
interrupt occurs.
If I/O interruptions are
suppre~sed,
the CSW is stored when the next
start I/O, Test I/O, or Halt I/O instruction is
executed.
The CSW is saved when DEBUG is
entered.
If the subcommand is issued correctly,
contents of the CSW
are displayed at
terminal in hexadecimal representation.
the
the
The format of the CSW subcommand is:
-------,
r
IL_____________________________________________
CSW
- J\
Bits
contents
'The-protection key is moved to the CSW
from
the
CAW.
It
indicates
the
protection key at the
time the I/O
started. The contents of this field are
not
affected by
programming
errors
detected by
the channel or
by the
condition causing termination
of the
operation.
4-7
This field is not used and
binary zeros.
8-31
The command
address
(in
eight bytes
the last CCW
32-47
The status bits indicate the conditions
in the device or channel that caused the
CSW to be stored.
48-63
The residual count is the difference
between the number of bytes specified in
the last executed CCW and the number of
bytes that were actually transferred.
When an input operation is terminated,
the difference between the original count
in the CCW and the residual count in the
CSW is equal to the number of bytes
transferred to storage; on an output
operation, the difference is equal to the
number of bytes transferred to the I/O
device.
0="3-
must contain
address contains a storage
hexadecimal representation)
greater than the address of
executed.
The CSW subcommand has no operands.
The format of the CSW is:
r---------------------------------------------,
The following error message
enter the CSW subcommand.
may appear when you
\KEYIOOOOI Command Address IStatuslByte Count -J\
L-____________________________________________
TOO MANY OPERANDS
03478
31 32
47 48
63
An operand was entered on the command line;
the CSW subcommand has no operands.
572
V"/370: system Logic and Problem Determination Guide
Use the DEFINE subcommand to assign symbolic
names to a specific storage address. Once a
symbolic name is assigned to a storage address,
that symbolic name can refer to that address in
any of the other DEBUG subcommands.
However,
the
symbol is
valid only
in the
debug
environment.
Issuing the DEFINE subcommand creates an
entry in the DEBUG symbol table. The entry
consists of
the symbol name,
the storage
address, and the length of the field.
A maximum
of 16 symbols can be defined in the DEBUG symbol
table at a given time.
bytecount
is a decimal number, from 1 throl11gh 56, which
specifies the length in bytes of the field
whose name is specifed by the first operand
(symbol) and whose
starting location is
specified by the second operand
(hex10c).
When the bytecount operand is not specified,
a default bytecount of 4 is assumed.
The following error messages may appear when the
DEFINE subcommand is issued:
INVALID OPERAND
When a DEFIlE subcommand specifies a symbol
that already exists in the DEBUG symbol table,
the storage address derived from the current
request replaces the previous storage address.
Several symbols may be assigned to the same
storage address, but each of these symbols
constitutes one entry in
the DEBUG symbol
table. The symbols remain defined until a new
DEF is issued for them or until an IPL request
loads a new copy of CMS.
The format of the DEFINE subcommand is:
r---·-------
I
I
I DEFine I symbol
I
I
I
I
r
hex10c
.,
I bytecountl
I
!
I
L
.J
This
message
indicates that
the
name
specified in the first operand contains all
numeric characters, the second operand is not
a valid hexadecimal number, or the third
operand is not a decimal number between 1 and
56 inclusive.
INVALID STORAGE ADDRESS
The sum of the second operand and the current
origin is greater than the virtual machine's
storage size. If the current origin size is
unknown, reset it to the desired value by
issuing the
ORIGIN subcommand
and then
reissue the DEF subcommand.
16 SYMBOLS ALREADY DEFINED
L
symbol
is the name to be assigned to the storage
address derived from the second operand,
hex10c. Symbol may be from 1 to 8 characters
long.
It must
contain. at least
one
nonhexadecima1 character.
Any symbolic name
longer
than
eiqht
characters
is
left-justified and truncated on the right
after the eighth character.
The DEBUG symbol table is full and no new
symbols may be defined until the current
definitions are cleared by obtaining a new
copy of CMS. However, an existing symbol may
be assigned to a new storage location by
issuing another DEF
subcommand for that
symbol.
MISSING OPERAND
The DEFINE subcommand requires at least two
operands and less than two were entered.
TOO MANY OPERANDS
hex10c
is the hexadecimal
storage location, in
relation to the current origin, to which the
name specified in the first operand (symbol),
is assigned.
Hex10c, a hexadecimal number,
is added to the current origin established by
the ORIGIN subcommand. The sum of the second
operand
(hex10c)
and the
or1g1n is the
storage address to which the symbolic name is
assigned. To assign the symbolic name to the
correct location be sure to know the current
origin.
The existing DEBUG symbol table
entries remain unchanged when the ORIGIN
subcommand is issued.
Three is the maximum number of operands for
the DEFINE subcommand and more than three
were entered.
Section 4. Diagnostic Aids
573
Use the DUMP subcommand to print part or all of
a virtual machine's storage on the printer.
The format of the DUMP subcommand is:
r-------------------------------------,
, r
,
I
I
r
I
I symbo11 I I symbo12 I
I DUmp I
I
I
I
I hexloc 1 I I hexloc2 I [ident]
I
.Q
I
I
I
I I
I
I
*
L
.J
I
I
I
I
I
J~
lI _ _ _ _ _ _I_ _ _ _ _ _ _ _ _ _ _L_ _ _ _ _ _ _.J_ _ _ _ _ _ _ _ _ .JI
.!!h~!~:
symboll
is the
name assigned
(via the
DEFINE
subcommand)
to the
storage address that
begins the dump.
hexloc 1
is the hexadecimal
storage location,
in
relation to the current origin, that begins
the dump.
The first and second operands specify the
starting and ending addresses, respectively, of
the area of storage to be dumped.
If you issue
DUMP without the first and second operands, 32
bytes of storage are dumped starting at the
current origin.
If you issue DUMP without the
second operand, 32 bytes of storage are dumped
starting at the location indicated by the first
operand.
If you specify ~he first and second operands,
they must be valid
symbols or hexadecimal
numbers. When you specify a symbol, the DEBUG
symbol table is searched. If a match is found,
the storage location
corresponding to that
symbol is the starting or ending address for the
dump.
When a hexadecimal number is specified,
it is added to the current origin to calculate
the starting or ending storage address for the
dump.
The first and
second operands must
designate storage addresses that are not greater
than the virtual machine's storage size. Also,
the storage address derived from the second
operand must be greater than the storage address
derived from the first operand.
An asterisk may
be specified for the second operand.
In this
case, all of storage from the starting address
(first operand) to the end of storage is printed
on the printer.
symbo12
is the
name assigned
(via the
DEFINE
subcommand) to the storage address that ends
the dump.
hexloc2
is the hexadecimal
storage location, in
relation to the current origin, that ends the
dump.
*
indicates that the dump ends at
last virtual storage address.
the user's
ident
is the name
(up to eight characters)
identifies this particular printout.
that
The requested information is printed offline
as soon as the printer is available.
First, a
heading:
ident FROM
location
starting
location
TO
ending
is printed.
Next, the general registers 0
through
7
and
8 through
15,
and
the
floating-point
registers 0
through 6
are
printed. Then the specified portion of virtual
storage is printed with the storage address of
the first byte in the line printed at the left,
followed by the alphameric interpretation of 32
bytes of storage.
574
The following error messages may appear when you
issue the DUMP subcommand.
INVALID OPERAND
This message
is issued if
the address
specified by the second operand is less than
that specified by the first operand, or if
the first or second
operands cannot be
located in the DEBUG symbol table and are not
valid hexadecimal numbers.
If either operand
is intended
to be a symbol,
a DEFINE
subcommand must previously have been issued
for that symbol; if not, the operand must
specify a valid hexadecimal location.
INVALID STORAGE ADDRESS
The hexadecimal number specified in the first
or second operand, when added to the current
origin, is greater than the user's virtual
storage size. If the current origin value is
unknown, reset it to the desired value by
issuing the
ORIGIN subcommand
and then
reissue the DUMP subcommand.
TOO MANY OPERANDS
Three is the maximum number of operands for
the DUMP subcommand; more than three operands
were entered.
VM/370: System Logic and Problem Determination Guide
§Q
Use the GO subcommand to 'exit from the debug
environment and begin execution
in the CMS
environment. The old PSW for the interruption
that caused the debug environment to be entered
is saved and later loaded to resume processing.
Issuing the GO subcommand loads the old PSi.
If the debug environment was entered due to a
breakpoint, external interruption, or program
interruption, then the GO subcommand does not
need
an
operand specifying
the
starting
address.
The format of the GO subcommand is:
r
,
I
r ,
I
I symbol I
I
I GO
I
I hexloc I
I
I
L.J
L--__
· ____________________________________
-.JI
symbol
is the name, already assigned by the DEFINE
subcommand, to a
storage location where
execution begins.
The following error messages
entering the GO subcommand.
may appear
while
INVALID OPERAND
An operand specified in the GO subcommand
cannot be located in the DEBUG symbol table
and is not a valid hexadecimal number. If
the operand is intended to be a symbol, a
DEFINE subcommand must have been previously
issued for that symbol; if not, the operand
must specify a valid hexadecimal storage
location.
INVALID STORAGE ADDRESS
hexloc
is the hexadecimal location, in relation to
the current origin, where execution begins.
When the GO subcommand is issued, the general
registers, CAW
(channel address word), and CSW
(channel status word)
are restored either to
their
contents
upon
entering
the
debug
environment, or, if they have been modified
while in
the debug environment,
to their
modified contents.
Then the old PSW is loaded
and becomes the current PSW.
Execution begins
at the instruction address contained in bits
40-63 of the PSW.
By specifying
an operand
with the
GO
subcommand, you can alter the address where
execution is to begin. This operand must be
specified whenever the GO subcommand is issued
if the debug environment is entered by issuing
the DEBUG command.
The operand may be a symbol or a hexadecimal
location. When a symbol is specified, the DEBUG
symbol table is searched.
If a match is found,
the storage address corresponding to the symbol
replaces the instruction address in the old PSW.
When a hexadecimal number is specified, it is
added to the current origin to calculate the
storage address that replaces the instruction
address in the old PSW.
In either case, the
derived storage address must not be greater than
the virtual machine's storage size. Further, it
is your responsibility to make sure that the
address referred to by the operand of the GO
subcommand contains an operation code.
The address at which execution is to begin is
not on a halfword boundary (indicating that
an operation code is not located at that
address) or the sum of the GO operand and the
current origin value is greater than the
virtual machine's storage
size.
If the
current value is unknown, it may be reset to
the desired value by issuing the ORIGIN
subcommand.
INCORRECT DEBUG EXIT
The GO subcommand without an operand has been
issued when DEBUG had not been entered due to
a breakpoint or external interruption. The
RETURN subcommand must be issued if DEBUG had
been entered via the DEBUG command.
TOO MANY OPERANDS
The GO subcommand has a maximum of one
operand; more than one operand was entered.
section 4. Diagnostic Aids
575
Use the GPR subcommand to print the contents of
one or more general registers at the terminal.
the register indicated by the second operand are
typed at the terminal.
Both operands must be
decimal numbers from 0 through 15 inclusive, and
the second operand must be greater than the
first.
The format of the GPR subcommand is:
r----------------------------------------------,
I _____________________________________
GPR I reg1 [reg2]
L
._________ JI
The following error messages may appear on the
terminal when the GPR subcommand is entered.
reg1
is a decimal number (from 0 through 15)
indicating the first or only general register
whose contents are to be typed.
reg2
is a decimal number (from 0 through 15)
indicating the last general register whose
contents are to be typed. This operand is
optional and is only specified when more than
one register's contents are to be printed.
When only one operand is specified, only the
contents of that general register are typed at
the terminal.
When two registers are specified,
the contents of all general registers from the
register indicated by the first operand through
576
INVALID OPERAND
The operand(s)
specified are not decimal
numbers from 0 through 15, or the second
operand is less than the first.
MISSING OPERAND
The GPR subommand requires at
operand, and none was entered.
least
one
TOO MANY OPERANDS
The GPR subcommand has a maximum of two
operands, and more than two operands were
entered.
VM/370: System Logic and Problem Determination Guide
Use the HI subcommand to close all open files
and I/O devices, and to update the master file
directory.
This
subcommand may
be issued
whenever the keyboard is unlocked in the debug
environment, regardless of the reason the debug
environment was entered.
The following error message may appear on the
terminal while entering the HI subcommand.
TOO MANY OPERANDS
The HI subcommand has no operands, and one or
more operands were entered.
The format of the HX subcommand is:
r----------------------------------------------,
I
HX
I
I
L_______ _
_ ___________ - - - J
The HX subcommand has no operands.
Section 4. Diagnostic Aids
577
Use the ORIGIN subcommand to set the origin
equal to the program load point. The ORIGIN
subcommand sets an origin or base address to be
used in the debug environment.
In all debug
subcommands,
you
can
specify
instruction
addresses in relation to the program load point,
rather than to O.
The hexadecimal location
specified in DEBUG subcommands then represents a
specific location within a program, the origin
represents the storage location of the beginning
of the program; and
the two values added
together represent the actual storage location
of that specific point in the program.
r--------------------------------------------,
I ORigin I {SymbOl}
I
I
hexloc
I
L _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _.___________ --'
symbol
is a name that was previously assigned (via
the DEFINE subcommand) to a storage address.
hexloc
is a hexadecimal location within
of the virtual machine's storage.
while
The
operand
specified
in
the
ORIGIN
subcommand cannot be located in the DEBUG
symbol table and is not a valid hexadecimal
number.
If the operand is intended to be a
symbol, a DEFINE subcommand must have been
previously issued for that symbol;
if not,
the operand must specify a valid hexadecimal
location.
INVALID STORAGE ADDRESS
The address specified by the ORIGIN operand
is greater than the user's virtual storage
size.
the limits
When the
ORIGIN subcommand
specifies a
symbol, the DEBUG symbol table is searched.
If
a match is found, the value corresponding to the
symbol
becomes the
new
origin.
When
a
hexadecimal location is specified, that value
becomes the origin. In either case, the operand
cannot specify an address greater than the
virtual machine's storage size.
578
The following error messages may appear
you enter the ORIGIN subcommand.
INVALID OPERAND
The format of the ORIGIN subcommand is:
I
Any origin set by an remains in effect until
another ORIGIN subcommand ORIGIN subcommand is
issued, or until you obtain a new copy of CMS.
Whenever a new ORIGIN subcommand is issued, the
value specified in that subcommand overlays the
previous origin setting. If you obtain a new
copy of CMS (via IPL), the origin is set to 0
until a new ORIGIN subcommand is issued.
MISSING OPERAND
The ORIGIN subcommand requires
and none was entered.
one operand,
TOO MANY OPERANDS
The ORIGIN subcommand
requires only
operand, and more than one was entered.
VM/370: system Logic and Problem Determination Guide
one
Use the PSi subcommand to type the contents of
the old PSi
(program status word)
for the
interruption that caused DEBUG to be entered.
The format of the PSi subcommand is:
r-----------------------------I PSi I
---,I
L _____________________________________________ ~
where the 1 in the first byte means that
external interruptions are allowed and xxxxxxxx
is the hexadecimal storage address of the DEBUG
program.
The
PSi contains
some information
not
contained in storage or registers but required
for proper program execution. In general, the
PSi controls instruction seq~encing and holds
and indicates the status of the systea in
relation to the program currently executing.
The PSi subcommand has no operands.
If DEBUG was entered due to an external
interrupt,
the PSi
subcommand causes
the
contents of the external old PSi to be typed at
the terminal.
If a program interrupt caused
DEBUG to be entered, the contents of the program
old PSi are typed.
If DEBUG was entered for any
other reason, the following is typed in response
to the PSi sUbcommand:
01000000 xxxxxxxx
The following error message
entering the PSi subcommand.
may appear
while
TOO MANY OPERANDS
The PSi subcommand has no operands and one or
more was entered.
Section 4. Diagnostic Aids
579
Use the RETURN subcommand to exit from t he debug
environment to the CMS command environment.
RETURN should be used only when DEBUG is entered
by issuing the DEBUG command.
ready message followed by a carriage return and
an unlocked keyboard indicates that the RETURN
subcommand has successfully executed and that
control
has
transferred from
the
DEBUG
environment to the CMS command environment.
The format of the RETURN subcommand is:
r-----------------------------·-------,
IL _RETurn
__
I
I
_ _______________ J
The RETURN subcommand has no operands.
When RETURN
is issued,
the information
contained in the general registers at the time
DEBUG was entered is restored or, if this
information was changed while in the debug
environment,
the
changed
information
is
restored.
In either case, register 15, the
error code register, is set to zero.
A branch
is then made to
the address contained in
register 14, the normal CMS return register.
If
DEBUG is entered by issuing the DEBUG command,
register 14 contains the address of a central
CMS service
routine and
control transfers
directly to the CMS command environment.
The
580
The following error messages may appear
entering the RETURN subcommand.
while
TOO MANY OPERANDS
The RETURN subcommand has no operands,
one or more were specified.
and
INCORRECT DEBUG EXIT
If DEBUG is entered due to a program or
external interruption, a breakpoint or an
unrecoverable
error,
this
message
is
displayed
in
response
to
the
RETURN
subcommand.
To
exit
from
the
DEBUG
environment under the above circumstances,
issue GO.
VM/370: System Logic and Problem Determination Guide
Use the SET subcommand to change the contents of
the control words and general registers that are
saved when the debug environment is entered.
The contents of these registers are restored
when control transfers from DEBUG to another
environment. If register contents were modified
in DEBUG, the changed contents are stored.
The SET subcommand can change the contents of
one or two general registers each time it is
issued. When four or less bytes of information
are specified,
only the
contents of
the
specified register are changed.
When more than
four bytes of information is specified, the
contents of the specified register and the next
sequential register are changed.
For example,
the SET subcommand:
SET
The format of the SET subcommand is:
r----------------------------------------------,
I SET I {CAW hexinfo
} I
I
I
I CSW hexinfo [hexinfo)
I
I
I PS W hexinfo [ hexinfo )
I _____________________________________________
I GPR reg
L
hexinfo
[hexinfo)
- JI
GPR
2 xxxxxxxx
changes only the contents of
2. But, the SET subcommand:
SET
GPR
changes the
and 3.
general
register
2 xxxxxxxx xxxxxxxx
contents of
general
registers
2
CSW hexinfo [hexinfo)
indicates that the
specified information
(hexinfo [hexinfo)
is stored in the CSW
(channel status word)
that existed at the
time DEBUG was entered.
The number of bytes that can be stored using
the SET subcommand varies depending on the form
of the subcommand. with the CAW form, up to
four bytes of information may be stored. With
the CSW, GPR, and PSW forms, up to eight bytes
of information may be stored, but these bytes
must be represented in two operands of four
bytes each.
When two operands of information
are specified, the information is stored in
consecutive locations (or registers), even if
one or both operands contain less than four
bytes of information.
PSW hex info [hexinfo)
indicates that the
specified information
(hexinfo [hexinfo)
is stored in old PSW
(program status word)
for the interruption
that caused DEBUG to be entered.
The contents of registers changed using the
SET subcommand are not displayed after the
subcommand is issued. To inspect the contents
of control words and registers, the CAW, CSW,
PSW, or GPR subcommands must be issued.
CAW hex info
indicates that the
specified information
(hexinfo) is stored in the CAW
(channel
address word) that existed at the time DEBUG
was entered.
GPR reg hexinfo [hexinfo)
indicates that the
s~ecified
information
(hexinfo
[hexinfo])
1S
stored
in
the
specified general register (reg).
Each hexinfo operand should be from one to
four bytes long. If an operand is less than
four bytes and contains an uneven number of
hexadecimal
digits
(representing
half-byte
information), the information is right-justified
and the left half of the uneven byte is set to
zero. If more than eight hexadecimal digits are
specified in a single operand, the information
is left-justified and truncated on the right
after the eighth digit.
only change the
The SET subcommand can
contents of one control word at a time.
For
example, the SET subcommand must be issued three
times:
SET
SET
SET
CAW
CSW
PSW
to change the
words.
hexinfo
hexinfo [hexinfo)
hexinfo [hexinfo]
contents
of
the three
The following error messages
entering the SET subcommand.
may appear
while
INVALID OPERAND
The first operand is not CAW, CSW, PSW, or
GPR, or the first operand is GPR and the
second operand is not
a decimal number
between 0 and 15 inclusive, or one or more of
the
hexinfo operands
does no~
contain
hexadecimal information.
MISSING OPERAND
The minimum
entered.
number of operands has
not been
TOO MANY OPERANDS
control
More than the required
were specified.
number of
operands
section 4. Diagnostic Aids
581
Use the STORE subcommand to store up to 12 bytes
of hexadecimal information in any valid virtual
storage address.
The information is stored
starting in the location derived from the first
operand (symbol or hexloc).
The format of the STORE subcommand is:
r--------------------------------·--------,
The STORE subcommand can store a maximum of
12 bytes at one time. By specifying all three
information operands, each containing four bytes
of information, the maximum 12 bytes can be
stored.
If less than four bytes are specified
in any or all of the operands, the information
given is arranged into a string of consecutive
bytes, and that string is stored starting at the
location derived from the first operand.
Stored
information is not typed at the terminal. To
inspect the changed contents of storage after a
STORE subcommand, issue an X subcommand.
I STore I {SymbOl} hex info [hexinfo [hexinfo]] I
IL______________________________________
I hexloc
JI
symbol
is the
naae assigned
(via the
DEFINE
subcommand) to the storage address where the
first byte
of specified
information is
stored.
hexloc
is the hexadecimal location,
current or1g1n, where the
information is stored.
relative to the
first byte of
hexinfo
is any hexadecimal information, four bytes or
less in length, to be stored.
If
the
first
operand
contains
any
nonhexadecimal
characters, the DEBUG symbol
table is searched for a matching symbol entry.
If a match is found in the DEBUG symbol table,
or
if
the first
operand
contains
only
hexadecimal characters, the current origin is
added to the specified operand and the resulting
storage address is used, provided it is not
greater than the
virtual machinels storage
size.
The information to be stored is specified in
hexadecimal format in the second through the
fourth operands. Each of these operands is from
one to four bytes
(that is, two to eight
hexadeciaml digits) long. If an operand is less
than four bytes long and contains an uneven
nUBber of
hexadecimal digits
(representing
half-byte information),
the information
is
right-justified and the left half of the uneven
byte is set to zero.
If more than eight
hexadecimal digits are specified in a single
operand, the information is left-justified and
truncated on the right after the eighth digit.
582
The following errcr messages may appear on the
terminal while entering the STORE subcommand.
INVALID OPERAND
The first operand cannot be located in the
DEBUG symbol table and
is not a valid
hexadecimal
number, or
the
information
specified in the second,
third, or fourth
operands is not in hexadecimal format.
If
the first operand is intended to be a symbol,
a DEFINE subcommand must have been previously
issued for that symbol;
if not, the operand
must specify a valid hexadecimal storage
location.
INVALID STORAGE ADDRESS
The current origin value, when added to the
hexadecimal number specified as the first
operand, gives an address greater than the
userls virtual storage size. If the origin
value is unknown,
reset it to the desired
value using the ORIGIN subcommand and reissue
the STORE subcommand.
MISSING OPERAND
Less than two operands were specified.
TOO MANY OPERANDS
More than four operands were specified.
VM/370: system Logic and Problem Determination Guide
----,
The second operand of the X subcommand is
optional.
If specified, it indicates the
number of bytes (up to a maximum of 56) whose
contents are to be displayed. If the second
operand is omitted and the first operand is a
hexadecimal location, a default value of four
bytes is assumed. If the second operand is
omitted and the first operand is a symbol,
the length attribute associated with that
symbol in the DEBUG symbol table is used as
the number of bytes to be displayed.
I
I
I
L
J
I
r
I
hexloc I n
I
I
I
I !
I
L
J
LI ___________________________________________
- - - JI
The following error messages may appear on the
terminal when the X subcommand is entered.
Use the X subcommand to examine and display the
contents of
specific locations
in virtual
storage. The information is displayed at the
terminal in hexadecimal format.
The format of the X (examine) subcommand is:
r
I
I
I
I
I
I
I
X
symbol
r
I n
I !~~g~h
,
I
I
,
INVALID OPERAND
symbol
is the
name assigned
(via the
DEFINE
subcommand)
to the storage address of the
first byte to be examined.
hexloc
is the hexadecimal location, in relation to
the current origin, of the first byte to be
examined.
The first operand cannot be located in the
DEBUG symbol table and
is not a valid
hexadecimal number, or the second operand is
not a decimal number from 1 through 56. If
the first operand is intended to be a symbol,
it must have been defined in a previous
DEFINE subcommand; otherwise, the operand
must specify a valid hexadecimal number.
INVALID STORAGE ADDRESS
n
is a decimal number from 1 through 56 that
specifies the number of bytes to be' examined.
If a symbol is specified without a second
operand, the length attribute associated with
that symbol
in the DEBUG
symbol table
specifies the number of bytes to be examined.
If a
hexadecimal location
is specified
without a second operand, four bytes are
examined.
The first
operand of
the subcommand
specifies the
beginning address
of the
portion of storage to be examined.
If the
operand
contains
any
nonhexadecimal
characters,
the DEBUG
symbol table
is
searched for a matching symbol entry.
If a
match is found, the storage address to which
that symbol refers is the location of the
first byte to be examined.
If no match is
found, or if the first operand contains only
hexadecimal characters, the current origin as
established by the ORIGIN subcommand is added
to the specified operand and the resulting
storage address is the location,of the first
byte to be examined.
The derived address
must not
be greater
than the
virtual
machine's storage size.
The hexadecimal number specified in the first
operand, when added to the current origin, is
greater than the storage size of the machine
being used.
If the current origin value is
unknown, reset it to the desired valqe by
issuing the ORIGIN subcommand and reissue the
X subcommand.
KISSING OPERAND
No operands were
required.
entered; at
least one
is
TOO KANY OPERANDS
Kore than
entered.
the maximum
of two
operands were
Section 4. Diagnostic Aids
583
SVCTRACE
Use the SVCTRACE command to trace internal
transfers of information resulting from SVC
(supervisor call)
instructions.
Issuing the
SVCTRACE command causes switches to be set.
These switches, in turn, cause information to be
recorded at appropriate times.
When the trace
is terminated,
the
recorded information is
printed at the system printer.
The information recorded
call is:
•
storage
address
instruction
of
for
a normal
SVC
the
SVC
calling
Name of the program being called
•
contents of the SVC old PSi
•
storage address of the return from the called
program
•
The general
registers
registers
T he parameter
issued.
list at
SVCTRACE ON
command is issued.
The first line of trace output starts with a
minus sign (-), a plus sign (+), or an asterisk
(*).
The format of the first line of trace
output is:
{: }
=
B/D
xxx/dd name FROM loc OLDPSi
GOPSi
psw2 [RC
rc]
•
•
A variety of information is printed whenever the
and
=
=
indicates
information
processing the SVC.
recorded
pswl
before
floating-point
the time
the SVC
+
indicates
information
recorded
after
processing the SVC, unless
applies.
*
indicates
processing
return.
N/D
is an abbreviation for SVC Bumber and Depth
(or level).
xxx
is the number of the SVC
numbered sequentially).
dd
is the nesting level of the SVC call.
*
is
information
recorded
a CMS SVC which had an
after
error
The format of the SVCTRACE command is:
------,
r
ISVCTrace
I
I
I
_._------'
L
call (they
are
name is the macro or routine being called.
ON
indicates tracing for all SVC calls.
OFF
discontinues all SVC tracing.
loc
is the program location
was issued.
from which the SVC
pswl is the PSi at the time the SVC was called.
The trace information is:
•
The
general registers
both before
the
SVC-called program is given control and after
a return from that program.
•
The floating-point registers both before the
SVC-called program is given control and after
a return from that program.
•
The parameter list, as
SVC was issued.
psw2 the PSi
with which the
routine
(for
example, RDBUF) being called is invoked, if
the first character of this line is a minus
sign f-).
If the first character of this
line is a plus sign
(+) or
asterisk (*),
PSi2 represents the
PSi which returns
control to the user.
rc
it existed
when the
To terminate tracing set by the SVCTRACE
command, issue the HO or SVCTRACE OFF command.
Both SVCTRACE OFF and
HO cause all trace
information recorded up to the point they are
issued to be printed at the system printer.
SVCTRACE OFF can be
issued only when the
keyboard is unlocked to accept input to the CMS
command environment.
TO terminate tracing at
any other point in system processing, HO must be
issued.
If a 8X
subcom.and to the DEBUG
environment or a logout from the control program
is issued before
terminating SVCTRACE, the
switches are cleared
automatically and all
recorded trace information is printed at the
system printer.
58Q
is the return code passed from the SVC
handling ~outine in general register 15.
This field
is omitted
if the
first
character of this line is a minus sign (-),
or if this is an OS SVC call. For a CMS
SVC, this field is zero if the line begins
with a plus sign (+), and nonzero for an
asterisk (*).
Also, this field equals the
contents of Register 15 in the "GPRS AFTER"
line.
V"/370: System Logic and Problem Determination Guide
The next two lines of output are the contents
of the general registers when control is passed
to the SVC handling routine. This output is
identified at the left by "-GPRSB". The format
of the output is:
The next line of output is the contents of
the caller's floating-point
registers.
The
output is identified at the left by "eFPRS." The
format of the output is:
-GPRSB
eFPRS
=
h h h h h h h h *dddddddd*
h h h h h h h h *dddddddd*
represents the
contents of
register in hexadecimal format.
a
The next line of output is the contents of
general registers 0, 1 and 15 when control is
returned to the user's program. The output is
identified at the left by "-GPRS AFTER :". The
format of the output is:
-GPRS AFTER
RO-R1
=h
h *dd* R15
is the EBCDIC translation of
of a general register.
eFPRSS
the contents
a
is the EBDCIC translation.
The last two lines of output are only printed
if the address in Register 1 is a valid address
for the virtual machine. If printed, the output
is the parameter list passed to the SVC. The
output is identified by "epARM" at the left.
The output format is:
ePARM
=h
h h h h h h h *dddddddd*
h h h h h h h h *dddddddd*
represents a word of hexadecimal data
~
represents the EBCDIC translation of
contents of a general register.
contents of
Each floating-point register is a doubleword and
each! and g represents a doubleword of data.
The EBCDIC translation is preceded and followed
by an asterisk (*).
h h h h h h b h *dddddddd*
h h h h h h h h *dddddddd*
contents of
f f f f *gggg*
a
The next two lines of output are the contents
of the general registers when the SVC handling
routine is finished processing. This output is
identified at the left by "-GPRSS". The format
of the output is:
represents the hexadecimal
general register.
=
represents the hexadecimal
floating-point register.
The only general registers that CMS routines
alter are registers 0, 1, and 15 so only those
registers are printed when control returns to
the user program.
The EBCDIC translation is
preceded and followed by an asterisk (*).
-GPRSS
a
The next line of output is the contents of
floating-point registers when the SVC-handling
routine is finished processing. The output is
identified by "eFPRSS" at the left. The format
of the output is:
h *d*
contents of
of
a
Each floating-point register is a doubleword:
each f
and g represents a doubleword of data.
The EBCDIC translation is preceded and followed
by an asterisk (*).
g
represents the hexadecimal
general register.
contents of
is
the
EBCDIC
translation
floating-point register.
the
The contents of general
registers 0-7 are
printed on the first line, with the contents of
8-F on the second line. The hexadecimal contents
of the registers registers are printed first,
following by the EBCDIC.
The EBCDIC translation
translation is preceded and followed by an
asterisk (*).
f f f f *gggg*
represents the hexadeciaal
floating-point register.
general
represents the EBCDIC translation of
contents of a general register.
=
a
the
is the EBCDIC translation.
The parameter list is found at the address
contained in register 1 before control is passed
to
the
SVC-handling program.
The
EBCDIC
translation is preceded and followed by an
asterisk (*).
Figure 66
output.
summarizes the types of
SVC trace
General registers 0-7 are printed on the first
line with registers 8-F on the second line. The
EBCDIC translation is preceded and followed by
an asterisk (*).
Section 4. Diagnostic Aids
585
r------------------------------------,
1 Identification 1 Comments
1
-------------------------------------------1
+ }
1The SVC and the routine which 1
{
1 issued the SVC.
1
1
1
1
1
IContents of general registersl
1 when control passed to the 1
1 SVC handlin~ routine.
1
NID
*
-GPRSB
-GPRS AFTER
-GPRSS
1
1
1Contents of general registers
1 0, 1, and 15 when control
1 is returned to the user
1 program.
1
IContents of the general
1 registers when the SVC
1 handling routine is finished
1 processing.
1
.FPRS
,Contents of floating-point
, register before the
, SVC-called program is given
, control and after returning
I from that program.
I
.FPRSS
Icontents of the floatingI point registers when the SVCI
I handling routine is finishedl
I processing.
I
I
I
.PARM
IThe parameter list, when one 1
I _is
L _ _ _._ _ _ _ _ _ _ _ _ _
_ _passed
_ _ _ _ _to
_ _ the
_ _ _ SVC.
_ _ _ _ _ _ _ _.II
Figure 66.
Summary of SVC Trace Output Lines
INVOKING DDR UNDER CMS
The format of the DDR command is:
r--------------------1
1
I
DDR
I
r ,
[filename [filetype Ifilemodel
,1
1
I
1
1
*
1
1
I
l
L
L _______
______
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _.I_ _ ---'1
filename filetype [filemode]
is
the
identification
of
the
file
containing the control statements for the
DDR program.
If no file identification is
provided, the DDR
program attempts to
obtain
control
statements
from
the
console. The filemode defaults to * if a
value is not provided.
INVOKING DDR AS A STANDALONE PROGRAM
TO use DDR as a standalone program, load it from
a real or virtual IPL device as you would any
other standalone program. Then indicate where
the DDR program is
to obtain its control
statements by responding to prompting messages
at the console.
see the "DDR Control statements" discussion
in the "CP Commands for Debugging" section. The
control statements for running standalone and
under CMS are identical, except that CMS ignores
the SYSPRINT control statement.
Use the DASD Dump Restore (DDR) service program
to dump, restore, copy, display, or print VM/370
user minidisks.
The DDR program may run as a
standalone program, or under CMS via the DDR
command.
586
VM/370: System Logic and Problem Determination Guide
section 5 has nine appendixes:
•
"Appendix A:
VM/370 Coding Conventions"
•
"Appendix B:
CP and RSCS Equate Symbols"
•
"Appendix C:
CMS Equate Symbols"
•
"Appendix D:
DASD Record Formats"
•
"Appendix E:
VM/370 Restrictions"
•
"Appendix F:
Virtual Devices Used in CMS"
•
"Appendix G:
Function Codes for DIAGNOSE Instructions"
•
"Appendix H:
CMS ZAP Service program"
•
"Appendix I:
Applying PTFs"
Section 5. Appendixes
587
!I.§~
Base address for modules
called via BALR
The following are coding conventions used
by CP modules. This information should
prove helpful if you debug, modify, or
update CP.
- For
virtual-to-Real
transla tion:
•
!!~~.!§~.§!:
FORMAT
Contents
~Q!.Y!!m
Labels--
1
10
16
31, 36, 41, etc.
•
1
2
Operation Code
Operands
Comments
•
When describing an area of storage in
mainline code, a copy file, or a macro,
DSECT
is
issued
containing
DS
instructions.
•
Meaningful names are used instead of
self-defining terms, for
example 5,
X'02', or C'I' represent a quantity
(absolute
address,
offset,
length,
register,
etc.).
All
labels,
displacements, and values are symbolic.
All bits should be symbolic and defined
by EQU. For example:
CONSTANTS
Constants follow the executable code and
precede the copy files and/or macros
that contain DSECTs or system equates.
Constants are defined
in a section
followed
by
a
section
containing
initialized working storage, followed by
working storage.
Each of these sections
is identified by a comment.
Wherever
possible for a module that is greater
than a page,
constants and working
storage are within the same page in
which they are referenced.
•
NO program modifies its own instructions
during execution.
•
No program
uses its
instructions as data.
Use
iirtu al address
Real address
•
COMMENT
Approximately 75 percent of the source
code contains comments.
sections of
code
performing distinctly
separate
functions are separated from each other
by a comment section.
address
VMSTATUS
EQU
X'02'
- To set a bit, use:
01
BYTE ,BIT
where BYTE
BQU symbol.
= name
of
field, BIT is an
- To reset a bit, use:
NI
BYTE,255-BIT
- To set multiple bits, use:
•
own
unlabeled
or
- All registers are referred to as:
REGISTER USAGE
RO, R1, ••• , R15
- For CP:
~.§gi2~~U:
6
7
8
10
11
12
13
14
BYTE,BIT1+BIT2
- All lengths of fields or blocks are
symbolic, that is,
length of VMBLOK
is:
!H~g
RCHBLOK, VCHBLOK
RCUBLOK, VCUBLOK
RDEVBLOK, VDEVBLOK
IOBLOK
VMBLOK
Base register for modules
called via SVC
SAVEAREA for modules
called via SVC
Return linkage for modules
called via BALR
VMBLOKSZ
•
EQU
*-VMBLOK
Avoid absolute relative addressing in
branches and data references, (that is,
location counter value (*)
or symbolic
label plus or minus a self-defining term
used to form a displacement).
section 5. Appendixes
589
•
When
using a
single operation
to
reference multiple values, specify each
value referenced, for example:
LM
R2,R4,CONT
CON1
CON2
CON3
DC
DC
DC
•
F'1'
F'2'
F'3'
•
Do not use PRINT NOGEN or PRINT
source code.
•
MODULE NAMES
external
name
DMK
- The next three letters of the module
name identify the module and must be
unique.
Example:
DSP
- The preceding
three-letter, unique
module identifier is the label of the
TITLE card.
Each entry point or external reference
must be prefixed by the six-letter
unique identifier of the module.
Example:
•
DMKDSPCH
TITLE Card Example:
DSP TITLE
'DMKDSP
VERSION v LEVEL I'
•
VM/370
DISPATCHER
PTF Card Example:
CP/CMS:
R2,AB (,R4)
To
determine
if your
program
is
executing in a virtual machine or a real
machine, issue the Store CPU ID (STIDP)
instruction.
If STIDP is issued from a
virtual machine, the version number (the
first byte of the CPUID field) returned
will be X'PP'.
OFF in
- The first three letters of the
are the assigned component code.
Example:
For all R X instruc tions use
• ,. to
specify the base register when indexing
is not being used, that is:
L
SET R2=CON1
SET R3=CON2
SET R4= CON3
Control section
names and
references are as follows:
•
PUNCH 'xxxxxxxx APPLIED'
The CP loadlist EXEC contains a list of CP
modules used by the VMFLOAD procedures when
punching the text decks that make up the CP
system.
All modules following DMKCPE in
the list are pageable CP modules.
Each 4K
page in this area may contain one or more
modules.
The module grouping gov:rns the
order
in which
they
appear 1n
the
loadl ist. An SPB 1 (Se t Page Bounda ry} card
is a loader control card which forces the
loader to start this module at the next
higher 4K
boundary.
An SPB
card is
required
only
for the
first
module
following DMKCPE.
If more than one module
is to be contained in a 4K page, only the
first can be assembled with an SPB card.
The second and subsequent modules for a
multiple module 4K page must not contain
SPB cards.
If changes are made to the loadlist,
care must be taken to ensure that any
modules loaded together in the pageable
area do not exceed the 4K limit.
Page
boundary crossover is not allowed in the
pageable CP modules.
The position of two modules in the
loadlist
is
critical.
All
modules
following DMKCPE must be reenterable and
must not contain any address constants
referring to anything in the pageable CP
area.
DMKCKP must be the last module in
the loadlist.
where xxxxxxxx = APAR number response
•
ERROR MESSAGES
There should not be any insertions into
the message at execution time and the
length of the message should be resolved
by the assembler.
If insertions must be
made, the message must be assembled as
different DC statements, and the insert
positions
are
to
be
individually
labeled.
590
lA 12-2-9 multipunch must be in column 1 of
an SPB card.
VM/370: System Logic and Problem Determination Guide
This appendix contains assembler language equate symbols
for:
•
•
•
•
•
that reference CP and RSCS data
VM/370 Device Classes, Types, Models and Peatures
VM/370 Machine Usage
VM/370 Extended Control Registers
VM/370 CP Usage
VM/370 Registers
section 5. Appendixes
591
CLASTER"
TYP2700
TYP2955
TYPTELE2
TYPTTY
TYPIBM 1
TYP2741
TYP1050
TYPUBDEF
TYPBSC
TYP3210
TYP3215
TYP2150
TYP1052
CLASGRAF
TYP2250
TYP2260
TYP2265
TYP3066
TYP1053
TYP3277
TYP32S4
TYP32S6
TYP315S
FTROPRDR
CLASORI
TYPRDR
TYP2501
TYP2540R
TYP3505
TYP1442R
TYP2520R
TYPTIMER
TYPTR
TYP2495
TYP2671
TYP1017
CLASORO
TYPPON
TYP2540P
TYP3525
TYP1442P
TYP2520P
TYPPRT
TYP1403
TYP3211
TYP1443
TYPTP
TYP101S
FTRUCS
CLASTAPE
TYP2401
TYP2415
TYP2420
TYP3420
TYP3410
TYP3411
FTR7TRK
FTRDLDNS
FTRTRANS
FTRDCONV
CLASDASD
TYP2311
TYP2314
TYP2319
592
EQU
EQO
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
BQU
EQU
EQO
EQO
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
BQU
EQU
EQU
EQO
BQU
EQO
EQU
EQO
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
BQU
EQU
EQU
EQU
EQU
BQU
EQU
EQU
EQO
EQO
EQO
EQU
EQU
EQU
EQO
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
X'SO'
X'40'
TYP2700
X'20'
X'20'
X' 10'
X' lS'
X' 14'
X' 1 C'
X'SO'
X'OO'
TYP3210
TYP3210
TYP3210
X'40'
X'SO'
X'40'
X'20'
X'10'
X'OS'
X'04'
X'02'
TYP32S4
TYP3277
X'SO'
X'20'
X'SO'
X'Sl'
X'S2'
X'S4'
X'SS'
X'90'
X'40'
X'20'
X' 21'
X'22'
X'24'
X' 10'
X'SO'
X'S2'
X'S4'
X'SS'
X'90'
X'40'
X'41'
X'42'
X'44'
X'20'
X'24'
X'Ol'
X'OS'
X' 80'
X'40'
X'20'
X '10'
X' OS'
TYP3410
X'SO'
X'40'
X' 20'
X' 10'
X'04'
X'SO'
X'40'
TYP2314
Teriminal Device Class
2700 Bisync Line
2955 Communications Line
Telegraph Terminal Control Type II
TELETYPE Terminal
IBM Terminal Control Type I
2741 Communications Terminal
1050 Communications Ter.inal
Terminal device type is undefined
Bisync Line for 3270 Remote stations
3210 Console
3215 Console
2150 Console
1052 Console
Graphics Device Class
2250 Display onit
2260 Display station
2265 Display station
3066 Console
1053 Printer
3277 Display station
3284 Printer
3286 Printer
3158 Console
operator ID Card Reader
Onit Record Input Device Class
Card Reader Device
2501 Card Reader
2540 Card Reader
3505 Card Reader
1442 Card Reader/Punch
2520 Card Reader/Punch
Timer Device
Tape Reader Device
2495 Magnetic Tape Cartridge Reader
2671 Paper Tape Reader
1017 Paper Tape Reader
unit Record output Device Class
Card Punch Device
2540 Card Punch
3525 Card Punch
1442 Card Punch
2520 Card Punch
Printer Type Device
1403 Printer
3211 Printer
1443 Printer
Tape Punch Device
101S Paper Tape Punch
UCS Feature
Magnetic Tape Device Class
2401 Tape Drive
2415 Tape Drive
2420 Tape Drive
3420 Tape Drive
3410 Tape Drive
3411 Tape Drive
7-track Feature
Dual Density Feature
Translate Feature
Data Conversion Feature
Direct Access storage Device Class
2311 Disk Storage Drive
2314 Disk storage Facility
2319 Disk Storage Facility
VM/370: system Logic and Problem Determination Guide
TIP2321
TYP3330
TYP3333
TYP3350
TYP2301
TYP2303
TIP2305
TYP3340
FTRRPS
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
FTREXTSN
FTR2311T
FTR2311B
FTR35MB
FTR10MB
FTRRSRL
CLASSPEC
TYPCTCA
TYP3104
TYP3105
TYPRSVl
TIPUNSUP
FTRTYPl
FTRTYP2
EQU
EQU
EQU
EOU
EOU
EQU
EQU
EQU
EOU
EQU
EQU
EQU
EOU
EQU
TYP2311
X' 10'
TYP3330
X'08'
TYP2311
TYP2311
X'02'
X'Ol'
X' 80'
2321 Data Cell Drive
3330 Disk storage Facility
3333 Disk storage Facility
3350 Disk storage Facility
3201 Parallel Drum
2303 Serial Drum
2305 Fixed Bead storage Device
3340 Disk Storage Facility
Rotational Positional sensing (RPS)
Installed (3340)
Extended Sense Bytes (24 bytes)
X'40'
(= VDEV231T)
Top half of 2314 used as 2311
X'20'
(= VDEV231B)
Bottom half of 2314 used as 2311
X' 10'
35 MB Data Module mounted (3340)
X'08'
10 MB Data Module mounted (3340)
X'04'
RESERVE/RELEASE are valid CCW op codes
X'02'
special device class
X'02'
Channel-to-channel adapter
X'80'
3104 Programmable Communication Control unit
X'40'
3105 programmable communications control unit
TYP3104
Reserved by IBM
X'02'
Device unsupported by VM/370
X'Ol'
Type 1 Channel Adapter (3104/3105)
X' 10'
Type 2 Channel Adapter (3704/3705)
X' 20'
section 5. Appendixes
593
!~Ll1.Q ~!£!!!!f~ !!~!§~
~!i~ Q~!!!!~g
EITMODE
MCHEK
WAIT
PROBMODE
EQU
EQU
BQU
EQU
~!i2 Q!1!!!!~g
PERMODE
TRAIMODE
IOMASK
EXTMASK
!!!
i!!
12
'13
14
'15
-
Extended mode
Machine check enabled
Wait state
Problem state
Bit
Bit
Bit
Bit
01
05
06
07
-
PER enabled
Translate mode
Summary I/O mask
summary external mask
£h~!!!!gl ~!~!y§
X' 80'
X'40'
X'20'
X' 10'
X' 08'
X'04'
X'02'
X'Ol'
X'80'
X'40'
X' 20'
X'10'
X'08'
X'04'
X'02'
X'Ol'
in
Bit
Bit
Bit
Bit
~!!~!!g~g f~!
X'40'
X'04'
X'02'
X'Ol'
EQU
EQU
EQU
EQU
EQU
EQU
BQU
EQU
EQU
EQU
EQU
EQU
EQU
BQU
EQU
BQU
~i!§ Qg!:i!!.~~
~!~!!g~!gL~!!~!!g~g r.~!
X' 08'
X'04'
X'02'
X' 0 l'
EQU
EQU
EQU
EQU
~i!§ Qg!:i!!.~~
ATTN
Sit
CUE
BUSY
CE
DE
UC
UE
PCI
IL
PRGC
PRTC
CDC
CCC
IFCC
CHC
!!!
!2!:E
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
£h~!!ngl £Q!!~!!g
32
33
34
35
36
37
38
39
40
41
L.2
Ln
L.4
L~5
46
Ln
!2fg
-
£~!
--
Attention
status modifier
Control unit end
Busy
Channel end
Device end
unit check
Unit exception
Program-control interruption
Incorrect length
Program check
Protection check
Channel data check
Channel control check
Interface control check
Chaining check
££!
CD
CC
SILl
SKIP
PCIF
IDA
BQU
EQU
BQU
EQU
EQU
EQU
X'80'
X'40'
X'20'
X' 10'
X'08'
X'04'
Bit
Bit
Bit
Bit
Bit
Bit
CMDRBJ
I BTRBQ
BUSOUT
BQCHK
DATACHK
EQU
EQU
EQU
EQU
EQU
X' 80'
X'40'
X' 20'
X' 10'
X'08'
Bit 0 - Command reject
Bit 1 - Intervention required
Bit 2 - Bus out
Bit 3 - Equipment check
Bit .~ - Data check
594
32 - Chain data
33 - Command chain
Suppress incorrect length indicator
34
35 - Suppress Data Transfer
program-control interruption fetch
36
37 - Indirect data address
-
V"/370: systea Logic and Problem Deteraination Guide
!~LJIQ ~!a:~!HnU~ ~Q!!a:BQ1 R~§!~a:~B~
~!i2 ~!!!!!!~g
!.!!
Q
~B~§
BLKMPX
SSMSUPP
EOU
EQU
BYTE 0
X'80'
X'40'
Bit 00 - Enable block multiplexing
Bit 01 - Enable SSM suppression
PAGE4K
PAGE2K
SEG1M
EQU
EQU
EQU
BYTE 1
X'80'
X'40'
X'10'
Bit 08
Use 4K pages
Bit 09 - Use 2K pages
Bit 11 - Use 1M segments
CKCMASK
CPTMASK
EQU
EQU
BYTE 2
X'08'
X'04'
Bit 20
Mask on clock comparator interruption
Bit 21 - Mask on CPU timer interruption
IHTMASK
KEYMASK
SIGMASK
EOU
EQU
EQU
BYTE 3
X'80'
X' 40'
X'20'
Bit 24 - Mask on interval timer interruption
Bit 25 - Mask on operator key interruption
Bit 26 - Mask on external signals 2-7
~!i2 ~!!!!!!~g
PERSUBR
PERIFET
PERSALT
PERGPRS
!!!!§
!.!!
-
2
BYTE 0
X'80'
X'40'
X'20'
X' 10'
EQU
EQU
EOU
EQU
12!!!!!!~g
~.!!~§
!.!!
-
Bit
Bit
Bit
Bit
00
01
02
03
-
Monitor
Monitor
Monitor
Monitor
00
01
02
04
05
06
07
-
Check stop control
Synchronous logout control
I/O logout control
Recovery report mask
Configuration report mask
External damage report mask
Warning condition report mask
successful branches
instruction fetches
storage alteration
register alteration
~.!!!.§1~
EQU
EQU
EQU
EQU
EQU
EQU
EQU
BYTE 0
X'80'
X'40'
X'20'
X'08'
X'04'
X'02'
X' 0 l '
Bit
Bit
Bit
Bit
Bit
Bit
Bit
ASYHELOG EQU
ASYHFLOG EQU
BYTE 1
X'80'
X'40'
Bit 08 - Asynch·ronous extended logout control
Bit 09 - Asynchronous fixed logcut control
HARDSTOP
SYHCLOG
IOLOG
RECOVRPT
COHFGRPT
DAMAGRPT
WARHGRPT
section 5. Appendixes
595
BRING
DEFER
LOCK
IOERETN
SYSTEM
EQU
EQU
EQU
EQU
EQU
X'80'
X'40'
X' 20'
X'lO'
X' 08'
Bring requested page
Defer execution until page in storage
Lock page for I/O operation
Return I/O errors to caller
Call to DMKPTRAN for system virtual machine space
DELSEGS
DELPAGES
NEWPAGES
NEWSEGS
KEEPSEGS
OLDVMSEG
EQU
EQU
EQU
EQU
EQU
EQU
X' 80'
X'40'
X'08'
X'04'
X'02'
X'Ol'
Release the segment tables
Release the page/swap tables
Build new page/swap table
Build new segment table
Retain information in old segment table
VMSEG pointer in VMBLOK valid
ERRMSG
NORET
DFRET
OPERATOR
LOGDROP
LOGHOLD
PRIORITY
VMGENIO
NOAUTO
ALARM
NOTIME
INHIBIT
EDIT
UCASE
EQU
EQU
EQU
EQU
EQU
BQU
EQU
EQU
BQU
BQU
BQU
BQU
EQU
EQU
X'0800'
X'0400'
X'0200'
X'OlOO'
X' 80'
X'40'
X' 20'
X' 10'
X'04'
X'02'
X' 0 l'
X '08'
X'04'
X'02'
Output - Control prograa error message
Output - Return immediately after call
Output - Free buffer after queueing
output - Message for system operator
Output - Logoff and drop line after message
output - Logoff and hold line after message
output - write this message immediately
I/O request generated by virtual machine
output - suppress auto carriage return
Output - sound the audible alarm
output - suppress time stamp on message
Input - Prevent display of this data
Input - Edit input data for corrections
Input - Translate data to upper case
RDRCHN
PCHCHN
PRTCHN
ADDS FB
CHGSFB
DELSFB
OPNSFB
ACTSFB
CHGRDV
CHGSHQ
EQU
EQU
EQU
EQU
BQU
EQU
EQU
EQU
EQU
EQU
X' 0 l'
X'02'
X'04'
X'08'
X' 10'
X'20'
X'40'
X' 80'
X'0100'
X'0200'
SFBLOK goes on reader chain
SFBLOK goes on punch chain
SFBLOK goes on print chain
Add new SFBLOK to recovery cylinder
Change existing SFBLOK
Delete SFBLOK from checkpoint
It is an open print-punch file
File being printed or punched
Change attributes of real device
Checkpoint a SHQBLOK
MBCLPERF
MNCOSYS
MBCOTH
MNCOTT
MNCOSUS
MNCLRESP
MNCOBRD
MNCOWRIT
MHCOERD
MNCLSCH
MBCODQ
MNCOAQ
IUICOAEL
MNCLUSER
MNCOUSER
BQU
BQU
BQU
EQU
BQU
EQU
BQU
BQU
BQU
EQU
BQU
BQU
EQU
EQU
BQU
X'OO'
X'OOOO'
X'0061'
X'0062'
X'0063'
X' 0 l'
X'OOOO'
X'OOOl'
X'0002'
X'02'
X'0002'
X'0003'
X'0004'
X'04'
X'OOOO'
MONITOR PERFORM class
PERFORM class; system performance
MONITOR tape header record
MOBITOR tape trailer record
MOBITOR collection suspension record
MONITOR RESPONSE class
RESPONSE class; begin read code
RESPONSE class; write code
RESPONSE class; end read code
MONITOR SCHEDULE class
SCHEDULE class; drop queue code
SCHEDULE class; add to queue code
Schedule class; add to eligable list code
MOBITOR USER class
USER class; user data
596
VM/370: System Logic and Problem Determination Guide
MHCLINST
MNCOSIM
MHCLDAST
MNCODASH
MNCODAS
MHCL SEEK
MBCOCYL
MNCLSYS
MICODA
EQO
EQO
EQO
EQO
EQO
EQ U
EQU
EQO
EQU
X'OS'
X'OOOO'
X'06'
X'OOOO'
X'OOOl'
X'07'
X'OOOO'
X' 08'
X'0002'
MOHITOR instruction simulation class
INST class; instruction simulation code
MOlITOR DASD/TAPE class
DASTAP class; first record
DASTAP class; data records
MONITOR DASD class
DASD class; SEEKs code
MONITOR SYSTEM PROFILE class
SYS class; DASD data
Section 5. Appendixes
597
!~L170 !!~~!~~j!!~
~~~12Qli£ !i~gi§~.§!: ~g.!!~:.!:~§
RO
Rl
R2
R3
R4
R5
R6
R7
R8
R9
Rl0
R 11
R12
R13
R14
R15
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
yO
Y2
Y4
Y6
EQU
EQU
EQU
EQU
0
2
4
6
I!Q!!!1!!g
CO
Cl
C2
C3
C4
C5
C6
C7
C8
C9
Cl0
Cll
C12
C13
C14
C15
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
1
1
1
1
1
1
1
598
1
1
1
1
1
1
General
j~:gi~!i!:
]~!iJ.!il!Q!!§
1
1
1
1
1
___ I
Point
ji:g!§l~!
]~!!J.!!!!Q!!2
Control
j~g!§~~!:
~~!!J.!!l!Q!!§
1
1
1
1
1
___ I
V"1370: system Logic and Problem Determination Guide
This appendix contains
for:
•
CftS Usage
•
CSS Registers
Field
Name
Assembler language equate symbols
used in CftS to
reference data
Field Description
CHANO
CHAN 1
CHAN2
CHAN3
CRAR4
CRANS
CHARM
EXTS
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
X'80'
X'40'
X'20'
X'10'
X'08'
X'04'
X'02'
X'Ol'
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
00
01
02
03
04
05
06
01
-
Channel 0 mask
Channel 1 mask
Channel 2 mask
Channel 3 mask
Channel 4 mask
Channel 5 mask
Input/output mask
External mask
ECSS
MCKM
IiAIT
PROB
EQU
EQU
EQU
EQU
X'08'
X'04'
X'02'
X'Ol'
Bit
Bit
Bit
Bit
12
13
14
15
-
Extended control mode mask
Machine check mask
wait state mask
Problem state mask
FOFM
DOFM
EUFS
SIGH
EQU
EQU
EQU
EQU
X'08'
X'04'
X'02'
X' 0 l'
Bit
Bit
Bit
Bit
36
31
38
39
-
Fixed-point overflow mask
Decimal overflow mask
Exponent underflow mask
significance mask
ATTN
SS
CUE
BUSY
CE
DE
UC
UE
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
X'80'
X'40'
X'20'
X' 10'
X'08'
X'04'
X'02'
X'Ol'
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
32
33
34
35
36
31
38
39
,-
PCI
ICL
PGC
PTC
CDC
CCC
ICC
CRC
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
X' 80'
X'40'
X' 20'
X'10'
X'08'
X'04'
X'02'
X'Ol'
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
40
41
42
43
44
45
46
47
Attention
Status modifier
Control unit end
Busy
Channel end
Device end
unit check
unit exception
- program-controlled interruption
Incorrect length
- Program check
- Protection check
- Channel data check
- Channel control check
- Interface control check
- Chaining check
-
Section 5. Appendixes
599
Field
Nalle
Field Description
~Q!!!Q!! ~h~!!!!!5!l ~Q!!m2!!g ~Qg~~
WRITE
RE1D
NOP
SENSE
WRDATl
RDDATl
SEEK
TIC
WRITE1
RDCONS
SETSEC
SE1RCH
EOU
EOU
EOU
EOU
EOU
EOU
EOU
EOU
EOU
EOU
EOU
EOU
~i~2 Q!5!'iB.!5!~
CD
CC
SILl
SKIP
PCIF
IDl
600
EOU
EOU
EOU
EOU
EOU
EOU
X' 0 l '
X'02'
X'03'
X'04'
X' OS'
X'06'
X'07'
X'OS'
X' 09'
X'OA'
X' 23'
X'31'
i!! 2
-----------------
Write
Read
No opera tion
Sense
Write data
Read data
Seek
Transfer in channel
write and space 1
Read from console
Set sector
Search ID equal
~hg!l!l!5!l ~Q!!!~!!~ !,Q!;:g (~~!O
X'SO'
X'40'
X'20'
X' 10'
X'OS'
X'04'
Bit
Bit
Bit
Bit
Bit
Bit
32 - Chain data
33 - Command chain
34 - suppress incorrect length
35 - Suppress data transfer
36 - Cause program control interruption
Indirect data address
37
-
VM/370: System Logic and Problem Determination Guide
Field
Nalle
RO
Rl
R2
R3
R4
R5
R6
R7
R8
R9
Rl0
Rll
R12
R13
R14
R15
FO
F2
F4
F6
co
C1
C2
C3
C4
C5
C6
C7
C8
C9
Cl0
Cll
C12
C13
C14
C15
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
o
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
o
2
4
6
o
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
section 5. Appendixes
601
Record 0 (8 bytes long)
to X'OO'.
of all
tracks other than track 0 is initialized
32 Pages/cylinder 2314,2319
'--T--T---r
I
I --r--r--,
*IEO 00 00 00 00 00 00 001
L_-L_-L_--'-
I
I
L_'___J
I
11100000
57 pages/cylinder 3330
'--T-T---r
I
f ~--y--,
lEO 00 00 00 00 00 00 001
L-L---L_--'-
I
I
L-I--J
24 pages/cylinder 2305
.---r--~-T---r~---r--Y--,
lEO 00 00 00 00 00 00 001
L-L---L_-L
I
I
•
I
I
120 pages/cylinder 3350 (native mode)
'--T---r---r---r~-~--y--,
IFO 00 00 00 00 00 00 001
L_-L---L_-L
2314 and 2319 32
3330 series
57
2305 and 3340 24
3350
120
I
I
I-'---.J
pages/cylinder
pages/cylinder
pages/cylinder
pages/cylinder
Cylinder 0 contains less pages because this area is used by CP.
*The first three pages of cylinder 0 are always flagged in use. On all
other cylinders, the first byte is a hexadecimal '00' unless the disk
area is flagged as bad. Record 0 of all tracks other than track 0 is
initialized to hexadecimal ·OO~.
Section 5. Appendixes
603
1PL record -- puts
program loaded.
system into wait state if storage
r-------~------~--------~--------~
L _______ -L ________ ________ ________ _______
,
device is initial
--,
100020000 OOOOOOOC 03000000 20000000 00000000 ______
000000001
__J
~
~
~
~
Checkpoint record -- This is the checkpoint program load at CP 1PL time
to retrieve and save control information for a war. start.
4 byte key of VOLl
80 byte data record
Key
r---~
1 VOL 1 1
L __
~
~Ii~§
r-------~
y--------~------~-----,
1-20 IE5D6D3P1 xx------->xxPOOO 00000005 000000001
I
1
21-40 10040
)401
1
1
41-60 14000---->00C3D7 F3F7P040 40404040 40-)401
1
61-80 140
L--_____ -L ________
1
~
________
~
______
~
)401
______
__J
xx->xx is a 6-byte label
Bytes 13-16 contain a pointer to the VTOC
Bytes 46-50 identify the system
Bytes 52-55 contain a pointer to the active directory
604
VM/370: System Logic and Problem Determination Guide
1024 bytes Track 0 Cylinder 0
Allocation byte map used to
identifies one cylinder.
o
identify cylinder
1 usage.
Each byte
r-> all 0<-,
r-------~
~+--------+,
100000100 040200--->FF 0000---->00001
L______
*
~
_________
+-L------------J
*
FF defines the last cylinder + 1 that can be allocated.
depending on the device.
00
01
02
04
This varies
temporary
permanent
T-disk
directory
44 bytes key Track 0, Cylinder 0
96 bytes data area
Format 4 OS DSCE type label - used to be compatible with OS.
,
r--------,
1 04--->041
L _ _ _ _ _ _ _ --I
FORM AT 4 LABEL
1
------I
44 Key
96 Byte Data
44 bytes key Track 0, Cylinder 0
96 bytes data area
Format 5 OS DSCE type label for compatibility with os.
r---I-I--I-I---,
1 05105105105100 1
I_I __ I_I ___J
L_ _
44 Byte Key
4096 bytes
r------------------,
1L-_______________
OS FORMAT 5 LABEL --I1
96 Byte Data Area
1 page, track 0 or track 1
F3 Record is reserved for CP system use.
Referred to as filler record.
section 5. Appendixes
605
1624 bytes, Track 1 (2314, 2319 only)
F4 used only on 2314
position on track.
and 2319
devices to
align Record
824 bytes track 1, cylinder 0 (2314, 2319 only)
First segment of Record 4 to be used for paging.
RO
R1
R2
Key
R3
R4
Key
R5
Key
R6
r----r--T----r-y----r-~_y--T---~__y_---_,__-_,
IPagelI ICheckiVIVOL1 IAllocl
IFormatl
IFormatl
I
IBit IP IPointlOILabellByte I I 4
I I 5
I
I
I Map I L I
ILI
I Map I I
I I
I
I
I
I I
111
I
I I
I I
I
I
I 812414096141 80 .L110241441
961441
96 I
I
L _ _ - L - . l . _ _ _ .l.- I
_ _ _.L_-.l. ____--.L__.L _ _ -.l.-__ --'
RO
RF3
RF4
R4
r----,
I
1
......- - - ,
I I 1 PAGE I I F I LLE R I I
I-I
I-I
I-I
I I 4096 I I 1624 I 1824
r--_,
I
I
I
8
L _ _--'
L _ _ _ --'
RO
R1
r-----,
r---,
I
-.J
L--_--'
R2
r----.
IPage
I I
I I
I
IBit Hapl-I
I-I
I
I
8
I LI _4096
I LI_2472
I
L--_---'
_----'
_ _ _ ,-.J
These records appear as above formats if cylinder is O.
606
VM/370: system Logic and Problem Determination Guide
4 in
proper
RO
R4
R3
R2
r--,
r-----,
r-----,
r---,
1--1
I-I
I-I
I
8
I
I
1624
I
I
4096
I
I
824
I
L ___ - - - - '
'--_ _ _ _ .1
L-_-.I
L _ _ _ _ -.I
RO
R4
R5
r-----,
r----,
r----,
1--1
I-I
I
8
I
I
3272
I
I
3296
I
L _ _ _ -.I
L _ _ _ -.I
L -_ _-.I
RO
R6
R5
r---,
R7
r-----,
I
I-I
I-I
r-----,
1--1
8
I II 800
L ___ - - - - '
RO
I
.I
I 4096 I
'--_ _ _ _.1
I
11648
I
L _ _ _ _ _ .1
R8
R7
r----'
,
r-----,
r-----,
I-I
I-I
I
8
I
I
2448
I
I
4096
I
L _ _ _-.I
L _____ -.I
L----.I
Note: Tracks 0 to 4 are repeated for tracks 5 to 9 (R9-R16), 10 to 14,
(R17-R24), and 15 to 19 (R25-R32). The last record is R32.
RO
r
R1
i
R2
I
Key
T
I
R3
R4
i
Key
R5
Key
R6
-T--T---~-T---~
RF3
I
IPagel! ICheckiVIVOL1 IBytel
IFormatl
IFormatl1
I
IBit IP IPointlOILabellMap I I 4
I
I 5
IPagel
I Map I L I
I LI
I
I
I
I I
I
I
I
I I
111
I
I I
I I
I
I
96 1441
96 140961
I 8 1241 4096141 80 110241441
L ___--L-.L-___ -.l._.L
__ _____ .L__.L _ _ _ _ -.l._-.L-.I
~
~
section 5. Appendixes
607
R3
r-----,
IPage
I I
I I
I I
I
IBit Mapl-I
I-I
I-I
I
I
I I
I I
I I
I
I
8
I L-_
I 4096
I IL _______
4096 --'I IL-_
4096
I
L _______ .I
_ _ --'
_- - - '
RO
r------,
R2
Rl
r------,
r--------,
I
I
I
V
l!:~£!_j~
RSS
RS6
RS1
r-----,
r-------, r-----'
I
1--1
I-I
I-I
I
I
I
I
I
I
I
I
8
I L-_
I 4096
I LI _4096
I IL _4096
L _ _ _ _ _ _ .I
_ _ _--'
_ _ .___ .I
_ _ _.I
RO
r----·-,
RO
R1
R2
Key
r--r--T----T
R4
R3
I
•
-.
Key
I
RS
Key
R6
RF3
-~~---,__-T_,
IPagelI IChecklVIVOLl IBytel
I Formatl
I Format I 1 I I
IBit IP IPointlOILabellMap I I 4
I I S
IPagel I
ISa p I L I
IL I
I
I I
I I
I
I I
I
I I
111
I
I I
I I
I
I I
I 8 1241 4096141 80 110241441
96 1441
96 L140961..I-.JI
L ___ - L _ . L ____ --L-.I..1.--.1.-_ _ _.1.--.1-.-_
RO
R1
r-----,
R2
r-----,
r-----,
R3
r----,
IPage
I I
I I
I I
IBit Mapl-I
I-I
I-I
I
I I
I I
I I
8
IL _4096
I 4096
I 4096
LI______ .II
L-_
_ _.II
_ _ .___ .II
I
I
I
I
L __ - - - - '
I
1!:~£!_1
RO
I
R22
I
V
R23
R24
r---.----,
r----,
I
1--1
1--1
I-I
I
I I
I I
I I
I 8
I L-_
I 4096
IL _______
4096 --'I IL _4096
L _ _ _ _ _ .I
_ _ .JI
_ _ _ _ --'
r-----'
608
r-----,
VM/310: system Logic and Problem Determination Guide
RO
R1
R2
Key
R3
R4
Key
R5
Key
R6
r----T--T-----T-T-----y----T--T------y--y------,
RO
r----'
R1
r-------'
R2
r-----,
~
_
~
~
_
~
~
~
_
~
~
~
IPagel! ICheckiVIVOL1 IBytel
IFormatl
IFormatl
IBit IP IPointlCILabellMap 1
1 4
1
I 5
1
IMap IL I
IL I
I
I
I
I
I
I
1.11
I
I
I
I
I
I
1
I
I
8 1241
4096141 __ 80 110241441
96 1441 ____
96-JI
1L____
__ _____
___
_____
R3
r-----,
IPage
I
I
1
I
I
1
I
IBit Mapl-I
I-I
1--1
I
I
I
I
. I
I
I
I
I
8
I
I 4096
I
IL-______
4096 -JI
IL-_____
4096 -.JI
I
L _______ .J
L _ _ _ _ _.J
I
I
I
RO
r-----'
V
R23
r------,
R24
r-------,
I
1--1
I-I
I
1
I
1
I
I
I
8
1 LI _______
4096 .JI
IL _______
4096 .JI
I
L _______ .J
section 5. Appendixes
609
A virtual machine created by VM/370 is capable of running an IBM
System/360 or System/370 operating system as long as certain VM/370
restrictions are not violated.
If your virtual machine produces
unexpected results, be sure that none of the following restrictions are
viola ted.
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 CPU).
However,
some
dynamically modified
channel
programs
are given
special
consideration by CP:
specifically, 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; and those generated by the OS/VS Telecommunications Access
Method (TCAM) Level 5, with the VM/370 option.
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/370 directory entry. There is
no such restriction for DOS ISAM, or for ISAM if it is running in an
as/vs virtual=virtual partition.
If ISAM is to run in an OS/VS
virtual=real partition, you must specify the ISAM option in the VM/370
directory entry for the OS/vs virtual machine.
virtual machines using OS/VS TCAM (Level 5, generated or invoked with
the VM/370 option) issue a DIAGNOSE instruction when the channel program
is modified.
This instruction causes CP to reflect the change in the
virtual ccw string to the real CCW string being executed by the channel.
CP is then able to execute the dynamically modified channel program
properly.
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.
The following restrictions exist for minidisks:
1.
In the case of read home address with the skip bit off, VM/370
modifies the home address data in user storage at the completion of
the channel program because the addresses must be converted for
minidisks; therefore, the data buffer area may not be dynamically
modified during the input/output operation.
Section 5. Appendixes
611
2.
On a minidisk, if a CCW
string uses multitrack search on
input/output operations, subsequent operations to that disk must
have preceding seeks or continue to use multitrack operations.
There is no restriction for dedicated disks.
3.
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
~eginning of the physical disk (that
is, at cylinder zero). There
1S
no such restriction for DOS ISAM or OS/VS ISAM running
virtual=virtual.
4.
VM/370 does not return an end-of-cylinder condition to
machine that has a virtual 2311 mapped to the top half
tracks 0 through 9) of 2314 or 2319 cylinders.
5.
If the user's channel program for a minidisk does not perform a
seek operation, then to prevent accidental accessing, VM/370
inserts a positioning seek operation into the user's channel
program. Thus, certain channel programs may generate a condition
code (CC) of zero on a SIO instead of an expected CC of one, which
is reflected to the virtual machine. The final status is reflected
to the virtual machine as an interrupt.
6.
A DASD channel program directed to a 3330, 3340, or 3350 device may
give results on dedicated drives which differ from r~sults on
miniaisks 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 terminate the program.
This is
because the record 0 count fields on the 3330, 3340, and 3350 must
contain the real cylinder number of the track on which they
reside.
Therefore, a search ID high, for example, based on a low
virtual cylinder number may terminate prematurely if a real record
o is encountered.
a virtual
(that is,
Note: Minidisks with non-zero relocation factors on 3330, 3340, and
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.
3350
7.
The IBCDASDI program cannot
3340, or 3350 minidisk.
8.
If the DASD channel programs directed to 3330/3340/3350 devices
include a write record R(O), results differ depending on whether
the 3330/3340/3350 is dedicated (this includes a mini disk defined
as the
entire device)
or nondedicated.
For a
dedicated
3330/3340/3350, a write R(O) is allowed, but the user must be aware
that the track descriptor record may not be valid from one
3330/3340/3350 to another. For a nondedicated 3330/3340/3350, a
write record R(O)
is replaced by a read record R(O) and tpe 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
intended.
612
assign alternate
tracks for
VM/370: System Logic and Problem Determination Guide
a 3330,
Timing dependencies in input/output devices
function consistently under VM/370:
1.
or
programming
do
not
The following telecommunication access methods (or the designated
option)
violate the restriction on timing dependency by using
program-controlled interrupt techniques and/or the restriction on
dynamically modified channel programs:
•
as
•
as
•
DOS Queued Telecommunications Access Method
•
OS Telecommunications Access Method (TCAM).
•
OS/VS Telecommunications Access Method
(TCAM)
earlier r and Level 5 if TCAM is not generated or
the VM/370 option.
Basic Telecommunications
dynamic buffering option.
Access
Method
(BTAM)
with
the
Queued Telecommunications Access Method (QTAM).
(QTAM).
Level 4 or
invoked with
These access methods may run in a virtual=real machine with CCW
translation suppressed by the SET NOTRANS ON command. Even if SET
NOTRANS ON is issued r CCW translation will take place if one of the
following conditions is in effect:
•
The channel program is directed at an a nondedicated device
a virtual CTCA r a
(such as a spooled unit record device r
minidisk r or a console).
•
The channel program starts with a SENSE operation code.
•
The channel program is for a dialed terminal.
•
START I/O tracing is in effect.
•
The CAW is
area.
in page zero or
beyond the end of
the virtual=real
(OS BTAM can be generated without dynamic buffering r in which case
no virtual machine execution violations occur. However r
the BTAM
reset poll macro will not execute under VM/370 if issued from third
level storage. For example r a reset poll macro has a NOP effect if
executed from a virtual=virtual storage under VS1 which is running
under VM/370.)
2.
Programming that makes use of the PCI channel interrupt for channel
program modification or processor signalling must be written so
that processing can continue normally if the PCI is not recognized
until I/O completion or if the modifications performed are not
executed by the channel.
3.
Devices that expect a response to an interrupt within a fixed
period of time may not function correctly because of execution
delays caused by normal VM/370 system processing. An example of
such a device is the IBM 1419 Magnetic Character Reader.
4.
The operation of a virtual block multiplexer channel is timing
dependent. For this reason r the channel appears available to the
virtual machine operating system r
and channel available interrupts
are not observed. However r operations on virtual block-multiplexing
Section 5. Appendixes
613
devices should use the available features like Rotational Position
sensing to enhance utilization of the real channels.
On the System/370 Model
158 only, the Virtual Machine Assist feature
cannot operate concurrently with the 7070/7074 compatibility feature
(Feature #7117).
Programs written for CPU model-dependent functions may not execute
properly in the virtual machine under VM/370.
The following points
should be noted:
1.
Programs written to examine the machine logout area do not have
meaningful data since VM/370 does not reflect the machine logout
data to a virtual machine.
2.
Programs written to obtain CPU identification (via the store CPU ID
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.
Programs written to obtain channel identification (via the store
Channel ID instruction, STIDC) receive information from the virtual
channel block.
Only the virtual channel type is reflected; the
other fields contain zeroes.
4.
No simulation of other CPU models is attempted by VM/370.
Other characteristics that exist for a
as follows:
virtual machine under VM/370 are
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 IBM System/370 CPU and channels operates in these
situations but is unable to provide predictable protection to other
virtual machines.
In addition, violation of this restriction may
compromise the
integrity of the
system.
The
results are
unpredictable.
2.
VM/370 has no multiple path support and, hence, does not take
advantage of the two-channel switch.
However, a two-channel switch
can be used between the IBM system/370 running a virtual machine
under VM/370 and another CPU.
3.
The DIAGNOSE instruction cannot be issued by the virtual machine
for its normal function.
VM/370 uses this instruction to allow the
virtual machine to communicate system services requests.
The
Diagnose interface requires the operand storage addresses passed to
it to be real to the virtual machine issuing the DIAGNOSE
instruction. For more information about the DIAGNOSE instruction in
a virtual machine, see the !~LllQ: ~y§~~~ f~~~~g~~~~~§ §~ig~.
614
VM/370: System Logic and Problem Determination 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 off
dedicated unit record devices
or certain self-modifying IPL
sequences off tape devices.
6.
The VM/370 spooling facilities do not support punch-feed-read,
stacker selection, or column binary operations.
Detection of
carriage control channels is supported for a virtual 3211 only.
7.
VM/370 does not support
operator's console.
8.
Programs that use the integrated emulators function only if the
real computing system has the appropriate compatibility feature.
VM/370 does not attempt simulation. The DOS emulator running under
OS or OS/VS is not supported under VM/370.
9.
The READ DIRECT and WRITE DIRECT instructions are not supported for
a virtual machine.
10.
The System/370 SET CLOCK instruction cannot be simulated and,
hence, is ignored if issued by a virtual machine. The System/370
STORE CLOCK instruction is a nonprivileged instruction and cannot
be trapped by VM/370; it provides the true TOD clock value from the
real cpu.
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 NOCLEAR 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 overlayed page is either the result of the following
formula:
count
control
on
the
virtual
1052
virtual machine size
-------------------- =
starting address of the overlayed page
2
or the hexadecimal value 20,000, whichever is smaller.
Section 5. Appendixes
615
14.
To maintain system integrity, data transfer sequences to and from a
virtual system console are limited to a maximum of 2032 bytes.
Channel programs containing data transfer sequences that violate
this restriction are terminated w~th an interrupt whose CSW status
indicates incorrect length and a channel program check.
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.
li2~~:
15.
When an I/O error occurs on a device, the System/370 hardware
maintains a contingent connection for that device until a SENSE
channel command is executed and sense data is recorded. That is, no
other I/O activity can occur on the device during this time.
Under
VM/370, the contingent connection is maintained until the SENSE
command is executed, but I/O activity from other virtual machines
can begin on the device while the sense data is being reflected to
the virtual machine. Therefore, the user should be 'aware that on a
shared disk, the access mechanism may have moved during this time.
16.
The mode setting for 7-track tape devices is maintained by the
control unit.
Therefore, when a virtual machine issues the SET
MODE channel command to a 7-track tape device, it changes the mode
setting of all 7-track tape devices attached to that control unit.
This has no effect on virtual machines (such as OS or DOS) that
issue SET MODE each time a CCW string is to be executed. However,
it can cause a problem if a virtual machine fails to issue a SET
MODE with each CCW string executed.
Another virtual machine may
change the mode setting for another device on the same control
unit, thereby changing the mode setting of all 7-track tape devices
attached to that control unit.
17.
OS/VS2 is supported in uniprocessor mode only.
18.
A shared system or one that uses discontiquous saved segments
cannot be loaded (via IPL) into a virtual machine running in the
virtual=real area.
19.
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.
See
X~LllQ: ~y§!~~ ~~§§~g~~ for additional information.
The following restrictions apply to CMS, the conversational subsystem of
VM/370:
1.
CMS executes only on a virtual IBM system/370 provided by VM/370.
2.
The maximum sizes in cylinders of CMS minidisks are as follows:
~i§~
2314/2319
3330 series
3340 Model 35
3340 Model 70/3344
3350 Series
616
~g~i~y~ £l!in~g~§
203
246
349
682
115
£~~L!~A~
200
404
348
696
not supported in native mode
VM/370: System Logic and Problem Determination Guide
3.
CMS employs the spooling facilities of VM/370 to perform unit
record I/O. However, a program running under CMS can issue its own
SIOs to attached dedicated unit record devices.
4.
Only those OS and DOS facilities that are simulated by CMS can be
used to execute OS and DOS programs produced by language processors
under CMS.
5.
Many types of object programs produced by CMS (and OS) languages
can be executed under CMS using CMS's simulation of OS supervisory
functions.
Although supported in OS and DOS virtual machines under
VM/370, the writing and updating of non-VSAM OS data sets and DOS
files are not supported under CMS.
6.
CMS can read sequential and partitioned OS data sets and sequential
DOS files, by simulating certain OS macros.
The following restrictions
reside on OS disks:
apply when CMS reads OS
data sets tqat
•
Read-password-protected data sets are not read.
•
BDAM and ISAM data sets are not read.
•
Multivolume data sets are read as single-volume data sets.
End-of-volume is treated as end-of-file
and there is no
end-of-volume switching.
•
Keys in
read.
•
User labels in user-labeled data sets are bypassed.
data sets with
The following restrictions
reside on DOS disks:
keys are ignored
apply when
and only the
CMS reads
data is
DOS files
that
•
Only DOS 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 DOS sequential files.
•
The following types of DOS files cannot be read:
--DOS DAM and ISAM files.
--Files with the input security indicator on.
--DOS files that contain more than 16 user label and/or data
extents.
(If the file has user labels, they occupy the
first extent; therefore the file must contain no more than
15 data extents.)
•
Multivolume
files
are
End-of-volume
is treated
end-of-volume switching.
•
User labels in user-labeled files are bypassed.
•
Since DOS files do not contain BLKSIZE, RECFM, or LRECL
parameters, these parameters must be specified via FILEDEF or
DCB parameters; otherwise, defaults of BLOCKSIZE=32760 and
RECFM=U are assigned. LRECL is not used for RECFM=U files.
read
as
as
single-volume
end-of-file.
There
files.
is
no
Section 5. Appendixes
617
•
CMS does not support the use of OS/VS DUMMY VSAM data sets at
program execution time, since the CMS/DOS implementation of the
DUMMY statement corresponds to
the DOS/VS implementation.
Specifying the DUMMY option with the DLBL command will cause an
execution-time error.
7.
Assembler program usage
(lIP) is not supported.
1.
If you intend to run VM/370 Release 1 and pre-PLC 9 Release 2
systems alternately, apply Release 1 PLC 14 or higher (APAR V1179)
to your Release 1 system, to provide compatibility and to prevent
loss of spool files in case of a warm start. Changes to the spool
file format in PLC 9 of Release 2 require a cold start when
switching between pre-Release 2 PLC 9 and post-Release 2 PLC 9
systems.
2.
The number of pages used for input/output must not exceed the total
number of user pages available in real storage. Violation of this
restriction causes the real computing system to be put into an
enabled wait state.
3.
If you intend to define more than 73 virtual devices for a single
virtual machine, be aware that any single request for free storage
in excess of 512 doublewords
(a full page) may cause the VM/370
system to abnormally terminate
(ABEND code PTR007) if the extra
storage i p not available on a contiguous page. Therefore, two
contiguous pages of free storage must be available in order to log
on a virtual machine with more than 73 virtual devices
(three
contiguous pages for a virtual machine with more than 146 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 73
devices should be the first to log on after IPL. The larger the
real machine size, the lesser the possibility of this occurring.
4.
of 16 binary
For remote 3270s,
VM/370 supports a maximum
synchronous lines, minus the number of 3704/3705 Communications
Controllers in NCP mode minus one
(if there are any 3704/3705
Communications Controllers in emulation mode) •
5.
If an I/O device (such as a disk or tape drive) drops ready status
while it is processing virtual I/O activity, any virtual machine
users performing I/O on that device are unable to continue
processing or to log off.
Also, the LOGOFF and FORCE commands are
not effective because they do not complete until all outstanding
I/O is finished. The system operator should determine which I/O
device is involved and make that device ready once more.
618
of VSAM
and the
ISAM Interface
VM/370: System Logic and Problem Determination Guide
Program
Figure 67 indicates those devices that are supported by a CMS machine.
-,
r
I
I
Virtual
IBM Device
3210, 3215,
3066, 3270
2314, 3330,
3350
2314, 3330,
3350
2314, 2319,
3340, 3350
2314, 2319,
3340, 3350
2314, 2319,
3340, 3350
2314, 2319,
3340, 3350
2314, 2319,
3340, 3350
2314, 2319,
3340, 3350
2314, 2319,
3340, 3350
2314, 2319,
3340, 3350
1403, 3211,
2540, 2501,
2540, 3525
2415, 2420,
3420
Virtual I Symbolic I
Address 1 1
Name
I
1052,
ccu
CON1
System console
3340
190
DSKO
system disk
3340
191 2
DSK1
Primary disk (user files)
3330,
ccu
DSK2
Disk (user files)
3330,
ccu
DSK3
Disk
(user files)
3330,
192
DSK4
Disk
(user files)
3330,
ccu
DSK5
Disk
(user files)
3330,
ccu
DSK6
Disk
(user files)
3330,
ccu
OSK7
Disk
(user files)
3330,
19E
DSK8
Disk
(user files)
3330,
ccu
DSK9
Disk
(user files)
1443
3505
OOE
OOC
000
181-4
Line
Card
Card
Tape
printer
reader
punch
drives
3410,
PRN1
ROR1
PCH1
TAP1-TAP4
I
I
Device Type
(read-only)
I
I 1The device addresses shown are those that are preassembled into the
I CMS resident device table. These need only be modified and a new
I device table made resident to change the addresses.
I 2The virtual device address (ccu) of a disk for user files can be
I any valid system/370 device address, and can be specified by the
I CMS user when he activates a disk.
If the user does not activate
I a disk immediately after loading CMS, CMS automatically activates
I the primary disk at virtual address 191.
L
Figure 67.
~
Devices Supported by a CMS Virtual Machine
Section 5. Appendixes
619
Figure 68 indicates
its use.
the DIAGNOSE codes used in
VM/370 and gives a
r-----IFunctionl
I
I Code
IClassl
DMKHVC
Label
Function
--,
DMKHVD I
Label
I
Store extended identification code.
HVDSTIDX
Examine
READCPC
000
G
004
C,E
008
G
Execute VM/370 CP command.
HVCONFN
OOC
G
Pseudo-timer facility.
HVCHRON
010
G
Release virtual storage pages.
HVCPGRL
014
G
Manipulate input spool files.
018
G
Standard DASD I/O.
01C
F
Clear I/O and MC recording areas.
020
G
General virtual I/O interruptions.
024
G
virtual device type inquiry.
028
G
Dynamic TIC modification.
02C
C,E,F
Get DASD
areas.
030
C,E,F
Read a page of error recording data.
Figure 68.
brief explanation of
data
from real storage.
address
HCDSPRD
HVCDISK
of
error
HVDLRER
HVCFAKE
HVDDTYP
HVCDCPM
HVDEREP 1
recording
HVDEREP2
Function Codes for DIAGNOSE Instruction (Part 1 of 2)
-------1
section 5. Appendixes
621
r--------------------------------·------------------------,
I Function I
I
I Code IClassl
I
I
Function
DMKHVC
Module
I
I
DMKHVD
Module
C,F
Beads the system dump spool file.
BVDRSDF
C,E
Beads the system symbol table.
HVDRDSYM
A,B,C
any
A,B,C
G
Dynamically
directory.
updates
BVDDIRCT
VM/310
the
Reserved for IBM use.
HVCEXIT
Reserved for IBM use.
HVCEXIT
Reserved for IBM use.
HVCEXIT
Generate accounting cards.
HVDACCT
Saves 3104/3105 control program image.
HVD3705
Enable
or
interruptions.
HVDEXPA
Virtual
disable
external
console interface for 3210.
Edit
message
settings.
according
to
EMSG
I
I
HVCGRAF
HVCEMSG
Provide virtual machine storage size.
HVCSTOR
Load, find, or purge a named system.
HVCSYS
start of functions specified
by a user.
HVCUSER
________________________________
---J
Function Codes for DIAGNOSE Instruction (Part 2 of 2)
622
VM/310: System Logic and Problem Determination Guide
ZAP is a CMS command that modifies or dumps MODULE,
LOADLIB, or TXTLIB
files.
It may be used to modify
either fixed or variable length MODULE
files.
It is for use by system support personnel only.
Input control records control ZAP processing. They can be submitted
either from the terminal or from a disk file.
Using the VER and REP
control records,
you can verify and replace data or instructions in a
control section
(CSECT).
Using the DUMP control record, you can dump
all or part of a CSECT, or an entire member of a LOADLIB or TXTLIB file,
or an entire module of a MODULE file.
The format of the ZAP command is:
r----------------------------------------------------------------------,
I
I
I
ZAP
I
I {MCDULE }
I LOADLIB [libname 1 ••• libname 3][ (option ••• [) ]]
I TXTLIB
I
I
I
I
I
2Eii2!!§ :
I
I
r
, r ,
I
I
1~~!H1
IIE]!]l
I
I
I
I INPUT filenameilNOPRINTI
IL __________________________________________________
I
L
.J L . J
o_ _ _ _ _ _ _ _ _ _ _ _ _
I
I
I
-.JI
MODULE
LOADLIB
TXTL IB
indicates the type of file that is to be modified or dumped.
libname
is the library name containing the member to be modified or
dumped.
You can specify one to three library names.
The
libname is valid only for LOADLIB and TXTLIB files.
r
~~B~
,
IPRINT
I
INOPRINTI
L
.J
indicates that input to the ZAP service program is submitted
through the terminal.
If you specify TERM, the prompting
message ENTER: is issued, and you can then enter input control
records up to 80 characters long.
If you specify PRINT with
TERM, all output prints on the printer,
but only error
messages display at the terminal.
If you specify NOPRINT with
TERM,
nothing prints on the printer.
All output except
control records displays at the terminal.
r
INPUT filename
,
IPRINT
I
I NOPRINT I
L
.J
specifies that input is submitted from a disk file, filename.
This file must have a filetype of ZAP, and must be a fixed
80-byte sequential file residing on any accessible device. If
you specify PRINT with INPUT filename, all output produced by
the ZAP service program prints on the printer. In addition,
section 5. Appendixes
623
commands and control records in error and error messages
display at the terminal. If you specify NOPRINT with INPUT
filename, nothing prints on the printer.
All output displays
at the terminal.
The following
combinations:
table shows
the
resulting
output of
valid
option
r---------'------------------------------------------'---.------,
1 OPTIONS 1
PRINT
1
NOPRINT
1
1-------,-----------------------------------------,-----I
I
I Commands and control records
1
1
1
INPUT
I
1
I
I Everything on the
in error and error messages 1
on the terminal. Everything 1
to printer.
I
1
terminal. Nothing on
the printer.
1
1
1
1------·_-------------------------------------1
I
I Only error messages on the
I Everything except controll
I terminal.
Everything on the 1 records on the terminal. 1
IL _ _ _ _ _ _ _ _ _ _I_ _ _Printer.
Nothing
on_ _the
printer.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _1
___
_______
_ _ _._
_ _ _----11
1
TERM
ZAP INPUT CONTROL RECORDS
Seven types of ZAP control records
VERIFY, REP, comment, and END.
exist:
NAME,
DUMP, BASE,
VER or
ZAP control records are free form and need not start in position one
of the record but the ZAP program can accept only 80 characters of data
for each control record.
Separate all information by one or more
blanks. All address fields including disp (displacement) fields in VER
and REP control records must contain an even number of hexadecimal
digits, to a maximum of six digits (OD, 02C8, 014318).
Data fields in
VER and REP control records must also contain an even number of
hexadecimal digits, but are not limited to six digits.
If you wish, you
example, 83256482 or
operation.
may separate the data anywhere by commas
(for
8325,6482). The commas have no effect on the
The program sets the NOGO switch on if a control record is found to
be in error. A file cannot be modified once the NOGO switch is turned
on. The next valid NAME record turns the NOGO switch off. This means
that if the control record is the NAME record, all succeeding records
are ignored until the next NAME, DUMP, or END record. For any other
error, only REP control records that follow are ignored.
The DUMP control record resets the NOGO switch off. The DUMP control
record must not immediately precede a BASE, VER, or REP control record.
A NAME control record must precede the BASE, VER, and REP control
records (if any) that follow a DUMP control record.
The DUMP control record allows you to dump a portion or all of a
specified control section, or the complete member or module.
The format
of the output of the dump is hexadecimal with an EBCDIC translation of
the hexadecimal data.
624
VM/370: System Logic and Problem Determination Guide
The DUMP control record is optional.
record is:
r-------
The format of the DUMP control
"----------,
I
I
I
I
r
I DUMP {membername} Icsectname [startaddress [endaddress]] I
I
I
modulename IALL
I
I
J
L
I
I
IL _____________________________________________________________- - - - JI
,
membername
is the name of the member to be dumped, or the member that
contains the CSECT(s) to be dumped. This member must be found
in one of the libraries specified in the ZAP command line.
However, if the library is a CMS TXTLIB, its directory does
not contain member names. Therefore, the program ignores the
member name
(although you must specify it), and the program
searches for the csectname (which you must specify).
modulename
is the name of the module to be dumped, or the module that
contains the CSECT(s)
to be dumped.
If you specify a module
that has no loader table, the program dumps the entire
module.
csectname is the name of the control section that is to be dumped. If
you do not specify csectname, the program dumps only the first
CSECT. The csectname is required for CMS TXTLIBs, optional
for OS TXTLIBs, LOADLIBs, and
MODULE files.
(See the
discussion of csectname under "Name control Record.") You must
not specify csectname for a module created with the NOMAP
option.
ALL
specifies to the program to dump all CSECTs within the
specified member or module. You can specify ALL for MODULE
files, LOADLIBs, and OS TEXTLIBs, but not for CMS TXTLIBS. If
you wish to dump all the CSECTs in a member of a CMS TXTLIB,
you must issue a separate DUMP control record for each CSECT.
startaddress
is the location within the specified CSECT where the dump is
to begin. lhis must be two, four, or six hexadecimal digits.
The start address is the displacement from the beginning of
the CSECT. For example, if you wish to start dumping at
address 08 in a CSECT that begins at location 400, you specify
start address or 08, not 0408.
endaddress
is the last address to be dumped.
This must be two, four, or
six hexadecimal digits.
If you specify no address, the
program dumps the rest of the CSECT.
Note that start and end
addresses apply only when you specify a csectname.
If the
file to be dumped contains undefined areas
(such as a DS in a
TXTLIE member), the hexadecimal portion of the dump contains
blanks to indicate that the corresponding positions are
undefined.
section 5. Appendixes
625
The NAME control record specifies the member or module and CSECT that
contain the data to be verified or replaced by the ZAP operation. The
format of the NAME control record is:
r---------------------------------------------------------------------,
I
I
I
I
IL
NAME
{ membername } [csectname]
modulename
I
I
_ _ _ _ _ _ _ _ _ _ _ _ _ _ - - 1I
membername }
{ modulename
is the member or module that you want to be searched for the
desired CSECT.
csectname
is the name of the desired control section.
You must
specify csectname if the CSECT you wish to modify is in a
eMS TXTLIB
(that is, TXTLIB created by the TXTLIB command
from CMS TEXT decks that do not have a NAME card following
the END card). The directory of a CMS TXTLIB contains only
CSECT names and no member names. The CSECT name specified
in the NAME record is compared with CSECT names in the
directory. If a CSECT match is found and no member name
match is found, the member selected is the one that contains
the CSECT name. The csectname is optional if the CSECT you
wish to modify is a LOADLIB or an OS TXTLIB (that is, a
TXTLIB created by the TXTLIB command from CMS TEXT decks
that have a NAME card after the END card). The dictionaries
of the specified libraries are searched for the member name
and the member is then searched for the CSECT name, if you
specified one.
If you do not specify csectname for a
LOADLIB or an OS TXTLIB, the program uses the first control
section. The csectname is optional for a MODULE file.
The
module named in the NAME control record is located and, if
you specified csectname, the first record is read to
determine the number of records in the module and the
availability of a loader table, which the program can then
search for the csectname. If you do not specify csectname,
the program uses the beginning location of the module. You
are not allowed to specify csectname if the module was
created with the NOMAP option. The NAME control r(~cord must
precede the BASE, VER, and REP control records. If it does
not, the program sets the NOGO switch on.
The BASE control record adjusts displacement values for subsequent VER
or REP control records for a CSECT whose starting address is not
location zero in an assembly listing.
The format of the BASE control
record is:
626
VM/370: System Logic and Problem Determination Guide
----------------,
..-I
I
I
BASE
I
I
I
address
--,,-------------'
L
address
is the starting address of the CSECT.
The address must be
two, four, or six hexadecimal digits. For example, for a
CSECT starting at location 400, you would specify the BASE
0400 in the BASE control record.
If a subsequent VER card
requests verification of location 0408, the BASE of 0400 is
subtracted from 0408, and the program verifies location 08 in
the CSECT.
This example applies if you specify TXTLIB,
LOADLIB, or MODULE and the module map is present.
However, if
no module map is present for a MODULE file
(that is, the
module was generated with the
NOMAP option), then all
operations are performed as if the BASE address is location O.
For example, if you specify a BASE of 400 and the address you
wish to inspect or modify is 408, then you must specify 08 and
not 408 in REP and VER control records. The address in this
case is from the start of the module. If you do not specify
csectname in the NAME control record, you cannot specify any
BASE value other than 00.
The BASE control record is
optional. See the discussion ~nder "VER or VERIFY control
Record." If specified, the BASE control record must follow
the NAME record, but it need not follow the NAME record
immediately.
For example, you could have the following
sequ~nce of control records: NAME, VER, REP, BASE, VER, REP.
The VER control record requests verification of instructions or data
within a CSECT. If the verification fails, the program does not perform
a subsequent REP operation until it encounters another NAME control
record.
The VER control record is
follow a single NAME record.
optional.
More
than one VER
record can
The format of the VER control record is:
..---
------,
I
:{
VERIFY }
VER
disp
I
I
I
I
data
I
L
disp
.
--'
is the hexadeciaal displacement of the data to be inspected
from the start of the CSECT, if you did not submit a BASE
control record for this CSECT.
If you did submit a BASE
control record, then disp is the actual location of the data.
The disp must be two, four, or six hexadecimal digits. This
displacement does not have to be aligned on a full word
section 5. Appendixes
621
boundary. If this displacement value is outside the limits of
the CSECT specified by the preceding NAME control record, the
VERIFY control record is rejected.
data
is the data against which the data in the CSECT is to be
compared. This must be an even number of hexadecimal digits.
For example, if the location you wish to verify is 3CC, and
the CSECT begins at location 2BO, you can either issue:
BASE 02BO
VER 03CC data
or you can omit the BASE control record, subtract the CSECT
start address from the address of the data, and issue:
VER 011C data
This also applies
record.
to the
disp
operand of
the REP
control
The REP control record modifies instructions or data at the specified
location within the CSECT that you specified in a preceding NAKE control
record. The data specified in the REP control record replaces the data
at the CSECT location specified by the disp operand. This replacement
is on a "one-for-one" basis; that is, one byte of data defined in the
control record replaces one byte of data at the location that you
specified.
If the replacement fails, the program does net perform
additional REP operations until it encounters another NAME control
record.
The REP control record is
follow a single NAME record.
optional.
More
than one REP
record can
The format of the REP control record is:
-------,
r
I
I
I
I
disp
data
I REP
L
I _________________________ _
disp
is the hexadecimal displacement of the data to be replaced
from the start of the CSECT, if you did not submit a BASE
control record for this CSECT.
If you did submit a BASE
control record, then disp is the actual location of the data.
The disp must be two, four, or six hexadecimal digits.
This
displacement need not address a fullword boundary.
If this
displacement value is outside the limits of the CSECT being
modified, the program does
not perform the replacement
operation.
data
is the data that is to replace the data in the
must be an even number of hexadecimal digits.
Although you do not have to
data, you should do so to make sure
you expect it to be.
!Q1~:
628
CSECT.
This
verify a location before replacing
that the data being changed is what
VM/370: System Logic and Problem Determination Guide
The ZAP program ignores comment control records.
If the PRINT option is
in effect, the program prints the comments.
The format of a comment
record is:
r----------------------------------------------------------------------,
I
I
I
I
*
I
I
comment
L _____________________________________________________________________ -J
You must follow the asterisk with at least one blank.
The END control record ends ZAP processing.
The END record is required
and must be the last control record.
The format of the END control
record is:
r
I
I END
IL ________________________________________________ _
SPECIAL CONSIDERATIONS FOR USING THE ZAP SERVICE PROGRAM
Before you use the ZAP command against MODULE files, you can
MODMAP command to determine whether a module map exists and
contains.
use the
what it
When a ZAP input file has more than one pair of VER and REP control
records and a VER control record (other than the first) fails, you must
remove the records prior to the failing record and correct the error
before you issue the ZAP command again.
Otherwise, the file being
modified returns to its original status.
If you issue a REP control record against a file that contains an
undefined area (for example, a Define storage area) within the REP data
field and do not issue a VER control record prior to the REP control
record, the bytes prior to the undefined area, if any, are modified and
all the bytes after the undefined area are not modified.
The program
prints warning message DMSZAP248W.
section 5. Appendixes
629
Appendix I
tells you how to apply Program Temporary Fixes
(PTFs) and
updates to an installed VM/310 system. It contains information about the
following:
•
supporting a VM/310 system
•
Updating modules using the VMFASM EXEC procedure
•
Using the VMFMAC EXEC procequre to
•
using VMFLOAD to generate a new nucleus
•
The loader
•
Using the GENERATE EXEC procedure to generate
nucleus, or to load IPCS
•
Using the VMFBLD EXEC procedure to build a new nucleus
•
Using the CMSGEND EXEC procedure to generate a CMS module
•
Using the ASMGEND EXEC procedure to generate the Assembler
•
Recommended procedures for updating VM/310
updat~
macro libraries
a new CP, CMS, or RSCS
The multiple virtual machine environment created by VM/310 permits
support of both hardware and software to be done concurrently with other
installation work.
virtual machines can be used to:
•
•
•
•
•
•
Generate and test new systems
Apply and test PTFs
Run hardware diagnostics
Retrieve and examine VM/370 ABEND dumps and error recordings
Examine portions of real VM/310 storage
Trace the execution of a system in a virtual machine
Before installing VM/310, you should develop an account support plan
with the IBM FE representative.
Appropriately configured virtual
machine entries should be included in the VM/310 directory for the
service representative. Two virtual machines, with userids CE and MAINT,
are defined
for these representatives
in the
VM/310 directory
distributed with the starter system.
Using the VM/310 update facility, you can update files with several
levels of updates and/or any number of program temporary fixes (PTFs).
Procedures are supplied for assembling the updated source code to
produce a uniquely identifiable text file.
The file has a unique
section 5. Appendixes
631
filename and records that identify the
libraries, and source statements.
origin of
the updates,
macro
Procedures are provided for generating load files fr~m various object
modules, and for generating MACLIB files from various COpy and MACRO
files.
The update procedure involves a file naming convention for update and
text files, a set of programs to support the processing, and a set of
EXEC procedures to process the files.
The update procedures and programs supplied with VM/370 are:
•
VMFASM
•
•
•
VMFLOAD
CMSGEND
GENERATE
GENERATE IPLDECK
•
GENERATE SRVCPGM
GENERATE IPCS
VMFMAC
CMS UPDATE Command
•
•
•
•
Incorporates PTFs and/or updates and creates a
new text file
Generates a new CP, CMS, or RSCS nucleus
Generates a new CMS module
Generates a new VM/370 system (CP, CMS, or RSCS)
Generates a
new standalone version of a service
program on disk
Punches the service programs on cards
Loads the IPCS modules onto the IPCS disk
Generates a new CP, CMS, or RSCS macro library
Updates modules
All modules prefaced by the letters DMK are CP modules. There are two
kinds of CP modules: those that are part of the CP nucleus
(these
modules are contained in the CPLOAD EXEC file) and those that are not
part of the CP nucleus (service programs that execute either standalone
or under CMS).
The programs that execute standalone are DMKDDR, DMKDIR,
and DMKFMT. If you apply a PTF to these modules and create a new text
deck, use the GENERATE EXEC to create a new standalone file.
632
VM/370: System Logic and Problem Determination Guide
The service programs that execute under CMS are:
•
•
•
•
DASD Dump Restore Program (module DMKDDR)
Directory program (module DMKDIR)
VMFDUMP, the virtual dump program (module DMKEDM)
NCPDUMP, the 3704/3705 dump program (module DMKRND).
If you apply updates to these modules,
use the CMSGEND EXEC to create a
new CMS module.
The module name to specify is DDR, DIRECT, NCPDUMP, or
VMFDUMP, respectively.
CMS cannot execute the Format/Allocate program
(mod ule DMKFMT)
and the IBCDASDI Virtual Disk Initialization program
(module IBCDASDI).
If you apply a PTF to any DMK module other than
these six service programs, you must reload CP
(using the VMFLOAD
command).
UPDATING A MODULE
The following discussions assume that areas containing the source code
for CP
and CMS are added
to the appropriate
virtual machine
configurations.
Source code for the CMS system is included on the CMS2
tape; source code for CP is included on the CP2 tape. These tapes are
distributed by the Program Information Department (PID).
VM/370 has update procedures to incorporate changes
(additions,
deletions, or corrections) into an existing module, macro, or copy file.
For example, if you apply updates to the DMKVAT module, the VMFASM
update procedure:
•
Locates the DMKVAT source file.
It is the unmodified Assembler
language source code that is distributed with the VM/370 system.
•
Locates the update control file for DMKVAT.
The control file name is
specified on the VMFASM command.
The control file can have any
filename, but must have a filetype of CNTRL.
It contains records
indicating how to apply the updates.
•
Applies the updates to tqe specified source (in this case, DMKVAT)
and gives the updated source a
temporary name by concatenating a $
(dollar sign) to the first seven characters of the filename (in this
case, the temporary filename is $DMKVAT).
•
Puts macro library names specified in the control file into the
proper Assembler library list.
(The macro libraries required at
assembly time are specified in a MACS record in the control file.)
•
Assembles the updated source file
($DMKVAT) and creates an updated
object deck.
The object deck filetype is derived from information
found in the control file. The filename of the updated object file is
the same as that of the original source, DMKVAT.
As the VMFASM update procedure progresses from one step to the next,
informational or error messages are displayed. To more fully understand
how the update procedures operate, you need to know what a control file
contains, and how it is handled.
The following discussion provides this
information.
Section 5. Appendixes
633
CONTROL FILES
The CMS UPDATE command and the VMFASM EXEC procedure use control files.
You may have one or more control files to specify various combinations
of updates and macro libraries to be used at different times. A control
file contains the following types of records:
•
The MACS Record -- This record contains the names of macro libraries
to be used at assembly time.
A MACS record is required for a control
file used by the CMS UPDATE command; it is optional for a control
file used by the VMFLOAD EXEC procedure.
A control file must not
contain more than one MACS record. If a MACS record is included r it
must precede any other records except comments. Up to eight libraries
may be specified in the MACS record (if space permits). A MACS record
has the following format:
uplevel MACS libl lib2 lib3 •••
The uplevel. field is usually
filetype of the updated file.
•
TEXT; it is
not used to
generate
th~
Update identification records--These records identify updates that
are to be applied to a particular source filer if such a file exists.
An update identification record has the following format:
uplevel upid
where uplevel is an update level identifier that generates a filetype
for the new file (the new filetype uniquely identifies the updated
source file).
The field r upid r is the update identification; it can
he from one to four characters long. This update identification is
concatenated with the prefix UPDT to identify the filetype of the
direct update to be applied.
The filename must be the same as the
name of the file to be
updated.
For example r if an update
identification record for DMKVAT is:
TEXT NEW1
the update file is called DMKVAT UPDTNEW1.The update level identifier
is TEXT.
•
AUX file identification records--These records contain the names of
auxiliary files
(AUX files) r which in turn contain a list of
filetypes of update files to be applied to a particular source file.
An auxiliary file identification record has the following format:
uplevel AUXnnnn
where uplevel is an update level identifier that generate~ the
filetype of the updated source file.
The string r nnnnr 1S an
identification string that can be from one to four characters long.
This identification string,
with the prefix AUX, is the filetype of
the auxiliary file that contains the list of updates to be applied.
The filename of the auxiliary file is the same as the filename of the
source file to be updated. For example, if an AUX file identification
record that contains a list of updates for DMKVAT is:
TEXT AUXnnnn
then the auxiliary file called DMKVAT AUXnnnn contains the filetypes
of the update files that are to be applied. These update files have
the same filename as the source file to be updated.
634
VM/370: System Logic and Problem Determination Guide
•
Commen ts-- An asterisk
(*)
in
identifies a comment record.
the
first
column
of
the
record
Note: Control file records in the format that was used under VM/370
Release 1 or 2 are still accepted under Release 3. Por example, an AUX
file identification record in the format
TEXT nnnn AUX
is still accepted by the update procedures.
A control file can have many update identification records, AUX file
identification records, and comments, but can have only one MACS
record. The control file can have any filename. Note,
however, that
VM/370 updates from IBM normally use the following special control
files:
•
A control file for CP source, copy,
and macro updates is called
DMKR30 CNTRL. The DMKR30 CNTRL file contains the following records:
- TEXT
- TEXT
•
A control file for CMS source updates is called DMSR30
DMSR30 CNTRL file contains the following records:
- TEXT
- TEXT
•
The
MACS CMSLIB OSMACRO
AUXR30
DMSM30
AUXM30
A control file for assembling the NCPDUMP source is called NCPR30
CNTRL.
The NCPR30 CNTRL file contains the following records:
- TEXT
- TEXT
•
CNTRL.
A control file for CMS macro and copy updates is called
CNTRL.
The DMSM30 CNTRL file contains the following record:
- COpy
•
MACS DMKMAC CMSLIB OSMACRO
AUXR30
MACS OSMACRO DMKMAC CMSLIB
AUXR30
A control file for assembling RSCS source, copy, and macro updates is
called DMTR30 CNTRL.
The DMTR30 CNTRL file contains the following
records:
- TEXT
- TEXT
MACS DMTLOC DMTMAC
AUXR30
PTF updates are distributed in card or magnetic tape form, cr as APAR
answers typed on coding forms. In any case, a CMS file (with the correct
filename and filetype) must be created on a disk to contain the update.
The disk must belong to the user (userid MAl NT) who is responsible for
updating VM/370. The disk may be the CP or CMS source disk, but it is
usually a separate disk.
section 5. Appendixes
635
A suggested virtual machine configuration
for updating a 2314 system
is:
USER MAINT CPCMS 720K 16M BCEG
ACCOUNT (install ation defin ed)
OPTION ECMODE REALTIMER
CONSOLE
009
3215
SPOOL
OOC
2540
READER A
SPOOL
OOD
2540
PUNCH A
SPOOL
OOE
1403
A
MDISK 190 2314 035 110 CPV 3LO MR
MDISK
191 2314 019 010 CPV3LO WR
MDISK
194 2314 145 058 CPV3LO MR
MDISK
199 2314 034 001 CPV3LO WR
MDISK
193 2314 001 050 USERDl MR
MDISK
294 2314 051 050 USERDl MR
MDISK 393 2314 001 110 USERD2 MR
MDISK
394 2314 001 110 USERD3 MR
MDISK 390 2314 101 003 USERDl MW
MDISK
cuu 2314 000 203 yyyyyy MW
READ
READ
READ
READ
READ
READ
READ
READ
READ
where cuu and yyyyyy are the address and label of your system residence
volume defined in your DMKSYS module.
A suggested virtual machine configuration
for updating a 3330 system
is:
USER MAINT CPCMS 720K 16M BCEG
ACCOUNT (installation defined)
OPTICN ECMODE REALTIMER
CONSOLE
009
3215
SPOOL
OOC
2540
READER A
SPOOL
OOD
2540
PUNCH A
SPOOL
OOE
1403
A
MDISK
190 3330 030 076 CPV3LO MR
MDISK 191 3330 016 007 CPV 3LO WR
MDISK
194 3330 106 044 CPV3LO MR
MDISK
199 3330 029 001 CPV3LO WR
MDISK
193 3330 001 030 USERDl MR
MDISK 294 3330 031 030 USERDl MR
MDISK
393 3330 061 060 USERDl MR
MDISK 394 3330 121 060 USERDl MR
MDISK
390 3330 181 002 USERDl MW
MDISK cuu 3330 000 404 YYYYYI MW
READ
READ
READ
READ
READ
READ
READ
READ
READ
where cuu and YYIIYI are the address and label of your system residence
volume defined in your DMKSYS module.
636
VM/370: System Logic and Problem Determination Guide
A suggested virtual machine configuration
for updating a 3340 system
is:
USER MAINT CPCMS 720K 16M BCEG
ACCOUNT (installation defined)
OPTION ECMODE REALTIMER
CONSOLE
009
3215
SPOOL
OOC
2540
READER
SPOOL
000
2540
PUNCH
SPOOL
OOE
1403
A
MDISK 190 3340 048 203 CPV3LO
MDISK 191 3340 026 015 CPV3LO
MDISK 194 3340 251 098 CPV3LO
MDISK 199 3340 046 002 CPV3LO
MDISK 193 3340 001 090 USERD1
MDISK 294 3340 031 090 USERD1
MDISK 393 3340 061 180 USERDl
MDISK 394 3340 121 180 USERD1
MDISK 390 3340 181 006 USERD1
MDISK cuu 3340 000 348 yyyyyy
A
A
MR
WR
MR
WR
MR
MR
MR
MR
MW
MW
READ
READ
READ
READ
READ
READ
READ
READ
READ
where cuu and yyyyyy are the address and label of your system residence
volume defined in your DMKSYS module.
The entries in the preceding VM/370 directory, with the exception of
the 193, 294,
393, 394, and 390 virtual disks, are in the 2314, 3330,
and 3340 VM/370 directories supplied with the starter system, and should
be included in your VM/370 directory, because IBM uses them for
support.
The contents of the preceding virtual disks are:
Disk fQ!!~~!!!:2
Current CMS system disk
Work area
191
19i~
CP and RSCS text retention
199 The 191 minidisk (work area)
193 CMS PTFs, updates, and updated text decks (object modules)
and updated text decks
(object
294 CP and RSCS PTFs, updates,
modules)
393 CMS source and macros
394 CP and RSCS source, macros, and copy files
390 CMS test nucleus area
cuu CP system residence device, or a replica of it, for test
purposes
190-
These·virtual disks are shown in Figure 69.
You should apply all distributed updates.
Once you create the
appropriate files, you should access the disks containing the CP, eMS,
or RSCS source files and update procedures, and apply the updates.
To apply the IBM distributed updates to an existing source file, use
the VMFASM EXEC procedure. To apply the IBM distributed updates to a
copy or macro file, use the VMFMAC EXEC procedure.
If you update a copy or macro file, you should use the VMFASM EXEC
procedure to reassemble the module(s) that contain that copy or macro
file.
section 5. Appendixes
637
Figure 69.
system support plan
Use the VMFASM EXEC procedure to update a specified source file
according to entries in a control file, and to assemble the updated
source file.
VMFASM invokes the eMS UPDATE command. The format of the
VMFASM command is:
638
VM/370: System Logic and Problem Determination Guide
r----------------------------------------------------------------,
VMFASM I fn 1 fn2 [ (options ••. [) ]]
I
I
I
I
QE~i2n§:
I
I,.
,,.
,,.
,
I IDISK I ITERM
I 11!~±
I
I IE~!]!:I I!!Q!:lH!~1 INOLISTI
.J
L
.J
L
J
I L
I
I
I
I
I,.
I
,
,.
,
, IDECK
"RENT I [EXP] [XREF]
I
, I !!QQ~~!i I , !tQ1!]!1 ,
,
I L
.J
L
.J
I
____________________________________________________________ -.J
fnl
is the filename of the source file to be updated.
fn2
is the filename of the control
a filetype of CNTRL.
file. The control file must have
QE!i9n§:
DISK
places the LISTING file on a virtual disk.
EB!!1
writes the LISTING file to the printer.
TERM
writes the diagnostic information on the SYSTERM data set. The
diagnostic information consists of the diagnosed statement
followed by the error message issued.
!!Q!:§~~
suppresses the TERM option.
1!~1
produces an Assembler listing.
NOLIST
does not produce an Assembler listing.
DECK
writes an object module on the device specified on the FILEDEF
statement for PUNCH.
!QQ]£!i
suppresses the DECK option.
RENT
checks the program for a possible violation cf program
reenterability. Code that makes the program nonreenterable is
identified by an error message.
!!QE§]1
suppresses the RENT option.
EXP
expands printing of certain macros which check for the SUP
parameter issued via the SYSPAEM option of the assembler.
XREF
causes the XREF(SHORT)
invokes the assembler.
option to
be
~Q~g:
invoked
VMFASM only accepts the non-defaulted options.
entered are ignored and the defaults are used.
The control file contains records that identify
applied and the macro libraries, if any, needed to
when
VMFASM
All other options
the updates to be
assemble the source
section 5. Appendixes
639
program. The updates are applied starting with the last update file in
the control file and in sequence up to the first update file
(or the
update file immediately following the HACS record).
Updates identified
by auxiliary files are applied starting with the last update in the
auxiliary file and proceeding in sequence up to the first.
For example,
a control
following two records:
TEXT
IBHl
HACS
DHKHAC
AUX2000
file
CHSlIB
named
UPDATEl
CNTRl
contains
the
OSHACRO
An Assembler language source file is named DHKVAT ASSEHBlE.
An auxiliary file named DHKVAT AUX2000 contains a list of filetypes
(NEW2 and NEW1) with NEW2 the first entry and NEWl the last.
The two update files are named DHKVAT NEWl and DHKVAT NEW2. These
are the files identified by the auxiliary file,
DHKVAT AUX2000. Assume
these files contain IBM-supplied updates to DMKVAT, such as inserted,
deleted, or replaced source statements and the appropriate control
statements. The update control statements are described in the !~LllQ:
f~§ fQmm~~~ ~ll~ ~~££Q ~gtg£g~~g with the CMS UPDATE command.
To update DMKVAT, you enter the command:
VMFASH DMKVAT UPDATEl
VMFASM does the following:
•
VMFASM locates the DMKVAT ASSEMBLE and UPDATEl CNTRl files.
•
The UPDATEl
CNTRL file is processed from
entry found is IBMl AUX2000.
•
VHFASM tries to locate the file named DHKVAT AUX2000 by searching all
accessed disks.
•
When VHFASH locates the DHKVAT AUX2000 file, it processes it from the
bottom up. The first entry found is NEW1.
•
VMFASM tries to locate the the update file named DMKVAT NEil. When it
finds DMKVAT NEW1, VHFASM applies the updates that are in DMKVAT NEWl
to the DHKVAT ASSEHBLE file, and creates a new file called $DMKVAT
ASSEMBLE.
•
Next, VMFASH processes the NEW2 entry in the DMKVAT AUX2000 file.
When VMFASM locates the update file DMKVAT NEW2,
it applies the
updates to the updated ASSEMBLE file ($DHKVAT).
•
Because there are no more filetypes listed in the DMKVAT AUX2000
file, VMFASH reads the next control record in the UPDATEl CNTRl file.
In this case, it is the MAes record.
640
the bottom up.
VM/370: System Logic and Problem Determination Guide
The first
•
After entering the macro library names
into the appropriate Assembler library
updated ASSEMBLE file ($DMKVAT).
•
The UPDATE command then stacks in the console read buffer the uplevel
(update level identifier) associated with the last update applied. If
there were no updates, it stacks the uplevel associated with the MACS
control record and the names of the macro libraries specified in the
MACS record. VMFASM then reads the stacked lines and concatenates the
uplevel
(if it is not TEXT)
to the characters TXT to form the
filetype of the assembled updated source.
that are on the MACS record
lists, VMFASM assembles the
An update level identifier of TEXT causes special handling in the
VMFASM EXEC procedure, whether or not an update is used with it. A
name of TEXT is used as the object module filetype without level
identification concatenation. Thus, TEXT becomes the filetype.
VMFASM places the macro library names that were specified en the MACS
record in the Assemble library list (via the CMS GLOBAL command) so
that those libraries can be used when the updated source file is
assembled.
In this example, the last (and only) update applied was identified as
IBM1 AUX2000. The file identification for the updated source is
DMKVAT TXTIBM1. The updated source is assembled using the macro
libraries DMKMAC, CMSLIB, and OSMACRO.
You may want, on occasion, to have entries in a control file that
specify an update level identifier but no update.
A record of the
following format, for example, is allowed:
NAMES
because the control file is used for loading object modules (text decks)
as well as for updating input files.
If updates are not
continues, if possible.
found, a
message
is
issued
and
processing
If you wish to apply your own update to VM/370 (for example, if you wish
to expand the accounting routines), you follow the same procedure
described for applying IBM-supplied updates.
You create the update file. You can name the update file in either of
two ways. If you are going to identify the update file directly in the
control file, use the form:
DMKACO UPDTupid
where DMKACO is the filename of the accounting module
expand, and upid is the identification for the filetype.
you might call your update file:
you wish to
For example,
DMKACO UPDTFIXl
section 5. Appendixes
641
The second way to identify your update is via an auxiliary file. If
you use an auxiliary file, you use the following form to name your
upda te file:
DMKACO ft
where DMKACO is the filename
expand and ft is any filetype.
of the
accounting routine
you wish
to
For example, you could have two update files called:
DMKACO NEWl
DMKACO NEW2
When you decide to use an auxiliary control file, it must have a name in
the form
DMKACO Auxnnnn
For example, assume you have an auxiliary control file called:
DMKACO AUXllll
This AUX
files) :
file has the following
entries (the filetypes of
your update
NEW2
NEW 1
Next, you must create a control file to identify all IBM-supplied
updates to the module you are changing and your own updates.
You must
apply the IBM-supplied updates first.
Assume there are IBM-supplied
updates in an auxiliary file called:
DMKACO AUXR30
and that your own updates are those used as examples in the preceding
paragraphs. Then, you need your own control file, identified as:
fn CNTRL
It can have any filename, but its filetype
example, the control file is called:
must be
CNTRL. For
Lec CNTRL
and it has the following records:
TEXT MACS DMKMAC
LOCAL FIXl
SPEC AUXllll
IBM 1 AUXR30
To apply the updates to DMKACO, issue the command:
VMFASM DMKVAT LOC
The VMFASM procedure handles the update as follows; it:
•
Locates the source file, DMKACO.
•
Locates the control file, LOC CNTRL.
•
Reads the control file, last line first (IBMl AUXR30).
642
VM/370: System Logic and Problem Determination Guide
this
•
Locates the IBM-supplied auxiliary file, DMKACO AUXR30.
•
Reads the DMKACO AUXR30 auxiliary file from bottom to top and applies
the IBM-supplied updates to DMKACO, naming the updated source $DMKACO
ASSEMBLE.
•
Reads the next entry in the control file
•
Locates your own auxiliary file, DMKACO AUXllll.
•
Reads the last entry (NEW1), locates the update file DMKACO NEW1, and
applies the update to the updated source $DMKACO.
•
Reads the next entry in your auxiliary file
(NEW2), locates the
corresponding update file DMKACO NEW2, and applies it to the updated
source $DMKACO. Processing for your auxiliary file is now complete.
•
Reads the next entry in the control file
•
Locates the directly-identified update file, DMKACO UPDTFIX1.
•
Applies the DMKACO UPDTFIXl updates to the updated source ($DMKACO).
•
Reads the next control record, the MACS record.
•
Issues the GLOBAL command for the macro libraries
MACS record (DMKMAC MAC LIB).
•
Assembles the updated source file, $DMKACO ASSEMBLE.
•
Names the object module DMKACO TXTLOCAL. The filetype is derived by
concatenating the prefix (TXT)
and the uplevel of the last upda te
applied (LOCAL).
(SPEC AUXllll).
(LOCAL FIX1) •
identified on the
If you create a new object module for a VM/370 module, you must also
reconstruct the CP, CMS, or RSCS nucleus using the VMFLOAD service
program. Or, if the file is a part of a CMS command module, use the
CMSGEND procedure to generate a new module utilizing the new object
code. See Appendix D to determine whether the CMS nucleus or some other
MODULE files must be generated again because of your update.
When you use CMSGEND to create a new module, you must change the
filetype of the object deck to TEXT (if it is not already TEXT) before
issuing the CMSGEND command.
After the CMSGEND processing is complete,
you can change the filetype of the object deck back to what it was
before.
Note that CMSGEND renames the existing module to "fname MODOLD"
before creating the updated module.
This ensures that any users
currently using the CMS system do not have their processing interrupted
by the updating of modules, because the SSTAT (system status table) of
the loaded system is still pointing to the area on the system disk
occupied by the renamed modu1e. When the system is reloaded, the SSTAT
points to the updated module, and the old module can be erased.
section 5. Appendixes
643
VMFASM invokes the UPDATE command, which produces two output files that
indicate which updates were applied. The file
fn UPDATES
lists the names of update
(fn) and the file
files that were
applied to the
source file
fn UPDLOG
lists the actual updates that were applied to the source file (fn) and
error messages.
Both of these files are included in the LISTING file,
and precede the program source statements. Also, the file
(fn UPDLOG)
precedes the object code in the text file.
644
VM/370: System Logic and Problem Determination Guide
I!HH~!
A
ABEND
(2~~ abnormal termination (ABEND»
ABEND macro
17
abnormal termination (ABEND)
11
CMS 16
codes 559
collect information 41
printing dumps 41
procudure when occurs 17
reading dumps 41
reason for
16,41
register usage 43
CP 12
codes 542
collect information 36
printing dump from tape 35
procedure when occurs 12
reading dumps 35
reason for
12,35
register usage 36
save area conventions 36
debugging procedures 15
dumps 34
messages
19
operating system 18
problem types 21
virtual machine (other than CMS)
18
ACCESS command 136
access methods
BDAM 193
restrictions 135
BDAM/QSAM
193
BPAM 193
for non-CMS environments 193
OS 193
supported by CMS 134
VSAM 193
CMS support for
193
accessing
a virtual disk 182
the file system 182
accounting card, processing 97
active disk and file storage management
182
acti ve disk table (ADT)
182
used in disk management 182
active file table (AFT)
182
used in file management 182
ADSTOP command 480
allocated
free storage, types of 185
storage, releasing of 188
allocating
free storage
nucleus
121
user 120
allocation
cylinder 81
management 76
of DASD space 94,226
of nucleus free storage 188
of storage 225
of user free storage 187
page frame, free storage 85
slot 80
AMSERV function, execution of
193
analyzing the problem 12
appendixes 587
applying PTFs 631
areas
nucleus constant (NUCON)
41
program, user and transient 126
assist feature, virtual machine 49
attaching
a real device 87
a virtual machine to the system 85
virtual machine, to the syst~m 229
attributes, spool file 97
AXS system service task, program
organization 241
B
batch
CMS
213
modules used in
215
BDAM
CMS support of 193
restrictions 135
BDAM/QSAK, CMS support of 193
BEGIN command 482
binary synchronous line
enabling/disabling, remote 3277
error recovery, 3270 224
bisync lines
data formats 75
I/O programs for 74
BPAM, CKS support of 193
224
C
called routine
modifications to system area
128
pSW fields
128
register
contents
128
restoration 128
register contents, when started 167
return location
126
returning 126
start-up table 128,167
caller, returning to 167
calling
DMKFREE
for a large block 85
for a subpool 84
DKKFRET
for a large block 85
for a subpool 85
calls
SVC
invalid 125
Index
645
simulation by OS and DOS/VS macro
125
carriage control characters, C~S 184
CCH (channel check handler)
100
overview 105
subroutines
channel control 105
channel error analysis 106
chain header block 186
FLCLB in 187
FLCLN in 187
FLHC in 187
FLNU in 187
FLPA in 187
format 186
MAX in 187
NUM in 187
POINTER in 186
SKEY in
187
TCODE in 187
chain links 178
changes, user status 91
channel, dedicated, support 72
channel check, interrupt, processing of
235
channel check handler
(§gg CCH (channel
check handler)}
channel-to-channel adapter, virtual 68
CHECK processing, os VSA~ 197
checkpoint
spool file 237
recovery of closed 237
clock interrupt reflection 217
CLOSE, OS VSAM, simulation of 197
closed, checkpointed spool files, recovery
of 237
closing
virtual machine input files 233
virtual output files 233
CMS (Conversational Monitor System)
ABEND 16
debugging procedure 17
procedure when occurs 17
reason for 16,41
recovery function 17
ABEND codes 559
ABEND dump
printing 41
reading 41
ABEND macro 17
accessing the file system 182
batch facility 213
modules used in 215
command
handling 163
language 111
processing 127
commands for debugging 568
BREAK 569
CAW 571
CSW 572
DEBUG 568
DEFINE 573
DUMP 574
GO 575
GPR 576
HX 577
ORIGIN 578
646
PSW 579
RETURN 580
SET 581
STORE 582
SVCTRACE 584
X 583
console management 163
control blocks 42
debugging
collect informaiton 41
comparison with CP facilities 33
register usage 43
debugging commands 568
BREAK 569
CAW 571
CSW 572
DEBUG 568
DEFINE 573
DUMP 574
GO 575
GPR 576
HI 577
ORIGIN 578
PSW 579
RETURN 580
SET 581
STORE 582
SVCTRACE 584
I
583
DEVTAB (device table)
115
disk organization 178
disk storage management 180
DOS/VS support 137
dynamic storage management 182
equate symbols 599
error codes
D~SFRES
558
D~SFRET
558
D~SFREX
558
file
execution 163
processing 163
file status table block 178
file status table format 178
file status tables 177
file system 111,113
accessing 182
management 177
files, storage organization of 177
first command processing 162
free storage management 185
functional information 115
handling
of PSi keys 190
PSW keys 124
SVC 124
initialization for OS SVC handling 162
interactive console environment 163
interface, display terminals 129
interrupts
external 115
handling 112
I/O 114
machine check 115
processing 184
program 114
SVC 112
introduction 111,160
IBM VM/370: System Logic and Problem Determination Guide
IPL command processing 160
label to module cross reference 281
load map 43
sample of 44
loader 168
loading, from card reader 160
maintaining interactive session 163
management, free storage 116
master file directory 180
miscellaneous functions 213
module entry point directory 247
module to label cross reference 265
nucleus constant (NUCON) areas 41
nucleus load map 43
OS and DOS VSAM
functions supported 138
hardware devices supported 138
OS simulation
access method support 134
BDAM restrictions 135
data management 130
handling files that reside on eMS
disks 130
handling files that reside on OS or
DOS disks 130
macro
130
notes 131
reading DOS files using OS macros
136
reading OS data sets using OS ,macros
136
supervisor calls 131
overview of functional areas 155
printer carriage control 184
printing a file 184
processing, commands entered during 164
program
development 112
organization 155
punching a card 183
read disk I/O
185
reading a card 183
record formats 178
register usage 115
restrictions on, as a saved system 191
return codes 557
routines that access the file system
182
simulation
of DOS environment 207
of OS by
198
storage
constant initialization 160
map
117,161
structure 116
structure of DMSNUC
115
system functions 156
USERSECT (user area)
115
virtual devices used in 619
virtual machine initialization 160
write disk I/O
185
ZAP service program 623
CMS commands
ACCESS 136
DEBUG 17,41,568
FILEDEF 136
MODMAP 43
VMFDUMP 34
CMSAMS-CMSVSAM DCSSs, storage relationships
with DMSASM 194
CMSCB, defined 199
CMSCVT, defined 199
CMS/DOS
CLOSE functions 209
routines that perform them 209
DOSLKED command 210
environment, termination of 213
execution related control commands 210
FETCH command 210
initialization 207
data areas 207
OS VSAM processing 196
OPEN functions 209
routines that perform them 209
service command processing 213
SVC functions
CANCL- SVC 6 211
CDLOAD-SVC 65 212
EOJ-SVC 14 212
EXCP-SVC 0 211
FETCH- SVC 1 211
FETCH-SVC 2 211
FETCH- SVC 4 211
FREEVIS-SVC 62 212
GETVIS-SVC 61 212
MVCOM-SVC 5 211
POST-SVC 40 212
RELEASE-SVC 64 212
RUNMODE-SVC 66 212
SECTVAL-SVC 75 212
simulation of 211
SVC 11 211
SVC 12 211
SVC 16 212
SVC 17 212
SVC 26 212
SVC 33 212
SVC 34 212
SVC 37 212
SVC 50 212
SVC 8 211
SVC 9 211
treated as NOPs 212,213
USE-SVC 63 212
WAIT-SVC 7 211
SVC functions not supported 213
SVC handling 195
CMSDOS-CMSVSAM-user program storage
relationships 195
CMS/VSAM error return processing 197
CMSVSAM-CMSDOS-user program storage
relationships 195
codes
for DIAGNOSE instruction 58
wait state 27
coding conventions
CP 589
VM/310 589
command
handling, CMS 163
processing
eMS
121
SET DOS ON 163
SET SYSNAME 163
commands
CP processing 230
Index
647
entered from the terminal 125
file system manipulation 177
passed via DMSINS, execution of 164
process of, entered during CMS 164
RSCS 140
spool files 97
management 99
spooling
real 98
virtual 98
commands for debugging
ADSTOP 480
BEGIN 482
DISPLAY 483
DUMP 489
SET 492
STORE 499
SYSTEM 502
TRACE 503
commands for system programmers and
analysts
debugging 508
DCP 509
DMCP 511
LOCATE 513
MONITOR 514
QUERY 515
STCP 528
comparison, of CP and CMS debugging
facilities 33
completion processing
DOS VSAM programs 198
OS VSAM programs . 198
component states, I/O 69
console
management, CMS 163
scheduling 222
simulation, virtual 219
console functions 88
CP 48
CP processing 230
CONTASK data, processing of 222
CONTASK interrupt, control, processing of
222
control block
CMS 42
I/O, real 66
manipulation macros, simulation of, VSAM
197
real 37
RCHBLOK 39
RCUBLOK 39
RDEVBLOK 39
virtual 37
VCHBLOK 37
VCUBLOK 38
VDEVBLOK 38
VMBLOK 37
control card routine 174
ENTRY card 174
LIBRARY card 174
control CONTASK interrupt, processing of
222
control flow for I/O processing 183
Control Program
(§~ CP (Control Program»
control program, RSCS 141
648
control register
usage 55
used by MCH 102
control statements, DDR 530
controlling
multiprogramming 91
virtual Machine Assist 49
conventions
linkage 165
SVCs 165
pageable CP modules 55
Conversational Monitor system
(2~~ CftS
(Conversational Monitor System»
CP (Control Program)
ABEND 12
procedure when occurs 12
reason for 12,35
ABEND codes 542
ABEND dump
printing from tape 35
reading 35
annotated flow diagram, use of 216
coding conventions 589
command module entry points 230
command processing 230
commands for system programmers and
analysts, debugging 508
console functions 48,88
processing 230
control blocks
RCHBLOK 39
RCUBLOK 39
RDEVBLOK 39
real 37
VCHBLOK 37
VCUBLOK 38
VDEVBLOK 38
virtual 37
VMBLOK 37
debugging
collect informaiton 36
comparison with eMS facilities 33
on a virtual machine 34
register usage 36
save area conventions 36
debugging commands 479
ADSTOP 480
BEGIN 482
DISPLAY 483
DUMP 489
SET 492
STORE 499
SYSTEM 502
TRACE 503
debugging commands for system
programmers and analysts
DCP 509
DMCP 511
LOCATE 513
MONITOR 514
QUERY 515
STCP 528
disabled loop 24
equate symbols 591
handling of saved systems 190
BIO operations 221
initialization 45,85
procedures 228
IBM VM/370: System Logic and Problem Determination Guide
internal trace table 477
interrupts
handling 52
processing 216
introduction 45
I/O operations, scheduling of 221
I/O scheduling for CP and the virtual
machine 218
label to module cross reference 373
loadlist requirements 590
module entry point directory 321
module to label cross reference 341
pageable module, identifying 39
program organization 216
program states 48
request stack 93
SIO operations 221
spooling 47,93,232
remote 48
termination 85
procedures 228
without a dump 16
trace table entries 478
undiagnosed machine check 16
unexpected results 23
unrecoverable machine check 16
virtual
interrupt processing 218
I/O operations 218
virtual machine
I/O management 47
management 46
preferred environment 48
storage management 46
time management 46
wait state
codes 540
disabled 25
enabled 26
CP commands
ADSTOP 480
BEGIN 482
DCP 509
DISPLAY 483
DMCP 511
DUMP 489
LOCATE 513
MONITOR 514
QUERY 515
SET 34,.492
STCP 528
STORE 499
SYSTEM 502
TRACE 503
CPU (Central Processing Unit), System/370,.
retry 101
cross reference
label to module
CMS 281
CP 373
RSCS 469
message-to-label, RSCS 563
module to label
CMS 265
CP 341
RSCS 465
CTCA operations between virtual machines
218
D
DASD (Direct Access storage Device)
error recovery 108
errors, during spooling 99
I/O initiated via DIAGNOSE 219
record formats 603
space
allocation of 94,.226
de-allocation of 226
exhausted for spool files 100
st~rage management
80
cylinder allocation 81
slot allocation 80
DASD Dump/Restore (DDR) Program 530
control statements 530
function control statements 532
invoking
standalone 530
under CMS 530
I/O definition statements 531
TYPE and PRINT functions,. sample output
539
data area modules 55
data. areas
RSCS 147
VM/370,. referenced by RSCS 148
data base, loader 175
data formats
for bisync lines 75
for remote 3270 75
DDR program
(§gg DASD Dump/Restore (DDR)
program)
de-allocation of DASD space 226
DEBUG command, usage 17
debugging
aids 477
approach to 11
CMS
collect information 41
register usage 43
comparison of CP and CMS facilities 33
CP
collect information 36
on a virtual machine 34
register usage 36
save area conventions 36
introduction 11
procedures
ABEND 15
loops 14
unexpected results 15
wait states 14
software problem 11
tools, summary of 29
with CMS 568
debugging commands
CP 479
for system programmers and analy~ts 508
DCP 509
DMCP 511
LOCATE 513
MONITOR 514
QUERY 515
STCP 528
dedicated channel, support 72
defining,. a virtual device 87
detaching, a virtual device 87
Index
649
device
real
attaching 87
spooling commands 98
virtual
defining 87
detaching 87
spooling commands 98
DIAGNOSE
codes 58
FINDSYS function 65
instruction format 58
instructions, issued by RSCS 141
interface 58
LOADSYS function 64
PURGESYS function 64
DIAGNOSE instruction
function codes for 622
starting a general I/O operation 219
used to start standard DASD I/O 219
diagnostic aids 477
direct access storage device
(§~~ DASD
(Direct Access Storage Device»
directories 245
directory routines, user 236
disconnecting
a terminal 87
permanently 87
temporarily 87
a virtual machine 87
permanently 87
temporarily 87
disk
and file storage management 182
I/O, CMS 185
organization in CMS 178
disk storage management
CMS 180
QMSK used in 180
QQMSK used in 180
dispatch entry point 231
dispatched user, reflection for 231
dispatching 231
a new virtual machine 232
states, user 90
support routines 92
virtual machines 88
examples 89
dispatching lists, virtual machine 89
DISPLAY command 483
DISPW macro, format 129
I:MKFREE
calling for a large block 85
calling for a sub pool 84
DMKFRET
calling for a large block 85
calling for a subpool 85
DMSACC module 203,204
used for access 182
DMSACF module 204
DMSACM module 204
DMSALU module 204
DMSAMS, operation of 194
DMSAMS-CMSAMS-CMSYSAM, storage
relationships
194
DMSARE module 203,204
DMSASN module 207,208
DMSBOP module 195,209
650
DMSBOP YSAM processing 195
DMSETB module 213
DMSBTP module 213
DMSCLS module 195,210
DMSCLS YSAM processing 195
DMSDLB module 207,208
DMSDLK module 210
DMSDOS module 195
DMSDOS VSAM processing 195
DMSEXS macro 190,192
DMSFCH module 210
DMSFET module 210
DMSFLD module 203,204
DMSFRE module
method of operation 187
used in free storage management 185
DMSFRE service routine 188
CALOC option of 189
CHECK option of 189
CKOFF option of 189
CKON option of 189
INITl option of 188
INIT2 option of 189
UREC option of 189
DMSFREE
allocated storage 188
error codes 191
free storage allocation 185
free storage management 118
free storage pointers 186
request efficiency 188
service routines 122
DMSFRES macro 122
DMSFREE macro
error codes 123
format 118
DMSFRES, error codes 191,558
DMSFRES macro 191
error codes 123
format 122
DMSFRET
error codes 191,558
releasing free storage 121
DMSFRET macro
error codes 123
format 121
DMSFREX error codes 558
DMSINS module, executing commands
164
.DMSINT module 164
DMSITS module 165
DMSKCP VSAM processing 195
DMSKEY macro 190,192
DMSLDR module 175
DMSLDS module 203,204
DMSLFS module 205
DMSLLU module 207,208
DMSMVE module 203,205
DMSOPT module 207,208
DMSPIO, carriage control characters 184
DMSPIO module 184
DMSQRY module 203,206
DMSROS module 205,207
DMSSCT module 206
DMSSEB nodule 206
DMSSET module 207
DMSSOP module 206
DMSSTT module 204,207
DMSSYT module 206
IBM VM/370: System Logic and Problem Determination Guide
DMSVIP module 196
DMSXCP module 195
DOS
CLOSE functions 209
environment simulation under CMS 207
initialization 207
assign logical and physical units
208
associate a DTF table filename with a
logical unit 209
data areas 207
for OS VSAM processing 196
list assignments of CMS/DOS logical
units 208
reseting compiler options 208
resetting DOS environment options
208
setting compiler options 208
setting DOS environment options 207
OPEN functions 209
simulation by CMS
handling files that reside on DOS
disks 130
read DOS files using OS macros 136
SVC calls 166
system control commands, processing of
207
use of CMS ACCESS command 136
use of CMS FILEDEF command 136
VSAM
functions supported by CMS 138
hardward devices supported by CMS
138
DOS commands 207
DOS emulator, interaction with virtual
Machine Assist feature 50
DOS VSAM
completion processing 198
execution of, for a DOS user 194
DOSCB 209
DOSCB chain, creation of 193
DOS-OS-VSAM-user program storage
relationships 196
DOS/VS
FETCH function 210
Linkage Editor, simulation of 210
support, under CMS 137
DTF tables, opening files associated with
209
DTFs, closing files associated with 210
DUMP
operand of CP SET command 34
subcommand of DEBUG 41
DUMP command 489
dump the system 229
dumps
ABEND 34
CMS ABEND, reading 41
CP ABEND
printing from tape 35
reading 35
printing 34
dynamic storage management, active disk and
file 182
E
ECC, validity checking 101
END card routine 174
operation 174
enhancements, miscellaneous, with VM/VS
Handshaking feature 51
ENTBY control card 174
entry point directory
CMS 247
CP 321
BSCS 455
entry points for CP commands 230
environments
non-CMS 192
access method support for 193
equate symbols
CM~
599
CP 591
RSCS 591
ERET error routine processing 198
ERP (error recording program)
105
error codes
DMSFREE macro 123
DMSFRES 558
DMSFRES macro 123
DMSFRET 558
DMSFRET macro 123
DMSFREX 558
from DMSFREE 191
from DMSFRES 191
from DMSFRET 191
error recording 107
record writing 107
via SVC 76 235
virtual machine, interface 107
error recording base, establishing 234
error recovery 107
DASD 108
hard 82
soft 82
spool files 99
tape 109
virtual storage paging 82
3270 binary synchronous line 224
3270 remote support 110
error return, CMS/VSAM, processing of 197
error routine, ERET, processing of 198
errors, DASD, during spooling 99
ESD card codes 175
ESD type 0 card routine 170
operation 170
ESD type 1 card routine 170
operation 170
ESD type 10 routine 172
ESD type 2 card routine 171
operation 171
ESD type 3 card routine 171
operation 171
ESD type 5 card routine 171
operation 171
ESD type 6 card routine 171
operation 171
ESDID (ESD ID table) entry 176
examples, of virtual machine dispatching
and scheduling 89
executable modules
pageable 55
resident 55
Index
651
executing
CMS files 163
text files 168
the pageable control program 54
execution
favored 48,92
of scheduled users 232
exit routine, user, processing of 198
extended virtual external interrupt 51
external interrupt 53,51
reflection 211
F
facilities
VM/370
real timing 65
timing 65
virtual timing 66
failure, system, recovery 100
favored execution option 48,92
features
system/370 recovery 101
control registers used by MCH 102
CPU retry 101
ICC validity checking 101
Virtual Machine Assist 49
VM/VS Handshaking 50
file status table (FST)
CMS 178
format 178
file status table block, format 178
file status tables, CMS 177
file system
CMS 111,113
management 177
manipulation commands 171
FILEDEF command 136
AUXPROC option 137
FILEDEF command flow 203
FINDSYS function 65
return codes 65
first chain link format 179
first command processing, CMS 162
format
CCW, 3270 remote 73
DIAGNOSE instruction 58
first chain link 179
macro
DISPW 129
tMSFREE 118
DMSFRES 122
DMSFRET 121
STRINIT 116
spool data 93
spool files 93
system save area 168
user save area 168
free chain element format 187
free storage
allocating
nucleus 121
user space 120
allocation
185
management 84,185,221
eMS 116,185
DMSFREE 118
652
GETMAIN 116
pointers 185
nucleus, allocation of 188
page frame allocation 85
pointers, DMSFREE 186
releasing 121
DMSFRET 121
user, allocation of 187
free storage table
FREETAB 186
NUCCODE 186
SYSCODE 186
TRNCODE 186
USARCODE 186
USERCODE 186
PREETAB free storage table 186
function codes for DIAGNOSE instructions
622
function control statements, DDR 532
functional area, overview, CMS 155
functions, console, CP 48
G
GENCB processing 191
GETMAIB
allocated storage 188
free storage
allocation 185
management 116
management pointers 185
graphic I/O processing, local 220
H
handling
CMS
PSW keys 124
SVC 124
interrupts 52,55
CMS 112
overview 53
link activity, RSCS 153
OS files
that reside on CMS disks 130
that reside on os or DOS disks
hard error, recovery 82
high-core nucleus chain 186
high-core user chain 186
HIO operations, CP 221
130
I
ICS card routine 169
operation 169
identifying, a pageable module 39
information, functional, CMS 115
initialization
eMS virtual machine 160
CMS/DOS, for OS VSAM processing
CP 45,85
procedures 228
DMSIBS module 160
DOS 207
for OS SVC handling, eMS 162
of a named system 162
of a saved system 162
IBM VM/370: System Logic and Problem Determination Guide
196
storage constant, CMS 160
system 85,228
for RMS 100
system table, CMS 160
virtual machine 229
input
processing
for a virtual machine 233
real spool files 97
virtual spool files 95
input device, real, spooling to 234
input files, virtual machine, closing of
233
input restrictions, loader 177
input/output control flow 183
input/output operations 182
instruction simulation for virtual machine
219
interactive console environment, CMS 163
Interactive Problem Control System
(§~~
IPCS (Interactive Problem Control System»
interface
DIAGNOSE 58
error recording, virtual machines 107
internal trace table 477
interrupt
channel check, processing of 235
handling, RSCS 142
in CMS
external 115
handling 112
I/O 114
machine check 115
program 114
SVC 112
I/O 70
virtual 70
machine check, processing of 235
reflection in a virtual machine 219
secondary, processor for 3270 224
start/stop terminal, processing of 222
3704/3705, handling of 223
interrupt processing 221
local graphic 220
MONITOR 217
program 217
interrupt reflection
clock 217
external 217
interrupts
external 53,57
extended virtual 57
handling 52,55
overview 53
I/O 52
machine check 52
processing 184,216
program 52,57
SVC 53,55
timer 57
introduction
CMS 111,160
debugging 11
RSCS 138
to CP 45
invalid SVC calls 125
I/O
component states 69
control blocks, real 66
disk, CMS 185
for DASD 219
general operation, initiated via
DIAGNOSE 219
instruction simulation, for virtual
machine 219
interrupts 52,70
virtual 70
macros, OS VSAM, simulation of 197
management 66
RSCS 142
paging 81
privileged instructions, other 68
processing, local graphic 220
programs
for bisync lines 74
for remote 3270 74
reconfiguration 86
requests
scheduling 71
virtual 67
virtual selector channel 68
RSCS
active and pending queues 153
methods and techniques 152
queues and subqueues 153
scheduler, paging 227
scheduling for CP and the virtual
machine 218
supervisor 66
3270, request handler 224
I/O definition statements, DDR 531
IPL command processing, CMS 160
IPL of the virtual machine 229
ISAM read sequence
locate an 220
validate 220
K
key
real PSi 190
real storage 190
virtual PSi 190
virtual storage 190
keys, storage protection
189
L
label to module cross reference
CMS 281
CP 373
RSCS 469
language, CMS command 111
LIBRARY control card 174
line driver programs
NPT 146
SML 144
linkage conventions 165
SVCs 165
links
RSCS
handling by 153
handling files 153
transmitting VM/370 files to
153
Index
653
LISTDS command flow 203
load map
CMS 43
sample of 44
nucleus 43
loader
CMS 168
data base 175
input restrictions 177
loading
CMS, from card reader 160
from card reader, CMS 160
t ext files
168
the nucleus 228
load list requirements, CP 590
LOADSYS function 64
return codes 64
local graphic
interrupt processing 220
I/O processing 220
locate ISAM read sequence 220
lock a page of free storage 225
loops 11,23
debugging procedures 14
disabled
CP 24
virtual machine 24
enabled, virtual machine 24
low-core nucleus chain 186
low-core user chain 186
M
machine check
interrupt 52
processing of 235
undiagnosed 16
unrecoverable 16
machine check handler
(§gg MCH (machine
check handler»
machine states, virtual machine 89
macro
format
DISPW 129
DMSFREE 118
DMSFRES 122
DMSFRET 121
STRINIT 116
macro processing
I/O
ENDREQ 197
ERASE 197
GET 197
POINT 197
PUT 197
macros
control block manipulation, VSAM 197
GENCB 197
MODCB 197
SHOWCB 197
TESTCB 197
maintaining interactive session, CMS 163
maintenance, virtual timer 65
management
allocation 76
commands, for spool files 99
free storage 53,84,227
CMS 116
654
I/O
66
RSCS 142
of pages 225
OS data, simulation by eMS 130
real spooling 96
real storage 94
storage
DASD 80
real 77
virtual 77
task, Rses 141
virtual machine 46
I/O 47
storage 46
time 46
virtual spooling 94
virtual storage 94
RSeS 142
master file directory
CMS 180
structure 181
MCH (machine check handler)
100
control registers 102
overview 101
recovery
functional 101
system 101
system repair 101
system-supported restart 101
subroutines 102
buffer error 104
initial analysis 102
main storage analysis 103
operator communication 103
recovery facility mode switching 103
soft recording 104
storage protect feature (SPF)
analysis 103
termination 105
virtual user termination 104
m~ssages, ABEND
19
message-to-Iabel cross reference, RSCS 563
miscellaneous eMS functions 213
MODCB processing 197
mode, VSl nonpaging 51
modifications, by called routine to system
area 128
MODMAP command 43
module directory, RSCS 447
module entry point directory
CMS 247
CP 321
RSCS 455
module entry points for CP commands 230
module to label cross reference
CMS 265
CP 341
Rses 465
modules
data area 55
executable
pageable 55
resident 55
pageable
conventions 55
identifying 40
restrictions 55
system support 55
IBM VM/370: System Logic and Problem Determination Guide
MONITOR interrupt processing 217
MOVEFILE command flow 203
multiprogramming, controlling 91
multitasking supervisor, program
organization of 239
N
named system initialization 162
network, control, RSCS 140
non-CMS operating environments 192
NPT line driver program 146
routines
function selector 146
I/O processing 146
line monitor 146
NPT line driver task, program organization
243
Nth chain link, format
179
nucleus
free storage
allocation 121,188
loading of 228
storage copy of 160
nucleus constant (NUCON) areas 41
nucleus load map 43
o
obtain a page of free storage 225
OPEN, OS VSAM, simulation of 196
operating environments
non-CMS 192
access method support for 193
operating' system, abnormal termination
(ABEND)
18
operation
of DMSINT 164
of DMSITS 165
options
performance
favored execution 48,92
reserved page frames 49
virtual=real 49,80
virtual Machine Assist 49
order seek queuing 71
organization, virtual disk 180
OS
CMS simulation, data management 130
control block functions, CMS simulation
of 198
macro simulation, under CMS 130
simulation by CMS
access method support 134
handling files that reside on CMS
disks 130
handling files that reside on OS
disks 130
notes 131
reading OS data sets using OS macros
136
supervisor calls 131
use of CMS ACCESS command 136
use of ~MS FILEDEF command 136
VSAM
functions supported by CMS 138
hardware devices supported by CMS
138
OS ACCESS, flow of commands used in 203
OS access method modules
DMSACC 204
DMSACF 204
DMSACM 204
DMSALU 204
DMSARE 204
DMSFLD 204
CONCAT 204
DSB 204
MEMBER 204
DMSLDS 204
DMSLFS 205
DMSMVE 205
DMSQRY 206
DISK routine 206
SEARCH routine 206
DMSROS 205
CHKXTNT routine 207
CHRCNVRT routine 207
common routines 207
DISKIO routine 207
GETALT routine 207
RDCNT routine 207
ROSACC routine 205
ROSFIND routine 205
ROSNTPTH routine 206
ROSPRS routine 205
ROSSTRET routine 205
ROSSTT routine 205
SETXTBT routine 207
SHKSENSE routine 207
DMSSCT 206
CKCONCAT routine 206
FIND (Type C) routine 206
NOTE routine 206
POINT routine 206
DMSSEB 206
EOBROUTN routine 206
OSREAD routine 206
DMSSOP 206
DMSSTT 207
DMSSVT 206
BLDL routine 206
BSP routine 206
FIND (Type D) routine 206
OS access method support 193
OS and DOS/VS macro simulation of SVC calls
125
OS functions
CMS module used for 199
defined 199
simulated by CMS 199
SVC numbers of 199
OS ISAM, handling by DMKISMTR 69
OS macro simulation SVC calls 166
OS simulation by CMS 198
OS simulation routines 199
ABEND-SVC 13 200
ATTACH-SVC 42 201
BACKSPACE-SVC 69 202
BLDL/FIBD(Type D)-SVC 18 201
CHAP-SVC 44 201
CHECK 203
CHKPT-SVC 63 202
CLOSE/TCLOSE-SVC 20/23 201
Index
655
DELETE-SVC 9 200
DEQ-SVC 48 202
DETACH-SVC 62 202
DEVTYPE-SVC 24 201
ENQ-SVC 56 202
EXIT-SVC 3 200
EXTRACT-SVC 40 201
FREEDBUF-SVC 57 202
FREEMAIN-SVC 5 200
GETMAIN/FREEMAIN-SVC 10 200
GETMAIN-SVC 4 200
GETPOOL 200
GET/PUT-SVC 96 202
IDENTIFY-SVC 41 201
LINK-SVC 6 200
LOAD-SVC 8 200
NOTE/POINT/FIND(Type C)
203
notes on 203
OPEN/OPENJ-SVC 19/22 201
POST-SVC 2 200
RDJFCB-SVC 64 202
READ/WRITE 202
SNAP-SVC 51 202
SPIE-SVC 14 201
STAE-SVC 60 202
-STAX-SVC 96 202
STIMER-SVC 47 201
STOW-SVC 21 201
SYNAD-SVC 68 202
TCLEARQ-SVC 94 202
TGET/TPUT-SVC 93 202
TIME-SVC 11 200
TRKBAL-SVC 25 201
TTIMER-SVC 46 201
used by Assembler 199
used by FORTRAN 199
used by PL/I 199
WAIT-SVC 1 200
WTO/WTOR-SVC 35 201
XCTL-SVC 7 200
XDAP-SVC 0 200
OS SVC handling, initialization for, CMS
162
as VSAM
CHECK processing 197
CLOSE, simulation of 197
execution, user 196
I/O macros, simulation of 197
OPEN, simualtion of 196
program completion processing 198
OS-DOS-VSAM-user program storage
relationships 196
output
processing
real spool files 96
virtual spool files 95
output files, virtual machine, closing of
233
output lines, SVCTRACE, summary of 586
overview
CCH 105
CMS, functional areas 155
MCH 101
RSCS 138
656
P
page
frames, reserved 49
management 225
of free storage
lock 225
obtain 225
return 225
unlock 225
reading from virtual storage 225
request, processing of 225
writing to virtual storage 225
page faults, pseudo, with VM/VS Handshaking
feature 51
page frame, allocation, free storage 85
pageable
control program, executing 54
CP modules
conventions 55
restrictions 55
executable modules 55
pages, virtual storage, releasing 227
paging
I/O 81
I/O scheduler 227
requests 76
virtual storage, error recovery 82
patch control block (PCB)
176
performance
options
favored execution 48,92
reserved page frames 49
virtual=real 49,80
virtual Machine Assist 49
pointers, free storage management 185
preferred virtual machine 48
printer, real, spooling to 233
printing a file, CMS 184
privileged instruction
I/O, other 68
program interrupt 57
problem
analyzing 12
determining if one exists 13
problem state, SVC interrupts 216
problem types
ABEND 11,21
loop 11,23
disabled, CP 24
disabled, virtual machine 24
enabled 24
unexpected results 11,23
CP 23
wait state 11,24
disabled, CP 25
disabled, RSCS virtual machine 27
disabled, virtual machine 26
enabled, CP 26
enabled, RSCS virtual machine 28
enabled, virtual machine 26
processing
accounting cards 97
CMS files 163
commands entered during eMS session 164
DOS system control commands 207
interrupts 184
RSCS, files from remote stations 153
IBM VM/370: System Logic and Problem Determination Guide
spool files
real input 97
real output 96
virtual output 95
virtual input 233
virtual output 232
program
areas, user and transient 126
development, CMS 112
organization, CMS 155
program areas
transient 167
user 167
Program Event Recording (PER), interaction
with virtual Machine Assist feature 50
program interrupt 52,57
privileged instruction 57
processing 217
program organization
RSCS 238
RSCS overview 238
program states, CP 48
programming, remote 3270 73
protection, storage 54
PRSERCH routine 175
operation 175
PSR
(2~~ IBM Program Systems
Representative (PSR»
PSi
fields, when called routine starts 128
validation 231
PSi keys
CMS handling of 190
handling by CMS 124
PTFs, applying 631
punch, real, spooling to 233
punching a card, CMS 183
PURGBSYS function 64
return codes 65
Q
QMSK data block 181
QUERY command flow 203
querying options in the virtual machine
environment 163
queuing, order seek 71
R
reading
a card, CMS 183
a DASD page from virtual storage
real
device
attaching 87
spooling commands 98
input devi~e, spooling to 234
PSi key 190
storage key 190
real spooling manager (DMKRSP)
96
real storage
allocation 225
management 77,94
page management 225
requests for page frames 78
225
reconfiguration, I/O 86
record, error, writing 107
record formats
CMS 178
DASD 603
recovery
from system failure 100
MCH
functional 101
system 101
system repair 101
system-supported restart 101
System/370 101
control registers used by MCH 102
CPU retry 101
BCC validity checking 101
Recovery Management Support
(§gg RMS
(Recovery Management Support»
REFADR routine 175
operation 175
reflection for the dispatched user 231
REFTBL
address field
176
entry 176
flagl byte 176
flag2 byte 176
info field 1'76
name field 176
value field 176
register
contents when called routine starts
128,167
restoration by called routine 128,168
usage, CMS 115
RELEASE command flow 203
releasing
allocated storage 188
free storage 121
storage 188
virtual storage pages 227
relocation, virtual 82
remote
stations, RSCS processing of files from
153
3270
CCW format 73
data formats 75
I/O programs for 74
support error recovery 110
3270 programming 73
Remote Spooling Communications Subsystem
(§~~ RSCS (Remote spooling Communications
Su1:system) )
REP card routine 172
operation 172
request handler, 3270 I/O 224
request stack, CP 93
requests
for real storage page frames 78
I/O
scheduling 71
virtual 67
paging 76
RSCS 147
requirements, RSCS storage 149
reserved, page frames 49
resident, executable modules 55
restart, MCH, system-supported 101
Index
657
restrictions
input, loader 177
on CMS as a saved system 191
pageable CP modules 55
Virtual Machine Assist feature 50
VM/370 613
return a page of free storage 225
return codes
CMS 557
FINDSYS function 65
LOADSYS function 64
PURGESYS function 65
return location, when returning to caller
168
returning
to caller 167
register restoration
168
return location 168
to the called routine 126
REX system service tasks, program
organization 240
RLD card routine 173
operation
173
RMS (Recovery Management Support)
100,234
channel check handler (CCH)
100
machine check handler (MCH)
100
system initialization 100
RSCS (Remote Spooling Communications
su bsystem)
AXS system service task, program
organization 241
control program 141
data areas 147
VM/370 148
DIAGNOSE instructions 141
equate symbols 591
interrupt handling 142
introduction 138
I/O
active and pending queues 153
method and techniques 152
queues and subqueues 153
label to module cross reference 469
links
handling 153
handling files 153
transmitting VM/370 files to 153
management
I/O 142
task 141
virtual storage 142
message-to-Iabel cross reference 563
module directory 447
module entry point directory 455
module to label cross reference 465
multitasking supervisor, program
organization of 239
network control 140
commands
140
CP and CMS commands used 140
CP instructions used 141
NPT line driver program 146
function selector routine 146
I/O processing routines 146
line monitor routine 146
NPT line driver task, program
organization 243
overview 138
658
processing files from remote stations
153
program organization 238
overview 238
request elements 141
REX system service tasks, program
organization 240
SML line driver program 144
buffer routines 145
function selector routine 145
I/O handler routine 145
processors 145
SML line driver task, program
organization 242
spooling, remote 48
storage requirements 149
supervisor 141
TAG file descriptor 147
task structure 142
tasks 143
ALERT task-to-task communication 150
asynchronous interrupts and exits
150
asynchronously requested services
150
dispatching 149,150
GIVE/TAKE task-to-task communication
151
posting a synch lock 150
synchronization locks 149
synchronizing 149
wait/post routines 149
virtual machine
configuration 139
locations and links 139,
nonprogrammable remote stations 139
programmable remote stations 139
remote stations 139
wait state
disabled 27
enabled 28
RSCS commands 140
S
saved system
effect on CMS as a 191
handling of, CP 190
initialization 162
restrictions on C~S as a 191
saving the 3704/3705 control program image
236
scheduler
functions, other 232
I/O paging 227
scheduling 231
CP I/O operations 221
interrupt handling 221
I/O for CP and the virtual machine 218
I/O requests 71
support routines 92
the console 222
users for execution 232
virtual machine I/O operations 221
virtual machines 88
examples 89
selector channel, virtual, I/O requests 68
service program, ZAP, CMS 623
IBM VM/370: System Logic and problem Determination Guide
service routines
DMSFRE 188
DMSFREE 122
TSO, support of 198
SET command (CP)
492
usage 34
SET DOS ON command processing, VSAM 163
SET SYSNAME command processing 163
setting options in the virtual machine
environment 163
shared segment storage management 226
SHOWCB processing 191
shutdown, normal 228
simulation
CMS, OS data management 130
of as by CMS 198
OS macro, under CMS 130
virtual console 12
control routine 12
invalid operation 12
read routine 12
sense operation 12
TIC operation 12
write routine 12
simulation routines, OS
(~gg OS simulation
rou tines)
SIO
operations, CP 221
virtual 61
SLC card routine 169
operation 169
SML line driver program 144
routines
buffer blocking and deblocking 145
function selector 145
I/O handler 145
processors 145
SML line driver task, program organization
242
soft error, recovery 82
software problem, debugging 11
space, allocation, DASD 94
spool data, format 93
spool files
attributes 91
checkpoint 236
initialization 236
commands 91
CP, closing with VM/VS Handshaking
feature 51
DASD, space exhausted 100
deletion of 234
error recovery 99
format 93
management, commands 99
real
input processing 91
output processing 96
recovery 236
recovery of closed checkpointed 231
virtual
input processing 95
output proces~ing 95
spooling 232
commands
for real device 98
for virtual device 98
CP
41,93
remote 48
DASD errors 99
real, management 96
remote, via RSCS 48
to the real input device 234
to the real printer 233
to the real punch 233
virtual, management 94
virtual console 95
virtual device to real device 232
start/stop terminals, interrupt processing
222
start-up table, called routine 161
STATE command flow 204
status, changes, user 91
status tables, file, CMS 111
storage
allocated by DMSFREE 188
allocated by GETMAIN 188
allocation 225
constant initialization, CMS 160
free
allocation 185
management of 53
map
CMS 111,161
organization of CMS files 111
protection 54
protection keys 189
releasing of 188
RSCS, requirements 149
structure in CMS 116
storage management
free 221
shared segment 226
temporary disk 226
storage relationships, DOS-OS-VSAM-user
program 196
STORE command 499
STRINIT macro, format 116
structure, CMS storage 116
subpool
calling DMKFREE for 84
calling DMKFRET for 85
subroutines
CCH
channel control 105
channel error analysis 106
MCH 102
buffer error 104
initial analysis 102
main storage analysis 103
operator communication 103
recovery facility mode switching 103
soft recording 104
storage protect feature (SPF)
analysis 103
termination 105
virtual user termination 104
summary of, VM/310 debugging tools 29
supervisor
I/O 66
RSCS 141
supervisor state, SVC interrupts,
processing of 216
support, dedicated channel 12
support plan, system 638
Index
659
support routines
dispatching 92
scheduling 92
SVC
CALLS
(2~~ SVC CALLS)
handling by CMS 124
handling for CMS/DOS 195
interrupt 53,55
problem state 216
supervisor state, processing of 216
linkage conventions 124
types 124,165
user handled 125,166
201
165
202 124,165
203 124,166
SVC calls
DOS 166
invalid
125,166
OS and DOS/VS simulation 125
OS macro simulation 166
SVC 201 165
svc 202 165
execute commands entered from the
terminal 125
search hierarchy for 125,166
SVC 203 166
SVC 76 error recording 235
SVCTRACE output lines, summary of 586
system
dump of 229
failure, recovery 100
file, management 177
functions; CMS 156
initialation 85,228
for RMS 100
save area format
168
start, warm 228
table initialition, CMS 160
termination 85
virtual machine, attaching to 229
SYSTEM command 502
system support modules 55
system support plan 638
System/370
recovery 101
control registers used by MCH 102
CPU retry 101
ECC validity checking 101
GIVE/TAKE task-to-task communcation
151
posting a synch lock 150
synchronation locks 149
synchroning 149
using asynchronously requested
services 150
wait/post routines 149
temporary disk storage management 226
terminals
disconnecting 87
permanently 87
temporarily 87
display, CMS interface 129
I/O control
disabling 222
enabling 222
termination
abnormal
(~~~ abnormal termination
(ABEND) )
CP 85
without a dump 16
of the virtual machine 229
procedures, CP 228
system 85
virtual machine 229
TESTCB processing 197
text files
168
executing 168
loading 168
thrashing, VPK of 0 191
timer
interrupt 57
virtual, maintenance 65
timing
facilities 65
real 65
virtual 66
TRACE command 503
trace table entries, CP 478
transient program areas 126,167
TSO service routine, support of 198
TXT card routine 172
operation 172
TYPE and PRINT function, DDR, sample output
539
U
T
table, start-up, called routine 167
table entry
ESDID 176
REPTBL 176
TAG, RSCS file descriptor 147
tape, error recovery 109
task management, RSCS 141
task structure, RSCS 142
tasks
RSCS 143
ALERT task-to-task communications
150
asynchronous interrupts and exits
150
dispatching 149,150
660
unexpected results 11,23
CP 23
debugging procedures 15
virtual machine 23
unlock a page of freee storage 225
update procedures, VM/370 631
updating modules with the VMPASM EXEC
procedure 638
usage, control register 55
user
directory routines 236
dispatching states 90
exit routine processing 198
free storage
allocating 120
allocation of 187
handled SVCs 166
program areas 126,161
IEM VM/370: System Logic and Problem Determination Guide
save area format 168
status changes 91
user program-CMSDOS-CMSVSAM storage
relationships 195
user program-VSAM-DOS-OS storage
relationships 196
V
validate ISAM read sequence 220
validation of the PSW 231
virtual
channel-to-channel adapter 68
device
defining 87
detaching 87
spooling commands 98
devices used in CMS 619
disk
accessing 182,
organization 180
physical organization 180
I/O interrupts 70
I/O requests 67
output files, closing of 233
PSi key 190
relocation 82
selector channel I/O requests 68
SIO 67
virtual=real option 49,80
virtual console
simulation 72,219
control routine 72
invalid operation 72
read routine 72
sense operation 72
TIC operation 72
write routine 72
spooling 95
virtual machine
abnormal termination (ABEND)
18
attaching to the system 85,229
debugging, CP 34
debugging commands, CP 479
disabled loop 24
disconnecting 87
permanently 87
temporarily 87
dispatching 88
example of 89
dispatching lists 89
enabled loop 24
environment
querying options 163
setting options 163
error recording, via SVC 76 235
error recording interface 107
initialition 229
CMS 160
input files, closing of 233
input processing 233
interrupt reflection 219
I/O, scheduling by CP 218
I/O instruction simulation 219
I/O operations, scheduling of 221
IPL of 229
machine states 89
management 46
I/O 47
storage 46
time 46
new, dispatching of 232
output processing 232
preferred 48
BSCS
configuration 139
locations and links 139
nonprogrammable remote stations 139
programmable remote stations 139
remote stations 139
scheduling 88
example of 89
termination 229
termination of 229
unexpected results 23
wait state, disabled 26
virtual Machine Assist feature 49
control 49
interaction
with DOS emulator 50
with Program Event Recording (PER)
50
restrictions 50
virtual Machine Facility/370 (VM/370)
coding conventions 589
CP and CMS commands used to control RSCS
network functions 140
CP instructions used to control RSCS
network functions 141
data areas, referenced by RSCS
148
debugging
introduction 11
software problem 11
summary of tools 29
restrictions 613
system, supporting a 631
timing facilities 65
real 65
virtual 66
transmitting files to an RSCS link 153
update procedures 631
virtual spooling manager (DMKVSP)
94
virtual storage
key' 190
management 77,94
EC mode 226
non-EC mode 225
RSCS 142
paging, error recovery 82
releasing pages 227
VMFASM EXEC procedure
other files produced by 644
updating modules with 638
using to apply updates 638
VMFDUMP command
format 34
usage 34
VM/VS Handshaking feature 50
closing CP spool files 51
miscellaneous enhancements 51
pseudo page faults 51
VM/370
(2~~ Virtual Machine Facility/370
(VM/370) )
VPK of 0 caused overhead 191
VSAM
CLOSE, OS, simulation of 197
Index
661
CMS support of 193
control block manipulation macros,
simulation of 197
execution for os user 196
execution of, for a DOS user 194
OPEN, OS, simulation of 196
processing, DMSDOS 195
SET DOS ON command processing 163
VSAM-DOS-OS-user program storage
relationships 196
VS1 nonpaging mode 51
Z
ZAP service program, CMS
3
3270
binary synchronous line error recovery
224
remote
CCW format 73
data formats 75
I/O programs for 74
programming 73
support error recovery 110
secondary interrupt processor 224
3277
remote, enabling/disabling of 224
remote station
binary synchronous line
enabling/disabling 224
enabling/disabling 224
3704/3705, saving the control program image
236
3705/3704, interrupt handling 223
Ii
wait state 11,24
codes 27
CP 540
debugging procedures 14
disabled
CP 25
RSCS virtual machine 27
virtual machine 26
enabled
CP 26
RSCS virtual machine 28
virtual machine 26
warm start 228
writing a DASD page to virtual storage
662
623
225
IBM VM/370: System Logic and Problem Determination Guide
READER'S
COMMENT
FORM
Title: IBM Virtual Machine Facility/370:
System Logic and Problem Determination
Guide
Order No. SY20-0885-0
Please check or fill in the items; adding explanations/comments in the space provided.
Which of the following terms best describes your job?
o
Customer Engineer
D Engineer
D Instructor
D Manager
D Mathematician
D Operator
D Programmer
D Sales Representative
D Student/Trainee
D Systems Analyst
D Systems Engineer
D Other ( explain below)
How did you use this publication?
D Introductory text
;] Reference manual
D Student/ D Instructor text
D Other (explain) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
..
Did you find the material easy to read and understand?
DYes
D No ( explain below)
Did you find the material organized for convenient use?
DYes
D No (explain below)
c •
:J:
Specific criticisms (explain below)
Clarifications on pages
Additions on pages
Deletions on pages
Errors on pages
Explanations and other comments:
Thank you for your cooperation. No postage necessary if maile4.in the U.S.A.
::;l
: 3"
:l>
SY20-088S-0
'0
• :J
'IQ
:-1
.::r
• en'
:r
·5"
Your views about this publication may help improve its usefulness; this form
will be sent to the author's department for appropriate action.
Using this
form to request system assistance and/or additional publications or to suggest
programming changes will delay response, however. For more direct handling
of such requests, please contact your IBM representative or the IBM Branch
Your comments will be carefully reviewed by
Office serving your locality.
the person or persons responsible for writing and publishing this material. All
comments or suggestions become the property of IBM
• CD
FOLD
: aJ
FOLD
............................................................................................................................ 3:
.:<
:3:
FIRST CLASS
PERMIT NO. 172
[
BURLINGTON, MASS.
]
.W
......
:!=?
:~
.~
:rBUSINESS REPLY MAIL
NO POSTAGE STAMP NECESSARY IF MAILED IN U.S.A.
:c8
: c;'
'1»
.:::s
.·:c.
."
'0
~
:P"
POSTAGE WI LL BE PAl D BY
:0
·CD
IBM CORPORATION
:3
•.CD
r+
VM/370 PUBLICATIONS
: :i'
• I»
• d'.
'0
24 NEW ENGLAND EXECUTIVE PARK
::::s
BURLINGTON, MASS. 01803
:c
'C)
'0.:
:CD
:."
• :::!.
• :::s
•'CD
r+
:c.
........................................~ ................................................................................... : :r
:c
FOLD
FOLD
'en
·:l>
.
• en
:<
'N
'0
:6
.OQ
'OQ
:Y"
:0
International Business Machines Corporation
Data Processing Division
1133 Westchester Avenue, White Plains, New York 10604
(U.S.A. only)
IBM World Trade Corporation
821 United Nations Plaza, New York, New York 10017
(International)
SV20-0885-0
.
"'tI
:i'
s-a.
:i'
c
en
~,
(I)
-<
N
9
o()Q
()Q
Y1
o
International Bu.lne•• Machine. Corporation
Data Proce ••lng Dlvl.lon
1133 We.tche.ter Avenue, White Plain., New York 10604
(U.S.A. only)
IBM World Trade Corporation
821 United Nation. Plaza, New York, New York 10017
(International)
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.3 Linearized : No XMP Toolkit : Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:56:37 Create Date : 2003:11:06 18:00:35-08:00 Modify Date : 2009:09:11 08:15:10-07:00 Metadata Date : 2009:09:11 08:15:10-07:00 Producer : Adobe Acrobat 9.13 Paper Capture Plug-in Format : application/pdf Document ID : uuid:631596ef-ff1b-4bc8-96ca-1785a06397f5 Instance ID : uuid:26c80014-ab2f-4fd1-a638-5b69b1d32146 Page Layout : SinglePage Page Mode : UseOutlines Page Count : 665EXIF Metadata provided by EXIF.tools