Type III Class A Program

Control Program-67/Cambridge Monitor System (CP-67 /CMS) Version 3.1

CMS Program Logic Manual Progra,m No. 3600-05.2.005

The Cambridge Monitor System (eMS) is a conversational monitor system that provides a comprehensive, easy-to-use set of programs (commands} giving the CMS user a wide variety of functions, including the ability to create addi- tional commands or subsystems to satisfy his special requ irements.

This manual provides a detailed description of the inter- nals of CMS.

GY20-0591-1

Type III Class A Program

The following documents are referenced in this manual:

CP-6 I/CMS User's Cuide, Form GH20-0~5,)

CP-n 7/CllS insral/ariuN Guide, Form GH20-0857 SRI-if' A STring Pr(Jcessing Language, Form 320-2005,

IB\l Cambridge Scientific Center

SCRIPT: An Online J/allllscripl Processing Sysrem, Form 320-:~023. IBM Cambridge Scientific Center OS/360 Supervisor & Duta Management

;Viano-Instructions. Form GC28-6647

Second Edition (Octol'er 1971)

This Type I II Program performs functions that may be fundamental tl) the operation and maintenance of a s} stem. It has not been subjected to formal test by IB\'1.

U util this program is reclassified. IB:v1 will provide for it: (1) Central Programming Service, including design errOl correction and all tt: matic d istribu tion of COrTec lions: and (2) FE Programming Service, including design error ,'crification. A PA R docun':ntation and submis<;ion. and application of Program Temporary Fixes or de-

velopment of an em('rf!\~tll'Y hYra~s when required IH\-1 floe, not guarantee service results or represent or war- rant that all errors WIll be correded.

The user is e'-.pected to make the final evaluation as to the usefulness of this program in his own environment.

THE I {)RLGOP,(; IS IN LIFt: 01 ALL WARRAl'\TILS LXPRESSED OR I~U)LIED.INCLLJDING, BUT NOT U\lITLD TO. TilL 1\1PLIJ·[) \\":\RRA.YfIl.S Of- \11 RCHAi\TABlLITY AND FITNESS fOR A PARTICULAR PURPOSE.

This edition applies to \'n-;ion 3. \!odifica tion Level J, of Can tr01 Program-6 7 !Cam bridge \1onitor System (3600-05.2.005 i and to all :-.ubscquent ver\iom and modifications until othen"ise indicated in new editions or Technical !\e,vslctter'

Changes arc continually made 1<) the information herein: therefore. before using this publication, consult the latest Sy~tern36(j SRL:'\ewsletter ((;N20-0360) for the editions that arc applicable and current.

(opiesoitlii,and otll('[ IB,\! publiL'alion~ c:an be obtained through IB\1 branch offices.

I'

COKTEXTS

Section 1: Introduction to C:\IS . . . . Components and Facilities Provided by C:VIS. . C l\IS Commands . . . • . . • • • . • . • File Creation, Maintenance and Manipulation .

Language Processors . . • •

Execution Control. . . . . . . • . • . Debugging Facilities .

Utilities . . . . Control Commands Library Facilities . . Page Release Facility C 1\1S Core Requirements C MS Batch Monitor.

Machine Configuration

Section 2: Internal Characteristics Internal Linkage Scheme . . . • Return Code Conventions . Main Storage Management

eMS Nucleus . • . . . . . . . • • • C MS Disk File Organization and Management

Disk Management . • • . . • ⁰ System Disk . • • . • • • ^{0 • • 0} Disk Space Management • • ^{0 0 • • • •}

Read-Write Disks . . . . .

System and Other Read-Only Disks . • . . Active File Table (AFT)Management

Active Disk Table (ADT) Management I/O Operations . . .

C lVIS Terminal I/O . . • • . C::.vIS Non-terminal I/O . . . . • ^{0 • •} Cser Input/Output Operations

HNDINT . • • . . • SVC Simulation ^{u 0 • • 0}

OS Simulation L'nder Cl\'IS

Operating S~'stem/360 SVC Simulation Routines Section ^~3: ;VIonitor Operations

System Initialization

System Continuity ^{c • • •} Stacking of Typed-in Commands.

Abbreviations for C:;\IS Commands.

Interruption Handling SVC Interruptions

HKDSVC

1 1 1 1 1 2 2 2 2 3 3 3 3 4

7 7 8 8 14 16 17

27 27 29 34 34 34 35 36 38 38 39 40

41 42 71 71

72 73 74 71 75 75 79

Input/Output Interruptions

Cl\IS Terminal Interruptions . . . . CMS Reader/Punch/Tape Interruptions CMS Printer/Disk Interruptions. . . User Controlled Device Interruptions Program Interruptions . . .

External Interruptions . . . . Machine-Check Interruptions Override Handling . . . .

Normal Override Operations

Error Override Operations . . . . System Restart . • • • ^{0 • • • • • • •} Section 4: Command Program Descriptions

File Creation, Maintenance, and Manipulation ALTER . • • • • • . ^{0 •} CEDIT

CLOSIO COMBINE EDIT ERASE FILEDEF FINIS LISTF OFFLINE PRINTF SCRIPT SPLIT STATE STATEW UPDATE Execution Control

EXEC . G • • •

GENMOD GLOBAL LOAD LOADMOD USE-REUSE START

S • • • .

Debugging Command Programs CLROVER . • • • • • DEBUG

SETERR . • ⁰ SETOVER

Language Processsing Command Programs ASSEl\IBLE . • . . . • • • •

FORTRA~

PLI

81 '32 83 83 84 84 84 84 85 85 86 86 87 87 87 90 90 91 93 98 101 106 106 108 111 113 115 116 117 118 119 119 120 124 125 126 128 129 130 132 132 133 136 137 138 138 140 141

S~OBOL • 143

BRCIK • 144

Ctilities 146

CNVT:26 146

C01\TPARE 147

CYTFV 148

DISK 150

DUMPD 152

DUMPF 153

DCMPREST 154

ECHO 155

FORMAT. 155

GENDIRT 165

J\IAPPRT; 166

lVIODMAP. 167

OSTAPE 0 167

SORT 169

STAT 169

TAPE 171

TAPEIO 174

TAPRINT 175

TPCOPY. 175

\VRTAPE. 176

Control Commands 177

BLIP. 178

CHARDEF 178

CPFUNCTN 178

IPL 179

KE. 180

KO. 180

KT. 181

KXo 181

LINEND 182

LOGIN. 182

LOGOUT. 188

RELEASE 189

RT. 191

SY~ Q 191

VSET 194

VSET BLIP. 194

VSET I:YIPEX ^Q 196

VSET IDRTBLS • 196

VSET LINEND 197

VSET RDYMSG • 197

VSET REDTYPE 198

VSET RELPAG • 198

Libraries. 199

:\IAC LIB 0 199

TXTLIB 202

Fortran Subroutines. 206

Section 5: Service Program Descriptions .

vi

Storage 'Management Function Programs FREE . . .

FRET . • . SVCFREE SVCFRET .

File Management Macros ADT. . . • . . AFT. • • • • • • DIOSCT .

FSTB . FVS • . .

File Management Function Programs • RDBUF • • • • • • • • WRBUF

FINIS • STATE STATEW POINT • • •

File Management Routines. • TFINIS . .

RELUFD • • • READFST . READMFD . . FSTLKP . . . . FSTLK\V.

UPDISK . . UPUFD . . LOGDISK.

SYSGEN-INITSYS. .

Disk Space Management Routines. • QQTRK . . • • • . QQTRKX. • . • • • TRKLKP.

TRKLKPX.

Active File Table Management Routines.

ACTLKP. • • • •

ACTNXT.

ACTFREE . ACTFRET .

Acti ve Disk Table Management Routines ADTLKP. • • • • • • • • • . ADTNXT . . • . . . • • • • . • Disk Handling Function Programs

RDTK • • • . • . . . • • •

\YRTK" • • • • • • Direct I/O

213 213 213 213 214 214 215 216 218 219 220 221 223 223 227 232 235 237 238 240 240 242 243 245 247 249 251 254 255 256 258 258 259 261 262 264 264 265 266 268 270 270 271 273 273 275 276

Unit Record Handling Function Programs. . CARDIO . . . ' . . . ^{0 • • •} PRINTR-PRINTIO

Tape Handling Function Program TAPEIO . . . .

Terminal Hardling Function Programs . . . . . CONWAIT. . . • • . . TYPLIN - CONWRITE .

TYPE . . . . W AITRD - CONREAD •

User Program Device Handling Routine Input/Output Service Routines .

Synchronize Routine . . . . WAIT . . . . Centralized Error Recovery Program Normal/Error Override Function Programs

.RDERR . . .RESNRM .RESERR . RESUME

• RPLERR .STEROV .STNOV • •

Debugging Function Program DEBDUMP • • • • . • • .

Control and Service Function Programs GETCLK

KILLEXF LIBEPACK • • PRTCLK

IPLDISK - INITIPL • SCAN • . • • . • • SETCLK . . • . • BARE67 - INITB67 DEFTFLV • • . • . CMS Loader

OVRLD Initial ~nd Resume Loading Routine SLC Card Routine . . . . ICS Card Routine - C2AEI . . . . ESD Card Analysis Routine - C3AAI

ESD Type 0 Card Routine - C3AA3 . ESD Type 1 Card Routine - E~TESD

ESD Type 2 Card Routine - C3AHI . . . . . ESD Type 4 Card Routine - PC . . .

ESD Types 5 and 6 Card Routine - PRVESD and CO:\lESD . TXT Card Routine - C4AAI . . . .

278 278 280 283 283 285 285 285 286 287 288 289 289 289 290 297 297 297 299 300 300 301 302 302 302 304 304 304 305 305 306 306 307 308 308 309 310 311 312 312 314 315 315 316 317 317

REP Card Routine - C4AA3 RLD Card Routine - C5AA1 END Card Routine - C6AA1 LDT Card Routine - C6AC1 Control Card Routine - CTLCRDI REF ADR Routine . . . . PRSERCH Routine

HEXB Conversion Subroutine . . . • • . Start Execution Routine - XEQQ

Disk and Type Output Routine - LDRlO Library Search Routine - LIBEP ACK • . Relevant Loader Data Bases

Section 6: CMS Batch Monitor. . .

App~ndix A: CMS File Naming Conventions • Appendix B: CMS Directory

Appendix C: CMS File System Cross-Reference List Appendix D: CMS Control Blocks.

Index

viii

318 319 321 322 323 324 324 325 326 327 328 329 335 337 342 350 353 355

ILLUSTRATIONS

Figure

I. Internal Linkage Scheme •

· · · · · · · · · · ^· · · ·

2. Internal Linkage Scheme - Multiple Levels

· · · · · · · ^·

3. CMS Main Storage Layout.

· · · · · · · ^· · · ^· · ^{· · ·}

4. _{5. 6. 7. 8. 9.} n;Qnl~nDl'Y\DntQ ...., ... - t ' Example of Chaining of Free Storage Blocks Example of Free Storage After First Request Example of Free Storage After Second Request. Example of Free Storage After Five Requests Free Storage After Second Block Has Been Returned ... """''''''.&. ... ...,.a..&'''- ... _ ... ,--...,. .... f .... nl'Y\ NTT(Y)N

· · · · ·

· · · · · · · · · · ^{· ·} · ^· · · ^· · ^{· · ·} ·

10. Displacements of V-cons from SYSREF

· · ^{· ·}

II. File status Table Entry.

· · · ^· ·

12. Master File Directory (MFD) •

· · · · ^{· · · · · ·}

13. MFD, FSTB, and FST Relationship

· · · · ^{· ·} · ·

14. First Chain Link (FCL)

· ^· · ^· · · · · ^· · · · ^·

15. Nth Chain Link

· · · · · · ^{· ·} · · · ·

16. Relationship of FST, Chain Links, Data Blocks, and

Items of a File.

· · ^{· · ·} · · · ^{· · ·} ·

17. Example of Three FST Hyperblocks in Main storage.

· · · ·

18. Active File Table Block

· · · · · · ^· · ^{· · ·} · ^·

19. Active File Table (AFT)

· · · · · · ^· · · · ^·

20. Data Block Structure for File Consisting of Fixed- Length

Items

. . _{. · · · · · · · · · · · · · · ·} · · · · ^·

2I. Data Block Structure for File Consisting of Variable-Length

Items

. . . · · ^· · · · ^· · · · ^· · · · · ^· · · · ^·

22. Disk Quarter-Track Assignment (QMSK) •

· ^·

23. Disk Sixteenth Track Assignment (QQMSK) •

· · · · · · ^·

24. Disk Address Format for First Chain Links 32

25. Disk Address Format for Nth Chain Links and for

Data Blocks

·

26. Read/Write Stack

· · ^·

27. Pending Read Stack

·

·

· · · ^·

28. Finished Read Stack •

· · · ^{· ·} · ^· · · ·

29. Contents of a CMS MODULE File

(Variable Records)

· · · · · ^{· ·} · · · · · ^·

30. Macro Dictionary Format

· · · · ^· · · ·

31. Dictionary Header Record Format·

· · · ^· · ·

32. Text Library Dictionary Format

· · · · ^{· ·} · ^·

33. Text Library Dictionary Header Record Format

· ^{· ·}

34. CMS ADT Macro.

· · · · · · · · · · ·

35. CMS AFT Macro.

· · ^·

36. CMS DIOSCT Macro

· · ^·

37. CMS FSTB Macro . ²²⁰

38. ClVIS FVS Macro

· ^{· ·}

39. Relationship of IOERR to RDTK/WRTK

· · · ·

40. Relationship of IOERR to PRINTIO 282

SECTION 1: INTRODUCTION TO CMS

The Cambridge Monitor System (CMS) is a single-user ,conversational operating sys- tem. It is designed to allow full use of an IBM System/360 through a simple terminal- orientated command language. CMS gives the user a full range of capabilities - creating and managing files, compiling and executing problem programs, and debugging -

requiring only the use of his remote terminal.

CMS also provides a batch version that will process non-conversational user jobs. Job control cards that are imbedded within the input stream dictate which batch function will be executed.

COlvlPO~'"ENTS & FA CILITIES PROVIDED BY CIVIS eMS Commands

A CMS command is (1) the name of a program resident in the nucleus or on any CMS disk, or (2) the name of a file containing other CIVIS commands. C1,[S commands fall into seven categories: file creation, maintenance, and manipulation; language proc- essors; execution control; debugging facilities; utilities; control commands; and library facilities.

File Creation, Maintenance and Manipulation

The file handling commands of Cl\IS allow the user to create and modify disk files via a context editor as well as to rename, copy, combine, split, update, erase, and print disk files. The user can also print or punch files on unit record equipment. He can create disk files from cards read via the card reader. He also can format text infor- mation for letters, documents, or reports by utilizing the SCRIPT facility of CMS.

Language Processors

Some Operating System/360 Language Processors are used under CMS. These include Assembler (F), FORTRAN IV (G), and PLI (F). The Assembler produces object pro- grams that may be executed under either CMS or OS, depending on the macros used in the source program. Special file handling routines for macro libraries are included.

The FORTRAN and PL/I compilers also produce OS-compatible object programs.

Diagnostics from the OS compilers are printed at the terminal unless suppressed by the user or directed to disk. Because the CMS file system does not provide as many access methods as OS/360, some features of PL/I are not supported at program execution time.

SCRIPT, a text processor, is also provided. There are two additional processors available as Type III programs from the IBM Program Information Department; they are SNOBOL, a string processing language, and BRUIN, an interpretive language.

BRUIN, BRown University INterpreter, was adapted from the OS version of BRUIN developed at Brown University, Providence, Rhode Island. BRUIN provides two

I modes of operation: a desk calculator mode and a stored program mode.

1

Execution Control

The execution control commands allow the user to load his programs from single object decks called TEXT files (the filetype TEXT is reserved for relocatable object prograJ;l1s) or from a program library. The user can pass a list of parameters to his program from the terminal and specify the point at which execution is to begin. To bypass the re locating loader for each execution of the program, he can create a file consisting of an image of the portion of core storage containing his program and load that non-relocatable copy back at any time. Since the loading commands can be accessed by executing pro- grams, overlay structures may be set up and dynamic loading can occur.

During program execution under CMS the user can fully interact with his programs. For example, in FORTRAN Gunder OS/360 a READ to logical unit 5 reads the SYSIN device and a WRITE to logical unit 6 writes to the SYSOUT device; under CMS, a READ to 5 reads the operator's console (remote terminal under CP) and a WRITE to 6 writes the console.

The user also has the facility to create a procedure that is a series of commands and then to execute these commands by typing a single instruction; logic statements can be placed in the file with the commands so that the order of command execution may be dynamically set or altered. This capability is called EXEC and allows a user to develop his own command language or sets of procedures. EXEC also allows for the passing of variable arguments from the terminal as well as between EXEC files, since EXEC files can be nested and/or recursive.

Debugging Facilities

A permanent, nucleus-resident debugging facility is available to the user. It allows stoppage of programs at predetermined points and examination of registers, PSW, and storage, and permits modification of these if it is desired. This information may be typed out at a user's terminal or printed offline. A program interrupt gives control to DEBUG, as does the external interrupt caused by the EXTERNAL console function. The user may also employ the program tracing routines, which record all SVC transfers, or just those sve's in which an error return is made.

Utilities

The utility functions in CMS provide tape copying facilities, disk file comparison, a disk file sort, and the dumping of files either by name onto the console or by cylinder loca- tions onto the offline printer, as well as the facility to dump files to tape and reload them onto disk. There are commands also for converting files of fixed-length records to variable-length records, for converting BCDIC files to EBCDIC, and for obtaining statistics on file space.

Control Comlnands

There are other commands that give the user the facility to suppress the typeout at his terminal, to restore typing at his terminal once the typeout is suppressed, and to kill program execution. The user can redefine the logical line-end character, the character delete and line delete characters, as well as the blip character that notifies him of CPU

utilization. He can also rename any command and define his own abbreviations to be used.

Library Facilities

CMS provides library facilities for program libraries. The user can generate his own libraries or add, delete, or list entries in existing libraries. He can also specify which libraries to use for program assemblies as well as program execution.

Page Release Facility

Certain CMS routines include a page release facility. This means that following a successful completion and before returning to the user or caller, the routine ref- erences NUCON and turns a page release flag on. When the routine then returns to INIT, INIT checks this flag. If it is on, !NIT issues a diagnose X'lO' to CP to re- lease user pages from X'12000' up to the value in LOWEXT.

For the user to prevent this release of pages, the CMS VSET RELPAG OFF command should be issued. The commands that have the page release facility are: ASSEMBLE, CEDIT, COMBINE, COMPARE, EDIT, FORTRA.."N", MACLIB, MAPPRT, PLI, SORT, SPLIT, TAPE, TXTLIB, and UPDATE.

CMS Core Requirements

eMS has a prerequisite for 80R bytes of virtual memory for the nucleus, transient area, and loader tables. At login time, core space for user file directories is allocated

dynamically as required. The rest of core storage is available to user programs.

CMS Batch Monitor

As well as being a conversational monitor, CMS provides a batch facility for running CMS jobs. The CMS batch monitor accepts a job stream from a tape unit or from the card-reader and writes the output either on tapes, the printer, or the card-punch. The job stream can consist of a System/360 Operating System SYSIN job stream with

FORTRAN (G), and Assembler (F) compile, load, and go jobs or it can consist of CMS commands along with control cards and card decks for compile, load, and go jobs for all the CMS supported c'Jmpilers.

Just as the conversational CMS does, the batch monitor can run from either a virtual machine or a real machine. Under CP, it can be used as a background monitor along with other conversational CMS users.

To eliminate the possibility of one job modifying the eMS batch monitor's nucleus in such a way as to affect the next job, the batch monitor is re-IPLed before each job begins.

Files can also be written onto the batch monitor's primary disk and then punched or printed, such as files written by FORTRAN programs; these files should be of limited size and considered as temporary, as they are erased at the completion of each job.

3

MACHINE CONFIGURATION

Whether running on a real (see Note below) or a virtual machine, CMS expects the fol- lowing machine configuration:

Device Virtual Symbolic

Address Name

1052 009 CON1 console

2311,2314 190 DSK1 system disk (read-only)

2311,2314 191** DSK2 primary disk (user files)

*2311,2314 192** DSK3 temporary disk (work space)

*2311,2314 000** DSK4 A dis k (us er files)

*2311,2314 000** DSK5 B disk (user files)

*2311,2314 19C** DSK6

I

1403 OOE PRNI line printer

2540 OOC RDR1 card reader

2540 OOD PCH1 card punch

*2400 180 TAP 1 tape drive

*2400 181 TAP2 tape drive

at least 256K bytes of core storage, 360/40 and up

*The 2311 or 2314 for the temporary disk, the A, B and C disks, and the two 2400 tape drives are optional devices; they are not included in the minimum configura- tion.

**The specified virtual addresses may be changed at any time by the CMS LOGIN command.

Note: For use on a real machine not having this I/O configuration, the device addresses can be redefined at 'load' time.

Under CP, of course, these devices are simulated and mapped to different addresses and/or different devices. For instance, CMS expects a 1052 printer-keyboard operator's console, but most remote terminals are 2741's; CP handles all channel program modi- fications necessary for this simulation.

CMS allows the user to add his own programs for

I/o

The system disk, located at address 190, is read-only and contains the CMS system commands. These system programs are physically divided into two groups: nucleus functions and disk-resident command modules. The nucleus programs are loaded into main storage during initial program load (IPL) and remain resident throughout system operation. The disk resident modules are loaded into main storage only when their services are needed. Certain disk resident programs are loaded into the transient area.

The primary disk, 191, is a read-write disk and normally is the first user disk. Files that the user wishes to retain for use across terminal sessions are stored on one of the user! s disks. Information stored on the primary disk remains there until it is deliber-

ately erased or destroyed by the user. Commands and input files are entered into the system from the console (that is, the terminal located at address 009). Output files, program results, and error and prompting messages are directed from within CMS to the console. The card reader, located at address OOC, may be used as the input

medium for files, source decks, and data to be processed by user programs. The card punch, address OOD, may receive user output files, processor object decks, and vari- ous other types of data. The printer, address OOE, may receive user program results, and Assembler, FORTRAN and PLI listlngs. A tape, located at address 181, may be used in Dump/Restore operation and as an input/output medium for files.

5

SECTION 2: INTERNAL CHARACTERISTICS

This section describes the internal characteristics of CMS, including the way in which control is passed among the programs that make it up, the manner in which it manages main storage, disk space, and files, and the nature of its

I/o

INTERNAL LINKAGE SCHEME

In CMS, control is generally passed from one program to another (for example, from a command program to a function program) by means of a supervisor call (SVC) instruc- tion. When one CMS program requires the services of another, it issues a special SVC of the form SVC X' CA'. (This SVC may be followed by a 4-byte address constant con- taining an error return address.) Associated with the

sve

The execution of the SVC instruction causes an interruption, and controi passes to a SVC interruption handler (SVCINT). When SVCINT receives control, it saves (1) con- tents of the calling program's registers and (2) the SVC old PSW. This PSW contains the address within the calling program to which control is to be returned when execution of the called program is complete. Having saved these items, SVCINT sets up a return register with an address pointing to a location within itself. This location is where the called program is to return control. It then branches to the called program. When ex- ecution of the called program is complete, it returns to SVCINT through the return register.

In an error occurred during execution of the caiied program, SVCIl\J"'T returns control:

• To the error return address, if one followed the SVC Xl CA' instruction.

• To the CMS standard error routine (STDERR), if no error return address was given after the SVC in the calling program.

If no errors occurred during execution of the called program, SVCINT restores the call- ing program's registers, and loads the saved PSW. Control returns to the calling pro- gram at the executable instruction following the SVC Xl CA' instruction. Figure 1 shows how this scheme works.

Control within CMS may be passed via SVC's to a level of twenty calls. For example, one CMS program may call another (first-level call), which may call another (second- level call), which may call another (third-level call), etc. SVCINT intercepts each of these nested calls and takes steps to ensure proper return to the calling program. It does this for each call by: (1) storing the SVC old PSW that results from the interrup- tion and the contents of the registers as they exist at the time for the inteTruption in a last-in, first-out list, and (2) passing control to the called program. Upon return from the last called program (the program at the lowest level will return to SVCINT first), SVCINT restores the registers with the saved register data stored in the last entry in the list, deletes that entry from the list, and loads the saved PSW. Control is thereby ret'urned to the program at the next higher le\~e1. 'Vhen execution of this program i~

complete, SVCINT follows a similar procedure to return control to the program that called it. Figure 2 shows how this scheme works.

7

Calling Program

• SVCX' CA' SVCINT

~----,---

• (See Note) NRMISAV

I I

<:J •

, • and PSW

Note: I f an error occurs during execution of the called program,

I I

Return Register

control is passed either to:

(1) The CMS standard error

I

I I I

C>R

- Branch to called program I ,

~--- -~ I

routine; or

(2) An error return location whose address is contained in an address constant followina the SVC.

• Restore Registers

! I.:

I-I+ ... _ _ _ _ _ _ _ _ _

I

I I

I i I I

Return

--L---J

Figure 1. Interoallinkage scheme

RETURN CODE CONVENTIONS

When a program, called via an SVC X' CAl instruction, returns to the calling program, register 15 contains a positive, negative, or zero code. A positive code indicates that an error occurred during the execution of the called program. A negative code indicates that control was never passed to the called program. (This might occur if, for example, the user incorrectly types a command from the terminal.) A zero code indicates that the called program was executed successfully.

SVCINT is the only CMS program that returns negative error codes.

MAIN STORAGE MANAGEMENT

Main storage is composed of five main areas: the nucleus, free storage area, a tran- sient area, user program area, and a loader tables area. The nucleus contains the core resident portion of CMS; it begins at Page 0 of main storage and extends upward into Page 13. Free storage is that portion of main storage between the end of the nucleus and the start of Page 17 of main storage. Page 17 is a transient area into which certain CMS commands are loaded. The user program area, which starts at Page 18 (or above), is the area into which the user programs are loaded. The last two pages prior to the end of core are reserved for the loader tables used by the Cl\fS commands LOAD, USE, and REUSE for loading in programs. (See Figure 3. )

Passing Control to Called Programs

Program A (Calls B Via SVC X' CA')

!A REGS! A PSW !

W

i i

A REGS A 8 REGS 8

A REGS A 8 REGS B C REGS C

psw

PSW

PSW PSW PSW

Program B (Calls C Via SVC X' CA')

"

Program C (Calls D Via SVC X' CA')

~ Program D (No Calls)

Save A's Registers and Resultant PSW;

Pass Control To B.

Save B's Registers And Resultant PSW;

Pass Control To C.

Save C's Registers And R esu Itant PSW;

Pass Control to D

+

Figure 2. Internal linkage scheme - multiple levels

t

Restore A's Register;

Load A PSW To Return To A

Restore S's Registers;

Load 8 PSW To Return to 8

Restore C's Registers;

Load C PSW To Return to C.

Returning To Cailer 'vVhen Called Program Finished

Program A

I ^I

I

Program B

All

Program C

J~

Program D ARE

ARE B RE

GS A PSW

GS A PSW GS 8 PSW

9

~ End Of Core Loader Tables

(Two Pages)

User Programs

.,.Startof Page 18 Transient Area

4-Start Of Page 17

~ree Stor~ge

. . . End of Nucleus Code

Nucleus

4-Start Of Page 0 Figure 3. CMS main storage layout

Main storage management allocates and keeps track of the free storage that is available.

Free storage is used by the various eMS programs requiring blocks of main storage for temporary use (for example, as buffer space into which data blocks are read for proc- essing). When a program requires main storage, it calls the FREE storage management program indicating the number of double words required. The storage management pro- gram allocates the required storage and returns a pointer to its starting location to the calling program.

When a program has finished with such temporary storage, it returns it to a free storage via the FRET storage management program, indicating the size and starting location of the block being returned.

The storage management programs keep track of free storage through a series of pointers, the first of which originates in the storage cell FREELIST. FREELIST always contains a pointer to the free storage block at the lowest address. The free storage block pointed to from FREELJST starts with two fields; the first contains a pointer to the second free storage block (that is, the free storage block that starts at the next higher address); the second field contains the size (in bytes) of the block itself. Similar fields exist for the second, third, and subsequent free storage blocks. Thus, free storage blocks are always chained from low to high addresses. Figure 4 illustrates this concept.

Main storage management works in the follOwing way. The first request for main storage causes Page 16 to be made available as free storage. A block of storage of the requested size is allocated to the caller from the high-numbered end of Page 16, FREELIST is ini- tialized to point to the beginning Q.ow-numbered end) of Page 16; the pointer and size fields

End Of P'ge 16

T

Block C [

I

l

Freelist

r,

"-~-.~{ ~­ --=-l

Key:

, / ////1) Portion Of Free Storage

V://

/

Allocation.

Figure 4. Example of chaining of free storage blocks

End of Page 15

Size Of B

Ql Cl ~ en ~ Ql ~ II..

I I

- - - - - - _!4-EndOfpage13i

Size Of A

Pointer To B End Of Nucleus

Code

at the beginning of Page 16 are initialized appropriately, and FREENUM is set to one.

(See Figure 5.) A second request for free storage causes the next available lower block near the end of Page 16 to be allocated to the caller, and the size field at the beginning of the one and only free storage block at the beginning of Page 16 is decremented by the number of bytes just allocated. (See Figure 6. )

Assume now that three additional requests for free storage blocks are satisfied (see Figure 7), but that after the last of these, the program that received the second block no longer needs it and returns it for use by other programs. The released block is chained into the free storage list as the second entry, and FREENUM is appropriately updated.

(See Figure 8. )

For each subsequent request for free storage, the storage management programs scan the chain of free storage blocks for one that is equal in size to that requested. H one is found, it is immediately allocated to the caller, the chain of free storage blocks is broken

11

First Block Allocated

Remaining Free Storage In Page 16 Available For Allocation

rr-,...,...,--;?'-r..,....-r-.."...-:~...,...,..-r-,..-End Of Page 16

Size This Block

r -_ _ ~ _______________________ O~~EndOfPa~15

Freenum

Key: First Block Of Free

V// / //:Ii

...

rL ... // __ ... / / .. _ // ... _

Figure 5. Example of free storage after rust request

End of Page 14

End Of Pa~ 13

End Of Nucleus Code

and relinked to delete the allocated block from the free storage list, and FREENUM is decremented by one. If a free storage block equal in size to that requested cannot be found, but one or more free storage blocks larger in size than that requested are found, storage is allocated to the caller from the high-numbered end of the last larger block that was found, and the size of that block is decremented appropriately.

If neither a matching nor a larger block of free storage is available, the EXTEND stor- age management program allocates another large block of free storage as available be- tween the end of the eMS nucleus and the start of Page 17. This large block (for exam- pIe, Page 15, later Page 14, then whatever free storage may be available at the end of block 13) is merged properly into the free ~torage chain (that is, FREELIST points to its beginning), and the caller's previously unsatisfied request is then handled in accordance with the revised chain of available storage. (Note in Figure 7 that Page 15 had to be ob- tained to allocate the third block, and later Page 14 was needed for allocation of the fifth block. )

Eod of P'g'

161

::~:c!::k {WWh00//A

Second Block

J

Allocated

L

In Page 16

Available for I---S-iz-e-T-h-is-S-IO-C-k - I

Allocation I - - - - -_ _ _ _ _ _ _ _ ~

a

~~~:a~;~~:ge

~---4 ... - - - -... End of Page 15

I

r---Fre_eL_ist

---:-._----JI

FreeNum

Key: Portion Of Free Storage

V// / //J

.... rL"'--~// .... _/ /;...0._ / / ... _ /'--U j Not Available For Allocation.

I I

l--- I

I

- +End of Page ,.

I I

I

I

I

End Of Page 13

End Of Nucleus Code

Figure 6. Example of free storage after second request

I

Q) Cl III til B

Q)

u... ~

I I I I

When a program returns a block of storage via FR ET, it is linked into the chain in its proper place, and FREELIST, FREE~T(JM, and the necessary pointer and size fields are appropriately updated as necessary. If the block returned abuts a free storage block

(either above, below, or both), they are combined into a single block with pointers, sizes, FR EE LIST, and FREENUM being appropriatelv adjusted as needed to maintain proper chain sequence and block sizes.

If there is not sufficient free storage available in the free storage area following the nucleus, pages are allocated by EXTEND and merged into the chain as needed, one at a time, from the end of the user program area, just below the loader tables. If a page (or more) of such storage is returned, this storage is also "given back". Care is taken by the storage management programs t~ ensure that any such storage allocated from the end of the user program area does not run into conflict with loaded programs, storage allo- cated by the GET MAIN procedure, COlVIMON area, and the like.

13

Freelist

First Block Allocated Second Block Allocated

Third Block Allocated

Fourth Block Allocated

Filth Biock Allocated

Remaining Free Storage in Page 14 Available For Allocation

_ Fnri Of P1I9f> 14

Size This Block

o

~---~---•• ~~---~4-EndOfPa~13

Freenum

Key: Portion Of Free Storage Currently In Use And Not Available For Allocation.

Figure 7. Example of free storage after five requests

CMS NUCLEUS

L..-_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

...J_

A key portion of the CMS nucleus, located near the beginning of Page 0, is the Nucleus Constant Area Table (NUCON). NUCON contains (1) several parameters used by the loading routines and storage management programs, (2) a table of device addresses, and

(3) a table of address constants giving the location of certain nucleus-resident CMS tables (for example, FVS, !ADT), and routines called via BALR instructions (for example, FREE & FRET). Some of the constants and parameters in NUCON, with their meaning and their usual values on a 256.K System/360, are as follows:

CORESIZ The size of core (computed at the beginning of a terminal session - for ex- ample, 40000 hex = 262144).

USFL User first location (12000 hex)

Freelist

First Block Allocated Second Block Allocated

Third Block Allocated

Fourth Block Allocated

Fifth Block Allocated

Remaining Free Storage in Page 14 -Available

For Aiiocation

Size This Block Pointer To Second Block

End Of Page 16

1

4 -End Of Page 14

~

I

I I I

t - - - f 4 -End Of Page 13

Freenum

L...-_ _ _ _ _ _ _ _ _ _ _ _ - - l + _ End Of Nucleus.-l Key: Portion Of Free Storage

Currently I n Use And Not Available For Allocation.

Figure 8. Free storage after second block has been returned

STADDR Address to start user execution (frequently 12000 hex) LDRTBL End of loader tables (40000 hex = 262144)

LOCCNI' Next core location to start (or resume) loading

Code

LOWEXT Lowest core address given out by EXTEND routine of the storage management programs (starts at 3E 000 hex)

HIMAIN Highest address given out by GETMAIN program

CONGEN An area used by the tvpe.writer routines (WAITRD, TYPLIN, CO NSI, etc.) for input and output areas, etc.

SYSREF Start of tables of address constants of certain CMS tables and routines.

15

To refer to NUCON and its contents, the CMSYSREF macro can be used. The CMSYSREF macro contains three main parts: Absolute, NUCON, and SYSREF. The Absolute sec- tion gives the displacenlents of absolute locations in page O. The NUCON part gives rel- ative displacements for the miscellaneous paranleters and device addresses. The SYSREF part of the CMSYSREF macro gives relative displacements of the address con- stants starting at SYSREF. In both the NUCON and SYSREF parts, the label of each parameter constant begins with D. For example, the label for the displacement of LOWEXT in NUCON is DLOWEXT.

Note that NUCON and SYSREF are always known locations to the CMS loading programs.

Thus, any disk resident program, by procedures outlined above using the CMSYSREF macro and the NUCON and SYSREF V-constants, can indirectly reference any quantities which are specified in the NUCON and SYSREF portions of the CMS Nucleus Constant Area.

For a complete list of the NUCON and SYSREF values, see the CMSYSREF macro as shown in Figures 9 and 10.

eMS DISK FILE ORGANIZATION AND MANAGEMENT

eMS files are stored on read-write and read-only disks. The CMS file management scheme uses various commands, functions, routines, and tables to structure and keep track of these files.

eMS handles up to six disks, one of which is the read-only System Disk ^(8-Disk), nor- mally having a device-address of 190. Up to five other disks can be active at any given time, each of them either read-write or read-only. Usually one of these is a read-write disk called the P-Disk or Primary disk (normally with a device-address of 191), on

which a user keeps his files, which are preserved by the CMS file system until they are purposely updated, erased, or replaced by the user or various command programs.

Each disk can be either a 2311 or 2314, from one to 203 cylinders. Other pertinent parameters for each disk are as follows:

• A 2311 holds a maximum of 8120 800-byte physical records

• A 2314 holds a maximum of 30,448 800-byte physical records

• Up to 3500 files may reside on a given disk

• Any given file can be as large as either 1. 16060 800-byte physical records

or

2. 65533 logical records (items)

The following pages describe the file management scheme used by CMS for files on read- write and read-only disks. For further information, see the sections "Disk .~ace Man- agement", "Active File Table (AFT) Management", and "Active Disk Table (ADT) Management' '.

2294 ^+* DISPLACEMENTS WITHIN ^{I I} NUCONSCT ^{I I} 2295H

OOOOlC 2296 +DCMSAREA EQU X ^I 1 C ^I

000300 2297+0CONSOLE EQU X¹300 '

000004 2298+DCORESIZ EQU X ^I 4^J

1"'\1"\1"\1"\,,-

UUUUI~ 2299+DERRINF EQU X I 1 C I

OOOODC 2300 +OH I MA I N EQU X'DC'

OOOOEO 2301+DIPLDEV EQU X'EO'

OOOOCC 2302+DLDAOOR EQU X'CC'

BSC CTF BASIC COMPILER EXECUTIVE PROGRAM

LOC OBJECT CODE ADDR1 ADDR2 STMT SOURCE STATEMENT

000014 2303+DLDRTBL EQU X' 14 '

0000C8 2304+DLOCCNT EQU X' C8'

000008 2305+DLOWEXT EQU X'DS'

0000C4 2306+DLSTADR EQU X' C4'

000000 2307 +0 L S T S V C EQU X'O '

0000lC 2308+DNRMINF EQU X'lC'

000318 2309+DPDISK EQU x¹318 '

000000 2310+DPSW EQU Xi DOi

00030C 2311+DSDISK EQU X' 30C '

000010 2312+0STADDR EQU X! 10 ^I

0000E2 2313+DSYSDEV EQU X ^I E2'

000018 2314+DTBLNG EQU X'18'

000324 2315+0TOISK EQU x'324'

000008 2316+DUSFL EQU X'S'

2317+*

Figure 9. Displacements from NUCON

Disk Management

Disk files are managed by a series of control blocks and tables. These blocks and tables are disk resident when the system is not in operation and, for the most part, main storage resident during a session. Because the blocks and tables are dynam- ically updated during the course of a session, an up-to-date copy of ~l].em is stored on the disk whenever necessary or requested. (The previous copy is deleted.) This is done to minimize the effect of a system malfunction.

File Management Tables on Disk

A description of each existing file is maintained in a file status table (FST) for that file.

The format of an FST entry is shown in Figure 11.

The file status tables for all files on the disk are grouped into a series of 800-byte disk records referred to as file status table blocks (FSTB). The file status table blocks are stored on the disk in available 800-byte recordse Each file status table block can ac- commodate up to 20 file status tables. Each of the file status table blocks is pointed to by an entry in the master file directory (MFD). The master file directory is the major file management table for disk. It is an 800-byte disk record located at a fixed point on the disk (cylinder 00, track 0, record 4). Figure 12 shows the format of the master file directory. Figure 13 shows the relationship of the master file directory, file status table blocks and file status tables.

17

2318+* DISPLACEMENT WITHIN "SYSREF ^I --- COMMUNICATION VECTOR REGION 2319+*

00009C 2320+DADTLKP EQU 156

000000 2321+DADTLKW EQU 192

000028 2322+DADTP EQU 40

00004C 2323+DADTS EQU 16

000040 2324+DADTT EQU 64

000050 2325+DBTVPLIN EQU 80

000004 2326+DBUFFER EQU 4

000008 2321+DCMSOP EQU 8

OOOOAC 2328+DCMSRET EQU 112

OOOOBC 2329+DCOM6UF EQU 188

oooooe 2330+DDEVTA8 EQU 12

000084 2331+DDIOSECT EQU 132

00007C 2332+DDMPEXEC EQU 124

000064 2333+00MPLIST EQU 100

000064 2334+DEXEC EQU 180

0000C8 2335+DEXISECT EQU 200

OOOOFO 2336+0FC6TAB EQU 240

000054 2331+DFRE06UF EOU 84

000068 2338+0FREE EOU 104

00006C 2339+0FRET EQU 108

000010 2340+OFSTLKP EQU 16

00001C 2341+DFSTLKW EQU 28

000000 2342+DFVS EOU 0

000014 2343+DGETCLK EOU 20

000018 2344+0GFLST EQU 24

OO(Hn^h 234SfC!ACT L.-.,u 3l;

000030 2346+OIOERRSP EQU 46

0000E8 2341+OIONTA6L EQU 232

00005C 2348+0LNKLST EQU 92

000090 2349+0MACLI 8L EQU 144

000094 2350+0MACSECT EOU 148

000080 2351+0NOTRKST EQU 116

000018 2352+0NUMTRKS EQU 120

000008 2353+00PSECT EOU 8

0000A8 2354+DOSRET EQU 168

000064 2355 +OOSYEC T EOU 100

000088 2356+DOSTA8LE EQU 136

000020 2357+0PIE EOU 32

8se CTF BASIC COMPILER EXECUTIVE PROGRAM

LOC OBJECT CODE ADDRl ADDR2 STMT SOURCE STATEMENT

00002e 2358+OPRTeLK EOU 44

000034 2359+0ROTK EQU 52

000038 2360+0SCAN EOU 56

000004 2361+0SCBPTR EQU 212

000010 2362+DSETCLK EQU 112

00003e 2363+0SSTAT EQU 60

000088 2364+0START EQU 184

0000A4 2365+0STATEXT EQU 164

000060 2366+0STR INIT EQU 96

000098 2367+0SYCSEeT EQU 152

000044 2368+0SWITeH EOU 68

OOOOEe 2369+OSYSeTL EQU 236

000048 2370+OTA8ENO EOU 12

ooooee 2371+0TBL2311 EOU 204

000000 2372+oT8L2314 EQU 208

000074 2373+0TXTLI8S EQU 116

OOOOAO 2374+DUPUFD EQU 160

0000e4 237S+OUSABRY EOU 196

000008 2376+DUSER 1 EOU 216

OOOODe 2371+OUSER2 EOU 220

OOOOEO 2318+DUSER3 EOU 224

OOOOE" 2379+0USER4 EOU 228

00008e 2380+0USyeTBL EOU 140

000058 2381+DWRTK EOU 88

Figure 10. Displacements of V-cons from SYSREF

~r

--4---+1

r-~ ______ ^~LE

I

8

FILE

1 - - - -

TYPE 16

DATE LAST WRITTEN

40 20

I

28

Write Pointer (Number of Item)

Filemode

Disk Address Of 1st Chain Link

122 Read Pointer I (Number Of Item) 126 Number Of

Items In File 30 F;x,d ¹31 Flag

Variable (1) Byte (2)

32 Item Length (F)

Max. Item Length (V) 36 Number of

L - 800-Byte Data Blocks i'limes on Date and Year:

(1) Date Last written is in packed decimal format MM DO HH MM e.g. 02 20 14 07 represents February 20, 2:07 p.m.

(2) Year is in character form e.g. C'69' for 1969 Figure 11. File status table entry

NI V I C . '"'-r ... · Year

(1) F = Fixed Length Items V = Variable Length Items (2) Flag BYTE: = a

19