DOCUMENT RESUME ED 082 490 EM 011 459 AUTHOR Brownlee, Edward H., Jr. TITLE PAMELA: An Interactive Assembler System for the IBM System/360 Computer. INSTITUTION North Carolina Univ., Chapel Hill. Dept. of Computer Science. PUB DATE 70 NOTE 82p.; Thesis submitted to the Department of Computer and Information Science of the University of North Carolina EDRS PRICE MF-$0.65 HC-$3.29 DESCRIPTORS Computer Based Laboratories; *Computer Programs; Computers; *Computer Science Education; Digital Computers; Interaction; *Man Machine Systems; Masters Theses; Program Descriptions; *Programing; Technical Reports IDENTIFIERS CC 30 Communications; CC 30 Terminal; CC 300 Screen; CC 303 Keyboard; IBM Model 40; IBM System 360; OS 360 Assembler Language; PAMELA; *Program Assembly Monitor Execution Learn Applicat; Station ABSTRACT A description of the Program Assembly and Monitored Execution for Learning App]'rations (PAMFL7) is presented. It is intended for instructors whc, propose to u.. the system and for programers who wish to modify it. PAMELA an interactiv.a system designed to teach the operating principles of the IBM System/360 digital coLputer at the machine language level. It runs on an IBM 360 Model 40, zommunicating with the user via a remote CC-30 Communications Station. The system can assemble and execute programs written in a subset of OS/360 Assembler Language. The source code can be entered from the CC-30 terminal, or from punched cards previously input. It can be edited by insertion, deletion or alteration of statements and instructions can be executed continuously or singly. Contents can he displayed on the CC-300 screen or modified from the CC-303 keyboard. Used in the classroom, PAMELA can provide illustrations of the primary functions o: instructions, as well as secondary effects such as setting of tho co,ndition code or raising of interrupts. Outside the classroom, the ;,;stem can serve as a laboratory facility, with which students test and debug their own programs or carry out exercises planned by the instructor. (Author) FILMED FROM BESTAVAILABLE COPY
Cr-
University of North Carolina atChapel Hill
1)Qp.,Ivt mellt litomput er mum 'informal. ionScict): 0 PAMELA: AN INTERACTIVE
ASSEMBLER SYSTEM FOR THE
IBM SYSTEM/360 COMPUTER
by
Edward H. Brownlee, Jr.
A thesis submitted to the faculty of the University of North Carolina at Chapel Hill in partial fulfillment of the requirements for the degree of Master of Science in the Department of CompuLer and Information Science
Chapel Hill.
1970
by:
( Adviser ACKNOWLEDGEMENTS
The author is indebted to Dr. Peter Calingaert for his invaluable assistance and suggestions in the preparation u this thesis; to
Ur. Gerald A Fisher, Jr.,for providing a classroom test enviionment for the system; and to William H. Blair and Gary D. Schultz for their wise counsel on many matters of technology ill
CONTENTS
I. INTRODUCTION .
II. USER'S MANUAL ...... 3
III. SUGGESTIONS FOR USE ...... 30
IV PROGRAM LOGIC ...... 36
V. TESTING PERFORMED ...... 45
VI. MODIFYING THE SYSTEM ...... , 52
APPENDIX A -- OS Interfaces and Feature Instructions 63
APPENDIX B -- Differences Between PAMELA and OSA 65
APPENDIX C I/O Caveats 69
APPENDIX D -- System Messages . 71
APPENDIX E Summary of System Commands ...... 75
APPENDIX F -- Abbreviations Used 77
APPENDIX G -- Program Listings (Separate Cover)
LIST OF REFERENCES . 2 ..4 ... 0 ...... 79 I INTRODUCTION
PAMELA (Program Assembly and Monitored Execution for Learning
Applications) is an interactive system designed for use as a tool in teaching the principles of ()petition of the IBM System/360 digital computer at the machine7,,latiguage level: It runs, itself, on an IBM 360
Model 40, communicating with the user via a remote CC-30 Communications
Station, manufactured by Computer Communications, Inc
The system is capable of assembling and executing programs written in a subset of OS/360 Assembler Language. The source code can be entered directly from the CC-30 terminal, or by means of punched cards pre- viously submitted to the host computer and called up from the terminal
It can later be edited by insertion, deletion, or alteration of state- ments Instructions can be executed continuously, halting only at preset locations or in case of error; or they can be executed one by one, halting after each instruction until a signal from the terminal is received. The contents of core storage, registers, and program status word can be displayed on tht. CC-300 TV screen or modified from the CC-303 keyboard; displayed information will be automatically up- dated whenever instruction execution is halted
Used in the classroom, the system can provide dynamic illustrations of the primary functions of instructions, as well as secondary effects such as setting of tht cr.adition code or raising of interrupts Outside the classroom, the system can be used as a laboratory facility, with which students test and debug their own programs, or carry out exercises planned by the instructor
The description of PAMELA presented in this paper is intended for the instructor who proposes to use the system or the programmer who wishes to expand or oCierwise modify its capabilities. Some prior knowledge of OS/360 is assumed; Operating System terminology and ab- breviations have been used freely. Appendix F contains an exhaustive
list of these abbreviations. USER'S MANUAL
In this chapter I have explained how to invoke PAMELA, establish communication with the system, and use all of the available facilities,
1 THE CC-30 TERMINAL
The instrument through which the user communicates with the PAMELA system is the CC-30 Communications Station The basic station con- figuration consists of a CC-301 TV Display Controller, CC-300 TV
Display, and CC-303 Alphanumeric Keyboard. These are the only comr. ponents necessary for using PAMELA; additional TV monitors and the
CC-304 Light Pen are helpful for classroom use (see Chapter III), but are not required
The CC-301 Controller consists of a buffer memory, a character generator, and an input/output section, Data is read from or written to the memory via a telephone line, coupled to the devices by an
IBM 2701 Data Adapter at the computer site and an acoustic coupler at the remote terminal, The data transfer rate achieved with this con- figuration is approximately 10 characters per second
The data in the buffer is scanned 60 times per second, converted to dot patterns by the character generator, and written on the TV display screen as humanly readable characters, Up to 800 characters
(20 lines of 40 characters each) can be displayed in this way. 4
By means of the alphanumeric keyboard, which is similar to an ordinary typewriter keyboard but contains several additional control keys, data can be keyed directly into the buffer memory from the terminal, and subsequently transmitted to the computer. Two way com- munication between system and user is thus established
For a more detailed description of the CC-30, consult Ref. 1.
2 INVOKING THE SYSTEM
I will now describe the procedures to be followed in activating the PAMELA system and establishing communication between the system and the CC-30 terminal. These procedure:; are necessarily dependent upon the computing facility and operating system being used, and the particulars are applicable only to the configuration on which the sys- tem was written (see Chapter VI).
2 1 JOB CONTROL
PAMELA is invoked by means of job control statements in the OS job stream Refer to the sample JCL of Fig. 2.1.
The JOB statement initiates the job and specifies accounting in-
;ormation, and must be present for every job- The TYPRUNisHOLD param- eter in this statement specifies that the job is not to be run until released by the computer operator. It is coded in order that the job may be read into the system well in advance of the proposed time of use, thus avoiding delay when the system is needed
The JOBLIB DD statement names the partitioned data set on which
PAMELA's load module resides. It must be present for every job unless
PAMELA has been placed in the OS link library, 5
//JOBNAME JOB (UNCCS.S7123,2),'BROWNLEE E H',CLASS=G,TYPRUN=HOLD
//JOBLIB DD DSNAME=UNC.CS.S7123.BROWNLEE.PAMELA,DISP=SHR
// EXEC PGM=PAMELA10
//CC30 DD UNIT=TWX
//SOURCE DD UNIT=2314,SPACE=(TRK,10),DCB=(DSORG=DA,RECFM=F)
//SYSUDUMP DD SYSOUT=A
//PROG1 DD *
data . .
/*
//PROG2 DD *
data
/*
Fig,2 1 -- JCL for Invocation of PAMELA 6
The EXEC statement specifies the member name of the particular
load module which is the PAMELA system, and causes the system to be
loaded into core and tc begin executing. It must be present for every
job.
The CC30 DD statement defines the TWX line data set for the CC-30
terminal, and must be present for every job.
The SOURCE DD statement defines the disk data set on which the
source file is to reside. It must be present for every job- In this
example, ten tracks of space have been requested, sufficient for some- what over 500 records
The SYSUDUMP DD statement defines the data set on which is
to be written in the event of abnormal termination of the: system- This
statement is never mandatory, but is always advisable, since without it an abnormal termination may be very difficult to diagnose-
The remaining DD cards define card data sets which may be refer- enced from the CC-30 terminal at execution time. The cards may con-
tain assembler language source statements or data to be read by the user's GET statements. Any number of card data sets may be included with a job; none is required. Any valid DD names (see Ref. 3) may be used; the ones shown in the example have no special significance.
When it is desired to initiate the system (assuming TYPRUN=HOLD was specified), have the operator release the job invoking the system,
If system initialization is successful, the message "PAMELA WAITING
FOR CALL" will be written at the console. The Data Adapter is then
ready to receive a call. 7
2 2 ESTABLISHING CONNECTION WITH THE TERMINAL
For a ,..omplete discussion of the details of the wiring and operation of the CC-30 terminal, consult Ref- 1 The instructions given here are those which apply to the PAMELA system in particular-
Insure that the alphanumeric keyboard, acoustic coupler, and
(optionally) light pen are plugged into the appropriate receptacles on the CC-301 controller- Both video and sync cables of the CC-300 TV
Display should be connected to the corresponding "TV" receptacles on the controller- Video and sync cables for other monitors to be used
(if any) should be connected to the corresponding "MON" receptacles.
The sync selector switches on the back panel of all monitors to be used should be in the down (external sync) position, No CC-30 components other than those mentioned above need be connected
Insure that the mode switches on the front of the controller are in the BLOCK, NORMAL, ALPHA, and READ positions (these are the down positions of all four switches)
Apply power to the controller, coupler, and TV monitors. Press the
CLEAR and MASTER CLEAR keys on the alphanumeric keyboard.
Press the INT key. to lock the keyboard; this conditions the control- ler to receive a transmission from the computer. Dial the number of the computer's data adapter, and when the carrier tone is heard, press the receiver firmly into the acoustic coupler.
The salutation "PAMELA" is written in the upper left corner of the screen The cursor is placed in the command area, the keyboard unlocks, and the system enters the command mode (see Sec, 4). Sign-on is now complete 8
3. CC-300 TV SCREE.,; LAYOUT
The user communicates with the system by means of commandsentered through the CC-303 keyboa::d. The system replies to the user with mes- sages displayed on the CC-300 display screen. It is important to dis- tinguish between these system command'. and messages and the assembler instructions and error messages, which appear in the source file(see
Sec 7).
For purposes of the PAMELA system, the display screen shouldbe imagined as partitioned into three areas (see Fig.2.2). The top two lines on the screen are the message__ areu. Here, and only here, the system displays error and other messages in reply tocommands entered by the user. The bottom two lines on the screen are the input area.
Here, and only here, the system reads commands, source statements,and updating information. The sixteen lines between the message area and
Message Area
Display Area
Input Area
Fig. 2.2 -- Screen Layout input area constitute the display area. Here, and only here, the sys-
tem displays the contents of core storage, general purpose registers,
floating point registers, and the program status word, as requested by
thc. user. Much freedom is allowed the user in planning the format of
the display area, in that each new display is placed on tLe line which
he requests.
It should be emphasized that the input area is the only portion
of the screen from which the system caa read information entered from
the CC-303 keyboard. It is possible, and at times may be convenient,
to key information into other portions of the screen for notational
purposes. Such information will, however, be completely ignored by
the system.
4. SYSTEM MODES
Depending upon the type of operation being performed, the PAMELA
system may be in either of two modes: command. mode or repeat mode.
Commands from the terminal will be recognized only when the system is
in the command mode, In repeat mode, the command last recognized is
executed repeatedly, once each time the INT key is pressed. New com- mands cannot be issued with the system in repeat mode. The repeat
mode is entered only when one of the commands XEQ1, NPUT, or DERR is
issued, To return from repeat mode to command mode, press the follow-
ing keys in order: RESET, 4,TRANS.
5 COMMAND FORMAT
All commands in the PAMELA system must be entered in the lower
right quarter of the input area, i.e., the last twenty spaces on the
bottom line of the CC-300 screen, The cursor is automatically placed 10 in the correct position for entering commands whenever the system is in command mode and is ready to accept a command. Should you disturb the position of the cursor, it can be replaced at the beginning of the com- mand field by pressing RESET,<---,TAB.
All commands have the following general format:
One or Zero or more operands Operation more separated by commas X-OFF blanks
Fig 2-3 -- Command Format
Note that no blanks are permitted between the beginning of the first and the end of the last operand, nor before the operation field, The
.X-OFF. character is formed by pressing the S key while holding down the SP-CODE key It is not mandatory, but if it is omitted the en- tire command field following the end of the last operand must be blank
Use of the X-OFF character also shortens transmission time.
After entering a command in the correct field, press INT. The com- mand will be read and, if no errors are detected, will be executed.
6- OPEl'AND TYPES
The opera%Us required for a command depend upon the operation being performed, but will always be selected from four basic formats:
1) a decimal integer
2) a hexadecimal integer
3) a decimal number
4) a symbcl
Each format is described in detail below 11
A decimal integer is an ordinary one- or two-digit whole number in the range 0-15 No sign, decimal point, nor leading zero is permitted.
The decimal integer operand form is used only to refer to registers or vo a quantity of lines in the display area.
Examples of valid decimal integers:
0
12
Examples of invalid decimal integers:
16 (not in range 0-15)
+4 (sign not permitted)
Hexadecimal integers consist of from one to six hexadecimal digits in the range 0-9 or A-F, enclosed in parentheses, and optionally fol- lowed immediately by the letter R. Hexadecimal integer operands are used only to refer to core storage locations. If the optional 'R'is coded, it specifies an address relative to location zero on the assem- bler listing most recently produced. Otherwise, an absolute machine address is specified If no assembly has been performed, an R is ig- nored
Examples of valid hexadecimal integers:
(02A800)
(11F1)
(30A)R
Examples of invalid hexadecimal integers:
(23H8) (contains invalid hexadecimal digit)
(104) R (space appears between parenthesis and R)
Decimal numbers consist of from one to three decimal digits in the range 0-9, optionally followed by a decimal point and from zero to 12 three additional digits A decimal number operand may refer to an assembler language statement number, to a statement number increment, or to the quantity of statements referenced, depending upon the com- mand in which it is used and its position therein.
Examples of valid decimal numbers:
24
019.8
169 444
Examples of invalid decimal numbers:
+16.1 (sign not permitted)
1.4800 (only 3 digits after decimal permitted)
Symbols consist of from one to eight alphabetic (A-2.,$,#,@) and numeric (0-9) characters, the first of which must be alphabetic. A symbol operand may refer to a label in an assembler language statement or to a card file DD name, depending upon the command in which it is used and its position therein.
Examples of valid symbols:
E2484
#7
PAMELA
Examples of invalid symbols:
8E5F (does not begin with alphabetic)
C23456789 (more than 8 characters)
YO-Y0 (contains character ocher than alphabetic
or numeric) 13
7 SOURCE STATEMENT FORMAT
The PAMELA system includes the facilities for storing and updating a large number of assembler language ("so-a=ce") statements in random
access disk storage The source statements used in the system have
basically the same format as those for the OS/3u° assembler, Each is
normally contain,7...fl in the first 71 character positions of an 80-
character source record (a record or card image is the disk storage
equivalent of a single punched card). Column 72 is the continuation
column, and should contain a blank unless a statement is to be continued
on the next record. Columns 73-80 (used for a statement number under
OS/360) must always be blank. If they are not blank when read in, the
system input reader will make them blank.
In addition to the regular 80-character card image, the system in-
put reader affixes a 40-character prefix to each record at the time it
is placed on the disk file Before the program is assembled this pre-
fix contains only the statement number written in its last seven posi-
tions. After assembly the prefix may contain, in addition, an error
message or the location counter and object code for the statement.
Whereas the 80-character card image portion of statements can be al-
tered at will from the terminal, the 40-character prefix cannot be al-
tered except by the system assembler.
8 INDIVIDUAL COMMAND DESCRIPTIONS
Armed with the foregoing general information, we are now prepared
to discuss the individual commands available. There are 22 commands
in all, and these are divided into six classes: 14
1) source handling commands
2) display storage commands
3) alter storage commands
6) assembler commands
5) execution commands
6) special purpose commands.
Refer to Appendix E for a tabular supplement to the discussion which follows
8 1 SOURCE HANDLING COMMANDS
The source handling commands are NPUT, DEL, DSRS, ASRS, DSRL, and
ASRL They are used to read in, display, alter, or delete the assem- bler language statements making up a program.
The In (NPUT) Command
This is the command used to read new source statements into the system Statements can be read either from the CC-30 terminal or from a card file previously submitted f.o the host computer.
SYNTAX The input command is written as follows:
NPUTdecimal-number-or-ormbol,decimal-number, symbol
The first operand is required; the remaining two are optional. If the second operand is omitted but the first and third are coded, two commas must separate the operands coded.
SEMANTICS- The system immediately enters the repeat mode. If the third operand is present, the card file having the specified symbol as its DD name is opened and the entire file is read into the system mem- ory- The system then returns to the command mode. If the third oper- 15 and is omitted, the cursor will be placed at the beginning of the input area. Statements may then be keyed in from the CC-303 keyboard.Key in a statement and press INT The statement will be read and the cur- sor positioned once again to enter the next statement. When all the desired statements have been entered, press RESET, ,TRANS to return to command mode
Regardless of whether card or keyboard input is used, the first operand becomes the statement number of the first statement read, and the second operand is the increment added to this to obtEin succeed- ing statement numbers If the second operand is omitted, an increment
of 1 is assumed,. For numbering purposes, a statement continued on sev- eral records counts as a single statement.
Note that new statements are always collated into their correct sequential positions in the system memory. If the number of a new statement matches that of an old statement exactly, the new statement replaces the old, If the number falls between two old statements, the new statement is inserted. Thus, judiciously chosen operands can make the NPUT statement a powerful editing facility.
Examples:
NPUT 1
(reads from the CC-30. Statement numbers will be
NPUT 3,0.1
(reads from the CC-30. Statement numbers will be
3.0,3.1,3.2, ..) 16
NPUT 5PROG1
(reads cards whose DD name is PROGI. Statement
numbers will be 5,6,7, ..)
The Delete (DEL) Command
This command is used to delete source statements from the system memory
SYNTAX The delete command is written as follows:
DEL decimal-number-or-symbol,decimal-number
The second operand is optional; the first is required if the second is coded, but is optional otherwise
SEMAN1ICS The system will delete from the memory the number of state- ments specified by the second operand, Any fractional part of this op- erand will be ignored. The first statement deleted will be the one whose number or label is the first operand, If the second operand is omitted but the first is coded, only the single statement named will be deleted If both operands are omitted, the entire file will be de- leted
If a statement which is continued over several records is deleted, all records included in the statement are deleted. If an assembler
LTORG or END statement is deleted, any literals inserted by the assem- bler following the statement will also be deleted-
Examples:
DEL 3,7
(deletes seven statements beginning with the one
numbered 3) 17
DEL 5 5
(deletes statement 5.5)
DEL
(deletes entire source file)
The RiEllax Source Commands (DSRS and DSRL)
These commands are used to display source statements.
SYNTAX The display source commands are written as follows:
DSRS decimal- number -or- symbol, decimal- number
or DSRL decimal-number-or-symbol,decimal-number
The first operand is required; the second is optional.
SEMANTICS. The number of statements specified by the second operand is displayed on the CC-300 TV screen, beginning with the statement whose number or label is the first operand. If the second operand is omitted, only one statement will be displayed. Immediately after the command is issued, the keyboard will unlock. Use the cursor control keys to position the cursor to the line in the display area where you wish the display to begin Then press INT. If INT is pressed without placing the cursor in the display area, the system will select the lowermost blank line which is directly under a non-blank line (note that only main storage displays writtenbythe system are considered to constitute non-blank lines). If no such line exists, the message
"PLACE CURSOR" will be written in the message area, at which time the user must place the cursor in the display area and press INT.
If DSRL (Display SouRce Long) is coded, each statement displayed requires three 40-character lines of the display area, plus two addi- 18
tional lines for each continuation record; the prefix and all the text of each statement are displayed. All literals inserted by the assem- bler after a LTORG or END statement are displayed along with the state- ment they follow, and do not count towards the number of statements
requested If DSRS (Display SouRce Short) is coded, only the first 40 characters of each statement are displayed, except for the first record, whose prefix is displayed, also Continuations and literals are not displayed Thus each statement, except the first, requires only one line on the CC-300 screen.
Examples:
DSRS 18.5,6
(displays six statements beginning with statement
number 18.5, in short form)
DSRLNAME1
(displays the statement labeled WAME1 in long form)
The Alter Source Commands (ASRS and ASRL)
These commands are used to modify source statements.
SYNTAX. The alter source commands are written as follows:
ASRS decimal-number-or-symbel,decimal-number
or ASRL decimal-number-or-fsymbol,decimal-number
The first operand is required;.the second is optional
SEMANTICS, The number of statements specified by the second operand will be displayed, one by one, in the input area, beginning with the statement whose number or label is the first operand. If the second operand is omitted, only one statement will be displayed. Immediately after each statement is displayed, transmission will halt and the key- 19 board will unlock. At this point use the cursor control and other keys to alter the displayed statement in any desired way. Then press INT.
The revised statement will replace the old one in memory
If ASRL (Alter SouRce Long) is coded, all the text of each state- ment is presented for rl eration, with both lines of the input area being used. If a statement is continued on more than one record, the continuations are presented after the first record and do rot count towards the number of statements requested. Literals generated by the assembler are not presented for alteration- If ASRS (Alter SouRce
Short) is coded, only the first 40 characters of each statement are pre- sented, with only the bottom line of the input area being used Con- tinuations are not displayed
Note that it is not possible to alter the prefix of any record, since the prefixes are not presented for alteration by ASRS nor ASRL.
Note also that unlike alteration of main storage (see Sec,8 3), alter- ation of source statements does not result in an updating of. infor- mation currently appearing in the display area.
Examples:
ASRS 10.67
(statement 10.67 is presented for alteration in
the short form)
ASRL X,2
(two statements, beginning with the one labeled
X, are presented for alteration in the long form) 20
8.2 DISPLAY STORAGE COMMANDS
The display storage commands are DCOR, DGPR, DFPR, DPSW, and CLR.
They are used to examine the contents of core storage, registers, and the program status word in the user's program. All displays created using display storage commands are updated by the system whenever the corresponding storage contents change. After a display storage command is issued, the keyboard will unlock. Select a line for the display as described in Sec. 8.1
The Display Core (DCOR) Command
SYNTAX. The display core command is written as follows:
DCORhexadecimal-integer-or-symbol
The operand is mandatory.
SEMANTICS. The hexadecimal contents of 8 bytes of core storage, be- ginning at the location specified, are displayed on the CC-300 screen.
Examples:
DCORSAVEAREA
(displays 8 bytes beginning with the storage
location labeled SAVEAREA)
DCOR (3E4)R
(displays 8 bytes beginning with the byte whose
assembler listing; location is 3E4)
DCOR (2A800)
(displays 8 bytes beginning with machine location
2A800) 21
The Display General Purpose Register (DGPR) Command
SYNTAX. The display general purpose register command is written as
follows:
DGPRdecimal-integer-or-symbol
or DGPRdecimal-integer-or-symbol,decimal-integer-or-symbol
At least 'one operand is mandatory.
SEMANTICS The 4-byte hexadecimal contents of the register or registers specified are displayed on the CC-300 screen
Examples:
DGPR 14
&displays register 14)
DGPR4,ANYREG
(displays register 4 and the one wbjch has been
equated to the symbol ANYREG)
The Display Floating Point Register (DFPR) Command
SYNTAX. The display floating point register command is written as follows:
DFPRdecimal-integer-or-symbol
The operand is mandatory. Note that the only valid FPR specifications are 0, 2, 4, and 6.
SEMANTICS. The 8-byte hexadecimal contents of the floating point reg- ister specified are 2isplayed on the CC-300 screen; the exponent and fraction parts are shown separated by a period (.).
Example:
DFPR 6 22
The Display Program Status Word (DPSW) Command
SYNTAX. The display program status word command is writt,... as follows:
DPSW
SEMANTICS. The 8-bite program status word is displayed on the CC-300 screen This display provides the following information: the current interruption code, instruction-length code, condition code, program mask, and instruction address.
The Clear (CLR) Command
SYNTAX. The clear command is written as follows:
CLR decimal- integer
The operand is optional
SEMANTICS. As pointed out earlier, any information displayed using display storage commands will be updated by the system whenever the corresponding storage contents change. Should you no longer require a particular display, the only way to remove it permanently from the screen (without the CLR command) would be to overwrite it with a dif- ferent display
The clear command allows you to erase a display from the screen permanently When this command is issued with an operand, the keyboard unlocks just as for other display commands. Position the cursor on the line you wish to erase and press INT. The line is overwritten with blanks, and the system is notified not to update the line any longer.
Additional lines are selected in the same way, one by one, until the number of displays specified by the operand have been erased. 23
If CLR is issued without operand, the entire screen (all three screen areas) will be cleared, and the system will immediately return to command mode
Note that since source statement displays are not updated by the system (they are "written and forgotten") you can erase such displays directly, simply by keying blanks over the displays from the CC-303 keyboard You ran, of course, use the CLR command if you prefer.
8 3 THE ALTER STORAGE COMMANDS
The alter storage commands are 4 AGPR, AFPR, and APSW. They are used to alter the contents of cc.,-': storage, registers, and the pro- gram status word.
SYNTAX The operand requirements of these instructions (i.e., the number, type, and interpretation thereof) are exactly tie same as those of the corresponding display storage commands, DCOR, DGPR, DFPR, and
OPSW
SEMANTICS. The current contents of the specified storage are written in the upper left quarter of the input area. They keyboard is then un- locked Use the cursor control-and other keys to alter the hexadecimal display in any desired way- However, take care to:
1) enter only valid hexadecimal digits in the range 0-9 or
A-F Otherwise the input will be rejected and the alter-
ation will not take place.
2) avoid disturbing the format of the displayed storage con-
tents; i.e , do not replace non-blanks by blanks nor blanks
by non-blanks. Failure to observe this rule will result
in unpredictable alterations to the storage. 24
3) avoid erasing the X-OFF character which is always written
at the end of a storage display presented for alteration.
Otherwise transmission time may be greatly increased.
After making the desired changes, press INT. The revised hexadecimal number will replace the old contents of the specified storage.
The system will honor all requests to display or alter storage except :
1) requests referencing core locations outside the area of
the most recently assembled program; or
2) requests to alter any of the high-order 34 bits of the PSW.
Thus only the condition code, program mask, and instruction
address are subject to direct alteration.
8.4 ASSEMBLY COMMANDS
Once a program has been entered into the system memory, using the
NPUT and other source handling commands, it must be assembled before it can he executed The PAMELA system includes a simple assembler for this purpose, capable of assembling a fairly generous subset of OS/360 assembler language (a summary of the restrictions defining this subset is given in Appendix B). The commands used to control assembly are
ASM and DERR.
The Assemble (ASM) Command
SYNTPX, The assemble command is written as follows:
ASM SEMANTICS, The assembler is invoked. A table of symbols is built which contains the label of each valid source statement assembled. 25
These symbols can subsequently be used as operands of system commands, when applicable. Core for the assembled program is allocated and the program is loaded into core. If any errors are detected, a message is placed in the prefix of each offending statement, and the message
"ERRORS IN ASSEMBLY" is written in the message area of the CC-300 screen. If no error is detected in a statement, the location of the generated code aid the hexadecimal code produced are placed in the prefix instead of an error message.
The DisElay Errors (DERR) Command
Thi: command may be used to examine the error messages placed in the prefixes of source statements by the assembler.
SYNTAX- The DERR command is written as follows:
DERR
SEMANTICS The system immediately enters the repeat mode. The disk file is then scanned fcr a source statement which contains an error message in its prefix. When one is found, the prefix and the first
40 characters of its text are displayed in the message area of the
CC 300 screen. The system then waits for the signal to scan for the next error (INT). or to return to command mode (RESET,
When there are no more erroneous statements the message "END OF
ASSEMBLY ERRORS" will be written in the message area.
You may return to the command mode after any error display (to al- ter the erroneous source statement, for example) and then re-issue
DERR at a later time; the scan for errors will continue where it left off. However, once the entire source file has been scanned (i.e., the 26
END OF ASSEMBLY ERRORS message has appeared), DERR cannot be used to scan the file again until another assembly has been performed.
Note that assembler error messages can also be examined using the
DSRL command. The DERR command merely offers the convenience of sorting out the statements which contain error messages.
8 5 EXECUTION COMMANDS
Once a program has been entered and assembled without error, it can be executed from the CC-30 terminal using the three execution com- mands, XEQ, XEQ1, and STOP,
The Execute LxEg.) Command
SYNTAX- The execute command is written as follows:
XEQ hexadecimal-integer-or-symbol-or-decimal-number
The operand is optional,
SEMANTICS. Control is passed to the point in the program whose core location, label, or statement number is the operand of the command.
If the symbol or decimal number form is used, the statement referenced must be a valid executable assembler language instruction. If the op- erand is omitted, control is passed to the instruction address specified by the current PSW.
Execution of instructions takes place continuously and without any visible indication at the terminal. Execution will halt only when one of the following conditions is satisfied:
1) a program interruption occurs;
2) a "STOP" is encountered (see STOP command, this section)
3) 1000 machine instructions have been executed; 77
4) an end-of-data condition is recognized on a user input
file
When execution is halted for any of these reasons a message ex- plaining the situation is written in the message area of the TV screen
(the third condition above results in the message "PROGRAM APPARENTLY
IN LOOP"). All storage displays on the screen are then updated.
Examples:
XEQ (E6)R
(execution begins at the statement whose location
on the assembler listing is 0000E6)
XEQ
(execution is begun at the instruction address speci-
fied by the current PSW)
The Execute Single Instruction (XEQ1) Command
SYNTAX, The execute single instruction command is written as follows:
XEQ1 hexadecimal-integer-or-symbol-or-decimal-number
The operand is optional
SEMANTICS If an operand is present, the address specified immediately replaces the instruction address in the PSW; if not, the PSW remains unchanged The system then enters the repeat mode and waits for fur- ther signals from the terminal. Each time INT is pressed, the single instruction then indicated by the instruction address in the PSW is executed and all storage displays on the screen are updated.
Execution can continue in this manner indefinitely. If a "STOP" is encountered, a message to that effect is displayed but otherwise it 28 is ignored. If a program interruption occurs a message is displayed and the operation is suppressed in the same manner as if continuous execution had been taking place (see Ref. 4). The system then stands ready to attempt to execute the next instruction. To cease executing, return to command mode in the usual way,
Example:
XEQ1 COMPUTE
(the system makes ready to execute the instruction
whose label is COMPUTE)
The Stop (STOP) Command
SYNTAX. The stop command is written as follows:
STOP hexadecimal-integer-or-symbol-or-decimal-number
The operand is optional.
SEMANTICS, The location specified by the operand is flagged as a stop location, If the instruction address becomes equal to a stop location following an XEQ command, execution is immediately halted (i.e., before executing the instruction at which the stop was set. Exception: if a stop is set at the first instruction specified by an XEQ command, it is ignored) Up to four stops may be set by is,Juing several STOP com- mands with different operands, and these remain in effect until a STOP command with no operands is issued, at which time all are eliminated
(it is not possible to eliminate stops selectively). If more stops are entered after the fourth, the excess stops are dropped, beginning with the oldest; the most recent ones remain in effect,
Example: 29
STOP 14
(A STOP is set at statement number 14)
8 6 SPECIAL PURPOSE COMMANDS
The End (END) Command
SYNTAX. The End command is written as follows:
END
SEMANTICS. The END command should be the last one issued in a PAMELA session The message "PAMELA TERMINATING" is written in the message
field of the CC-33C screen. The telephone line is thea disconnected and the system terminates.
The ---Translate (XLAT) Command SYNTAX. The translate command is written as follows:
XLAT hexadecimal-integer-or-symbol
The operand is mandatory.
SEMANTICS. The EBCDIC character representations of 80 bytes of core, beginning at the location specified by the operand, are written into the message area of the CC-300 screen Characters which have no EBCDIC encoding in the CC-30 character set appear on the screen as the "CAN" character (II) Displays created using the translate command are not updated if the contents of core change.
Example:
XLAT BUFFER
(displays 80 bytes beginning with the storage
location labeled BUFFER) III. SUGGESTIONS FOR USE
In Chapter II I described in detail the facilities of the PAMELA system and how these may be invoked. In this section I will make sug- gestions for achieving optimal efficiency in the use of the system for several applications.
The system is intended for use in either of two modes: as an ersatz lab for testing, debugging, and experimenting with assembler- language programs (student-controlled mode), or as a classroom tool for illustrating the execution of System/360 machine instructions (teacher- controlled mode).
1. TEACHER-CONTROLLED MODE
As a classroom tool, PAMELA can be used to illustrate a variety of
System/360 functions, such as
1) the alteration of the registers and main core by machine
instructions;
2) setting of the PSW instruction address by branch instruc-
tions;
3) setting of the condition code bits in the PSW by arithmetic
and logical instructions and by the SPM instruction;
4) setting of the instruction length code bits in the PSW by
all instructions;
5) halting of execution and setting of the PSW interrupt code
by program interruptions; 31
6) suppression of program interruptions by appropriate program
mask settings;
7) action of elementary 1/0 macros.
When you plan to use PAELA in the classroom, prepare the illus- trations beforehand and run them on the system once before class, when- ever possible Try to anticipate questions which are likely to be asked, and devise and test illustrations answering them. Following this procedure will insure that the examples are correctly constructed and that any system bugs uncovered by the examples will be revealed prior to the class.
Entering source statements from the CC-30 keyboard is an extremely slow process and should be avoided except when very brief alterations or insertions must be made. Instead, punch the source programs on cards and submit them to the computer center as explained in Chapter
II. Note that any number of programs can be submitted in this way and accessed in a single session. By appropriate use of the NPUT command, code sequences can even be concatenated or merged. For example, if you submit two decks with DD names PROG1 and INSERT, each consisting of 20 statements, the command sequence NPUT 1PROG1
NPUT4.01,0.01,INSERT will result in a source file containing 40 statements, Those of INSERT will be placed between the fourth and fifth statements of PROG1, and will be numbered 4.01, 4.02,..., 4.20. Any valid PAMELA commands could have been executed between the two NPUT commands, operating only upon the statements in TROG1. 32
On a low-speed line, such as the one on which the system was de- veloped, considerable time is required for transmissions from computer
to terminal: about four seconds per line, or more than a minute to
fill the entire display area. Therefore, if lengthy displays (e.g.,
an assembler listing) are to be produced in class, the lecture should be planned so as to fill the periods of transmission. If very long
source code listings are desired, or if many other displays are desired
in conjunction with a source code listing, it is probably wise tJ pre-
sent the source code on paper by some conventional means.
If the CC-30 terminal used includes a CC-304 Light Pen, this de- vice can be used as a pointer to call attention to a particular area
of the CC-300 screen. At any time while the keyboard is unlocked (the blue light is on), a character detected by the light pen will appear marked by a flickering background on all connected monitors.To re- place the marker elsewhere, detect another character; to remove the marker entirely, press MASTER RESET on the CC-303 keyboard. (Note:
do not press MASTER RESET while the terminal is sending or receiving a transmission from the computer. To do so may result in lost data, a system "hang-up", or other catastrophe.)
Some students have complained that the marker renders the marked character difficult to read. It is advisable, therefore, to erase the marker promptly after it has been placed, or else to mark a field by an unimportant character (such as a leading zero, in the case of a nu- meric field) 33
Z. STUDENT-CONTROLLED MODE
I envision two possible uses of the system in the student-controlled mode. One is to have each student or team of students carry out a planned exercise prepared by the instructor. The other possibility is to make the system available to the student as a test and debug facili- ty for his own assembler language programs.
A planned exercise has the advantage that the student need not learn the details of system operation; he can be instructed which system com- mands to use at each step. This method also allows the instructor more contvol over what material the students learn during a session.
If, on the other hand, the student is given complete control of his session (unplanned exercise), he can tailor the study to his indi- vidual ability and interest. Of course, this alternative also makes less demand on the instructor's time.
ff unplanned exercises are to be used, caution the student against the inefficiency of entering source statements from the terminal, men- tioned earlier in this chapter. Discourage particularly his attempt- ing to compose a program at the terminal. I have found that this pro- cedure, while tempting in an interactive environment, is difficult and frustrating when coding any but the most trivial programs in assembler language. IV. PROGRAM LOGIC
The PAMELA system consists of five basic components:
1) the Executive
2) the I/O Interface
3) the Assembler
4) the Display and Alteration Facility (DAF)
5) the Execution Monitor.
Here follows a general description of each of these components. Refer to the overlay diagram (Fig. 4.1) to see the relationship between the various modules.
1 THE EXECUTIVE
The Executive is a single, permanently resident module (EXEC) which initiates and oversees all system activities, and is the entry point of the PAMELA system. It is responsible for system initialization, interpretation of the "operation" portion of commands, and the display of most error messages. Also in this module are data fields which must remain resident in core, notably the symbol table and the System
Control Block (SYSCB). Some part of the SYSCB is used by almost every component of the system, so this data field merits some special dis- cussion.
First come the user's sixteen pseudo-registers. Then his instruc- tion address, absolute assembler listing origin, and his condition code and other pseudo-PSW information. The next two words, LBOUND and EXEC Executive DREAD CCREAD I/O Interface XEQMON ExecutionMonitor EXPRVAL Assembler DSOURCE PASS1 PASS2 DISPLAY DAF DCPROC 1 DCGEN Fig. 4 1 -- Overlay Structure UBOUND, define the limits of the user's core storage. lie may not ref-
erence any location outside these limits. After these come the 88 bytes used for the display of error messages; almost all messages from
peripheral routines are returr2d in this field. Then we h..:vc the three
addresses used in symbol table maintenance. The first point: to the
beginning of the table, the third points to the end of tne available
space, and the second points to the last entry placed in the table by
the most recent assembly, i.e., the last active entry. Next come the
four "stop" fields, which are f.-;t by the STOP command Finally we
have the screen table, where a three-word record is kept of each main storage display currently in the display area.
2. THE I/O INTERFACE
The 1/0 Interface consists of two permanently resident modules
(DREAD and CCREAD) responsible for the details of all input and out- put for the system, with the exception of reading card files, which is done by the standard OS QSAR routines called in DSOURCE.
DREAD is a streamlined, specialized adaptation of IBM's Indexed
Sequential Access Method (ISAR) used in maintaining the disk source
file. It performs all buffer maintenance, key search, and collating of records, using a core-resident key table much like the "master
index" of OS ISAR. The actual transfer of data to and from the disk
is done by calling the OS BDAM and (for initial dummy records) BsAn
routines.
The advantages of using this specialized routine instead of ISA:: are: 37
1) It is not necessary to issue SETL and ESETL macros to re-
position the file; repositioning is performed automati-
cally when a specific record (as opposed to the next
sequential record) is referenced.
2) OS ISAM requires the use of two different access methods
(QISAM or BISAM) depending upon whether a record is to be
inserted within the file or added to the end. DREAD allows
records to be written anywhere in the file using the same
DCB and read/write macros.
3) My, initial experiments with ISAM had to be cut short due
to excessive computer time consumption; DREAD performs all
the services which I require at about ten times the speed.
These advantages are apparently realized because of the sacrifice of generality in DREAD.
CCREAD is the CC-30 terminal I/O interface. It is capable of read- ing from or writing to any specified locations on the CC-300 screen, and also of writing to the line where the user places the cursor and reporting where that line was. It also contains routines for enabling and disabling the TWX line, error recovery, and translation between
EBCDIC and the backwards-ASCII-with-parity code of the CC -30-
With the exception of the initial connection, which is done via a
BTAM "READ", all CC-30 I/O is done using the EXCP I/O technique; the
requisite channel programs are coded explicitly in CCREAD. This af-
fords two important advantages:
1) The Program-Controlled Interruption (PCI) facility pro-
vides elegant means for issuing the HALT-I/0 instruction 38
required after a "Read Cursor Address Register" command
to the CC-30. This is a very awkward task if BTAM is used
exclusively.
2) The BTAM disconnect function aborts consistently when used
with the CC-30. The simple "Disable" channel command which
I issue has always completed successfully.
3. THE ASSEMBLER
The Assembler is a collection of five modules (PASS1, DCPROC, PASS2,
DCGEN, and EXPRVAL) which perform the translation of a users program from assembler language to machine code. It consists of two passes; the first overlays all the other nonresident modules, and the second in turn overlays the first.
PASS1 is the main routine for the first pass. It builds the sym- bol table, interprets all opcodes, allocates space for all constants, and constructs the literal table statements. Any core storage reserved for a previously assembled program is freed. Intermediate text, in- cluding some error messages, is generated and placed in the source file prefixes to be used by PASS2.
DCPROC is a subroutine used only by PASS1. It determines the length attribute, alignment, and total storage requirements for each constant encountered, whether as a literal or as the operand of a DC or DS statement. To a limited extent, it checks for formatting errors.
Finally, in the case of address constants, it determines certain char- acteristics which must be known to allow assembly of the constant as a literal 39
PASS2, the main routine for the second pass, interprets the oper- ands of all machine statements; performs base register functions, in- cluding the execution of USING and DROP statements; and outputs object code directly into core obtained by a GETMAIN macro. It completes the object code listing appearing in the prefix of each statement, or plac- es error messages in the prefixes of erroneous statements not flagged in the first pass All records which were flagged by PASS1 are com- pletely ignored by PASS2
The actual generation of constants is performed by DCGEN whenever
PASS2 encounters a DC statement or a literal statement generated by
PASS1 In generating S-constants, DCGEN utilizes the base-displacement facilities of the main routine, via the entry point BASEDISP Other- wise the module is self-contained.
EXPRVAL evaluates expressions of the type used as operands in as- sembler language statements. BecauSe it is used in both passes, it must appear above PASS1 and PASS2 in the overlay structure, even though logically it is a subroutine of these modules.
3.1 INSTRUCTION SET
The PAMELA Assembler recognizes the mnemonic operation codes of all
OS/360 machine instructions, including privileged operations, floating point instructions, and decimal instructions. One additional special- purpose instruction has been included in the set recognized by PAMELA: the BLUB (Branch and Link UnBridled) instruction.
The machine language format of the BLUR instruction is shown in
Fig. 4.2. It performs exactly the same function as BALR, except that 40
013
R1 I
Fig. 42 -- BLUB Instruction
the Execution Monitor relinquishes control of processing, and the re-
turn address placed in will l be a location in PAMELA rather than the
address of the instruction following the BLUB. Most safeguards against
program interruptions, infinite loops, destruction of PAMELA's resident
modules, etc , are lifted. BLUP is intended for branching to system
subroutines (as in G1T and PUT macros) or for performing diagnostic
checks of *he system from the terminal Naturally, it should be used with discretion
3.2 MACRO-INSTRUCTIONS
Only five system macro instructions are recognized by the Assembler:
OPEN, CLOSE, GET, PUT, and DCB. User macro definitions are not sup-
ported
All macros are expanded as if "PRINT NOGEN" were in effect, i.e., only the object code is generated and not the corresponding source
statements Format requirements for the macros are quite rigid (see
Appendix B).
In the case of the DCB macro, minimal error checking is performed, with all operands ignored completely except MACRF and DDNAME. Default
values are assigned to all other operands, and no checks for agreement
with the user's operands are performed
OPEN and CLOSE macros are expanded exactly as under OS, subject to
the extra restrictions mentioned in Appendix B. 41
GET and PUT macros produce, under OS, a BALR to the system Get/Put
routines- In order that PAMELA may relinquish control to these system
subroutines, the PAMELA Assembler gene:ates, instead, a BLUB instruc-
tion, described above The return address passed to the subroutines
is the location in the Execution Monitor from which PAMELA resumes
control. Otherwise the expansions are identical to those of OS-
4 THE DISPLAY AND ALTERATION FACILITY
Two routines (DSOURCE and DISPLAY) are responsible for producing
the displays and performing the alterations requested by the user.
They (along with XEQMON) overlay t.Ine Assembler when called into core.
DISPLAY is the display and alteration manager for main storage: core, registers, the PSW, and stops. It is callec when either 1) the user issues a command whose operand explicitly or implicitly refers to main storage; or 2) the Execution Monitor returns control to the Exec- utive. In the latter case, DISPLAY serves to update any displays of storage changed by the user's code.
The module has three entry points. Entry point DISPLAY is used after a DCOR, DGPR, DFPR, CLR, or XLAT command, to indicate that no alteration to the user's main storage is to be made. Entry point ALTER is used following an ACOR, AGPR, AFPR, APSW, or STOP command, or after an XEQ or XEQ1 command with operand. For these entry points, an op- tion code is passed in register 0 to indicate which command is in ef- fect Finally, CHECK is the entry point used upon return from the
Execution Monitor; each main storage display is checked against the corresponding screen entry in the SYSCB to insure it is current. Those which are not are updated, 42
Most of DISPLAY consists of routines to interpret the four types of operands for the display and alteration commands, build the three- word screen entries showing what data is displayed on each CC-300 line, and generate the actual displays to be transmitted to the terminal.
There are also brief sequences which make alterations to core, regis- ters, the PSW, and the stops.
DSOURCE performs roughly the same functions for secondary storage on the disk file as does DISPLAY for main storage. It is galled fol- lowing a DSRS, DSRL, ASRS, ASRL, NPUT, or DEL command, and is respon- sible for displaying, altering, adding to, or deleting from the disk file (as in OS ISAM, deletion is accomplished by simply flagging the record with X'FF' in the first byte).
The bulk of the code in DSOURCE is concerned with interpreting the symbol or statement number operands which may appear with the source handling commands, constructing displays and transmitting them to the terminal, and building the prefixes which are affixed to input records.
The DCB ased for reading from a card file is in the DREAD module, so that it may be permanently resident and hence available for use by the
Assembler as a skeleton in expanding the DCB macro.
5 THE EXECUTION MONITOR
The raison dlgtre of the system, for which the remaining modules are but servants, is the Execution Monitor, which executes the user's code while protecting him against abnorma: terminations due to pro- gram exceptions, infinite loops, or destruction of PAMELA's resident modules. Tire single control section, XEQMON (along with the DAP), overlays the Assembler when called into core, 43
XEQMON is entered follcwing an XEQ or XEQ1 command, though the
DISPLAY module may be called first to interpret the operand, if there is one The cycle of execution is then as follows:
1) Move a copy of the user's current instruction, as specified by
the pseudo-PSW, into a special field of tne Monitor. Update
the pseudo-PSW (Note: All the user's pseudo-storage is in
thu SYSCB.)
2) Examine the opcode and core addresses referenced, if any, and
insure that the instruction does not reference any location
outside the user's area of core; if it does, raise a pseudo-
protection interrupt.
3) Insure that the instruction is not a BC, BCR, BAL, BALR, BCT,
BCTR, BXLE, BXH, or EX, as these instructions could cause
PAMELA to lose control. If it is one of these instructions,
perform an iv' rpretive pseudo-operation and go to step 7.
4) Insure that the instruction will not befoul PAMELA's "recovery"
base register (see step 6) Either register 4 or 8 can be used;
if the user instruction alters both register 4 and register 8
(only the LM instruction can do this) perform an interpretive
pseudo-operation and go to step 7-
5) If the instruction is innocuous by all the above criteria, load
all registers and the condition code from the user's pseudo-
storage and allow execution of the copy of the user's instruc-
tion
6) Recover from the demolition of PAMELA's registers wrought in
step 5: replace the user's new registers and condition code in 44
his pseudo-storage, and re-estabi;.':', the Execution Monitor's
base registers.
7) Count one user instruction as havilg been executed. If the
count passed to XEQMON in register 0 has been reached (this
count will be 1 if XEQ1 was specified), or if a stop has been
set at the current instruction address, return to the Executive.
Otherwise, go to step 1.
Except for those errors checked for in steps 2, 3, and 4, any kind
of program interrupt may occur when the user's instruction is executed
in step 5. If an interrupt does occur, OS passes control to PAMELA's
interruption handler, EXERR (an entry point of XEQMON), as specified
by the SPIE macro issued by the Executive during system initialization.
EXERR determines the type of interrupt which occurred, sets the inter-
rupt code in the pseudo-PSW, and returns control to the Executive with
an error message indicating the interrupt type.
The only known way that user code can terminate the system abnor- mally is for an error to occur after the Execution Monitor has relin-
quished control, i.e., after an SVC or BLUB instruction. V. TESTING PERFORMED
All system testing discussed in this chapter has been performed on line, iu the hardware environment described in Chapter VI. Though the tests were not all performed during the same terminal session, PAMELA was in each session run in the 44K "Graphics" partition,_ other tasks being concurrently active in the multiprogramming environment.
I have listed in separate paragraphs the tests aimed at the various components of the system. In fact, of course, all tests were performed on the system as a whole, and a particular test in general required action by several components.
1. EXECUTIVE
Each of the 23 commands in PAMELA's repertoire has been issued and correctly interpreted. Invalid commands, including some containing too many characters and some not properly positioned in the field, have resulted in the appropriate error message. The error display facilities have correctly displayed 20, 40, and 60 character error messages returned from peripheral routines. The assembly error scan- ning routine has performed correctly with both erroneous and 2rror- free assemblies; the scan has been successfully halted and re- started.
2, DISPLAY AND ALTERATION FACILITY
Each of the 6 source handling commands has been successfully exe- cuted, with all valid combinations of omitted and specified operands /46 tested for each command. Operands tested have included examples of both the statement number and symbol formats. Extensive source input has been accomplished both from card decks and from the terminal
Omission of operands has produced the appropriate error message for those commands requiring operands (extra operands are ignored by
DSOURCE) Nonexistent labels, statement numbers, and DD names have been entered as operands and have produced the appropriate messages.
Several arbitrary invalid operands were tried in both operand formats and produced the appropriate message.
An NPUT command causing statement number overflow has been tried and correctly flagged. An input source deck was read which contained more than 16 consecutive continuation cards; input was halted and the appropriate message generated
Each of the 11 main storage display and alteration commands has been successfully executed with all valid combinations of specified and omitted operands tested for each command, All four operand formats have been correctly interpreted.
All four types of main storage display have been correctly created, and have been updated following both alter-storage and execution com- mands The XLAT command has correctly translated codes belonging to the CC-30 chracter set, and has produced the "CAN" character in place of other codes, as intended. More than four STOP commands were issued without an interveningnull STOP command, and the excess stops were dropped beginning with the oldest, as intended.
Omission of operands has produced the appropriate error message for those commands requiring operands (extra operands are ignored by 47
DISPLAY). Nonexistent labels and statement numbers have been entered as operands and have produced the appropriate error messages. Several invalid operands were tried in all four operand formats and as input to min storage alLeration commands, and produced the appropriate mes- sage Attempts were made to reference core locations outside the pro- gram area and to modify the 34 high-order bits of the PSW; in each case the target was properly protected.
3. ASSEMBLER
Each of the 160 System/360 instructions bearing mnemonic operation codes (the Diagnose instruction does not) has been submitted with ap- propriate operands to PAMELA's assembler, and has been assembled cor- rectly, in the sense that the object code was the same as that produced by the OS assembler, This includes the extended mnemonics for the BC and BCR instructions. Operands were specified with both explicit and implied lengths, explicit and implied base registers, and expressions of maximum allowable complexity, as set forth in Appendix B
Each of the assembler instructions honored by PAMELA hay been is- sued and correctly executed. In the case of CNOP, operands have been included requiring the generation of one, two, and three NOPR instruc- tions In the case of the DC and DS instructions, each of the 12 con- stant types recognized by PAMELA has been correctly generated, with both explicit and implied lengths, and with multiple suboperands where applicable Several different replication factors, including zero, were correctly applied.
Each of the 5 I/O macros recognized by PAMELA has been issued and correctly expanded, in the sense that the generated code has success- 8 fully performed input and output functions, including recognition of and end-of-data condition.
The following assembler language errors were submitted to the as- sembler and correctly identified:
- Symbols beginning with a numeric character, or consisting of
more than eight characters, or containing an illegal character;
An unlabeled EQU instruction;
- Labeled CkqOP, END, and ORG instructions;
- Literals longer than 61 characters;
- More than one consecutive continuation card, or a continuation
card with non-blanks in columns 1-15;
- Undefined or missing opcodes;
- Statements following the END card;
- Statements which reserve core storage preceding a START state-
ment, or more than one START statement in a single program;
- Missing and extra operands with both machine instructions and
assembler instructions;
- Duplicate or undefined labels;
- Constant definitions (both in DC statements and as literals)
specifying invalid types, invalid lengths, excessive magnitudes,
invalid data, and extra or omitted suboperands;
- Constant definitions with missing parentheses or quote marks;
- CCB instructions with invalid or missing MACRF or DDNAME speci-
fications;
- An absolute expression as the operand of an ORG instruction;
- Relocatable expressions as the operands of START and DROP; 49
Expressions containing consecutive operators, invalid self-
defintrg terms, undefined operators, and operators as the final
chara ters;
- Expressions containing two levelsof parentheses;
- Expressions containing a literal inconjunction with other oper-
tnds;
- Expressions consistingof the sum of two .elocatable terms, or
containing a * or / operation applied to a relocatable term; 24 - Expressions having avalue greater than 2 - 1;
- Relocatable expressions used asregister, length, displacement,
or immediate data specifications;
- Register, length, displacement, orimmediate data specifications
outside permissible range;
- A DROP instruction referencing aregister not in use;
- An unaddressable expression used asthe second operand of an RX
instruction;
- Literals appearing twice in a singleinstruction, or as the des-
tination.field of an instruction which alters core storage;
- Alignment errors on double-word,full-word, and half-word instruc-
tions;
- OPEN and CLOSE instructions withinvalid option specifications;
- Programs causing overflow of thesymbol table, literal table, or
core storage pool.
4 I/O INTERFACE
Each of the functions of CCREAD has been performed successfully: connecting and disconnecting of the TWX line, reading from a specified 50 area of the CC-30 memory, waiting for an interrupt from the terminal, writing to a program-specified screen location, and writing to a loca- tion designated from the terminal. In the last case, both manual and default placement of the cursor have been accomplished, with the ap- propriate message being generated when default placement is requested but is not applicable
CC-30 I/O errors, presumably due to normal line noise, have occurred in the course of testing, and in every case recovery has been success- fully accomplished.
Each of the functions of DREAD has been performed successfully: creation and expansion of the source file; reading of records, both sequentially and randomly; and writing of records at the end of the file (concatenating), between two existing records (inserting), and in place of existing records (updating). Deleted records (bearing the
X'FF' flag in the first byte) have been ignored, as intended.
The end-of-data conditicn has always been correctly raised by re- turning a code of 4 in register 15.
By varying the SPACE parameter of the SOURCE DD card, I have on different occasions caused both the physical disk space and the index space allocation to be exc^.eded. In each case the system terminated abnormally with a completion code of 12, as intended.
5. EXECUTION MONITOR
Each of the 11 machine instructions which are performed interpre- tively by the execution monitor, and at least one instruction having each of the five basic instruction formats (RR, RX, RS, SI, and SS), has been successfully executed. Successful execution means that all main storage (including the fields ofthe PSW) was correctly set fol-
lowing execution of the instructions.
Execution has been halted and the appropriatemessage displayed by each of the 15 types of program interruptions, encountering :1
"step" set 'y the user, exhaustionof the instruction rofult passed in register 0, and an end-of-data conditionon a user input file VI, MODIFYING THE SYSTEM
The comments of this chapter are intended to serve as guidelines in the implementation of future modifications or extensions to the system. Known quantitative limitations on various system features are also described.
1 DIAGNOSTIC FACILITIES
To aid in the testiug of modifications made to the system (and in the elimination of bugs which may turn up in the present system), two diagnostic facilities have been incorporated into PAMELA. They are the BLUB instruction and the BOMB command.
The BLUB instruction, described in Chapter IV, Sec. 3.1, was orig- inally intended as a device to allow the execution monitor to relin- quish control to Operating System subroutines, such as GET and PUT.
It was later discovered that through judicious use of the instruction, certain protective restrictions imposed by PAMELA could be permanently removed, thus allowing the powerful storage display and alteration fa- cilities to be used on the system itself. For example, one could com- pose a program from the terminal which would reset the upper and lower program area boundaries in the SYSCB to X'FFFFFF' and V000000', re- spectively, and branch to this routine via a BLUB. After the routine executed and returned control to PAMELA, the DCOR and ACOR commands could be used to examine core contents anywhere in the partition: the 53 save area for PAMELA's registers, for instance. This technique was in fact used on a number of occasions in debugging the system.
The BOMB command is a special system command which is issued just as any other command, but was not mentioned in Chapter II because it is not intended for general u: a. It takes no operand. When issued, it causes the message "PAMELA TERMINATING" to be written in the message area, after which the system terminates abnormally with a completion code of 16. If a SYSUDUM2 DD card was included with the job, a dump will be produced, which can then be used for debugging
2. THE SOURCE FILE
The number of records which can be stored on the disk source file is limited by two factors: the volume of disk storage available, and the amount of core allocated for the index.
The 120-byte source records are blocked into units of 14 records each. Each track allocated to the data set, assuming an IBM 2314 disk drive, will hold four such blocks; thus one cylinder is sufficient for 1120 source records. The SPACE parameter of the //SOURCE DD card for a given run should request at least N/56 tracks, where N is the largest number of records which will occupy the main source file at any one time during the run. Considerable margin (perhaps 20%) above this minimal figure should be allowed if the file may be modified from the terminal, as the space occupied by records deleted during use may under certain conditions remain temporarily unavailable.
Each block of records requires an 8-byte entry in the INDEX, an area of main core located in DREAD. In the present system, space for 54
50 index entries has been provided; this is sufficient to maintain 700 source records. To change this capacity, simply make the replication fa, -tor of the INDEX field equal to the number of blocks desired.
'f either the disk space or index space requirements exceed that which i3 available during a run, PAMELA terminates abnormally with a completion code of 12.
3. THE SYMBOL TABLE
The symbol table, created by the Assembler and occupying an area of core in EXEC, contains a 16-byte ..Intry for each symbol or literal appearing in an assembly, In the present system, space for 50 such entries is provided in the field labeled SYMTBL. Overfloi: of this table results in immediate termination of the current assembly: the system does not ABEND. To change tke capacity of the symbol table, increase or decrease the size of the SYMT1.L field by four full words for each entry space to be added or deleted.
A desirable sophistication would be to have core for the symbol table allocated dynamically at assembly time. However, I ran think of no way to accomplish this which does not involve cumbers-y-e (i.e., chained) table search techniques, additional auxiliary storage, or a third assembler pass. A much simpler alternative would be to add a special system command which would allow the user to specify the size of the symbol table from the terminal if the default size were unsuit- able. A GETMAIN would be issued and the appropriate addresses stored in the SYSCB. 55
4. LITERALS
Another assembler limitation is upon the total length, in charac-
ters, of literal constant definitions occurring between successive
LTORG statements, or between the last LTORG and the END statement.
Literal definitions are stored in the LITTBL field in PASS1 until a
LTORG or END statement causes them to be dumped into the source file,
at which time LITTBL is re-initialized. Literals stored in the literal
table require one byte for each character in the definition, excluding
the initial '='. Thus, fcr example, the literals
=E'10 5'
= 5PL4'6'
=C'&&ABCDEF' would require a total of 7+7+11=25 bytes in the literal table. In the
present system, 256 bytes are provided. If the table overflows, the
current assembly is terminated immediately, but the system does not
ABEND. To change the capacity of the literal table, alter the length modifier of the LITTBL DS statement
In addition to the above limitation on the combined length of lit-
erals, the length of a single literal definition, excluding the initial
'=', may not exceed 61 characters. If this restriction is violated,
the statement containing the literal is flagged, but assembly contin-
ues. The purpose of the restriction is to insure that the assembler-
generated literal statements following a LTORG or END instruction
will each fit on only one record, in columns 10-71. To remove the
restriction, add a sequence to the LTORG statement handler in PASS1 56 allowing it to generate continuation cards, and remove the test for
literal length performed in the literal processing (LTPROC) section.
5. HARDWARE AND SUPEUISOR SERVICES
PAMELA was designed to run on an IBM 360/40 computer, under the
control of OS/360 with MFT-II, Release 16. The system instruction set should inclode both the decimal and floating point feature instructions.
The protection feature is not necessary, as it is partially simulated by PAMELA. Approximately 23K of core is required for the system, in-
cluding all overhead but excluding space for the user's object program and buffers.
The I/O facilities used are:
1) an IBM 2314 Direct Access Storage Facility;
2) an IBM 2540 Card Reader/Punch;
3) an IBM 2701 Telegraph Adapter, Type II (TX);
4) a Computer Communications CC-30 Communications Station,
basic configuration, specially modified for TPX compati-
bility.
I have not attempted to run PAMELA with any other computer, oper- ating system, or I/O configuration, so I cannot state with authority
exactly what changes would have to be made in order to do so. However,
I will now suggest trouble spots which are likely to arise when at-
tempting to implement PAMELA in a different environment, based upon my
knowledge of the environment-sensitive aspects of the system. 57
5 1 SYSTEMS WITHOUT FLOATING POINT OR DECIMAL FEATURE
The floating point feature instructions are required only in ti'e
execution of system commands referencing the floating point registers,
(DFPR and AFPR) and in the generation of floating point constants dur-
ing assemblies. In the absence of the floating point feature these
two services are meaningless anyhow, and the code performing them
should simply be removed. Appendix A includes a tabulation showing the
location of each occurrence of floating point instructions.
Lack of the decimal feature is a more serious problem. Decimal
instructions are used in such diverse activities as numbering source
statements, interpreting constant definitions in assemblies, and for- matting displays (see Appendix A). Decimal arithmetic functions will
have to be replaced by binary arithmetic followed by conversions. For- matting will have to be made less sophisticated than that afforded by
the ED instruction (e,g., suppression of leading zeros), or else code
mimicking the functions of ED will have to be written.
5.2 SYSTEMS WITH INSUFFICIENT CORE STORAGE
By current standards the core storage requirement of PAMELA is
quite modest, and will not present a problem on most IBM/360 models
unless very large user programs are to be run. Indeed, the system was
wr.tten with compactness in mind, and if core storage should become
a problem I can offer but few suggestions for reducing the require-
ments significantly. Such suggestions as I do make will be concerned
with reducing the size of tables and buffers, rather than executed
code. 58
The bulkiest parts of the system other than the executed code are, in order of decreasing size:
1) the two disk I/O buffers in DREAD (3360 bytes combined);
2) the error messages in PASS1 and PASS2 (1276 bytes combined);
3) the symbol table in EXEC (800 bytes)
Two buffers are required in DREAD in order to avoid an unreasonable amount of reading and writing during insert operations. Each is 1680 bytes long, accommodating one block of 14 records each 120 bytes long.
The size of the buffers could be reduced by decreasing the blocking
factor of the source file. This can be achieved simply by reducinp the value of the BLKF symbol as defined in an EOU statement in DREAD and re-assembling the module. The buffers lengths and all other blocksize-dependent values, such as the BLKSIZE operand of the DCB's, are expressed in terms of BLKF and will be adjusted automatically.
Naturally, such a reduction would result in slower I/O operation and decreased space utilization efficiency on the disk.
The size of the error message tables in the assembler suggests placing all error messages in a third assembler pass and identifying errors in the first two- passes by means of a single number, say. The
third pass could overlay the first two, thus requiring no additional core, and could substitute an actual message for the corresponding num- bers. Note that since PASS1 and PASS2 overlay each other already, this procedure will not result in a savings of a full 1276 bytes; in fact
the amount saved will be equal to the length of the larger of the ta-
bles in PASSI and PASS2 (roughly half of 1276). 59
I have explained earlier how the size of the symbol table can be reduced by decreasing the possible number of entries. It would be de- sirable to reduce the size of each entry below the present 16 bytes: but I don't believe this is possible without eliminating some of the services (e.g., recognition of statements by label) which use the table.
5 3 OTHER OPERATING SYSTEMS
Running PAMELA under operating systems other than OS/360 Release
16 may require sweeping changes in I/O segments, but otherwise should present few problems- Moreover, almost all I/O functions have been carefully relegated to those modules whose sole responsibility is the handling of I/O details, i e., DREAD and CCREAD- The only exceptions are the macros in DSOURCE which are used in reading source code from cards. Thus, only these three modules need be modified in order to run PAMELA under different I/O supervision. On the other hand, if the user is to be permitted to perform I/O functions in his object pro- grams, it may be necessary to modify the macro-expanding portions of
PAMELA's Assembler, or else require the user to expand his own macros as ordinary machine instructions.
There is one particular modification that may well have to be made even when running under OS Release 16, at installations other than the one on which PAMELA was developed. The convention here is to "spool" card files onto temporary disk storage at the time a job is entered into the system. Such files are blocked 5 cards (400 bytes) to a block. Since this is a purely local convention, it will quite likely 60 be necessary to change the BLKSIZE parameter of the card DCB (CRDCB) in DREAD for operating at any ocher installation
Aside from I/O, the only interfaces with the Operating System are through the Overlay Supervisor, and the following macros: GETMAIN (Ger.
Main. Storage), FREEMAIN (Free Main Storage), ABEND (Abnormal End), and
SPIE (Specify Program Interruption Exit).
I will make no attempt to discuss in greater detail the substitu- tions which will be necessary to run PAMELA under particular operating systems, To aid in such an endeavor, however, Appendix A includes an exhaustive tabulation of all PAMELA/OS interfaces (system macros) and their locations in the source listings,
5.4 OTHER I/O HARDWARE
With the exception of the channel programs 4-or the 2701 /CC-30 in
CCREAD, all I/O in PAMELA is done by standard OS access methods.Thus it should be device - independent in an OS environment and I foresee no difficulties in using PAMELA with other card readers, such as the IBM
2501, or other disk drives, such as the IBM 2311. Note, however, that if a 2311 disk drive is used, optimal space utilization may require some experimenting with the source file blocking factor.
Operating with a terminal other than the CC-30 or through a data adapter other than the IBM 2701 will probably require sweeping changes in the CCREAD module, because the device-dependent EXCP ac,ess method is used. In addition, a few CC-30 i..incrol character manipulations
take place in modules other than CCREAD; all such occurrences are
listed in Appendix A. 61
Note also that a specially modified CC-30 terminal is required: the X-OFF character must be added to the controller's character set in order to make the terminal TWX-compatible This modification will be made by the manufacturer if requested.
5.i MULTIPLE TERMINALS
The PAMELA system has not been written for use with more than one terminal connected simultaneously. Moreover, I have done little in- vestigating of the possibility. I will only state that all the system modules, with the exception of the root segment (EXEC, DREAD, and
CCREAD), are serially reusable but not re-entrant. EXEC is not seri- ally reusable because it contains the SYSCB and symbol table. DREAD contains the disk buffers, index, and a few pointers which must remain unaltered from one invocation to the next, as well as several DCB's.
CCREAD contains the DCB for the CC-30.
6. A SAVE FACILITY
It would be desirable to allow a user to save a disk source file for later use, once he has debugged a program or example. He can, in
fact, do this now by specifying a permanent data set in the //SOURCE
DD statement and signing off the system when his source file is satis-
factory. However, he cannot in the same session cause a file to be
saved and then continue with another problem.
One way to achieve this latter capability would be ro implement a new system command which, when issued, would close the current source
file and open a new one, defined by a different DD statement, whose name could be specified by the operand of the command, The new DDNAME 62
would replace the old one in thesource file DCB's, as is done for
card files now. The number of different files which couldbe saved
would then be limited only by the number of DDstatements defining
source data sets for the job.
A (less cumbersome) variationon this would be to provide a com- mand which causes the currentsource file to be printed or punched.
After the command is executed, the file could becleared and re-used
in the usual manner. APPENDIX A
OS Interfaces and
Special Feature Instructions
In this appendix I have tabulated the occurrences of PAMELA/OS
interfaces and special feature instructions, as an aid to implementing
PAMELA on another comput'r or operating system. Entries in this list
have the following format! XXXX nn (YYYY), where XXXX is the module
name, nn the page number in the assembler listing of the module (see
Appendix G), and YYYY the particular instruction being cited, if any.
Direct Modifications of System Control Blocks:
CCREAD 7 CCREAD 9 DSOURCE 8
PASS2 16 PASS2 17
CC-30 Control Character Manipulations (other than in CCREAD):
DISPLAY 6 DISPLAY 9
Occurrences of Decimal Feature Instructions:
DISPLAY 5 (ED) DISPLAY 5(ED) DCPROC 1 (ZAP)
DCGEN 2 (ZAP) DSOURCE 3 (ZAP) DSOURCE 8 (AP)
DSOURCE 8 (ED)
Occurrences of Floating Point Feature Instructions:
DISPLAY 9(LD) DISPLAY 12 (STD) DCGEN 10 (LD)
DCGEN 10 (LD) DCGEN 10 (MDR) DCGEN 10 (MDR) 64
DCGEN 10 (SUR) DCGEN 11(ED) DCGLN 11 mit)
DCGEN 11 (ADR) DCGEN 11 (DD) DCGEN 11(LNDR)
DCGEN 11(STD)
Occurrences of System Macros;
CCREAD 6 (CLOSE) CCREAD 7 (EXCP) CCREAD 7 (WAITR)
CCREAD 7(ABEND) CCREAD 9 (OPEN) CCREAD 9 (RFAD)
CCREAD 9 (ABEND) CCREAD 9 (WTO) CCREAD 10 (WAITR)
CCREAD 14 (DCB) CCREAD 14 (DFTRMLST) PASS2 2 ((.;ET11AIN1
PASS2 2(SPIE) PASS2 22 (SPIEL DREAD 4 (CLOSE)
DREAD 4 (OPEN) DREAD 4 (WRITE) DREAD 5 (CHECK)
DREAD 5(CLOSE) DREAD 5 (OPEN) DREAD 7 (READ)
DREAD 7(READ) DREAD 7 (WRITE) DREAD 7 (WRITE)
DREAD 7(CHECK) DREAD 8 (READ) DREAD 8 (READ)
DREAD 9 (ABEND) DREAD 10 (DCB) DREAD 11 (DCB)
DREAD 12 (DCB) EXEC 1(SPIE) EXEC 5 (ABEND)
DSOURCE 8 (OPEN) DSOURCE 8 (GET) DSOURCE 10 (CLOSE)
DSOURCE 12 (CLOSE) PASS) 2 (FREEMAIN) APPENDIX B
Differences Between PAMELA and
OS Assembler Languages
The PAMELA Assembler is faster and requires much less core and secondary storage than the OS Assembler for a given assembler lan- guage program. These advantages are realized at the cost of some gen- erality. Here I have listed all the known differences between PAMELA assembler language and OS assembler language (F-level) (see Ref. 2).
Although the list appears lengthy, I claim that most of the omitted features are not likely to be needed in a program written by a begin- ning student of OSA, nor in an illustrative program for such a student.
Only five system macro instructions are recognized by the assem- bler: OPEN, CLOSE, GET, PUT, and DCB. User-written macro definitions are not supported. For the five system macros, the operand formats are more restricted than under OSA, as noted below.
All macro instructions must be written in the "normal" format
(adopting the terminology of Ref. 2). The "alternate" format, wherein blanks and/or comments may follow any operand of a macro-instruction which is to be continued on a subsequent card, is not permitted.
The OPEN and CLOSE macros must be written as follows:
OPEN (expression,(INPUT))
or OPEN (expression,(OUTPUT))
or OPEN (expression) (INPUT is assumed) 66
CLOSE (expression)
In particular, note that all parentheses are required, that the regis-
ter form of specification (as CLOSE ((2)) ) is not permitted, that only tht INPUT or OUTPUT option is permitted in OPEN, and that only one DCB may be opened or closed by each macro-instruction,
The GET and PUT macros must be written as follows:
GET expression,expression
PUT expression,expression
In particular, note that the register form of specification is not permitted, and that both expressions are required (i.e., only the
"move" form of the macros may be used).
In the DCB macro, all operands are completely ignored except MACRF and DDNAME. Both of these operands are required, but may appear any- where in the operand field. DDNAME is written just as in OSA. MACRF must be coded as follows:
MACRF=(GM) (for an input data set)
or MACRF=(PM) .(for an output data set)
Except for these two operands, default values are assumed for all
DCB fields, and the user's specifications, if any, are not checked for agreement. The default values are as follows:
On Input: DSORG=PS,RECFM=FB,BLKSIZE=400,LRECL=80
On Output: DSORC=PS,RECFM=FA,BLKSIZE=133
An end-of-data condition on an input file always results in halted ex-
ecution and a message on the CC-30 screen. The user must then direct
further processing through the-use -of system commands. 67
Since all programs assembled by the PAMELA assembler are self- contained and are loaded directly into core, the following OS external reference facilities are not provided:
1) The instructions CSECT, DSECT, EXTRN, ENTRY, CXD, DXD, and
COM.
2) V- and Q-constants.
The following macro language and conditional assembler facilities are not supported:
1) The instructions ACTR, AGO, AIF, ANOP, GBLA, GBLB, GBLC,
LCLA, LCLB, LCLC, MACRO, MEND, MEXIT, MNOTE, SETA, SETB,
and SETC
2) Symbolic parameters and the system variables &SYSNDX,
&SYSECT, and &SYSLIST.
The following assembly formatting instructions are not supported:
EJECT, ICTL, ISEQ, PRINT, PUNCH, REPRO, SPACE, TITLE.
The CCW and COPY assembler instructions are not supported.
Only the length attribute, 1,', may be used in expressions. The type, scaling, integer, count, and number attributes are not supported.
Only one continuation card is permitted for any statement, includ- ing macro-instructions.
At most three terms and one level of parentheses may be used in expressions- Complex relocatability is not supported, since there are no external symbols. No attributes other than the length attribute are supported.
The following facilities for the definition of constants as literals or as operands of DC and DS statements are not supported: 68
1) V- and Q-constants.
2) Exponent and scale modifiers. Length modifiers must be
unsigned decimal integers; bit length specifications and
expressions as modifiers are not supported,
3) Multiple operands. However, multiple constants in a single
operand may be specified for all types except C, X, B, and
S.
4) Length specifications greater than 256 bytes, even in DS
statements with C or X types.
Only one register may be specified in each USING or DROP instruc- tion.
Each operand of a CNOP instruction must be a decimal digit: ex- pressions are not permitted
The operand of an END instruction, if coded, will be ignored. The entry point of a program is determined, instead, by the XEO or XE01 system commands. APPENDIX C
I/O Caveats
Because I/O functions require intervention by the Operating System, many of the safeguards against abnormal termination which PAMELA nor- mally provides are necessarily circumvented during I/O operations. To some extent, therefore, a user must perform input and output at his own risk. Whenever practicable, I recommend that the Display and Al- teration Facilities be used to simulate card reader and printer I/O, as the former provide a reasonably efficient and much less hazardous means of modifying and examining the contents of core storage. If it is necessary to perform "live" I/O, however, the following rules should be obaerved.
Insure that all DDNAME parameters in DCB instructions are valid DD names of card files submitted with the job, and that each DCB is open before a GET or PUT referring to it is executed. Failure E0 observe this rule will probably result in an abnormal termination with a system completion code of 0C1.
Never allow the object code generated by I/O macros to be modified in core. In particular, the common practice of dynamically modifying the EODAD field of a DCB is not permissible under PAMELA, and will very likely cause abnormal termination of the system if the end-of-data condition is raised. 70
Insure that any existing data setsare closed before issuing an
ASM system command; otherwise, the newprogram may overlay the old
DCB fields. General havoc will then descend when the OperatingSystem attempts to free the devices bound to the nonexistentLonttol blocks. APPENDIX D
System Messages
Error and informational messages are written by the system in the message area of the CC-30 TV screen Messages once written are not automatically erased. They may be blanked over using the space bar if desired, but otherwise they will remain displayed until overwritten by a different message If, after a particular message is displayed, the same error is committed a second time, the cursor will trace over the message a second time; thus there is no danger of confusion as to whether or not a message is still in effect
Below is an exhaustive, alphabetized list of all system messages and an explanation of each
DATA INTERRUPT -- A type 7 program interruption has occurred during
execution See Ref 4 for details
DECIMAL DIVIDE INTERRUPT -- The quotient from a Divide Decimal (DP)
instruction was too large. A type 11 program interruption occurred.
DECIMAL OVERFLOW -- A decimal arithmetic instruction caused an over-
flow A type 10 program interruption occurred
END OF ASSEMBLY ERRORS -- A DERR system command was issued, but all
errors in the most recent assembly had already been displayed
END OF FILE -- An end-of-data condition was raised. Either a card
source file, a card data file, or the disk source file has been 72
read in its entirety
ERRORS IN ASSEMBLY -- An ASM command was issued, and assembler lan-
guage errors were detected in the source code
EXECUTION INTERRUPT -- An Execute (EX) machine instruction referred
to another Execute instruction A type 3 program interruption
occurred
EXPONENT OVERFLOW -- A floating-point arithmetic instruction caused
an overflow. A type 12 program interruption occurred.
FILE NOT FOUND -- An NPUT system command specified a card file as
source input, but no file with the specified DD name was included
in the job
FIXED-POINT DIVIDE INTERRUPT The quotient from a Divide (D or DR)
instruction was too large A type 9 program interruption occurred.
FIXED-POINT OVERFLOW -- A fixed-point arithmetic instruction caused
an overflow. A type 8 program interruption occurred
FLOATING-POINT DIVIDE INTERRUPT -- A Floating Point Divide (DE, DD,
DER, or DDR) instruction specified a divisor of zero. A type 15
program interruption occurred
INSTRUCTION COUNTER OUT OF RANGE -- The instruction address spec-
ified by the current PSW is outside the program area
INSUFFICIENT CORE STORAGE -- The program being assembled could not be ASSEMBLY TERMINATED
loaded into the main storage space available
INVALID COMMAND -- A command was issued which was not a valid oper-
ation, or was not in the proper format
INVALID OPERAND -- The input to an alter storage command, or one or
more system command operands, were not in an acceptable format 7'3
LABEL NOT FOUND -- The operand of a system command was taken to be
a label, but no statement having that ]abel had been correctly
assembled.
LINE ERROR -- WILL RETRY A CC-30 I/O error occurred during trans-
mission or reception of data The operation will be retried one
time. If the keyboard does not unlock shortly after this message
is written, the system has probably terminated.
LOCATION OUTSIDE PROGRAM AREA -- An ACOR or DCOR system command has
requested a core location outside the program area.
MISPLACED START -- ASSEMBLY TERMINATED -- Statements causing core
storage to be reserved were encountered prior to the START state-
ment in an assembly; or, more than one START statement was en-
countered.
NO 'END' -- ASSEMBLY TERMINATED -- No END statement was found in an
assembly.
NO SUCH STATEMENT CORRECTLY ASSEMBLED -- A label or statement number
was specified as the operand of a system command, but the specified
statement contained an error, or else no assembly has been per-
formed at all upon it.
OPERATION INTERRUPT -- A type 1 program interruption has occurred
during execution. See Ref. 4 for details
PAMELA TERMINATING An END system command has been issued- Alter
the system writes this message, the phone connection will be broken,
PLACE CURSOR Default cursor placement was requested, but is not
applicable under the rules of Chapter II. 74
PRIVILEGED OPERATION INTERRUPT -- A type 2 program interruption has
occurred during execution See Ref. 4 for details.
PROGRAM APPARENTLY IN LOOP -- One thousand machine instructions have
been executed without encountering a stop, error, or end-of-data
condition.
RECORD NOT FOUND A source handling system command has specified
a label which has not been assembled into the symbol table, or a
statement number which does not appear in the source file
REFERENCE TO LOCATION OUT OF RANGE -- A machine instruction specified
a core location outside the program area.
SEQUENCE NUMBER TOO LARGE -- An NPUT system command specified an ini- INPUT TERMINATED
tial statement number and increment which caus '.d an input statement
to be assigned a number greater than 999.999.
SIGNIFICANCE INTERRUPT A type 14 program interruption has occurred
during execution. See Ref 4 for details.
SPECIFICATION INTERRUPT A type 6 program interruption has occurred
during execution. See Ref. 4 for details.
"STOP" ENCOUNTERED -- Execution was halted because a stop was set at
the current instruction address.
TABLE OVERFLOW -- ASSEMBLY TERMINATED -- The number of symbols or the
total character length of literals appearing in a program is too
large.
YOU MAY NOT ALTER THE 34 HIGH-ORDER BITS An APSW system command OF THE PSW
was issued, and an attempt was made to alter one or more of the
system mask, protection key, AMWP, interruption code, or instruc-
tion length code fields. APPENDIX E
Summary of
System Commands
Command Function Operand 1 Operand 2 Operand 3
ACOR Alter Core HL(R)
AFPR Alter F-P Reg IL(R)
AGPR Alter Gen Reg IL(R) IL
APSW Alter PSW
ASM Assemble
ASRL Alter Source Long NL(R) N
ASRS Alter Source Short NL(R) N
CLR Clear I
DCOR Disp Core HL(R)
DEL Delete Source NL N
DERR Disp Errors
DFPR Disp F-P Reg IL(R)
DGPR Disp Gen Reg IL(R) IL
DPSW Disp PSW
DSRL Disp Source Long NL(R) N
DSRS Disp Source Short NL(R) N
END End Session
NPUT Input Source NL(R) N L 76
Command Function Operand 1 Operand 2 Operand 3
STOP Set Stops HNL
XEQ Execute HNL
XEQ1 Execute Single HNL
XLAT Translate HL(R)
Guide to Operand Codes:
I Decimal Integer
H -- Hexadecimal Integer
N Decimal Number
L -- Symbol
(R) -- Required APPENDIX F
Abbreviations Used
BDAM Basic Direct Access Method
BISAM Basic Indexed Sequential Access Method
BSAM Basic Sequential Access Method
BTAM Basic Telecommunications Access Method
DAF Display and Alteration Facility
DCB -- Data Control Block
DD -- Data Definition
EBCDIC Extended Binary Coded Decimal Interchange Code
EXCP Execute Channel Program
IBM -- International Business Machines
ISAM -- Indexed Sequential Access Method
I/O -- input/Output
JCL -- Job Control Language
MFT Multiprocessing with Fixed number of Tasks
OS -- Operating System
OSA -- Operating System Assembler language
PAMELA -- Program Assembly and Monitored Execution for Learning
Applications
PCI -- Program Controlled Interruption
PSW -- Program Status Word
QISAM -- Queued Indexed Sequential Access Method ;h
()SAM Queued Sequential Access Method
SYSCB System Control Block
TV Television
TWX -- Teletypewriter Exchange LIST OF REFERENCES
1. Computer Communications, Inc., CC-30 CommunicationsStation Reference Manual, 1968.
2. international Business Machines Corp.,IBM System/36U Ub Assembler Language, Form C28-6514, 1964.
3 international Business Machines Corp.,IBM System/360 OS Job Control Language, Form C28-6539, 1968.
4. international Business Machines Corp , IBM System/360 Principles of Operation, Form A22-6821, 1968.