From a84e10cb2f09f18a6c81ab5149c89309cc360027 Mon Sep 17 00:00:00 2001 From: "Mark A. Stevens" Date: Sat, 22 Jan 2022 19:56:22 -0600 Subject: [PATCH] Created branch to hold help files. Changes improve consistency among documents. --- .project | 11 + BASIC.HELPCMD.D1 | 23 + BLOCKTAP.HELPCMD.D1 | 81 + COBOL.HELPCMD.D1 | 29 + EXECUTIL.HELPCMD.D1 | 567 +++++++ FORTH.HELPCMD.D1 | 19 + FORTRAN.HELPCMD.D1 | 119 ++ FORTRANG.HELPCMD.D1 | 6 + FORTRANH.HELPCMD.D1 | 6 + GCC.HELPCMD.D1 | 82 + GCC.HELPCMD2.D1 | 52 + GCCLIB.HELPCMD.D1 | 177 ++ PASC370.HELPCMD.D1 | 17 + PASCAL.HELPCMD.D1 | 19 + PASCOMP.HELPCMD.D1 | 17 + PASLINK.HELPCMD.D1 | 15 + PDPCLIB.HELPCMD.D1 | 90 + PL360.HELPCMD.D1 | 37 + PL360MAN.LISTING.D1 | 3883 +++++++++++++++++++++++++++++++++++++++++++ PLCT.HELPCMD.D1 | 19 + PLI.HELPCMD.D1 | 297 ++++ WATFIV.HELPCMD.D1 | 18 + 22 files changed, 5584 insertions(+) create mode 100644 .project create mode 100644 BASIC.HELPCMD.D1 create mode 100644 BLOCKTAP.HELPCMD.D1 create mode 100644 COBOL.HELPCMD.D1 create mode 100644 EXECUTIL.HELPCMD.D1 create mode 100644 FORTH.HELPCMD.D1 create mode 100644 FORTRAN.HELPCMD.D1 create mode 100644 FORTRANG.HELPCMD.D1 create mode 100644 FORTRANH.HELPCMD.D1 create mode 100644 GCC.HELPCMD.D1 create mode 100644 GCC.HELPCMD2.D1 create mode 100644 GCCLIB.HELPCMD.D1 create mode 100644 PASC370.HELPCMD.D1 create mode 100644 PASCAL.HELPCMD.D1 create mode 100644 PASCOMP.HELPCMD.D1 create mode 100644 PASLINK.HELPCMD.D1 create mode 100644 PDPCLIB.HELPCMD.D1 create mode 100644 PL360.HELPCMD.D1 create mode 100644 PL360MAN.LISTING.D1 create mode 100644 PLCT.HELPCMD.D1 create mode 100644 PLI.HELPCMD.D1 create mode 100644 WATFIV.HELPCMD.D1 diff --git a/.project b/.project new file mode 100644 index 0000000..02e8c14 --- /dev/null +++ b/.project @@ -0,0 +1,11 @@ + + + vm370 + + + + + + + + diff --git a/BASIC.HELPCMD.D1 b/BASIC.HELPCMD.D1 new file mode 100644 index 0000000..73d0729 --- /dev/null +++ b/BASIC.HELPCMD.D1 @@ -0,0 +1,23 @@ +BASIC CMS Command + +Acronym for Beginners' All-purpose Symbolic Instruction Code, runs CALL-OS +BASIC as supplied with VM/370 R1. ++----------+-----------------------------------------------------------------+ +| BASIC | fn [( [)] | ++----------+-----------------------------------------------------------------+ +where: + +fn Is the filename of the file to be run. It must have a filetype + of BASIC. + +option: + +LONG Tells BASIC to use LONG form numbers. + +For more details see + +GC20-1803-1 VM370 BASIC Language Reference Manual Rel 1 + +which may be downloaded from BITSAVERS in the folder + +http://bitsavers.org/pdf/ibm/370/VM_370/Release_1/ diff --git a/BLOCKTAP.HELPCMD.D1 b/BLOCKTAP.HELPCMD.D1 new file mode 100644 index 0000000..595aa27 --- /dev/null +++ b/BLOCKTAP.HELPCMD.D1 @@ -0,0 +1,81 @@ +BLOCKTAP Nucles Extension + +Trap TAPEIO calls and change the blocksize to 32k (approx). This was written +expressly to improve the functions of VMFPLC2 and TAPE. There are sequences of +I/O operations which are probably NOT handled correctly by this routine but it +should work correctly for all sequences generated by VMFPLC2 and TAPE. Tapes +created withOUT BLOCKTAP will be readable with BLOCKTAP ON. ++----------+------------------------------------------------------------------+ +| BLOCKTAP | ON|OFF|Q|CLOSE [(options...[)]] | +| | options: | +| | BLOCK|NOBLOCK TYPE|NOTYPE TAP1|TAPi|181|cuu | +| | Default Options: TAP1 BLOCK TYPE | ++----------+------------------------------------------------------------------+ + +where: + +ON installs the nucleus extension (unless already installed) and turns it + ON for the specified (or defaulted) device. + +OFF turns it OFF for the specified (or defaulted) device and removes the + nucleus extension if no devices are still ON. It performs the CLOSE + and Q functions before extracting itself. + +CLOSE performs any necessary tape operations to insure that the physical + tape reflects the commands which have been buffered. The buffer is + empty after this operation. It performs the Q function after closing. + +Q gives statistics for output operations. Included are the number of + bytes, gaps and tape marks written. Also, the length of tape written + in feet. (Both virtual (what would have been written without BLOCKTAP) + and real (what was actually written to the tape) are reported. + +Options: + +TAPn 18n specifies the symbolic tape identification (TAPn) or the actual device + address of the tape to be read from or written to, where n is 0 to F, + corresponding to devices (cuu) 180-187 and 288-28F. The default is + TAP1 or 181. The unit specified by cuu must previously have been + attached to your CMS virtual machine before any tape I/O operation can + be attempted. + +NOBLOCK specifies that the output tape blocksize is NOT to be altered. This + option will optimize tape movement and eliminate the extra gaps + produced by superfluous tape marks and subsequent re-positioning of + the tape. Tapes created with this option will be readable without + BLOCKTAP. + + Options BLOCK and NOBLOCK may be specified ONLY with the ON function. + +TYPE specifies that statistics are to be given on the CLOSE and OFF + functions. + +NOTYPE specifies that statistics are NOT to be given on the CLOSE and OFF + functions. The confirmation messages on the ON function are also + suppressed. This option has NO effect on the Q function. + + The TYPE/NOTYPE setting is preserved for the specified device until + changed (by specifying the opposite setting). + +This command installs a Nucleus Extension for the TAPEIO function. The nucleus +extension buffers I/O requests and causes the tape to be written in standard OS +VariableBlocked format. Each record in this format is one TAPEIO request. A +block is written to tape ONLY when addition of data to it would cause it to +exceed 32760 bytes. It is also written if an ERG, SENSE, REW or RUN command is +given. + +Note that WTM, BSF, FSR and BSR commands are buffered. This saves tape when the +"standard" CMS command sequence of "write the file, WTM, WTM, BSF, BSF" is +issued over and over again ... because the superfluous tape marks are NOT +written. + +The user must NOT re-position the tape with any CP commands while BLOCKTAP is +ON because the last few commands are probably still in the buffer and were NOT +written to the tape!!! + +NO warrantee of ANY kind is either expressed or implied by the author or +Brigham Young University. + +Author: Steven C. Howes Brigham Young University +Version: 1 +Date: 11 May 1987 diff --git a/COBOL.HELPCMD.D1 b/COBOL.HELPCMD.D1 new file mode 100644 index 0000000..caaa3be --- /dev/null +++ b/COBOL.HELPCMD.D1 @@ -0,0 +1,29 @@ +COBOL CMS EXEC + +Use the COBOL exec to compile COBOL programs using the OS MVT/MFT Cobol V3 +compiler described in GC28-6399 which may be downloaded from www.bitsavers.org. + +The format of the COBOL command is + ++------------+----------------------------------------------------------------+ +| COBOL | filename | ++------------+----------------------------------------------------------------+ + +where: + +filename Is the name of a file with filetype COBOL and fixed length 80 byte + records. + +Options: + +The command does not accept any options but passes the following options to +the COBOL compiler: + +Notes: + +1. The compiler outputs two files "filename TEXT" containing the generated + object code, and "filename LISTING" which contains the compiler listing + including diagnostic messages. + +2. The COBOL runtime is contained in "COB360 TXTLIB Y". Issue a GLOBAL TXTLIB + referencing this file before loading a cobol program. diff --git a/EXECUTIL.HELPCMD.D1 b/EXECUTIL.HELPCMD.D1 new file mode 100644 index 0000000..0d6c2c9 --- /dev/null +++ b/EXECUTIL.HELPCMD.D1 @@ -0,0 +1,567 @@ +EXECUTIL CMS MODULE + +Places information about the CP and CMS environment on the stack. ++----------+------------------------------------------------------------------+ +| EXECUTIL | function | ++----------+------------------------------------------------------------------+ +| Functions: | +| | +| FREEADDR - unused virtual addresses | +| FREEMODE - unused disk mode letters | +| INFO - useful constants | +| QDISK - CMS disks | +| QFILE - CMS disk files | +| QLIB - currently globaled libraries | +| QREADER - spooled reader files | +| QSTACK - CMS console stack | +| READ - read records from CMS disk files | +| TYPE - type lines at the terminal | +| WRITE - write records to CMS disk files | +| | +| Options: | +| | +| See the desription of each function below for details of the options | +| | +| **NOTE** | +| There is no "(" between the funcion and the options | ++-----------------------------------------------------------------------------+ + +Functions: + +FREADDR + +Syntax: +EXECUTIL FREEADDR [ cuu 191 [ n 1 ] ] + +The FREEADDR function stacks (LIFO) a single line containing the next 'n' +unused virtual addresses equal to, or higher than, the given 'cuu' parameter. +The value 'n' must be positive and an arbitrary limit of 30 addresses can be +stacked. The highest valid virtual address is 5FF, and if there are fewer than +'n' unused virtual addresses in the range 'cuu' to 5FF, then nothing is stacked +and a return code of 1 is returned. + +Errors: + +1 Insufficient unused virtual addresses + + +EXECUTIL FREEMODE [ mode * A ] + +The FREEMODE function stacks (LIFO) a single line containing all of the +currently unused mode letters, in alphabetical order and separated by blanks. +If the 'mode' parameter is specified, then only unused mode letters in the +range 'mode' to Z are stacked. If it is specified as '*', this is equivalent +to 'A', and hence all unused mode letters are stacked (i.e. range A to Z). The +'mode' parameter can consist of either just a mode letter by itself, or both +the mode letter and a mode number. + +Errors: + +1 No unused mode letters available + + +INFO Function + +Syntax: + +EXECUTIL INFO + +The INFO function stacks (LIFO) a single line containing the following useful +items of information: + current date as MM/DD/YY + current time of day as HH:MM:SS + day of the week (Mon, Tue, Wed, Thu, Fri, Sat, Sun) + name of the current month (Jan, Feb, ...) + userid of the virtual machine + current size of the machine's virtual memory, given as nnnK + account number used for accounting purposes (or '*' if none available) + CPU model number (e.g. 158, 168, 3031, 3033, 4341) + CPU serial number (6 decimal digits). This is useful for uniquely + identifying a physical processor, especially if there are several with + the same model number. + +Errors: + +None. + + +QDISK Function + +Syntax: + +EXECUTIL QDISK [ mode * A ] +EXECUTIL QDISK ADDress [ cuu 191 ] +EXECUTIL QDISK LABel [ label TDISK1 ] + +The QDISK function stacks information about accessed CMS disks. There are +three ways of selecting the disk or disks for which you want this information, +each corresponding to one of the syntax forms show above. The first form +accepts a 'mode' parameter, which specifies the disk for which you want the +information to be stacked. If it is specified as '*', then the information is +stacked for all currently accessed disks. In this case the lines are stacked +such that you will read them in alphabetical order by disk mode. + +The other two forms allow you to select the disk by specifying either; 1) the +keyword ADDRESS and the virtual address of the disk, or 2) the keyword LABEL +and the label of the disk. All of the currently accessed disks are scanned to +search for the first one with the given address or label. + +For each disk selected, the following information is stacked: + + the mode used in the ACCESS command for this disk (e.g. 'B' or 'C/A') + virtual address of the disk (cuu) + the size of the disk in cylinders + the number of files on the disk + the number of disk blocks in use + the number of unused disk blocks either 'R/O' or 'R/W' + the 6-character disk label mode letter at which the disk is accessed. This + is usually the same as 'accmode', but saves you having to check if + 'accmode' is in the "mode/parent" format (e.g. 'C/A'), if all you want is + the mode letter. + the size of the disk blocks being used. + +Errors: + +1 Disk specified is not accessed + + +QFILE Function + +Syntax: + +EXECUTIL QFILE fn * ft * [ fm * A1 [ fm ... ]] +[ ( [ FIRST ] [ EXT ] [ LIFO FIFO ] ] + +Description: + +The QFILE function stacks information about CMS disk files. The 'fn' and 'ft' +parameters must be specified and give the filename and filetype of the file or +files for which you want this information. Unfortunately QFILE does not +support the same pattern matching abilities of the LISTFILE command, but it +does allow the filename and/or filetype to be given as '*', which matches any +filename or filetype. You can specifically list all of the filemodes to be +searched, or you can specify '*', indicating that all filemodes are to be +searched. + +The FIRST option indicates that searching is to stop as soon as the first file +is found. + +The EXT options specifies that any read/only extension disks for the given +filemodes are also to be searched (by default they are not searched). + +The FIFO and LIFO options specify the order in which the lines are to be +stacked, LIFO being the default. + +For each file selected, the following information is stacked: + the filename, filetype, and filemode of the file + the record format of the file, either 'F' or 'V' + the logical record length of the file + the number of records in the file + the size of the file in disk blocks + the date the file was last written (MM/DD/YY) + the time of day the file was last written (HH:MM:SS) +Errors: + +28 File not found + + +QLIB Function + +Syntax: + +EXECUTIL QLIB MACLIB TXTLIB DOSLIB + +The QLIB function stacks (LIFO) a single line containing the names of the +specified libraries (MACLIB, TXTLIB, or DOSLIB), that are currently globaled. + +Errors: + +1 No libraries globaled + + +QREADER Function + +Syntax: + +EXECUTIL QREADER [ Name fn ft ] [ FRom userid ] +[ Type DSK PRT CON PUN RDR DMP MON UNK ] +[ CLass c ] [ Hold ] [ NOHold ] +[ spoolid spoolid ... ] +[ FIRST ] [ LAST ] [ EXCLude ] + +The QREADER function stacks information about spool files in your virtual +reader. The output lines are stacked LIFO, such that the order you read the +lines is the same as the order of the files in the reader. The order of the +files in the reader is not changed. + +The first set of parameters select a particular subset of the reader files for +which you want the information. If no selection parameters are specified, +information on all the reader files is returned. + +The 'Name' parameter must be followed by the filename and filetype of the +reader files to be selected. Either can be '*', which matches any filename or +filetype. + +The 'FRom' parameter selects only those files sent to you from the given +userid. + +The 'CLass' parameter selects only those files in the given class. + +The 'Type' parameter selects only the files of the given type as follows: + PRT printer files + CON console files + RDR card-image files without header records (real card files or created by + the PUNCH command with the NOHEADER option) + PUN card-image files with header records (created using the PUNCH command + with the HEADER option) + DSK card-image files in DISK DUMP format (created by the DISK DUMP command) + DMP system DUMP files (either from CP VMDUMP command or CP abend dumps) + MON system MONITOR files + UNK unknown type. This will select only those card-image files (PUN, RDR, or + DSK) that are in SYSTEM-hold. (Thus their type is "unknown" since + EXECUTIL is unable to read them to determine the format.) + +The 'Hold' and 'NOHold' parameters select only files in USER-hold or not in +USER-hold, respectively. + +Finally, a specific set of files can be selected by listing their spoolids +(4-digit spool file identification numbers). Only files from that set of +numbers will be selected. + +The selection parameters can be given in any order and several can be combined +to select a group of files. For example, +QREADER TYPE CON FROM HELP +will stack information only about CONSOLE files sent from userid HELP. + +The remaining options further define the files for which you wish the +information to be stacked. Specifying 'FIRST' or 'LAST' indicates that you are +only interested in either the first or the last reader file which matches all +of the selection parameters. The 'EXClude' option reverses the effect of all +the selection parameters except FIRST and LAST. If 'EXClude' is specified then +information is returned about all files that do NOT match the selection +criteria. These options can also be combined. For example, +QREADER CLASS Z EXCLUDE FIRST HOLD +will stack information about the first file in the reader that is not a class Z +file in HOLD status. + +The following information is stacked for each reader file selected: + spoolid (4 decimal digits) + 1-character class code + number of records in the file + number of copies of the file + type code indicating the format of the file (PRT, CON, RDR, PUN, DSK, DMP, + MON, UNK) + hold status + NONE - file not held + USER - file in USER-hold + SYS - file in SYSTEM-hold + USYS - file in USER- and SYSTEM-hold + userid that created the reader file + creation date (MM/DD/YY) + time of day the file was created (HH:MM:SS) + distribution code + filename and filetype of the file (may be null strings if not known) + +Errors: + +1 No reader files selected + + +QSTACK Function + +Syntax: + +EXECUTIL QSTACK [ n 0 ] + +The QSTACK function stacks (LIFO) a single line containing the number of lines +currently in the CMS console stack, and the difference between that number and +the given parameter 'n'. (i.e. if there are 'x' lines in the stack, it stacks +'x' and 'x-n'. + +It is most useful in situations where a command or function will place a +variable number of lines in the stack, such as in the following example. + +* GET NUMBER OF LINES IN THE STACK NOW +EXECUTIL QSTACK +&READ VARS &NUMLINS +* GET INFO ON THE FILES +EXECUTIL QFILE * &FTYPE * +&IF &RETCODE ^= 0 &GOTO -ERR1 +* GET NUMBER OF LINES JUST STACKED +EXECUTIL QSTACK &NUMLINS +&READ VARS &JUNK &NUMLINS + +Errors: + +None. + + +READ Function + +Syntax: + +EXECUTIL READ fn ft [ fm * ] +[ recno * [ nrecs * [ truncol * ]]] +[ ( FIFO LIFO ] + +The READ function reads records from a CMS disk file and stacks the lines in +the CMS console stack. The first two parameters, the filename and filetype of +the file, must always be specified. The filemode parameter can be omitted, +even if the 'recno' parameter is given. If the parameter following the +filetype looks like a valid filemode (i.e. a mode letter, a mode letter and +mode number, or '*'), then it is taken as the filemode, otherwise the parameter +is assumed to be the 'recno' parameter and the default filemode is used. The +default filemode is '*' which causes all disks to be searched for the file to +be read. + +The 'recno' parameter gives the record number at which to start reading. The +READ function does not close the file after reading so specifying 'recno' as +'*' (the default) causes reading to continue from where you left off. If this +is the first call to read this file, reading starts at the beginning. + +The 'nrecs' parameter indicates the number of records to be read. Starting at +'recno', the next 'nrecs' records will be read, or, if 'nrecs' is negative, the +preceding 'nrecs' records will be read in reverse order. Specifying '*' causes +all records from 'recno' to the end of the file to be read and stacked. +Similarly, '-*' causes all records from 'recno' to the start of the file to be +read in reverse order. The default is to read only one record. + +The 'truncol' parameter gives the truncation column. The entire record is +read, but only columns 1 to 'truncol' of each record are stacked. If 'truncol' +is not specified or is given as '*', the entire record is stacked. The main +use for this parameter is to prevent the serialization numbers of some +fixed-length files from being stacked. Although the READ function will allow +lines of greater than 130 characters to be stacked, the result of reading these +lines is largely unpredictable. + +Lastly, the 'FIFO' and 'LIFO' options indicate the order in which the lines are +to be stacked, the default being FIFO. + +The lines are stacked exactly as they are read from the file. You must +remember that if these lines are subsequently read by EXEC using the &READ +statement, the EXEC processor will tokenize the lines. + +The READ function does not close the file after reading, thus the next time the +READ function is invoked you can continue reading from where you left off. If +you wish to start reading the file from the start again, or use the file for +some other purpose, you must explicitly close the file via the FINIS command. +An attempt to read past the end of the file results in a return code of -12. + +Errors: + +-12 EOF reached +28 File not found +40 Error reading the file + +Typed Error Messages: + +EXCUTL040E ERROR 'nn' READING 'fileid'. + +See the documentation for the FSREAD macro in the CMS Command and Macro +Reference manual for the error numbers for return code 40. + + +TYPE Function + +Syntax: + +EXECUTIL TYPE [ n * ] [ NOCR ] [ ( text ) ] +[ TAB [ +9 READ [nn +nn -nn] ... ]] + +The TYPE function reads lines from the CMS console stack and types them on the +terminal, or types a single line from text given on the command line. + +The first parameter is the number of lines which are to be read from the CMS +console stack. If this parameter is omitted, specified as '*', or if there are +fewer than 'n' lines in the stack, then lines are read and typed until the +stack is empty. + +The 'NOCR' option causes the lines to be typed without a carriage return and +linefeed at the end. This feature is useful when issuing prompts to the +terminal (as shown in the example below), or if reading from the CMS console +stack this allows several short lines to be concatenated. This option has no +effect when using a 3270-type display terminal. + +Instead of reading from the CMS console stack, the text to be typed can be +specified on the command line by enclosing it in parentheses. Again, this is +useful for issuing prompts as in the following example: + +EXECUTIL TYPE NOCR (Filename ?) +which (on a non-display terminal) would type +Filename ? _ +and leave the cursor at the end of the line as shown. The text on the command +line can also contain the concatenation operator ('||'), which causes the two +adjacent tokens to be concatenated. This circumvents the problems caused by +tokenization. For example, +EXECUTIL TYPE ( Invalid para || meters || : ) +will type 'Invalid parameters:'. + +Normally, lines read from the stack are typed exactly as they are, or, if text +is given on the command line, the output line is formed by inserting a single +blank between the tokens (subject to tokens being concatenated together via ' +'). However, the TAB option allows the output line to be formatted into +specific columns before being typed out. The tab settings can either be read +from a line in the console stack, or be specified following the keyword 'TAB' +on the command line. Because there can be an indefinite number of tabs +specified, the TAB option must be the last on the command line. Tab settings +can be specified in three ways: + +[ nn +nn -nn ] ... + +Specifying 'nn' sets the next tab at column number nn. The forms '+nn' and +'-nn' set the next tab at the given positive or negative offset from the last +tab position. A positive offset (+nn) has a special meaning when it is the +last (or only) tab specification on the line. In this case it causes a tab to +be set 'every nn' positions from the current column. For example: + +TAB +7 +TAB 1 8 15 +7 +TAB 1 8 15 22 29 36 43 ... + +are equivalent tab specifications. Any combination of absolute column numbers, +positive and negative offsets can be used, as long as all tabs are set at +positive column positions. An arbitrary maximum of 35 tab settings is allowed. +If you only specify the keyword 'TAB', then a default setting of 'TAB +9' is +used. If you specify 'TAB READ', then a single line is read from the CMS +console stack (or terminal) and decoded as tab settings. This helps prevent +command lines from becoming too long. Thus: + +&STACK LIFO 4 +6 -1 24 +15 +EXECUTIL TYPE * TAB READ +is equivalent to +EXECUTIL TYPE * TAB 4 +6 -1 24 +15 + +When tab settings are given, the line read from the CMS console stack or the +text from the command line, is first separated into fields delimited by blanks, +then, working left to right, each field is positioned according to the tab +settings. + +&STACK LIFO Value= ******* ( Canadian ) $3 +EXECUTIL TYPE 1 TAB 1 10 +8 +1 +8 -18 + +results in the following line being typed: + Value= $3****** (Canadian) +columns 123456789*123456789*123456789*123456789* + +Notice that because it works left to right, the '$3' field overlaid the first +part of the '********' field. + +Errors: + +16 Invalid tab sequence + +Typed Error Messages: + +EXCUTL016E INVALID TAB SEQUENCE. + + +WRITE Function + +Syntax: + +EXECUTIL WRITE fn ft [ fm * A1 ] +[ recno * [ nrecs * 1 [ recfm [ lrecl ]]]] +[ ( text ) ] [ LCASE ] +[ TAB [ +9 READ [nn +nn -nn] ... ] ] + +The WRITE function writes records to CMS disk files. The data to be written is +obtained from the stack, the terminal, or the command line. + +The first two parameters, the filename and filetype of the file to be written, +must always be specified. The filemode parameter can be omitted, even if the +'recno' parameter is given. The rule is that if it looks like a valid filemode +(i.e. a mode letter, a mode letter and mode number, or '*'), then it is taken +as the filemode, otherwise the parameter is assumed to be the 'recno' parameter +and the default filemode (A1) is used. If the filemode is given as '*', then +all read/write disks will be searched for the given file. If the file already +exists and is on a read/write disk, then the file is updated or appended to, +depending upon the other parameters. If the file does not already exist on a +read/write disk, it is automatically created on your A-disk. + +The 'recno' parameter is the starting record number to be written. Specifying +'*' (the default) causes the records to be appended to the file. If the file +is a variable-length file, the WRITE function forces the records to be +appended. + +If the file is fixed-length, any individual record can be written or rewritten. +If you give a record number that is past the current end of the file, then null +records containing hexadecimal zeroes will be inserted. + +The 'nrecs' parameter gives the number of records to be written. If 'nrecs' is +given explictly as a decimal number, then precisely 'nrec' reads will be issued +to the stack, or if the stack is empty or becomes empty, the reads will be +presented at the terminal. If 'nrecs' is given as '*' (the default), then +there are two possible actions, depending upon the initial state of the console +stack. If initially there are lines in the stack, then reads are issued until +the stack is empty. However, if the stack is initially empty, then reads are +issued to the terminal until a null line is entered. (Note: if 'nrecs' is +given explicitly and reads are presented to the terminal, entering a null line +is equivalent to entering a single blank.) + +The 'recfm' and 'lrecl' parameters are used only if a new file is being +created. If the file specified already exists, then both parameters are +totally ignored. The valid 'recfm' values are 'F' (fixed-length) which is the +default, and 'V' (variable-length). The default 'lrecl' for fixed- files is 80 +characters. The 'lrecl' parameter is meaningless for variable-length files as +the logical record length is always the length of the longest record in the +file. However, specifying 'lrecl' in this case, will not cause a error. + +If the line to be written to the file is only a few tokens, it can be specified +on the command line by enclosing it in parentheses. The special concatenation +token (' ') can be used exactly as described in the documentation for the TYPE +function. + +If lines are being read from the terminal or the stack, the 'LCASE' option +prevents the read routines from converting the input to upper case. + +The lines to be written can be formatted to some extent by specifying tab +settings to be used. Again, the 'TAB' parameter is exactly as described for +the TYPE function. + +Errors: + 16 Invalid tab sequence + 40 Error writing the file. + +Typed Error Messages: + +EXCUTL016E INVALID TAB SEQUENCE. + +EXCUTL040E ERROR 'nn' WRITING 'fileid'. + +See the CMS Command and Macro Reference manual under the FSWRITE macro for the +error numbers for return code 40. + +An easy way to see the format of the output stacked by any of the first set of +functions is to use EXECUTIL EXEC. This EXEC simply consists of the following: + +&CONTROL ERROR +EXECUTIL &1 &2 &3 &4 &5 &6 &7 &8 &9 ... +EXECUTIL TYPE * + +The second line executes the EXECUTIL module with whatever parameters you give, +and the EXECUTIL TYPE command then types out all of the lines that were +stacked. For example, + +executil info +06/13/80 16:39:16 Fri Jun LEW 800K C1234 3031 970137 +R; + + +Error Conditions + +Any errors or special conditions are reflected in the return code. Error +messages typed at the terminal are edited in accordance with the current EMSG +setting. Each function has its own specific return codes, but the following +apply to all functions: + +0 Normal exit +77 Invalid parameter +88 Missing parameter +99 Unknown function + + +Error Messages: + +EXCUTL077E INVALID 'function' PARAMETER - 'parameter'. +EXCUTL088E 'function' OPERAND MISSING. +EXCUTL099E UNKNOWN FUNCTION - 'function'. diff --git a/FORTH.HELPCMD.D1 b/FORTH.HELPCMD.D1 new file mode 100644 index 0000000..67f7243 --- /dev/null +++ b/FORTH.HELPCMD.D1 @@ -0,0 +1,19 @@ +FORTH CMS COMMAND + +Invokes the FORTH interpreter, Release 1 Version 1. ++-----------------------------------------------------------------------------+ +| FORTH | ++-----------------------------------------------------------------------------+ +On loading FORTH, it will attempt to load your extensions from the file +FORTH $PROG$ A. + +If this file does not exist, it remains in the forth interpreter, and prints +the error. + + 'FORTH $PROG$ A' File does NOT exist + FORTH ready + ? + +To exit forth type "END" or "end" at the '?' prompt. + +Enter .HELP in FORTH for more information. diff --git a/FORTRAN.HELPCMD.D1 b/FORTRAN.HELPCMD.D1 new file mode 100644 index 0000000..1dea997 --- /dev/null +++ b/FORTRAN.HELPCMD.D1 @@ -0,0 +1,119 @@ +FORTRAN ¦ FORTRANG ¦ FORTRANH MODULES + +Use the FORTRANG & FORTRANH commands to invoke the OS FORTRAN Compliers. Then +use the LOAD and START commands to run the programs. ++----------------+------------------------------------------------------------+ +| FORTRAN[G¦H] | filename ( options | +| | | +| | DIsk¦PRint¦NOPRint EBCDIC¦BCD ID¦NOID | +| | LINECNT(60)¦LINECNT(NN) LOAD¦NOLOAD MAP¦NOMAP | +| | NAME(MAIN)¦NAME(XXXXXXXX) NODECK¦DECK NOEDIT¦EDIT* | +| | NOID¦ID NOLIST¦LIST NOXL¦XL* NOXREF¦XREF* | +| | OPT(0)¦OPT(1)¦OPT(2)* | +| | SIZE(0000K)¦SIZE(NNNNNNNN)¦SIZE(NNNNK)* | +| | SOURCE¦NOSOURCE* TRACE(0)¦TRACE(nnnn)* | +| | * - Option only available with FORTRANH | ++----------------+------------------------------------------------------------+ +Where: + +FORTRAN + controls which compiler is invoked. FORTRAN with no suffix invokes + Fortran G. + +filename the name of the file to be compiled. The filetype must be + FORTRAN and it must have fixed length 80 byte records. + +Options: + +DIsk + writes the complier listing as LISTING on the "A" disk. +PRint + writes to the users virtual printer. +NOPRint + do not write a listing file. + +EBCDIC¦BCD + allows the reading of a program in EBCDIC or BCD code. The default + is EBCDIC. + +ID¦NOID + ID specifies that internal sequence numbers will be generated. These + can be used by the run time library to annotate errors. The default + is NOID. + +LINECNT(NN) + specify the lines per page on the lisiting. The default is 66. + +LOAD¦NOLOAD + controls OBJECT file generation. Default is LOAD. + +MAP¦NOMAP + controls inclusing of Storage map in listing. Default is NOMAP + +NAME(XXXXXXXX) + alocates a name to the MAIN program. Default MAIN. + +NODECK¦DECK + controls the punching of the object code. If DECK is specified an + OBJECT deck is punched. Default is NODECK. + +NOEDIT¦EDIT* + writes an editing listing. Requires OPT(2). Fortran H only. + +NOLIST¦LIST + include the Source Code in the Listing file. Default is LIST. + +NOXL¦XL* + enables some Extended Language facilites as described in GY28-6642. + Fortran H only. + +NOXREF¦XREF* + includes a cross reference in the listing. The default is NOXREF. + Fortran H only. + +OPT(0)¦OPT(1)¦OPT(2)* + set the Optimization level. Fortran H only. + +SIZE(0K)¦SIZE(N)¦SIZE(K)* + set the Storage used by the compiler. Generally not usefull. H Only. + Fortran H only. + +SOURCE¦NOSOURC* + include a copy of the source in the listing. The default is SOURCE. + Fortran H only. + +TRACE(0)¦TRACE(nnnn)* + only for debugging the compiler. Fortran H only. + +Usage Notes: + +1. These are the the OS MVT Compilers which implement FORTRAN IV as described + in the manual: + + IBM System/360 FORTRAN IV Language, Form C28-6515 + + This, along with the other relevant manuals may be downloaded from: + + http://bitsavers.org/pdf/ibm/360/fortran/ + +2. When running FORTRAN programs by default all IO takes place to CMS disk + files of the form : + + FILE FTnnF001 A + + where "nn" is the stream number in the program. If you wish to do IO to a + specified file or device issue a FILEDEF referencing DD name FTnnF001. + For example entering: + + FILEDEF FT06F001 TERM + + will cause output on stream 6 to be sent to the CMS console. + + The CMS FILEDEF command expands "nn" to FTnnF001. + +4. The FORTRAN runtime library FORTLIB TXTLIB Y is required to load FORTRAN + programs and must be referenced in a GLOBAL TXTLIB command before issuing + a LOAD or INCLUDE command. + +5. The VM/370 Community Edition also includes the WATFIV compiler. + See HELP WATFIV for more information. diff --git a/FORTRANG.HELPCMD.D1 b/FORTRANG.HELPCMD.D1 new file mode 100644 index 0000000..feb430d --- /dev/null +++ b/FORTRANG.HELPCMD.D1 @@ -0,0 +1,6 @@ +FORTRANG MODULES + +Use the FORTRANG command to invoke the OS FORTRAN G Complier. Then +use the LOAD and START commands to run the programs. + +See HELP FORTRAN for details of using the G and H compilers. diff --git a/FORTRANH.HELPCMD.D1 b/FORTRANH.HELPCMD.D1 new file mode 100644 index 0000000..b1a70be --- /dev/null +++ b/FORTRANH.HELPCMD.D1 @@ -0,0 +1,6 @@ +FORTRANH MODULES + +Use the FORTRANH command to invoke the OS FORTRAN H Complier. Then +use the LOAD and START commands to run the programs. + +See HELP FORTRAN for details of using the G and H compilers. diff --git a/GCC.HELPCMD.D1 b/GCC.HELPCMD.D1 new file mode 100644 index 0000000..c4cbd4a --- /dev/null +++ b/GCC.HELPCMD.D1 @@ -0,0 +1,82 @@ +GCC CMS EXEC + +Use the GCC command to compile and assemble a C source file using the GNU C +compiler. Then use the LOAD and START commands to run the program: + + gcc hello + load hello + start + +The format of the GCC command is: ++----------+------------------------------------------------------------------+ +| GCC | [fn [ft|C [fm|A]]] [( [options] | +| | options: | +| | ASM|NOASM CSECT|NOCSECT KEEP|NOKEEP LIB fn | +| | OS|CMS PARM fn | ++----------+------------------------------------------------------------------+ +where: + +fn [ft [fm]] + identifies the C source file to be compiled. ft defaults to C and fm + defaults to A. + +Options: + +ASM|NOASM + specifies whether the ASSEMBLE output file from the C compiler is to + be assembled or not. ASM is the default. + +CSECT|NOCSECT + specifies that the blank CSECT statement produced by GCC is to be + given a label. NOCSECT is the default. CSECT is required only when + building a library of C routines. + +KEEP|NOKEEP + specifies whether or not the assembler output files from the C + compiler are to be kept or erased. NOKEEP is the default. + +LIB fn specifies the runtime library with which the program is to be + compiled. GCC will link and access the appropriate disk containing + the C header files. Two runtime libraries are available: + + GCCLIB uses only "native" CMS functions for system services. Using + this library it is possible to write programs that may be + loaded into resident memory as extensions of the CMS nucleus. + + Ensure GCCLIB is in your list of GLOBAL TXTLIBs to run your + compiled progam. Type HELP GCCLIB for more information. + + PDPCLIB uses simulated OS functions for system services. + + Ensure PDPCLIB is in your list of GLOBAL TXTLIBs to run your + compiled progam. Type "HELP PDPCLIB" for more information. + + LIB PDPCLIB is the default. + +OS|CMS OS is shorthand for LIB PDPCLIB. CMS is shorthand for LIB GCCLIB. + +PARM fn specifies a file of type PARM containg arguments to pass to GCC. By + the default file 'GCC PARM *' is used. + +Notes: + + 1. The GCC compiler is V3.2.3 and so is missing some features modern + code relies on. + + 2. Both PDPCLIB and GCCLIB only implement the C90 standard. See the + appropriate HELP files for more details + + 3. As the GCC EXEC calls the normal VM Assembler and LOADER external + names are limited to 8 characters. As a result when porting code + you will often get duplicate external names. One way round this + is to create a ".h" file that redefines the names and include + this in each module of your project. + + 4. The include () files are specific to to the compiler. + This for PDPCLIB are on the GCCCMS 201 disk, those for GCCLIB + on the GCCCMS 202. The GCC EXEC links and accesses the appropriate + before calling the compiler. + + For more information on PDPCLIB and GCC see the project web site at:- + + https://gccmvs.sourceforge.net/ diff --git a/GCC.HELPCMD2.D1 b/GCC.HELPCMD2.D1 new file mode 100644 index 0000000..f7f3c35 --- /dev/null +++ b/GCC.HELPCMD2.D1 @@ -0,0 +1,52 @@ +Usage Notes: + +1. To compile a C program called HELLO C A, type + GCC HELLO + To run the program, you must have the appropriate TXTLIB specified. Use + the GLOBAL command to do this: + GLOBAL TXTLIB PDPCLIB + Now you can load and run the program: + LOAD HELLO + START + Alternatively you can create a module of your program: + LOAD HELLO + GENMOD HELLO + Now you can invoke the program by typing its name: + HELLO + +2. When opening a file you may simply specify the name e.g. + + fptr=fopen("TEST DATA A", "W") + + To simplifiy porting the "." character may also be used to separate the + components of the file, e.g, "TEST.DATA.A" refers to the same file. + + PDPCLIB uses OS emulation and needs a FILEDEF. In this case it will + issue a FILEDEF command "under the covers" with an FD of the form + + FILEDEF PDPnnnnn DISK TEST DATA A (RECFM V + + to allow access to the file. You may see these DD names + in error messages. + + Should you wish to issue your own FILEDEF commands you may use a + fie name of the form + + DD: + + and therefore coding an open as follows:- + + fopen("DD:TEST", "w"); + + and issuing the followings FILEDEF command before running the program: + : + FILEDEF TEST DISK TEST DATA A (LRECL 80 RECFM V + + would access the same data. Type HELP PDPCLIB for more information. + +3. The source code for the GCC compiler and runtime libraries is on the + GCCCMS userid disks. + +4. An alternate runtime library called GCCLIB is available for C programs. + This runtime library lets you code C programs that directly access CMS + system services. Type HELP GCCLIB for more information. diff --git a/GCCLIB.HELPCMD.D1 b/GCCLIB.HELPCMD.D1 new file mode 100644 index 0000000..6bbf50b --- /dev/null +++ b/GCCLIB.HELPCMD.D1 @@ -0,0 +1,177 @@ +GCCLIB, The "Native CMS" GCC Runtime Library + +Version 0.7.1 - 21 Feb 2020 + +Robert O'Hara, Redmond Washington, July 2010 +rpohara@msn.com + +Many thanks to Paul Edwards and Dave Wade + + +Introduction: What is a "Native CMS" runtime library? +------------------------------------------------------ + +Language processors in CMS such as the assembler, FORTRAN, and PL/I, have +traditionally been ports of the versions that run on OS or MVS. These programs +use OS macros, and therefore OS SVCs, to access system services. CMS supports +this by simulating a limited set of OS services. Thus, for example, a call to +allocate memory (GETMAIN) is mapped to the native CMS service (DMSFRE). + +So what is the problem? Because many OS programs (given the batch heritage of +that operating system) do not free the memory they use, CMS automatically frees +all OS memory after each command is run. Thus it is not possible for a program +that uses OS services to call another such program as a CMS command. The +obvious example of such a situation is the REXX processor (BREXX or Regina +REXX). As things stand, since the REXX processor is uses C, and the existing +C runtime library uses OS simulation, it cannot call another program (such as a +compiler) that also uses OS simulation. + +GCCLIB is a "Native" CMS GCC runtime library. It removes these restrictions, +and uses only CMS services to access operating system functions. If your goal +is to write C programs that are portable across operating systems, then this +library is probably not what you want to use. But if you want to write +programs just for CMS, then this library will give you the best access to CMS +system services. + +In CMS it is possible to load programs into memory and have them reamin their +for the rest of your session. These are called "resident" programs. Starting +with VM/SP, IBM made it possible for users to create resident programs via the +NUCXLOAD command. In VM/370 we have the RESLIB command which performs a +similar function. Using the RESLIB command, the GCCLIB library can be loaded +into memory. When a C program is then loaded, it is linked to the memory- +resident runtime through some small stub routines. The difference in program +size is dramatic: a simple hello world program is 60K bytes in size, when all +of the needed runtime code is linked in. The same program is less than 800 +bytes in size using the resident library. + +This means it is now possible to write programs that execute in the 8K CMS +transient area, and can be called in CMS Subset mode from within EDIT or other +programs. Type HELP RESLIB for more information. + +In the VM/370 Sixpack version 1.2, VM/370 CE V1R1M1, and following, the GCCLIB +runtime library is automatically loaded into CMS resident memory during CMS +initialization. + + +Using GCCLIB +------------ + +To compile programs with GCCLIB, put this command in your PROFILE EXEC: + GLOBAL TXTLIB GCCLIB + +Use the GCC command to compile and assemble a C program, specifying the CMS or +LIB GCCLIB option. Type HELP GCC for information on it the GCC command. Use +the standard CMS LOAD and GENMOD commands to build an executable. For example, +to compile the HELLO C program (copy it from the U disk to your A disk first): + GLOBAL TXTLIB GCCLIB + GCC HELLO (CMS + LOAD HELLO + START + + +CMS-Specific Functions in GCCLIB +-------------------------------- + +Beyond the functions provided by the standard C runtime library , GCCLIB +implements the following CMS-specific functions: + CMSargstring() return the unedited argument string + CMScardPunch() write a line to the virtual card punch + CMScardRead() read a line from the virtual card reader + CMSclock() return the system clock time + CMScommand() issue a CMS command + CMSconsoleRead() read a line from the console or program stack + CMSconsoleWait() wait for console I/O to complete + CMSconsoleWrite() write a line to the console + CMSdebug() call a debug routine where a breakpoint can be set + CMSfileClose() close a CMS file + CMSfileErase() erase a CMS file + CMSfileOpen() open a CMS file + CMSfilePoint() set the read or write pointer to a record in a file + CMSfileRead() read one or more records from a CMS file + CMSfileRename() rename a CMS file + CMSfileState() determine if a file exists + CMSfileWrite() write one or more records to a CMS file + CMSgetClock() get the system clock time + CMSmemoryAlloc() allocate memory + CMSmemoryFree() release allocated memory + CMSprintLine() write a line to the virtual printer + CMSstackLine() stack a line on the CMS program stack + CMSstackQuery() determine the number of lines in the program stack + +For more details on these, see the CMSSYS H file, located on GCCCMS 202. + + +Limitations +----------- + +GCCLIB does not yet implement the complete C runtime library. The following +routines are not yet implemented: + snprintf() stdio.h + + +Since GCCLIB does not use OS simulation, it is not necessary (or possible) to +use the FILEDEF command to define a file via an OS DDNAME. Instead, the +fopen() function has been extended: + + FILE * fopen(const char * filespec, const char * access) + + Open the specified file and return a stream associated with that file. + filespec is a pointer to a string containing the specification of the + file to be opened: + "CONSOLE" terminal console (read or write) + "PRINTER" printer (write only) + "PUNCH" card punch (write only) + "READER" card reader (read only) + filename filetype filemode [F|V [recordLength]] + disk file (read or write), where: + filename is the up to 8 character name. + filetype is the up to 8 character type. + filemode is the up to 2 character disk mode leter and + optional number. + F|V specifies the record format fixed or variable. + It is ignored when opening a file for reading. + reclen specifies the record length. It is required for + fixed-length files, and is taken as the maximum + record length for variable-length files. It is + ignored when opening a file for reading + Each of the above items must be separated by one or more + blanks. + + access specifies how the file will be accessed (i.e. for input, output, + etc): + "r" Open a text file for reading + "w" Create a text file for writing + "a" Append to a text file + "rb" Open a binary file for reading + "wb" Create a binary file for writing + "ab" Append to a binary file + + Notes: + 1. The maximum record length is 65535 bytes. + 2. The maximum number of records in a file is 32768. + 3. The maximum number of 800-byte blocks in a file is 16060. + 4. When writing a text file, a newline character signals the end of the + current record. + 5. When reading a text file, a newline character is inserted at the end + of each record. + 6. When writing a fixed-length text file the buffer will be padded with + blanks if needed. + 7. When writing a fixed-length binary file the buffer will be padded + with NULLs if needed. + 8. Opening a file for writing causes the existing file of that name to + be erased, if it exists. + +GCCLIB does not support I/O redirection. If you need that, use the standard +GCC library, PDPCLIB. In GCCLIB, printf() always prints on the console, and +scanf() always reads from the console. + + +Finally +------- + +This code has not been thoroughly tested. Don't use it for anything important +like controlling a nuclear reactor. I'm just a hobbyist! + +Questions, comments? Post them to the H390-VM group on Yahoo! + +Robert O'Hara diff --git a/PASC370.HELPCMD.D1 b/PASC370.HELPCMD.D1 new file mode 100644 index 0000000..6395b5b --- /dev/null +++ b/PASC370.HELPCMD.D1 @@ -0,0 +1,17 @@ +PASC370 CMS EXEC + +The PASC370 exec is used to convert PASCAL P-CODE into IBM 370 object code +The format of the command is ++---------+-------------------------------------------------------------------+ +| PASC370 | filename | ++---------+-------------------------------------------------------------------+ +where: + +filename + The name of the file to be compiled. It must have a filetype of + "PCODE". + + The output is a loadable TEXT file and a listing of type LIST002 + +Notes: +1. Is called by the PASCAL EXEC. diff --git a/PASCAL.HELPCMD.D1 b/PASCAL.HELPCMD.D1 new file mode 100644 index 0000000..22319b4 --- /dev/null +++ b/PASCAL.HELPCMD.D1 @@ -0,0 +1,19 @@ +PASCAL CMS EXEC + +The PASCAL exec runs the following EXEC to Compile a PASCAL source program +into a CMS Module file. The format of the PASCAL command is ++--------+--------------------------------------------------------------------+ +| PASCAL | filename | ++--------+--------------------------------------------------------------------+ +where: + +filename + The name of the file to be compiled. It must have a filetype of "PASCAL" + +Notes: + +The PASCAL exec calls the following EXECS: + +PASCOMP - Compile the PASCAL tp p-code +PASC370 - Convert the P-Code to IBM Object Code +PASLINK - Call the CMS loader and GENMOD commands to create a module. diff --git a/PASCOMP.HELPCMD.D1 b/PASCOMP.HELPCMD.D1 new file mode 100644 index 0000000..c905268 --- /dev/null +++ b/PASCOMP.HELPCMD.D1 @@ -0,0 +1,17 @@ +PASCOMP CMS EXEC + +The PASCOMP exec is used to translate a PASCAL source program into P-CODE +The format of the command is ++---------+-------------------------------------------------------------------+ +| PASCOMP | filename | ++---------+-------------------------------------------------------------------+ +where: + +filename + The name of the file to be compiled. It must have a filetype of + "PASCAL" + + The output is a P-CODE file. + +Notes: +1. Is called by the PASCAL EXEC. diff --git a/PASLINK.HELPCMD.D1 b/PASLINK.HELPCMD.D1 new file mode 100644 index 0000000..6e8281a --- /dev/null +++ b/PASLINK.HELPCMD.D1 @@ -0,0 +1,15 @@ +PASLINK CMS EXEC + +The PASLINK exec runsis used to load a compiled PASCAL program +into a CMS Module file. The format of the PASLINK command is ++----------+------------------------------------------------------------------+ +| PASCLINK | filename-1 [filename-2 ... filename-n3] | ++----------+------------------------------------------------------------------+ +where: + +filename-1, filename-2, filename-n + Are the names of "TEXT" files to be loaded. + The generated module is saved as filename-1 MODULE A. + +Notes: +1. Is called by the PASCAL EXEC. diff --git a/PDPCLIB.HELPCMD.D1 b/PDPCLIB.HELPCMD.D1 new file mode 100644 index 0000000..b9d532d --- /dev/null +++ b/PDPCLIB.HELPCMD.D1 @@ -0,0 +1,90 @@ + +PDPCLIB - An implemention of the C90 Library for GCC + + PDPCLIB is an implemntation of the C90 runtime library. It has been + implemented on several platforms and the CMS port is based on the + MVS code with minor adaptations to allow it to work in CMS. + + The C90 standard is over 30 years old and so the library does NOT + contain many of the routines a modern programmer expects. Specifically + it includes the routines described in the following header files:- + + + + + + + + + + + + + + + + + + If your "C" program uses a system include that is not in that list, its not + part of PDPCLIB and you may have to port it yourself. + + Using PDPCLIB + ============= + + The GCC EXEC that runs the GCC compiler and the CMS Assembler + uses PDPCLIB by default. The necessary ".h" files + are stored on the GCCCMS 201 disk and the EXEC will link and access + this disk by default. + + The PDPCLIB TXTLIB Y contains the object modules necessary to load + "C" programs that use this library. It must be specified in a + "GLOBAL TXTLIB" command before loading a "C" program. + + As PDPCLIB uses OS QSAM emulation to read and write files, a + "FILEDEF" command is needed for each file that is open. To ease + the burden on "C" programmers and to simpify porting code from + other platforms, the PDPCLIB open routines will issue a FILEDEF + command to create a Dataset Descriptor (DD) for it to use. + + The DD names used are of the form "PDP<00000>" and these may + appear in error messages. If you wish to issue your own FIELDEF + commands use a filename of the form: + + "DD:" + + and PDPCLIB will not issue a FILEDEF, but expect a DD of + to exist. This allows non-disk files such as tapes and printers + to be accessed. + + IO Redirection + ============== + + The PDPCLIB startup routine uses the following DD names for + the standard "C" streams. + + C Stream Name DD name + stdin SYSIN + stdout SYSTERM + stderr SYSPRINT + + If there are no existing FILEDEFS for these streams the startup routine + will issue FILEDEFs to assign them to the VM Console. + + If they are defined it will attempt to use them which permits standard + IO to be re-directed in a clunky way. + + PARM File + ========= + + When PDPCLIB was first ported to CMS there was an issue with passing + the command line to the program. As released VM/CMS splits the command + line into tokens, truncating each token to 8 chacaters. This makes + running tradional "C" programs challenging. In order to allow a full + un-edited command line to be passed the PARMFILE mechanism was concocted. + When the C startup code runs it checks to see if a DD of PARMFILE is + allocated. If it is, it will read the command line from the file and + pass it to main() in argv[]. + + Its not usually necessary to use this as CMS has been modified to + allow access to a full command line, this mechanism remains in place + to permit EXECs that use it to continue to work. diff --git a/PL360.HELPCMD.D1 b/PL360.HELPCMD.D1 new file mode 100644 index 0000000..ea54d0a --- /dev/null +++ b/PL360.HELPCMD.D1 @@ -0,0 +1,37 @@ +PL360 CMS MODULE + +Runs the PL360 Compiler. ++-----------------------------------------------------------------------------+ +| PL360 | fn-1 [fn-2 ... fn-n] [( options ] | +| | | +| | Options: | +| | LIst|NOLIst LOad|NoLoad Deck|NODeck Print|Noprint | +| | TErm|NOTErm DIsk|NODIsk | ++-----------------------------------------------------------------------------+ +where: + +fn-1 [fn-2 ... fn-n] + is the filename of the PL360 file, or files to be compiled. +Options: + + LIst|NOLIST + enables or disables a source listing. + + LOad|NOLoad + controls loading the compiled program. + + Deck|NODeck + controls generating an OBJECT deck. + + Print|NoPrint + put the output on DISK. + + TErm|NOTErm + write diagnostics to the terminal. + + DISK|NODISK + put the listing on DISK. + +Notes: + +1. The user manual is available as PL360MAN LISTING U diff --git a/PL360MAN.LISTING.D1 b/PL360MAN.LISTING.D1 new file mode 100644 index 0000000..1dde32c --- /dev/null +++ b/PL360MAN.LISTING.D1 @@ -0,0 +1,3883 @@ + +1 CONTENTS ++ CONTENTS ++ CONTENTS + + SECTION 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . 1-1 + + SECTION 2. DEFINITION OF THE PL360 ENVIRONMENT + 2.1 Terminology, Notation, and Basic Definitions . . . 2-1 + 2.1.1 The Processor . . . . . . . . . . . . . . . 2-1 + 2.1.2 Relationships . . . . . . . . . . . . . . . 2-2 + 2.1.3 The Program . . . . . . . . . . . . . . . . 2-2 + 2.1.4 Syntax . . . . . . . . . . . . . . . . . . 2-2 + 2.2 Identifiers and Basic Symbols . . . . . . . . . . 2-3 + 2.2.1 Identifiers . . . . . . . . . . . . . . . . 2-4 + 2.2.2 Basic Symbols . . . . . . . . . . . . . . . 2-4 + 2.2.3 Standard Identifiers . . . . . . . . . . . 2-5 + + SECTION 3. VALUES + 3.1 Hexadecimal Values . . . . . . . . . . . . . . . . 3-1 + 3.2 Decimal Values . . . . . . . . . . . . . . . . . . 3-1 + 3.3 Numeric Values . . . . . . . . . . . . . . . . . . 3-2 + 3.4 String Values . . . . . . . . . . . . . . . . . . 3-2 + + SECTION 4. PROGRAM FORMAT + 4.1 Block Structure . . . . . . . . . . . . . . . . . 4-1 + 4.2 Program Segmentation . . . . . . . . . . . . . . . 4-3 + 4.3 Data Segmentation . . . . . . . . . . . . . . . . 4-3 + 4.4 Main Program . . . . . . . . . . . . . . . . . . . 4-4 + + SECTION 5. DECLARATIONS + 5.1 Register Synonym Declarations . . . . . . . . . . 5-1 + 5.2 Segment Base Declarations . . . . . . . . . . . . 5-1 + 5.3 Cell Declarations . . . . . . . . . . . . . . . . 5-2 + 5.4 Cell Designators . . . . . . . . . . . . . . . . . 5-3 + 5.5 Cell Synonym Declarations . . . . . . . . . . . . 5-4 + 5.6 EQUATE Declarations . . . . . . . . . . . . . . . 5-5 + + SECTION 6. STATEMENTS + 6.1 Register Assignments . . . . . . . . . . . . . . . 6-1 + 6.2 Register Assignment Expressions . . . . . . . . . 6-2 + 6.3 Cell Assignments . . . . . . . . . . . . . . . . . 6-3 + 6.4 GOTO Statements and Labels . . . . . . . . . . . . 6-4 + 6.5 Conditions and Compound Conditions . . . . . . . . 6-4 + 6.6 IF Statements . . . . . . . . . . . . . . . . . . 6-6 + 6.7 WHILE Statements . . . . . . . . . . . . . . . . . 6-6 + 6.8 FOR Statements . . . . . . . . . . . . . . . . . . 6-7 + 6.9 CASE Statements . . . . . . . . . . . . . . . . . 6-7 + + SECTION 7. FUNCTIONS + 7.1 Function Declarations . . . . . . . . . . . . . . 7-1 + 7.2 Function Statements . . . . . . . . . . . . . . . 7-1 + + SECTION 8. PROCEDURES + 8.1 Procedure Declarations . . . . . . . . . . . . . . 8-1 + 8.2 Procedure Statements . . . . . . . . . . . . . . . 8-2 + + SECTION 9. THE RUN-TIME LIBRARY + 9.1 Standard Procedures . . . . . . . . . . . . . . . . 9-1 + 9.2 Number Conversion Procedures . . . . . . . . . . . 9-2 + 9.3 Data Manipulation Procedures . . . . . . . . . . . 9-4 +B i +1 + SECTION 10. COMPILER CONTROL FACILITIES + 10.1 Instructions to the Compiler . . . . . . . . . . . 10-1 + 10.1.1 Listing Control . . . . . . . . . . . . . 10-1 + 10.1.2 Listing Options . . . . . . . . . . . . . 10-1 + 10.1.3 Operating System Control . . . . . . . . . 10-2 + 10.1.4 Identification . . . . . . . . . . . . . . 10-2 + 10.1.5 Program Base Register Control . . . . . . 10-2 + 10.1.6 Object Deck Control . . . . . . . . . . . 10-3 + 10.1.7 Copy Facility . . . . . . . . . . . . . . 10-3 + 10.1.8 Conditional Compile Directives . . . . . . 10-3 + 10.2 Compiler Listing Output . . . . . . . . . . . . . 10-4 + 10.3 Error Messages of the Compiler . . . . . . . . . . 10-5 + 10.4 Compiler Object Program Output . . . . . . . . . . 10-6 + + SECTION 11. LINKAGE CONVENTIONS + 11.1 Calling External Routines from PL360 . . . . . . . 11-1 + 11.2 Requesting Supervisor Services . . . . . . . . . . 11-2 + 11.3 Calling PL360 Procedures from External Routines . 11-2 + + SECTION 12. PL360 AS AN ORVYL LANGUAGE PROCESSOR + 12.1 Using the PL360 Compiler with ORVYL . . . . . . . 12-1 + 12.2 Input/Output Subroutines for + Interactive PL360 Programs . . . . . . . . . . . 12-3 + + APPENDIX A. EXAMPLE PROGRAMS AND LISTINGS + Sample Program Demonstrating Extensions to PL360 . . . A-1 + Right Triangle Problem . . . . . . . . . . . . . . . . A-6 + Global Procedure TRTEST . . . . . . . . . . . . . . . A-9 + ORVYL Program to Set Options . . . . . . . . . . . . . A-11 + + APPENDIX B. THE OBJECT CODE . . . . . . . . . . . . . . . . . . . B-1 + + APPENDIX C. COMPILER CONSTRUCTS . . . . . . . . . . . . . . . . . C-1 + + APPENDIX D. SYNTACTIC INDEX . . . . . . . . . . . . . . . . . . . D-1 + + APPENDIX E. SYNTACTIC ENTITIES . . . . . . . . . . . . . . . . . . E-1 + + + + + TABLES ++ TABLES ++ TABLES + + Table 6.1 Allowable Cell and Register Type Combinations . . . . . 6-1 + Table 6.2 Allowable Cell and Value Combinations . . . . . . . . . 6-3 + Table 6.3 Condition Code States . . . . . . . . . . . . . . . . . 6-5 + + Table 7.1 Instruction Format . . . . . . . . . . . . . . . . . . . 7-2 + + Table B.1 Object Code Operators . . . . . . . . . . . . . . . . . B-1 + + Table C.1 2-Byte Instructions . . . . . . . . . . . . . . . . . . C-2 + Table C.2 4-Byte Instructions . . . . . . . . . . . . . . . . . . C-3 +B ii +1 + REFERENCES ++ REFERENCES ++ REFERENCES + + + [1] N. Wirth: PL360. "A Programming Language for the 360 Computers," + JACM 15 (1968) 37. + + [2] SCIP/Academic Computing Services Program Libraries, Polya Hall + Stanford University. + + [3] J. Eve: "PL360 Language Extensions," Internal Note, Computing + Laboratory. University of Newcastle upon Tyne. + + [4] G. M. Amdahl, G. A. Blaauw, F. P. Brooks, Jr.: "Architecture + of the IBM System/360," IBM Journal of Research and Development 8 + (1964) 87. + + [5] G. A. Blaauw et al. "The structure of System/360," IBM Systems + Journal 3 (1964) 119. + + [6] "IBM System/360 Principles of Operation," IBM A22-6821. + + [7] "IBM System/360 OS Assembler Language," IBM C28-6514. + + [8] MTS Vol. I, University of Michigan Computation Center, Ann Arbor. + + [9] "IBM System/360 Linkage Editor and Loader" IBM C28-6538. + + [10] "PL360 Programming Manual," University Computing Laboratory, + University of Newcastle upon Tyne, Caremont Tower, Newcastle upon + Tyne, NE1 7RU, England, 1970. + + [11] "IBM System/360 DOS System Control and System Service Programs," + IBM C24-5036 + + [12] R. Fajman and J. Borgelt, "ORVYL User's Guide," Stanford + University Computation Center, 1971. + + [13] "IBM System/360 Disk Operating System Supervisor and Input/Output + Macros," IBM C24-5037. + + [14] N. Wirth: "Format of PL360 Programs," ALGOL W - Project Memo, + Stanford University, Sept. 9, 1966. +B iii +1 + FOREWORD ++ FOREWORD ++ FOREWORD + + The intent of this manual is to provide a reference tool for programmers + using PL360. Although it is not a textbook, it has been organized in + such a way that each section introduces new material dependent on + information covered in preceding sections. In that sense, it can serve + as a self-teaching aid. + + Those readers not familiar with Bacus-Naur Form (BNF), may find the + syntactic rules used to describe the language difficult to understand. + However, the textual descriptions and examples associated with a set of + syntactic rules should serve to clarify those rules. Also, the sample + programs of Appendix A further clarify the language structure. + + Knowledge of the 360 architecture [4, 5 or 6] is a prerequisite for + understanding the language definition and some familiarity with the 360 + Assembly Language [7] and linkage editor [8] is assumed in the + description of the object code produced by the compiler. + + In writing this manual, the authors have drawn heavily upon the + (anonymous) PL360 Programming Manual published by the University of + Newcastle upon Tyne, Computing Laboratory [10]. + +B iv +1 + SECTION 1. INTRODUCTION ++ SECTION 1. INTRODUCTION ++ SECTION 1. INTRODUCTION + + PL360 is a programming language designed specifically for the IBM + System/360 computers. It provides the facilities for a symbolic machine + language but displays a structure similar to that of ALGOL. A formal + description of an earlier version of the language has been published by + Niklaus Wirth [1] who directed the development of the PL360 language and + its compiler at the Computer Science Department of Stanford University. + Although PL360 was originally designed for writing logically + self-contained programs, subsequent extensions permit communication with + separately compiled programs. + + An efficient one pass "in core" compiler, written by Niklaus Wirth, + Joseph W. Wells, Jr. and Edwin Satterthwaite, Jr., which incorporates + these extensions is available through the Stanford Program Library [2]. + This compiler translates PL360 source code into object modules in the + format required by several 360 operating systems (OS and MTS for + example). The documentation issued with the compiler includes several + amendments to the original language definition. Further extensions were + carried out at the University of Newcastle by James Eve. These changes + [3,10] were aimed primarily at relaxing the linkage constraints on + separately compiled programs, enabling for example direct communication + with programs using OS/360 type linkages. Michael Malcolm of the + Stanford Computer Science Department made several modifications to the + version of the compiler produced by James Eve. These extensions made it + possible to run the compiler and compiled programs under DOS operating + systems. Assembly language subroutines were also written for both OS + and DOS to facilitate input-output with sequential tape and disk files. + Dick Guertin of the Stanford Center for Information Processing extended + the syntax of PL360, primarily to increase programming convenience. He + has also written assembly language interfaces to allow interactive use + of both the PL360 compiler and PL360 programs under the ORVYL + time-sharing monitor at Stanford. Andrew Koening of Columbia University + also contributed improvements to the compiler. + + The language definition and compiler description incorporating all + changes are given in this manual. For a full discussion of the + background underlying the development of PL360 and a description of the + organization and development of the compiler together with some + perceptive comments on the 360 architecture, reference must still be + made to [1], where the aims of the language are summarized: + + ... it was decided to develop a tool which would: + 1. allow full use of the facilities provided by the 360 + hardware, + 2. provide convenience in writing and correcting programs, and + 3. encourage the user to write in a clear and comprehensible + style. + + As a consequence of 3, it was felt that programs should not be + able to modify themselves. The language should have the + facilities necessary to express compiler and supervisor + programs, and the programmer should be able to determine every + detailed machine operation. +B 1-1 +1 + SECTION 2. DEFINITION OF THE PL360 ENVIRONMENT ++ SECTION 2. DEFINITION OF THE PL360 ENVIRONMENT ++ SECTION 2. DEFINITION OF THE PL360 ENVIRONMENT + + 2.1 Terminology, Notation, and Basic Definitions ++2.1 Terminology, Notation, and Basic Definitions ++2.1 Terminology, Notation, and Basic Definitions + + The language is defined in terms of a computer which is comprised of a + number of processing units and a finite set of storage elements. Each + of the storage elements holds a content, also called value. At any + given time, certain significant relationships may exist between storage + elements and values. These relationships may be recognized and altered, + and new values may be created by the processing units. The actions + taken by the processors are determined by a program. The set of + possible programs form the language. A program is composed of, and can + therefore be decomposed into elementary constructions according to the + rules of a syntax, or grammar. To each elementary construction + corresponds an elementary action specified as a semantic rule of the + language. The action denoted by a program is defined as the sequence of + elementary actions corresponding to the elementary constructions which + are obtained when the program is decomposed (parsed) by reading from + left to right. + + + 2.1.1 The Processor ++2.1.1 The Processor ++2.1.1 The Processor + + At any time, the state of the processor is described by a sequence of + bits called the program status word (PSW). The status word contains, + among other information, a pointer to the next instruction to be + executed, and a quantity which is called the condition code. + + Storage elements are classified into registers and core memory cells, + simply called cells. Registers are divided into three types according + to their size and the operations which can be performed on their values. + The types of registers are: + + a. integer or logical (a sequence of 32 bits) + b. real (a sequence of 32 bits) + c. long real (a sequence of 64 bits) + + Cells are classified into five types according to their size and the + type of value which they may contain. A cell may be structured or + simple. The types of simple values and simple cells are: + + a. byte or character (a sequence of 8 bits = 1 byte) + b. short integer (a sequence of 16 bits = 2 bytes, interpreted + as an integer in two's complement binary notation) + c. integer or logical (a sequence of 32 bits = 4 bytes, + interpreted as an integer in two's complement binary + notation) + d. real (a sequence of 32 bits = 4 bytes, interpreted as a + base-16 floating-point number) + e. long real (a sequence of 64 bits = 8 bytes, interpreted as + a base-16 floating-point number) + + The types integer and logical are treated as equivalent in the language, + and consequently only one of them, namely integer, will be mentioned + throughout this manual. Likewise, byte and character are equivalent and + only byte is mentioned. +B 2-1 +1 + 2.1.2 Relationships ++2.1.2 Relationships ++2.1.2 Relationships + + The most fundamental relationship is that which exists between a cell + and its value. It is known as containment; the cell is said to contain + the value. + + Another relationship exists between the cells which are the components + of a structured cell, called an array, and the structured cell itself. + It is known as subordination. Structured cells are regarded as + containing the ordered set of the values of the component cells. + + A set of relationships between values is defined by monadic and dyadic + functions or operations, which the processor is able to evaluate or + perform. The relationships are defined by mappings between values (or + pairs of values) known as the operands, and values known as the results + of the evaluation. These mappings are not precisely defined in this + manual; instead, see [6]. + + + 2.1.3 The Program ++2.1.3 The Program ++2.1.3 The Program + + A program contains declarations and statements. Declarations serve to + list the cells, registers, procedures, and other quantities which are + involved in the algorithm described by the program, and to associate + names, called identifiers, with them. Statements specify the operations + to be performed on these quantities, to which they refer through the use + of identifiers. + + A program is a sequence of tokens, which are basic symbols, strings or + comments. Every token is itself a sequence of characters. The + following conventions are used: + + a. Basic symbols constitute the basic vocabulary of the + language (cf. 2.2.2). They are either single characters, + or uppercase letter sequences. + b. Strings are sequences of characters enclosed in quote marks + i.e. "string" (cf. 3.4). + c. Comments are sequences of characters (not containing a + semicolon) preceded by the basic symbol COMMENT and + followed by a semicolon (;). Comments may also be written + as a sequence of characters between vertical bars (!). + Thus, ! this is a comment ! It is understood that comments + have no effect on the execution of a program. + + In order that a sequence of tokens be an executable program, it must be + constructed according to the rules of the syntax. + + + 2.1.4 Syntax ++2.1.4 Syntax ++2.1.4 Syntax + + A sequence of tokens constitutes an instance of a syntactic entity (or + construct), if that entity can be derived from the sequence by one or + more applications of syntatic substitution rules. In each such + application, the sequence equal to the right side of the rule is + replaced by the symbol which is its left side. +B 2-2 +1 + Syntactic entities (cf. Appendix D, E) are denoted by english words + enclosed in brackets < and >. These words describe approximately the + nature of the syntatic entity, and where these words are used elsewhere + in the text, they refer to that syntactic entity. For reasons of + notational convenience and brevity, the uppercase letters A, K, and T + are also used in the denotation of syntactic entities. They stand as + abbreviations for any of the following words (or pairs): + + A K T ++ A K T ++ A K T + + long real long real long real + real real real + integer integer integer + short integer short integer + byte + + Syntactic rules are of the form ::= & where is a syntactic + entity (called the left side) and & is a finite sequence of tokens and + syntactic entities (called the right side of the rule). The notation + + ::= &1 ! &2 ! ... ! &n + + is used as an abbreviation for the n syntactic rules + + ::= &1, ::= &2, ..., ::= &n + + If in the denotations of constituents of the rule the uppercase letters + A, K, or T occur more than once, they must be replaced consistently, or + possibly according to further rules given in the accompanying text. As + an example, the syntactic rule + + ::= + + is an abbreviation for the set of rules + + ::= + ::= + ::= + + + 2.2 Identifiers and Basic Symbols ++2.2 Identifiers and Basic Symbols ++2.2 Identifiers and Basic Symbols + + The implementation imposes the restriction that only the first 10 + characters of identifiers are recognized as significant. + + Throughout this section, user defined identifiers are shown in lowercase + letters to distinguish them from standard identifiers and basic symbols. + In actual practice, all identifiers are constructed from uppercase + letters. +B 2-3 +1 + 2.2.1 Identifiers ++2.2.1 Identifiers ++2.2.1 Identifiers + + ::= A!B!C!D!E!F!G!H!I!J!K!L!M!N!O!P!Q!R!S!T!U!V!W!X!Y!Z + ::= 0 ! 1 ! 2 ! 3 ! 4 ! 5 ! 6 ! 7 ! 8 ! 9 + ::= ! ! + ::= + ::= + ::= + ::= + ::= + + An identifier is a K-register, T-cell, procedure, function, or integer + value identifier, if it has respectively been associated with a + K-register, T-cell, procedure, function, or integer value (called a + quantity) in one of the blocks surrounding its occurrence (cf. 4.1). + This association is achieved by an appropriate declaration. The + identifier is said to designate the associated quantity. If the same + identifier is associated with more than one quantity, then the + considered occurrence designates the quantity to which it was associated + in the innermost block embracing the considered occurrence. In any one + block, an identifier must be associated with exactly one quantity. In + the parse of a program, that association determines which of the rules + given above applies. + + Any processing computer and operating system can be considered to + provide an environment in which the program is embedded, and in which + some identifiers are permanently declared. Some identifiers are assumed + to be known in every environment; they are called standard identifiers, + and are listed in Section 2.2.3. + + + 2.2.2 Basic Symbols ++2.2.2 Basic Symbols ++2.2.2 Basic Symbols + + Basic symbols which consist of uppercase letter sequences shown below + are denoted by the same letter sequences without further distinction. + Such letter sequences are called reserved words and cannot be used as + identifiers. Embedded blanks are not allowed in reserved words, + identifiers, and numbers. Adjacent reserved words, identifiers, and + numbers must be separated by at least one blank or other + non-alphanumeric. Otherwise, blanks may be used freely. The basic + symbols are: + + + - * / ( ) = < > ¬ + , ; . : @ # _ " ' ! + DO IF OF OR + ABS AND END FOR NEG SYN XOR + BASE BYTE CASE DATA ELSE GOTO LONG NULL + REAL SHLA SHLL SHRA SHRL STEP THEN + ARRAY BEGIN CLOSE DUMMY SHORT UNTIL WHILE + COMMON EQUATE GLOBAL + COMMENT INTEGER LOGICAL SEGMENT + EXTERNAL FUNCTION REGISTER + CHARACTER PROCEDURE +B 2-4 +1 + 2.2.3 Standard Identifiers ++2.2.3 Standard Identifiers ++2.2.3 Standard Identifiers + + The following identifiers are predeclared in the language but may be + redeclared due to block structure. Their predefined meanings are + specified in Section 5, Section 7.1, or Section 9.1. + + MEM + B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 B13 B14 B15 + R0 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 + F0 F2 F4 F6 + F01 F23 F45 F67 + BALR CLC CLI CVB CVD ED EDMK EX IC + LA LH LM LTR MVC MVI MVN MVZ NC NI OC OI PACK + RESET SET SLDA SLDL SPM SRDA SRDL STC STH STM SVC + TEST TM TR TRT TS UNPK XC XI + CARRY FALSE MIXED OFF ON OVERFLOW STRING TRUE + CANCEL GET KLOSE OPEN PAGE PRINT PUNCH PUT READ WRITE +B 2-5 +1 + SECTION 3. VALUES ++ SECTION 3. VALUES ++ SECTION 3. VALUES + + 3.1 Hexadecimal Values ++3.1 Hexadecimal Values ++3.1 Hexadecimal Values + + Values may be expressed in hexadecimal notation. + + ::= ! A ! B ! C ! D ! E ! F + ::= # + ! + + A hexadecimal value denotes a sequence of bits. Each hexadecimal digit + stands for a sequence of four bits defined as follows: + + 0 = 0000 4 = 0100 8 = 1000 C = 1100 + 1 = 0001 5 = 0101 9 = 1001 D = 1101 + 2 = 0010 6 = 0110 A = 1010 E = 1110 + 3 = 0011 7 = 0111 B = 1011 F = 1111 + + Note: If hexadecimal values are used in conjunction with arithmetic or + logical operators in a program, they must be considered as a sequence of + bits which constitute the computer's representation of the number on + which the operator is applied. Hexadecimal values followed by the + letter R or L may be used to denote numbers in unnormalized + floating-point representation [4,5,6]. + + + 3.2 Decimal Values ++3.2 Decimal Values ++3.2 Decimal Values + + ::= + ! + ::= S + ::= . + ! + ::= + ::= + ! ' + ! ' + ::= + ! R + ::= L + ! L + ::= + ! _ + + Integer, real, and long real numbers are represented in decimal + notation. The latter two can be followed by a scale factor denoting an + integral power of 10. Short integers are distinguished from integers by + the letter S following the number. In order to denote a negative + number, an unsigned number is preceded by the underscore symbol "_". + (Note: the underscore is used so as not to confuse negative values with + the subtract operator "-", which is never part of a number.) + + Note: A-number is an abbreviation for long real number, real number, + short integer number and integer number as defined in section 2.1.4 as a + notational convenience. +B 3-1 +1 + 3.3 Numeric Values ++3.3 Numeric Values ++3.3 Numeric Values + + ::= X + ::= + ! S + ::= + ! + ! + ::= + ! R + ::= + ! L + + Examples: + + byte values: 2X _5X + short integer values: 10S #FF00S + integer values: 0 #106C _1 size + real values: 1.0 _3.14 2.7'8 #46000001R + long real values: 0L 3.14159265359L #4E00000000000001L + + + 3.4 String Values ++3.4 String Values ++3.4 String Values + + There are also string values, but these are not generally used in + conjunction with arithmetic or logical operators. + + ::= " " + ! X + ::= + ! + ::= ! "" + + When a string is a character sequence enclosed in quote marks, the + string is limited to a total of 255 characters. If a quote mark (") is + to be a character of the sequence, it is represented by a pair of + consecutive quote marks. + + When a string is a hexadecimal value ending in X, up to 16 hexadecimal + digits may be specified. Each pair of hexadecimal digits represents one + character. If the number of hexadecimal digits specified is odd, a + hexadecimal 0 is prefixed to the specified value to make the total even. + + Examples: "ABC" denotes the sequence ABC + "A""Z" denotes the sequence A"Z + #C1C2C3X denotes the sequence ABC +B 3-2 +1 + SECTION 4. PROGRAM FORMAT ++ SECTION 4. PROGRAM FORMAT ++ SECTION 4. PROGRAM FORMAT + + Compiler input records consist of 80 characters. The first 72 + characters of each record are processed as part of a PL360 program; + characters 73 through 80 are listed but not otherwise processed. + Character 72 of one record is considered to be immediately followed by + character 1 of the next record. Character position 1 may contain any + character except '$' or any other character (e.g., /) that would signal + a compiler control statement or job control statement. + + + 4.1 Block Structure ++4.1 Block Structure ++4.1 Block Structure + + ::= . ! + GLOBAL ; . ! + GLOBAL BASE ; + ::= END + ::= ! ; ! +