Each formatted binary block has its length stored within it. The length includes all bytes of the block except the checksum byte. The checksum byte is the negative of the sum of all preceding bytes. Formatted binary blocks may be separated by a variable number of null (0) bytes.

The (data bytes) portion of each formatted binary block contains the actual object module information. RT--11 uses and recognizes eight types of data blocks. The information in these blocks guides the Linker as it translates object code into a runnable program. (FLFRDB_TAB) lists the eight types of data blocks. (#) (RT--11 Data Blocks\FLFRDB_TAB) (3\16\10) (IdentificationCode\Block Type\Function) (#1\GSD\Holds the Global Symbol Directory information.) (#2\ENDGSD\Signals the end of Global Symbol Directory blocks in a module.) (#3\TXT\Holds the actual binary text of the program.) (#4\RLD\Holds Relocation Directory information.) (#5\ISD\Holds the Internal Symbol Directory information (not supported by RT--11).) (#6\ENDMOD\Signals the end of the object module.) (#7\Librarianheader\Holds the status of the library file (see (FLFLHF_SEC)).) (10\Librarian end\Signals the end of the library file (see (FLFLEB_SEC)).)

An object module must begin with a Global Symbol Directory (GSD) block and end with an End of Module (ENDMOD) block. Additional GSD blocks can occur anywhere in the file, but must appear before an End of Global Symbol Directory (ENDGSD) block. An ENDGSD block must appear before the ENDMOD block, and at least one Relocation Directory (RLD) block must appear before the first Text Information (TXT) block. Additional RLD and TXT blocks can appear anywhere in the file. The Internal Symbol Directory (ISD) block can appear anywhere in the file between the initial GSD and ENDMOD blocks. (FLFGOF_FIG) shows a general scheme for an object module.

(General Object Module Format\FLFGOF_FIG) (POSTSCRIPT\S561C2FLFGOF_FIG.EPS\26)

You must declare all program sections (p-sects, v-sects, and c-sects) defined in a module in GSD items. The size word of each program section definition should contain the size in bytes to be reserved for the section. If you declare a program section more than once in a single object module, the Linker uses the largest declared size for that section. All global symbols that are defined in a given program section must appear in the GSD items immediately following the definition item of that program section.

A special program section, called the absolute section (Use code_example here to make space in name more clear.) (#) ((.#ABS.)), is allocated by the Linker, beginning at location 0 of memory. Immediately after the GSD item that defines the absolute section, declare all global symbols that contain absolute (non-relocatable) values. If you do not want to allocate any memory space for the absolute section, specify zero as its size word. You can do this even if absolute global symbol definitions occur after it.

You must declare in GSD items those global symbols that are referenced but not defined in the current object module. These global references may appear in any GSD item except the very first, which contains the module name. In MACRO, referenced globals are listed in a GSD block under the (Use code_example here to make space in name more clear.) (#) ((.#ABS.)) p-sect. They always have the p-sect definition preceding them.

Note that when a 16-bit word is stored as part of the information in a data block, it is always stored as two consecutive 8-bit bytes, with the low-order byte first.

Object module data blocks vary in length. The first byte in a data block is a code that identifies the type of data block. The codes range from 0 through 10(8), as (FLFRDB_TAB) shows. The format of the rest of the information in the data block depends on the type of data block.

The following sections describe in detail the format of the data blocks. (Global Symbol Directory Block (GSD))

Global Symbol Directory blocks contain all the information the Linker needs to assign addresses to global symbols and to allocate the memory a job requires. (FLFEGB_TAB) shows the eight types of entries that GSD blocks can contain.

(Entries in GSD Blocks\FLFEGB_TAB) (2\5) (EntryType\Description) (0\Module Name) (1\Control Section Name (c-sect)) (2\Internal Symbol Name) (3\Transfer Address) (4\Global Symbol Name) (5\Program Section Name (p-sect)) (6\Program Version Identification (IDENT)) (7\Mapped Array Declaration (v-sect))

Each entry type is represented by four words in the GSD data block. The first two words contain six Radix--50 characters. The third word contains a flag byte and the entry type identification. The fourth word contains additional information about the entry. (FLFGDB_FIG) illustrates the format of the GSD data block and the entry types.

(Global Symbol Directory Data Block\FLFGDB_FIG) (POSTSCRIPT\S561C2FLFGDB_FIG.EPS\22)

The following sections describe the entry types for GSD data blocks. (Module Name (Entry Type 0))

The module name entry, illustrated in (flfge0_FIG), declares the name of the object module. The name need not be unique with respect to other object modules because modules are identified by file, not module name. However, only one module name declaration can occur in a single object module.

(Module Name Entry Format (Entry Type 0)\FLFGE0_FIG) (POSTSCRIPT\S561C2FLFGE0_FIG.EPS\7) (Control Section Name (Entry Type 1))

The control section name entry (see (flfge1_FIG)) declares the name of a control section. The Linker converts control sections -- which include a-sects, blank c-sects, and named c-sects -- to p-sects. For compatibility with other systems, the Linker processes a-sects and both forms of c-sects. See (flfge5_SEC) for the entry the Linker generates for a .PSECT statement.

You can define .ASECT and .CSECT statements in terms of .PSECT statements, as follows:

For a blank c-sect, define a p-sect with the following attributes: .PSECT ,RW,I,LCL,REL,CON

For a named c-sect, the p-sect definition is: .PSECT name,RW,I,GBL,REL,OVR

For an a-sect, the p-sect definition is: .PSECT . ABS.,RW,I,GBL,ABS,OVR

The Linker processes a-sects and c-sects as p-sects with the fixed attributes defined above.

(Control Section Name Entry Format (Entry Type 1)\flfge1_FIG) (POSTSCRIPT\S561C2FLFGE1_FIG.EPS\7) (Internal Symbol Name (Entry Type 2))

The internal symbol name entry (see (flfge2_FIG)) declares the name of an internal symbol with respect to the module. Because the Linker does not support internal symbol tables, the detailed format of this entry is not defined. If the Linker encounters an internal symbol entry while reading the GSD, it ignores it.

(Internal Symbol Name Entry Format (Entry Type 2)\flfge2_FIG) (POSTSCRIPT\S561C2FLFGE2_FIG.EPS\7) (Transfer Address (Entry Type 3))

The transfer address entry (see (flfge3_FIG)) declares the transfer address of a module relative to a p-sect. The first two words of the entry define the name of the p-sect. The fourth word indicates the relative offset from the beginning of that p-sect. If no transfer address is declared in a module, do not specify the transfer address entry in the GSD, or specify a transfer address 000001 relative to the default absolute (Use code_example here to make space in name more clear.) (#) ((.#ABS.)) psect.

To begin execution of a program within a particular object module of a program, specify the starting address to the Linker as the transfer address. The Linker passes the first even transfer address it encounters to RT--11 as the program's starting address. Whenever the resulting program executes, the start address indicates the first executable instruction. If there is no transfer address (if, for example, you did not specify one with the .END directive in a MACRO--11 program), or if all transfer addresses are odd, the resulting program does not self-start when you run it.

(Transfer Address Entry Format (Entry Type 3)\flfge3_FIG) (POSTSCRIPT\S561C2FLFGE3_FIG.EPS\7) When the p-sect is absolute, (Offset \bold)is the actual transfer address if it is not equal to 000001. (Global Symbol Name (Entry Type 4))

The global symbol name entry (see (flfge4_FIG)) declares either a global reference or a definition. All definition entries must appear after the declaration of the p-sect under which they are defined, and before the declaration of another p-sect. Global references can appear anywhere within the GSD.

(Global Symbol Name Entry Format (Entry Type 4)\flfge4_FIG) (POSTSCRIPT\S561C2FLFGE4_FIG.EPS\7)

The first two words of the entry define the name of the global symbol. The flag byte declares the attributes of the symbol. The fourth word contains the value of the symbol relative to the p-sect under which it is defined.

The flag byte of the symbol declaration entry has the bit assignments shown in (FLFGSF_TAB). Bits 1, 2, 4, 6, and 7 are not used by the RT--11 Linker.

(Flag Bits for Global Symbol Name Entry\FLFGSF_TAB) (2\4) (Bit\Meaning) (0\Weak Qualifier 0 = Strong (normal) symbol 1 = Weak symbol) (3\Definition 0 = Global symbol reference 1 = Global symbol definition) (5\Relocation 0 = Absolute symbol value 1 = Relative symbol value) (Program Section Name (Entry Type 5)\flfge5_SEC)

The p-sect name entry (see (flfge5_FIG)) declares the name of a p-sect and its maximum length in the module. It also uses the flag byte to declare the attributes of the p-sect. The default attributes of the p-sect (blank or named with no attributes specified) are as follows: .PSECT ,RW,I,LCL,REL,CON

(P-sect Name Entry Format (Entry Type 5)\flfge5_FIG) (POSTSCRIPT\S561C2FLFGE5_FIG.EPS\7) The length of all absolute sections is zero.

GSD records must be constructed so that after a p-sect name has been declared, all global symbol definitions pertaining to it must appear before another p-sect name is declared. Global symbols are declared by symbol declaration entries. Thus, the normal format is a series of p-sect names, each followed by optional symbol declarations.

(FLFPFB_TAB) shows the bit assignments of the flag byte. Bits 1 and 3 are not used by the RT--11 Linker.

(Flag Bits for P-sect Name Entry\FLFPFB_TAB) (2\4) (Bit\Meaning) (0\Save (Root Allocation) 0 = P-sect scope is determined by the value of bit 6. 1 = P-sect is allocated in the root and its scope is global regardless of the value of bit 6.) (2\Allocation 0 = P-sect references are to be concatenated with other references to the same p-sect to form the total amount of memory allocated to the section. 1 = P-sect references are to be overlaid. The total amount of memory allocated to the p-sect is the size of the largest request made by individual references to the same p-sect.) (4\Access (not supported by RT--11 monitors) 0 = P-sect has read/write access. 1 = P-sect has read-only access.) (5\Relocation 0 = P-sect is absolute and requires no relocation. 1 = P-sect is relocatable and references to the control section must have a relocation bias added before they become absolute.) (6\Scope 0 = The scope of the p-sect is local. References to the same p-sect will be collected only within the overlay segment in which the p-sect is defined. 1 = The scope of the p-sect is global. References to the p-sect are collected across overlay segment boundaries.) (7\Type 0 = The p-sect contains instruction (I) references. Concatenation of this p-sect will be by word boundary. Globals will be given overlay control blocks. 1 = The p-sect contains data (D) references. Concatenation of this p-sect will be by byte boundary. Globals will not go through the overlay handler.) (Program Version Identification (Entry Type 6))

The program version identification entry (see (flfge6_FIG)) declares the version of the module. The Linker saves the version identification, or IDENT, of the first module that defines a nonblank version. It then includes this identification on the memory allocation map.

The first two words of the entry contain the version identification. The Linker does not use either the flag byte or the fourth word because they contain no meaningful information.

(Program Version Identification Entry Format (Entry Type 6)\flfge6_FIG) (POSTSCRIPT\S561C2FLFGE6_FIG.EPS\7) (Mapped Array Declaration (Entry Type 7))

The mapped array declaration (see (flfge7_FIG)) allocates space within the mapped array area of the job's memory. The Linker adds the array name to the list of p-sect names, and subsequent RLD blocks can reference it. The Linker adds the length (in units of 32-word blocks) to the job's mapped array allocation. It rounds up the total amount of memory allocated to each mapped array to the nearest 256-word boundary. The contents of the flag byte are reserved and assumed to be zero. (Only the FORTRAN IV compiler produces this v-sect.)

The Linker processes a v-sect as a p-sect with the following attributes: .PSECT . VIR.,RW,D,GBL,REL,CON

The size is equal to the number of 32(10)-word blocks required. If the length is zero, the segment is the root. There must never be any globals under this section, which starts at a base of 0. One additional address window is allocated whenever a mapped array is declared.

(Mapped Array Declaration Entry Format (Entry Type 7)\flfge7_FIG) (POSTSCRIPT\S561C2FLFGE7_FIG.EPS\7) (End of Global Symbol Directory Block (ENDGSD))

The end of global symbol directory block (see (FLFEGB_FIG)) declares that no other GSD blocks are contained in this module. Exactly one end of GSD block must appear in every object module. The length of the data block is one word.

(End of GSD Data Block\FLFEGB_FIG) (POSTSCRIPT\S561C2FLFEGB_FIG.EPS\3) (Text Information Block (TXT))

The text information block (see (FLFTXT_FIG)) contains a byte string of information that the Linker writes directly into the output file. The block consists of a load address followed by the byte string.

Text records can contain words or bytes of information whose final contents have not yet been determined. This information is bound by a relocation directory block that immediately follows the text block. If the text block does not need modification, then a relocation directory block is not needed. Thus, multiple text blocks can appear in sequence before encountering a relocation directory block.

The load address of the text block is specified as an offset from the current p-sect base. At least one relocation directory block must precede the first text block. This RLD block must declare the current p-sect.

(Text Information Data Block\FLFTXT_FIG) (POSTSCRIPT\S561C2FLFTXT_FIG.EPS\17) (Relocation Directory Block (RLD))

Relocation directory blocks (see (FLFRLD_FIG)) contain the information the Linker needs to relocate and link the preceding text information block. Every module must have at least one relocation directory block that precedes the first text information block. The first block does not modify a preceding text block. Instead, it defines the current p-sect and location.

(Relocation Directory Data Block\FLFRLD_FIG) (POSTSCRIPT\S561C2FLFRLD_FIG.EPS\26)

Relocation directory blocks can contain 14 types of entries. These entries are classified as relocation, or location modification entries. (FLFVET_TAB) lists the valid entry types. (#)

(Valid Entry Types for RLD Blocks\FLFVET_TAB) (2\5) (EntryType\Description) (#1\Internal Relocation) (#2\Global Relocation) (#3\Internal Displaced Relocation) (#4\Global Displaced Relocation) (#5\Global Additive Relocation) (#6\Global Additive Displaced Relocation) (#7\Location Counter Definition) (10\Location Counter Modification) (11\Program Limits (.LIMIT)) (12\P-sect Relocation) (13\Not used) (14\P-sect Displaced Relocation) (15\P-sect Additive Relocation) (16\P-sect Additive Displaced Relocation) (17\Complex Relocation)

Each type of entry is represented by a command byte, which specifies the type of entry and the word or byte modification. This byte is followed by a displacement byte and then by the information required for the particular type of entry. The displacement byte, when added to the value calculated from the load address of the preceding text information block, yields the virtual address in the image that is to be modified. The command byte of each entry has the bit assignments shown in (FLFBAR_TAB). The following sections describe the valid entry types for the RLD data block. (#)

(Bit Assignments for the RLD Command Byte\FLFBAR_TAB) (2\4) (Bit\Meaning) (0--6\Specify the type of entry. Although there is room to specify 128 command types, only 14(10) are currently implemented in the RT--11 Linker.) (##7\Modification (the B bit in Figures (FLFRT1_FIG\VALUE) through (FLFRT17_FIG\VALUE)). This feature is not supported by RT--11, and the bit is ignored if set. The RT--11 Linker supports word relocation, not byte relocation. 0 = The command modifies an entire word. 1 = The command modifies only one byte.) (Internal Relocation (Entry Type 1))

This type of entry (see (FLFRT1_FIG)) relocates a direct pointer to an address within a module. The Linker adds the current p-sect base address to a specified constant and writes the result into the output file at the calculated address -- that is, it adds a displacement byte to the value calculated from the load address of the preceding text block.

For example: A: MOV #A,R0

or .WORD A

(Internal Relocation (Entry Type 1)\FLFRT1_FIG) (POSTSCRIPT\S561C2FLFRT1_FIG.EPS\4) (Global Relocation (Entry Type 2))

This type of entry (see (FLFRT2_FIG)) relocates a direct pointer to a global symbol. The Linker obtains the definition of the global symbol and writes the result into the output file at the calculated address.

For example: MOV #GLOBAL,R0

or .WORD GLOBAL

(Global Relocation (Entry Type 2)\FLFRT2_FIG) (POSTSCRIPT\S561C2FLFRT2_FIG.EPS\4) (Internal Displaced Relocation (Entry Type 3))

This type of entry (see (FLFRT3_FIG)) relocates a relative reference to an absolute address from within a relocatable control section. The Linker subtracts from the specified constant the address plus 2 into which the relocated value is to be written. The Linker then writes the result into the output file at the calculated address.

For example: CLR 177550

or MOV 177550,R0

(Internal Displaced Relocation (Entry Type 3)\FLFRT3_FIG) (POSTSCRIPT\S561C2FLFRT3_FIG.EPS\4) (Global Displaced Relocation (Entry Type 4))

This type of entry (see (FLFRT4_FIG)) relocates a relative reference to a global symbol. The Linker obtains the definition of the global symbol and subtracts from the definition value the address plus 2 into which the relocated value is to be written. It then writes the result into the output file at the calculated address.

For example: CLR GLOBAL

or MOV GLOBAL,R0

(Global Displaced Relocation (Entry Type 4)\FLFRT4_FIG) (POSTSCRIPT\S561C2FLFRT4_FIG.EPS\4) (Global Additive Relocation (Entry Type 5))

This type of entry (see (FLFRT5_FIG)) relocates a direct pointer to a global symbol with an additive constant. The Linker obtains the definition of the global, adds the specified constant, and then writes the resultant value into the output file at the calculated address.

For example: MOV #GLOBAL+2,R0

or .WORD GLOBAL-4

(Global Additive Relocation (Entry Type 5)\FLFRT5_FIG) (POSTSCRIPT\S561C2FLFRT5_FIG.EPS\5) (Global Additive Displaced Relocation (Entry Type 6))

This type of entry (see (FLFRT6_FIG)) relocates a reference to a global symbol with an additive constant. The Linker obtains the definition of the global symbol and adds the specified constant to the definition value. The Linker subtracts from the resultant additive value the address plus 2 into which the relocated value is to be written. It then writes the result into the output file at the calculated address.

For example: CLR GLOBAL+2

or MOV GLOBAL-5,R0

(Global Additive Displaced Relocation (Entry Type 6)\FLFRT6_FIG) (POSTSCRIPT\S561C2FLFRT6_FIG.EPS\5) (Location Counter Definition (Entry Type 7))

This type of entry (see (FLFRT7_FIG)) declares a current p-sect and location counter value. The Linker stores the control base as the current control section. It adds the current control section base to the specified constant and stores the result as the current location counter value.

(Location Counter Definition (Entry Type 7)\FLFRT7_FIG) (POSTSCRIPT\S561C2FLFRT7_FIG.EPS\5) (Location Counter Modification (Entry Type 10))

This type of entry (see (FLFRT10_FIG)) modifies the current location counter. The Linker adds the current p-sect base to the specified constant and stores the result as the current location counter.

For example: .=.+N

or .BLKB N

(Location Counter Modification (Entry Type 10)\FLFRT10_FIG) (POSTSCRIPT\S561C2FLFRT10_FIG.EPS\4) (Program Limits (Entry Type 11))

This type of entry (see (FLFRT11_FIG)) is generated by the .LIMIT assembler directive. The Linker obtains the first address above the header, which is normally the beginning of the stack, and the highest address allocated to the job. It then writes these addresses into the output file at the calculated address and the following location, respectively.

For example: .LIMIT

(Program Limits (Entry Type 11)\FLFRT11_FIG) (POSTSCRIPT\S561C2FLFRT11_FIG.EPS\2) (P-sect Relocation (Entry Type 12))

This type of entry (see (FLFRT12_FIG)) relocates a direct pointer to the beginning address of another p-sect (other than the p-sect in which the reference is made) within a module. The Linker obtains the current base address of the specified p-sect and writes it into the output file at the calculated address.

For example: .PSECT A B: . . . .PSECT C MOV #B,R0

or .WORD B

(P-sect Relocation (Entry Type 12)\FLFRT12_FIG) (keep) (POSTSCRIPT\S561C2FLFRT12_FIG.EPS\4) (P-sect Displaced Relocation (Entry Type 14))

This type of entry (see (FLFRT14_FIG)) relocates a relative reference to the beginning address of another p-sect within a module. The Linker obtains the current base address of the specified p-sect. It then subtracts from the base value the address plus 2 into which the relocated value is to be written and writes the result into the output file at the calculated address.

For example: .PSECT A B: . . . .PSECT C MOV B,R0

(P-sect Displaced Relocation (Entry Type 14)\FLFRT14_FIG) (POSTSCRIPT\S561C2FLFRT14_FIG.EPS\4) (P-sect Additive Relocation (Entry Type 15))

This type of entry (see (FLFRT15_FIG)) relocates a direct pointer to an address in another p-sect within a module. The Linker obtains the current base address of the specified p-sect. It adds the base to the specified constant and then writes the result into the output file at the calculated address.

For example: .PSECT A B: . . . C: . . . .PSECT D MOV #B+10,R0 MOV #C,R0

or .WORD B+10 .WORD C

(P-sect Additive Relocation (Entry Type 15)\FLFRT15_FIG) (POSTSCRIPT\S561C2FLFRT15_FIG.EPS\5) (P-sect Additive Displaced Relocation (Entry Type 16))

This type of entry (see (FLFRT16_FIG)) relocates a relative reference to an address in another p-sect within a module. The Linker obtains the current base address of the specified p-sect and adds it to the specified constant. Next, it subtracts from the resultant additive value the address plus 2 into which the relocated value is to be written. It writes the final result into the output file at the calculated address.

For example: .PSECT A B: . . . C: . . . .PSECT D MOV B+10,R0 MOV C,R0

(P-sect Additive Displaced Relocation (Entry Type 16)\FLFRT16_FIG) (POSTSCRIPT\S561C2FLFRT16_FIG.EPS\5) (Complex Relocation (Entry Type 17))

This type of entry (see (FLFRT17_FIG)) resolves a complex relocation expression. A complex relocation expression is one in which any of the MACRO--11 binary or unary operations are permitted with any type of argument, regardless of whether the argument is unresolved global, relocatable to any p-sect base, absolute, or a complex relocatable subexpression.

The RLD command word is followed by a string of numerically specified operation codes and arguments. The operation codes each occupy one byte and the entire RLD command must fit in a single data block. (FLFOCR_TAB) shows the list of valid operation codes. Note that complex relocation on foreground links causes a warning message from the Linker. The results of complex relocation will be correct if no relocatable symbols are involved. (#)

(Operation Codes for Complex Relocation\FLFOCR_TAB) (2\5) (Code\Description) (#0\No operation) (#1\Addition (+)) (#2\Subtraction (--)) (#3\Multiplication (*)) (#4\Division (/)) (#5\Logical AND (&)) (#6\Logical inclusive OR (!)) (#7\Exclusive OR) (10\Negation (--)) (11\Complement (^C)) (12\Store result (command termination)) (13\Store result with displaced relocation (command termination)) (16\Fetch global symbol. It is followed by four bytes containing the symbol name in Radix--50 representation.) (17\Fetch relocatable value. It is followed by one byte containing the section number, and two bytes containing the offset within the section.) (20\Fetch constant. It is followed by two bytes containing the constant.)

The STORE commands (codes 12 and 13) indicate that the value is to be written into the output file at the calculated address.

The Linker evaluates all operands as 16-bit signed quantities using two's complement arithmetic. The results are equivalent to expressions that are evaluated internally by the assembler. Note the following rules: (NUMBERED) An attempt to divide by 0 yields a 0 result. The Linker issues a warning message. All results are truncated from the left in order to fit into 16 bits. No diagnostic is issued if the number was too large. If the result modifies a byte, the Linker checks for truncation errors. (Byte operations are not allowed.) All operations are perfomed on relocated (additive) or absolute 16-bit quantities. PC displacement is applied to the result only.

For example: .PSECT ALPHA A: . . . .PSECT BETA B: . . . MOV (#A+B->,R1)

(Complex Relocation (Entry Type 17)\FLFRT17_FIG) (keep) (POSTSCRIPT\S561C2FLFRT17_FIG.EPS\5) (Internal Symbol Directory Block (ISD))

Internal symbol directory blocks (see (FLFISD_FIG)) declare definitions of symbols that are local to a module. The Linker does not support this feature; therefore, a detailed data block format is not documented here. If the Linker encounters this type of data block, it ignores it.

(Internal Symbol Directory Data Block\FLFISD_FIG) (keep) (POSTSCRIPT\S561C2FLFISD_FIG.EPS\5) (End Of Module Block (ENDMOD))

The end of module block (see (FLFEMB_FIG)) declares the end of an object module. Exactly one end of module record must appear in each object module. It is one word long.

(End of Module Data Block\FLFEMB_FIG) (keep) (POSTSCRIPT\S561C2FLFEMB_FIG.EPS\3) (Symbol Table Definition File Format (.STB))

The RT--11 Linker can produce a symbol table (.STB) file as its third output file. The text of the .STB file consists of global symbol table definitions. For example, if the source file contains (X == 10), the .STB file contains (X = 10). Or, if the source file contains (A = FOO), the .STB file contains the address of FOO.

The .STB file can serve as a communication link between a background and a foreground job. This communication comes about when you link the background job and obtain a .STB file as output. Then, when you link the foreground job, include the .STB file as one of the input files. The foreground job is then able to reference symbols used by the background job. Similarly, you can use the .STB file to create a communication link between a program and a symbolic debugger.

The internal format of the .STB file consists entirely of Global Symbol Directory (GSD) data blocks followed by one End of Global Symbol Directory (ENDGSD) data block and one End of Module (ENDMOD) data block. (FLFSTBF_FIG) illustrates the .STB file format.

(.STB File Format\FLFSTBF_FIG) (POSTSCRIPT\S561C2FLFSTBF_FIG.EPS\16) (Library File Format (.OBJ and .MLB))

A library file contains concatenated modules and some additional information. RT--11 supports object and macro libraries. Object libraries usually have an .OBJ file type; macro libraries usually have a .MLB file type.

The modules in an object or macro library file are preceded by a Library Header Block and Library Directory, and are followed by the Library End Block, or trailer. (FLFLFF_FIG) shows the format of an object or macro library file.

(Library File Format (.OBJ and .MAC)\FLFLFF_FIG) (POSTSCRIPT\S561C2FLFLFF_FIG.EPS\10)

Diagrams of each component in the library file structure are included in the sections that follow. See the (SUM_BOOK) for information on using the librarian. (Library Header Format\FLFLHF_SEC)

The library header describes the status of the file. Of the two tables that follow, (FLFOLH_TAB) shows the contents of the object library header and (FLFMLH_TAB) shows the contents of the macro library header.

All numeric values shown are octal. The date and time, which are in standard RT--11 format, are the date and time the library was created. This information is displayed when the library is listed. (#)

(Object Library Header Format\FLFOLH_TAB) (3\6\8) (Offset\Contents\Description) (#0\###1\Library header block code) (#2\##42\) (#4\###7\Librarian code) (#6\#500\Library version number) (10\###0\1 if library created with /X option) (12\\Date in RT-11 format (0 if none)) (14\\Time expressed in two words) (16\\) (20\###0\Reserved) (22\###0\Reserved) (24\###0\Reserved) (26\##10\Directory relative start address) (30\\Number of bytes in directory and header) (32\###0\Reserved) (34\\Next insert relative block number) (36\\Next byte within block) (40\\Directory starts here) (#) (Macro Library Header Format\FLFMLH_TAB) (3\6\8) (Offset\Contents\Description) (#0\1001\Library type and ID code) (#2\#500\Library version number) (#4\###0\Reserved) (#6\\Date in RT-11 format (0 if none)) (10\\Time expressed in two words) (12\\) (14\###0\Reserved) (16\###0\Reserved) (20\###0\Reserved) (22\###0\Reserved) (24\###0\Reserved) (26\###0\Reserved) (30\###0\Reserved) (32\##10\Size of directory entries) (34\\Directory starting relative block number) (36\\Number of directory entries allocated; default is 200) (40\\Number of directory entries available) (Library Directories)

There are two kinds of library directories: for object libraries, the directory is an Entry Point Table (EPT); for macro libraries, the directory is a Macro Name Table (MNT). The EPT directory (see (FLFOLH_TAB) for the header format) consists of 4-word entries that contain information related to all modules in the library file.

Note that if you use the librarian /N option for object libraries to include module names, bit 15 of the relative block number word is set to 1. If you invoke the librarian with the monitor LIBRARY command, module names are never included.

(Library Directory Format (.OBJ)\FLFOLD_FIG) (POSTSCRIPT\S561C2FLFOLD_FIG.EPS\8)

In the library directory, the symbol characters represent the entry point or the macro name. The relative byte maximum is 777(8).

The object library directory starts on the first word after the library header, word 40(8). The object library directory is only long enough to accommodate the exact number of modules in the library and space for this directory is not preallocated. The directory is kept in memory during librarian operations, and the amount of available memory is the only limiting factor on the maximum size of the directory. Reserved locations in the header and at the end of the directory -- those not used by the directory -- are zero filled. Modules follow the directory and they are stored beginning in the next block after the directory.

The macro library directory starts on a block boundary, relative block 1 of the library file. (See (FLFMLH_TAB) for the header format) Its size is preallocated. The default size is two blocks, but you can change this by using the librarian /M option. Unused entries in the directory are filled with --1. Macro files are stored starting on the block boundary after the directory. This is relative block 3 of the library file if you use the default directory size.

Modules in libraries are concatenated by byte. (See (FLFMCB_FIG) for an example of byte concatenation.) This means that a module can start on an odd address. When this occurs, the Linker shifts the module to an even address at link time. (Library End Block Format\FLFLEB_SEC)

Following all modules in an object or macro library is a specially coded Library End Block, or trailer, which signifies the end of the file (see (FLFLEB_FIG)).

(Library End Block Format\FLFLEB_FIG) (POSTSCRIPT\S561C2FLFLEB_FIG.EPS\8) (Absolute Binary File Format (.LDA))

Both the Linker /L option and the keyboard monitor LINK command /LDA option produce output files in an absolute binary format. Such a format is suitable for down-line loading of programs, for loading stand-alone application programs, and as input to special programs that put code into ROM (Read-Only Memory).

Absolute binary format, shown in (FLFLDA_FIG), consists of a sequence of data blocks, where each block represents the data to be loaded into a specific portion of memory. The data portion of each block consists of the absolute load address of the block, followed by the absolute data bytes to be loaded into memory beginning at the load address. There can be as many data blocks as necessary in an .LDA file. The last block of the file is special because it contains only the program start address, or transfer address, in its data portion. If this address is even, the Absolute Loader passes control to the loaded program at this address. If the address is odd (that is, if the program has no transfer address, or the transfer address was specified as a byte boundary), the loader halts after loading. The final block of the .LDA file is recognized by the fact that its length is six bytes.

The general procedure for loading a program that will execute in a stand-alone environment is as follows: (NUMBERED) Using the console microcode, load the Bootstrap Loader into memory. If the processor does not contain console microcode, you must toggle the Bootstrap Loader into memory. Using the Bootstrap Loader, load the Absolute Loader into memory. Using the Absolute Loader, load the .LDA file into memory and begin execution.

Most PDP--11 processors contain console microcode that make step 1 unnecessary. The procedure for loading stand-alone programs is described in the (MPH_BOOK). LSI--11/23 computer systems do not have bootstrap loader microcode and require the use of steps 1 and 2.

The Bootstrap Loader is printed on the PDP--11 Programming Card, which is part of every RT--11 distribution kit.

(Absolute Binary Format (.LDA)\FLFLDA_FIG) (POSTSCRIPT\S561C2FLFLDA_FIG.EPS\46) (keep\MULTIPAGE)

The load module's data blocks contain only absolute binary load data and absolute load addresses. All global references have been resolved and the Linker has performed the appropriate relocation. (Standard Save Image File Format (.SAV)\nonidsav_sec)

Standard save images do not support separated I--D space. Standard save images can be run in the background environment under any monitor and as virtual jobs in the foreground or system job environment under mapped monitors. Save image files normally have a .SAV file type. This format is an image of the program exactly as it would appear in memory. (Block 0 -- the first 256-word unit -- of the file corresponds to memory locations 0--776, block 1 to locations 1000--1776, and so on.) See (FLFSB0_TAB) for the contents of block 0 of a standard .SAV file. (Note that not all locations are used for each link; for example, whether the job is for a mapped environment or whether it is overlaid affect block 0.) See also the (SUM_BOOK) for more information on the load modules created by the Linker. (#)

(Information in Block 0 of a .SAV Image\FLFSB0_TAB) (2\8) (Offset\Contents) (######0\VIR in Radix--50 if the Linker /V option was used.) (######2\Virtual high limit if Linker /V option was used.) (######4\Job definition word ($JSX) bits. See (jsx_tab) for bit definitions.) (######6\Reserved) (#####10\Reserved) (#####12\Reserved) (FIRST) (#####14\BPT trap PC(mapped monitors only)) (#####16\BPT trap PSW (mapped monitors only)) (#####20\IOT trap PC (mapped monitors only)) (#####22\IOT trap PSW (mapped monitors only)) (#####24\Reserved) (#####26\Reserved) (#####30\Reserved) (#####32\Overlay definition word (SV.CVH) bits. See tables (ovcvh_tab\value) and (svcvh_tab\value) for bit definitions.) (#####34\Trap vector PC (TRAP)) (#####36\Trap vector PSW (TRAP)) (#####40\Program's relative start address) (#####42\Initial location of stack pointer (changed by /M option)) (#####44\Job Status Word) (#####46\USR swap address) (#####50\Program's high limit) (##52-62\Reserved) (#####64\Address of overlay handler table for overlaid files) (#####66\Address of start of window definition blocks (if /V used)) (#70--356\Reserved) (360--377\Bitmap area)

Location 4 in block 0 contains the job definition word, $JSX. The low three bits in $JSX define certain characteristics about how the program can be loaded and whether the program can be run under VBGEXE. The other bits in $JSX pertain only to programs that support separated I--D space addressing and Supervisor mode. See (jsx_tab) for a description of the $JSX bits.

In overlaid programs, location 32 in absolute block 0 contains the overlay definition word, SV.CVH. The low 5 bits in SV.CVH define the overlay handler and describe the overlay handler characteristics. The high 3 bits in the low byte are reserved and the high byte contains the edit level for the overlay handler source file (and are of no concern to the user). See (ovcvh_tab) for the bit mask that defines each overlay handler and (svcvh_tab) for a description of the SV.CVH bits.

Locations 360--377 are the CCB and are are restricted for use by the system. The Linker stores the program memory usage bits in these eight words, which are called a bitmap. Each bit represents one 256-word block of memory and is set if the program occupies any part of that block of memory. Bit 7 of byte 360 corresponds to locations 0 through 777; bit 6 of byte 360 corresponds to locations 1000 through 1777, and so on. The monitor uses this information when it loads the program.

The monitor commands R and RUN load and start a program stored in a .SAV file. (The RUN command is actually a combination of the GET and START commands.) First, the Keyboard Monitor reads block 0 of the .SAV file into an internal USR buffer. It extracts information from locations 40--64 and 360--377 (the bitmap, described above). Using the protection bitmap (called LOWMAP), which resides in RMON, KMON checks each word in block 0 of the file. It does not load locations that are protected, such as location 54 and the device interrupt vectors. It loads unprotected locations into memory from the USR buffer. Next, KMON sets location 50 to the top of usable memory, or to the top of the user program, whichever is greater.

If the RUN command (or the GET command) was issued, KMON checks the bitmap from locations 360--377 of the .SAV file. For each bit that is set, it loads the corresponding block of the .SAV file into memory. However, if KMON is in memory space that the program needs to use, KMON puts the block of the .SAV file into a USR buffer and then moves it to the file SWAP.SYS.

Finally, when it is time to begin execution of the program, KMON transfers control to RMON. RMON reads the parts of the program, if any, that are stored in SWAP.SYS into memory, where they overlay KMON and possibly the USR. The monitor keeps track of the fact that KMON (and perhaps the USR) are swapped out, and execution of the program begins.

(Job Definition Word ($JSX) Bit Definitions\jsx_tab) (3\8\8) (Bit Mask\Symbol\Meaning) (000001\REQID$\Job requires separated I--D space.) (000002\USEID$\Job uses separated I--D space, if possible.) (000004\REQSM$\Job requires Supervisor mode support.) (000010\USESM$\Job uses Supervisor mode, if possible.) (000020\ALL64$\.SETTOP under VBGEXE supported to top of memory (-2).) (000040\IOPAG$\IOPAGE region under VBGEXE is mapped to PAR7.) (000100\NOVBG$\Job cannot be run under VBGEXE.) (000200\VBGEX$\Job can be run under VBGEXE.) (000400-100000\\Reserved.) (Identifying Overlay Handlers in SV.CVH\ovcvh_tab) (2\8) (Bit Mask\Overlay Handler) (000001\OHANDL) (000003\VHANDL) (000012\XHANDL) (000027\ZHANDL) (Overlay Definition Word (SV.CVH) Bit Definitions\SVCVH_tab) (3\8\8) (Bit Mask\Symbol\Meaning) (000001\CVH.DK\Supports disk-type (/O) overlays) (000002\CVH.MP\Supports virtual-type (/V) overlays) (000004\CVH.ID\Supports separated I--D space and Supervisor Mode) (000010\CVH.XH\Supports single virtual-type overlay only) (000020\CVH.LO\Program loader (VBGEXE) initializes /O overlay area) (000040-000200\\Reserved) (000400-100000\CVH.ED\The edit level of the overlay handlers source file (for Digital internal use only).) (Extended Save Image File Format (.SAV)\idsav_sec)

Support for separated I--D space addressing produces the extended save image file format. Such a job has an odd transfer address that stops it from being run as a standard save image.

The extended save image file format differs from the standard in a number of ways, as illustrated in the following diagram. There is a header for the D-space segments followed by one for the I-space segments. There is a root for each address space and each root contains an overlay handler for that address space. Note also that the D-space header is loaded at physical block 0, while the I-space header is loaded at virtual block 0 (defined at location 40).

(Extended Save Image File Format\idsav_fig) (postscript\s561c2_idsav_fig.eps\17)

The contents of the D-space header (absolute block 0 of the save image) are described in (flfsdb0_tab). The contents of the I-space header are described in (flfsib0_tab). In (flfsdb0_tab) note particularly locations 4, 30, 40, and 60.

LINK couples each I-space segment with a corresponding D-space segment (if there is a corresponding D-space segment). The coupling is identified by a segment number ((segnum)) that is stored in the following 3-word routine at the beginning of each I-space segment: MOV (PC)+,R0 .WORD #12.*segnum RETURN

As mentioned, there need not be a corresponding D-space segment for each I-space segment. Further, there is no segment identifier in D-space segments; they are identified only by an entry in the overlay handler table and the corresponding I-space segment. (#)

(Information in Absolute Block 0 (D-Space Header) of Extended .SAV Image\FLFSDB0_TAB) (2\8) (Offset\Contents) (######0\VIR in Radix--50 if the Linker /V option was used.) (######2\Virtual high limit if Linker /V option was used.) (######4\Job definition word ($JSX) bits. See (jsx_tab) for bit definitions.) (######6\Reserved) (#####10\Reserved) (#####12\Reserved) (FIRST) (#####14\BPT trap PC) (#####16\BPT trap PSW) (#####20\IOT trap PC) (#####22\IOT trap PSW) (#####24\Reserved) (#####26\Reserved) (#####30\Contains 000000 or 100000.

If 000000, all system subroutines linked into program support separated I--D space. Program can be run.

If 100000, at least one system subroutine which cannot support separated I--D space has been linked into the program. Program cannot be run; VBGEXE returns an error at attempt to run program.) (#####32\Overlay definition word (SV.CVH) bits. See tables (ovcvh_tab\value) and (svcvh_tab\value) for bit definitions.) (#####34\Trap vector PC (TRAP)) (#####36\Trap vector PSW (TRAP)) (#####40\Value of (2*blknum+1), where (blknum) is the relative file block number of the I-space CCB (first block after D-space blocks).) (#####42\Initial location of stack pointer (changed by /M option)) (#####44\Job Status Word) (#####46\USR swap address) (#####50\Program's high limit) (#####52\Reserved.) (#####54\Reserved.) (#####56\Reserved.) (LAST) (#####60\Contains (<)IDS> in Radix-50 to indicate separated I--D space job.) (#####62\Reserved.) (#####64\Address of overlay handler table for overlaid files) (#####66\Address of start of window definition blocks (if /V used)) (#70--356\Reserved) (360--377\CCB (core control block) bitmap area) (#)

(Information in Relative Block 0 (I-Space Header) of Extended .SAV Image\FLFSIB0_TAB) (2\8) (Offset\Contents) (###0--36\Contain 000000) (#####40\Program's relative start address (interpreted as a User mode I-space virtual address.)) (##42--46\Contain 000000) (#####50\Program's I-space high limit) (#52--356\Contain 000000) (360--377\I-space CCB (core control block) bitmap area) (Relocatable File Format (.REL))

To link a foreground job, use the Linker /R option or the keyboard monitor LINK command with the /FOREGROUND option. This causes the Linker to produce output in a linked, relocatable format, with a .REL file type. Note that system files are also stored in relocatable format. The only difference is that system files use a file type of .SYS instead of .REL. (#)

(Information in Block 0 of a .REL Image\FLFRB0_TAB) (2\8) (Offset\Contents) (######0\VIR in Radix--50 if the Linker /V option was used.) (######2\Virtual high limit if Linker /V option was used.) (######4\Job definition word ($JSX) bits. See (jsx_tab) for bit definitions.) (######6\Reserved) (#####10\Reserved) (#####12\Reserved) (FIRST) (#####14\BPT trap PC(mapped monitors only)) (#####16\BPT trap PSW (mapped monitors only)) (#####20\IOT trap PC (mapped monitors only)) (#####22\IOT trap PSW (mapped monitors only)) (#####24\Reserved) (#####26\Reserved) (#####30\Reserved) (#####32\Overlay definition word (SV.CVH) bits. See tables (ovcvh_tab\value) and (svcvh_tab\value) for bit definitions.) (#####34\Trap vector PC (TRAP)) (#####36\Trap vector PSW (TRAP)) (#####40\Program's relative start address) (#####42\Initial location of stack pointer (changed by /M option)) (#####44\Job Status Word) (#####46\USR swap address) (#####50\Program's high limit) (#####52\Size of program's root segment, in bytes.) (#####54\Stack size, in bytes (changed by /R:n option).) (#####56\Size of overlay region, in bytes (0 if not overlaid)) (LAST) (#####60\.REL file ID (REL in Radix--50)) (#####62\Relative block number for start of relocation information) (#####64\Address of overlay handler table for overlaid files) (#####66\Address of start of window definition blocks (if /V used)) (#70--356\Reserved) (360--377\Bitmap area)

The object modules used to create a .REL file are linked as if they were a background .SAV image, with a base of 1000. This permits you to use .ASECT directives to store information in locations 0 through 777 in .REL files. All global references have been resolved. The Linker does not relocate the .REL file at link time; it merely includes relocation information to be used at FRUN time. The relocation information in the file is used to determine which words in the program must be relocated when the job is installed in memory.

There are two types of .REL files to consider: those programs with overlay segments, and those without them. (.REL Files Without Overlays)

A .REL file for a program without overlays appears as shown in (FLFRWO_FIG).

(.REL File Without Overlays\FLFRWO_FIG) (POSTSCRIPT\S561C2FLFRWO_FIG.EPS\3)

Block 0 (relative to the start of the file) contains the information shown in (FLFSB0_TAB). Some of this information is used by the FRUN processor.

In the case of a program without overlays, the FRUN processor performs the following general steps to install a foreground job. (NUMBERED) It reads block 0 of the file into an internal monitor buffer. It obtains the amount of memory required for the job from location 52(8) of block 0 of the file, and allocates the space in memory by moving KMON and the USR down. It reads the program text into the allocated space. It reads the relocation information into an internal buffer. It relocates the locations indicated in the relocation information area by adding or subtracting the relocation quantity. This quantity is the starting address the job occupies in memory, adjusted by the relocation base of the file. .REL files are linked with a base of 1000.

The relocation information consists of a list of addresses relative to the start of the user's program. The monitor scans the list, and for each relative address computes an actual address. That address is then loaded with its original contents plus or minus the relocation constant. The relocation information is shown in (FLFRRI_FIG).

(Root Relocation Information Format\FLFRRI_FIG) (POSTSCRIPT\S561C2FLFRRI_FIG.EPS\15)

In (FLFRRI_FIG), bits 0 through 14 represent the relative address to relocate divided by 2. This implies that relocation is always done on a word boundary, which is indeed the case. Bit 15 indicates the type of relocation to perform -- positive or negative. The relocation constant (which is the load address of the program) is added to or subtracted from the indicated location depending on the sense of bit 15; 0 implies addition, while 1 implies subtraction. A full 16-bit word is the original contents. The value 177776, or --2, terminates the list of relocation information for a file without overlays. (.REL Files with Overlays)

When you include overlays in a program, in addition to relocating the root segment, the FRUN processor must also relocate the overlay segments. Since overlays are not permanently memory resident but are read in from the file as needed, they require an additional operation. FRUN relocates each overlay segment and rewrites it into the file before the program begins execution. (Therefore, the volume containing the file must be write-enabled.) Thus, when the overlay is called into memory during program execution, it is correct. This process takes place each time you run an overlaid file with FRUN or SRUN. The relocation information for overlaid files contains both the list of addresses to be modified and the original contents of each location. This allows the file to be executed again after the first usage. It is necessary to preserve the original contents in case some change has occurred in the operating environment. Examples of these changes include using a different monitor version, running on a system with a different amount of memory, and having a different set of device handlers or system jobs resident in memory. (FLFRAO_FIG) shows a .REL file with overlays. Refer to (FLFRRI_FIG) and (FLFORB_FIG) for more detail of the relocation information.

(.REL File with Overlays\FLFRAO_FIG) (POSTSCRIPT\S561C2FLFRAO_FIG.EPS\32)

(Overlay Segment Relocation Block\FLFORB_FIG) (POSTSCRIPT\S561C2FLFORB_FIG.EPS\17)

In the case of a .REL file with overlays, location 56 of block 0 of the .REL file contains the size in bytes of all the overlay regions. FRUN adds this size to the size of the program base segment (in location 52) to allocate space for the job.

After FRUN relocates the program base (root) code, it reads each existing overlay into the program overlay region in memory, relocates it using the overlay relocation information, and then writes it back into the file.

The root relocation information section is terminated with a --1. This --1 is also an indication that an overlay segment relocation block follows.

The relocation is relative to the start of the program and is interpreted as if it were in a file without overlays (that is, bit 15 indicates the type of relocation, and the displacement is the true displacement divided by 2). Encountering --1 indicates that a new overlay region begins here; a --2 indicates the termination of all relocation information. (Stream ASCII File Format)

Source files, such as MACRO--11 and FORTRAN IV programs, and text files that you create with an editor are in stream ASCII format. These files consist of a series of bytes, each byte representing an ASCII character. Stream ASCII files have no special headers or end blocks, nor do they include any formatted binary blocks. (Defining a Line or Record)

RT--11 typically defines a line of input as a string of characters terminated by a linefeed (012(8)) or formfeed (014(8)). Some programs also define vertical tab (013(8)) as a line terminator. In RT--11, linefeeds generally come as part of a carriage return/linefeed pair (the RETURN key), but treating carriage-return (015(8)) as a line terminator can cause complications in some programming applications and should be avoided. For example, treating carriage return as a line terminator makes it more difficult to do overprinting. Instead, consider the linefeed to be the line or record terminator. (End-of-File)

Although not required, an 032(8), or CTRL/Z character, may terminate a stream ASCII file. When you use PIP with the /A option (or when you use the monitor COPY/ASCII command) to copy an ASCII file, PIP expects to find a CTRL/Z at the end of the file. If there is an embedded CTRL/Z character within the file, PIP considers the CTRL/Z to mark the file's end, and any characters following the CTRL/Z are ignored. When you use PIP in its default mode (image) or when you use the monitor COPY command without any option to copy an ASCII file, PIP does not look for a CTRL/Z character. It simply copies blocks until it reaches the end of the file.

Programs that process stream ASCII files should ignore nulls (000(8)). Many programs that write ASCII files fill the remainder of the last block of the file with nulls instead of appending a CTRL/Z. When reading such a file, a program can read all the data in the file, ignore the trailing nulls, then receive an end-of-file error from RT--11 when it tries to read beyond the last block of the file. (CREF File Format)

The RT--11 CREF program produces a cross-reference listing. You can only run CREF indirectly -- that is, by chaining to it from another program, such as your own language processor. CREF appends its cross-reference table to the listing file your calling program creates.

To chain to CREF, you must first store some information in the chain communication area (absolute locations 500 through 776) of the calling program. (FLFCCI_TAB) lists the information that CREF requires. (#)

(CREF Chain Interface Specification\FLFCCI_TAB) (3\8\12) (Location\Contents\Description) (####500\.RAD50##/SY#/\The file specification to call CREF:) (####502\.RAD50##/CRE/\) (####504\.RAD50##/F##/\) (####506\.RAD50##/SAV/\) (####510\\RT--11 channel number of output file) (####512\\Radix--50 name of output device) (####514\\Highest output block number written, plus 1) (####516\\RT--11 channel number of input file) (####520\\Radix--50 name of input device) (####522\\Highest input block number written, plus 1) (####524\\Listing format: 0 = 80 columns, --1 = 132) (####526\.RAD50##/dev/\Program to chain back to. (If this value is zero, CREF closes the listing file and exits.)) (####530\.RAD50##/fil/\) (####532\.RAD50##/nam/\) (####534\.RAD50##/typ/\) (536--776\\.ASCIZ string for CREF to use as title line (no page number))

The input file you supply to CREF must consist of 12(10)-byte entries, one entry for each reference to a symbol. (FLFCIF_TAB) shows the format of the entries. (#)

(Entry Format for CREF Input File\FLFCIF_TAB) (2\8) (OctalByte\Offset Value) (####0\Section descriptor: Bits 0 through 4 contain an alphabetic character for CREF to use as the section name. The ASCII value is stripped to 5 bits. Bits 5 through 7 contain the section number. This number controls the order of the sections.) (##1--6\The ASCII name of the symbol.) (#7--10\The page number, in binary. Put --1 here if you are not using page numbers.) (11--12\The line number, in binary.) (###13\A one-character identifier for CREF to print next to this reference. Typically, this character is used to identify a destructive reference or a definitional reference.) (BUP Saveset Section Definition Block Format\flfbup_sec)

A BUP saveset consists of at least one section; more that one section is created if the saveset spans more than one output volume. Each section is a complete, protected RT--11 file. Block 0 of each section contains information for that section that BUP uses in directory and restoration operations. (FLFPBC_TAB) describes the contents of a BUP saveset block 0. (#)

(Contents of Block 0 of a BUP Saveset Section\FLFPBC_TAB) (2\10) (StartingOffset\Contents) (####0--1\Number of definition blocks (currently = 1)) (####2--5\Radix--50 "BUP" and three spaces) (####6--7\Major version number of BUP that created the file section) (##10--11\Minor version number of BUP that created the file section) (##12--17\Reserved (zero)) (##20--21\First three characters of filename, in Radix--50) (##22--23\Last three characters of filename, in Radix--50) (##24--25\File type, in Radix--50) (##26--27\Reserved (zero)) (##30--31\First file section length) (##32--33\Intermediate file section lengths) (##34--35\Last file section length) (##36--37\Total saveset length (without definition blocks)) (##40--41\Number of file sections in saveset) (##42--43\Section number of this file section) (##44--45\Reserved (zero)) (##46--47\Date of backup (RT--11 date word format)) (##50--57\Time of backup (four words: HOUR, MINUTES, SECONDS, TICKS)) (#60--177\CSI command line that created the saveset) (200--777\Reserved (zero)) (Error Log File Formats)

Device handlers that support error logging call the error logger through a monitor pointer on each successful I/O transfer as well as on each error. The (copy code \bold)in the error logger retrieves, or copies, the appropriate information from the handler, storing it in the error log input buffer in the error logger's memory area. The error log job is suspended until the copy routine puts some data into the input buffer, at which point the monitor resumes the error log job so it can process the new data.

The error log job remains suspended until the error log input buffer has filled to 200(10) or more words of the 256(10)-word total buffer size. The copy code portion of the EL job informs the monitor of this by setting the carry bit on return. Thus the error log job is resumed by the monitor only when the error log input buffer contains a sizeable amount of information to be processed.

For device errors, cache errors, and memory parity errors, the error logger first creates or updates the unit statistics information in the copy of the disk file header that is in memory. The EL job (disk output code) stores error records in the disk output buffer (one of two buffers, since double-buffering is used) until a 256(10)-word block is full. That is, it stores records until the buffer cannot contain the next record. Then it writes the updated header record and the accumulated error records to a disk file called ERRLOG.DAT. (FLFELS_FIG) describes the error logging subsystem.

For successful I/O transfers, the error logger first creates or updates the unit statistics information in the copy of the disk file header that is in memory, as it does with device and memory errors. It writes the updated header to disk only after 10(10) good I/O transfers have been logged.

(Error Logging Subsystem\FLFELS_FIG) (POSTSCRIPT\MLO-007350B\34.5) (Error Log Disk File Format)

The error log disk file is called ERRLOG.DAT. (FLFEDF_FIG) shows its format.

The first part of the figure describes the contents of block 0, the header block. For each device on which error logging is done, there is a statistics record (a 7-word entry) in block 0. Since the number of records is a variable SYSGEN parameter, the pointer at the beginning of block 0 points to the end of these device-specific records in block 0.

The second part of the figure, beginning with block 1, describes the 256-word blocks containing error records. The data in these records will vary depending on the situation. The blocks can contain statistics on device errors, memory errors, or both, depending on the error logging you have enabled and the order in which error-logging events happen.

The low byte of the first word for both Device Error and Memory Error Reports contains the record size. Records are contiguous within blocks and, therefore, the (size of this error record) field is an offset to the next record in the block. The final record in each block contains a -1 in the size field, indicating that the next record in the file begins at the first word of the next block.

The (Unit Number) field in the Device Error Record and the (Parity ID) field in the Memory Error Record indicate the kind of error (Device or Memory) which is being reported. If the field contains a value equal to or greater than zero, the report is for a device error and the field contains the device unit number reporting the error. If the value in the field is less than zero, the report is for a memory error and the values have the following meaning:

(2\6) (--2\for a memory error) (--3\for a cache error) (--4\for both memory and cache error)

(ERRLOG.DAT Format\FLFEDF_FIG) (\MULTIPAGE) (POSTSCRIPT\S561C2FLFEDF1_FIG.EPS\37) (POSTSCRIPT\S561C2FLFEDF2_FIG.EPS\45) (A dummy index entry) (End of Chapter) (End of manual)