--_ IBM Virtual Machine Facility/370: System Logic and Problem Determination Guide Voiume Systems.

Transcription

1 File No. S37-36 Order No. SV Systems BM Virtual Machine Facility/37: System Logic and Problem Determination Guide Voiume 2 Conversational Monitor System (ems) Release 6 PLC 1 This publication is intended for the BM system hardware and software support personnel. t provides the following information for the CMS component of VM/37: Description of program logic Module descriptions and cross-references Abend codes PREREQUSTE PUBLCATONS BM Virtual Machine Facility/37: ntroduction, Order No. GC2Q-18 Terminal User's Guide, Order No. GC2-181 CMS Command and Macro Reference, Order No. GC2Q-1818 CMS User's Guide, Order No. GC2Q _.. -

2 This is a major revision of, and obso~etes, 5Y and Technical Newsletter 5N This edition applies to B~!~~2~ 2 ~~~ 1 (Prograa Level Change) of tb~ BM Virtual Machine Facility/37 and to all sabsequent releases until otherwise indicated in new editions or Tecbnical Newsletters. Technical changes and additions to text and illustrations are indicated by a vertical bar to the left of the change. Changes are periodically.ade to the infor.ation herein; before usin~ this publication in connection with the operation of BM systems, consult the latest!~~ ~2!~~LJ1Q ~i~!iqg~ h, Order Ro. GC2-1, for the editions that are applicable and currant. Publications are not stocked at the address given below; requests for copies of BK publications should be made to your BM representative or to the BK branch office serving your locality. A form for readers' com.ents is provided at the back of this Fublication. f the form has been removed, co.ments.ay be addressed to EM Corporaticn, 'K/37 Publications, Dept. D58, Bldg. 76-2, P.o. Box 39, Pou~hkeeFsie, New York BM may use or distribute any of the information you supply in any way it believes appropriate without incurring any Obligation whatever. You may, of course, continue to use the information you supply. Copyright nternational Business Machines Corporation 1977, 1979

3 Preface This publication provides the BM system hardware and software support personnel with the information needed to analyze problems that may occur on the BM Virtual Machine Facility/37 (VM/37). Use the directories and use the!~1q ~i~ AE~as ~n 2niE21 ~12! 199i to help you to isolate the problem. Use the method of operation and program organization sections, if necessary, to understand the operation that was being performed. This manual comprises three volumes: "Volume 1. VM/37 Control Program (CP)," "Volume 2. Conversational Monitor System (CMS)," and "Volume 3. Remote Spooling Communications Subsystem (RSCS)" contain the logic description for each of the components. Each of these volumes is divided into four sections: ntroduction~ Method of Operation, Directory, and Diagnostic Aids. The method of operation and program organization sections contain the functions and relationships of the program routines in VM/37. They indicate the program operation and organization in a general way to serve as a guide in understanding VM/37. They are not meant to be a detailed analysis of VM/37 programming and cannot be used as such. The directories contain descriptions of all the assemble modules in CP, CMS, and RSCS. They also contain extensive cross-references between modules and labels within a VM/37 component. The diagncstic aids s~ctions contain additional information useful for determining the cause of a problem. The Appendix -- which is in Volume 1 - contains a description of VM/37 Extended Control-Program Support (ECPS). The following terms in this publication refer to the indicated support devices: "235" refers to Be 235 Fixed Bead Storage, Models 1 and 2. "27x" refers to BM 271, 272, and 273 Transmission Control Units or the ntegrated Communications Adapter (CA) on the System/37 Model 135. "333" refers to the BM 333 Disk Storage, Models 1, 2, or 11; the BM 3333 Disk Storage and Control, Models 1 or 11; and the 335 Direct Access Storage operating in 333/3333 Model 1 or 333/3333 Model 11 compatibility mode. "334" refers to the BM 334 Disk Storage, Models A2, B1, and B2, and the 3344 Direct Access storage Model B2. ~335~ refers to the Access Storage Models native mode. BM 335 A2 and Direct B2 in "374", "375", or "37X" refers to EM 374 and 375 Controllers. Communications The term "375" refers to the 375 and the 375 unless otherwise noted. "2741" refers to the BM 2741 and the 3767, unless otherwise specified. solate the co~ponent of VM/37 in which the problem occurred. Use the list of restrictions in!~ll1q ~y ~ ~ ~~ ~gg to be certain that the operation that was being performed was valid. "327" refers to a series of display devices, namely the BM 3275, 3276, 3277, 3278 Disrlay Stations. A specific device type is used only when a distinction is required between device types. nformation about disrlay terminal usage also applies to the BM 336, 3138, 3148, and 3158 Display Consoles when used in display mode, unless otherwise noted. Preface iii

4 Any information pertaining to the BM 3284 or 3286 also pertains to the EM 3287, 3288 dnd the 3289 printers, unless otherwise noted. and No: PREREQUSTE PUBLCATONS SUPPLEMENTARY PUBLCATONS Order No.!~~ Q~L!~, ]Q~L!~, ~~Q!]L1Q!2 ~!~!~f 1~ngy~g~, Order No. GC33-41 COREQUSTE PUBLCATONS RELATED PUBLCATON!~~!i!!~~l ~~ ~i~~!~ ili!ll11q ~EQQli~g 2!!Y~! ~!iq~ ~Y~212!~! Q2~f~2 ~Y!Q~, Order No. GC2-18l6 ~Y2!~~ ffq9f~!~~f~2 QyiQ~, Order No. GC2-l87 CMS/DOS is part of the CMS system and is not a separate system. The term CMS/DOS is used in this publication as a concise way of stating that the DOS simulation mode of CMS is currently active; that is, the CMS command SET DOS ON has been previously issued. The phrase "CMS file system" refers to disk files that are in CMS's 8-byte block format; CMS's VSAM data sets are not included. n addition, for EREP processing the following OS/VS Library publications are required: iv BH VM/37 System Logic and Problem Determination--Volume 2

5 ~- Contents SU~~ARY OF A~LNDMENrS. ix CONVERSATONAL MONTOR SYSTE~ (CMS) 2-1 NTRODUCTON TO CMS The CMS Command Language The File System. Program Development NTERRUPT HANDLNG N CMS. SVC nterruptions.. nternal Linkage SVCs Other SVCs. nput/output nterruptions Termina: nterruptions Reader/Punch/Printer nterruptions User-Controlled Device nterruptions Program nterruptions External nterruptions Machine Check nterruptions FUNCTON AL NFORMAr ON 2-11 Re~ister Usage Structure of DMSNUC U:JERSSCT (User Area) 2-12 DEVT AB (Device rable) 2-12 Structure of CMS Storage 2-12 Free Storage Management GETMAN Free Storage Management DMSFREE Free Storage Management Releasing Allocated Storage 2-21 DMSFREE Service Routines 2-22 Error Codes from DMSFRES, DMSFREE, and DMSFRET 2-24 CMS Handling of P SW Keys CMS SVC Handling 2-26 SiC Types and Linkage Conventions 2-26 Search Hierarchy for SVC User and Transient Program Areas 2-29 Called Routine Start-Up Table 2-31 Returning to the Calling Routine CMS nterface for Display Terminals 2-34 Os MACRO SMULATON UNDER CMS 2-35 OS Data Management Simulation 2-35 Handling Files that Reside on CMS Disks 2-35 Handling Files that Reside on OS or DOS Disks Simulation Notes 2-38 Access Method Support Reading OS Data Sets and DOS Files Using Os Macros 2-45 DOS/VS SUPPORT ONDER CMS 2-48 CMS Support for OS and DOS VSAM Functions 2-48 CMS METHOD OF OPERATON AND PROGRAM ORGANZATON NTALZATON OF THE C~S VRTUAL MACHNE ENVRONMENT nitialization: Loading a CMS Virtual Machine from Ca ra. Reader nitializes Storage Contents and System Tables 2-58 Processes PL Command Line Parameters nitialize OS SVC-Handling without the Use of the CMSSEG Segment 2-59 nitializing a Named or Saved System 2-bO Handling the First Commanj Line Passed to :MS. 2-6 Setting and QueryinJ Virtual Machine Environment Options 2-6 DMSSET: SET DOS ON (VSAM) Processing 2-6 DMSSET: SET SYSNAME Processing 2-61 PRCCSSSNG AND EXECUTNG CMS PLES 2-62 ~aintaining an nteractive Console Environment e 2-62 Console Management and Command Handling in CMS 2-62 Maintaining an nteractive Command/Response Session 2-62 Execute Commands Passed via DMSNS 2-63 Handle Commands Entered During a CMS Terminal Session 2-63 Method of Operation for DMSNT 2-64 Method of Operation for DMSTS 2-65 Types of SVCs and Linka~e Conventions 2-66 Search Hierarchy for SVC User ana Transient Pro~ram Areas 2-68 Called ROlltine Start-Up Tabl e Returning to the Caller System ana User Save Area For~ats. 2-7 Load and :sxecute Text Files SL: :ard Routine rcs Card Routine - C2AE1.. ~ 2-73 ESD Type a Card Routine - C3AA ESD Type 1 Card Routine - ENTESD 2-74 ESC Type 2 Card Routine - C3AH ESD Type 4 Routine - pc ESD TYFes 5 and 6 Card Routine - PRVESD ana. COMESD 2-76 ESD Type 1 Routine - WEAK EXTRN 2-77 TXT :ard Routine - C4AA REP C3.rd RO;Jt.ine - C4AA END Card Routine - C6AA1 2-8 Control Card Routine - CTLCRD REFAD R Routine (DMSLDRB) 2-82 PRSERCH Routine (DMSLDRD) Loader Data Ba ses ESDTB Entry 2-83 Pa tch Control Block (PCB) Loader nput Restrictions Processing Commands That Manipulate the File System Managing the CMS File System 2-86 Contents v

6 How CMS Files Are ~rganized in Storag~ 2-86 File Status rabes 2-86 Chain Links CMS Record Formats Disk or~anization Physical Organization of Virtual Disks 2-88 The Master File Directory Keeping rrack of Read/Write Disk Storage: QMSK and QQMSK 2-9 Dynamic Storage Management: Active Disks and Files CMS Routines Used To Access the File System Access a Virtual Disk: DMSACC 2-93 Handling O Operations Unit Record /O Processing 2-94 Han.dlin;, nterruptions 2-98 Disk 1/ in CMS Read or Write Disk /O 2-98 Managin] ems Stnr~~p _ Types of Allocated Free Storage 2-99 GE~~AN Free Storage Management Pointers. 2-1 DMSFREE Free Storage Pointers 2-11 DMSFRS Method of Operation Relative Efficiency of DMSFREE Requests Releasing Allocated Storage 2-15 DMSFRE Service Routines Stora;,e Protection Keys CMS System Handling of PSW Keys 2-17 CP Handling for Saved Syste.s 2-18 Error Codes from DMSFRRF., DMSFRES, and DMSFRET.2-11 The DMSFRES Macro The DMSKEY Macro The DMSEXS Macro SMULATE NON-CMS OPERATNG ENVRONMENTS Access Method Support for Non-CMS Operating Environments OS Access Method Support CMS Support for the Virtual Storage Access Method Creating the DOSCB Chain Executing an AMSERV Function Executing a VSAM Function for a DOS User CMS/DOS SVC Handling Executing ~ VSAM Function for an as User Completion processing for OS and DOS VSAr. Programs OS Simulation by CMS Simulating a DOS Environment under ems nitializing DOS and Processing DOS System Control Commands Setting or Resettin~ System Environment Options Process CMS/DOS OPEN al~ CLOSE Functions 2-14 Process CMS/DOS Exe=ution-Related Control Commands Simulate DOS SVC Functions SV:s Tredted as No-Op by CMS/DOS 2-1~7 Process CMS/DOS sarvice.commands Terminate processing the CMS/DOS Environment PERFORMNG MSCELLANEOUS CMS FUN:TONS ems 3atch Facility Error Printouts C MS D RECl'OR ES MODULE ENTRY PONT DRECTORY ~ODULE-TO-LAB~L CROSS REFERENCE LABEL-TO-MODULE CROSS REFERENCE CMS DAGNOSTC ADS SUPPORTED DEVCES DMSFREX E~ROR CODES Error :odes from DMSFREE, DMSFRES, and DMSFRET.2-24 ABEND CODES Abend Recovery Unrecoverable Termination -- The HALT Option of DMSERR APPENDX A: CMS MACRO LBRARY APPENDX E: CMS/DOS Macro Library NDEX vi BM VM/37 System Logic and Program Determination--Volume 2

7 FGURES Figure 1. FiJure 2. Figure 3. Figure 4. Fi;ure 5. Figure 6. Figu:r:e 7. Figure 8. 'igure 9. Figure 1. Figure 11. Figure 12. Figure 13. Figure 14. CftS File System 2-6 Devices Supporte1 by a C~S virtual 5achine 2-13 CftS Storage ftap 2-16 CftS Co.~and (and Request; processing 2-3 PSi Fields when :alled Routine Starts 2-31 Register Conte&ts when :alled Routine Starts 2-31 Simulated os Supervisor Calls.========2-31 An Overview of the Functional Areas ~f CKS 2-52 Details of CftS Systea Functions and the Routines that Perform Them 2-53 PSi Fields when Callea Routine is Started 2-69 Register Contents when :alled Routine is Started 2-1 How CMS File Records are Chained Togehter 2-86 Format of a File Status Block; Format of a rile Status rable 2-86 For.at of the First Chain Link and Nth Ch~in Links 2-89 Figur~ 15. Arr~nlement of Fixed-Length Recoras and Variable-Length Re=oris in Files 2-B9 Figure 16. structure of the Master File Directort 2-92 Figure 17. Disk Storage Allocation Using the QMSK Data Block 2-92 Figure 18. Flow of Control for Unit Recora /O processing 2-94 Figure 19. Relationships in storage between the CMS nterface ~oaule DMSA~S and the CMSAMS ana CHSVSAM DCSSs ~2-115 Figure 2. The Relationships in storage between the User Program and the C~SDOS ana CMSVSAft DCSSs Figure 21. Relationship in storage between the User Program, the os Simulation and nterface Routines, and the CMSDOS ana CMSVSAft DCSSs figure 22. OS Functions that CMS Simulates Figure 23. Devices Supported by a Virtual Machine Figure 24. CBS Abend Codes Contents vii

8 viii BM VM/37 System Logic and Program Determination--Voluae 2

9 Summary of Amendments for SY V!/31 Release 6 pte 1 AUTOMATC RENTALZATON SUPPORT!~!: Program and Documentation rhis support allows a ems virtual machine to specify that control be given to a reinitialization program as an alternative to entering a disabled wait state after an abend. This information is included in the "CMS Method of Operation and program Organization" section of this publication under "Processes PL Line Parameters" and in the "CMS Diagnostic Aids" section of this publication under "Unrecoverable Termination." Summary of Amendments ix

10 summary cf Amendments for SY as updated by TNL SN VM/37 Release 5 PLC 12 NDEX CORRECTON ~gng~ : Documentation only The index Problem (~R~f--was corrected. for!~lq Q~i~!!!~g!!~~ in error x BM VM/37 Syste~ Logic and Problem Determination--Volu.e 2

11 ~~".~no Summary of Amendments for S2-887 VM/37 Release 5 PLC 1 SSTEK LOGC AND PROBLEM DETERMNATON GUDE HAS BEEN REORGANZED ~hgdqed: Documentation only!~l~lq ~!~~ 1991 and Problem Determination Guide has been-split-nto three-vouies.--iouae 1 contains the CP component, Volume 2 the C~S component, and Volume 3 the RSCS component. The following material has been removed from this publication: "ntroduction to Debugging" and "Debugging with C~S." This information can be found in Y~LJ1~ ~Y!~. ff~ra~~~f~ ~~! ~. "Appendix A. VM/37 Coding Conventions." This information can be found in!~ljq a!~ ff2gf~!2 yid~. "Appendix B. DASD Record Formats." This information can be found in!~ljq ~~!ic~ RQY!!~2 f!qg!~! ~~! in the FORMAT section. "Appendix c. V~/37 Restrictions." This information can be found in!~11q fj~nidg gdg Syste! ~2D2g!!QD ~Ylg~ or!~ljq ~!!2! ~2 ~g2 "~ppendix D. Applying PTFs." This information can be found in!~ljq fjsd~~~~ g~g ~!~! ~2n~~!i2n Guid2 The following sections have been reaoved from the "C~S Diagnostic Aids" section of this publication: The following has been added to Volume 2: "Appendix!: CMS Macro Library" "Appendix B: CMS/Des Macro Library" The following topics have been removed from PCP Diagnostic Aids": CP Commands Used to Debug the Virtual Machine. These are contained in!~ljq ~E CO!!~~Q ~~fe~~~!q! ~~n~g! Q2~ CP Commands for System ihese are contained QE~ato~ yid~. V8/37 SUPPORTS PROCESSORS!2!: Program Feature 331, 332, Programmers. in Y~~Q AND 333 VM/37 provides support for the new channel-attached consoles that are part of the 333 processors. VM/37 uses the 333 processor aodel numbers in selecting monel-dependent routines and setting pertinent time slices. The channels of the new processors are supported by the channel check error ~n ~Cvv.cL ~~~~~"~. During initialization of the machine check handler/channel check handler, error frames are read from the Service Record File (SRF) and written to the V8/37 error recording area as a new record type. ZAP Service Program. A complete description of ZAP can be found in!~l11q QE~atQ!~ Qy!Q~ DDR. A complete can be found in Yig~ description of DDR!~LJQ QE~at2~ CMS Return Codes. These can be found in!~ljq a! 1~~ Me ggg. Commands for Debugging. description of DEBUG can!~ljq ~~~ US~f~ ~!g~. A complete be found in Su ary of Amendments xi

12 VM/37 MONTOR COMMAND!~~: Progra~ Feature ENHANCED Specification recipient of data. of i1 userid the spocled as the monitor VM/37 monitor facilities now include, in addition to data collection on tape, spooling to disk. Operands have been added to the MONTOR command that allow: The autcmatic start and collection by values. The automatic start and defined stop of data time-fo-day stop of data collection by defining a high limit value.!h SCELLANEOUS fhg~g~g: Programming and Documentation Minor technical and editorial changes have been made in order to clarify the text. xii BM VM/37 System Logic and problem Determination--Volume 2

13 Conversational Monitor System (CMS) This section contains the following information: ntroduction to CMS nterrupt Handling in C"S Functional nforaation OS ftacros Under CMS DOS/iS Support Under ems CMS ntroduction 2-1

14 2-2 B! V!/37 Syste. Logic and program Deteraination--Voluae 2

15 ntroduction To ems The Conversational Monitor system (CMS), the major subsystem of Vft/37, 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. CftS is designed specifically for the Vft/37 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 CftS user has his own machine configuration and his own files. Debugging is simpler because the files and storage area are protected fro. other users. Programs can be debugged fro. the terminal. The terminal is used as a printer to examine limited a.ounts of data. After examining program data, the terminal user can enter commands on the terminal that will alter the program. This is the most common method used to debug programs that run in CMS. CMS, operating with the VM/37 Control Program, is a time sharing system suitable for problem solving, program development, and general work. t includes several programming language processors, file manipulation commands, utilities, and debugging aids. Additionally, CftS provides facilities to simplify the operation of other operating systems in a virtual machine environment when controlled from a remote terminal. For example, CMS capabilities are used t~ create and modify job streams, and to analyze virtual Frinter output. Part of the CMS environment is related to the virtual machine environment created by CP. Each user is completely isolated from the activities of all other users, and each machine in which CBS executes has virtual storage available to it and managed for it. The CP commands are recognized by CBS. For example, the co ands 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. t supports a variety of programming languages, service functions, file manipulation, program execution control, and general system control. For detailed information on CftS commands, refer to the!~l11q CMS ~QD~~ g~g ~g!q Re!~renc~. Figure 4 describes CMS command processing. CMS ntroduction 2-3

16 The File System The Conversational Monitor System 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. Logical access to those virtual disks is controlled by CMS, while CP facilities manage the device sharing and virtual-to-real mapping. User files in CMS are identified with three designators. The first is filename. The second is a filetype designator that may imply specific file characteristics to the CMS file.anagement routines$ The third is a filemode designator that describes the location and access mode of the file. The compilers available under ems 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 CftS EDT facility. EDT provides extensive context editing services. Pile characteristics such as record length and format, tab locations, and serialization options can be specified. The system includes standard definitions for certain filetypes. ems 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 LSTNG. These disk locations may be overridden by the user. 1 single user file is limited to a maximum of records and must reside on one virtual disk. The file management system limits the number of files on anyone virtual disk to 34. All CftS disk files are written as aoo-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. 1 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. Virtual disks may be shared by ems users; the facility is provided by YM/37 to all virtual.achines, 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. ems files can be written onto and restored from unlabeled tapes via CMS commands. 2utiQ~: Multiple write access under ems can produce unpredictable results. 2-4 BM VM/37 System Logic and Program Determination--Volume 2

17 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 1 describes the CMS file system. Program Development The Conversational Monitor System 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 changede n order 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 reco~ds are physically kept in the chained SOO-byte blocks that 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 Supervisor Call functions such as GETMAN/FREEMAN and TME are simulated. The simulation restrictions concerning what types of as object programs can be executed under CMS are primarily related to the as/pcp, MFT, and MVT ndexed sequential Access Method (SAM) and the telecommunications access methods, while functions related to multitasking in as and DOS/VS are ignored by CMS. For more information, see "as Macro simulation under CMS" and "DOS/VS Support under CMS." CMS ntroduction 2-5

18 to..) ~..,- DMSNUC Area of Storage \.Q j:;i 1-/ H CD to AFT 3 ~ ~ 3: DMSNUC... n w 3:..,.J til "2i til..,- "<... en CD c+ CD til i ~ en 1:-4 ri- O CD.Q!..,. () ~ t: Pol i1:1 1-/ \Q H jl. iii t=' (D r+ CD H i... t: ~ ri-..,. t: ~... d CD to..) Free Storage Di,;k Storage

19 nterrupt Handling n ems CMS receives virtual SiC, input/output, program, machine, and external interruptions and passes control to the appropriate handling program. SVC nterruptions The Conversational Monitor System is SVC (supervisor call) driven. SVC interruptions are handled by the DMSTS resident routines. Two types of SVCs are processed by DMSTS: internal linkage SVC 22 and 23, and any other SVCs. The internal linkage SiC 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 DMSNT). ~he as SVCs are issued by the processing programs (for example, the Assembler). NTERNAL LNKAGE SVCS When DMSTS receives control as a result of an internal linkage SVC (22 or 23), 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 22, or by a halfword code following SVC 23. ) For SVC 22, if the called program is not found in the internal function table of nucleus {resident} routines, then DMSTS attempts to call in a module (a CMS file with file type MODULE) of this name via the LOADMOD command. f the program was not found in the function table, nor was a module successfully loaded, DMSTS returns an error code to the caller. To return from the called program, DMSTS restores the calling program's registers, and makes the appropriate normal or error return as defined by the calling program. OTHER SVCs The general approach taken by DMSTS 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 functiorr program, as is the case with the internal linkage SVC, DMSTS passes control to the appropriate routine. The SVC number determines the appropriate routine. n handling non-cms SiC calls, DMSTS refers first to a user-defined SVC table (if one has been set up by the DMSHDS program). f the user-defined SVC table is present, any SVC number (other than 22 or 23) is looked for in that table. f it is found, control is transferred to the routine at the specified address. CMS ntroduction 2-7

20 f the SVC number is not found in the user-defined SVC table (or if the table is nonexistent), DMSTS either transfers control to the CftSDOS shared segment (if SETDOS ON has been issued), or the standard system table (contained in DMSSVT) of OS calls is searched for that SVC number. f the SVC number is found, control is transferred to the corresponding address in the usual manner. f the SVC is not in either table, then the supervisor call is treated as an abend call. The DMSHDS initialization program sets up the user-defined SVC table. t is possible for a user to provide his own SVC routines. nput/output nterruptions All input/output interruptions are received by the /O interrupt handler, DftST. DftST saves the /O old PSi and the CSi (channel status word). t then determines the status and requirements of the device cau~in; the interruption and passes cfil~1 Lo the ~uutine that processes interruptions from that device. DMST 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 DMST. At this point, DftST tests the wait bit in the saved /O old PSi. f this bit is off, the interruption was probably caused by a terminal (asynchronous) /O operation. DftST then returns control to the interrupted program by loading the /O old PSi. f the wait bit is on, the interruption was probably caused by a nanterminal (synchronous) /O operation. The program that initiated the operation most likely called the DMSOi function routine to wait for a particular type of interruption (usually a device end) n this case, DMST checks the pseudo-wait bit in the device table entry for the interrupting device. f this bit is off, the system is waiting for some event other than the interruption from the interrupting device; DftST returns to the wait state by loading the saved /O old PSi. (This PSi has the wait bit on.) f the pseudo-wait bit is on, the system is waiting for an interruption from that particular device. f this interruption is not the one being waited for, DMST loads the saved /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. f the interruption is the one being waited for, DftST resets both the pseudo-wait bit in the device table entry and the wait bit in the /O old PSi. t then loads that PSi. This causes control to be returned to the DftSOi function routine, which, in turn, returns control to the program that called it to wait for the interruption. 2-8 BM VM/37 System Logic and Program Determination--Volume 2