MONITOR PROGRAMS

The Monitor programs: Supervisor, DUP, Assembler, FORTRAN Compiler, Core Load Builder, and Core Image Loader reside in the IBM System Area on the master cartridge. The following paragraphs briefly describe these programs and the subprograms within them that are of most interest to the user.

SUPERVISOR

The Supervisor is actually a group of programs and areas which are responsible for the control functions of the Monitor system. The Supervisor reads control records included in the stacked job input, decodes them, and calls the appropriate Monitor program to perform the specified operation. The Supervisor initially achieves control of the Monitor system through the user-initiated cold start procedure (see Cold Start).

A portion of the Supervisor is located in core storage. This portion is called the Resident Monitor.

RESIDENT MONITOR

The resident portion of the Monitor system consists of (1) a data area used for system parameters and for communication between Monitor programs (COMMA), (2) the Skeleton Supervisor, and (3) a disk I/O subroutine (either DISKZ, DISK1, or DISKN).

Core Communications Area (COMMA)

In general, COMMA consists of the parameters required by the Core Image Loader to process a CALL LINK to a DCI program without referring to the Disk Communications area (DCOM). This information is interspersed with parts of the Skeleton Supervisor (see Appendix H, Resident Monitor).

Skeleton Supervisor

On any entry to the Resident Monitor (EXIT, LINK, or DUMP), the Skeleton Supervisor calls the Core Image Loader, which determines where the Skeleton Supervisor was entered and either calls the Supervisor if the entry was at EXIT or DUMP or fetches and transfers control to the core load specified in the CALL LINK statement if the entry was at LINK. (If the link to be executed is in Disk System format, it will be necessary to call the Core Load Builder before transferring control to the core load itself.)

The use of the Core Image Loader as an intermediate supervisor allows the Monitor system to achieve efficient link-to-link transfer of control.

The Skeleton Supervisor, which is interspersed with COMMA, consists of the entry points and subroutines described below.

LINK Entry Point. LINK is the entry point in the Skeleton Supervisor that accomplishes link-to-link transfer of control.

EXIT Entry Point. EXIT is the entry point in the Skeleton Supervisor that accomplishes link-to-Supervisor transfer of control.

DUMP Entry Point. DUMP is the entry point in the Skeleton Supervisor that prints out the contents of core storage between specified limits. Dynamic dumps are obtained through the DUMP entry point; terminal dumps are obtained through the DUMP entry point plus 1.

ILS02 Subroutine. The ILS02 subroutine handles the servicing of interrupts on level 2. Only the disk devices on the system interrupt on level 2. Since the Skeleton Supervisor requires the disk, the ILS02 subroutine is a part of the Resident Monitor.

ILS04 Subroutine. The ILS04 subroutine handles the servicing of interrupts on level 4. One of the devices that interrupt on level 4 is the Keyboard. Since the user may perform a console interrupt request at any time, the ILS04 subroutine is a part of the Resident Monitor.

Preoperative Error Trap. The preoperative error trap is entered by all ISS subroutines when an error is detected before an operation has been initiated. The trap consists of a WAIT and a branch. When the PROGRAM START key is pressed, execution resumes at the location following the branch to this trap. Under certain conditions, this trap is entered when no error has occurred, e.g., FORTRAN PAUSE.

Postoperative Error Traps. One of the postoperative error traps (there is one for each interrupt level) is entered by all ISS subroutines when an error is detected after an operation has been initiated. Each trap consists of a WAIT and a branch. When the PROGRAM START key is pressed, control is returned to the ISS subroutine, which may then retry the operation in error.

PROGRAM STOP Key Trap. The PROGRAM STOP key trap is entered if a level 5 interrupt occurs and there is no user-written device subroutine associated with level 5 currently in core. The trap consists of a WAIT and a branch. When the PROGRAM START key is pressed, the interrupt level is turned off and execution resumes following the point of the level 5 interrupt.

This trap allows the user to stop the entire 1130 system with the ability to continue execution without disturbing the system status or the contents of core storage.

If a higher interrupt level is being serviced when the PROGRAM STOP key is pressed, the PROGRAM STOP key interrupt is masked until the current operation is completed.

Interrupt Request Key

When the INT REQ key is pressed, all busy indicators are turned off and a switch in COMMA is set to instruct the Supervisor to pass input records until a JOB record is encountered. Parts of the Monitor which should not be interrupted before completion, e. g., SYSUP, delay the interrupt request until they have completed their operation.

Disk I/O Subroutine

The disk I/O subroutine required by the program in control resides in core storage following the Skeleton Supervisor. The following table lists the disk I/O subroutines, their approximate sizes, and the corresponding addresses of the end of the Resident Monitor plus 1.

DISKZ is the disk I/O subroutine used by all system programs. DISKZ is initially loaded with the Resident Monitor.

Prior to the execution of a core load requiring DISK1 or DISKN, the Core Image Loader overlays DISKZ with the required disk I/O subroutine. When control is returned to the Supervisor, the Core Image Loader overlays the disk I/O subroutine currently in core (if DISK1 or DISKN) with DISKZ. User programs, including those written in FORTRAN language, may use any of the three disk I/O subroutines; however, only one disk I/O subroutine may be referenced in a given core load. In this context "core load" includes column 19 of the XEQ record (the entry in column 19 of the XEQ record specifies the version of the disk I/O subroutine to be used by the core load during execution).

DISK-RESIDENT SUPERVISOR PROGRAMS

The programs described below are the disk-resident programs that constitute the Supervisor. One of these programs is fetched and given control by the Core Image Loader, depending upon the entry made in the Skeleton Supervisor; the Monitor Control Record Analyzer is called following an EXIT entry, the DUMP program following, a DUMP entry.

Monitor Control Record Analyzer

The Monitor Control Record Analyzer (1) reads a Monitor control record or Supervisor control record from the input stream, (2) prints the control record on the principal print device, and (3) fetches the required Monitor program and transfers control to it. Supervisor control records are stored on disk in the Supervisor Control Record Area.

Supervisor Control Record Area. The Supervisor Control Record Area is the area on disk, within the IBM System Area, on which the FILES, LOCAL, and NOCAL control records are stored from the input stream. The Core Load Builder reads these records from this area on disk for analysis during the building of the core image program.

MONITOR CONTROL RECORDS

Monitor control records perform the load and control functions of the Monitor system. The individual control records are described in the paragraphs that follow.

Where shown in the control record format, the character "b" indicates that the column must be blank. Remarks may be punched in the card columns listed as "not used" in the control record formats.

// JOB

The JOB control record defines the start of a new job. It causes the Supervisor to perform the job initialization procedure, which includes:

• The initialization of COMMA

• The initialization of the parameters in DCOM

• The setting of the Temporary Mode Indicator if a T is present in column 8 of the JOB control record (reset if no T in column 8). If set, the temporary mode indicator causes all DSF programs, DCI programs, or Data files stored in the User Area by DUP during the current job to be deleted automatically from that area at the end of the job (that is, at the beginning of the next job). See DCOM for DUP restrictions while in the temporary mode.

• The definition of the cartridges to be used during the current job. IDs 1 through 5 on the JOB control record specify the cartridges to be used. These cartridges may be mounted on the physical drives in any order. The order of the IDs in the JOB control record specifies the logical assignments for the cartridges. IDs 1 through 5 correspond to logical drives 0 through 4, and they must be specified consecutively. If only three drives are to be used IDs 1-3 only are specified. The cartridge-related entries of COMMA and DCOM (quintuples) are filled in according to the logical order specified by the user. The first ID may be left blank, in which case the master cartridge for the last JOB will also be the master for this JOB.

• The definition of the cartridge on which the Core Image Buffer for the current job is to be found. The ID of the cartridge containing the CIB must follow the field of the fifth cartridge ID. If the CIB ID is omitted, the CIB on the master cartridge is used. Core image programs can be built faster if the CIB is assigned to a cartridge other than the master cartridge.

• The definition of the cartridge containing the Working Storage to be used by the Monitor programs (System Working Storage). The ID of the cartridge to be used for Working Storage by the Monitor System must follow the CIB ID. If the Working Storage ID is omitted, all Monitor programs use the Working Storage on the master cartridge (except when otherwise specified, see DUP Control Records). Core Image programs can be built faster if the System Working Storage is on a cartridge other than the master cartridge. They can be built even faster if the CIB, the system Working Storage, and the Monitor system itself are all on separate cartridges. Assemblies are also faster if System Working Storage is on a separate cartridge.

• The definition of the cartridge containing the unformatted I/O ($$$$$) disk buffer area to be used with this job.

• The starting of a new page on the principal print device. A skip to channel 1 is executed on the 1132 or 1403 Printer; or five consecutive carriage returns are made on the Console Printer. The page count is reset to 1, and the current page heading is replaced with whatever appears in columns 51-58 of the JOB control record. HDNG (assembler language) statements and **(FORTRAN control record) records will cause additional information to be printed.

The format of the JOB control record is as follows.

// ASM

This control record causes the Supervisor to read the Assembler into core storage and transfer control to it. Any Assembler control records and the source statements to be assembled must follow this control record. Comments control records (// *) may not follow this control record.

The format of the ASM control record is as follows.

(See *FILES, p. 23 for working storage for user programs.)

// FOR

This control record causes the Supervisor to read the FORTRAN Compiler into core storage and transfer control to it. Any FORTRAN control records and the source statements to be compiled must follow this control record. Comments control records (// *) may not follow this control record.

The format of the FOR control record is as follows.

// DUP

This control record causes the Supervisor to read the control portion of the Disk Utility Program into core storage and transfer control to it. A DUP control record must follow this control record. Only one // DUP control record is required to process a stack of DUP control records, provided no Monitor control record other than the Comments control record (// *) is encountered.

The format of the DUP Monitor control record is as follows.

// XEQ

This control record causes the Supervisor to initialize for core load execution. If the name specified in this control record (columns 8 through 12) is that of a mainline program stored in Disk System format, the Supervisor reads the Supervisor control records (LOCAL, NOCAL, or FILES), if any, from the input stream and writes them in the Supervisor Control Record Area (SCRA). The Core Load Builder is then called to build a core image program from the mainline program.

If no name is specified on this control record, a mainline program in Disk System format is assumed to be stored in the Working Storage of the cartridge specified in columns 21-24. The Supervisor then processes the Supervisor control records and calls the Core Load Builder via the LINK entry point in the Resident Monitor.

After the Core Image program has been built, or if the name in the control record is that of a program already stored on disk in DCI format, the Core Image Loader is called to read the core load into core storage and transfer control to it.

If an L is punched in column 14 of this control record, a core map is printed by the Core Load Builder during the building of the core image program. In addition, a core map is printed for all DSF links during the execution (see Reading a Core Map and a File Map for an example of a core map). These core maps include:

• The execution address of the mainline program
• The names and execution addresses of all subprograms in the core load
• All file allocations, with the file number, sector address (relative to first sector of Working Storage for files in Working Storage, absolute otherwise), sector count, and either cartridge ID or the address of Working Storage. (If the file is in Working Storage, the address of Working Storage will be included; otherwise, the name of the file is printed.)

Columns 16 and 17 of this control record contain the right-justified decimal count of Supervisor control records to be read by the Supervisor before calling the Core Load Builder.

Column 19 contains a character that identifies the disk I/O subroutine to be used by the core load during execution. If column 19 contains zero or one, DISK1 is fetched by the Core Image Loader along with the core load. If Column 19 contains an N, DISKN is fetched. If column 19 contains a blank or a Z, no disk I/O subroutine is fetched (that is, DISKZ, which is in core storage for use by the Monitor programs, is used by the core load). Any other character is illegal and will cause the execution to be bypassed. All links in Disk System format that are called during a given execution must utilize the same disk I/O subroutine as the link that precedes them in execution.

Comments control records (// *) may not follow an XEQ control record.

The format of the XEQ control record is as follows.

// PAUS

This control record causes the Supervisor to WAIT. When PROGRAM START is pressed, the Supervisor continues processing Monitor control records from the input stream.

The format of the PAUS control record is as follows.

// TYP

This control record causes the Supervisor to temporarily assign the Keyboard as the principal input device. The Keyboard replaces the card or paper tape reader as the principal input device until a TEND or JOB control record is entered from the Keyboard.

The format of the TYP control record is as follows.

With the Keyboard as the principal input device, the keyboard functions are identical to those discussed for TYPEZ and TYPE0 (System Library Subroutines) with one exception. The END-OF-MESSAGE character causes the rest of the buffer to be filled with blanks. Therefore, at the completion of a new message, nothing will remain of any previously-entered message.

// TEND

This control record causes the Supervisor to reassign the card or paper tape reader as the principal input device. The reassignment is to whichever unit was the principal device prior to the detection of a TYP control record.

The TEND control record must be entered from the Keyboard. The format of the TEND control record is as follows.

// EJECT

This control record causes the 1403 Printer or 1132 Printer, whichever is the principal print device, to skip to a new page and print the page header. Control is then returned to the Supervisor, which reads the next record in the input stream. The EJECT control record itself is printed.

The format of the EJECT control record is as follows.

// *(comments)

This control record allows the user to print alphameric text on the listing printed on the principal print device by the Supervisor and DUP. The Supervisor and DUP simply print the control record and continue reading control records from the input stream. The Comments control record may not immediately follow an XEQ, ASM, or FOR control record.

The format of the Comments control record is as follows.

// CPRNT

This control record causes the Supervisor to print all Monitor and Supervisor control records that it reads on the Console Printer. Printing by all other Monitor programs will be on the principal print device.

Once the CPRNT control record has taken effect, all Monitor and Supervisor control records will be printed as described above. To return the printing of Monitor and Supervisor control records to the principal print device, a reload function must be performed by the System Loader to redefine the principal print device.

The format of the CPRNT control record is as follows.

SUPERVISOR CONTROL RECORDS

The control records described below (LOCAL, NOCAL, and FILES) are used by the Core Load Builder to:

• Provide for subprogram overlays during execution (LOCAL)
• Include subprograms not called in the core load (NOCAL)
• Equate disk storage files defined in the mainline program during compilation or assembly to specific files stored on the disk (FILES)

These control records are placed in the input stream following an XEQ Monitor control record that names a mainline program stored in Disk System format or following a STORECI control record. In either case the control records are written on disk in the Supervisor Control Record Area (SCRA), from which the Core Load Builder reads them for processing.

Up to 99 Supervisor control records may follow the XEQ or STORECI control record. There is no specified order (by type) to be followed; however, the types may not be intermixed.

*LOCAL

LOCAL (load-on-call) subprograms are subprograms specified by the user to be read, one at a time, as they are called during the execution, into a LOCAL overlay area. The LOCAL subprograms are specified on the LOCAL control record as follows:

where

• MAIN1 is the name of the mainline program already stored on disk. SUB1 through SUBn are the names of the LOCAL subprograms used with that mainline program.

In the case illustrated below, all the LOCAL control records except the last end with a comma (continuation character) and the mainline program name appears on the first LOCAL control record only.

The same results would have been obtained if the records had been:

All the LOCAL subprograms for each mainline program in an execution must be specified on the LOCAL control records that follow the XEQ Monitor control record initiating the execution.

Separate LOCAL control records must be used for each mainline program in the execution that calls LOCAL subprograms. For example,

where

• MAIN2 is a link called by MAIN 1.

If the mainline program is to be executed from Working Storage, the mainline program name must be omitted from the LOCAL control record. For example,

This LOCAL control record format must be used if LOCALs are to be specified with the DUP operation STORECI. No embedded blanks are allowed in the LOCAL control record.

*NOCAL

NOCAL (load-although-not-called) subprograms are subprograms specified by the user to be included in the core load, even though they are not called. They are specified on NOCAL control records using the same format that applies to LOCAL control records except that *NOCAL is used in place of *LOCAL.

Rules for LOCAL and NOCAL Usage

The user must observe the following rules in the usage of LOCAL and NOCAL control records

• A subprogram cannot be specified as a LOCAL subprogram if it causes another subprogram, also specified as a LOCAL subprogram in the same mainline program, to be called. For example, if A calls B and B calls C, and A is a LOCAL subprogram, neither B nor C can be specified as a LOCAL subprogram for the same mainline program.
• If a subprogram is specified as a LOCAL subprogram and system overlays (SOCALs) are employed, the subprogram is made a LOCAL subprogram, even if it would otherwise have been included in one of the SOCALs.
• If a subprogram is specified as a LOCAL subprogram, it is included as a LOCAL subprogram in the core image program even if it is not otherwise called.
• The information on all the LOCAL control records for an execution may not exceed M+2(C+1), where M is the number of mainlines and C is the number of commas. This restriction also applies to NOCAL control records.
• Only subprogram types 3, 4, 5, and 6 can be named on LOCAL and NOCAL control records. Subprogram types 3 and 5 are referenced by LIBF statements, types 4 and 6 with CALL statements. Types 5 and 6 are ISSs; types 3 and 4 are subprograms. See Appendix C for a description of subprogram types.
• Conversion tables, e.g., EBPA, HOLTB, may not be used as LOCALs.

*FILES

By means of FILES control records the file numbers specified in FORTRAN DEFINE FILE statements or in Assembler FILE statements are equated to the names of Data Files stored in the User and Fixed areas. FILES control records may also be used to define Data Files in Working Storage other than the master cartridge. All the User/Fixed Area files to be used by all the core loads in an execution must be defined in the FILES control records following the XEQ Monitor control record initiating the execution. All the files thus defined are available to each core load in the execution. When Data Files are equated in a program stored in DCI, successful execution of this program requires that all cartridges on which these files are stored must be in the same condition and on the same logical drives as when the STORECI occurred. This is necessary since the Core Load Builder places an absolute sector address, including the drive code, into the file table for each equated file. The format of the FILES control record is as follows.

where

• FILE1 through FILEn are the file numbers specified in the FORTRAN DEFINE FILE statements or Assembler FILE statements.
• NAME1 through NAMEn are the names of Data Files already stored on disk. If the name is omitted (2 commas are required in the control record format), the file is placed in Working Storage on the specified cartridge.
• CAR1 through CARn are the IDs of the cartridges on which the respective Data Files are found. If the cartridge ID is omitted, it is assumed that the corresponding Data File has been defined on the master cartridge.

Continuation of FILES control records may be indicated by a comma following the last file definition on the control record, as follows:

The continuation comma may appear only immediately after a right parenthesis.

No more than 159 files may be equated during an execution.

No embedded blanks are allowed in the FILES control record.

SUPERVISOR CORE DUMP PROGRAM

The DUMP program provides the user with a hexadecimal printout of the contents of core storage. The calling sequences for the DUMP and PDMP statements are contained in the Assembler language manual (Form C26-5927). FORTRAN programs access the DUMP Program through the FORTRAN statement CALL PDUMP (See FORTRAN language manual, Form C26-3715).

Terminal and Dynamic Dumps

The DUMP entry point ($DUMP) in the Skeleton Supervisor (and thus the DUMP program in the Supervisor) can be entered (1) by a BSI to the DUMP entry point, (2) by a manually executed transfer to the DUMP entry point plus 1, or (3) by a branch to location zero. which contains an MDX to $DUMP+1

When the DUMP entry point is entered, a dump of the area of core storage bounded by the limit parameters is given in hexadecimal format. Execution of the core load in progress then resumes at the location following the last parameter of the call to the DUMP entry point.

When $DUMP+1 is entered, a dump of the entire contents of core storage is given in hexadecimal format. The DUMP program then executes a CALL EXIT, thereby terminating the execution of the core load in progress.

A portion of a core dump is printed below.

ACCUMULATOR 4000      EXTENSION 78D3    XR1 7FA0    XR2 78D3    XR3 0000       OVERFLOW OFF       CARRY OFF

ADDR    ***0  ***1  ***2  ***3    ***4  ***5  ***6  ***7    ***8  ***9  ***A  ***B    ***C  ***D  ***E  ***F

0000    103F  FFFB  0000  0000    0FFA  0140  0080  C000    7AED  7C56  00B3  0000    00C4  0091  8000  0000
0010    0000  5540  FFFF  C000    0327  0008  0001  7FA0    0900  703F  4000  78D3    00F2  7400  00EE  70F0
0020    4D00  C002  4400  00F2    140C  C0ES  7080  7084    763F  30CC  4C80  0028    0038  0150  0CC0  0000
0030    0000  0000  C007  0000    0000  C0CA  0000  00CC    7014  CCCC  1810  7012    0001  0004  FFFF  0000
0040    7400  0032  7080  0806    6902  0480  0038  0001    C6F3  44C0  0082  C0F0    7001  C0F0  0007  7400
0050    0032  7080  0880  6580    0039  C101  1800  C100    0868  6500  010C  C0FE    1890  4400  0082  7400
0060    00EE  70F0  4102  0000    0000  0000  0000  0000    0000  0CC0  C000  0000    C000  0000  C0CA  0000
0070    C000  0000  0000  0000    0000  0000  FFFF  0000    0802  0CC1  0000  0000    0000  0000  0000  0000
0080    0000  0000  3000  4080    0081  0000  3000  4080    0085  CC00  3000  4C80    0089  0000  3000  4C80
0090    0080  C000  30C0  4CC0    C091  0106  CC00  0000    0000  0000  0140  0000    0000  0000  0000  9C00
00A0    0000  C0CA  0000  CCCC    0658  0658  0658  0000    0000  C0CA  CC00  0000    0000  0000  0CC0  0000
00B0    0000  C000  C0CA  0051    6906  6A07  2807  080A    4400  0CF7  6500  78A0    6600  7803  2000  0802
00C0    4CC0  0083  0001  9400    002A  0818  2806  690F    6610  0816  1002  4010    0000  4480  0020  FFFE
00D0    6109  0810  1149  4580    7F58  2C00  6500  7FA0    6600  7803  C803  4CC0    00C4  4001  4000  7803
00E0    0200  CFC0  0000  0300    0000  0000  0000  0000    0000  0CC0  C0CA  0000    0000  CC00  0011  0000
00F0    0068  FF6A  0048  7400    00EE  70FC  7002  008A    7015  6SCF  6610  1008    003C  1800  0058  6211
0100    6A60  C0F0  0084  7053    4C00  G1BE  6908  081E    6500  7FA0  6600  7803    4C80  0087  6500  0004
0110    6600  C0F2  0819  D0CS    4850  70EE  0800  0900    74FF  00EE  7036  C812    C014  4293  1810  0480
0120    0198  7000  0001  0140    0FFA  0140  C004  95CC    0004  95CC  0122  9600    9400  9781  0E8A  0141
0130    5002  5004  FEC0  0001    0080  C600  C0CA  5000    0FFE  01CC  0701  0007    000A  009F  FFFB  9680
0140    0400  0141  0000  88FF    0C00  0000  1810  00A6    74FF  0032  1000  7060    C0E3  700F  C0EB  4400
0150    0028  703A  0009  1800    C101  1803  7040  7401    0032  6500  C001  0900    0807  0800  1810  1084
0160    0C0E  8006  0018  600A    0033  8006  8008  80C7    0006  62F0  6980  0101    E0CB  0101  5400  00A4
0170    4828  1006  C101  8002    7401  016F  7201  70F5    6600  00F2  0230  2490    0250  0400  009F  EA4E
0180    023A  5A43  0239  EA50    9247  0237  EA42  8247    0240  6A48  0236  0A30    0A36  0268  4828  70BC
0190    1C02  4828  7068  1008    4828  70BC  0101  9400    009A  4818  7014  1893    180F  1002  EA3A  1800
01A0    4810  7001  F251  8230    0634  4213  CA38  0A34    4213  C231  0480  0198    9101  4020  0116  CA3C
01B0    4808  7094  8A40  0A3C    4830  1810  8248  01CC    CA36  0634  C101  6A50    0101  4213  C240  0235
01C0    C247  4820  4213  CA32    09C0  0230  4808  7069    7500  0140  C900  0A32    CA3C  0900  708F  0000
01D0    0CC0  0000  0000  0000    0000  0000  0000  0000    0000  0C0C  CCA0  3333    0166  0100  0300  001C
01E0    4480  7089  0006  6780    7FFC  1860  CF00  0142    633C  6FCC  1925  6300    C193  4028  0181  6780
01F0    7F33  6F00  045A  6F00    0200  0120  4C20  0307    C11D  4C28  0283  0700    7F70  4C18  0257  0400
0200    0395  4400  02A9  0302    1804  4C20  020C  CC00    0342  0000  1064  7004    CC00  033E  DC00  7064
0210    4480  70B8  4480  1085    4480  7085  4480  7085    4480  7085  4480  7085    0400  0386  4418  03E7
0220    4400  0440  6600  0356    6311  4C79  4480  7068    7925  405A  6600  7925    6780  7FFC  C302  4480
0230    7C80  0928  0601  C303    4480  70B0  0928  0206    1800  0207  C305  4480    1080  C928  0400  C306
0240    4480  7080  C928  0A13    4480  7088  7925  4480    70A5  4480  70BS  4480    7085  4036  6600  0371
0250    4C3F  6600  0378  4030    4480  7065  6215  6500    039F  040C  0398  0400    0390  6680  7FFC  7206
0260    6A5D  7201  6A13  1810    0400  C390  4400  03A7    1000  C000  0390  0916    4480  70B7  C4C0  0390
0270    4018  0200  4480  7088    1925  6600  7792  C202    8400  039C  0400  039C    7203  74FF  039F  7001
0280    703C  0400  0396  70DE    02E0  613C  0008  0500    7925  71FF  70FC  65C0    7FA0  4C80  0284  4040
0290    0254  6105  A30A  4008    740C  02A4  71FF  70FA    0003  0C0A  44A0  7D88    7925  4080  0290  0287
02A0    6A01  C700  032F  0700    7925  13FF  70FA  4C8C    029F  0203  6780  7FFC    C000  0394  0800  4480
02B0    7083  4080  C2A9  0700    7F68  1004  1804  4C18    0209  0700  7F68  4000    01F1  0400  7788  6700
02C0    0004  4DB0  0209  0700    7868  1004  1804  9480    02BE  040C  0386  C600    00FB  8400  0398  0400
02D0    0398  C700  7F70  180C    1000  EC80  C2BE  4000    01FF  0193  4C10  0287    7301  6F00  0336  74FC
02E0    0336  7C05  1810  0400    0386  4000  01F1  4480    7085  4480  70B5  4098    C110  4C28  02FF  C844
02F0    D845  C84A  0845  6600    032F  630A  40A8  4480    7068  7925  C845  0CC0    70A4  4480  7DRD  0835
0300    0835  0832  0835  66C0    032F  630A  70EF  6827    4400  044C  6700  7925    6680  7884  72C1  0202
0310    4020  0315  C01D  7280    7086  C019  4C20  0318    C112  9202  0112  1810    0400  0390  C112  0400
0320    0398  4400  03A7  C40C    0390  4018  02E7  4480    7086  7925  1203  C202    4020  02E7  7082  0000
0330    40C5  05C4  4006  0640    C4E4  0407  0603  C563    4040  4040  03C5  E361    C603  0563  C603  C5E3
0340    4040  4040  0305  5340    78C3  09C4  054C  4040    5BC6  0701  0440  4040    76C6  07C1  C440  4040
0350    7803  C9C2  C140  4040    7BE4  0305  E340  4040    7606  03C5  E340  6203    E309  4005  0646  4040

                                                    [etcetera]

7EB0    4480  7063  7A14  D8C8    28CF  6900  6609  6606    6500  7FA0  4C80  7662    764F  6700  0000  6600
7EC0    7926  6500  7FA0  C888    2001  4C80  7E8C  435E    4480  1CBA  0100  CAFE    0002  C089  7005  4355
7ED0    4480  706A  0200  C0B4    D0AC  68A0  C301  E063    0115  4820  C300  4C30    7560  4480  7064  005C
7EE0    80A0  1800  1010  68A6    8115  90A9  4C08  7EEB    4480  7064  0050  0896    4400  00F2  7400  00EE
7EF0    70F0  0091  0116  8300    0117  4480  7087  C12E    4098  7ECF  1010  012E    4F00  0002  70FD  C080
7F00    0116  8300  0117  4480    1067  C12E  4C98  7500    1010  0125  4F00  0002    0000  0000  0000  0000
7F10    0000  0000  0000  C000    0000  0000  0000  0000    0000  C0CA  0000  0000    0000  0000  0070  0001
7F20    0000  0000  0000  0000    0406  3040  0020  0000    0200  0000  0000  0000    0CC0  FFF6  0C00  0000
7F30    0000  C0CA  0000  0000    0000  0000  0000  C000    0000  CC01  0001  010A    7800  0000  0000  0000
7F40    0000  0000  00CC  1052    C000  0000  0000  0000    1052  0000  0000  0000    0000  0106  0C00  0000
7F50    0000  C000  0000  2222    3333  000F  0A68  3333    0000  0000  0000  0000    0140  0000  0000  0000
7F60    0000  0110  1110  0000    0000  CC00  FFFE  0000    00CC  0000  0000  0118    0000  0000  0000  0000
7F70    0150  0000  0000  0000    0000  0020  CC00  0000    0000  0000  000C  0009    C0CA  0000  0000  0000
7F80    0000  C000  0000  0000    0000  C0CA  0000  000C    0000  0000  0000  0000    0000  0000  0000  0000
7F90    05A3  C008  0566  C0B0    03CC  0015  0461  0018    03CC  0010  05A3  001F    05A3  0024  0500  0029
7FA0    05F8  0030  0230  0035    0230  0037  C248  0039    0000  C000  0000  0000    0000  0000  0000  0000
7FB0    0000  0000  0000  0000    0000  CC00  7803  7068    0000  0000  CC00  0000    0000  0000  CCC0  0000
7FC0    00CC  0000  C0C0  0000    0000  0000  0000  0000    0000  0000  C000  0000    0000  0000  0000  0000
7FD0    0000  0000  0000  0000    0000  0000  0000  0000    0000  0C00  0004  0568    0461  7080  0038  0000
7FE0    7064  0000  0000  0000    0000  0000  0000  0000    0080  0080  0080  0080    0080  7C56  74EA  7A56
7FF0    0000  0000  00A0  C0F2    7803  7066  0802  78D3    11DE  7091  7A06  0640    7782  7925  7985  7963


[note: the above has not been proofed except for the basic format. - HSS]

DISK UTILITY PROGRAM (DUP)

The Disk Utility Program (DUP) provides the user with the ability to perform the following operations through the use of control records.

• Store Disk System Format (DSF) programs, Disk Core Image (DCI) programs, and Data Files on the disk
• Make the DSF programs, DCI programs, and Data Files on the disk available in printed, punched card, or punched paper tape output
• Remove DSF programs, DCI programs, and Data Files from the disk
• Determine the status of disk storage through a printed copy of LET/FLET
• Modify the system
• Perform other disk maintenance functions

DUP control records are described in the section of this manual entitled DUP Control Records. DUP error messages are listed in Appendix A.

GENERAL FLOW

DUP is called into operation when the Supervisor recognizes a DUP Monitor control record (// DUP). The control portion of DUP is brought into core to read the next record from the input stream, which should be a DUP control record (*...). The DUP control record is printed and analyzed. LET is searched for the program specified, and switches and indicators are set in accordance with the information obtained from the control record. The DUP program required to perform the requested operation is then read into core from the disk and given control.

The DUP program performs its assigned tasks, directed by the switches and indicators that were set according to the information on the DUP control record. Upon completion of its tasks, the DUP program prints a message and returns control to the control portion of DUP. The control portion indicates the completion of the DUP operation with a printed message and reads the next record from the input stream.

If the record read is a Monitor control record other than comments, control is returned to the Supervisor to process the record. If the record read is a DUP control record, DUP maintains control and reads the next record. Comments Monitor control records are simply printed; blank records are passed.

INFORMATION TRANSFER AND FORMAT CONVERSION

Table 2 summarizes the DUP operations that transfer information from one area or medium to another area or medium. In addition, the format conversions made during the transfers of information are shown. The acronyms for the various formats are described below. The formats are described in Appendix C.

ALTERING LET/FLET

The two tables LET and FLET constitute a directory to the contents of the User and Fixed areas on disk. The allocation of disk storage and, correspondingly, the contents of LET/FLET can be altered by the user only through the use of DUP.

Before storing any DSF program, DCI program, or Data File, DUP searches LET/FLET to ensure that the name of the DSF program, DCI program, or Data File does not already appear in LET/FLET on the cartridge specified on the DUP control record. (If no cartridge is specified, the LET/FLET of every cartridge specified on the last JOB record is searched.) Disk storage is allocated to the DSF program, DCI program, or Data File and a corresponding entry is made in LET/FLET only if the name is not found.

When dumping or deleting a DSF program, DCI program, or Data File from the User/Fixed Area, the DSF program, DCI program, or Data File is located through LET/FLET using the name specified by the user in the DUP control record.

A LET/FLET printout and description is contained in Appendix G.

DUP CONTROL RECORDS

DUP control records call IBM-supplied programs that perform operations involving the disk such as storing, moving, deleting, and dumping data and/or programs.

DUP control records generally follow the format described below. Note that all fields in the control record except the count field are always left-justified and that unless otherwise stated, all fields are required.

Table 2. Summary of DUP Data Transfer Operations

Column 1. Column 1 always contains an *(asterisk).

Operation Field. Columns 2 through 12 (21 in the case of the DEFINE operation) contain the name of the desired DUP operation. Columns 2 through 6 identify the basic operation (STOREDATACI); columns 7 through 12 (or 21) identify the extended operation (STOREDATACI). Where shown in the control record format, a blank character (b) is required within or following the operation name.

FROM and TO Fields. Columns 13 and 14 contain the "FROM" symbol, that is, the symbol specifying the disk area or I/O device from which information is to be obtained (the source). Columns 17 and 18 contain the "TO" symbol, that is, the symbol specifying the disk area or I/O device to which information is to be transferred (the destination). The symbols that must be used as the "FROM" and "TO" symbols are shown below.

When used, the symbols UA, FX, and WS each specify an area on disk but do not identify the cartridge on which the area is found.

Name Field. Columns 21 through 25 contain the name of the DSF program, DCI program, or Data File involved in the specified DUP operation. The name may consist of up to five aiphameric characters, and must be left-justified within the field. The first character must be alphabetic (A-Z, $), and no embedded blank characters are allowed.

When referencing a DSF program, DCI program, or Data File already stored on disk, the name must be an exact duplicate of the LET/FLET entry.

Count Field. Columns 27 through 30 contain the count. The count is always a right-justified decimal integer. The count field is defined in the individual control record formats for those operations that require it.

FROM and TO Cartridge ID Fields. Columns 31 through 34 contain the cartridge ID of the cartridge containing the disk area from which information is to be obtained, that is, the "FROM" (source) cartridge ID. Columns 37 through 40 contain the cartridge ID of the cartridge containing the disk area to which information is to be transferred, that is, the "TO" (destination) cartridge ID.

Either or both of these cartridge IDs may be omitted. If a cartridge ID is omitted, and the corresponding FROM or TO field is the User or Fixed Area, a search is made of the LET/FLET on each cartridge specified on the JOB record, starting with the cartridge on logical drive zero (the master cartridge) and continuing through logical drive four. If the corresponding FROM or TO field is Working Storage, then a default to System Working Storage is made. If a cartridge ID is specified, the LET/FLET on the specified cartridge only is searched, or System Working Storage is used.

Use of the "FROM" and "TO" cartridge IDs makes it possible for DUP (1) to transfer DSF programs, DCI programs, and Data Files from one cartridge to another without deleting them from the source cartridge, and (2) to operate on a DSF program, DCI program, or Data File even though the same name appears in the LET/FLET on more than one cartridge.

Unused Columns. All unused columns between columns 2 and 40 must be left blank. Columns 41 through 80 are ignored by DUP and are available for user's remarks.

DUP Operations and Control Record Formats

The following are descriptions of the various DUP operations. Each description consists of (1) a brief description of the processing performed, (2) a breakdown of the control record for the operation, and (3) a table of the transfers and format conversions possible in the operation.

*DUMP

The DUMP operation moves information from the User/Fixed Area on disk to Working Storage or makes information from the User/Fixed Area and Working Storage available as card, paper tape, or printed output. The print format is illustrated in Appendix C.

The movement of DSF programs from the User/Fixed Area to the output devices is accomplished in two phases; that is, the information is first moved to System Working Storage and then to the output device. Hence, information residing in Working Storage on the cartridge defined in the JOB Monitor control record by the Working Storage ID (see // JOB under Monitor Control Records is destroyed during the DUMP operation. Data Files and DCI programs are moved directly from the User/Fixed Area to the output devices.

The number of disk blocks to be dumped is obtained from the LET/FLET entry, or, if the dump is from Working Storage, from the appropriate Working Storage Indicator in DCOM.

The format of the DUMP control record is as follows.

The following chart is a summary of the information transfers and format conversions performed by DUMP.

*DUMPDATA

The DUMPDATA operation moves information from the User/Fixed Area on disk to Working Storage or makes information from the User/Fixed Area and Working Storage available in card, paper tape, or printed output. The print format is similar to that of DUMP (see Appendix C). The DUMPDATA operation differs from the DUMP operation in that the information, after transfer, is always in data format, and the amount of information transferred is dependent upon the count field of the DUMPDATA control record rather than the actual length of the program or data.

Information is moved directly from the User/Fixed Area or Working Storage to the output devices. The contents of Working Storage are not changed.

The count field (columns 27-30) in the DUMPDATA control record specifies the number of sectors to be dumped. This number of sectors is dumped regardless of the length of the DSF program, DCI program, or Data File, as indicated in the LET/FLET entry or in the Working Storage Indicator.

The format of the DUMPDATA control record is as follows.

The following chart is a summary of the information transfers and format conversions performed by DUMPDATA.

*DUMPLET

The DUMPLET operation prints the contents of LET on the principal print device. In addition, the contents of FLET are also printed on the principal print device if a Fixed Area has been defined by the user.

If the name of a DSF program, DCI program, or Data File is specified in the DUMPLET control record, only the LET/FLET entry corresponding to that name is printed. If a cartridge ID is specified in the control record, the LET/FLET on only that cartridge is printed. If neither name nor cartridge ID are specified, the entire contents of both LET and FLET on each cartridge specified on the JOB record are printed. A sample LET/FLET dump and description appears in Appendix G.

The format of the DUMPLET control record is as follows.

*DUMPFLET

The DUMPFLET operation prints the contents of FLET on the principal print device.

If the name of a DCI program or Data File is specified in the DUMPFLET control record, only the FLET entry corresponding to that name is printed. If a cartridge ID is specified in the control record, the FLET on that cartridge only is printed. If neither name nor cartridge ID are specified, the entire contents of the FLET on each cartridge defined on the JOB record are printed. A sample LET/FLET dump and description appears in Appendix G.

The format of the DUMPFLET control record is as follows.

*STORE

The STORE operation moves information from Working Storage to the User Area or accepts information from the input devices and moves it to Working Storage or the User Area.

All movement of information from the input devices to the User Area is accomplished in two phases; that is, the information is first moved to the System Working Storage and then to the User Area. Hence, information residing in Working Storage on the cartridge defined in the JOB Monitor control record by the Working Storage ID (see // JOB under Monitor Control Records) is destroyed during the STORE operation.

Since the User Area and Working Storage are adjacent areas, and since the User Area expands as needed into what had been Working Storage, DUP assumes that on any STORE operation to the User Area, the contents of that Working Storage are destroyed. Therefore, the appropriate Working Storage Indicator is reset to zero following the STORE operation to the User Area.

DUP makes the required LET entry (or entries) for each program stored. A LET entry is made for each entry point in the program. DUP supplies the disk block count required in the LET entry for the primary entry point.

The format of the STORE control record is as follows.

The following chart is a summary of the information transfers and format conversions performed by STORE.

*STOREDATA

The STOREDATA operation moves information from Working Storage to the User/Fixed Area or accepts information from the input devices and moves it to Working Storage or the User/Fixed Area. DUP assumes that the input to the STOREDATA operation is in data format; the output from the STOREDATA operation is always in data format.

Information is moved directly from the input devices to the User/Fixed Area. The contents of Working Storage are not changed except that when storing to the User Area, the contents of Working Storage on that drive are destroyed since the User Area and Working Storage are adjacent areas.

DUP makes the required LET/FLET entry. The name specified on the STOREDATA control record is the name used to generate the LET/FLET entry and is the name that must be used in all subsequent references to the Data File. DUP supplies the disk block count required in the LET/FLET entry if the source is cards or paper tape. If the source is Working Storage, the sector count specified in the STOREDATA control record is used.

The format of the STOREDATA control record is as follows.

The following chart is a summary of the information transfers and format conversions performed by STOREDATA.

*STOREDATACI

The STOREDATACI operation moves information from Working Storage to the User/Fixed Area on disk or accepts information from the input devices and moves it to Working Storage or to the User/Fixed Area. If the input is from cards or paper tape, the STOREDATACI operation assumes the input format to be card or paper tape core image format. If the input is from Working Storage (the information has been previously dumped to Working Storage or stored in Working Storage from an input device), the appropriate Format Indicator must indicate Disk Core Image format (DCI); otherwise, no STORE operation is performed. The output from the STOREDATACI operation is always in Disk Core Image format.

All movement of information from the input devices to the User/Fixed Area is done directly; that is, the transfer is not made via Working Storage. Hence, the contents of Working Storage are not changed by the STOREDATACI operation when storing information from an input device to the Fixed Area. Note, however, that when storing to the User Area, the contents of Working Storage on that drive are destroyed.

DUP makes the required LET/FLET entry. The name specified on the STOREDATACI control record is the name used to generate the LET/FLET entry and is the name that must be used in all subsequent references to the core image program. DUP computes the disk block count required in the LET/FLET entry from the count specified in the STOREDATACI control record.

The format of the STOREDATACI control record is as follows.

The following chart is a summary of the information transfers and format conversions performed by STOREDATACI.

*STORECI

The STORECI operation obtains an object program from Working Storage or from an input device, converts it into a core image program using the Core Load Builder, and stores the core image program into the User/Fixed Area.

Figure 5. Layout of a Core Image Program Stored in the User/Fixed Area

The Core Load Builder is fetched to build a core image program for the STORECI operation as if execution were to follow; that is, that portion of the core load residing above core location 4096 is placed in the System CIB, and LOCALs and/or SOCALs are placed in System Working Storage. The STORECI operation stores all these portions of the core image program into the "TO" (destination) area.

The DCI program stored in the User/Fixed Area includes the Transfer Vector built by the Core Load Builder; however, neither the disk I/O subroutine nor any COMMON area is included. Figure 5 shows the layout of a DCI program as it is stored in the User/Fixed Area. No scale is intended in this illustration.

DUP makes the required LET/FLET entry for the core image program as it is stored. The name specified on the STORECI control record is the name used to generate the LET/FLET entry and is the name that must be used in all subsequent references to the DCI program. DUP obtains the disk block count required in the LET/FLET entry from the Core Load Builder.

The format of the STORECI control record is as follows.

The following chart is a summary of the information transfers and format conversions performed by STORECI.

*STOREMOD

The STOREMOD operation moves information from Working Storage into the User/Fixed Area. If the name of the DSF program, DCI program, or Data File specified on the STOREMOD control record is identical to an entry in LET/FLET (that is, a DSF program, DCI program, or Data File of the same name already resides in the User/Fixed Area), the information in Working Storage overlays (replaces) that DSF program, DCI program, or Data File in the User/Fixed Area. The format of Working Storage must match the format of the LET/FLET entry which is to be replaced.

If the name on the STOREMOD control record does not match an entry in LET/FLET, a simple STORE operation is performed (see *STORE).

The STOREMOD operation permits the user to modify a DSF program, DCI program, or Data File in the User/Fixed Area without changing its name or relative position within the area. However, the length of the DSF program, DCI program, or Data File in Working Storage cannot be greater than the length of the DSF program, DCI program, or Data File that it replaces in the User/Fixed Area. No change is made to the LET/FLET entry as a result of this operation.

The format of the STOREMOD control record is as follows.

The following chart is a summary of the information transfers and format conversions performed by STOREMOD.

*DELETE

The DELETE operation removes a specified DSF program, DCI program, or Data File from the User/Fixed Area. The deletion is accomplished by the removal of the LET/FLET entry (or entries) for the DSF program, DCI program, or Data File, including the dummy entry for associated padding, if any.

If a DSF program, DCI program, or Data File is deleted from the User Area, that area is packed so that (1) the areas represented by LET entries are contiguous, and (2) Working Storage can be increased by the amount of disk storage formerly occupied by the deleted DSF program, DCI program, or Data File.

If a DCI program or Data File is deleted from the Fixed Area, no packing of that area occurs. The FLET entry for the deleted DCI program or Data File, including the dummy entry for associated padding, if any, is replaced by a single dummy entry (1DUMY) representing the area formerly occupied by the deleted DCI program or Data File and its padding. DUP store operations may be used to place new entries in the Fixed Area.

The contents of Working Storage are not destroyed by the DELETE operation.

The format of the DELETE control record is as follows.

*DEFINE

The DEFINE operation (1) initially establishes the size of the Fixed Area, (2) increases or decreases the size of the Fixed Area, (3) deletes the Assembler or FORTRAN Compiler, or both, from the System Area. If the Assembler and/or FORTRAN Compiler is to be deleted, this deletion must be performed prior to defining the Fixed Area on the master cartridge (or after completely removing a defined Fixed Area).

Definition of a Fixed Area on disk allows the user to store DCI programs and Data Files in fixed locations, which can subsequently be referred to by sector address. The Fixed Area is defined in cylinder increments (one cylinder minimum). When a FIXED AREA is defined, one cylinder is always reserved for FLET, i.e., the initial definition of the Fixed Area must be two cylinders.

Increases and decreases in the size of the Fixed Area must also be made in cylinder units; however, the Fixed Area cannot be decreased by a number greater than the number of unused cylinders at the end of the last program or data file in the Fixed Area. If all DCI programs and Data Files have been deleted from the Fixed Area (1DUMY entries) and the Fixed Area is decreased to less than two cylinders by a DEFINE FIXED AREA control record, the remaining Fixed Area, as well as FLET, is deleted. The Fixed Area and FLET will likewise be deleted if the DEFINE FIXED AREA control record specifies a decrease that exceeds the number of cylinders of Fixed Area on the cartridge.

The control record format for definition of the Fixed Area is described below.

Deletion of the Assembler and/or FORTRAN Compiler causes the specified Monitor programs to be removed from the IBM System Area on the master cartridge. The IBM System Area is then packed so that following programs and areas occupy the areas formerly occupied by the deleted Monitor programs. SLET entries are updated to reflect the new disk storage allocation for the Monitor programs. The reload table is used to make adjustments in the programs which use disk storage addresses from SLET. If the Assembler and/or FORTRAN Compiler is to be deleted, the user must perform this deletion before defining the Fixed Area on the master cartridge, or after completely removing the Fixed Area. After the Assembler and/or FORTRAN Compiler have been deleted, neither can be restored without performing an initial load.

The control record format for deletion of the Assembler and/or FORTRAN Compiler is described below.

*DWADR

The DWADR control record causes a sector address to be written on every sector of Working Storage on the cartridge specified by the DWADR control record, or if no ID is specified, on the System Working Storage. The operation restores correct disk sector addresses in Working Storage if they have been modified during execution of a user's program.

The contents of Working Storage prior to the operation are destroyed.

Following the sector address word (word 0), the first 240 words of each sector contain the sector address of that sector, including the drive code. The remaining 80 words of each sector contain zeros.

A dummy // DUP record is printed on the principal printer following the printing of the *DWADR control record and the DUP exit message.

The format of DWADR control record is as follows.

ASSEMBLER

The basic language for the Assembler in the Monitor system is described in the publication IBM 1130 Assembler Language (Form C26-5927). Therefore, this section contains only a general description of the Assembler program and its operation. Assembler control records are described in the section Assembler Control Records; Assembler messages, error messages, and error detection codes are listed in Appendix A.

The 1130 Monitor Assembler cannot be operated independently of the Monitor system; however, the Assembler can be deleted from the Monitor system if desired (see *DEFINE under DUP Control Records).

An ASM Monitor control record is used to call the Assembler into operation. The Assembler reads the source program, including control records, from the principal input device. After assembly, the object program resides in System Working Storage. The object program can now be (1) called for execution with an XEQ Monitor control record, (2) stored in the User/Fixed Area with a STORE or STORECI operation (see DUP Control Records) or (3) punched as a binary deck or tape with a DUMP operation (see DUP Control Records).

If symbol table overflow exceeds the number of sectors allocated for overflow by the OVERFLOW SECTORS control record (a maximum of 32 sectors is allowed), an Assembler error message is printed. The approximate maximum size of the symbol table (including overflow) and, hence, the maximum number of symbols that can be defined in a program, is determined by the size of core storage as indicated below:

CARD OPERATION

The source deck (including Assembler control cards) can be assembled either as part of a job or as a separate job. In either case, the source deck must be preceded by an ASM Monitor control record.

One-Pass Mode

In most cases, the source deck is passed through the 1442 Card Read Punch or 2501 Card Reader only once. If the assembly is part of a stacked job, the assembly proceeds without operator intervention. If the END card of the source deck is the last card in the hopper, press reader START when the reader goes not-ready.

The assembly of a program may start in one-pass mode and then change to two-pass mode. This condition occurs when the intermediate output of pass 1 exceeds the capacity of Working Storage less the number of overflow sectors specified. The system WAITs at the preoperative error trap ($PRET) with /100E (1442 input) or /400E (2501 input) displayed in the Accumulator (see Assembler error messages, Appendix A). If this assembly is part of a stacked job, operator intervention is necessary to prevent the Assembler from reading the Monitor control card following the END card of the source deck. Remove the stacked input behind the END card and press PROGRAM START. The assembly will continue in two-pass mode.

Two-Pass Mode

In some cases it may be known in advance that it is necessary to assemble in two-pass mode, that is, pass the source deck through the 1442 Card Read Punch or the 2501 Card Reader twice. If a copy of the source deck, including all Assembler control records, is placed behind the original, the source deck will be read twice, and a stacked job is again possible even when in two-pass mode. Two-pass mode is not allowed with 1134 or Keyboard input.

It is important to note that when a deck is being assembled in two-pass mode, the Assembler is ready to read another card as soon as pass 1 processing of the END card is completed. Therefore, a Monitor control record must not follow the END card the first time (or the first END card if the deck has been copied), or the Assembler will trap this record and execute a CALL EXIT.

If the deck has not been copied, the END card should be the last card in the hopper. Press reader START to process the last card and complete pass 1. The Assembler will then try to read cards for pass 2; therefore, the source deck (with its control cards) should be removed from the stacker and placed in the hopper. Press reader START to begin pass 2 of the assembly. Operation is continuous if the source deck is taken from the stacker during pass 1 and placed in the hopper behind the END card. If the END card is the last card in the hopper, press reader START to complete the assembly.

Punch Symbol Table Option

If the *PUNCH SYMBOL TABLE Assembler control card is used and the principal input device is the 1442 Card Read Punch, sufficient blank cards must be placed after the END card and before the next Monitor control record in the stacked job input. (If a non-blank card is read when punching on the 1442-6, 7 the Assembler will WAIT at the preoperative error trap ($PRET) with /100F displayed in the accumulator). In estimating the number of blank cards required, allow one card for each symbol used in the source deck. Unnecessary blank cards will be passed until the next Monitor control record is read.

If the system configuration is 2501/1442, place blank cards in the 1442 hopper and press 1442 START before beginning the assembly.

Note: Do not place non-blank cards in the 1442-5. The punch may be damaged if an attempt is made to punch a hole where a hole exists. No error is detected.

KEYBOARD/PAPER TAPE OPERATION

Most of the procedures for card input are also applicable to keyboard/paper tape input. The LIST DECK, LIST DECK E, PUNCH SYMBOL TABLE, and TWO PASS MODE options are not allowed with keyboard/paper tape input.

Note: The paper tape input to the Assembler is punched in PTTC/8 code, one frame per character. The format of the keyboard/paper tape control records is the same as the card format. The format of the symbolic program keyboard/paper tape records is the same as card format except for the following:

• The record does not contain leading blanks corresponding to card columns 1-20.
• The record does not contain blanks or data corresponding to card columns 72-80.
• Trailing blanks need not be used. Therefore, up to 51 characters (corresponding to card columns 21-71) can appear in the record.

The assembly is continuous, and at the end of the assembly control is returned to the Supervisor, which will then pass any delete codes between the Assembler and the next Monitor control record. The assembler will also pass any codes that may occur between paper tape records of the source program.

The first record processed by the Assembler is checked for an asterisk in column one. If an asterisk is present in column one, this record is treated as an Assembler control record. This procedure continues until the first non-asterisk character is detected in column one. For this record, and all records following (up to and including the END statement), column one is treated as if it were column twenty-one; therefore, the first non-control record should not be an * comments record.

ORIGIN OF MAINLINES

The origin of a relocatable program is always set at zero unless otherwise specified in the source program.

The origin of an absolute mainline program, if not otherwise specified in an ORG statement, is set to the end of DISKN plus 30 (the core image header record is 30 words long).

If the program requires DISKZ, DISK1, or DISKN, the origin may be set to the end of the requested disk I/O subroutine plus 30.

If no disk I/O subroutine is used by the program, the origin may be set as low as the end of DISKZ plus 30.

Note that if DISKZ is in core during execution (required or not), the ORG statement for the program being executed must specify an even core address greater than or equal to the end of DISKZ plus 30. An ORG to the end of DISKZ plus 30, followed by a BSS or a BES of an odd number of locations is not allowed. This sequence has the same effect as an ORG to an odd location.

Figure 6. Layout of an Assembler Input Deck

ASSEMBLER CONTROL RECORDS

Assembler control records are used to specify options affecting an assembly and its output. These control records must precede the source program and can be in any order (see Figure 6). Assembler control records can be entered in card or paper tape form along with the source program deck or tape or, unless otherwise noted, may be entered from the Keyboard along with the source statements (see // TYP under Monitor Control Records).

All Assembler control records have the following format:

    Column 1: * (asterisk)
        2-71: Option

If an Assembler control record contains an asterisk in column 1, but the option does not agree, character for character, with its valid format, as described below, the asterisk is replaced by a minus sign on the control record listing. The erroneous control record is ignored and no other error occurs.

Assembler control records can be written in free form; that is, any number of blanks may occur between the characters of the option. However, only one blank must separate the last character in the option, and the first character of any required numeric field. Remarks may be included in the control record following the option or numeric field; however, at least one blank must separate the last character of the option or numeric field and the remarks.

*TWO PASS MODE

This control record causes the Assembler to read the source deck twice. TWO PASS MODE must be specified when:

• The user desires a list deck to be punched on the 1442 Card Read Punch, model 6 or 7 (see LIST DECK and LIST DECK E).
• One-pass operation cannot be performed because the intermediate output (source records) exceeds the capacity of Working Storage.

This control record is ignored if source statements are entered from the Keyboard or the 1134 Paper Tape Reader.

The format of the TWO PASS MODE control record is as follows.

*LIST

This control record causes the Assembler to provide a printed listing on the principal print device (1403 Printer, 1132 Printer, or Console Printer). The format of the printed listing corresponds to that of the list deck (see Figure 7). If the LIST control record is not used, only those statements in which assembly errors are detected will be listed. All BSS, BES, ORG, and EQU statements in which errors are detected will be unconditionally listed in Pass 1 of the assembly.

A sample program listing appears in Appendix J.

The format of the LIST control record is as follows.

*LIST DECK

This control record causes the Assembler to punch a list deck if the principal I/O device is a 1442 model 6 or 7 Card Read Punch. This option requires two passes of the source deck (TWO PASS MODE). The list deck format is shown in Figure 7. Object information is punched into columns 1-19 of the source deck during pass 2.

This control record is ignored if entered from the 2501 Card Reader, the 1134 Paper Tape Reader, or the Keyboard.

The format of the LIST DECK control record is as follows.

*LIST DECK E

This control record causes the Assembler to punch assembly error codes only (columns 18-19) in the list deck output (see LIST DECK). The principal I/O device must be a 1442 model 6 or 7 Card Read Punch. The Assembler error detection codes are listed in Appendix A.

This control record is ignored if entered from the 2501 Card Reader, the 1134 Paper Tape Reader, or the Keyboard.

Figure 7. List Deck Format

The format of the LIST DECK E control record is as follows:

*PRINT SYMBOL TABLE

This control record causes the Assembler to provide a printed listing of the symbol table on the principal print device. Symbols are grouped five per line. Multiply-defined symbols are preceded by the letter M; symbols with absolute values in a relocatable program are preceded by the letter A. The M and A flags, however, are not counted as assembly errors.

The format of the PRINT SYMBOL TABLE control record is as follows.

*PUNCH SYMBOL TABLE

This control record causes the Assembler to punch the symbol table as a series of EQU source cards. Each source card contains one symbol. These cards can be used as source input to the System Symbol Table when the SAVE SYMBOL TABLE control record is used with an assembly in which they are included:

This control record is ignored if entered from the 1134 Paper Tape Reader or the Keyboard.

The format of the PUNCH SYMBOL TABLE control record is as follows.

*SAVE SYMBOL TABLE

This control record causes the Assembler to save the symbol table generated in this assembly on the disk as a System Symbol Table. This System Symbol Table is saved until the next assembly containing a SAVE SYMBOL TABLE control record causes a new assembly-generated symbol table to replace it. This control record is also used with the SYSTEM SYMBOL TABLE control record to add symbols to the System Symbol Table. The SAVE SYMBOL TABLE option requires that this assembly be absolute. If any assembly errors are detected, or if the symbol table exceeds 100 symbols, the symbol table is not saved as a System Symbol Table, and an assembly error message is printed (see Assembler Error Messages, Appendix A).

The format of the SAVE SYMBOL TABLE control record is as follows.

*SYSTEM SYMBOL TABLE

This control record causes the Assembler to add the System Symbol Table (previously built by a SAVE SYMBOL TABLE assembly) to the symbol table for this assembly as the assembly begins. This control record is used when it is desired to refer to symbols in the System Symbol Table without redefining those symbols in the source program, or it is used together with the SAVE SYMBOL TABLE control record when it is desired to add symbols to the System Symbol Table. All symbols in the System Symbol Table have absolute values.

The format of the SYSTEM SYMBOL TABLE control record is as follows.

*LEVEL

This control record specifies the interrupt levels serviced by an ISS and, hence, the associated ILS subroutines. It is required for the assembly of an ISS subroutine. The interrupt level number is a decimal number in the range 0-5. If the device operates on more than one interrupt level (for example, the 1442 Card Read Punch), one LEVEL control record is required for each interrupt level on which the device operates. At least one blank must separate the word LEVEL and the interrupt level number.

If a LEVEL control record is not used when assembling an ISS subroutine, an Error Message is printed at the end of the assembly (see Assembler Error Messages, Appendix A).

The format of the LEVEL control record is as follows.

*OVERFLOW SECTORS

This control record specifies the number of sectors of Working Storage to be used by the Assembler for symbol table overflow. The number of overflow sectors (nn) is a decimal number between 1 and 32. If the entry is zero or blank, no overflow sectors are allowed. if the entry is greater than 32, only 32 overflow sectors are allowed. If this control record is not used, no overflow sectors are allowed; if it is used, the Assembler actually allocates one more sector than the number specified. This additional sector is used as a working sector when the Assembler is handling symbol table overflow.

The format of the OVERFLOW SECTORS control record is as follows.

*COMMON

This control record specifies the length (in words) of COMMON as defined by a FORTRAN core load that is to be executed prior to the execution of the program being assembled. Use of this control record provides for a COMMON area to be saved in linking between FORTRAN mainlines and Assembler mainlines. At least one blank must separate the word COMMON and the decimal number.

The format of the COMMON control record is as follows.

FORTRAN COMPILER

The basic language for the FORTRAN Compiler in the Monitor system is described in the publication IBM 1130/1800 Basic FORTRAN IV Language (Form C263715); therefore, this section contains only a general description of the Compiler and its operation. The FORTRAN Compiler control records are described in the section FORTRAN Control Records; FORTRAN messages and error messages are listed in Appendix A.

The FORTRAN Compiler cannot be operated independently of the Monitor system; however, it can be deleted from the Monitor system if desired (see *DEFINE under DUP Control Records).

A FOR Monitor control record is used to call the FORTRAN Compiler into operation. The Compiler reads the source program, including control records, from the principal input device. After compilation, the object program resides in System Working Storage and can be (1) called for execution with an XEQ Monitor control record, (2) stored in the User/Fixed Area with a STORE or STORECI operation (see DUP Control Records) or (3) punched as a binary deck or tape with a DUMP operation (see DUP Control Records).

The 1130 FORTRAN I/O logical unit numbers and record sizes are listed in Table 3.

//b RECORDS READ DURING THE EXECUTION OF A FORTRAN PROGRAM

During the execution of a FORTRAN program, any //b record encountered by CARDZ, READZ, or PAPTZ will cause an immediate CALL EXIT. The Supervisor will then search for the next valid Monitor control record entered from the reader. Only the //b characters on the record trapped by CARDZ, READZ, or PAPTZ are recognized. Any other data entered in this record is not available to programs in the Monitor system. The record is not listed. For off-line listing purposes, however, this record can contain comments (e.g., // END OF DATA).

FORTRAN CONTROL RECORDS

Before a FORTRAN program is compiled, the user can specify certain options affecting both the compilation and execution of the program by means of control records. These control records must precede the source program and can be in any order (see Figure 8).

FORTRAN control records can be entered in card or paper tape form along with the source program deck or tape, or they may be entered from the Keyboard along with the source statements (see // TYP under Monitor Control Records). The IOCS and NAME control records can be used only in mainline programs; the others can be used in both mainline programs and subprograms.

All FORTRAN control records have the following format:

    Column 1: *(asterisk)
        2-72: Option

Table 3. FORTRAN I/O Logical Unit Designations and Record Sizes

*Unformatted disk I/O comprises 320 word records (including a two-word header). The first word of the header must contain the count of the physical record within the logical record (see example following). The second word of the header must contain the number of effective words in the individual physical record. The second ward of the header of the last physical record within a logical record must have the sign bit (-) on. Unformatted disk characters are stored in as they appear in core storage.

Example:

      DIMENSION A (400)      800 words
      WRITE (10) A

Physical records (maximum record length 320 words due to disk sector size)

An end-of-file record occupies one sector. Word one of the header must be 1 and word two must be a negative zero (/8000).

Figure 8. Layout of a FORTRAN Compiler Input Deck

If a FORTRAN control record contains an asterisk in column 1, but the option does not agree, character for character, with its valid format, as described below, the asterisk is replaced by a minus sign on the control record listing. The erroneous control record is ignored in the compilation and the option is not performed; however, no error results.

FORTRAN control records can be written in free form; that is, any number of blanks may occur between the characters of the option. No remarks are allowed.

*IOCS(...)

This control record is required to specify any I/O device that is to be used during execution of the program; however, only the devices required should be included. Because the IOCS control record may appear only in the mainline program, it must include all the I/O devices used by all FORTRAN subprograms that are called. The device names must be in parentheses with a comma between each name. The valid names and the devices to which they correspond are listed below:

Note that CARD is used for the 1442 Card Read Punch, Model 6 or 7 and that 1442 PUNCH is used for the 1442 Card Punch, Model 5 (1442 PUNCH may be used with a 1442 Model 6 or 7 if the function is punch only; 1442 PUNCH uses less core). These two names are mutually exclusive; therefore, the use of both the CARD and 1442 PUNCH IOCS Control Records in the same compilation is not allowed.

Subprograms that are a part of a FORTRAN core load but are written in Assembler language can use any I/O subroutines for any device that is not specified on the IOCS control record. Otherwise they must use the same I/O subroutine as the FORTRAN subprogram.

Any number of IOCS control records can be used to specify the required device names.

The format of the IOCS control record is as follows.

*LIST SOURCE PROGRAM

This control record causes the Compiler to list the source program on the principal print device as it is read in.

The format of the LIST SOURCE PROGRAM control record is as follows:

*LIST SUBPROGRAM NAMES

This control record causes the Compiler to list on the principal print device the names of all subprograms (including EXTERNAL subprograms) called directly by the compiled program.

The format of the LIST SUBPROGRAM NAMES control record is as follows.

*LIST SYMBOL TABLE

This control record causes the Compiler to list the following items on the principal print device:

• Variable names and their relative addresses
• Statement numbers and their relative addresses
• Statement function names and their relative addresses
• Constants and their relative addresses

The format of the LIST SYMBOL TABLE control record is as follows.

*LIST ALL

This control record causes the Compiler to list the source program, subprogram names, and the symbol table on the principal print device. If this control record is used, the other LIST control records are not required.

The format of the LIST ALL control record is as follows.

*EXTENDED PRECISION

This control record causes the Compiler to store variables and real constants in three words instead of two and to generate linkage to extended precision subprograms.

The format of the EXTENDED PRECISION control record is as follows.

*ONE WORD INTEGERS

This control record causes the Compiler to allocate one word of storage for integer variables rather than the same allocation (two or three words) used for real variables. Whether this control record is used or not, integer constants are always contained in one word. When this control record is used, the program does not conform to the USASI Basic FORTRAN standard for data storage and may require modification in order to be used with other FORTRAN systems.

The format of the ONE WORD INTEGERS control record is as follows.

*NAME

This control record causes the Compiler to print the specified program name at the end of the listing. The name is five consecutive characters (including blanks) starting at the first non-blank column following NAME. At least one blank must separate the word NAME and the mainline program name.

The format of the NAME control record is as follows.

**(Header Information)

This column record causes the Compiler to print the information in columns 3-72 at the top of each page of compilation printout when a 1403 Printer or 1132 Printer is the principal print device. It initially causes a skip to channel 1 when the first statement of the program is read.

The format of the header control record is as follows.

*ARITHMETIC TRACE

This control record causes the Compiler to generate linkage to the trace subprograms, which are executed whenever a value is assigned to a variable on the left of an equal sign. If console entry switch 15 is on during execution and program logic (see Optional Tracing) does not prevent tracing, the value of the assigned variable is printed as it is calculated.

If tracing is requested, an IOCS control record must also be present to indicate that either the typewriter (that is, the Console Printer), 1132 Printer, or 1403 Printer is needed. If more than one print device is specified in the IOCS control record, the fastest device is used for tracing.

The traced value for a variable to the left of an equal sign of an arithmetic statement is printed with one leading asterisk.

The format of the ARITHMETIC TRACE control record is as follows.

*TRANSFER TRACE

This control record causes the Compiler to generate linkage to the trace subprograms, which are executed whenever an IF statement or computed GO TO statement is encountered. If console entry switch 15 is on during execution and program logic (see Optional Tracing) does not prevent tracing, the value of the IF expression or the value of the computed GO TO index is printed.

If tracing is requested, an IOCS control record must also be present to indicate that either the typewriter (that is, the Console Printer), 1132 Printer, or 1403 Printer is needed. If more than one print device is specified in the IOCS control record, the fastest device is used for tracing.

The traced value for the expression in an IF statement is printed with two leading asterisks. The traced value for the index of a computed GO TO statement is printed with three leading asterisks.

The format of the TRANSFER TRACE control records is as follows.

Optional Tracing

The user can elect to trace only selected parts of the program by placing statements in the source program logic flow to start and stop tracing. This is done by executing a CALL TSTOP to stop tracing or a CALL TSTRT to start tracing. Thus, tracing occurs only if

• Console entry switch 15 is on (can be turned off at any time)
• The trace control records were compiled with the source program
• A CALL TSTOP has not been executed, or a CALL TSTRT has been executed since the last CALL TSTOP.

Operating Notes

A constant in a STOP or PAUSE statement is treated as a hexadecimal number. This hexadecimal number and its decimal equivalent appear in the list of constants. The hexadecimal number is also displayed in the accumulator when the system waits at $PRET during the execution of the PAUSE or STOP statement.

Variables and constants that require more than one word of storage have the address of the word nearest the zero address of the machine. In the case of arrays, the given address refers to the addressed word of the first element. In the case of a two- or three-word integer, the integer value is contained in the addressed word. The first variable listed might not be addressed at 0000 because space may be required for generated temporary storage locations.

The relative address for variables not in COMMON would be the actual address if the program started at storage location zero. The relative address for variables in COMMON would be the actual address if the machine had 32K storage. Variables in COMMON reside in the high-order core location of the machine being used (e. g., first COMMON variable will be loaded to /1FFF on an 8K machine).

Any of the three versions of the disk I/O subroutines may be used with a FORTRAN core load. However, under normal circumstances no advantage in speed may be gained, because the FORTRAN disk formatting subroutine operates with one sector at a time. SOCALs may operate faster if DISKN is used.

KEYBOARD INPUT OF DATA RECORDS

Data records of up to 80 characters can be read from the keyboard by a FORTRAN READ statement. Data values must be right-justified in their respective fields.

Keyboard Operation

If it is desirable to key in less than 80 characters, the EOF key can be pressed to stop transmittal. Also, the ERASE FIELD or BACKSPACE key can be pressed to restart the record transmittal if an error is detected while entering data. If the keyboard appears to be locked up, press REST KB to restore the keyboard. The correct case shift must be selected before data is entered.

Buffer Status After Keyboard Input

When the END FLD key is pressed prior to completing a full buffer load of 80 characters, blanks are inserted in the remainder of the buffer. If more data is necessary to satisfay the list items, the remaining numeric fields (I, E, or F) are stored in core as zeros and remaining alphameric fields (A or H) are stored as blanks. Processing is continuous and no errors result from the above condition.

OBJECT PROGRAM PAPER TAPE DATA RECORD FORMAT

Data records of up to 80 EBCDIC characters in PTTC/8 code can be read or written by the FORTRAN object programs. The delete and new-line codes are recognized. Delete codes and case shifts are not included in the count of characters. If a new-line code is enountered before the 80th character is read, the record is terminated. If the 80th character is not a new-line code, the 81st character is read and assumed to be a new-line code. A newline code is punched at the end of each output record.

FORTRAN I/O ERRORS

If input/output errors are detected during execution, the program stops and cannot be contined. The error is indicated by a display in the accumulator. The error displays and meanings are listed in Appendix A, Table 12.

When the output field is too small to contain the number, the field is filled with asterisks and execution is continued.

The input/output routines used by FORTRAN (PAPTZ, CARDZ, PRNTZ, WRTYZ, TYPEZ, PNCHZ, READZ, PRNZ) wait on any I/O device error or device not in a ready condition. When the devices are ready, press PROGRAM START to execute the I/O operation. Error detection in functional and arithmetic subroutines is possible by the use of source program statements. Refer to "FORTRAN Machine and Program Indicator Tests" in the manual, IBM 1130/1800 Basic FORTRAN IV Language (Form C26-3715).

CORE LOAD BUILDER

The Core Load Builder builds a specified mainline program into a core image program. The mainline program, with its required programs (LOCALs and SOCALs included), is converted from Disk System format to Disk Core Image format. During the conversion, the Core Load Builder also builds the Core Image Header record and the Transfer Vector. The resultant core image program is suitable for immediate execution or for storing on the disk in Disk Core Image format for future execution. The Core Load Builder can build a core load that references up to approximately 150 different LIBF and CALL entry points, e.g., 80 LIBFs plus 70 CALLs (the maximum number of LIBFs allowable is 83 due to the size of the LIBF Transfer Vector). The Core Load Builder is called by:

• The Supervisor. After the Supervisor has detected the XEQ Monitor control record in the input stream and has read the Supervisor control records, if any, and written them in the Supervisor Control Record Area (SCRA) on disk, the Supervisor dummys up a CALL LINK to the program specified on the XEQ record unless the program resides in Working Storage, in which case the Supervisor calls the Core Load Builder directly. The Core Load Builder then builds the core load and returns control to the Core Image Loader to fetch the core load and transfer control to it.
• DUP. After DUP has detected the STORECI control record, it reads the Supervisor control records, if any, and writes them in the Supervisor Control Record Area (SCRA) on disk. Unless the program is already in Working Storage, DUP fetches the program, converts it to Disk System format, if necessary, and stores it in Working Storage. Next, the Core Load Builder is fetched to construct the core image program (see Core Load Construction). After the core image program has been built, the Core Load Builder returns control to DUP to store the core image program in the User or Fixed Area.
• The Core Image Loader. When the Resident Monitor is entered at the LINK entry point, the Core Image Loader is called to transfer control to the next link. The Core Image Loader determines the format of the link from the LET/FLET entry and, if the program to be executed is in Disk System format, calls the Core Load Builder to construct the core image program (see Core Load Construction).

After the core image program has been built, the Core Load Builder returns control to the Core Image Loader to fetch the core load and transfer control to it.

CORE LOAD CONSTRUCTION

The following paragraphs describe the functions of the Core Load Builder during the construction of a core image program. These functions are not necessarily performed in the order in which they appear. Figure 9 shows a core image program being built. Figure 5 (see *STORECI under DUP Control Records) shows a core image program stored on disk. Figure 11 (see Fetching a Link under Core Image Loader shows a core load ready for execution.

Processing the Contents of the SCRA

The LOCAL, NOCAL, and FILES control records are read from the Supervisor Control Record Area (SCRA) on disk and analyzed. Tables are built from the information obtained from the respective control record types. These tables are used in later phases of the construction of the core image program.

Conversion of the Mainline Program

The mainline program is converted from Disk System format to Disk Core Image format. The mainline is always converted before any other part of the core load.

Figure 9. Distribution of a Core Image Program being Built

Incorporation of Subprograms

All the subprograms called by the mainline program and by other subprograms are included in the core load, except for (1) the disk I/O subroutine, (2) any LOCAL subprograms specified, and (3) SOCALs (see System Overlays).

If LOCALs have been specified or if SOCALs are employed by the Core Load Builder, the LOCAL/SOCAL flipper (FLIPR) is included in the core load. The order of conversion is generally NOCALs, followed by the subprograms in the order they are called. The order of processing when either LOCALs or SOCALs are included is more complicated and will not be discussed here.

Provision for LOCALs and SOCALs

If LOCALs have been specified, a LOCAL Area as large as the largest LOCAL is reserved in the core load, into which the LOCAL subprograms are read by the LOCAL/SOCAL flipper. In addition, the subprograms specified on the LOCAL control records are written in Working Storage following any files defined in Working Storage. If the core load is executed immediately, each LOCAL is read, as it is called, from Working Storage into the LOCAL Area by the LOCAL/SOCAL flipper. If the core load is stored in Disk Core Image format before it is executed, the LOCALs are stored following the core load. During execution, the LOCAL/SOCAL flipper fetches them from the User/Fixed Area.

If SOCALs are employed by the Core Load Builder, a SOCAL Area as large as the largest SOCAL (usually SOCAL 2) is reserved in the core load, into which the SOCALs are read by the LOCAL/SOCAL flipper. In addition, the subprograms comprising the SOCALs are written in Working Storage following any files defined in Working Storage and any LOCALs stored there. If the core load is executed immediately, each SOCAL is read from Working Storage into the SOCAL Area by the LOCAL/SOCAL flipper as it is called. If the core load is stored in Disk Core Image format before it is executed, the SOCALs are stored following the core load and the LOCALs, if any. During execution, the LOCAL/SOCAL flipper fetches the SOCALs from the User/Fixed Area.

Construction of the Core Image Header

During the construction of the Core Image program, the Core Load Builder also constructs the Core Image Header, which contains the information required by the Core Image Loader to initialize the core load for execution. This header becomes a part of the core image program and resides in core along with the rest of the core load during execution. Since FORTRAN subroutines access this information during execution, the header is not to be considered a work area.

Processing Defined Files

The Core Load Builder uses the information in the FILES control record to equate files defined in the mainline program (by the FORTRAN DEFINE FILE statement or by the Assembler FILE statement) to Data Files on disk. The processing consists of comparing the file number in a 7-word DEFINE FILE table entry with each of the file numbers from the FILES control records, which have been stored in the SCRA by the Supervisor or DUP. If a match occurs, the name of the disk area associated with the file number on the FILES control record is found in LET/FLET, and the sector address of that disk area (including the logical drive code) is placed in word 5 of the DEFINE FILE table entry. If none of the file numbers from the FILES control records match the number in the DEFINE FILE table entry or if no name is specified on the FILES control record, the Core Load Builder assigns an area in Working Storage for the Data File. The sector address of the Data File, relative to the start of Working Storage, is placed in word 5 of the DEFINE FILE table entry. This procedure is repeated for each 7-word DEFINE FILE table entry in the mainline program.

Use of the Core Image Buffer (CIB) and Working Storage

The Core Load Builder places in the CIB any parts of the core load which, when loaded, are to reside below location 4096. Any parts of the core load that are to reside above location 4095 are placed directly into core storage.

Enough Working Storage is reserved by the Core Load Builder to contain any Data Files assigned by the Core Load Builder to Working Storage. All the LOCAL subprograms and SOCALs, respectively, are stored in Working Storage following any files defined there. Figure 9 shows the distribution of a core image program between core storage, the CIB, and Working Storage. These diagrams depict a core image program just after it has been built but before it has been stored (STORECI).

Assignment of the Core Load Origin

The Core Load Builder origins core loads built from relocatable mainline programs at the next higher-addressed word above the end of the disk I/O subroutine to be used by the core load plus 30.

The origins for core loads built from absolute mainline programs are not controlled by the Core Load Builder. Therefore, the user must origin absolute mainline programs at 30 or more words above the end of the disk I/O subroutine to be used by the core load (these 30 words are required for the Core Image Header).

TRANSFER VECTOR

The Transfer Vector is a table included in each core load that provides the linkage to the subprograms. It is composed of the LIBF TV, the Transfer Vector for subprograms referenced by LIBF statements, and the CALL TV, the Transfer Vector for subprograms referenced by CALL statements.

Each CALL TV entry is a single word containing the absolute address of an entry point in a subprogram included in the core load that is referenced by a CALL statement. In the case of a subprogram referenced by a CALL statement but specified as a LOCAL, the CALL TV entry contains the address of the special LOCAL linkage instead of the subprogram entry point address. If SOCALs are required, the CALL TV entries for function subprograms contain the address of the special SOCAL linkage instead of the subprogram entry point address.

Each LIBF TV entry consists of three words. Word 1 is the link word in which the return address is stored. Words 2 and 3 contain a branch to the subprogram entry point. In the case of a subprogram referenced by a LIBF statement but specified as a LOCAL, the LIBF TV entry for its entry point contains a branch to the special LOCAL linkage instead of to the subprogram entry point address. If SOCALs are required, the LIBF TV entry for a SOCAL subprogram contains a branch to a special entry in the LIBF TV for the SOCAL of which the subprogram is a part. This special entry provides the linkage to the desired SOCAL subprogram.

SYSTEM OVERLAYS

SOCALs (system-overlays-to-be-loaded-on-call) are subprogram groups (by type and subtype) that are made into overlays by the Core Load Builder. They make it possible for many FORTRAN core loads that would otherwise not fit into core to be loaded and executed.

If, in constructing a core image program from a FORTRAN mainline program, the Core Load Builder determines that the core load will not fit into core, SOCALs are created by the Core Load Builder for the core load. In addition, the LOCAL/SOCAL flipper, which fetches the SOCALs when they are required during execution, is included in the core load along with the area into which the SOCALs are loaded (the SOCAL Area).

The SOCALs are created by subprogram type and subtype (see the description of program type and subtype under Disk System Format in Appendix C). The following table describes the SOCALs.

There are two SOCAL options. The Core Load Builder first attempts to make the core load fit into core by using SOCALs 1 and 2 only (option 1). If the core load still will not fit into core, SOCALs 1, 2, and 3 are used (option 2). If the use of option 2 still does not make it possible for the core load to fit into core, an error message is printed (see Core Load Builder Error Messages, Appendix A).

Option 1 reduces the core requirement of the core load by an amount equal to the size of the smaller of the two SOCALs used, minus approximately 15 additional words required for the special SOCAL linkage. Option 2 reduces the core requirement by an amount equal to the sum of the sizes of the two smallest SOCALs minus approximately 20 additional words required for the special SOCAL linkage. SOCAL 2 is usually the largest SOCAL.

Each SOCAL does not contain all the available subprograms of the specified types and subtypes; only those subprograms of the specified types and subtypes required by the core load are contained in the SOCAL.

If a subprogram that would otherwise be included in a SOCAL is specified as a LOCAL subprogram, that subprogram is made a LOCAL and is not included in the SOCAL in which it would ordinarily be found.

SOCALs are never built for core loads in which the mainline program is written in Assembler language.

LOCAL/SOCAL FLIPPER (FLIPR)

The LOCAL/SOCAL flipper is included in each core load in which LOCAL subprograms have been specified and/or in which SOCALs have been employed. If execution of the core load immediately follows the building of the core image program, this subroutine reads a LOCAL/SOCAL from Working Storage into the LOCAL/SOCAL Area as it is called during execution. If the core image program was stored in the User or Fixed Area in Disk Core Image format prior to execution, the flipper reads each LOCAL/SOCAL as it is called during execution from the User or Fixed Area (where it was stored following the core load) into the LOCAL/SOCAL Area.

The flipper is entered via the special LOCAL/SOCAL linkage. A check is made to determine if the required LOCAL/SOCAL is already in core. If it is not in core, the flipper reads the required LOCAL/SOCAL into the LOCAL/SOCAL Area, and transfers the LOCAL/SOCAL subprogram via the special linkage.

CORE IMAGE LOADER

The Core Image Loader serves both as a loader for core loads and as an interface for some parts of the Monitor system.

On any entry to the Skeleton Supervisor, the Core Image Loader is fetched and control is transferred to it. The Core Image Loader determines where the Skeleton Supervisor was entered, i.e., at $EXIT, $DUMP, or $LINK.

FETCHING THE SUPERVISOR

If an entry was made to the Skeleton Supervisor at the $EXIT entry point, the Core Image Loader first fetches the disk I/O subroutine used by the Monitor programs (DISKZ), if it is not already in core. It then fetches and transfers control to the Monitor Control Record Analyzer to read Monitor control records from the input stream.

If an entry was made to the Skeleton Supervisor at the $DUMP entry point, the Core Image Loader first saves words 6-4095 on the CIB and then fetches and transfers control to the DUMP program to perform the core dump according to the parameters specified. At the completion of the dump, the DUMP program either restores core from the CIB and transfers control back to the core load, or it terminates the execution with a CALL EXIT (see Terminal and Dynamic Dumps under Supervisor).

FETCHING A LINK

If an entry was made to the Skeleton Supervisor at the $LINK entry point, the Core Image Loader first saves low COMMON (locations 1536-1855 if DISKN is in core, locations 1216-1535 if DISK1 is in core, or locations 896-1215 if DISKZ is in core). It then determines from COMMA the lowest-addressed word of COMMON, if any, defined by the core load just executed. Any COMMON below location 4096 is saved in the CIB by the Core Image Loader.

Figure 10 illustrates the scheme used in saving COMMON between links.

The LET/FLET entry for the link to be fetched is then located, and the Core Image Loader determines from it whether the link is in Disk Core Image format or Disk System format. If the link is in Disk Core Image format, the Core Image Loader fetches the disk I/O subroutine required by the core load, if it is not already in core. It next restores low COMMON if it lies within the COMMON defined by the core load just executed. The core load is then fetched and control is transferred to it.

If the link is in Disk System format, the Core Image Loader calls the Core Load Builder to construct a core image program from the mainline program. After the core image program has been built, the Core Load Builder returns control to the Core Image Loader, which then fetches the core load, as described above, and transfers control to it.

Figure 11 shows the layout of a core load loaded into core, ready for execution.

Figure 10. Scheme for Saving COMMON between Links

Figure 11. Layout of a Core Load Loaded for Execution

But wait, there's MORE...