unisys ClearPath OS 2200 Data Structures Programming Reference Manual imagine it. done. ClearPath OS 2200 Release 13.0 February

Size: px
Start display at page:

Download "unisys ClearPath OS 2200 Data Structures Programming Reference Manual imagine it. done. ClearPath OS 2200 Release 13.0 February 2011 7833 3481 002"

Transcription

1 unisys imagine it. done. ClearPath OS 2200 Data Structures Programming Reference Manual ClearPath OS 2200 Release 13.0 February

2 NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product or related information described herein is only furnished pursuant and subject to the terms and conditions of a duly executed agreement to purchase or lease equipment or to license software. The only warranties made by Unisys, if any, with respect to the products described in this document are set forth in such agreement. Unisys cannot accept any financial or other responsibility that may be the result of your use of the information in this document or software material, including direct, special, or consequential damages. You should be very careful to ensure that the use of this information and/or software material complies with the laws, rules, and regulations of the jurisdictions with respect to which it is used. The information contained herein is subject to change without notice. Revisions may be issued to advise of such changes and/or additions. Notice to U.S. Government End Users: This is commercial computer software or hardware documentation developed at private expense. Use, reproduction, or disclosure by the Government is subject to the terms of Unisys standard commercial license for the products, and where applicable, the restricted/limited rights provisions of the contract data rights clauses. Unisys and ClearPath are registered trademarks of Unisys Corporation in the United States and other countries. All other brands and products referenced in this document are acknowledged to be the trademarks or registered trademarks of their respective holders.

3 Contents Section 1. Introduction 1.1. Documentation Updates Related Data Structure Formats Notation Conventions Section 2. Absolute Element Format 2.1. Absolute Element Format Absolute Element Format Header Table Format Bank Load Table Format Absolute Element Text and Access Control Word Formats ACW Formats Example of ACWs in an Absolute Element Segment Load Table Entry Formats Collector-Generated Tables ENTRY$ Entry-Point Table XREF$ External Reference Table COMMN$ Common Block Table S$NAP$ Table Relocatable Segments Diagnostic Table Formats Segment Name Table Element Name Table Bank Name Table Location Counter Table Entry-Point Name Table Absolute Value Definition Table CAP-Element Format CAP-Element Header Table CAP-Element Bank Load Table Section 3. Attributed Character Data Format 3.1. Attributes Part Sub-string Description Attribute Items Text Part Padding Bytes Encoding Example Processing ACD iii

4 Contents Section 4. DIAG$ File Format 4.1. DIAG$ File Format for Collector-Generated Absolutes DIAG$ File Format for Object Modules, ZOOMs, and Absolutes with the TYPE NPEDIAG Directive File Header Format Program Header Activity Entry Section 5. FURPUR/PCFP File Formats 5.1. Basic File Formats FURPUR Tape File Format Revised Format Original FURPUR Format and Its Variants Element File Format Multi-reel Files Section 6. Internal Format (INFOR) 6.1. INFOR Identifiers for Processor Call Statement The INFOR Table INFOR Table Example Reading the INFOR Table Determining the INFOR Table Size Section 7. Object Module Format 7.1. Object Module (OM) Layout OM Overview OM Level Structures The OM Control Header OM Header OM Header Extension Complete Name Table OM Definitions Bank Group Header Element Table Banks Bank Header Bank Header Extension Bank Control Information Bank Reference Table Bank Text Information Access Control Words (ACW) Bank Part Entry P-codes P-code Operand Types Link Relative Pointer P-code Operators iv

5 Contents Find Normal Name Find Common Block Name Find Normal Name in RNT Find Common Block Name in RNT Find Initialized Common Block Name in RNT Perform Incompatibility Resolution Check Parameters Short Check Parameters Long Retrieve Definition Value Branch on Failure Branch on Success Branch Unconditionally Call P Expression Return Provide Value Provide Common Block Name Pop Push Add Subtract Shift Left Shift Right Truncate Value Provide Common Block Value NOP No Operation Provide Definition Index Set Failure Flag Clear Failure Flag Enable Soft Fail Resolve Normal Name Short Resolve Normal Name Long Resolve Definition Short Resolve Definition Long Define Normal Name Short Define Normal Name Long Define Common Block (Referencer) Define Common Block (User) Define Common Block (Definer) Provide Resolve Value Provide Common Block Definition Value Resolve Heap ID Section 8. Program File Format 8.1. Standard Program File Minimum Program File Large Program File File Table Index File Table Index Format Large Program File FTI Format Program File Tables v

6 Contents 8.6. Element Table Symbolic Element Table Item Relocatable Element Table Item Executable Element Table Item Omnibus Element Table Item Procedure Tables Assembler, FORTRAN, and PLUS Procedure Table Item COBOL Procedure Table Item Relocatable Element Entry-Point Table Object Module Entry-Point Table Number of Table Entries Program File Creation and Maintenance LEPF Considerations Section 9. Relocatable Binary Format 9.1. The Preamble Base Table Location Counter Table Undefined Symbol Table Entry-Point Table Control Information (INFO) Table The Text Word Groups Group Counter Relocation Bits Relocation Field Selection Section 10. Shift-Code Format (Kanji) Shift-Code Format Shift-Code Examples Processing Shift-Code Format Section 11. Symbolic Debugging Dictionary Format Restrictions Level Level U Link String SDD SDD Header SDD Pointer Table Pointer Table Entry SDD Procedure Table Procedure Logical Bank Table (PROC_LB_TABLE) Register Save Table (PRO_REGSV TABLE) vi

7 Contents Procedure Parameter Table (PROC_PARM_TABLE) Variable Table (SDELVARIABLE_TABLE) VBL_ADDRTYPE VBL Format Type VBL Format Info VBL Array Info VBL Structure Info VBL Enumeration Info SDD Label Table SDD Internal Statement Number Table SDD Statement Table SDD Used-Set Table Entry SDD Source Name Table Entry SDD AFA Offset Table AFA Offset Table Entry SDD LB Relocation Table Section 12. System Data Format SDF Types Unspecified Symbiont Complex (Types C, I, and P) FORTRAN V Library (Type F) General Symbolic (Type S) PCIOS (Type X) Data Record Formats READ$ Data Records PRINT$ Data Records PUNCH$ Data Records General Symbolic Data Records PCIOS Data Records Control Record Formats Bypass Control Record (040) Character Set Change Control Record (042) Label Control Records (050) Continuation Control Record (051) SIR$ Line-Change Control Record (052) CTS/IPF Line Number Control Record (053) ER PRTCN$ Control Records (060) Special Print Control Records PRINT$ (061) PCHCN$ Control Records (070) End-of-File Control Record (077) Section 13. System Library Structure Creating the System Library Structure Maintaining the System Library Structure The Exec Bootstrap and Its Effect on the System Library Structure Installation Status vii

8 Contents The Internal Structure of the System Library SYS$*DATA$ File SYS$LIB$*PROC$ File SYS$LIB$*RUN$ File Search Orders Processor Search Order Common Bank Search Order Universal Compiling System Library Search Order System Runstream Search Order Collector Search Order SYS$*DATA$ Elements CO$INSTALL$/COMUS$ CO$INSTALL$/HISTORY FILE-BDI$ LIB-ABS$ LIB$NAMES PACKAGE/PRODUCT and the PACKAGE_INFO SGS PROC$ELT and the PROC$ELT SGS SSDEF$ ELMS-DIR$ KEYTABLE$ KEYTABLE$/HISTORY Product Installation Files BANK-BDI$ Subsystem Definition Elements File Security on Product Installation Files SYS$LIB$*PROC$ SYS$*RUN$ and SYS$LIB$*RUN$ AUTO$START Elements SYS$LIB$ and SYS$LIB$*LIB$ SYS$*LIB$ SYS$LIB$*LIB$ SYS$*RLIB$ Section 14. Zero Overhead Object Module Format ZOOM Format Overview ZOOM Level Structures Program File Table of Contents (TOC) ZOOM Header Bank Group Table Entry Bank ID Table Bank Load Table Entry ACW Table Glossary... 1 viii

9 Figures 2 1. Example of Overlay Segments That Span Banks Example of Overlay Segments That Do Not Span Banks Main Segments in Non-initially Loaded Dynamic Banks Main Segments in Initially Loaded Dynamic and Static Banks Attributed Character Data Format FURPUR Control Statements Used to Alter File Formats OM Level Structures OM Control Header OM Header OM Header Extension Link String Format Definition Entry Format Bank Group Header Element Table Element Part Table Element Name Table File Name Table OM Bank Header OM Bank Header Extension OM Bank Control Information Bank Reference Entry Bank Text Information ACW Format Bank Part Entry OM p-code format Find Normal Name Find Common BlockName Find Normal Name in RNT Find Common Block Name in RNT Find Initialized Common Block Name in RNT Find Normal Name Check Parameters Short Check Parameters Long Retrieve Definition value Branch on Failure Branch on Success Branch Unconditionally Call P Expression Return Provide Value ix

10 Figures Provide Common Block Name Pop Push Add Subtract Shift Left Shift Right Truncate Value Provide Common Block Value NOP No Operation Provide Definition Index Set Failure Flag Clear Failure Flag Enable Soft Fail Resolve Normal Name Short Resolve Normal Name Long Resolve Definition Short Resolve Definition Long Define Normal Name Short Define Normal Name Long Define Common Block (Referencer) Define Common Block (User) Define Common Block (Definer) Provide Resolve Value Provide Common Block Definition Value Resolve Heap ID Program File Structure Program File Format Program File Example Large Program File Format File Table Index Format (cont.) Large Program File FTI Format Program File Table Format (Including Pointer Table) Symbolic Element Table Item Relocatable Element Table Item Executable Element Table Item Omnibus Element Table Item Assembler, FORTRAN, and PLUS Procedure Table Item COBOL Procedure Table Item Relocatable Element Entry-Point Table Item Standard Relocation Information Bit Stream Enhanced Relocation Information Bit Stream Link String SDD SDD_HEADER SDD Pointer Table Pointer Table Entry SDD Procedure Table PROC_LB_TABLE x

11 Figures PROC_REGSV TABLE PROC PARM TABLE SDD Variable Table VBL_FORMAT INFO VBL_ARRAY_INFO Short form VBL_ARRAY INFO - Long form VBL_STRUCT INFO VBL Enumeration Info Entry SDD_LABEL TABLE SDD Internal_Statement_Numbertable SDD_STATEMENT TABLE Header for line Statement 10.1.s Statement 10.1.s Statement Statement Statement 12.c Statement Statement Statement SDD Used-Set Table Entry Used Table Item Entry Set Table Item Entry Unresolvable Table Item Entry Item Entry SDD AFA_OFFSET_TABLB AFA_OFFSET TABLE ENTRY SDD_LB_RELOCATION TABLE Library Structure Overview Zoom Structure Zoom Header Bank Group Table Entry Bank ID Table Bank Load Table Entry ACW Table xi

12 Figures xii

13 Tables 2 1. Mapping of Bits in Type Field to Bank Types Group Counter Field Group Counter Relocation Functions Word Addresses Field Size Indicator Bits Function Identifier Formats Relocation Modification Values Additional Modification Indicators SDF Types xiii

14 Tables xiv

15 Examples 2 1. ACWs in an Absolute Element SOLAR Product Summary Report Collector Output for File Search xv

16 Examples xvi

17 Section 1 Introduction This manual contains information on the data structures used in the OS 2200 operating system. It is a reference manual for use by OS 2200 development and support programmers and site systems analysts. This manual explains the relationships of the data structures. Many of the sections consist of tables and figures diagramming formats Documentation Updates This manual contains all the information available at the time of publication. Technical changes that were not available at that time are supplied in PLE To obtain a copy of the PLE, contact your Unisys representative or access the current PLE from the Unisys Product Support Web site: Note: If you are not logged into the Product Support site, you will be asked to do so. Audience This manual is intended for use by OS 2200 development and support programmers and site systems analysts. Prerequisites This manual requires a general knowledge of computers and operating systems. Before using this manual, the audience should be familiar with file formats. How to Use This Manual Since this manual is primarily a reference and not an instructional tool, many of the sections consist of tables and figures diagramming formats, entries, and relationships of the data structures

18 Introduction 1.2. Related Data Structure Formats The following is a list of data structures that are described in other documents or available from the 2200 S&SwPI Compiler Products group. Master File Directory See the OS 2200 Exec System Software Administration Reference Manual. Tape Labeling Formats See the OS 2200 Exec System Software Administration Reference Manual. Log Entry File Formats See the OS 2200 System Log Operations and Support Reference Manual. FAS Volume Formats See the OS 2200 File Administration System (FAS) Operations Guide Notation Conventions The OS 1100 Meta-Assembler mnemonics are used whenever machine instructions are discussed. For more information on these mnemonics, refer to the MASM Programming Reference Manual. The mnemonics U and XU indicate immediate data references (operand taken directly from the address portion of the instruction rather than from the main storage referenced by that address). The mnemonics XH1, XH2, and XU indicate that the 18-bit value is to be loaded with sign-extension to 36 bits (that is, if bit 18 is a one, bits 0 17 are set to one). Control registers are indicated by the following mnemonics: A0, A1,..., A15 Accumulators (A0 A3 can also be used as index registers). A15+1, A15+2 Additional accumulators for double-register instructions. X1, X2,..., X11 Index registers. R0, R1, R2,..., R15 R-registers

19 Introduction Activities can use one of two sets of control registers, the major set (all control registers as given above) or the minor set (registers X8 through X11, A0 through A5, and R1 through R3). Subroutines frequently use a subset of the minor set called volatile registers (that is, data left in these registers cannot be saved). This subset includes registers X11, A0 through A5, and R1 through R3. The dollar sign ($) is generally used in system-defined external symbols, procedure names, and file names; to avoid duplication, do not use this character. The $ generally occurs as the last character of a symbol, but for procedure names it is usually the second character. In packet and table formats, brackets ([ ]) are used to indicate optional parameters. The symbol is used to indicate a blank character. In control statements, Executive request (ER), and procedure call formats, capital letters represent themselves and must be coded as shown. Lowercase letters represent variables that must be coded as directed in the text. Numbers are represented as in assembler syntax; that is, a leading zero specifies octal. In this manual, the 36 bits in the OS 2200 computer word are numbered 00 to 35 from left to right. Previously, the bits were numbered 00 to 35 from right to left. Boldface type is used in the diagram description to indicate field names. If a field description does not fit in the space available in the diagram, an asterisk appears in the field. This is explained in the description that follows the diagram

20 Introduction

21 Section 2 Absolute Element Format 2.1. Absolute Element Format An absolute element contains a complete program in binary form suitable for execution by the Exec. Such elements normally occur as output from a collection of relocatable elements, with all necessary linkages and relocation performed. The header table is always at the beginning of the element and is 28 words in length. The table is followed by the bank load table (BLT). This information is used by the OS 2200 Exec to load program banks. Following the BLT may be a common bank list. This is used by the Exec to keep records of common bank usage. Following the above tables are the overlay segments. The main segment follows the overlay segments. Intermixed with segment instructions and data are load control groups. Each 28-word load control specifies the relative storage address of the blocks of instructions and data that follow. All load control groups start at a sector boundary when the program resides on sector-formatted mass storage. Usually program instructions are contained in logical structures called I-banks, while the data is contained in D-banks. One bank of a program (either an I-bank or D-bank) is designated as the control bank. For segmented programs, the table used in loading the segments is included in the main segment of the program control bank. A table of entry points to the program, a table of undefined references from the program, and a list of common data areas are also included in the main segment of the control bank when entry points are specified by DEF directives or external references are specified by REF directives in the Collector source language

22 Absolute Element Format The various tables used by diagnostic routines follow the main segment. These tables are Static diagnostic pointer table and static diagnostic text (user-formatted) Segment name table Element name table Bank name table Location counter table Entry-point name table Absolute value definition table Any relocatable segments (RSEG) in the program are output first. The overlay segments are output in the same order as specified in the source language, and the main segment is output last. Each segment is output by portion within a bank in order of ascending bank descriptor indexes (BDI). Banks are assigned ascending BDIs as follows: Z option banks S option banks Non-initially based dynamic banks Initially based dynamic banks Static banks Control bank INFO-11 banks Link vector bank

23 Absolute Element Format 2.2. Absolute Element Format The absolute element format is as follows: header table bank load table common bank list (if present) text of overlay segments text of main segments (all but the control bank) segment load table (SLT$) (if present) entry-point table (ENTRY$) (if present) external reference table (XREF$) (if present) indirect load table (if present) text of main segment of control bank static diagnostic pointer table (present if any INFO group 8 in collection) static diagnostic text (present if any INFO group 8 in collection) segment name table (SNT) (present unless Z option used call) element name table (ENT) (present unless Z option used call) bank name table (BNT) (present unless Z option used call) location counter table (LCT) (present unless Z option used call) entry-point name table (EPNT) (present unless Z option used call) absolute value definition table (ABSV) (present unless Z option used call) Note: Solid lines denote sector boundaries

24 Absolute Element Format 2.3. Header Table Format The header table format is as follows: 00 sentinel ( ) 01 E 0 BDI-initial PSRMI (BDR 0) E 0 BDI-initial PSRMD (BDR 2) 02 E 0 BDI-initial PSRUI (BDR 1) E 0 BDI-initial PSRUD (BDR 3) E 0 BDI-control bank program start address 05 sector address of main segment access control word (ACW) for initially loaded banks 06 number of 4-word SLT entries SLT word length 07 B N time and date of absolute element creation (reversed TDATE$ format) 016 Fieldata SYS$*RLIB$ ID (see note 2) 017 options in master bit notation 020 sector address of diagnostic tables 021 static diagnostic pointer table word length control bank SLT$ address 022 number of ENTRY$ entries control bank ENTRY$ address 023 number of COMMN$ entries control bank COMMN$ address 024 number of XREF$ entries control bank XREF$ address 025 number of indirect load table entries control bank IDL table address 026 word length of LCT word length of BNT 027 word length of SNT word length of ENT 030 word length of EPNT word length of static diagnostic including pointer table 031 word length of ABSV word length of BLT 032 C total mass storage word length of element

25 Absolute Element Format Notes: 1. All sector addresses are relative to the header table sector address. 2. Word 016 previously contained the SYS$*RLIB$ ID provided by SYSLIB, when SYSLIB was installed in SYS$*RLIB$. When SYSLIB was moved to its own standard library file, a SYS$*RLIB$ ID was no longer available and is no longer inserted into word 016. When tables are not included, the corresponding entries in the header table are cleared to zero. Abbreviations used are as follows: E SLT B N LCT BNT SNT ENT EPNT ABSV BLT C Set if the BDI is for the Exec bank descriptor table (BDT) Segment load table Set if TYPE BLOCKSIZE64 was specified Set if TYPE NPEDIAG was specified Location counter table Bank name table Segment name table Element name table Entry-point name table Absolute value definition table Bank load table Set by partial checkpoint

26 Absolute Element Format 2.4. Bank Load Table Format The bank load table (BLT), actually the preliminary bank descriptor table, format is as follows: BDI type pref. block count sector address of bank s main segment ACWs SLR lower, BDR lower limit Table 2 1 shows the bank type associated with each bit of the type field, and what option to use on the IBANK or DBANK directive to create that kind of bank. Table 2 1. Mapping of Bits in Type Field to Bank Types Bit Bank Type Option on IBANK or DBANK Directive 0 Bank is dynamic. D 1 Bank is a D-bank. DBANK directive 2 Write protect set for bank. R Bank is a guaranteed entry bank. Bank is an S-option shared bank. Bank requires test-and-set queuing. Bank requires common D-bank contingencies. Allow this bank to process program bank contingencies. Start bank of absolute word boundary. The preference field (bits 9 through 11) is defined as follows: 4 No storage preference; default value 5 Requires extended mode There is one BLT entry for each bank in the program. Entries are ordered by ascending BDI beginning with BDI 4. For V-option banks (assign addresses but strip code), the block count is 0. The Block count is the number of 512-word blocks or 64-word blocks (if TYPE BLOCKSIZE64 was specified) in the bank. G S Q H A T

27 Absolute Element Format The last entry in the BLT is followed by the common bank list (if it exists) in the same sector, if room is left. Common Bank List Format. Each word in the common bank list format is as follows: first BDI second BDI third BDI This table contains the BDI for the Exec BDT of all common banks referenced within the program. BDIs of common banks specified for initial basing will be included within this list. Bits 0 11 of word 6 of the program file absolute element table contains the number of third-word values contained in this list. This table immediately follows the bank load table, in the absolute element

28 Absolute Element Format 2.5. Absolute Element Text and Access Control Word Formats The following section consists mainly of figures depicting the absolute element text and ACW formats. An example of ACWs in an absolute element and in segment load table entry formats is also included. Absolute Element Text Formats The absolute element text formats are shown in Figure 2 1 through Figure 2 4. Figure 2 1. Example of Overlay Segments That Span Banks

29 Absolute Element Format Figure 2 2. Example of Overlay Segments That Do Not Span Banks Figure 2 3. Main Segments in Non-initially Loaded Dynamic Banks

30 Absolute Element Format Figure 2 4. Main Segments in Initially Loaded Dynamic and Static Banks The only case in which ACWs for a segment spanning banks are not packed within any ACW buffer is when the ACWs are for the main segment of a non-initially dynamic bank. That is, the first ACW for a non-initially loaded dynamic banks main segment will always start on a sector boundary, as will its first text word

31 Absolute Element Format ACW Formats The normal ACW format is as follows. For the first ACW, the text is obtained from the following sector. Subsequent normal ACWs will obtain more text at the end of the text loaded by the previous ACW. Normal ACW number of words to load program start address for load The zero-fill ACW is used to zero-fill areas of storage into which no text is initially loaded. Each bank s main segment ACWs contain a zero-fill ACW to fill storage with zeros from the end of the main segment to the end of the last storage block assigned to that bank. Zero-Fill ACW 1 0 number of words to zero-fill program start address for fill The following ACW is an end-of-load (EOL) sentinel. It marks the end of the set of normal and zero-fill ACWs for each segment part within a bank. EOL Sentinel The following ACW is for the relocation bits for an RSEG and immediately follows the EOL sentinel for the actual RSEG text ACWs. RSEG Relocation Bits ACW number of relocation words The following ACW is an NOP ACW. It is recognized and bypassed by the Exec. NOP ACW The following ACW is an NOP common block ACW. Bits contain the BDI of the bank into which common block text is to be loaded. The ACWs immediately following the NOP common block ACW specify the locations where the common block text is loaded within the indicated bank. An EOL sentinel follows the last ACW for the common block text load

32 Absolute Element Format NOP Common Block ACW 0 1 BDI Example of ACWs in an Absolute Element Consider the hypothetical situation depicted in Example 2 1. Example 2 1. ACWs in an Absolute Element The sentinel shows: The end of the ACWs for the I-bank (or D-bank) within a sector The end of the ACWs if a sector is only partially filled (the rest of the sector would also be filled with the sentinel) The last sector of the ACWs is completely filled (a sector of sentinels follows it)

33 Absolute Element Format Segment Load Table Entry Formats The SLT has two formats: one for bank-implied collections and one for bank-named collections. The The SLT format for bank-implied collections is as follows: 00 A type 0 forward link to active segment 01 last I-bank address first I-bank address 02 last D-bank address first D-bank address 03 0 sector address of first load control group Word 00 A type Bit 0 set if segment is not loaded. 000 Main segment for bank-implied SLT format 010 Dynamic segment ( C ) 027 Relocatable segment ( R ) 024 Overlay segment ( O ) If type = 0 in the first SLT entry, the table only contains 4-word entries as previously formatted. The SLT format for bank-named collections is as follows 00 A type 0 forward link to active segment 01 last I-bank address first I-bank address 02 BDI 0 extension index 03 0 sector address of first load control group Word 00 A type Bit 0 is set if segment is not loaded. 022 Main segment for bank-named SLT format ( M ) 011 Dynamic segment ( D ) 027 Relocatable segment ( R ) 024 Overlay segment ( O )

34 Absolute Element Format BDI BDI value for bank into which segment part is loaded. The forward link to the active segment is the address for the next SLT entry of a loaded segment. That is, all loaded segments are chained together by this link. All segments are chained off the main segment. Though the main segment is always first, the rest of the segments are chained in an arbitrary manner. The half-words used for the forward links to the active segments are used by the Exec. The sector address of the first load control group points to the first group of ACWs. This sector address also is used only by the Exec. Bank-named SLT formats can contain extension entries. An extension entry is necessary when a segment spans banks. When word 2 (bits 18 35) of the SLT is nonzero, it contains a link to the next SLT extension for the segment. The extension index is the program address of the word immediately preceding the first word of the extension entry. Extension Entry Index last bank address first bank address BDI 0 extension index Each 4-word entry and its extensions are linked in order of ascending BDI value. The SLT 4-word entry for the main segment never contains an extension index, because no extension entries are built for the main segment. For RSEG SLT entries, the format is the same in both the bank-implied and bank-named SLT. RSEG Entry 00 A forward link to active segment 01 last RSEG address 0 03 BDI 0 number of relocation words 03 0 sector address of first load control group

35 Absolute Element Format 2.6. Collector-Generated Tables The following tables exist in absolute elements and are accessible to the user via the Collector-defined tags: ENTRY$ first address of the entry-point table XREF$ first address of the external reference table COMMN$ first address of the common block table If these tables do not exist, the values of these tags are zero. These tables contain 3-word entries, as described below. The COMMN$, ENTRY$, and XREF$ tables have a 1-word header formatted as follows: ENTRY$ Entry-Point Table 0 number of entries The entry-point table contains 3-word entries describing only those entry points specified on the Collector DEF directive number of entries entry-point name 03 value (absolute program address) If the entry point is in a segment designated for indirect loading, bits 0 17 of word 03 contain the address of the entry for the entry point in the indirect load table, and bits of word 03 contain the absolute program address of the entry point XREF$ External Reference Table The external reference table consists of 3-word entries describing those references named on the Collector REF directive. If any of these references is also an entry point, no entry is built in XREF$ for that reference number of entries external reference name 03 ER ERR$ The external reference in the absolute text is assigned the address of the third word in XREF$. Therefore, if a jump has been made to the external reference, an ER ERR$ is done. This can be used for testing and debugging program modules

36 Absolute Element Format COMMN$ Common Block Table When the REF or DEF directives are present, the common block table is included in the absolute. The common block table contains 3-word entries number of entries common block name (BLANK$COMMON for blank common) 03 length of common block address of common block S$NAP$ Table Each snapshot dump requested by a SNAP directive causes an entry to be made in the S$NAP$ table. This table is placed at entry point S$NAP$ in element SNAP$. The instruction for the SNAP is replaced by SLJ SNAP$$, with the snap number in the a-field of the instruction. 00 SNAP$ control word 01 frequency desired (from SNAP data image) 02 replaced instruction dump limit (from SNAP data image) 03 actual frequency number number of dumps taken Indirect Load Table Each reference made by a segment to an entry point in any I-banks of segments that are designated for indirect loading causes an entry in the indirect load table: 00 SLJ A 02 SLJ B 03 actual entry-point program address Word 00 A is one of the following entries: IDJ$ index to segment load table (SLT$) entry defining this segment Entry to indirect load routine for all jump commands except SLJ when zero-fill is required on load, and program does not contain DSEGs

37 Absolute Element Format Word 01 B IDJD$ IDJA$ Entry to indirect load routine for all jump commands except SLJ when zero-fill is required on load, and program does contain DSEGs. Entry to indirect load routine for all jump commands except SLJ when zero-fill is not required on load, and program does not contain DSEGs. IDJAD$ Entry to indirect load routine for all jump commands except SLJ when zero-fill is not required on load, and program does contain DSEGs. is one of the following entries: IDSLJ$ Entry to indirect load routine for SLJ commands when zero-fill is required on load, and program does not contain DSEGs. IDSJD$ ISLJA$ Entry to indirect load routine for SLJ commands when zero-fill is required on load, and program does contain DSEGs. Entry to indirect load routine for SLJ commands when zero-fill is not required on load, and program does not contain DSEGs. ISJAD$ Entry to indirect load routine for SLJ commands when zero-fill is not required on load, and program does contain DSEGs

38 Absolute Element Format 2.7. Relocatable Segments A relocatable segment allows the location of the RSEG within the program to be determined dynamically by the program during execution rather than at collection. Each relocatable segment is relocated relative to zero by the Collector. The instructions and data for all elements in an RSEG are collected together and assigned continuous addresses with odd location counters following even location counters. The relocation of an RSEG is done after the RSEG is loaded by adding the starting address of the RSEG to the right and/or left half of each word as marked by the Collector. The half-words are not marked for load time relocation if the relocatable binary code specifies subtraction of a location counter or an undefined symbol that is not absolute. The segment load table is marked to designate relocatable segments. A table is produced by the Collector that indicates which half-words are to be relocated. Bit 0 of the first word of the table is 1 if the left half of word 01 of the segment is to be relocated. Bit 1 is 1 to relocate the right half of word 01 of the segment. Bit 2 is 1 to relocate the left half of word 02 of the segment, and bit 3 is 1 to relocate the right half of word 02 of the segment. Therefore, each word in the relocation bit table represents 18 words in the relocatable segment

39 Absolute Element Format 2.8. Diagnostic Table Formats The diagnostic table format is as follows: The pointer table is organized by ascending segment index (found in the bank and segment index value table in the Collector listing). All index addresses are relative to the start of the table. The number of banks for segment index n indicates the number of extension entries for this piece of diagnostic text. This number reflects the number of banks this segment spans. The index address is relative to the start of the table for both extension and static diagnostic information. The start of the pointer entries and the length of the pointer entries are found in the header table. If the pointer entries do not fill one sector, the extension entries begin on the next sector boundary

40 Absolute Element Format Segment Name Table The SNT contains segment name entries and extension entries. Segment Name Entry segment name 12 Fieldata characters 02 address of extension relative index BDI 03 relative sector address of load control group for text Extension Entry 00 address of extension relative index BDI 01 relative sector address of load control group for text The relative index points to the word in the load control group where this segment description begins Element Name Table The ENT format is as follows: element name 12 Fieldata characters 03 time and date relocatable element was created (reversed TDATE$ format) The ENT is created in alphabetical order Bank Name Table Each bank has an entry in the BNT. These entries are in ascending BDI order, and correspond one-to-one with the BLT entries. bank name 12 Fieldata characters 03 link address of first LC entry number of LC entries The field link address of first LC entry is a word offset from the start of the LCT that describes the location counter

41 Absolute Element Format Location Counter Table The LCT format is as follows: 00 segment index in SNT element index in SNT 01 D L C X R I 0 location counter number BDI 02 location counter word length location counter program start address Word 00 segment index in SNT The word offset from the beginning of the SNT of the segment containing this location counter. element index in ENT Word 01 The word offset from the beginning of the ENT of the element containing this location counter. D L C X R I Set if LC is in a D-bank Set if LC is from an element in the file SYS$RLIB$ Set if LC text is for a common block Set if LC is the actual common block Set if LC text is in an RSEG Set if LC contains INFO-8 If C is set, bits of word 02 contain an index to the LCT entry for the final LC assigned to the common block in the absolute element. If X is set, the LC number is 0. It is a logical conflict for both C and X to be set in the same entry Entry-Point Name Table The EPNT format is as follows: 00 entry-point name Fieldata characters 03 LC entry link address relative address The field LC entry link address is the word offset from the start of the LCT that describes the location counter. Relative address is the address of the entry point relative to the start of the location counter. The EPNT is created in alphabetical order

42 Absolute Element Format Absolute Value Definition Table The ABSV format is as follows: externalized name 12 Fieldata characters 02 absolute value The ABSV is created in alphabetical order CAP-Element Format A CAP element is created by the conflict avoidance processor (CAP). A CAP element has a format similar to that of an absolute element, with two important differences CAP-Element Header Table In the header table the sentinel (offset 00) is This is done so that a CAP element can be identified CAP-Element Bank Load Table The CAP element uses a different BLT than an absolute element. The BLT CAP-element format is as follows: 00 placement factor 01 frequency number sector address of bank s main segment ACWs type pref. block count SLR lower, BDR lower limit Placement and Frequency number are no longer used and are ignored during loading of the absolute element. See 2.4 for the BLT format

43 Section 3 Attributed Character Data Format Attributed character data (ACD) items are data items containing character data that can be attributed. The ACD modifies characters. ACD is currently defined as character set 077. The ACD format specified in this section consists of three parts, the concatenation of which must fit precisely within an integral number of words. The third part of the text format ensures this because it is a number of padding bytes that fill out the byte stream to a word boundary. The size of the byte stream, in words, is specified in the system data format (SDF) control word. The three parts of the ACD are Attributes (optional) Text (required) Padding bytes (as needed) Note: While the entire ACD must start and end on word boundaries, the three parts need not do so Attributes Part The attributes part specifies all the attributes of all characters in the character bytes part of the text part. If the entire text has the default attributes (ASCII character set with no special attributes), there does not need to be an attributes part. In this case or in the case where the entire text has the same non-default attribute (such as an entire line of font 2, ASCII text), then the string consists of a single sub-string. For text strings where the attribute changes once in the text, the attributes part consists of two sub-strings. Any number of sub-strings can be handled by the attributes part. The first character of each sub-string is called an attribute change point. There is a pointer to each attribute change point that serves as an index into the text and gives the location of the first character of a sub-string. In the following discussion, this pointer is referred to as the index

44 Attributed Character Data Format The attributes part of the ACD consists of a sub-string description for each sub-string and two necessary control bytes at the beginning of the entire attributes part. The following is the attributes part format: 1st byte nd byte byte count 2 3rd byte and higher 1 or more sub-string descriptions Byte count 2 is the number of bytes remaining in the attributes part. As for the text part, the size of the attributes part (in bytes) is byte count 2 plus Sub-string Description Each sub-string of the text may have one or more attributes that are different from the previous sub-string (or the default when considering the first sub-string). Each attribute change is described by an attribute item. Each sub-string description has the following format: 1st byte byte count 3 2nd byte index 3rd byte and higher attribute items Byte count 3 is the number of bytes remaining in the sub-string description. In this case, byte count 3 is equal to one (for the index byte) plus the sum of the sizes of all attribute items (in bytes). The size of the sub-string description is byte count 3 plus 1. The index points to the first character byte of the sub-string. The attribute items allowed are described in the following text Attribute Items There are six supported attribute items. Each of the six is either a 1- or 2-byte string. In each case, the first byte is the key to the meaning of the attribute item. In the case where the second byte is needed, it is a qualification. The attribute items (identified by the octal value of the first byte) are described as follows: character set 0345 The character set of the text changes to the encoding specified in the second byte as follows: 01 - ASCII JIS-16 Each ASCII character consists of one byte, and each kanji character consists of two bytes

45 Attributed Character Data Format normal font 0306 alternate font 0307 The font to be used is the normal font. The font to be used is the secondary font. reset all attributes 0120 specified font 0340 All of the attributes are to be reset to their defaults. The font to be used is the font specified in the next byte. The next byte must contain an allowable font number (currently 0, 1, 2, or 3). See note 1. horizontal spacing 0343 character size 0342 Notes: The horizontal spacing (center to center) of the text changes to the distance contained in the second byte. A value of zero means device-dependent default. See note 2 concerning units of measure. The size of the graphical characters displayed changes to the size (in decipoints) contained in the second byte (height) and the third byte (width). The values of zero mean device-dependent defaults. See note 2 concerning units of measure. 1. The references to font here are equivalent to translate table for laser printers. 2. The default unit is device dependent (usually, single displayable character position ). Many combinations of attributes are possible. Individual devices may limit which attributes they process

46 Attributed Character Data Format 3.2. Text Part The text part is the character data. It does not contain any attribute information. It does contain some control information (first two bytes), but the remainder of this part is character data. The format of the text part is as follows: 1st byte nd byte byte count 1 3rd byte 4th byte 1st byte of text 2nd byte of text Byte count 1 is the number of bytes of text that follow the 1st byte. The total size of the text part would be equal to byte count 1 plus 2. The string This is red and blue. would look like this: (0300)(21)This is red and blue. ASCII characters are shown as is, one character per byte. Each of the first bytes (containing octal and decimal numbers respectively) are shown enclosed by parentheses Padding Bytes When the attributes part and text part have been created, a sufficient number of padding bytes must be added to ensure that the image ends on a word boundary. Each padding byte has the value 0237.Padding bytes can also be used before the attribute part or before the text part. This might be done if performance considerations would dictate the starting character bytes on a word boundary

47 Attributed Character Data Format 3.4. Encoding Example Figure 3 1 is an example of the ACD format. Figure 3 1. Attributed Character Data Format

48 Attributed Character Data Format 3.5. Processing ACD ACD is created by the SLIB symbolic write services and read by the symbolic read services. See the SLIB Programming Reference Manual. ACD is created by the SYSLIB symbolic access routines (SAR) WRITE, ATREAD, and COM functions and read by the SAR READ, ATREAD, and COM functions. See the SYSLIB Programming Reference Manual

49 Section 4 DIAG$ File Format 4.1. DIAG$ File Format for Collector-Generated Absolutes The DIAG$ file format is internal to the OS 2200 Exec system and is subject to change without notice. The header block is normally located at sector 1000 (decimal). However, if diagnostic dumps have been used, then sector 0 word 05 contains the sector number. Note: If bit 1 in word 7 of the absolute header table is set (Collector TYPE NPEDIAG directive for mixed mode absolutes), the operating system will create a dump as though it came from an Object Module-Based Program." (See Section 4.2.) The postmortem dump (PMD) header format is as follows excluding those collected with the TYPE NPEDIAG directive: 00 PMD$$$ internal file name of program file containing the absolute element 03 program header table address 04 TAL forced dump indicator 05 (reserved) 06 program condition word ASA address 07 PCTLBDI number of banks dumped 010 BDI size address in DIAG$ file relative to header..... n BDI size address in DIAG$ file relative to header

50 DIAG$ File Format Word 00 Bits 0 35 PMD$$$ This word contains a Fieldata sentinel for use in verifying that the table is present, and determining which format is in use. Word 01 Word 02 Bits 0 35 internal filename of program file Word 03 Bits 0 35 These two words contain the Fieldata internal file name of the program file containing the absolute element. These two words are initialized from the cell EU in the program control table (PCT). program header table address Word 04 Bits 0 11 This word contains the relative sector address of the program header table contained in the file indicated in words 01 and 02. This word is initialized from the cell EX in the PCT. This cell contains information relating to the last activity to terminate. type and level (TAL) Bits Switching level forced dump indicator The W option on statement was set. This option specifies that only user programs and processors in the system files that encounter an error are written to the diagnostic file. For more information on statement, refer to the ECL End Use and Programming Reference Manual

51 DIAG$ File Format Bits ASA address Word 05 Bits 0 35 PCT relative address of the activity save area (ASA) for the last activity to terminate. (reserved) Word 06 Bits 0 35 Reserved program condition word Word 07 Bits 0 17 This word contains information pertaining to the condition of the program at the time the last activity terminated. PCTLBDI Bits LBDI of the PCT bank. number of banks dumped This cell contains the number of banks, including the PCT, that were written to the DIAG$ file. Write-protected banks and dynamic banks not loaded at the time of termination were not dumped. Word 010 Word n Bits 0 8 BDI The following cells describe the banks dumped. BDI for this bank

52 DIAG$ File Format Bits 9 17 size Bits The final size of bank: the number of 512-word blocks. If type BLOCKSIZE64 is on, then this is still the number of 512-word blocks needed to hold the bank. For single-bank programs collected with an implied collection, a zero length may appear for the missing I- or D-bank. address in DIAG$ file relative to header This cell contains the sector address, relative to the PMD header block, for the start of this bank area in the DIAG$ file DIAG$ File Format for Object Modules, ZOOMs, and Absolutes with the TYPE NPEDIAG Directive Following the execution of an object module or zero overhead object module (ZOOM), the DIAG$ file may contain one or more entries describing contingency conditions, including the normal termination contingencies for return control stack (RCS) underflow or ER EXIT$. Each time a contingency occurs that receives an extended mode standard action, an entry is made in the DIAG$ file. Following the execution of an absolute collected with the TYPE NPEDIAG directive, the DIAG$ file may contain two or more entries describing an activity that terminated abnormally, that is, it did not terminate by means of an ER-EXIT$ or RCS underflow. If all activities terminated normally, no data will have been written to the DIAG$ file. Also, if bit 1 in word 7 of the absolute header table is set (Collector TYPE NPEDIAG directive for mixed mode absolutes), the operating system will create a dump as though it came from an "Object Module-Based Program." When any activity of such an absolute terminates abnormally (restricted to activity abnormal termination), only the activity local banks are written to the DIAG$ file. The last activity to terminate will write all program local banks to the DIAG$ file. (Refer to the Executive Requests PRM section for additional information describing the operating system action concerning this absolute indicator.) File Header Format The diagnostic file header controls access and the current state (length, version, and so on) of a diagnostic file. Only one file header exists per diagnostic file and begins on a sector boundary. The format of the DIAG$ file header is as follows: 01 validation constant 02 version (reserved) 03 first activity entry addr

53 DIAG$ File Format 04 last activity entry addr 05 next available space 06 sectors remaining 07 file hdr len pgm hdr len 08 pgm start time 010 pgm start time in 00 microsecond units Word 00 Bits 0 35 validation constant: ASCII CHARACTERS ASCII *df* Word 01 Bits 0 17 version: UNSIGNED INTEGER This manual illustrates version 3. Bits (reserved): LOGICAL Reserved Word 02 Bits 0 35 first activity entry addr: UNSIGNED INTEGER The sector file relative address of the first activity entry. Word 03 Bits 0 35 last activity entry addr: UNSIGNED INTEGER The sector file relative address of the last activity entry written

54 DIAG$ File Format Word 04 Bits 0 35 next available space: UNSIGNED INTEGER Word 05 Bits 0 35 The sector file relative address of the next available space in the diagnostic file. sectors remaining: UNSIGNED INTEGER Word 06 Bits 0 17 Number of sectors remaining in the file. If negative, file expansion failed, so no more diagnostics will be taken. file hdr len: UNSIGNED INTEGER RANGE (0 TO ) Bits Size, in sectors, of the file header area. Definition saved for editing routines. The value placed in this field is defined as file hdr len value. pgm hdr len: UNSIGNED INTEGER RANGE (0 TO ) Word 07 Bits 0 35 Size, in sectors, of the program common area. Definition saved for editing routines. The value placed in this field is defined as pgm hdr len value. pgm start time: UNSIGNED INTEGER Word 010 Bits 0 35 The time the program was started. pgm start time 200 microsecond units: UNSIGNSED INTEGER The time that the program was started, in 200 microsecond units since midnight of the day on which the program was started

55 DIAG$ File Format Program Header The program header contains information for the program that is common to all of the program s activities. Only one program header exists per diagnostic file and starts on a sector boundary. The program header format is as follows: 00 runid 01 runid (reserved) 02 activity hdr len bank hdr len pgm file directory id pgm filename 011 (reserved) pgm abs file cycle pgm element name pgm version name orig time stamp exec lvl 025 access (reserved) 026 r bit gate lp 027 link fault gate lp 030 entry pt resol gate lp 031 new user to ss gate lp 032 pgm name 033 max run time priority pgm type file index * * * * pgm options 035 (reserved) pgm file number 036 errant subq chain pointer rtps number 037 * * * control flag * error flag

56 DIAG$ File Format 040 * * * wait count 041 reentrant bcp va 042 vindex entry number * * * 043 printq device 044 pgm addr dwtime stamp 047 zoom pgm entry point 050 Latent parameter 051 als initial size als max size 052 zoom blt (reserved) (reserved) 060 tip type (reserved) hvtip lib bank 061 hvtip srs 062 hvtip icp lib bank (reserved) Word 00 Bits 0 35 runid Word 01 Bits 0 17 runid: ASCII CHARACTERS Bits For batch and demand, this is the unique identification of the run. It should be used in all messages and log entries that need to be identified by run. (reserved): LOGICAL Reserved

57 DIAG$ File Format Word 02 Bits 0 17 activity hdr len: UNSIGNED INTEGER Bits Size, in sectors, of the activity header. Definition saved for editing routines. The value placed in this field is defined as activity hdr len value. bank hdr len: UNSIGNED INTEGER Size, in sectors, of the bank header. Definition saved for editing routines. The value placed in this field is defined as bank hdr len value. Word 03 Word 04 Bits 0 35 pgm file directory id: LOGICAL This is the directory name of the program file from which the last program was loaded. Zero, if none. Word 05 Word 010 Bits 0 35 pgm filename: LOGICAL Word 011 Bit 0 Bits 1 17 Bits This is the file name of the program file from which the last program was loaded. At the present time, this is usually the qualifier and file name in FIELDATA. When set, indicates that the program represented in this file is an absolute that was collected with the TYPE NPEDIAG directive. When clear, this entry is for an object module. reserved pgm abs file cycle: LOGICAL This is the absolute file cycle of the program file from which the last program was loaded

58 DIAG$ File Format Word 012 Word 014 Bits 0 35 pgm element name: ASCII CHARACTERS This is the name of the program element from which the last program load was done. Word 015 Word 017 Bits 0 35 pgm version name: ASCII CHARACTERS This is the version name for the program element from which the last program load was done. Word 020 Word 021 Bits 0 35 orig time stamp: LOGICAL Reserved for the time stamp from the creation of the program. This field is currently not always zero. Word 022 Word 024 Bits 0 35 exec lvl: ASCII CHARACTERS Word 025 Bits 0 17 The level of the Exec under which the program is executing. access: UNSIGNED INTEGER RANGE (0 TO ) Bits The domain and ring numbers assigned to this subsystem. (reserved): LOGICAL Reserved

59 DIAG$ File Format Word 026 Bits 0 35 r bit gate lp: LOGICAL Word 027 Bits 0 35 Latent parameter of the gate for R-bit interrupts. This is used to load an object module from the program file when a reference to the bank receives a residency bit interrupt and the bank belongs to the Linking System. link fault gate lp: LOGICAL Word 030 Bits 0 35 Latent parameter of the gate for when a link fault occurs. The Linking System must be called to resolve the external reference represented by the link vector entry. entry pt resol gate lp: LOGICAL Word 031 Bits 0 35 Latent parameter of the gate for entry point resolution. This is used to resolve an entry point after the new subsystem has been created. new user to ss gate lp: LOGICAL Word 032 Bits 0 35 Latent parameter of the gate when the subsystem is already created at a higher address tree level than the user is executing at. This occurs when a run-level activity does a subsystem transition to an application-level subsystem. The application-level subsystem is already created, so the Linking System does not need to load any banks. The Linking System creates only the necessary gates. pgm name: FIELDATA CHARACTERS This is the transaction program name taken directly from the validation table (VALTAB). It is left-justified and space-filled

60 DIAG$ File Format Word 033 Bits 0 11 max run time: UNSIGNED INTEGER Bits This is the maximum run time of this transaction (in minutes for an online-batch program and in seconds for a transaction program). priority: FIELDATA CHARACTERS Bits This is the run priority for this transaction program. It must be within the range A to Z. pgm type: STATUS Bits This is the program type for this transaction. The following values describe the program types. Possible entries for this field are given in the following table. Value 01 This is a self-destructive program. 02 This is a self-initializing program. 03 This is a reentrant program. 04 This is an online-batch program. 05 This is a high-volume program. file index: STATUS Program Types This field indicates which file the program should be loaded from. Values 0 2 are for transactions that have been run through SUPUR, and values3 5 are for transactions that have not been run through SUPUR, which is not allowed for ZOOMs. The value must be 0 for High-Volume Transaction Processing (HVTIP) transactions. The following values describe the file index. Possible entries for this field are given in the following table. Value File Index 00 This program is in the main library cycle. 01 This program is in the alternate library cycle. 02 This program is in the test library cycle

61 DIAG$ File Format Bits max nbr copies: UNSIGNED INTEGER Word 034 Bit 0 Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 This is the maximum number of copies of this transaction allowed to be in memory concurrently. sticking allowed: CONDITION This flag corresponds to the I status option. If set and sticking is turned on, the transaction may be stuck in main storage. production uses mcb: CONDITION This flag corresponds to the J status option. If set, the production version of the transaction program uses the Message Control Bank (MCB). If not set, it uses COMPOOL. bt loading allowed: CONDITION This flag corresponds to the K status option. If set, block transfer loading is allowed. test uses mcb: CONDITION This flag corresponds to the L status option. If set, the test version of the transaction program uses the MCB. If not set, it uses COMPOOL. new main allowed: CONDITION This flag corresponds to the M status option. If set, a new main SUBQ is created if the current main SUBQ is marked in error. Transaction scheduling then takes place from the new main SUBQ. n status option: CONDITION This flag corresponds to the N status option. The N status option is reserved for system use and is currently unused

62 DIAG$ File Format Bits 6 11 o thru t status options: CONDITION Bits Status options O through T are user defined. wait queue length: UNSIGNED INTEGER Bits These bits contain the desired wait-queue length expressed as a multiple of the number of active program copies. The default is zero. nbr pct blocks: UNSIGNED INTEGER Bits These bits contain the number of 512-word PCT blocks minus 1. The default is zero. pgm options: UNSIGNED INTEGER

63 DIAG$ File Format The meanings of the program option bits are given in the following table. Bit Meaning 18 File control superstructure (FCSS) change function (CG) allowed. 19 Not used. 20 Inhibit common bank dumps when dumping to a printer (only meaningful when used with Z option). 21 Permit TIP logging for this program. 22 Allow maximum number of print pages to be exceeded. 23 Program must schedule another program or send an output response before terminating. 24 Test mode. 25 Program is allowed to manipulate its status list of the operating program (SLOP) table entry. 26 Allow manipulation of KONS security directory Program is allowed to release logical COMPOOL blocks via the CRELOG primitive call. Program is allowed to write into protected KONS area. Program is allowed to read this area with or without option. 29 Create a diagdump file upon abnormal program termination. 30 FCSS release function (RE) allowed. FCREG file registration/deregistration allowed. 31 Allow physical COMPOOL requests. 32 Not presently in use (used for debugging when STPAUL on). 33 Program is allowed to access protected system files. 34 Training mode. 35 Program will produce a dump upon abnormal termination. Word 035 Bits 0 17 (reserved): LOGICAL Reserved. Bits pgm file number: UNSIGNED INTEGER This is the TIP program file number. It is present for SUPUR program files only

64 DIAG$ File Format Word 036 Bits 0 17 errant subq chain pointer: POINTER Bits This is the relative address of the next errant SUBQ in an errant SUBQ chain or 0 if the end of the chain. This is a global cell. The main SUBQ must be locked when altering or searching an errant SUBQ chain. rtps number: UNSIGNED INTEGER Word 037 Bits 0 5 This is the index into the resident transaction program system (RTPS) program name table for this SUBQ. (0 = not RTPS program.) deact rtps pgm copies: UNSIGNED INTEGER Bits 6 11 This is the number of deactivated RTPS program copies. nbr active copies: UNSIGNED INTEGER Bits This is the number of active copies of this transaction. In a main SUBQ linked to one or more errant SUBQs, SUBACT represents the cumulative total of active program copies for all the linked SUBQs. In an errant SUBQ, SUBACT reflects only the number of active copies for that SUBQ. SUBACT is a global cell that is updated only when the main SUBQ is locked. pgm format indicator: STATUS This is the program indicator. The following values describe the program formats. Possible entries for this field are given in the following table. Value Program Formats 00 Absolute standard load format 01 Absolute fast load format 02 ZOOM standard load format 03 ZOOM fast load format 04 ZOOM HVTIP format

65 DIAG$ File Format Bits control flag: STATUS This is the control flag for the transaction. It indicates the current or pending SUBQ activity. The following values describe the control flags. Possible entries for this field are given in the following table. Value Control Flags 00 No activity is occurring, and the SUBQ is eligible for loading another program copy. 01 The SUBQ is being constructed by TRFUNC. 02 The SUBQ is on the PSH/TIPMEM initial load chain. 03 The program load is in progress. 04 The program is waiting for a reentrant bank load. 05 All TIP memory banks for this transaction have been acquired. 06 The SUBQ is temporarily held in its current state. One usage of SQHOLD is to prevent the SUBQ from being released between the time it is unlocked and relocked. Bits nbr copies stuck: UNSIGNED INTEGER Bits The number of copies of this transaction that are stuck. error flag: STATUS This field may be set to indicate that no more schedule requests are to be processed through this SUBQ. After active copies terminate, the SUBQ is to be rebuilt to process any schedule requests on the wait-queue. The following values describe the error flags. Possible entries for this field are given in the following table. Value Error Flags 00 The SUBQ is not in error. 01 The SUBQ is in error The program needs more bank control packets (BCP) in a TIP memory group to load. The program needs more banks in a TIP memory group than that group can hold

66 DIAG$ File Format Word 040 Bits 0 5 drain stuck copies: CONDITION Bits 6 11 When this field is set, TIP will drain away stuck program copies. nbr resident copies: UNSIGNED INTEGER Bits The number of resident copies. In a main SUBQ linked to one or more errant SUBQs, SUBNRC represents the cumulative total of resident copies for all the linked SUBQs. In an errant SUBQ, SUBNRC reflects only the number of resident copies for that SUBQ. SUBNRC is a global cell that is updated only when the main SUBQ is locked. tip pgm switch level: UNSIGNED INTEGER Bits The TIP program initial switching level. wait count: UNSIGNED INTEGER Word 041 Bits 0 35 The number of schedule packets on the wait-q. reentrant bcp va: POINTER The virtual address in L,BDI offset format of the reentrant BCP. This field contains zero when there is no reentrant bank attached to the SUBQ

67 DIAG$ File Format Word 042 Bits 0 17 vindex entry number: UNSIGNED INTEGER Bits This is the VALTAB index (VINDEX) entry number for this transaction. It must be multiplied by VXLEN to get offset in VINDEX bank to point at either real VINDEX or test VINDEX entry. da req fail count: UNSIGNED INTEGER Bits For TIP memory, this is the group number in which a request for allocation of a bank failed. For standard memory, this is the count of dynamic allocator (DA) requests that failed. tip memory required: UNSIGNED INTEGER Bits This flag is set if TIP memory is required. This cell is also used as a pass count for TIPMEM. If TIPMEM is unable to load the transaction, it bumps this cell before processing the next SUBQ. TIPMEM resets this cell to 1 when loading is successful. subq flags The following bits describe the SUBQ flags. Possible entries for this field are given in the following table. Bit SUBQ Flags Unused 34 Alternate load file available flag 35 Transaction code in use flag Word 043 Bits 0 35 printq device: FIELDATA CHARACTERS The default print queue that transactions for this SUBQ will use. It is derived from the VALTAB field VTBPRQ. It contains Fieldata spaces if no print queue was explicitly defined

68 DIAG$ File Format Word 044 Bits 0 35 pgm addr: LOGICAL The file-relative sector address of the beginning of the transaction program within the TIP program file. For programs in standard load format, the entire element is present (including control information), whether it is an absolute or a ZOOM element. For programs in fast load format, only the bank text is present. In either case, this is the start of the program. It must be converted to a word address by multiplying by 28 (words per sector) to be useful to the Exec for reading from TIP files via the TIP file control routine COMWRD. Word 045 Word 046 Bits 0 35 dwtime stamp: LOGICAL Word 047 Bits 0 35 The time and date when the ZOOM was created. It is stored in double-word, LINK-generated (not DWTIME$) format as the number of nanoseconds since midnight, January 1, 1900, with 1900 not counted as a leap year. zoom pgm entry point: POINTER Word 050 Bits 0 35 The program entry point, in L,BDI,offset format, where execution begins. latent parameter: UNSIGNED INTEGER Word 051 Bits 0 17 The latent parameter (R0 value). It is currently the virtual address of the link vector bank. als initial size: UNSIGNED INTEGER The activity-local stack (ALS) initial size. This is taken from LCPALS

69 DIAG$ File Format Bits als max size: UNSIGNED INTEGER Word 052 Bits 0 35 The maximum size of the activity-local stack. zoom blt: POINTER The virtual address, in L,BDI,offset format, of the ZOOM bank load table. Word 053 Word 054 Bits 0 35 (reserved): LOGICAL TIP memory group numbers for the Exec-created banks for this program. Word 055 Word 057 Bits 0 35 (reserved): LOGICAL Word 060 Bits 0 11 Unused. These words are present to make version 2 (or higher) more compatible with versions 0 and 1 of DIAG$ files. DIAG$ file versions 0 and 1 contained 22-word TIP SUBQs. Version 2 and above contain a 19-word TIP SUBQ information packet plus padding. This keeps following fields in the same relative position for all DIAG$ file versions. tip type: LOGICAL Bits This field may take on the following values: = not TIP; = batch or demand connect; = transaction program; = online batch, not connected; = online batch, connected. (reserved): LOGICAL Reserved, must be zero

70 DIAG$ File Format Bits hvtip lib bank: LOGICAL Word 061 Bits 0 35 The library and bank number for HVTIP transactions. Zero if non-hvtip transactions. hvtip srs: LOGICAL Word 062 Bits 0 17 The virtual address of HVTIP software return stack. Zero if non-hvtip transactions. hvtip icp lib bank: LOGICAL Bits The library and bank number for the initial control program (ICP). Zero if non-hvtip transactions. (reserved): LOGICAL Reserved, must be zero. Program Header (overlay 1) 00 transaction id 01 transaction id (reserved) Word 00 Word 01 Bit 17 transaction id: ASCII CHARACTERS Bits For TIP, the first character is an asterisk (*) followed by the 5-character ID made up of the application number and sequence number, to give a unique ID. (reserved)

71 DIAG$ File Format Activity Entry The activity entry contains information unique to each of the program activities. This includes information unique to that activity and the current contingency (activity entry hdr) and information on each of that activity s banks (bank entry). Multiple activity entries can exist in a diagnostic file. These may be entries for different activities or multiple entries for the same activity at different points in its execution. All activity entries start on a sector boundary. For absolutes collected with the TYPE NPEDIAG directive, all but the last entry written will contain only activity local banks. The last entry written, as pointed to by word 3 of the File Header (see 4.2.1), will contain only program local banks. Activity Entry Header The activity entry header contains activity entry control information and other information that is unique to this activity at this point in its execution. The format of the activity entry header is as follows: 00 prev activity entry addr 01 next activity entry addr 02 current activity entry len time stamp 05 activity id (reserved) act id wd0 h1 06 act id wd0 h2 act id wd1 h1 07 act id wd1 h2 return control stack ptr 010 return control stack va 011 asa spcb va 012 jump history stack word 012 repeated 7 additional times contingency pkt

72 DIAG$ File Format Word 00 Bits 0 35 prev activity entry addr: UNSIGNED INTEGER Word 01 Bits 0 35 The sector-relative file address of the previous activity entry. Zero if the current entry is the first activity entry. next activity entry addr: UNSIGNED INTEGER Word 02 Bits 0 35 The sector-relative file address of the next activity entry. Points to the next available space if the next entry is not yet written. current activity entry len: UNSIGNED INTEGER Size, in sectors, of the current activity entry. Does not include the activity header length. Word 03 Word 04 Bits 0 35 time stamp: LOGICAL Word 05 Bits 0 5 The 2-word binary representation of the time in nanoseconds from January 1, Time when this activity entry was created. activity id: UNSIGNED INTEGER Bits 6 17 The numeric ID for this activity. The value zero indicates that this activity has no ID. An activity gains an ID only on an ER FORK$. (reserved): LOGICAL Reserved; must be zero

73 DIAG$ File Format Bits act id wd0 h1: LOGICAL The 72-bit activity identifier. H1 of activity ID word 0. Word 06 Bits 0 17 act id wd0 h2: LOGICAL The 72-bit activity identifier. H2 of activity ID word 0. Bits act id wd1 h1: LOGICAL The 72-bit activity identifier. H1 of activity ID word 1. Word 07 Bits 0 17 act id wd1 h2: LOGICAL The 72-bit activity identifier. H2 of activity ID word 1. Bits return control stack ptr: UNSIGNED INTEGER Pointer to the current entry on the RCS. Word 010 Bits 0 35 return control stack va: LOGICAL The virtual address of this activity RCS. Word 011 Bits 0 35 asa spcb va: LOGICAL The virtual address of SP3068 scientific processor control block

74 DIAG$ File Format Word 012 Bits 0 35 jump history stack: LOGICAL The contents of the jump history stack (JHS) buffer at the time of the interrupt. Word 013 Word 021 Bits 0 35 Word 012 Repeated seven additional times. Word 022 Word 0157 Bits 0 35 contingency pkt: LOGICAL Contingency packet for the contingency that caused this dump to be written. Bank Entry Header The bank entries contain information about the program-level banks and this activity s activity-level banks in the home subsystem. The bank entry header points to the actual contents of the bank. There may be multiple bank entries per activity entry. Each bank entry header and the bank text start on a sector boundary. 00 lvl bdi (reserved) 01 bank entry size 02 next bank entry ptr bank description 011 start of bank text Word 00 Bits 0 17 lvl bdi: LOGICAL The L,BDI of the bank

75 DIAG$ File Format Bits (reserved): LOGICAL Word 01 Bits 0 35 Reserved. bank entry size: UNSIGNED INTEGER Word 02 Bits 0 35 Size, in words, of the entire bank entry. This includes the bank header and text, but does not include any gaps to round to the next sector boundary. next bank entry ptr: UNSIGNED INTEGER The file-relative sector address of the next bank entry. This address is on a sector boundary. Zero if there are no more bank entries for this activity. Word 03 Word 010 Bits 0 35 bank description: LOGICAL Word 011 Bits 0 35 The bank description as returned from a CALL to INSPECT$BANK. start of bank text: UNSIGNED INTEGER The file-relative address of the start of the bank text

76 DIAG$ File Format

77 Section 5 FURPUR/PCFP File Formats 5.1. Basic File Formats Figure 5 1 illustrates the relationships of files to each other. The exact formats have been simplified for clarity. The control statements illustrated are control statements that transfer data between the indicated file types

78 FURPUR/PCFP File Formats Figure 5 1. FURPUR Control Statements Used to Alter File Formats

79 FURPUR/PCFP File Formats Figure 5 1. FURPUR Control Statements Used to Alter File Formats (cont.)

80 FURPUR/PCFP File Formats 5.2. FURPUR Tape File Format statement copies a file from mass storage to tape, or from tape to mass storage, without regard to the format of the file contents. This section describes the FURPUR tape format, which is the format of the logical file written to tape by statement. Multiple variations of the FURPUR format are described. See for a description of the revised format developed for Program-Callable FURPUR (PCFP). See for a description of the variants of the original format written by FURPUR before PCFP was developed. By default, PCFP writes the revised FURPUR format, but reads both the revised format and all variants of the original format. By setting a special compatibility option, a caller can cause PCFP to write the original variant of the FURPUR format appropriate for the type of tape being written to Revised Format This section describes the FURPUR format as it has been revised for PCFP. This format has the following changes over the original format: The revised format allows multiple tracks to be written to tape as a single block. The file descriptor indicates how many tracks are written/read with each I/O. Under the revised format, the file descriptor is always written as a single I/O block, separate from any text blocks. This allows the descriptor to be read before any of the file text. The revised format does not require reading of the initial block of the next logical file to determine if the current logical file is continued to another reel. The original format, since it often does require such look-ahead, also requires backspacing so that the tape is properly positioned at the start of the next logical file. The revised format is identical for tapes with data compression disabled and enabled, which was not true for all variants of the original FURPUR format. The revised format does retain differences between labeled and unlabeled tapes. Since the FURPUR format is revised for PCFP, compatibility between the original versions and the revised version is a concern. In the revised format, this concern is addressed as follows: PCFP and FURPUR can read all variants of the original FURPUR format. PCFP can write both the original FURPUR format and the revised format. continues to write the original FURPUR format if the output tape has data compression disabled. writes the revised format if the output tape has data compression enabled or if the D option is included

81 FURPUR/PCFP File Formats Arrangement of Data within a FURPUR Logical File The following is a layout of the data stored within a logical file written to tape with the revised FURPUR format. Each vertical line delimits a physical I/O block, which is a segment of data that is written to and can be read from the tape with a single I/O command. A tape is always positioned between blocks; it is never possible to read the same block with more than one I/O function, unless the tape is backspaced between the functions. Logical File Descriptor Regular Text Block... Regular Text Block Last Text Block EOF Mark The logical file descriptor always exists in an I/O block by itself, so that it can be read without also reading any logical file text. Each regular text block contains the same number of tracks, from one to sixteen. Each track is 1,794 words in length. The first two words contain a track header and the remaining 1,792 words contain the actual data for the track. The number of tracks in each regular text block is contained in the logical file descriptor. There can be any number of regular text blocks, including zero. The last text block differs from the regular text blocks in two ways: First, in the track header of the last track in the block, the last track indicator bit is set. Second, the last block might contain fewer tracks of text than the preceding blocks. For a logical file that contains no text, the file descriptor is followed immediately by an end-of-file (EOF) mark. If a logical file must be continued across reels, the layout at the end of the first reel varies based on the type of tape involved. In the case of unlabeled tape, the end of the first reel is laid out as follows: Regular Text Block EOF Mark File-Swap Block EOF Mark EOF Mark The last text block before the file-swap block always contains the full number of text tracks indicated in the file descriptor. As with all tracks before the last in a logical file, the last track indicator of the track immediately before the swap point is not set. For the case of labeled tape, the file-swap block and the two EOF marks following it are not written. System labels indicate that the logical file continues to another reel, so that the file-swap block is not necessary. The TLBL$ Executive request must be used to determine that a swap is necessary. The logical end of a tape is the end of the recorded data on the last reel of the tape file. For an unlabeled tape it is indicated by two consecutive EOF marks with no preceding file-swap block. For a labeled tape it is indicated by the special combination of an I/O status 01 (end-of-file) and an abnormal frame count (AFC) value of 3. Two consecutive EOF marks are not the logical end of a labeled tape unless the AFC value for the second EOF is

82 FURPUR/PCFP File Formats FURPUR File Descriptor The FURPUR file descriptor is 28 words long, formatted as follows: id pattern qualifier file name 06 f cycle 07 month day year 010 hour minute second 011 revision-id 0 equip code 012 high trk written num trks in grp Word 00 Word 01 Bits 0 35 id pattern: FIELDATA CHARACTERS This pattern identifies the logical file as FURPUR format. It always has the value COPYG in the first word and the value BLKSEQ in the second. Word 02 Word 03 Bits 0 35 qualifier: FIELDATA CHARACTERS Gives the qualifier of the file from which the logical file was copied. Word 04 Word 05 Bits 0 35 file name: FIELDATA CHARACTERS Gives the file name of the file from which the logical file was copied

83 FURPUR/PCFP File Formats Word 06 Bits 0 35 f cycle: FIELDATA CHARACTERS Word 07 Bits 0 11 Gives the absolute F-cycle of the file from which the logical file was copied. If the file that was copied was a temporary file that had no absolute F-cycle, it has a value of 0. This character string is right-justified, space-filled. month: FIELDATA CHARACTERS Bits day: FIELDATA CHARACTERS Bits year: FIELDATA CHARACTERS Word 010 Bits 0 11 hour: FIELDATA CHARACTERS Bits minute: FIELDATA CHARACTERS Bits second: FIELDATA CHARACTERS Word 011 Bits 0 5 revision id: UNSIGNED INTEGER Indicates the version of the data structures used for the logical file descriptor and for the track headers. A value of 1 indicates the revised format, described in this section. A value of 0 indicates the original FURPUR format, described in

84 FURPUR/PCFP File Formats Bits equip code: INTEGER Word 012 Bits 0 35 Gives the equipment code of the file from which the logical file was copied. This equipment code is the same as that returned by the FITEM$ Executive request; the interpretations of the various values can be found in the ER Programming Reference Manual. high trk written: UNSIGNED INTEGER Word 013 Bits Gives the highest track written for the file from which the logical file was copied. num trks in grp: UNSIGNED INTEGER RANGE (1 TO 16) Gives the number of tracks stored in each regular text block of the logical file. (The last text block may contain fewer tracks.) FURPUR Track Header Each track header is 2 words long, formatted as follows: 00 * sector addr 01 chksum trk seq num Word 00 Bit 0 last track indicator: CONDITION Bits 1 35 This item is true (1) only for the last track in the logical file. If a logical file is continued to another reel, for the last track written on any reel but the final reel, the last track indicator has a value of false (0). sector addr: UNSIGNED INTEGER Sector address of the start of the track within the random-access file (RAF). This value is always a multiple of track-size/sector-size = 1792/28 = 64. Note that this value is always a sector address, even when the logical file was copied from a word-addressable mass storage file

85 FURPUR/PCFP File Formats Word 01 Bits 0 17 chksum: LOGICAL Bits Gives the value of the checksum for the track. The checksum is calculated by summing each of the 1792 words of the track, then summing H1 and H2 of this sum, and truncating to 18 bits. Checksums are optional in the revised format. trk seq num: UNSIGNED INTEGER Gives the sequence number of the track in the logical file. These sequence numbers are strictly sequential, starting at zero, with no regard for the unoccupied area of the file. If there are over 262,144 tracks in the logical file, then the sequence number wraps around back to zero. FURPUR File-Swap Block The file-swap block is a 16-word block containing only constants. This block is formatted as follows: EOR$ EOR$ All character strings are ASCII Original FURPUR Format and Its Variants This section describes the original FURPUR format, and the variants of it that were written to various types of tape. These original variants are described by how they differ from the revised format described in Differences in Structure Definitions The FURPUR format has three components, defined as follows:

86 FURPUR/PCFP File Formats File descriptor In the original FURPUR format, the file descriptor is identical to the revised format, except that the revision id in word 011 and the num trks in grp in word 013 are always zeroes. Track header In the original format, the 1-bit item last track indicator in bit 0 of word 00 does not exist, and the item sector addr occupies all of word 00. However, the value of sector addr can never be large enough so that its leftmost bit is set. File-swap block The file-swap block is identical for the revised and original FURPUR formats. Differences in Arrangement of Data within the Logical File This section describes data layouts under the original FURPUR format, which differ depending on the type of tape. Ordinary Unlabeled Tape The term ordinary tape refers to all tape types except those specifically cited in the subsections that follow. For ordinary unlabeled tape, the data layout differs from the revised format as follows: All text blocks can contain only a single track (which includes the track header). Ordinary Labeled Tape Labeled tape contains system labels at the start of each reel, between logical files, and at the end of each reel. The labels are written and read automatically by the operating system, and are transparent to ordinary I/O. For ordinary labeled tape, the data layout differs from the revised format as follows: All text blocks can contain only a single track (which includes the track header). Compressed Tape Compressed tape can be labeled or unlabeled. For compressed tape, the data arrangement differs from the revised format as follows: Text tracks are grouped into I/O blocks, as with the revised format, but the file descriptor does not indicate how many tracks are in each group. FURPUR handles reading such a tape by guessing that the number of tracks per group is the same as a site-configured constant (which is the block size FURPUR uses to write these tapes). If it happens that this guess is wrong, FURPUR determines the correct value from information it acquired while trying to read the first block, backspaces the tape to the start of the logical file, and reads the logical file using the correct block size. The file descriptor is not written as a separate I/O block; instead, it is placed at the start of the first text block of the logical file, and this text block contains one less track than the regular text blocks. This scheme means that the initial tracks of the file must be read at the same time as the descriptor, unless the tape is backspaced. The indicator for logical end of tape differs depending on whether tape is labeled or unlabeled. The handling for this case is the same as it is for ordinary labeled and unlabeled tape, respectively, as described in the previous sections

87 FURPUR/PCFP File Formats Historical Variants The following topics describe differences in the original FURPUR format as it evolved through the years. It is possible that tapes in these formats may be archived or may have been copied to newer media types. In all cases FURPUR and PCFP can read all of these variants. FURPUR Levels Prior to 28R1 (Released in Late 1979) Prior to 28R1 file-swap blocks were 14 words in length instead of 16 words. Words 01 through 07 were binary zeroes instead of ASCII EOR$. For some levels the word 00 idpattern was instead of FURPUR Levels Prior to 27R3A (Released in Late 1978) Prior to 27R3A file-swap blocks were written for both labeled and unlabeled tapes. FURPUR Levels Prior to 27R1 (Released in Late 1975) Prior to 27R1 the FURPUR file descriptor contained binary zeroes in words 01 through 033. These file descriptors do not contain any information about the file from which the logical tape file was created. The track header contained binary zeros in word 01. These track headers do not contain either a checksum or a sequence number Element File Format An element file is produced from a program file by using control statement. It is a sequential file, found only on magnetic tape, and it can consist of a series of symbolic, relocatable, executable, and omnibus elements. Note: There are no plans to support element files in Program-Callable FURPUR. The elements (see FURPUR element file format, on the following page) are written in sequential order on the tape. Each element (see element in element file format, on the following page) contains a 28-word element label block and the element text. The element label block consists of the 10-word program file element table item followed by 18 words of zero and contains the following information: Element file identifier Element name, version, type, and size Time and date the element was added to the file The remainder of the element consists of 224-word blocks of the text of the element. This information is identical to the element text in the program file from which the element file was created. The only difference is that the element text is blocked into 224-word blocks; the last block is padded to force a 224-word block if the text does not occupy an exact multiple of 224 words

88 FURPUR/PCFP File Formats FURPUR Element File Format element label block 1 variable number of element text blocks element label block 2 variable number of element text blocks variable number of elements element label block n variable number of element text blocks end-of-file (EOF) mark Element in Element File Format element label block element text block 1 element text block 2 variable number of element text blocks element text block n (padding to 224-word boundary)

89 FURPUR/PCFP File Formats 5.4. Multi-reel Files The FURPUR processor automatically generates and checks for end-of-reel sentinels. For more information about the FURPUR processor, refer to the Executive Control Language (ECL) and FURPUR Reference Manual. The commands that write on tape generate an end-of-reel sentinel for unlabeled tapes when the hardware returns an end-of-tape status. The end-of-reel sentinel for unlabeled tapes has the following form: Word Word 1 Word (ASCII $EOR ) Word 8 Word FURPUR uses this format for both 8-bit and 6-bit labeled tapes. When writing to a quarter-word MSA tape, FURPUR uses the equivalent of the 8-bit format read as quarter-word. The commands that check the block following each EOF mark for an end-of-reel sentinel. The check is made for both labeled and unlabeled tapes, with one exception: A move across single-reel tapes does not read the next block after an EOF mark. Thus, files on a single-reel tape may have different file identifiers than the one used to assign the file. The current end-of-reel sentinel check is for 054 in bits 0 5 of word 00 in the first block after an EOF mark. If the sentinel is found, processing continues on the next reel. If word 00 does not contain an end-of-reel sentinel, FURPUR positions the tape between the EOF mark and the first block or, for a move with a remaining file count above 0, continues on to the end of the next file. Notes: 1. Higher levels of FURPUR will read the end-of-reel sentinel for unlabeled tapes as it is written by FURPUR level 28R1. The higher FURPUR levels will not read an end-ofreel sentinel on a labeled tape (instead, they will rely on the tape labeling information to determine when a tape swap is necessary). 2. Future FURPUR levels will not read unlabeled multireel tapes produced by the symbiont complex since they still use the old format of end-of-tape. 3. Not all levels of FURPUR handle multireel Processor Common Input/Output System (PCIOS) tape files, because different levels use different methods of indicating endof-tape

90 FURPUR/PCFP File Formats

91 Section 6 Internal Format (INFOR) When a program is executed as a processor, the OS 2200 Exec converts the processor call statement into internal format (INFOR) and supplies it as input data to the first symbiont read operation performed by the program. Note: This conversion occurs only for programs that are executed as a processor and not for programs executed with control statement program) INFOR Identifiers for Processor Call Statement The following diagram shows the general format of a processor call statement and the parts that are identified by INFOR. INFOR identifies the processor,options part of the processor call statement as field type 0. This is referred to as the command field. It is composed of field 1 and the option field. The field-1, field-2,...,field-n part of the call statement is identified as field type 1 and is referred to as the specification field. It is composed of a variable number of fields. INFOR does not include the label field and comment field of the processor call statement. Note: In other Unisys documents, the command field may be referred to as the processor field or operation field. The specification field may be referred to as the operand field, parameter operand, or parameter field

92 Internal Format (INFOR) A field in the processor call statement contains information that conforms to the syntax conventions of a file name or element name, as specified in the ECL End Use and Programming Reference Manual. The format of the standard filename.eltname notation consists of 8 parts. The following diagram shows how these parts are identified by INFOR. INFOR identifies each part of the filename.eltname in a field by its assigned sub-field number. For example, the filename is always identified as sub-field number 2, and eltname is always identified as sub-field number 6. The character data contained within the sub-field is referred to as the symbolic sub-field

93 Internal Format (INFOR) 6.2. The INFOR Table The format of the INFOR table is as follows:

94 Internal Format (INFOR) Word 0 Bits 0 9 Type Control statement type number. If these 10 bits are placed right-justified and zero-filled in a 36-bit word, the result value indicates the following: 0051 The INFOR table is for a processor call The INFOR table is for a FURPUR statement. Note: In an octal dump of word 0, the 4 leftmost octal digits would be 0244 if the INFOR table is for a processor call and the A and B were not specified. Bits Options These 26 bits are master bits representing the options that were specified in the option field of the processor call statement. Bit 10 is set if A was specified, bit 11 is set if B was specified,..., bit 35 is set if Z was specified. Note: The option field has no field number associated with it and has no sub-field descriptions generated for it. Sub-field Description This is an entry of 2 or 3 words consisting of the following parts: Sub-field control word Symbolic sub-field There is one sub-field description for each sub-field that was specified in the processor call statement

95 Internal Format (INFOR) Sub-field Control Word The following 1-word entry provides information about the sub-field. Bits 0 5 Field Type (FT) Indicates whether the sub-field is in the command field or in the specification field. The possible values are 0 Command field 1 Specification field Bits 6 11 Field Number (FN) The field number (within the field type) that contains the sub-field. In the processor call statement, fields are numbered beginning with 1, left to right, and are separated by commas. The highest field number is 63. If more than 63 fields are entered in the processor call statement, the 64th and following fields are numbered beginning with 1. Bits Sub-field Number (SFN) Identifies which part of the filename.eltname notation is being described by the sub-field. The possible values are 1 File qualifier 2 File name 3 File cycle 4 Read key 5 Write key 6 Element name 7 Version name 8 Element cycle

96 Internal Format (INFOR) Bits File Continuation Indicator (FCI) Bits The possible values are: 075 The Fieldata code for the period (.) character. This value indicates that the sub-field is the first one of the field, and the field contains a leading period. 000 Value used for all other cases. Character Count (CC) A value in the range 1 to 6. The character count indicates the number of characters in the last word of the symbolic sub-field. Bits Word Count (WC) A value of 1 or 2. The word count indicates the number of words in the symbolic sub-field of the sub-field description. Symbolic Sub-field This is the character data that was entered for the sub-field in the processor call statement. It is a Fieldata character string that uses either 1 or 2 words as indicated by the WC value. Each word can contain up to 6 characters. The number of characters in the symbolic sub-field can be calculated using the following formula: 6 * (WC - 1) + CC The characters are left-justified, and the unused rightmost character positions in the last word are space-filled

97 Internal Format (INFOR) The range for the number of characters and number of words in the symbolic sub-field is as follows: SFN Sub-field Name Number of Characters Number of Words 1 File qualifier 1 to 12 1 or 2 2 File name 1 to 12 1 or 2 3 File cycle 1 to Read key 1 to Write key 1 to Element name 1 to 12 1 or 2 7 Version name 1 to 12 1 or 2 8 Element cycle 1 to 3 1 INFOR Table Conventions The following conventions are used when generating the INFOR data: Except for one special situation, a sub-field description is generated only if symbolic sub-field information has been entered for that sub-field number in the processor call statement. The exception is if a field in the processor call statement contains a file name with a leading asterisk (*) character. For this situation, a sub-field description is generated as if a qualifier of 12 spaces had been entered in that field in the processor call statement. If a field in the processor call statement contains a leading period, the first sub-field description generated for the field will contain a value of 075 in the FCI part of the sub-field control word. If the symbolic information in the processor call statement uses a character type other than Fieldata, it is first translated into Fieldata before being put in the INFOR table. For example, if lowercase ASCII characters are entered in the processor call statement, the symbolic sub-fields in the INFOR table will contain the corresponding uppercase characters in Fieldata. If a processor call statement is continued onto more than one line using the semicolon (;), the INFOR is generated as if the call statement were on one line

98 Internal Format (INFOR) 6.3. INFOR Table Example Assume that the following processor call statement is entered to execute program.abs with c and z options and 3 fields in the specification field. The following octal word would be generated for word 0 of INFOR: The following sub-field descriptions would be generated in the INFOR table: Field 1 of command field FT FN SFN FCI CC WC Symbolic Sub-field PROGRAM ABS Field 1 of specification field FT FN SFN FCI CC WC Symbolic Sub-field FILE WRTKEY ELT Field 2 of specification field No sub-field descriptions are generated because the field contains only sub-field separators and no symbolic sub-field information. Field 3 of specification field FT FN SFN FCI CC WC Symbolic Sub-field ELEMENTNAME VERSION3 This example generates 23 words of INFOR

99 Internal Format (INFOR) 6.4. Reading the INFOR Table The INFOR data is supplied as input data to the first symbiont read operation performed by the program. The program issues an ER AREAD$, ER READ$, or ER SYMB$ (READ$ function) with a buffer size of at least 27 words specified. The INFOR data is received in blocks of 27 words or less. Only full sub-field descriptions are put in the block. If a sub-field description does not fit within the last words of the block, it is put in the next block. Upon return from the read, register A0 contains the following information: Bit 4 Bit 5 Bits This bit is set if the data transferred into the buffer is INFOR data. This bit is set if more INFOR data needs to be read. These bits specify the number of words transferred into the buffer. Notes: If the program issues a read command that specifies a buffer size less than 27 words, INFOR data may be transferred into the area beyond the end of the buffer. The SYSLIB and the SLIB service libraries provide INFOR routines to read the INFOR table, to search it, and to transfer data from it to other tables. See the SYSLIB Programming Reference Manual and the SLIB Programming Reference Manual Determining the INFOR Table Size If a program intends to read the entire INFOR table into memory, the size of the memory area needed to hold the INFOR table can be determined by adding the maximum sizes needed by the various types of information that are put in the table. 1 Word 0 of INFOR table + 18 Words needed for field 1 of the command field if it contains a fully specified file name and element name. + 20*n n is the number of fields that the program expects in the specification field. Multiply n by 20, which is the number of words needed by each field if it contains a fully specified file name and element name. sum The sum above is the maximum size of the INFOR table

100 Internal Format (INFOR)

101 Section 7 Object Module Format Object Module (OM) is the object file type used by the Linking System in an OS 2200 system. It is produced by the compilers and the Link Processor. It can be directly executed or combined with other OMs. This section defines the data structures in the OM that are used to execute programs. The OM format is owned by the Linking System and currently used by the UCS compilers, MASM, FLIT, GSA, EXEC, and Linking System Object Module (OM) Layout This section describes the logical layout of the OM format in mass storage. It provides the field names and status names for all the structures in the OM. The OM format is defined by the following code declaration elements: DC-OMFORMAT DC-OMFORMAT contains the PLUS declarations for the OM. OM.H OM.H contains the C declarations for the OM. The structure and field names are the same between DC-OMFORMAT and OM.H. However, all the names in OM.H are in lowercase because C is case sensitive. There are differences between the status and enumeration names because C enumerations define names that are not local to the use of the enumeration variable. The names must be unique for all the names at the global scope. However, for PLUS where two status lists may contain the same status name, a status or an enumeration field is used. This section lists the PLUS and C versions of the define type name and the names used in the status or enumeration list. All the status names have been modified from the PLUS to the C version. In most cases, a common suffix is appended to the end of the PLUS name to form the name in the enumeration list. Note: Currently, the Linking System owns the DC OMFORMAT (the PLUS version) and OM.H (the C version). Changes to any one of these files require change to other file to maintain consistency. During the solar installation of LINK, the OM/H element is written to the file SYS$LIB$*PROC$. When an OM is referenced by a processor call, either from or from another OM, Exec calls the Linking System to load the OM. A ZOOM is a special type of OM that is loaded directly by the Exec. A ZOOM has all the OM structures defined in this section as well as the structures defined in Section 14, Zero Overhead Object Module Format

102 Object Module Format 7.2. OM Overview The OM is divided into two major parts: the control information and the text. The control information is used to determine how the OM is linked with other OMs, or how it is loaded. The text represents the actual data to be loaded into the banks of the executing program. The control information is also broken down into various pieces. The OM control information is a hierarchical structure. The root structure is the OM header that contains element level information and points to other element level structures in the OM such as the name table, the p-codes, and the definitions. The OM header also points to the bank groups in the OM. A bank group is a collection of banks which are treated as a unit for loading. The bank group points to the banks in the bank group. In turn, each bank has a header that describes its attributes and also contains pointers to the bank level structures such as the reference table, bank part table, and the text for the bank. Note: Only the OM Header and the text of an OM are pointed to by structures outside the OM (pointed to by the Table of Contents Entry). The other structures are all located by following the pointers in the control information in the OM which, unless specified are word offsets from the start of the element. Many fields in these data structures include Integrated Scientific Processor (ISP) in their names. These fields related to the ISP, which is a de-committed hardware product. With LINK release 11R1 in late 2001, several fields were added to the OM Definition entry and the Bank Group Header to solve field overflow problems. The OM Definition entry received new fields, full complete name offset, and full expression offset. The Bank Group Header received full bank group name offset. The original fields have the same names without the leading full. The new full fields are always set to the appropriate values starting with level 11R1. The older fields are also still set; however, if they overflow they are set to zero as an indication that the newer fields must be used

103 Object Module Format OM Level Structures Figure 7 1 shows an overview of the OM structures The OM Control Header Figure 7 1. OM Level Structures The OM Control header is always at the beginning of the OM. It contains the total length of the element and pointers to the control information and the bank text. Refer to Figure 7 2 for OM Control Header. Words 01 through 012 in this structure is a copy of the initial Executable Element Table Item (See Section 8.6.3, Executable Element Table) and, though currently created by the Linking System in all the OMs, it is not used to load the OM. Word 013 is used to locate the element table and word 0 is used to verify that this element is an OM. The Linking System ignores the other values in the OM Control Header when it loads the OM

104 Object Module Format 00 recognition value element name (2 words) 03 version link pointer link 04 flag bits element type type link version name (2 words) 07 F OM header sector address 010 element subtype element sub subtype zoom header offset 011 OM text sector address 012 creation date time 013 OM element table sector address Word 00 recognition value Figure 7 2. OM Control Header length of element text (sectors) A constant used to verify that this is an OM. This should be *OM* in ASCII characters. Word 01 Word 02 element name The name of the element in Fieldata characters, left-justified, and space-filled. Word 03 bits 0-17 version link Refer to Section 8.6, Element Table for the definition of version link. bits pointer Iink Refer to Section 8.6, Element Table for the definition of pointer link

105 Object Module Format Word 04 bits 0-11 flag bits Refer to Section 8.6.3, Executable Element Table Item for the definition of flag bits. bits element type 06 executable. Refer to Section 8.6 Element Table for the list of all element types. type link Refer to Section 8.6, Element Table for the definition of type link. Word 05 Word 06 version name The version name of the element (12 Fieldata characters). Word 07 bit 0 F Flag bit set for OMs. bits 1-35 OM header sector address The sector offset from the start of the OM to the OM Header. Word 010 bits 0-5 element subtype 01 OM 03 ZOOM

106 Object Module Format bits 6-11 element sub subtype For subtype 1 (OM): 00 object module (OM) 01 bound object module (BOM) For subtype 3 (ZOOM): bits undefined 01 ZOOM zoom header offset This field contains the sector offset of the ZOOM header from the beginning of the OM Header. This allows the EXEC to identify where to find the ZOOM header without reading the OM header. If the OM is a ZOOM and this field contains 0, the sector offset of the ZOOM header will not fit in the field. In this case, the EXEC must look in the OM header for the ZOOM header address. bits length of element text (sectors) The length of the executable element text in sectors. Word 011 OM text sector address Sector offset from the start of the Program File. Note that this is the sector address of the OM at the time it was created. If the program file is packed or the OM element is copied to some other file, this sector address will be incorrect. Word 012 Creation Date Time Standard date and time as defined by reverse ER TDATE$. Date is in H2 and time in H1. Date is in Month, Day, Year (modulo 1964) format. OM element table sector address Sector offset of the element table from the start of the Object Module. This field is null if the table does not exist. This field is not part of the Executable Element Table Item

107 Object Module Format OM Header Figure 7 3 shows a picture of the OM Header. 00 recognition value linking system level id (3 words) creation time (2 words) 06 element length 07 OM attributes L N refine- ment level 010 definition p-code list size 011 definition p-code list offset 012 reference p-code list size 013 reference p-code list offset 014 OM definition count 015 OM definition table offset 016 complete name table size 017 complete name table offset * OM version number 020 LBN bank group number table size linker page size 021 LBN bank group number table offset 022 zoom control info offset 023 ALS initial size 024 ALS max size 025 max banks min gap size 026 extension offset 027 total bank parts bank group count 030 n bank group offset (this field repeats) Figure 7 3. OM Header The OM Header contains the information required to identify the OM and to locate its bank groups and other control structures. The header contains the following fields: Word 00 recognition value A constant used to verify that this is an OM. This should be *OM* as ASCII characters

108 Object Module Format Word 01 Word 03 linking system level ID 12 ASCII characters that contain the current internal level of the linking system that created this OM. Word 04 Word 05 creation time The number of 1/8th milliseconds past Jan 1, Word 06 element length The total length of the element in words. Word 07 bits 0-11 OM attributes This field contains information about the banks contained in this OM. Each flag bit in this field is one bit flag that indicates characteristics of the OM. Bit Meaning 0 Has_BM Set if the OM contains Basic Mode banks. 1 Has_EM Set if the OM contains Extended Mode banks. 2 Has_Eagle Set if the OM contains ISP Mode banks. 3 Has_Unknown Set if the OM contains banks whose mode is unknown. 4 Eagle_Fully_Idnked Set if this is an ISP OM that has been fully resolved. 5 No_Blockdata_Search Set if no blockdata search is to occur for common blocks referenced by this OM. 6 OM_Is_ZOOM Set if the OM is actually a ZOOM. ZOOM's are loaded by the EXEC, rather than the Linking System. 7 Addrs_Are_Assgd Set if BDI's have been allocated and references patched with real addresses. This bit is true if the OM is a Bound OM (BOM) or a ZOOM. 8 Bank_Parts_Combined Set if the bank parts of this OM have been combined into bank part entries of a bank. Older versions of bank parts are in a different form. 9 No_XREFS Set if the OM contains no unresolved reference external expressions. 10 Flat_Environment Set if the OM contains a flat data bank. 11 OM_is_FLSS Set if this OM is a FLSS OM, produced with the OUTPUT FAST_LOAD SELF_CONTAINED statement

109 Object Module Format bit 12 LN Set to 1 if this OM has long names any name longer than 1024 characters (bytes). bits refinement level Contains an integer that identifies the changes made to the way the OM is physically written to mass storage. This field is provided to support upward compatibility and at the same time allow these variations to be used to the advantage of the Linking System. Refinement level is set to 1. bits The OM has been written in inverse hierarchical order (Bank Ctrl Information, Bank Header, Group Header, and so on) 1 The OM has been written in the hierarchical order (Group Header, Bank header, Control Information, and so on) OM version number This field contains an integer that indicates the revision level of the Object Module Format. This should allow the Linking System to detect when an incompatible OM has been given or found through library search. OM version number is set to 1. Word 010 definition p-code list size The length of the list of p-codes that are used in definition expressions in words. Word 011 definition p-code list offset The word offset from the start of the element to the list of p-codes that are used in definition expressions. Word 012 reference p-code list size The length of the list of p-codes that are used in reference expressions in words

110 Object Module Format Word 013 reference p-code list offset The word offset from the start of the element to the list of p-codes that are used in reference expressions. Note: The p-codes for all definition expressions contained in an Object Module are placed into a single table. p-codes in each expression are contiguous. Word 014 OM definition count The number of definitions. Word 015 OM definition table offset The word offset from the start of the element to the table of definitions. Word 016 complete name table size The size (in words) of the table containing the Link_String forms of all names used in an OM. Word 017 complete name table offset The word offset from the start of the element to the table containing the Link_String string form of all names used in an OM. Word 020 bits 0-23 LBN bank group number table size The size (in words) of the table that translates between Logical Bank Numbers and the replication numbers of the Bank Groups to which they belong. bits linker page size The size (in words) of the virtual storage manager's pages when the OM was created

111 Object Module Format Word 021 LBN bank group number table offset The word offset from the start of the element to the table that translates between Logical Bank Numbers and the replication numbers of the Bank Groups to which they belong. Word 022 zoom control information offset The word offset from the start of the element to the load control information to be used when initial load of the OM is done by the EXEC. Refer to Section 14, Zero Overhead Object Module Format for more information. Word 023 ALS initial size The size (in words) of the initial allocation for the Activity-local stack bank for an activity executing the program contained in this Object Module. Word 024 ALS max size The largest size of the Activity-local stack bank. Word 025 bits 0-17 Max banks Used by the static linker to estimate buffer sizes required to hold bank group headers. This value is the number of banks in the group that contains the most banks. bits min gap size The value of Min_Gap used when the OM was created. This value is number of words in the smallest gap of uninitialized text in any bank of the OM. Word 026 extension offset The offset of the OM Header Extension

112 Object Module Format Word 027 bits 0-17 total bank parts The total number of bank parts in the OM. bits bank group count The number of bank groups in this OM. Word 030 bank group offset(s) An array of word offsets from the start of the element that point to the bank groups of this OM OM Header Extension Figure 7 4 shows a picture of the OM Header Extension. 00 VA 01 logical bank number (LBN) 02 bank offset 03 latent parameter 04 latent parameter LBN 05 latent parameter offset reserved (9 words) Figure 7 4. OM Header Extension The OM Header extension contains additional information describing the OM. Specifically it contains information regarding the address of the starting address of the OM. Word 00 virtual address A Virtual Address representing the start address of this OM. Currently valid only in ZOOMs and BOMs

113 Object Module Format Word 01 logical bank number (LBN) LBN of the bank of the entry point for the start address of this OM. Word 02 bank offset Offset in the bank of the entry point for the start address of this OM. Word 03 latent parameter The Virtual Address of the latent parameter for the starting address of this OM. Valid only in ZOOMs and BOMs. Word 04 latent parameter LBN LBN of the bank of the latent parameter for the starting entry point of this OM. Word 05 latent parameter offset Offset in the bank of the latent parameter for the starting entry point of this OM Complete Name Table The complete name table is used to hold the strings in the OM. It is a table of link strings. A link string contains a code, a length, and the text for the string as shown in Figure code set * length 01-n text Figure 7 5. Link String Format

114 Object Module Format The Link String Format contains the following fields: Word 00 bits 0-8 code set Indicates ASCII or KANJI. Numeric Value PLUS Status code_set_value UC Constant 01 S'ASCII' ascii_code_set 020 S'JIS16' jis16_code_set bits length The length of the string in characters. Word 01 through n text The text of the string, left justified OM Definitions All the definitions for the OM are in the definition table. Figure 7 6 shows the format of a definition. 00 encoded name 01 definition type 02 flat status reserved visibility SCS conformance expression length complete name offset expression offset 03 full complete name offset 04 full expression offset reserved (2 words) Figure 7 6. Definition Entry Format

115 Object Module Format Definition Entry Format contains the following fields: Word 00 encoded name In order to make the entries of the definition table fixed in size, the link_string form of the definition's name is encoded into a 36 bit value. This value is used as a key when the table of definitions is searched. Word 01 bits 0-5 definition type The following definition types are available bits 6-11 Numeric Value OM_Def_Type_Format PLUS Status Value om_def_type_format UC Constant 00 S'Unknown' unknown_def_type 020 S'Cmn_blk' cmn_blk_def_type 021 S'Code' code_def_type 022 S'Constant' constant def type 023 S'Data' data_def_type 024 S'Fixed_Gate' fixed_gate_def_type visibility This field provides information about whether the definition is visible to other OMs during resolution of those OM s references. Possible values are as follows Numeric Value PLUS Status Value visibility_format UC Constant 020 S'Ext' ext_visibility 021 S'Int' int_visibility 022 S'SS_Ext' ss_ext_visibility

116 Object Module Format bits SCS conformance This field is relevant only on definitions with type = S'Code'. This shows how the routine definition identifies and conforms to the Standard Calling Sequence. S'Undefined' is only defined for old OMs that did not initialize SCS_Conformance to one of the other three values. It is not a valid value for the OMs that are currently created. bits complete name offset Numeric Value PLUS Status Value scs_conformance_format UC Constant 00 S'Undefined' undefined_conformance 01 S'None' none_conformance 020 S'Loose' loose_conformance 021 S'Strict' strict_conformance As the link_string form of the definition name is of variable length, it is not placed in the definition's entry in this table. Instead, the Link_String forms of all names in an OM are placed in a single table. This field contains the offset within the table of that definition name. If the offset is too large to fit into this field ( > ), this value is set to 0(zero) and the complete name offset field (Word 03) is used. Word 02 bits 0-5 flat status Set to S'Flat' if the definition resides in an OM created by the compiler with the FLAT option on. bits 6-8 Numeric Value Flat_Status_Format PLUS Status flat_status_format UC Constant 00 S' Do_Not_C are' do_not_care_addres sing 01 S'Not_Flat' not_flat_addressing 02 S'Flat' ' flat_addressing reserved Set to zero. However, in some pre-1989 OMs, these bits are set to random values

117 Object Module Format bits 9-17 expression length The length in words of the expression that corresponds to this definition. bits expression offset Definition expressions are similar to names in Link_String form in which they are made up of a variable number of p-codes, each of which may vary in length. Therefore, the lists of p-codes that make up an expression are combined into a single table for entire OM. This field contains the word offset in that table of the first p-code in a particular expression of the definition. If the offset is too large to fit into this field ( > ), this value is set to zero and the complete expression offset field (Word 04) is used. Word 03 full complete name offset Refer to the description for complete name offset in Word always sets this field. Word 04 full complete expression offset Refer to the description for expression offset in Word always sets this field Bank Group Header Bank Groups are collections of banks that are loaded at the same time. The Bank Group Header is used to describe the bank groups in the OM. Figure 7 7 shows the format of the bank group header. 00 full bank group name offset 01 VAs reserved 02 bank group name offset related bank count 03 related bank offset (repeats) Figure 7 7. Bank Group Header

118 Object Module Format The bank group header contains the following fields: Word 00 full bank group name offset Refer to the description for bank group name offset in Word always sets this field. Word 01 bit 0 VAs When set, this bit indicates that the VAs for all banks of the bank group have been assigned when the OM was created. Word 02 bits 0-17 bank group name offset The offset (in words) from the beginning of the complete name table of the Link string form of the bank group name. If the offset is too large to fit into this field (> ), the value is set to zero and the full bank group name offset field (Word 00) is used. bits related bank count The number of banks in the bank group. Word 03-n related bank offset An array of zero or more word offsets to the bank headers of the banks in this bank group. Each offset is one word

119 Object Module Format Element Table An Element Table is included in an OM created by the LINK processor when the F letter option is not specified. The Element Table is used to identify all OMs and the time of creation that was included in the output OM. The Element Table is used by OMLIST (through the LIST processor) to display the object module and time of creation information. 00 recognition value 01 total element count 02 total element part table size 03-n element part table (repeats) Figure 7 8. Element Table The Element Table contains the following fields: Word 00 recognition value A constant used to identify this structure as an Element Table. This should be *ET* in ASCII characters. Word 01 total element count The total number of elements in the Element Table. Word 02 total element part table size The size (in words) of all the Element Part Tables in the Element Table. Words 03-n element part table This is a repeating field. The number of element part table entries is equal to the number of static links that were used to create the object module. Each element part table contains information about the object modules that were included by that particular static link. The element part table is shown in Figure

120 Object Module Format 00 element count 01 file count 02 current ENT offset 03 current FBT offset 04 next EPT offset 05 element name table n file name table Figure 7 9. Element Part Table The element part table contains the following fields: Word 00 element count The number of Element Name Tables in the Element Part Table. Word 01 file count The number of File Name Tables in the Element Part Table. Word 02 current ENT offset The word offset from the top of the Element Part Table to the Element Name Table. Word 03 current FNT offset The word offset from the top of the Element Part Table to the File Name Table. Word 04 next EPT offset The word offset from the top of the Element Part Table to the next Element Part Table

121 Object Module Format Word 05 element name table This is a repeating field. The number of Element Name Table entries is equal to the number of object modules that were included in the static link associated with a particular element part table entry. The element name table entry is shown in Figure Word n file name table This is a repeating field. The number of file name table entries is equal to the number of unique file names that are associated with the object modules in the element name table entries for a particular element part table entry. The file name table entry is shown in Figure previous EPT offset 01 ENT index 02 FNT index 03 code set reserved length element name( characters 1-24) element name reserved (character 25) 011 time of creation Figure Element Name Table The element name table contains the following fields: Word 00 previous EPT offset The word offset to the previous Element Part Table. Word 01 ENT index The index of the Element Name Table in the Element Part Table. Word 02 FNT index The index of the File Name Table in the Element Part Table

122 Object Module Format Word 03 bits 0-8 code set Indicates ASCII or KANJI. bits length Numeric Value PLUS Status code_set_value UC Constant 01 S'ASCII' ascii_code_set 020 S'JIS16' jis16_code_set The length of the element name in characters. Word 04 and Word 5 bits 0-8 element name The text of the element name which can be a maximum of 25 characters. Word 06 time of creation The time and date on which the element was created in reverse TDATE$ format. 00 code set reserved length 01-n file name (characters 1-30) Figure File Name Table The file name table is variable length depending on the number of characters in the file name. The file name table contains the following fields: Word 00 bits 0-8 code set Indicates ASCII or KANJI

123 Object Module Format bits length Numeric Value PLUS Status code_set_value UC Constant 01 S'ASCII' ascii_code_set 020 S'JIS16' jis16_code_set The length of the file name in characters. Word 01-n file name 7.3. Banks The text of the file name which can be a maximum of 30 characters. Banks are the basic unit of information in the OM. A bank in the OM represents a physical bank to be created when the OM is loaded. The following structures describe the attributes of a bank in the OM Bank Header An OM Bank Header exists for each bank in the OM. This header contains pointers to information which describe the bank and pointers to information that describe the contents of the bank. Figure 7 12 shows the OM Bank Header. 00 reserved logical bank number 01 FF bank part type SDD logical bank number 02 SDD offset 03 bank name offset 04 ISP LBN entry count LV parallel table ACW count 05 LV parallel table ACW pointer 06 LV parallel table pointer 07 LV parallel table size 010 common block definition index 011 common block hash value heap name offset 012 bank reference count 013 bank reference offset 014 bank control info offset 015 text info offset 016 bank group number bank part count 017 extension offset 020 ISP LBN table offset 021 bank part entry offset Figure OM Bank Header

124 Object Module Format The OM bank header table contains the following fields: Word 00 logical bank number (LBN) A numeric value that uniquely identifies this bank within the OM. Word 01 bits 0-1 flags The following two one bit flags are defined as follows: bits 2-11 Non_Par_LVB No_XREFS This field is true if the required index into the bank reference table is found in the second word of the LVE rather than in the parallel table. This field is true if the bank contains no reference expressions which are not resolved to addresses within this OM. bank part type Indicates if the bank parts are combined (new style) or separate. bits Numeric Value Flat_Status_Format PLUS Status Value flat_status_format UC Constant 00 S'Separate' separate_bank_part_type 01 S' Combined ' combined_bank_part_type SSD logical bank number (LBN) The Logical Bank Number of the SDD information for this bank. Word 02 SSD offset The offset within the SDD LBN of the SDD information for this bank. Word 03 bank name offset The word offset of the link-string form of the symbolic name that was attached to the bank at the time of its creation, within the table of complete names. This name is unique among banks in this OM

125 Object Module Format Word 04 bits 0-17 ISP LBN entry count The number of entries in the table that contains the LBN's which correspond to indices that reside in the bank text. Refer to Word 020 for a description of ISP LBN table. bits LV parallel table ACW count The number of ACWs in the list of ACWs that describe the Link Vector Parallel Table. Note: This field is no longer used. Word 05 LV parallel table ACW pointer The offset of the list of ACWs that describe the Link Vector Parallel Table. Note: This field is no longer used. Word 06 LV parallel table pointer The offset of the text of the Link Vector Parallel Table. The relationship between the words in this table and the text of the bank itself is described by the ACWs for the LV parallel table. Note: This field is no longer used. Word 07 LV parallel table size The size of the Link Vector Parallel Table. Note: This field is no longer used. Word 010 common block definition index The index in the table of definitions of a common block definition within this bank. If none exists, this field is null. If bank parts exist which have common blocks defined, the bank part headers for those parts will contain valid values in this field

126 Object Module Format Word 011 bits 0-17 common block hash value This field contains a value that was computed using the initial values of all text of the bank. At the time any program requires loading of the common block, this value is compared with values for the common block that appear in other OMs. This checking takes place only if specifically required by the p-code operator that defines the common block. bits heap name offset The word offset of the link-string form of the symbolic name which was attached to the heap that this bank will be merged within the table of complete names. This name is unique among heap banks in this OM. This is an 18 bit field. During static linking, a fatal error occurs if the value for this field exceeds Word 012 bank reference count The number of references in this bank. Word 013 bank reference offset The word offset from the start of the element to the table of references of the bank. Word 014 control information offset The word offset from the start of the element to the control information of the bank. Word 015 text information offset The word offset from the start of the element to information about the text of this bank, for example, load information

127 Object Module Format Word 016 bits 0-17 bank group number The index in the table of Bank Group headers of the group to which this bank belongs. bits bank part count The number of bank parts within this bank. Bank parts result from merging number of banks into one single bank. Word 017 extension offset Word offset to an area that is an extension of the bank header. This exists to allow upward compatibility as well as future enhancement of the Bank Header. Word 020 ISP LBN table offset Word offset to the table that translates the bank indices contained in ISP text words to the LBNs of the banks they refer to. Word 021 bank part entry offset Word offset to the table of bank part information for each of the bank parts contained in the bank Bank Header Extension The bank header extension provides additional information about the bank. Figure 7 13 shows the Bank Header Extension structure. 00 ISP LBN index entry count * 01 ISP LBN index table offset 02 Total length 03 reserved (9 words) 013 Figure OM Bank Header Extension

128 Object Module Format The bank header extension contains the following fields: Word 00 bits 0-17 ISP LBN index entry count Contains the number of entries in the LBN_Index Table; these entries describe the relocation for consecutive areas of an ISP code bank. Word 01 ISP LBN index table offset Contains the word offset of the LEN index table. Word 02 total length Used only as temporary storage at Static Link time Bank Control Information The bank control information structure holds additional information about the attributes of the bank. Figure 7 14 shows the Bank Control Information structure. 00 flags1 eagle local VASM area ID reserved priority 01 lower address 02 size 03 max allowed address 04 min allowed address 05 Type own access nonown access mode locality access control 06 storage alignment sub-type relocation merge order flags2 class method 07 VA 01 0 reserved Figure OM Bank Control Information

129 Object Module Format The bank control information contains the following fields: Word 00 bits 0-17 flags1 The following flags are defined in the first 18 bits of the structure Bit Meaning 0 Zero_Fill This field, when set to true, indicates that uninitialized parts of the bank must contain zeroes when the program is executed. 1 Already_Zero_Filled This field, when set to true, indicates that the bank will initialize itself to zeroes where appropriate. This implies that text exists which contains zeroes, and this will be loaded along with the other text. 2 Has_Strong_Refs This condition indicates whether or not the bank contains any references that have the strength value S'Strong'. 3 Has_Normal_Refs This condition indicates whether or not the bank contains any references having the strength value S'Normal'. 4 Bank_Is_Segmented This condition flags whether or not this bank is segmented. If true, the 262k segments of the bank are to be treated as separate physical banks, but must be assigned adjacent BDIs. 5 Required_In_AST This field is set to true if LINK has determined that the bank should be represented in the Active Segment Table (AST) on the ISP. This flag may be necessary because the expression handler may not be involved if the bank is referenced through a relocation bit. 6 Refs_Other_Bank_Group This field is set to true if the bank makes references to banks that are in other bank groups. This may be used if VA prediction has been done, and it is necessary to know if other bank groups are referenced, since the VAs of banks in those other groups will not be predicted. 7 CB_Aligned Flagged when Common Block type is aligned for the ISP Paging_Status This 3 bit bank attribute can possess one of the following values: Not_Paged ( meaning bank will not be paged ) Paged ( meaning bank is paged when needed ) 2 Page_Locked (meaning bank is always paged in its entirety ) 11 No_XREFS This field is used by the Linking System during the load of Bound OM's. It is true if none of the reference expressions in the bank remains unresolved. 12 Allocated_In_HVTIP_Heap Set to true if the space for the bank is to be allocated in the HVTIP heap. This is primarily used during debugging, and also internally by LINK to determine the banks that are to receive entries in the ZOOM load information. 13 Named_Heap Set to true if this bank is associated with, and probably will be merged into a named heap

130 Object Module Format Bit Meaning Flat_Status A status field describing the probable layout of the bank. Numeric Value Flat_Status_Format PLUS Status Value flat_status_format UC Constant 00 S'Do_Not_Care' do_not_care_addressing 01 S'Not_Flat' not_flat_addressing 02 S Flat' flat_addressing 17 Mod_64_BDI When set, the bank requires a BDI that is module 64 (multiple of 0100). Word 00 bits eagle local priority This bank's priority for inclusion in the ISP local storage bank. Relevant only if Storage_Class = S'Eagle_Local'. Word 00 bits VASM area ID Identifies the virtual address space model (VASM) management area in which this bank is to be allocated. The predefined values are as follows: 0 (NONE) No management area is associated with this bank. The VASM is not used in determining the management of this bank. 1(UNSPECIFIED) A determination of what management area this bank belongs to is made at load time using the management area selection algorithm specified in the VASM. 2 (CODE) The UCS default management area for code banks. 3 (PROGRAM_LOCAL_HEAP) The UCS default management area for program local data banks. URTS may request program local heap space from this area. 4 (ACTIVITY_LOCAL_HEAP) The UCS default management area for the activity local stack and activity local data banks. URTS may request activity local heap space from the non-stack portion of this area. 5 (BASEABLE) The UCS default management area for banks which are always based before use. There are no other restrictions on the type of bank based in the BASEABLE area. 6 (SDD) The UCS management area for SDD banks

131 Object Module Format Word 01 lower address The lowest relative address in the bank. The granularity of this value is given by the attribute alignment. Word 02 size The size of the bank in words when first loaded. Word 03 max allowed address The maximum allowed address. This value is used to determine whether or not this is a large bank. Word 04 min allowed address The smallest address permitted to exist in this bank. Word 05 bits 0-5 type Treatment of a bank by various routines of the Linking System is based on its type. The possible types are as follows: Numeric Value Bank_Type_Format PLUS Status bank_type_format UC Constant 00 S'Unknown' unknown_bank_type 020 S'Cmn_Blk' cmn_blk_bank_type 021 S'Code' code_bank_type 023 S'Data' data_bank_type 024 S'General_Purpose' general_purpose_bank_type 025 S'Link_Vector' link_vector_bank_type 026 S'SDD' sdd_bank_type 027 S'Multiple_Types' multiple_types_bank_type 030 S'Info' info_bank_type

132 Object Module Format bits 6-11 own access The definition of access for activities whose keys unlock the bank. Corresponds after considering protection attributes to SAP. The possible values are as follows: bits nonown access Numeric Value Own_Access_Format PLUS Status own_and_nonown_access_format UC Constant 00 S'Unknown' unknown_access 020 S'Read_Only' read_only_access 021 S'Execute_Only' execute_only_access 022 S'Read_Write' read_write_access 023 S'Read_Execute' read_execute_access 024 S'General_Purpose' general_purpose_access The definition of access for activities whose keys do not unlock the bank. If the bank's domain class is other than s'private' this attribute is ignored. The values are as follows bits Numeric Value Nonown_Access_Format PLUS status own_and_nonown_access_format C constant 00 S'Unknown' unknown_access 01 S'None' none_access 020 S'Read_Only' read_only_access 021 S'E xecute_only' execute_only_access 022 S'Read_Write' read_write_access 023 S'Read_Execute' read_execute_access 024 S'General_Purpose' general_purpose_access mode The mode of the bank are as follows: Numeric Value Mode_Format PLUS Status mode_format C Constant 00 S'Unknown' unknown_mode_bank 020 S'Basic' basic_mode_bank 021 S'Eagle' eagle_mode_bank 022 S'Extended' extended_mode_bank 023 S'Other' other_mode_bank

133 Object Module Format bits locality The degree of sharability of the bank. This value will be mapped into the hardware address tree at execution time. The values are as follows: bits access control Numeric Value Locality_Format PLUS Status locality_format C Constant 00 S'Unknown' unknown_local 020 S'Activity' activity_local 021 S'Program' program_local 022 S'Run' run_local 023 S'Application' application_local 024 S'System' system_local 025 S'Caller_Local' caller_local This value is used to determine the Ring number to request when the Linking System calls the Exec to acquire a physical bank for this logical bank. User_1, User_2, and so on, indicate decreasing privilege. The values are as follows Numeric Value Access_Ctrl_Format PLUS status access_ctrl_format C constant 00 S'Unknown' unknown_access_control 020 S'Kernel' kernel_access_control 021 S'Trusted_Nonkernel' trusted_nonkernel_access_control 022 S'User_1' user_1_access_control 023 S'User_2' user_2_access_control 024 S'User_3' user_3_access_control Word 06 bits 0-5 storage class The definition of the hardware memory type needed by the bank. The values are as follows Numeric Value Storage_Class_Format PLUS status storage_class_format UC Constant 00 S'Unknown' unknown_storage_class 020 S'Eagle_local' eagle_local_storage_class

134 Object Module Format bits 6-11 Numeric Value Storage_Class_Format PLUS status storage_class_format UC Constant 021 S'HPSU_or_MSU' hpsu_or_msu_storage_class 022 S'HPSU' hpsu_storage_class 023 S'MSU msu_storage_class alignment The boundary requirements that must be satisfied when creating the bank for this bank template. This is the power of 2 word boundary alignment required, so 0 implies word alignment, 1 implies double word alignment, and so on. bits sub-type This is a set of masterbits that are used to determine the types of the banks that were merged to create this bank. If the bank is not the product of a merge, then the appropriate bit is set. bits relocation method Specifies the accelerated relocation method to use for this bank. This is used with the relocation bits of the bank. bits Numeric Value Relocation_Method_Type PLUS status relocation_method_type UC constant 00 S' Unspecified' unspecified_relocation 05 S'Code_Offset_16_Bit' code_offset_16_bit_relocation 07 S Code_offset_18_bit no UC constant 012 S'Offset_In_LBN_1 6_Bit' offset_in_lbn_1 6_bit_relocation 017 S'No_Relocation' no_relocation_relocation 024 S'Local_Addr_To_VA' local_addr_to_va_relocation 031 S'Same Bank_VA' same_bank_va_relocation 036 S'Offset_In_Indexed_LBN' offset_in_indexed_lbn_relocation

135 Object Module Format merge order Specifies the rules to use when this bank is merged with other banks. bits Numeric Value Merge_Order_Format PLUS status merge_order_format UC constant 00 S'Any' any_merge_order 01 S'None' none_merge_order 02 S'First' first_merge_order 03 S'Last' last_merge_order 04 S'Lo' lo_merge_order 05 S'Hi' hi_merge_order flags2 33 Requires_Low_BDI Values are as follows: 0 The bank may have a low BDI or high BDI (that is, greater than 4095). 1 the bank must have a BDI less than Word 07 VA 34 unused 35 unused When the OM is really a BOM or ZOOM, this field contains the L, BDI, and offset assigned to the first location in the bank Bank Reference Table The bank reference table contains the references for the bank. Figure 7 15 shows a picture of the Bank Reference Table. Each reference is represented as a p-code series of operations, in a manner similar to that for the definitions. The item labeled bank_reference contains information specific to a reference. 00 type strength resolution type storage class group info valid SCS conformance 01 expression offset 02 expression size expression length requires gate 03 flat status binding status LBN 04 word offset 05 group size group increment 06 bit offset * Figure Bank Reference Entry *

136 Object Module Format The bank reference entry contains the following fields: Word 00 bits 0-5 type The type of definition that this reference expects as its resolution. bits 6-11 Numeric Value Bank_Ref_Type_Format PLUS Status bank_ref_type_format UC Constant 00 S'Unknown' unknown_ref_type 02 S'Any' any_ref_type 020 S'Cmn_Blk' cmn_blk_ref_type 021 S'Code' code_ref_type 022 S' Constant' constant_ref_type 023 S'Data' data_ref_type 024 S'SDD' sdd_ref_type strength Determines the resolution time. A strong reference is resolved before execution time, while a normal reference is not. In addition, a strong reference causes inclusion during any pre execution linking. Only references with a resolution type of S'LVE' can be normal. bits Numeric Value Bank_Ref_Strength_Format PLUS Status bank_ref_strength_format UC Constant 00 S'Unknown' unknown_strength 020 S'Strong' strong_strength 021 S'Normal' normal_strength 022 S'Static' static_strength 023 S'OM_Split' om_split_strength resolution type Determines how the reference will be resolved. Link Vector entries are resolved as LVE. Other references can be resolved with BDI, offset, or both

137 Object Module Format bits Numeric Value Bank_Ref_Res_Type_Format PLUS Status bank_ref_res_type_format UC Constant 00 S'Unknown' unknown_res_type 020 S'BDI' bdi_res_type 021 S'Offset' offs et _res_t yp e 022 S'BDI_and_Offset' bdi_and_offset_res_type 023 S'LVE' Ive_res_type 024 S'LBN' Ibn_res_type 025 S'Offset_from_LBN' offset from_lbn_res_type 026 S'LBN_and_Offset' lbn_and_offset_res_type 027 S'Entry_Var' entry_var_res_type 030 S'OM_identifier' om_identifier_res_type 031 S'Elt_Info' elt_info_res_type 032 S'SS_Identifier' ss_identifier_res type 033 S'DW_Time' dw_time_res_type 034 S'Entry_VA' entry_va_res_type storage class This field contains the class of storage that the reference expects. This is important when the reference is from the ISP. Since the reference is to the Local Store bank, it is necessary that the definition exist. bits Numeric Value Storage Class_Format PLUS status storage_class_format UC constant 00 S'Unknown' unknown_storage_class 020 S'Eagle_Local' eagle_local_storage_class 021 S'HPSU_or_MSU' hpsu_or_msu_storage_class 022 S'HPSU' hpsu_storage_class 023 S'MSU' msu_storage_class group information valid This field is set to true if the relocation described by this expression consists of repeating the same operation on a number of fields. bits SCS conformance This field is relevant only on references with type = S'Code'. This shows how the routine this reference identifies expects the called routine to conform to the Standard Calling Sequence. S'Undefined' is only defined for old OMs that did not initialize SCS_Conformance to one of the other three values. It is not a valid value for OMs that are currently created

138 Object Module Format Numeric Value PLUS Status scs_conformance_format UC Constant 00 S'Undefined' undefined_conformance 01 S'None' none_conformance 020 S'Loose' loose_conformance 021 S'Strict' strict_conformance Word 01 expression offset The offset within the table of reference p-codes of the first p code of the expression for this reference. Word 02 bits 0-17 expression size This field contains the size (number of bits) that are to be considered as a field to be relocated. bits expression length bit 27 The length of the expression that corresponds to this reference in words, which is the number of words of p-codes. requires gate A condition value that indicates that the reference requires a gate when it is true. The reference will be resolved using the address of the gate. This implies that the target of the reference is a code address and that the resolution type is VA resolution. Word 03 bits 0-5 flat status Indicates whether or not the reference is resolved to an address within the flat data bank. The possible values are as follows

139 Object Module Format Numeric Value Flat_Status_Format PLUS Status flat_status_format UC Constant 00 S'Do_Not_Care' do_not_care_addressing 01 S'Not_Flat' not_flat_addressing 02 S'Flat'' flat_addressing bits 6-11 binding status Indicates whether the reference is resolved to an address within the OM. bits LBN Numeric Value Bank_Ref_Binding_Format PLUS Status bank_ref_binding_format UC Constant 00 S' Undefined' undefined_reference 024 S'Not_Bound' not_bound_reference 025 S'Bound' bound_reference Logical Bank Number (LBN) of the bank making the reference. The following items give information about the field from which the given reference was made. The term Relocation is used here in describing the field because the field is eventually relocated using the value obtained as a result of the resolution of this reference. Word 04 word offset The word offset within the LBN given of the field to be relocated. Word 05 bits 0-17 group size This field is valid if group_info_valid is true and provides the size (in bits) of the field to be relocated. bits18-35 group increment This field contains the size (in bits) of a unit within which a field of grouse bits is to be relocated

140 Object Module Format Word 06 bits 0-5 bit offset This field contains the offset from the base address given (LBN, Offset) of the field to be relocated Bank Text Information The bank text information structure describes the location of the text for a bank. It contains the information required to load, initialize, and relocate the text of the bank. Figure 7 16 shows the Bank Text Information Table. 00 text offset 01 relocation info offset 02 load ACW count relocation ACW count 03 load ACW offset 04 relocation ACW offset Word 00 text offset Figure Bank Text Information The word offset to the beginning of the text for this bank. Word 01 relocation information offset The word offset to the relocation information controlled by the relocation ACWs for this bank. Word 02 bits 0-17 load ACW count The number of Access Control Words (ACWs) for loading the text of this bank. bits relocation ACW count The number of ACWs for relocation of this bank's text

141 Object Module Format Word 03 load ACW offset The word offset from the start of the element to this bank's load ACWs. Word 04 relocation ACW offset The word offset from the start of the element to the relocation ACWs of this bank Access Control Words (ACW) The Access Control Word (ACW) structure is used to control the loading of initialized text for a bank. Figure 7 17 shows a picture of an ACW. 00 word count ACW type 01 bank offset Figure ACW Format The table of load ACW contains the access control words used in loading this bank's text. A variety of ACWs will be available and distinguished by the value of ACW_type. This value can be used like a p-code to extend the capabilities of the ACWs. For example, a value might indicate that a pattern of constants be repeated a number of times. (The ACW will contain the repeat count and a pointer to the pattern.) Word 00 bits 0-29 word count The number of words controlled by this ACW. If this is a Reloc_ACW, then this field contains the number of bits that are relocated by the text controlled by this ACW. In other words, the number of bits in the relocation information. bits ACW type The type of this ACW. This value tells whether the ACW describes a pattern or not. Numeric value Text_Type_Format PLUS Status text_type_format UC Constant 036 S'Pattern' pattern_acw_type 024 S'Normal' normal_acw_type

142 Object Module Format Word 01 bank offset The offset (in words) of the location within the bank to begin the operation described by the ACW Bank Part Entry The bank part entry structure describes the parts of a bank after being merged. Figure 7 18 shows a picture of the Bank Part Entry. 00 size 01 type alignment LBN 02 CB _A * SSD LBN 03 SSD offset 04 bank name offset 05 common bank definition index common bank hash value Figure Bank Part Entry Bank_Part_Entry contains control information and attributes for each bank part. It contains the following fields: Word 00 size The size of the bank part in words when it was first created. Word 01 bits 0-5 type The type of the bank part when it was first created. Numeric Value Bank_Type_Format PLUS Status bank_type_format UC Constant 00 S'Unknown' unknown_bank_type 020 S'Cmn_Blk' crnn_blk_bank_type 021 S'Code' code_bank_type 023 S'Data' data_bank type 024 S'General_Purpose' general_purpose_bank_type 025 S'Link_Vector' link_vector_bank_type

143 Object Module Format Numeric Value Bank_Type_Format PLUS Status 026 S'SDD' sdd_bank_type bank_type_format UC Constant 027 S'Multiple_Types' multiple_types_bank_type 030 S'Info' info_bank_type bits 6-11 alignment The boundary requirements that must be satisfied when creating the bank part. This is the power of two word alignment. Therefore, zero(0) implies word alignment and one(1) implies double word alignment and so on. bits LBN A numeric value that uniquely identifies this bank part within the OM. Word 02 bit 0 CB_A Flagged when the Common Block type is aligned for the ISP. bits SSD LBN The LBN of the SDD information for this bank part. Word 03 SSD offset The offset within SDD_LBN of the SDD information for this bank part. Word 04 bank name offset The offset of the link string form of the symbolic name which was attached to the bank part at the time of its creation within the table of complete names. This name will have the original bank name

144 Object Module Format Word 05 bits 0-17 common bank definition index The index in the table of definitions of a common block definition within this bank part. If none exist then this field is null. This is an 18 bit field. During static linking, a fatal error occurs if the value for this field exceeds bits common bank hash value 7.4. P-codes This field contains a value that was computed using the initial values of all text of the bank. At the time any program requires loading of the common block, this value is compared with values for the common block which appear in other OMs. This checking only takes place if specifically required by the p-code operator that defines the common block. P-codes or Pseudo codes are used by the linking system to represent expressions. They are used to evaluate both references and expressions. Figure 7 19 shows the OM p-code Format. 00 length expression type operation 01 n operand(s) Figure OM p-code format The following fields form a pseudo code (p-code). Length Expression type Operation Operand(s) The Length of the expression in words. The type of the expression. The operation for this expression that is the p-code operator. The optional operands for this expression. Both references and definitions are represented as a series of operations in a pseudo machine language or p-code. Many of the operations are common to both references and definitions but a few are unique to one or the other. The p-codes are accessed differently for references and definitions. For references, they are pointed directly by the unresolved Link Vector. For definitions, there is a structure at a higher level that allows rapid location of the definitions by name. Note: References do not have names; they refer to names

145 Object Module Format Operations can succeed or fail. There are two levels of failure that is hard and soft. A hard failure cannot be tested; the expression fails immediately. Soft failures are normally identical to hard failures. However, if the Enable soft fail p-code immediately precedes an operation that can have a soft failure, then the failure can be detected and reset. Soft failures can also be simulated with the Fail p-code. The pseudo machine is a stack machine. All operations that return a value return it on the stack. Arithmetic operations work on the stack. At the end of processing, the top value on the stack is the value of the expression. For references, the value is patched into the referencing location; for definitions, the value is used as the definition's value. If the soft failure flag is set at the end of expression evaluation then the expression has failed and the value is not patched or used. If the stack is empty after the expression is evaluated, then the expression is in error. If more than one value remains in the stack, the others are ignored and no error occurs. Strings do not appear directly in these p-codes. Instead, the index of the string within the object module is used. Object Module Output Routines (OMOR) users can obtain this value by calling Create_Name P-code Operand Types The following table lists all of the p-code operand types Code Description 1 Fixed Size Constant The constant is 36 bits long. 2 Variable Size Constant The constant size, in bits, and the constant itself are specified. The constant size fills the first word, and the actual constant begins in the next word and continues for as many words as required. 3 Reference Pointer The logical bank number and offset of a reference entry (exact format to be determined). 4 Definition Pointer The offset of a definition name. 5 One Address A single bank-relative address given as a relative pointer with the bit offset, logical bank number and word offset. 6 Two Addresses The first address is a location in a code bank, and the second is a location in a Link Vector Bank. Both are given as relative pointers. 7 4 Level Virtual Address 4 Level Extended Mode VA. 8 2 Level Virtual Address 2 Level Basic Mode VA. 9 8 Level Virtual Address 8 Level Extended Mode VA Level Virtual Address and Latent Parameter 4 Level Extended Mode VA Level Virtual Address and Latent Parameter 2 Level Basic Mode VA Level Virtual Address and Latent Parameter 8 Level Extended Mode VA Link Relative Pointer Link Relative Pointer is another structure used in handling p-codes. A link relative pointer describes a virtual address in terms that are meaningful before execution, namely logical bit offset, logical bank number and word offset

146 Object Module Format A link relative pointer contains the following fields. Bit Bank Offset The bit offset of the item. The logical bank number of the item. The word offset of the item P-code Operators This section describes all the p-code operators and the format of the p-code for each operator. The following table gives the numeric value for each p-code operator. Num P-code Operator 1 Find normal name 2 Find common block name 3 Find normal name in Resolved Name Table 4 Find common block name in RNT 5 Find initialized common block name in RNT 6 Perform incompatibility resolution 7 Check parameters - short 8 Check parameters - long 9 Retrieve definition value 10 Branch on failure 11 Branch on success 12 Branch unconditionally 13 Call p-expression 14 Return 15 Provide value 16 Provide common block name 17 Pop (discard value) 18 Push (duplicate value) 19 Add 20 Subtract 21 Shift left 22 Shift right 23 Truncate value 24 Provide common block value 25 NOP (no operation) 26 Provide definition index: 51 Set failure flag 52 Clear failure flag 53 Enable soft fail 54 Resolve normal name short 55 Resolve normal name long 56 Resolve definition- short

147 Object Module Format Num 57 Resolve definition long P-code Operator 58 Define normal name short 59 Define normal name - long 60 Define common block (referencer) 61 Define common block (user) 62 Define common block (definer) 63 Provide resolve value 64 Provide common block definition value 65 Resolve Heap ID Find Normal Name The library search chain is searched for the specified name. This includes a search of the Resolved Name Table (RNT) and the files, as appropriate. If the name is not found, then a soft failure results. If the name is found, then a pointer to the definition is placed on the top of the stack. In all name search interfaces, the library code name may be a null string. If it is, only the subsystem library search chain is searched. The RNT contains those names that are already known to the Linking System, either because of previous references to them or to another name in their defining object module or because they have been named through explicit definition. 00 length = 3 * operation = 1 (01) 01 name offset (string offset) 02 library code name offset (string offset) Figure Find Normal Name

148 Object Module Format Find Common Block Name The library search chain is searched for the specified common block name. This includes a search of the RNT and the files, as appropriate. If the name is not found, a soft failure results. If the name is found, a pointer to the definition is placed on the top of the stack. 00 length = 3 * operation = 2 (02) 01 name offset (string offset) 02 library code name offset (string offset) Figure Find Common BlockName Find Normal Name in RNT If the name is not found, a soft failure results and the stack is unchanged. If the name is found, the resulting definition pointer is placed on the top of the stack. The effect of searching only the RNT is to find the name if it is already known to the Linking System. The definition found may differ from that found by Find Normal Name if the name is present in two files. 00 length = 3 * operation = 3 (03) 01 name offset (string offset) 02 library code name offset (string offset) Figure Find Normal Name in RNT Find Common Block Name in RNT If the name is not found, a soft failure results and the stack is unchanged. If the name is found, the resulting definition pointer is placed on the top of the stack. The name is only found if the common block has been initialized. 00 length = 2 * operation = 4 (04) 01 name offset (string offset) Figure Find Common Block Name in RNT Find Initialized Common Block Name in RNT If the name is not found, a soft failure results and the stack is unchanged. If the name is found, the resulting definition pointer is placed on the top of the stack. The name is only found if the common block has been initialized. 00 length = 2 * operation = 5 (05) 01 name offset (string offset) Figure Find Initialized Common Block Name in RNT

149 Object Module Format Perform Incompatibility Resolution The interface type specified is compared with the interface type of the counterpart object (that is for definitions it is the reference and for references it is the definition) and appropriate adjustments are made. Depending on values in the incompatibility matrix, a soft failure may result. 00 length = 2 * operation = 6 (06) 01 interface type Figure Find Normal Name Check Parameters Short The parameter description is compared with its counterpart (reference or definition). The parameter hash codes are used in the comparison. If they are incompatible, a soft failure results. 00 length = 3 * operation = 7 (07) 01 relative offset to long description 02 parameter hash code Check Parameters Long Figure Check Parameters Short The parameter description is compared with its long counterpart (reference or definition). If the counterpart used the Check parameters short p-code, the parameter hash code is used; otherwise, the long parameter descriptions are compared. If they are incompatible, a soft failure results. 00 length = 3 * operation = 8 (010) 01 relative offset to long description 02 parameter hash code Figure Check Parameters Long Retrieve Definition Value Determine the value of the definition whose pointer is on top of the stack. This may require creating banks. If the top of the stack is something other than a pointer to a definition, a soft failure results. 00 length = 1 * operation = 9 (011) Figure Retrieve Definition value

150 Object Module Format Branch on Failure If the failure flag is set, clear it and transfer to the given offset. 00 length = 2 * operation = 10 (012) 01 branch target offset from start of expression Figure Branch on Failure Branch on Success If the failure flag is clear, transfer to the given offset. 00 length = 2 * operation = 11 (013) 01 branch target offset from start of expression Branch Unconditionally Always transfer to the given offset. Figure Branch on Success 00 length = 2 * operation = 12 (014) 01 branch target offset from start of expression Call P Expression Not implemented. Figure Branch Unconditionally 00 length = 2 * operation = 13 (015) 01 to be defined Return Figure Call P Expression An expression invoked by Call p-expression~returns using this recode. If this p-code is encountered in an expression that was not invoked by Call p-expression, a hard failure results. 00 length = 1 * operation = 14 (016) Figure Return

151 Object Module Format Provide Value Used to place a constant or program address on the stack. 00 length = 2 expression type operation = 15 (017) 01 value format depends on type Figure Provide Value Provide Common Block Name The common block name is provided for RNT insertion. This is needed for common block definitions because the definition is found by local resolution but must still be placed in the RET. The start address of the common block should already be on the top of the stack; in other words, the common block value operation should precede this one. 00 length = 2 * operation = 16 (020) 01 name offset (string offset) Pop Figure Provide Common Block Name The pop operand on the stack is removed and discarded. A soft failure occurs if the stack is empty. 00 length = 1 * operation = 17 (021) Push Figure Pop A copy of the top operand on the stack is placed on top of the stack. A soft failure occurs if the stack is empty. 00 length = 1 * operation = 18 (022) Add Figure Push The top two operands on the stack are removed from the stack and added. The result is placed on the stack. There may be some type restrictions on arithmetic operands, particularly for the two address type. 00 length = 1 * operation = 19 (023) Figure Add

152 Object Module Format Subtract The top two operands on the stack are removed, the top value is subtracted from the second, and the result is placed on the stack. 00 length = 1 * operation = 20 (024) Shift Left Figure Subtract The operand on top of the stack is shifted left to the specified number of bits. 00 length = 2 * operation = 21 (025) 01 shift count (in bits) Shift Right Figure Shift Left The operand on top of the stack is shifted right to the specified number of bits. 00 length = 2 * operation = 22 (026) 01 shift count (in bits) Truncate Value Figure Shift Right The operand on top of the stack is truncated on the left to the specified number of bits. A hard failure occurs if the truncated bits are not all identical to the highest order remaining bit. This operation can be used to trap errors that occur when a relocated field is actually composed of overlapping subfields. 00 length = 2 * operation = 23 (027) 01 length (in bits) Figure Truncate Value Provide Common Block Value This is similar to the Provide value, where the value (which in this case represents the start of a common block) is placed on the top of the stack. Only single address values are guaranteed to work. When a Provide common block name operation is encountered, the initial values of the common block are checked according to the initial value check level

153 Object Module Format The initial value check level is one of the following 0 None 1 Hash (hash codes are compared) 2 Size (declared sizes are compared) 3 Hash and size (both hash codes and sizes are compared) 00 length = 3 expression type operation = 24 (030) 01 value format depends on type 02 initial value check level NOP No Operation Figure Provide Common Block Value No operation is performed other than incrementing the p-code pointer. This is useful for filling to paging boundaries within expression lists. Length can be any nonzero value. If length is greater than one, the parameter words are also ignored. 00 length = 2 * operation = 25 (031) 01 optional unused parameters Provide Definition Index Figure NOP No Operation The specified definition index is retained. Later provide value operations may provide the value of the definition, but gate processing still requires the definition index. This p- code is intended to use only part of Provide definition value and Provide common block definition value. 00 length = 2 * operation = 26 (032) 01 definition index Set Failure Flag Figure Provide Definition Index The soft failure flag is set. The expression does not fail immediately, that is, there is an implicit Enable soft fail operation. 00 length = 1 * operation = 51 (063) Figure Set Failure Flag

154 Object Module Format Clear Failure Flag The soft failure flag is cleared. 00 length = 1 * operation = 52 (064) Enable Soft Fail Figure Clear Failure Flag If the next p-code generates a soft failure, the expression will not fail immediately. If the next p-code is a macro p-code, then soft failure of a constituent p-code causes immediate soft failure of the macro p-code but not the expression. 00 length = 1 * operation = 53 (065) Figure Enable Soft Fail Resolve Normal Name Short 00 length = 6 * operation = 54 (066) 01 name offset (string offset) 02 library code name offset (string offset) 03 interface type 04 relative offset to long parameter 05 parameter hash code Figure Resolve Normal Name Short This operation obtains the value for a name and does all required checks. The result is left on top of the stack. This p-code and the next p-code are expected to be the most commonly used. Soft failures can result from any of the following: name not found parameter check failure incompatibility resolution failure The operation consists of the following p-codes: Find normal name Resolve definition short All parameters after the name pointer can be omitted. If a parameter is absent, no subsequent parameters can be present. The length field is used to determine which parameters are present

155 Object Module Format Resolve Normal Name Long 00 length = 6 * operation = 55 (067) 01 name offset (string offset) 02 library code name offset (string offset) 03 interface type 04 relative offset to long parameter 05 parameter hash code Figure Resolve Normal Name Long This operation is identical to Resolve normal name short except that it invokes long parameter checking instead of short. The result is left on top of the stack. The operation contains the following p-codes: Find normal name Resolve definition long Soft failures can result from any of the following: name not found parameter check failure incompatibility resolution failure This operation deliberately has the same format as Resolve normal name short to make it easy to change one to the other Resolve Definition Short 00 length = 4 * operation = 56 (070) 01 interface type 02 relative offset to long parameter 03 parameter hash code Figure Resolve Definition Short This operator determines a value for the definition on top of the stack. This standard operation performs the following functions: Performs incompatibility resolution. Checks parameters short. Retrieves definition value

156 Object Module Format Resolve Definition Long 00 length = 4 * operation = 57 (071) 01 interface type 02 relative offset to long parameter 03 parameter hash code Figure Resolve Definition Long This operator determines a value for the definition on top of the stack. This standard operation performs the following functions: Performs incompatibility resolution. Checks parameters long. Retrieves definition value Define Normal Name Short 00 length = 5 expression type operation = 58 (072) 01 value format depends on type 02 interface type 03 relative offset to long parameter 04 parameter hash code Figure Define Normal Name Short This p-code is normally used for defining addresses (constants need only the Provide value operation). The standard program performs the following functions: Performs incompatibility resolution Checks parameters short Provides value Define Normal Name Long 00 length = 5 expression type operation = 59 (073) 01 value format depends on type 02 interface type 03 relative offset to long parameter 04 parameter hash code Figure Define Normal Name Long

157 Object Module Format This p-code is normally used for defining addresses (constants need only the Provide value operation). The standard program performs the following functions: Performs incompatibility resolution Checks parameters long Provides value Define Common Block (Referencer) A referencer common block has a definition of the common block available, but searches for another definition of the common block before using its own. This operation performs the following tasks: Enables soft failure Finds common block name in RNT If found, provides common block value (checking initial values) to end of expression Enables soft failure Finds common block name If found, retrieves definition value Defines common block (definer) A definition containing a Define Common Block (referencer) p-code is not externally visible; instead, it is found through local resolution. This is typically used where initial values are present, but there may be another initial value definition as in a FORTRAN COMMON block with initial values (there may be a BLOCK DATA subprogram). This definition will be attached to the bank containing the common block as the cmn_blk_def attribute and will not be of type cmn_blk. The meaning and values for Initial value check level can be found with the definition of Provide common block value. 00 length = 5 * operation = 60 (074) 01 name offset (string offset) 02 library code name offset (string offset) 03 value single address type 04 initial value check level Figure Define Common Block (Referencer) Define Common Block (User) A user common block definition type is used if the program using the common block has no initial values. The program uses an initialized version of the common block if one exists, but if it does not exist, then it will not search for other programs

158 Object Module Format This operation performs the following tasks: Enables soft failure Finds common block name in RNT If success, retrieves definition value end Defines common block (definer) A definition containing a Define Common Block (user) p-code is not externally visible; instead, it is found through local resolution. It will be attached to its bank as the cmn_blk_def attribute. 00 length = 4 * operation = 61 (075) 01 name offset (string offset) 02 value single address type 03 initial value check level Figure Define Common Block (User) Define Common Block (Definer) A definer common block definition is intended for applications such as the FORTRAN BLOCKDATA subprogram. In these cases, the common block is defined in a separate program from any references to it. The definition is found by a referencer or user definition. The definer definition program is: Provide common block value Provide common block name A definition containing a Define common block (Definer) operation is externally visible. The name pointer should point to the same name as that of the definition. The definition should be type 'cmn_blk' and should be pointed by its bank's attributes. 00 length = 4 * operation = 62 (076) 01 name offset (string offset) 02 value single address type 03 initial value check level Figure Define Common Block (Definer)

159 Object Module Format Provide Resolve Value Used to place a constant or program address on the stack. Used when the constant or address is derived from a definition. This consists of: Provide definition index Provide value 00 length = 3 expression type operation = 63 (077) 01 definition index 02 value format depends on type Figure Provide Resolve Value Provide Common Block Definition Value Used to place a common block start address on the stack. Restrictions are similar to the Provide common block name. This is defined as: Provide definition index Provide common block value 00 length = 3 expression type operation = 64 (0100) 01 definition index 02 value format depends on type Figure Provide Common Block Definition Value Resolve Heap ID The first operand contains the offset of the heap name in the complete name table. 00 length = 2 * operation = 65 (0101) 01 heap ID name offset (string offset) Figure Resolve Heap ID

160 Object Module Format

161 Section 8 Program File Format A file is an organized collection of data that is stored and manipulated as a unit with a unique name. A program file is a structured file that allows random access to the elements it contains. An element is a named grouping of information that is manipulated as a unit within the program file. A program file can be created as either a temporary or cataloged mass storage file. A program file can be assigned as either a sector-addressable mass storage file or a sector-addressable memory file. There are three basic program file formats: The standard program file, referred to as a PF, has small, variable length tables. It has a normal maximum capacity of 2,671 elements that can be expanded to 5,000 elements. Each element may have a maximum of 262,143 sectors of element text data. The large program file, referred to as an LPF, has large, fixed length tables. It has a fixed maximum of 26,146 elements. Each element may have a maximum of 262,143 sectors of element text data. The large element program file, referred to as an LEPF, can be initialized with the small, variable length format of a standard program file (standard LEPF) or with the large, fixed length format of a large program file (large LEPF). The main difference from a PF or LPF is that LEPF element text length is limited only by the maximum size of the file. LEPF elements can have over 262,143 sectors of text, if desired. There are two interfaces available for OS 2200 software and user programs to access program files: The Exec program file package (PFP) Executive requests (ERs) The SYSLIB basic service package (BSP) functions The standard program file can be created, accessed and updated by the PFP and BSP interfaces. The large program file can be created only by the BSP interface and can be accessed and updated by the PFP and BSP interfaces. The large element program file can be created, accessed and updated only by the BSP interface (see 7.1)

162 Program File Format There are four general types of elements: Symbolic Relocatable Executable Omnibus The symbolic element type includes procedure type elements. The executable element type includes absolute elements and object module elements. The standard program file and the large program file can contain any combination of these element types. The large element program file can currently contain only symbolic elements (other than procedure type symbolic elements) and omnibus elements. Elements in the program file can be marked to be deleted. The elements are not removed until the program file is rewritten with the File Utility Routines/Program File Utility Routines statement or Program-Callable FURPUR (PCFP) PACK_PF function or copied to another file with the statement or PCFP COPY_ELT function. Deleted elements can be undeleted with the PCFP UNDELETE_ELT function. While the program file is structured as shown in Figure 7 1, the tables that physically make up the file are not necessarily contiguous. Links are automatically generated to logically structure the file as a continuous entity. The program file is composed of three major parts: File table index (FTI) See 7.4. Table of contents (TOC) Element table Assembler procedure table (APT) COBOL procedure table (CPT) FORTRAN/PLUS procedure table (FPPT Relocatable element entry-point table (REEPT Element text area The element, procedure, and entry-point tables are sometimes referred to as the TOC tables. The common format of the TOC tables is described in 7.5, and the format of the table items is described in 7.6, 7.7, and 7.8. The program file may also contain an object module entry-point table (OMEPT); it is located in the element text area, not in the TOC. The procedure tables are created by the Procedure Definition Processor (PDP) and are retained by FURPUR and PCFP during copy operations

163 Program File Format The REEPT and OMEPT are created by the statements and PCFP PREP_PF function. Figure 7 1 shows the structure of the program file. The program file TOC tables, if present, are always in the order shown. The element table is always present if there are entries in the file. Figure 8 1. Program File Structure There are three variations of the basic program file structure shown in Figure 8 1. The first two variations apply to the standard program file (PF) and to the standard LEPF. The third variation applies to the large program file (LPF) and the large LEPF. Standard program file BSP or PFP can create the default PF format from an empty file. BSP, the command or the PCFP CHG_FILE function can create the standard LEPF format from an empty file. The program file structure attempts to optimally use the file space by allowing a varying number of tables and table entries. See 8.1 for a complete description. Minimum program file The command can rewrite a PF or a standard LEPF to minimize the size of the element table and the three procedure tables and to maximize the size of the relocatable element entry point table. See 8.2 for a complete description. Large program file BSP, the command or the PCFP CHG_FILE function can create the LPF format from an empty file. BSP, the command or the PCFP CHG_FILE function can create the large LEPF format from an empty file. The program file structure allows a large, fixed number of tables and table entries. See 8.3 for a complete description. See 8.10 for the number of entries that can be made in the program file under various conditions

164 Program File Format 8.1. Standard Program File The characteristics of the standard program file are as follows: Default standard program file is identified by the Fieldata characters '**PF**' in word 0 of the file. Standard LEPF is identified by the Fieldata characters '*LEPF*' in word 0 of the file and by a size indicator value of 0 in the file table index (see 7.4.1). The FTI contains table descriptors with information about each table. A table does not exist until the starting sector has been set in the table descriptor. When a file is initialized as a program file, the length and starting sector of each table are set to zero in the table descriptors. The element table always starts at a fixed sector. The APT, CPT, FPPT, and REEPT start at the system-defined sector for the table or at a greater sector if the previous table has extended beyond the system-defined starting sector for the table. A table can expand until it encounters the start of the next table or the start of the element text area. The element table is the first table in the TOC and the space allocated for the element table cannot be overlaid by another table provided the program file has not been rewritten with the statement (see 8.2). The element table is the only table for which there are a fixed number of allowable entries. If the element table is expanded to the start of element text area, no entries can be made in any other TOC table. If the assembler procedure table is expanded to the start of the element text area, no entries can be made in the COBOL procedure table, the FORTRAN/PLUS procedure table, or the REEPT. If the COBOL procedure table is expanded to the start of the element text area, no entries can be made in the FORTRAN/PLUS procedure table and the REEPT. If the FORTRAN/PLUS procedure table is expanded to the start of the element text area, no entries can be made in the REEPT

165 Program File Format Figure 8 2 shows the program file format. Although Figure 8 2 shows all of the TOC tables, only the element table is always present if there are entries in the file. The relative sectors are shown on the left side of the table format. 0 file table index (FTI) element table assembler procedure table (APT) COBOL procedure table (CPT) FORTRAN/PLUS procedure table (FPPT) relocatable element entry-point table (REEPT) element text area includes object module entry-point table (OMEPT) Figure 8 2. Program File Format Notes: Figure 8 2 gives the starting sector for each program file table if the table starts at the system-defined sector for the table. The actual starting sectors can be greater than shown in Figure 8 2 except for the element table, which always starts at sector 1, and the element text area, which starts at sector The tables and the element text area will not start at a relative sector address that is less than the sector address shown unless the program file has been rewritten with the statement (see 8.2). An exception to the above rule is when the REEPT is created by the PCFP PREP_PF function. In this case, the starting sector is set so that the table ends at sector 1791, just before the starting sector of the element text area. The starting sector can be less than the default sector address 1344 shown, as long as it is after the end of the highest table present in the Table of Contents. The FTI and the five tables are allocated the first 28 tracks (50,176 decimal words) of the program file

166 Program File Format If each table starts at its system-defined sector, then the maximum lengths of the tables are as follows: Tracks Sectors Words Tables sectors Element table Assembler procedure table COBOL procedure table FORTRAN/PLUS procedure table Relocatable element entry-point table The actual table lengths can be greater than or less than the system-defined lengths listed above. The table lengths listed apply only if an entry is made in each table before a previous TOC table expands beyond the starting sector of the table Minimum Program File The statement is used to rewrite a standard program file to minimize the file space when there is no requirement to add more entries to the program file. The result of operation is a program file with a minimum-length TOC. The statement is also used to provide sufficient space in the program file to create an REEPT for all undeleted relocatable elements in the element table. The statement is ignored for the large program file because of the fixed format of the TOC tables. Each table with entries is started at the next sector immediately following the previous table with entries. The element text area is started at the first track not being used for the REEPT unless the REEPT is not created by specifying the D option on statement. If there are no procedure tables and an REEPT is created, only 1 to 4 elements can be added to the file. If there are no procedure tables and an REEPT is not created, only 1 to 179 elements can be added to the file, because the start-of-element text is set at the next track boundary after the last entry in the element table. If any of the procedure tables have entries, only 1 to 4 elements can be added to the program file. Figure 8 3 shows an example of a standard program file after it has been rewritten by the command. This figure assumes that the program file contained one symbolic element and one relocatable element and that the relocatable element contained less than 358 relocatable entry points before command. The relative sectors are shown on the left side of the table format

167 Program File Format 0 file table index (FTI) element table relocatable element entry-point table (REEPT) symbolic element text relocatable element text Notes: Figure 8 3. Program File Example After operation, the REEPT starts at sector 8 and the element text area starts at sector 64. There are no procedure tables and none can be created. Only three elements can be added to the file. For a description of statement, see the Executive Control Language (ECL) and FURPUR Reference Manual Large Program File The large program file (LPF) is identified by the ASCII characters '*LPF' in word 0 of the file. The large LEPF is identified by the Fieldata characters '*LEPF*' in word 0 of the file and by a size indicator value of 4 in the file table index (see 8.4.2). The large program file expands the space allocated to the tables, to the maximum allowable size within the confines of the present program file structure, except for the REEPT. BSP, the command or the PCFP CHG_FILE function creates the LPF from an empty file. BSP, the command or the PCFP CHG_FILE function creates the large LEPF from an empty file. When a file is initialized in the fixed-length table format, the starting sector of each table and the start of the element text area are set in the FTI. The length of each table is set to zero in the FTI. A nonzero table length indicates that the table has entries. Each table has a fixed, maximum number of allowable entries (see 8.10). See for a specific description of the initialization of a large program file

168 Program File Format Figure 8 4 shows the large program file format. The relative sectors are shown on the left side of the table format. 0 file table index (FTI) Element table.. assembler procedure table (APT).. COBOL procedure table (CPT).. FORTRAN/PLUS procedure table (FPPT).. relocatable element entry-point table (REEPT) element text area includes object module entry-point table (OMEPT) Notes: Figure 8 4. Large Program File Format Figure 8 4 gives the starting sector for each of the large program file tables. The FTI and the five tables are allocated the first 629 tracks (1,127,168 decimal The lengths of the tables are as follows: Tracks Sectors Words Tables sectors Element table Assembler procedure table COBOL procedure table FORTRAN/PLUS procedure table Relocatable element entry-point table

169 Program File Format If the REEPT was allowed to expand to a maximum length of 146 tracks (65,373 entries), then the start of element text area would be sector 46,720 decimal. This maximum length REEPT is not implemented at this time. The 45-track (80,640 word) limit on the REEPT is imposed by the PCFP PREP_PF function File Table Index The FTI is the control structure for the program file. It identifies the file and contains information about the file, the tables, and the element text area. The FTI is located in sector 0 of the file, and word 0 of the FTI identifies the file as a program file. Word 0 of the FTI is also word 0 of the file. The FTI contains 3-word table descriptors for each table that give the starting sector of the table, length of the table, length of the pointer table, and length of the table items. The starting sector of the table is relative to the start of the file. A table does not exist until there is a starting sector for the table in the table descriptor. In the variable-length table format, the starting sector of table is set when the table is initialized and cleared when the table no longer has any entries or is invalidated. In the fixed-length table format, the starting sector of table is set when the file is initialized as a large program file and remains set as long as the file exists. To determine if a table exists, check the starting sector of table field in the table descriptor. IF starting_sector_of_table EQUALS zero THEN the table does not exist To determine if there are any entries in a table, compare the length of table with the length of pointer table in the table descriptor. IF length_of_table LESS-THAN-OR-EQUAL length_of_pointer_table THEN the table is empty Note: The length of pointer table should always be obtained from the table descriptor and never used as a hard-coded value since the program file design allows for the length of pointer table to change with files and tables within a file. The FTI for the variable-length table format standard program file is described in 8.4.1, and the FTI for the fixed-length table format large program file is described in The two FTI formats have the same structure; only the content of some fields is different

170 Program File Format File Table Index Format Figure 8 5 describes the format of the FTI for the variable-length table format program file program file identifier 01 next sector available for writing element text 02 run-id (used by CTS and IPF) 03 zero starting sector of element table 04 length of element table zero 05 length-1 of pointer table 06 zero 07 length of table item length of assembler procedure table in words 010 length-1 of pointer table 011 zero 012 length of table item length of COBOL procedure table in words 013 length-1 of pointer table 014 zero 015 length of table item length of FORTRAN/PLUS procedure table in words 016 length-1 of pointer table 017 zero 020 length of table item length of relocatable element entry-point table in words zero starting sector of assembler procedure table (APT) zero zero starting sector of COBOL procedure table (CPT) zero zero starting sector of FORTRAN/PLUS procedure table (FPPT) zero zero starting sector of relocatable element entry-point table (REEPT) zero Figure 8 5. File Table Index Format

171 Program File Format length-1 of pointer table length of table item zero 022 length of largest preamble in relocatable element in sectors revision level size indicator new rel elt flag 023 zero 024 starting sector of element text area sequence number of latest executable element in file 025 starting word of object module entry-point table (OMEPT) 026 zero OMEPT next write location 027 OMEPT information zero 030 zero 031 zero 032 zero 033 time in milliseconds past midnight (used by CTS and IPF) Figure 8 5. File Table Index Format (cont.) When BSP or PFP creates the default PF format from an empty file, the FTI contains the following information: FTI Word 00 The identifier **PF**. FTI Word 01 The next sector for writing element text. FTI Word 022 (bits 18 23) The revision level of 0. FTI Word 022 (bits 24 29) The size indicator of 0. FTI Word 024 The starting sector of element text. When BSP, the command, or the PCFP CHG_FILE function creates the standard LEPF format from an empty file, the FTI contains the following information: FTI Word 00 The Fieldata identifier '*LEPF*'. FTI Word 01 The next sector for writing element text. FTI Word 022 (bits 18 23) The revision level of 1. FTI Word 022 (bits 24 29) The size indicator of 0. FTI Word 024 The starting sector of element text

172 Program File Format All other fields in the FTI are zero. The sector locations of the tables and text are relative to the start of the file. The lengths are in words unless sectors are specified. The following words describe the fields in the FTI: Word 00 Bits 0 35 program file identifier Word 01 Bits 0 35 For the default PF format, contains the characters '**PF**' in Fieldata (octal ). The identifier is defined by the system constant PF$ID. For the standard LEPF format, contains the characters '*LEPF*' in Fieldata (octal ). The identifier is defined by the system constant LEPF$ID. next sector available for writing element text Word 02 Bits 0 35 run-id This field must always be updated after an element has been added to the program file. With the Exec PFP, this is done by calling ER PFUWL$ or ER PFI$ with the new write location. With the SYSLIB BSP, updating is done at the next write location in the BSP file control table (FCT). A run-id used by Conversational Time Sharing (CTS) and the Interactive Processing Facility (IPF 1100). Word 03 Word 05 The 3-word descriptor for the element table. Word 06 Word 010 The 3-word descriptor for the APT. Word 011 Word 013 The 3-word descriptor for the CPT. Word 014 Word 016 The 3-word descriptor for the FPPT

173 Program File Format Word 017 Word 021 The 3-word descriptor for the REEPT. The REEPT is created by the PCFP PREP_PF function and the statements. When a relocatable element table item is inserted or deleted, the REEPT is invalidated by setting the starting sector of REEPT field in the 3-word table descriptor to zero. The length of REEPT field should also be set to zero, but the starting sector of REEPT field must be set to zero to invalidate the REEPT. Word 022 Bits 0 17 length of largest preamble in relocatable element Bits The sector length of the largest preamble from the undeleted relocatable elements in the program file. revision level Bits The revision level for the program file format. The revision level is incremented if the format of the program file changes. For the default PF format, the current revision level is zero. The revision level is defined by the system constant PF$LEVEL0. For the standard LEPF format the current revision level is 1. The revision level is defined by the system constant LEPF$LEVEL1. size indicator Bits Defines the size and format of the program file TOC. This field is 0 for the program file. For size 0, the program file size is initialized in variable-length table format with 28-track TOC. For the default PF format and the standard LEPF format the size indicator is zero. new relocatable element flag The new relocatable element flag. This field is set to nonzero when a relocatable element table item is added to the program file. This field is cleared when an absolute element table item is added to the program file. The purpose of this flag is to allow the automatic recollection of relocatable elements in the file TPF$ for statement if new relocatable elements have been added to the file TPF$ since the last absolute element was added to the file TPF$

174 Program File Format Word 023 Bits 0 17 reserved Bits Set to zero. sequence number of latest executable element in file Word 024 Bits 0 35 The sequence number of the last executable element added to the program file. Zero if there are no executable elements in the program file, or if the last executable element added to the file is marked as deleted. starting sector of element text area Word 025 Bits 0 35 The sector, relative to the start of the file, at which the element text area starts. starting word of object module entry-point table (OMEPT) Word 026 Bits 0 17 The word, relative to the start of the file, at which the OMEPT starts. Reserved Bits Set to zero. OMEPT next write location The value of next sector available for writing element text at the time the OMEPT was created

175 Program File Format Word 027 Bits 0 17 OMEPT information Bits General information describing attributes (for example, block size) of the OMEPT. Reserved Set to zero. Word 030 Word 032 Bits 0 35 reserved Word 033 Bits 0 35 These 3 words are reserved and set to zero. time in milliseconds past midnight The time in milliseconds past midnight value from ER TIME$ that is used by CTS and IPF. The 3-word table descriptor in the program file FTI does not contain any information until PFP or BSP makes an entry in the table. The table descriptor contains the following information: Starting sector of table This field is initially set to zero. When an entry is made in a table, this field is set to the system-defined starting sector for the table or to a higher sector if the previous table has extended beyond the system-defined starting sector for the table. The system-defined starting sector is always used for the element table because the element table is the first table in the TOC. This field is set to zero when there are no longer any entries in the table or the table must be invalidated. Length of table This field is in words and is initially set to zero. When a table is created, this field is set to the length of the pointer table and then incremented by the length of table item field each time an entry is made in the table. This field is set to zero when there are no longer any entries in the table or the table must be invalidated. The length of a table is limited to decimal words because of the 18-bit field

176 Program File Format (Length 1) of pointer table This field is in words and is set to the system defined pointer table length 1 for the table. The system-defined pointer table length is currently 5 sectors (140 decimal words) and is the same for the five TOC tables. The program file design allows for the pointer table length to be changed. The pointer table length must always be obtained from the table descriptor in the FTI and never hard-coded in a program since it may change. Length of table item This field is in words and is set to the system-defined table item length for the table. The table item length must always be obtained from the table descriptor in the FTI or the last word of the pointer table and never hard-coded in a program since it may change Large Program File FTI Format Figure 8 6 describes the format of the FTI for the fixed-length table format large program file program file identifier 01 next sector available for writing element text 02 run-id (used by CTS and IPF) 03 zero starting sector of element table 04 length of element table zero 05 length-1 of pointer table 06 zero 07 length of table item length of assembler procedure table in words 010 length-1 of pointer table 011 zero length of table item zero starting sector of assembler procedure table (APT) zero zero starting sector of COBOL procedure table (CPT) 012 length of COBOL procedure table in words zero 013 length-1 of pointer table 014 zero 015 length of table item length of FORTRAN/PLUS procedure table in words 016 length-1 of pointer table 017 zero length of table item Figure 8 6. Large Program File FTI Format zero starting sector of FORTRAN/PLUS procedure table (FPPT) zero zero starting sector of relocatable element entry-point table (REEPT)

177 Program File Format length of relocatable element entry-point table in words length-1 of pointer table length of table item length of largest preamble in relocatable element in sectors 023 zero revision level zero zero size indicator new rel elt flag sequence number of latest executable element in file 024 starting sector of element text area 025 starting word of object module entry-point table (OMEPT) 026 zero OMEPT next write location 027 OMEPT information zero 030 zero 031 zero 032 zero 033 time in milliseconds past midnight (used by CTS and IPF) Figure 8 6. Large Program File FTI Format (cont.) When BSP, the command, the command or the PCFP CHG_FILE function creates a large program file (LPF or large LEPF) from an empty file, the FTI contains the following information: FTI Word 00 For an LPF the ASCII identifier '*LPF' and for a large LEPF the Fieldata identifier '*LEPF*'. FTI Word 01 The next sector for writing element text. FTI Words 03, 06, 011, 014, 017 The starting sector of table. FTI Words 05, 010, 013, 016, 021 (bits 0 11) The length of pointer table-1. FTI Words 05, 010, 013, 016, 021 (bits 12 17) The length of table item. FTI Word 022 (bits 18 23) The revision level of 1. FTI Word 022 (bits 24 29) The size indicator of 4. FTI Word 024 The starting sector of element text. All other fields in the FTI are zero. The sector locations of the tables and text are relative to the start of the file. The lengths are in words unless sectors are specified

178 Program File Format Only the fields that differ from Figure 7 5 are described below: Word 00 Bits 0 35 program file identifier Word 022 Bits For the LPF format, contains the characters '*LPF' in ASCII (octal ). The identifier is defined by the system constant LPF$ID. For the large LEPF format, contains the characters '*LEPF*' in Fieldata (octal ). The identifier is defined by the system constant LEPF$ID. revision level Bits For the LPF format the current revision level is 1. The revision level is defined by the system constant LPF$LEVEL1. For the large LEPF format the current revision level is 1. The revision level is defined by the system constant LEPF$LEVEL1. size indicator Defines the size and format of the program file TOC. The size indicator is set to 4 for the large program file. This indicates the file is initialized in fixed-length table format with a 629-track TOC Program File Tables The program file table format (including the pointer table) is common to the five program file TOC tables: element table, APT, CPT, FPPT, and REEPT. The common program file table format applies to both the program file (see 8.1) and the large program file (see 8.3). This common format does not apply to the OMEPT (see 8.9). Each TOC table contains a pointer table with pointers to the entries in the table. The entries in the table are called table items. The table items point to information in the element text area

179 Program File Format Figure 8 7 describes the format of the program file tables. The relative sectors are shown on the left side of the table format pointer or zero pointer or zero 01 pointer or zero pointer or zero 02 pointer or zero pointer or zero pointer or zero pointer or zero 0212 pointer or zero pointer or zero 0213 length of table item (words) number of items in table.. table item (sequence number 1).. table item (sequence number 2).. table item (sequence number 3) table item (sequence number nnnnn) Figure 8 7. Program File Table Format (Including Pointer Table)

180 Program File Format The pointer table is located at the start of the program file table. The length of the pointer table is contained in the field length 1 of pointer table in the table descriptor for the table in the FTI (see Figure 8 5 and Figure 8 6). The first 139 words of the pointer table contain pointers to the start of a chain of table items. The table items that belong to a particular chain are determined by dividing the sum of the words containing the name in the table item by the length of the pointer table (139 words) and using the remainder as an index into the pointer table. A total of 278 chains can exist, because each word contains two pointers; the pointer in bits 0 17 of the word is used if the quotient was odd, and the pointer in bits of the word is used if the quotient was even. The last word of the pointer table is a control word that contains the length of a table item in bits 0 17 and the number of table item entries in the table in bits The length of table item field in the pointer table control word is the same as the length of table item field in the FTI table descriptor for the table. The number of items in table field is incremented each time an entry is added to the table and includes items marked to be deleted The sequence number is the order in which table items are entered in the table. The sequence number of the first item entered in the table is 1, the sequence number of the second item entered in the table is 2, and so on. The sequence number for the first table item in a chain is stored in the pointer half-word that is calculated as described above. The sequence number is also used in succeeding table items to link them to other table items in the chain. When two or more table items are pointed to from the same pointer half-word in the pointer table, chains are formed and linked with pointers within the table items. See 8.6, 8.7, and 8.8 for a description of the table item links. Note: To maximize performance when using large numbers of elements in a single program file of any type, give each element a unique name. A unique name is one that does not have the same index into the pointer table. This ensures an even distribution of names in the pointer table, resulting in compact search chains. In the worst-case scenario, if each element had the same index into the pointer table (e.g. see Notes under Figure 8 13 in regarding selecting COB0L procedure names), all the elements would be chained to a single pointer table pointer. The table items start in the word following the pointer table control word. Each table item is written to the file in the ascending order in which it was added to the table. The following process could be used to find an entry in the element table: Given that each half-word in the element table pointer table contains zero or the sequence number of an element table item, an element entry is found by adding the two halves of the element name together and dividing the result by the length of the table, which is obtained from word 05 (bits 0 11) of the FTI. The remainder of the division in this algorithm is used as an index into the pointer table. If the quotient is odd, the sequence number in bits 0 17 of the word is used. Otherwise, the sequence number in bits is used

181 Program File Format Subtract 1 from the sequence number and multiply the result by the element table item length from word 05 (bits 12 17) of the FTI. The result is the word location of the table item relative to the start of the element table items. The element item pointed to can contain pointers to the element being searched for or links to other element table items. If a link is found to be zero before the element is found, the element is not in the file and a status of no find is returned Element Table This section describes the element table items for the symbolic, relocatable, executable, and omnibus element types. The following values for the element types are defined: 00 Undefined (reserved) 01 Symbolic (SYM) 02 Assembler procedure (ASMP) 03 COBOL procedure (COBP) 04 FORTRAN procedure (FORP) 05 Relocatable (REL) 06 Executable (Absolute) 07 Omnibus (OMN) The symbolic element (type 1) and the procedure element (types 2, 3, and 4) have the same table item format. A symbolic PLUS procedure (PSP) element (type 1 subtype 29) is treated the same as a FORTRAN procedure element (type 4). Procedure element types 2, 3, and 4 are defined as symbolic elements (type 1) in structure and content. Therefore, element types 1, 2, 3, and 4 with the same element name and version name will match on a search of the TOC. This means that element types 1, 2, 3, and 4 cannot have the same element name and version name and all be undeleted. For example, if an element of type 1 exists in the file and an element of type 2 with the same element name and version name is added to the file, the existing element with the same name will be marked as deleted. When searching for both deleted and undeleted elements, only the first element (usually the lowest sequence number) with the same element name and version will be found. The large element program file can currently contain only symbolic elements (type 1) and omnibus elements (type 7). Procedure elements (type 1, subtype 29 and types 2, 3 and 4), relocatable elements (type 5) and executable elements (type 6) are not currently allowed in an LEPF. The table item formats for the different element types are the same except for word 06 and word 07. See Figure 8 8, Figure 8 9, Figure 8 10, and Figure

182 Program File Format The flag bits in word 03 (bits 0 11) of the element table item are defined by element type. Some flag bits have a common definition for all element types, and other flag bits are defined for a specific element type. See Figure 8 8, Figure 8 9, Figure 8 10, and Figure 8 11 and the descriptions for word 03 of the table items. Here is the hierarchy of links within the element table: 1. Pointer link Sequence number of another element table item with the same pointer table index (hash code), but a different element name. 2. Element type link Sequence number of another element table item with the same element name, but with a different element type. 3. Version name link Sequence number of another element table item with the same element name and element type, but with a different version name or the same version name marked as deleted Symbolic Element Table Item Figure 8 8 describes the format of the 10-word table item for symbolic elements (element types 1, 2, 3, and 4). Procedure elements (type 1, subtype 29 and types 2, 3 and 4) are not currently allowed in an LEPF element name 02 version link pointer link 03 flag bits element type type link version name 06 cycle limit latest cycle number current number of cycles 07 element subtype length of element text 010 sector location of element text 011 time element added date element added (month, day, year) Figure 8 8. Symbolic Element Table Item

183 Program File Format Word 00 Word 01 Bits 0 35 element name The element name in Fieldata characters, left-justified and space-filled. Word 02 Bits 0 17 version link See 8.6 for a description of the version name link. Bits pointer link See 8.6 for a description of the pointer link. Word 03 Bits 0 11 flag bits The following bit definitions apply to element types 1, 2, 3, and 4: 0 Table item is marked as deleted. 1 2 Element text length granularity. For a PF or LPF this field is not used and should be zero. For an LEPF this field contains the granularity of the length of element text field in word 07 and can have the binary values: 00 Element text length is in number of sectors. 01 Element text length is in number of tracks. A track contains 64 sectors. 10 Element text length is in number of positions. A position contains 64 tracks or 4,096 sectors. 11 Reserved and currently illegal

184 Program File Format Word 03 Bits Zero 4 Zero 5 Arithmetic fault noninterrupt mode 6 Arithmetic fault compatibility mode 7 ASCII character set 8 Contains kanji characters 9 Third-word sensitive 10 Quarter-word sensitive 11 Marked in error element type The following values for the element types are defined: 01 Symbolic (SYM) 02 Assembler procedure (ASMP) 03 COBOL procedure (COBP) 04 FORTRAN procedure (FORP) Note: A PLUS procedure (PSP) element (type 1, subtype 29) is treated the same as a FORTRAN procedure (FORP) element (type 4). Bits type link See 8.6 for a description of the element type link. Word 04 Word 05 Bits 0 35 version name The version name in Fieldata characters, left-justified and space-filled

185 Program File Format Word 06 The symbolic element cycle word. Bits 0 11 cycle limit Bits The maximum number of element cycles retained in the symbolic element. This field is initially set to the element cycle maximum value defined by the system constant CYCLIM$ in element SYS$DEF. CYCLIM$ is currently 5. latest cycle number Bits This field starts at zero and is the highest element cycle number that exists in the symbolic element. current number of cycles Word 07 Bits 0 5 Starts at 1 (the first element cycle is cycle 0). element subtype Bits 6 35 The symbolic and omnibus element subtype codes are defined in the system library element SSTYP$. See the SYSLIB Programming Reference Manual for a list of the element subtype codes. length of element text For a PF or LPF bits 6 17 are not used and should be zero. Bits contain the length of the element text in sectors. This allows a maximum of octal or 262,143 decimal sectors of element text. For an LEPF bits 6 35 contain the length of the element text. Word 03 flag bits 1 2 specify the granularity of this value (sectors, tracks or positions)

186 Program File Format Word 010 Bits 0 35 sector location of element text Word 011 Bits 0 17 The sector location, relative to the start of the file, of the element text. time element added Bits The time the element was created or added to the program file. The time is in seconds past 2400 (ER TDATE$ format). date element added The month, date, and year the element was created or added to the program file (ER TDATE$ format). Bits are defined as follows: Bits month Bits day Bits year Value is 1 to 12. Value is 1 to 31. Current year is obtained by adding 1964 to this value

187 Program File Format Relocatable Element Table Item Figure 8 9 describes the format of the 10-word table item for relocatable elements (element type 5). Relocatable elements are not currently allowed in an LEPF element name 02 version link pointer link 03 flag bits element type type link version name 06 sector location of preamble to relocatable element 07 length of preamble length of relocatable text 010 sector location of element text 011 time element added date element added (month, day, year) Figure 8 9. Relocatable Element Table Item Note: The description of Figure 8 9 is the same as for Figure 8 8 except for word 03 (bits 0 11), word 03 (bits 12 17), word 06, and word 07. Word 03 Bits 0 11 flag bits The following bit definitions apply to element type 5: 0 Table item is marked as deleted. 1 Zero 2 Zero 3 Zero 4 Zero 5 Arithmetic fault noninterrupt mode 6 Arithmetic fault compatibility mode 7 Zero 8 Zero 9 Third-word sensitive 10 Quarter-word sensitive 11 Marked in error

188 Program File Format Word 03 Bits element type 05 relocatable (REL) Word 06 Bits 0 35 sector location of preamble to relocatable element Word 07 Bits 0 17 The sector location, relative to the start of the file, of the preamble to the relocatable element. length of preamble Bits The length of the preamble to the relocatable element in sectors. length of relocatable text The length of the relocatable text in sectors

189 Program File Format Executable Element Table Item Figure 8 10 describes the format of the 10-word table item for executable elements (element type 6). Executable elements are not currently allowed in an LEPF element name 02 version link pointer link 03 flag bits element type type link version name 06 (content varies by subtype, see below) 07 element subtype element sub-subtype ZOOM header 010 sector location of element text length of element text 011 time element added date element added (month, day, year) Figure Executable Element Table Item Note: The description of Figure 8 10 is the same as for Figure 8 8 except for word 03 (bits 0 11), word 03 (bits 12 17), word 06, and word 07. Word 03 Bits 0 11 flag bits The following bit definitions apply to element type 6: 0 Table item is marked as deleted. 1 Zero 2 Zero 3 Zero 4 Zero 5 Arithmetic fault noninterrupt mode 6 Arithmetic fault compatibility mode 7 Real-time load 8 Block count in bank load table is for 64-word blocks. 9 Third-word sensitive

190 Program File Format 10 Quarter-word sensitive 11 Marked in error Bits element type 06 Executable Word 06 (for subtype 0 (ABS)) flag bits zero number of user banks number of common banks Bits 0 5 flag bits Bits 6 11 The following bit definitions apply to element type 6: 0 Always set 1 Memory conflict avoidance absolute; created by conflict avoidance processor (CAP) 2 Requires two processor state registers (PSR) due to initial and utility bank basing 3 Suppresses zero-fill 4 No start address for program reserved Bits Set to zero. number of user banks Bits The number of user banks in the program. number of common banks The number of common banks referenced by the program

191 Program File Format Word 06 (for subtypes 1 (OM) and 3 (ZOOM)) control sector offset Bit 0 Always set Bits 1 35 control sector offset The sector offset, relative to the sector location of element text in word 010, of the OM Header. Word 06 (for subtype 2 (SSD)) Zero Word 07 Bits 0 5 element subtype 00 absolute (ABS) 01 object module (OM) 02 subsystem definition (SSD) 03 zero overhead object module (ZOOM)

192 Program File Format Bits 6 11 element sub-subtype Bits For subtype 0 (ABS): This field is zero. For subtype 1 (OM): 00 object module (OM) 01 bound object module (BOM) For subtype 2 (SSD): This field is zero. For subtype 3 (ZOOM): 00 undefined 01 ZOOM ZOOM header (for subtype 3 (ZOOM) only) Bits The sector offset, relative to the control sector pointed to by the control sector offset in word 6, of the ZOOM header. If zero, then does not apply because the actual sector offset is greater than 63. Length of element text The length of the executable element text in sectors

193 Program File Format Omnibus Element Table Item Figure 8 11 describes the format of the 10-word table item for omnibus elements (element type 7) element name version link pointer link 03 flag bits element type type link version name 06 reserved for application use 07 element subtype element sub-subtype length of element text 010 sector location of element text 011 time element added date element added (month, day, year) Figure Omnibus Element Table Item Note: The description of Figure 8 11 is the same as for Figure 8 8 except for word 03 (bits 0 11), word 03 (bits 12 17), word 06, and word 07 (bits 6 35). Word 00 Word 01 element name Word 02 Bits 0 17 version link Bits pointer link

194 Program File Format Word 03 Bits 0 11 flag bits 0 Table item is marked as deleted. 1 2 Element text length granularity (see 7.6.1) Zero Bits element type 07 OMN Word 04 Word 05 version name Word 06 Bits 0 35 reserved for application use Word 07 Bits 0 5 Bits 6 11 This word is reserved for specific uses or Unisys applications. Use of this word does not imply any universal meaning for all omnibus elements. element subtype element sub-subtype For subtype 051 (COMUS): 00 File-BDI$ format 01 Bank-BDI$ format

195 Program File Format Bits length of element text For a PF or LPF bits are not used and should be zero. Bits contain the length of the element text in sectors. This allows a maximum of octal or 262,143 decimal sectors of element text. For an LEPF bits contain the length of the element text. Word 03 flag bits 1 2 specify the granularity of this value (sectors, tracks or positions) Procedure Tables This section describes the assembler procedure table (APT), COBOL procedure table (CPT), and the FORTRAN/PLUS procedure table (FPPT). Entries are made in the procedure tables by the Procedure Definition Processor, which is called by control statement. The common table format for the procedure tables is described in 8.5. All procedure table items contain the same information: the procedure name, a link to the element that contains the text of the procedure, a pointer link, flag bits, and the relative word location of the procedure in the file Assembler, FORTRAN, and PLUS Procedure Table Item Figure 8 12 describes the format of the 4-word table item for Assembler, FORTRAN, and PLUS procedures procedure name 02 element link pointer link or zero 03 flag bits word location of procedure Figure Assembler, FORTRAN, and PLUS Procedure Table Item Word 00 Word 01 Bits 0 35 procedure name The procedure entry-point name in Fieldata characters, left-justified and space-filled

196 Program File Format Word 02 Bits 0 17 element link Bits Sequence number of the element table item for the procedure element that contains the text of the procedure. pointer link or zero Word 03 Bits 0 5 Sequence number of another procedure table item with the same pointer table index (hash code) but a different procedure entry-point name. The pointer link can be zero. flag bits 0 The procedure is marked as deleted. 1 Zero 2 If set, text of the procedure is in 9-bit (ASCII like) characters. If clear, text of the procedure is in 6-bit (Fieldata) characters. 3 Text of the procedure contains sequence numbers in columns that should be ignored. 4 Text of the procedure contains kanji characters. 5 Zero (reserved) Bits 6 35 word location of procedure Word location of the procedure name relative to start of file. This is the word location of the SDF control word for the record containing the procedure name. If there are 042, 052, or 053 SDF control records preceding the procedure name, the location is still the SDF control word for the record containing the procedure name. The maximum value is because of the 30-bit limit of this field

197 Program File Format COBOL Procedure Table Item Figure 8 13 describes the format of the 4-word or 8-word table item for COBOL procedures COBOL procedure name 01 (characters 1-12) 02 element link pointer link or zero 03 flag bits word location of procedure 04 COBOL procedure name 05 (characters 13-24) 06 zero 07 COBOL procedure name (characters 25 30) Notes: Figure COBOL Procedure Table Item Words are always present in the COBOL procedure table item. The meaning of the fields in words of the COBOL procedure table item is the same as described for Figure 8 12 except for word 03 (bit 1). Words are present only if bit 1 of word 03 is set. The algorithm used for the procedure pointer table (see 8.5) uses only the first two words of a procedure table item. Thus, if several COBOL procedures are defined with a name distinction only after the first 12 characters, all of these procedures will end up on the same pointer link chain. This could affect performance. Word 03 Bit 1 COBOL procedure table item is extended to 8 words. Word 04 Word 05 Bits 0 35 COBOL procedure name Characters of the COBOL procedure name in Fieldata, left-justified and space-filled

198 Program File Format Word 06 Bits 0 35 Reserved Word 07 Bits 0 35 Set to zero. Because the search algorithm used for the COBOL procedure table item relies on word 06 being zero, BSP would need to change if word 06 is used. COBOL procedure name Characters of the COBOL procedure name in Fieldata, left-justified and space-filled Relocatable Element Entry-Point Table This section describes the REEPT. The common table format for the REEPT is described in 8.5. The REEPT is the set of all entry-point names in the file and the link from each entrypoint name to the relocatable element table item for the relocatable element that contains the entry point. The relocatable entry-point name is not available to the Collector unless it exists in the REEPT. The REEPT is created by the FURPUR statements and the PCFP PREP_PF function from the preambles of undeleted relocatable elements in the file. For more information on FURPUR, see the Executive Control Language (ECL) and FURPUR Reference Manual. The REEPT is invalidated whenever a relocatable element is added to or deleted from the element table. For the program file, this is done by setting the starting sector of REEPT and length of REEPT to zero in the FTI table descriptor. For the large program file, only the length of REEPT is set to zero because the starting sector of REEPT must remain set in the fixed-length table format

199 Program File Format Figure 8 14 describes the format of the REEPT item entry-point name 02 element link pointer link or zero 03 D F zero duplicate link or zero Figure Relocatable Element Entry-Point Table Item Word 00 Word 01 Bits 0 35 entry-point name Word 02 Bits 0 17 The entry-point name in Fieldata characters, left-justified and space-filled. element link Bits Sequence number of the element table item for the relocatable element that contains the entry point. pointer link or zero Word 03 Bit 0 Sequence number of another entry-point table item with the same pointer table index (hash code) but a different entry-point name. The pointer link can be zero. DF flag bit 0 If this bit is set, indicates the entry point is deleted. Bits duplicate link Sequence number of another entry-point table item with the same entry-point name but a different element link. The duplicate link can be zero

200 Program File Format 8.9. Object Module Entry-Point Table The OMEPT is created by the Linking System, either directly during object module execution or indirectly via statements and PCFP PREP_PF function from the control information in undeleted object module elements. The OMEPT differs from the other program file tables in that it is located in the element text area, not in the TOC area. Because the OMEPT is located in the element text area, it is not restricted in size except by the maximum granule for the file. The description of the OMEPT is restricted and controlled by the Linking System group. The identifier in words 0,1 of the OMEPT is OMEPT?ID in ASCII where? represents the octal value Number of Table Entries The following table gives the number of entries allowed in each TOC table for various conditions, provided the program file has not been rewritten by the statement. Table Type ET APT CPT (8 word) CPT (4 word) FPPT REEPT Column 1 gives the maximum allowable entries if all program file tables have entries and each table starts at the system-defined starting sector for the table. For the CPT, 4-word represents procedure names that are 12 characters or less, and 8-word represents procedure names that are 13 to 30 characters. Only the element table has a guaranteed number of allowable entries provided that the program file has not been rewritten by the statement. If the element table is fully expanded to the start of the element text area before entries are made in any other table, then no entries can be made in the other tables. 2 Column 2 gives the maximum number of entries allowed if the program file table starts at the system-defined sector and there are no entries in the following tables, thus permitting expansion of the table to the maximum limit, which is the starting sector of the element text area. 3 Column 3 gives the guaranteed maximum number of entries allowed in each table of the large program file. The guaranteed number of entries for each table results because the length of the table is fixed in the large program file

201 Program File Format Program File Creation and Maintenance The Exec PFP ERs and the SYSLIB BSP are the OS 2200 system interfaces to the program file structure. The Exec PFP ERs are documented in the ER Programming Reference Manual. The SYSLIB BSP interface is documented in the SYSLIB Programming Reference Manual. The Exec PFP ERs provide a subset of the SYSLIB BSP functionality. The SYSLIB BSP provides functions to: Read the FTI Read a TOC table Search a table for a specific entry Mark a specific entry in a table as deleted Locate an entry in a table given its sequence number Add an entry to a table Change an entry in a table Write the last table entry referenced back to the file Write a table back to the file Write the FTI back to the file The BSP functions can create, access and update PF, LPF and LEPF program files. The Exec PFP provides ERs to: Insert an entry in the element table Search the element table for a specific entry Mark an element table entry as deleted Update the next location for writing element text in the FTI Get the next location for writing element text The Exec PFP interface can create, access and update PF program files. The Exec PFP interface cannot create LPF program files but can access and update them. The Exec PFP interface cannot currently create, access nor update LEPF program files. The program file is a system data structure that is subject to change in content or format without notice. Any software that needs to access the program file must do so through the Exec PFP ERs or the SYSLIB BSP interface. PFP and BSP guarantee compatibility with all formats and versions of the program file

202 Program File Format System-defined default values for the program file are in element SYS$DEF in the SYSLIB installation file SYS$LIB$*SYSLIB. These include CYCLIM$ symbolic element cycle maximum Program file identifiers: - PF$ID program file identifier - LPF$ID large program file identifier - LEPF$ID large element program file identifier Starting sectors for tables Pointer table length Table item length LEPF Considerations This section contains additional information, limitations, restrictions and considerations pertaining to LEPFs and their use. HMP IX 5.1 or higher levels of the following software products are required to support the large element program file: FURPUR level 31R6 or higher PCFP level 2R2 or higher SYSLIB level 76R1 or higher The following are general limitations and restrictions: LEPFs are first supported by the BSP contained in SYSLIB 76R1. LEPFs are not recognized as program files by any prior SYSLIB level. The initial implementation of LEPFs is intended primarily for use by MAPPER, as a container for large MAPPER reports (symbolic elements) that have over 262,143 sectors of element text. Initially, only MAPPER, FURPUR, PCFP and the BSP component of SYSLIB support LEPFs. Initially, LEPFs are not supported by the Exec, including the PFP ER interface and the command etc.). Initially, LEPFs cannot contain procedure elements (element type 1, subtype 29 and element types 2, 3 and 4), relocatable elements (element type 5) and executable elements (element type 6). Calling programs that are not modified will not recognize LEPFs as program files. This includes programs that call the relocatable version of BSP, even when they are recollected with SYSLIB 76R1 or later levels. See the SYSLIB Programming Reference Manual for details on modifying programs to create, access and update LEPFs

203 Program File Format The following are considerations when reading element table entries: When reading elements from a PF or LPF: The maximum element text size is 262,143 sectors. The element text length in word 07 is stated in sectors for all element types. For all element types the flag bits field 'element text length granularity' (word 03, bits 1 2) is not used and should be ignored. For symbolic elements 'element text length' word 07, bits 6 17 (S2 and S3) are not used and should be ignored. For omnibus elements 'element text length' word 07, bits (S3) are not used and should be ignored. When reading elements from an LEPF: The maximum element text size is limited only by maximum file size.the theoretical maximum is octal or 1,073,735,936 decimal sectors. This is based on the maximum possible file size minus 1,792 sectors reserved for the TOC of a standard LEPF. Make sure the correct field size is used when loading 'element text length' from word 07. For symbolic elements the field size is 30 bits (bits 6 35) and for omnibus elements the field size is 24 bits (bits 12 35). Once the correct 'element text length' value is loaded, the 'element text length granularity' field (word 03, bits 1 2) must be examined: If it is 0, element text length is stated in sectors. If it is 1, element text length is stated in tracks. Track granularity can be converted to sector granularity by multiplying by 64 or by shifting left by 6 bits. If it is 2, element text length is stated in positions. Position granularity can be converted to sector granularity by multiplying by 4,096 or by shifting left by 12 bits. Combinations of element text length and element text length granularity can result in a number of sectors that is over the theoretical maximum described above. The result may even be over 36 bits, so maximum value checks or double-word operations are recommended to determine the validity of the calculated element text length

204 Program File Format The following are considerations when creating element table entries: When creating elements in a PF or LPF: The maximum element text size is 262,143 sectors. The 'element text length granularity' (word 03, bits 1 2) field should be 0. For symbolic elements 'element text length' word 07, bits 6 17 (S2 and S3) should be 0. For omnibus elements 'element text length' word 07, bits (S3) should be 0. When creating elements in an LEPF: If the element text is at most 262,143 sectors, use the above PF and LPF format for the element table item. For efficiency and to avoid wasted mass storage, select the smallest granularity possible. Sector granularity is the smallest, followed by track and then position. ο ο For symbolic elements the 30-bit 'element text length' field is large enough to describe any element text using sector granularity. Neither track nor position granularity is needed for symbolic elements. For omnibus elements the 24-bit 'element text length' field is large enough to describe element text of 16,777,152 sectors using sector granularity. For element text larger that this, use track granularity. Position granularity is not needed for omnibus elements. When using track or position granularity, make sure that 'element text length' is rounded up to the next granule when it is not an even multiple of track size or position size. For example a track granularity element with 5,000 tracks plus 1 sector (320,001 sectors) must be rounded up to 5,001 tracks (320,064 sectors); a position granularity element with 70 positions plus 1 sector (286,721 sectors) must be rounded up to 71 positions (290,816 sectors). If 'element text length' is rounded up, as described above, additional sectors must be written to pad the element to the proper granule boundary. It is recommended that sectors containing zeroes be used for the padding. In the above examples the track granularity element would require 63 sectors of padding and the position granularity element would require 4,095 sectors of padding. As described above, neither track nor position granularity should be used for symbolic elements and track granularity should only be used for omnibus elements with over 16,777,152 sectors or 262,143 tracks of element text. When using track or position granularity, make sure that the final 'element text length' is converted back to number of sectors when updating the FTI 'next sector available for writing element text', in word 01 of Figure 8 5 and Figure

205 Section 9 Relocatable Binary Format A relocatable element is the output of the language processors (for example, FTN, ACOB, and MASM) and sometimes the OS 2200 Collector (via control statement). Relocatable elements are in relocatable binary (RB) format and are used as input to a collection to produce an executable program (that is, absolute element). The relocatable binary format is optimized, as far as storage space and relocation efficiency, for the instructions and data to be coded under control of location counters one and two. Some compilers use, almost entirely, location counter one for instructions and location counter two for data of the generated code. The relocatable element is divided into two parts called the preamble and the text. The preamble contains information concerning the external properties of the element. The text contains the generated instructions plus the relocation information. With the release of SB4, an enhanced relocatable binary format was provided. The enhancement provided in this format is the capability to recognize the new address formats introduced by the extended mode architecture. Additionally, 18-bit addressing is provided by allowing an 18-bit offset instead of the previous 16-bit offset. All releases of MASM and the Collector (R option) since SB4 will generate the enhanced relocatable binary format. All releases of the Collector since SB4 will process both the standard relocatable binary format and the enhanced relocatable binary format. Currently, no other processors that generate relocatable binary format elements have determined a need to make use of the enhanced relocatable binary format. The standard relocatable binary format (ROR and ROR$) is owned and maintained by SYSLIB. The enhanced relocatable binary format (ROR$E) is owned and maintained by the Collector. For a description of the subroutines provided to generate a standard or enhanced relocatable binary format element, refer to the SYSLIB Programming Reference Manual or the Collector Programming Reference Manual

206 Relocatable Binary Format 9.1. The Preamble The preamble of a relocatable element is composed of five tables located after the text of the relocatable element. These tables, in the order given, are Base table Location counter table Undefined symbol table Entry-point table Control information (INFO) table Except for the base table, only those tables necessary to a particular element are included in the preamble. The base table is always included. The preamble is a variablelength table Base Table There are two formats for the base table. The first four words of both base table formats are the same for the standard and enhanced relocatable binary formats. A fifth word was attached for the enhanced relocatable binary format in order to distinguish the enhanced format from the standard format and to allow an indicator to indicate future versions of relocatable binary format enhancements. The rest of the fifth word is currently reserved and zero-filled. Additional words may be attached by future relocatable binary format enhancements, which are distinguishable by the indicator in bits 0 5 of word 04 of the base table. The format for the base table, always included in the preamble, is as follows: 00 index to location counter table item count of location counter table 01 index to undefined symbol table item count of undefined symbol table 02 index to entry point table item count of entry point table 03 index to control information table item count of control information table The indices in the left half of the entry are relative to word zero of the base table. For the standard relocatable binary format, the location counter index is always four. For the enhanced relocatable binary format, the location counter index is determined by the relocatable binary version indicator in bits 0 5 of word offset

207 Relocatable Binary Format The fifth word of the base table for enhanced relocatable binary has the following format: 04 RB Version Reserved (zero) Bits 0 5 contain the relocatable binary version of the ROR$E relocatable binary format used to create the element containing this base table. ROR$E provides an externalized flag, ROR$VERSION, which should be used to set the relocatable binary version in bits 0 5 of word 04 of the base table before the preamble containing the base table is written out to the program file. The TBLWR$EB Table Write subroutine provided with ROR$E should be used to write out the preamble for the relocatable binary element being created. Currently, only the relocatable binary version 1 is defined. For relocatable binary version 1, the length of the base table is five words Location Counter Table The location counter table format is as follows: 00 K-bit count length of location counter 0 01 minimum data read address (D-bank address) length of location counter n-2... n-1 length of location counter n-1 n length of location counter n where n must be less than 512. The K-bit count is the number of bits needed to contain the number of undefined symbols in the element, or the largest location counter number, whichever is greater. The K-bit count must be the same value supplied to the SYSLIB relocatable output routine (ROR or ROR$), subroutine SROR or SROR$EB, or the Collector relocatable output routine (ROR$E), subroutine SROR$EB. The minimum address assigned to the data area of this element is normally zero. However, for some programs, the minimum address is specified by the compiler, generating INFO group 3. The location counter table is a variable-length table with a maximum length of 512. The location in the table is the counter number. The length of the table is equal to the highest-numbered location counter used in the element plus one

208 Relocatable Binary Format For example, assume that counters 1, 3, 4, and 7 are used, and the number of words reserved or generated are 20, 30, 5, and 3 under the respective counters. In addition, there is an entry point under the void location counter 6. An example location counter table follows. 00 K-bit count If bits 0 17 = and bits = 0, the location counter is nonexistent. Otherwise, a word of all zeros indicates a void location counter. The use of void location counters should be avoided since it makes the Collector less efficient. However, location counters 0 and 1 cannot be marked nonexistent. If bits = 1, the location counter has a length of zero Undefined Symbol Table The undefined symbol table is a list of all the symbols that are not defined within the element. The undefined symbols can be up to 12 characters in length; each entry in the table is two words. The text, in place of the undefined symbol, contains indicators that link these specific references to the undefined symbol table. The value of the indicator is the order of the symbol in the table beginning with zero. The indicator value multiplied by two gives the index into the table of the first word of the undefined symbol. There can be up to 1024 undefined symbols in an element within the constraints of the K-bit count. The entries are left-justified and space-filled Fieldata. Entries in the undefined symbol table need not be in any particular order (for example, lexically ordered). The 1024 limit is determined by the design limitation within the Collector when processing IN entries at collection time two-word entries = 2048 words = 1/3 of a word. The Collector uses bits in an internal data structure for this information

209 Relocatable Binary Format The relocatable binary format undefined symbol table format is as follows: undefined symbol up to 12 Fieldata characters n n+1 where n is the last undefined symbol entry Entry-Point Table The entry-point table format is as follows: entry-point name -up to 12 Fieldata characters 02 location counter number or descriptor bit 0 03 value Each entry-point table item entry is four words in length. The first two words contain the name of the entry point in Fieldata (left-justified and space-filled). The third word is used in two different ways, depending on whether bit 8 is set or clear. The fourth word is a value. Entries in the entry-point table do not need to be in any particular order. Bit 8 of the third word is called the descriptor bit. If the descriptor bit is set, the entry point is an absolute value and has the value of the contents of the fourth word in this item s entry. If the descriptor bit is clear, the entry-point value is relative to the location counter specified in bits 9 17 of the third word. Other than bit 8, the designator bit, the rest of bits 0 8 of the third word are zero not used. The maximum location counter number is 512, which fits in bits 9 17 of the third word. Bits of the third word are zero-filled. Any number of entry points can be given

210 Relocatable Binary Format Control Information (INFO) Table Each group entry in the control information table (CIT) currently has a four-word structure. Certain fields within this structure are used for the same purpose for all the different group entries that can be inserted into this table. Words 00 and 01 of the structure are zero-filled or used to specify a Fieldata name up to 12 characters in length. Bits 0 5 of word 02 contain the group number that identifies the purpose of the entry. If an address specification is possible for a group (groups 2, 3, 4, and 11), bits of word 02 contain this information. If a location counter number can be specified for a group (groups 2, 4, 7, 8, 9, and 10), bits 0 11 or word 03 contains the location counter number. Unless indicated otherwise (group 11), the remaining unused fields of words 02 and 03 are zero-filled. When merging relocatables with group 2, 4, and 8 control table entries during an R-option collection, the Collector does not allow a named common block (group 2), blank common block (group 4), or diagnostic entry (group 8) to have the same location counter number specification in more than one of these groups. The Collector adjusts the location counter number specifications to prevent this. The CIT can contain entries for INFO groups 2, 3, 4, 7, 8, 9, 10, 11, and 12. INFO groups 1, 5, and 6 are not inserted into the CIT. They are handled by the Meta-Assembler (MASM), which uses alternate means to pass the information from these groups to the Collector. Listed below are the CIT entries recognized by the Collector. INFO Group 2 Entry (named common block) common block name 12 Fieldata characters 02 2 zero minimum address (if any) or zero 03 location counter number zero INFO Group 3 Entry (minimum address specification) zero 02 3 zero minimum address (if any) for D-bank or zero 03 zero minimum address (if any) for I-bank or zero The INFO 3 entry indicates the capability to specify an I-bank minimum address specification in bits of word 03. This capability was implemented in the Collector but is apparently not being used. Due to internal coding changes in the Collector and problems detected in the implementation of this capability, the feature is partially disabled within the Collector. Thus, it is not recommended that an I-bank minimum address specification be used in an INFO group 3 entry unless the user verifies that the Collector can handle it appropriately

211 Relocatable Binary Format INFO Group 4 Entry (blank common block) zero 02 4 zero minimum address (if any) or zero 03 location counter number zero INFO Group 7 Entry (even start address for location counter) zero 02 7 zero 03 location counter number zero INFO Group 8 Entry (diagnostic information) zero 02 8 zero 03 location counter number zero During an R-option collection in the resultant Collector-generated relocatable binary element, the Collector will insert two words of Fieldata spaces into words 00 and 01 of an INFO group 8 entry instead of zero-filling these two words. INFO Group 9 Entry (read-only location counter) zero 9 zero location counter number zero INFO Group 10 Entry (extended mode location counter) zero 10 zero location counter number zero

212 Relocatable Binary Format INFO Group 11 Entry (void bank) bank name 11 option bits starting address (if any) or zero zero Option bits: Bit 15 I-bank Bit 16 D option (dynamic bank) Bit 17 S option (shared bank) INFO Group 12 Entry (LIB entry) keyword name maximum of 12 Fieldata characters 12 zero zero A keyword name is used to indicate a system-installed product library that is to be found in the default chain of standard product libraries searched by the Collector at collection time. This chain of standard product libraries is not defined by the Collector. A product registers its library as a standard product library with the Collector when the product is installed on a system. Optionally, the product may also provide a keyname for its product library when registering the library at installation time. The keyword can then be used to alter the search order at collection time. During a collection, the Collector acquires this information from SYS$*DATA$.LIB$NAMES, which was updated during the product installation The Text In general, compilers and assemblers do not need to set up the text format. The provided relocatable output routine formats the text when called by the compilers or assemblers. The relocatable output routines ROR and ROR$ (provided by SYSLIB) and the relocatable output routine ROR$E (provided by the Collector) use the same strategy to format the text. The enhancements provided by the Collector in ROR$E have introduced some minor variations that are described as they are encountered in the following descriptions. The text of a relocatable binary element is separated from the preamble for the same relocatable binary element in a program file. The element table item for the relocatable binary element entry in the program file points to the sector locations for the related element preamble and its text. The text is broken into blocks, which in turn are broken into word groups. The word groups are broken into text words and relocation information related to the text words. The block size is fixed by all the relocatable output routines at 14 words. The first text block begins on a sector boundary

213 Relocatable Binary Format The relocation information is optimized for the most heavily expected use of two location counters in a word group. These location counters are called normal counter one and normal counter two, or for short, NC1 and NC2. NC1 is the location counter controlling the text words of this word group except when the text words are controlled by location counter two. In this case, NC1 is location counter one. NC2 is always location counter two. The notations (NC1) and (NC2) are used to indicate the current assignment of NC1 and NC2. The current assignment of a location counter is the absolute starting address of that counter as assigned by the Collector. Within the relocation information, fields refer to location counters and undefined symbols. These fields are K bits in length. The compilers and assemblers may specify the value of K. If the value of K is not specified, the fields are assumed to be 10 bits in length. The value of K supplied to the relocatable output routine must be in the left half of the first word of the location counter table in the preamble. In this section, the bit positions of the computer word are numbered from 00 to 35 from left to right. Any connected portion of a word, from bit M to bit N (where M <= N) may be relocated mod 2 (N-M+1) - 1. Here are the possible relocation specifications: Relocation by any of the 512 location counters Relocation by any of the 1024 undefined symbols Addition or subtraction of relocation increments Repeated addition and/or subtraction of relocation increments Special tests are made by the Collector to flag any possible field overflow

214 Relocatable Binary Format Word Groups Word groups represent text words that are allocated to sequential memory cells. Each word group is made up of two parts: the word relocation information and the text words themselves. Both parts of a word group are contained within a single block of 14 words. However, each part of a word group is physically located at different ends of the 14-word block. The relocation information for a word group is located closer to the beginning of the block, and text words for the same word group are relatively located closer to the end of the block. Multiple word groups, each word group with both of its parts, can be contained within a single 14-word block as follows. Relocation Information and Text Words relocation information for first word group relocation information for second word group..... text words for second word group text words for first word group 015 sequence number The text words are in inverse order in the block from the way they are allocated to memory cells. The last word in each block is a sequence number. Bits 0 11 are two Fieldata characters. The first begins with A and cycles through the entire Fieldata character set. The second is always a letter. Bits are always zero. The relocation information in any word group is in the form of a stream of bits. The length of the stream is variable, but the first bit of a stream is always the leftmost bit of a word

215 Relocatable Binary Format The relocation information for each word group includes fixed- and variable-length fields. Relocation Information Bit Stream 10 starting address word count group counter (L bits) cont. group counter (L bits) variable-length bit stream containing the relocation bits for text words..... The first bit of a relocation information bit stream always begins with the leftmost bit of a word. The first two bits are used to indicate two different types of relocation information bit streams. To indicate the beginning of a relocation information bit stream, the first bit is always set (1). When the relocation information bit stream is finished for the current word group, the first bit of the next word can be checked to determine whether a relocation information bit stream exists for another word group in this block. If the first bit is set, another word group entry exists in the block. If the first bit is not set, there are no more word groups within this particular text block of 14 words. The second bit of the relocation information bit stream is usually clear (0) to indicate a regular relocation information bit stream. Most relocation information bit streams will have this second bit clear. If the second bit is set (1), the bit stream is used to indicate a program transfer address. A program transfer address is used to indicate to the Collector an address that is to be used to start the program (start address) when executed. Since many relocatable binary formatted elements may make up a single executable program, generally only one of the relocatable elements that make up the program will have a program transfer address relocation information bit stream. Occasionally, a program may indicate no program transfer address (start address) or contain multiple program transfer addresses. These cases will be indicated at collection time or can be resolved at collection time by Collector directives. Bits 10 and 11 indicate the start of an existing relocation information bit stream. 10 Regular bit stream indicator 11 Program transfer address bit stream indicator Following the 2-bit indicator at the beginning of the relocation information bit stream is the starting address field of the bit stream. This field is used to indicate the starting address within the program of the first text word in this word group relative to the start of the group counter (indicated in a subsequent field of this word group bit stream). In the SYSLIB standard relocatable output routines, the starting address field is 16 bits long; it is located in bits 2 17 of the bit stream. To accommodate the 18 bit addressing capabilities of current and future released hardware, the Collector-enhanced relocatable output routine uses a starting address field that is 18 bits long (located in bits 2 19 of the bit stream)

216 Relocatable Binary Format The field following the starting address field in the relocation information bit stream is the word count field. This 9-bit field contains the number of text words contained in the text word portion of this word group. In the standard relocatable binary elements, bits contain the word count. In the enhanced relocatable binary elements, bits contain the word count. In the enhanced relocatable binary elements, bits contain the word count. Although this field is 9 bits long, the current maximum block size is 14 words. The number of text words must be less than 14 words, because one word is used for the block sequence number and one or more words contain this relocation information bit stream part of the word group. The next field in the relocation information bit stream is the group counter field. The length of the group counter field is adjustable and is referred to as L bits in length. The size of L is determined by the location counter under which the text words for this word group are to be placed and the K-bit count value provided in bits 0 17 of the first word of the preamble s location counter table for this relocatable binary element (see and 9.2). The length of L may vary from 2 bits to K+2 bits. Thus, this field in the bit stream may overflow into the next word. Since 10 is often used for the K-bit count, L can often be 12 bits long and cause the group counter field to overflow into the next word. Although the group counter field is adjustable, it becomes a variable-length field within a specific relocatable binary element that is always either 2 bits long or K+2 bits long. The group counter field starts with bit 27 for a standard relocatable binary element and bit 29 for an enhanced relocatable binary element. (For a description of the usage of the group counter field, see ) Table 9 1. Group Counter Field Group Counter Value L-Bit Length L-Bits Location counter 0 2 bits 00 Location counter 1 2 bits 01 Location counter 2 2 bits 10 Location counter > 2 12 bits (assume K=10) (K) bits with location counter

217 Relocatable Binary Format The Collector Programming Reference Manual recommends maximizing the usage of location counters 1 and 2 when feasible in order to minimize the amount of processing required by the relocatable output routines and to produce a more compact relocatable binary element. This in turn produces a smaller bit stream for the Collector to analyze. After the L bits that make up the group counter field in the relocation information bit stream, a variable-length bit stream field is created. This variable-length bit stream contains the relocation bits for the text words for this word group entry. The variablelength field varies extremely in length and content. This is the last field of the bit stream that makes up the relocation information part of a word group. For a description of the various contents that make up this variable-length field, see When the first two bits of the relocation information bit stream indicate that it is to be used for a program transfer address, the following fields are similar to those described above. The differences are that the word count for a program transfer address is zero, and therefore there is no variable-length bit stream field to contain any relocation bits for text words Group Counter The group counter is the location counter under which the text words are to be placed. During collection, the starting address of this location counter is added to the word group starting address to determine the absolute program address of the text words. The group counter is determined by the L bits following the word count field. The group counter also determines which location counter is assigned to NC1. Table 9 2. Group Counter Relocation Bits Group Counter NC1 NC X where X > 2 X 2 The stream of relocation bits governs the relocation of the text words. The possible bit combinations and their meanings follow. The bits in the text words are numbered 00 to 35 from left to right for consistency with current documentation standards

218 Relocatable Binary Format Note: Many processors such as MASM and LIST display fields that are being extracted in order to apply relocation using the old numbering system, where the bits in the text words are numbered 00 to 35 from right to left. Internally, the relocatable binary routines also use the old numbering sequence of 00 to 35 from right to left. Thus, in examples of relocation bits bit streams where a bit is pointed at as a left limit or right limit, the bit is numbered according to the old right-to-left numbering system, which was the standard when these routines and processors were designed. Figure 9 1 and Figure 9 2 show how the modification is accomplished using the relocation bits to provide the necessary relocation information. The modification bits that make up the relocation bits bit stream are grouped for logical functions. Each logical function group of modification bits also varies in length. The field of the text word to be modified is selected, and then the necessary modification is determined. Additional bits determine when the modification bits apply to another word, another field, or the same field. The relocation bits use a modification scheme based on functions identified by addressing capabilities. The first few bits in the variable-length bit stream determine which relocation function is to be used by the Collector at collection time. In Figure 9 1 and Figure 9 2, these function-identifying bits are those immediately following pointer A in the diagrams. The function identifier can be 1, 2, or 4 bits in length. Table 9 3. Relocation Functions Identifier Bit Length Type of Relocation Function Indicated 1 1 bit Relocation by right address (RA) 00 2 bits No relocation attached bits Relocation by left address (LA) bits Relocation by right half-word (RH) bits Relocation by left half-word (LH) bits Relocation by special fields

219 Relocatable Binary Format Figure 9 1 is a diagram of the standard relocation information bit stream. The symbols and terms used in Figure 9 1 and Figure 9 2 are defined in text following Figure 9 2. Figure 9 1. Standard Relocation Information Bit Stream

220 Relocatable Binary Format Figure 9 2 is a diagram of the enhanced relocation information bit stream. Figure 9 2. Enhanced Relocation Information Bit Stream The following symbols and terms are used in Figure 9 1 and Figure 9 2. A description is provided for each symbol or term. Word Count Number of text words within the text word portion of a word group within a 14-word block. S Sign bit for an address type field that was extracted from the current text word. XX Sign bit filler extension bits used to extend an extracted 16-bit address field to a half-word to which the sign bit S is prefixed and extended

221 Relocatable Binary Format LLL Address field size for a left address or right address extracted field. Current field sizes are 16, 12, or 7 bits. This determines where to prefix the sign bit S and sign extend the address field. A Pointer in diagrams indicating the point in the relocation information bit stream where the field size to extract from the text word begins. This includes where the bit stream continues for the next field when multiple fields in the same text word are modified by relocation. B Pointer in diagrams indicating the end of the information for extracting the field size and the beginning of the information indicating the addition or subtraction of what type of relocation modification is to be applied. This also points to where the bit stream continues for additional relocation modification bits to be applied to the same extracted field of the same text word. K-Bits A fixed field width in bits for an element found in bits 0 17 of word 00 in the Location Counter Table from the Preamble for the relocatable binary element. Exit Indicates the termination of the modification bits in the relocation information bit stream that apply to the current text word being modified. If another text word exists in the same text word portion of the current word group, the modification bits for the next text word will be processed using pointer A in the diagrams as a starting point. The relocation functions, left and right address and left and right half-word address, are based on the architecture addressing capabilities. The sign for the value contained in the address field for these instructions is maintained separately from the actual value so that the address value does not lose the upper bit of the value for a sign bit. On the other hand, relocation information by special fields does not provide a separate sign bit. Therefore, the upper bit in this relocation special field value may or may not be a sign bit depending on how the value is being used. For the architecture addressing capability functions, the text word being relocated contains bits for an address-type field. The modification bits in the relocation bits bit stream are used to modify these text word bits being used as an address-type field value. Using the modification bits and the text word, at collection time this address-type field is extracted, formed, and expanded to a word by the Collector before relocation arithmetic is performed

222 Relocatable Binary Format The Collector performs this differently depending on which format is used: SYSLIB standard relocatable binary format or Collector-enhanced relocatable binary format. The enhanced relocatable binary format was primarily provided to handle additional addressing capabilities not previously available before the extended mode architecture. The following addressing capabilities are currently provided by these two relocatable binary formats. Table 9 4. Word Addresses Addressing Relocation Function Field Bits SYSLIB Standard RB Format Collector-Enhanced RB Format Right Half-Word Left Half-Word Right Address Left Address Not Available Not Available Not Available Not Available For the right half-word and the left half-word functions, either the standard relocation format or the enhanced relocation format extracts the indicated 18-bit field from the text word, prefixes it with the sign bit (indicated by S in Figure 9 1 and Figure 9 2), and extends the sign bit to a word at collection time in order to perform the relocation. The standard relocatable binary format for right address and left address functions uses additional modification bits (indicated by XX in Figure 9 1) as fillers to extend the 16-bit field from the text word to 18 bits and then prefix the sign bit indicated by S. To perform the relocation, the Collector extends the sign bit to a word at collection time. The enhanced relocatable binary format for right address and left address functions uses additional modification bits (indicated by LLL in Figure 9 2) to determine which right address or left address field size is to be extracted from the text word. For consistency and implementation reasons, both right address and left address have the same field size options. Using the field size modification bits (LLL), the Collector extracts the indicated field size from the text word, prefixes the sign bit indicated by S to the extracted field size address bits, and extends the sign bit to a word at collection time in order to perform relocation (this replaces the filler bits XX used by the standard relocatable binary format)

223 Relocatable Binary Format The field size indicator bits (LLL) are defined in Table 9 5. Table 9 5. Field Size Indicator Bits Field Size Indicator Bits (LLL) bits bits bits Indicated Field Size 100 Currently undefined 011 Currently undefined 010 Currently undefined 001 Currently undefined 000 Currently undefined The enhanced format allows for additional address field types to be defined if they are ever needed. For special field relocation situations (function identifier 0111), the field that is to be extracted from the text word is not considered an address field. Thus, the field being extracted will not be treated as a signed address field. Instead, an additional 12 modification bits follow the function identifier 0111 in the relocation bits bit stream. The first 6 bits indicate the bit for the left limit of the field to be extracted from the text word. The second 6 bits indicate the bit for the right limit of the field to be extracted from the text word at collection time. The relocation arithmetic is performed on this extracted bit field value at collection time. When a field is extracted from the text word in this manner, the most significant bit of the extracted field is used as the sign bit. The modification bits acquired from the relocation bits bit stream have so far only determined the function identifier in order to determine the field to be acquired from the text word being modified

224 Relocatable Binary Format Examples of these function identifier portions of the modification bits in the relocation bits bit stream are given in Table 9 6. Table 9 6. Function Identifier Formats Function Identifier Standard Format Enhanced Format No relocation attached Special fields 0111zzzzzzZZZZZZ 0111zzzzzzZZZZZZ Special fields example: Left limit = 043 (35) Right limit = 033 (27) Right half-word 0101S 0101S Right half-word example Left half-word 0110S 0110S Left half-word example Left address 0100SXX 0100LLLS Left address example Right address 1SXX 1LLLS Right address example Legend S sign bit XX field extension bits LLL field size bits z left limit Z right limit Note: Internally the relocatable binary routines extract fields using the old numbering system, where the bits in the text word are numbered 00 to 35 from right to left

225 Relocatable Binary Format The following statements provide additional information for the related function identifier in Table 9 6: For the function identifier right half-word, the extracted address type field from the right half of the text word is to be treated as a positive value. For the function identifier left half-word, the extracted address type field from the left half of the text word is to be treated as a negative value. For the function identifier left address, the extracted 16-bit address-type field from the left half of the text word is to be treated as a negative value. XX equals 11 for sign extension. LLL = 111 to indicate a 16-bit field size. For the function identifier right address, the extracted address-type field from the right half of the text word is to be treated as a positive value. XX equals 00 for sign extension of the 16-bit address field. LLL = 110 to indicate a 12-bit address size. When the function identifier is 00, no relocation is attached to the indicated text word. This completes the modification bits subsection of the relocation bits bit stream for that particular text word. The following modification bits will be applied to the next text word in this word group if another text word remains in the 14-word block. For the remaining function identifiers, the modification bits are extended to indicate what type of relocation modification is to be applied to the text word field that was extracted by the preceding function identifier bits in this set of modification bits. All of the appended modification bits, indicating relocation modification to be applied to the currently extracted text word field, follow pointer B in Figure 9 1 and Figure 9 2. Multiple relocation modifications of the same extracted text word field restart the related modification bits at pointer B again. When the modification bits for relocation modification of the current text word field have been provided, the modification bits bit stream will return to pointer A to acquire the function identifier for the next field to be relocated within the same text word if more relocation modification is to be applied to this text word. Otherwise, the subset of modification bits bit stream to be applied to the current text word is completed. The following modification bits will be applied to the next text word in this word group if another text word remains in the 14-word block. If the word group is completed, processing will proceed to the next word group if another one exists in this block. Otherwise, the next block is processed. The first bit of the modification bits appended following the function identifier indicates whether the following relocation information is to be added or subtracted to the extracted text word field. This bit immediately follows at pointer B in Figure 9 1 and Figure 9 2. If this bit is clear (0), the following relocation modification is to be added to the extracted text word field. Otherwise, if the bit is set (1), the relocation modification will be subtracted from the extracted text word field

226 Relocatable Binary Format The next two bits in the modification bits bit stream indicate where the relocation modification value is that will be added or subtracted to the extracted text word field. The modification can be by NC1 or NC2 or the modification can be by undefined symbol or location counter. (See for a description of NC1 and NC2.) If modification is by NC1 or NC2, only these two bits are needed to indicate this type of modification. If modification is by undefined symbol or location counter, an additional set of bits is attached to these two modification bits. The additional set of attached bits is used to provide the location counter value or provide the offset value for the undefined symbol in the undefined symbol table portion of the preamble for this relocatable binary element (see 9.1.3). The attached bits are K bits in length. The K-bit count is acquired from bits 0 17 of word 00 in the location counter table portion of the preamble (see 9.1.2). The relocation modification values are given in Table 9 7. Table 9 7. Relocation Modification Values Modification Bits Modification Value to Be Applied 00 Modify (add or subtract) by the value of NC1. 01 Modify by the value of NC K bits Modify by the value of the undefined symbol indicated in the next K bits K bits Modify by the value of the location counter provided in the next K bits. Thus far, the modification bits have extracted the field to be modified from the text word (function identifier), determined whether the modification is to be added or subtracted, and indicated the type of modification value to be applied to the extracted text word field (modification type bits). Next, the modification bits must indicate whether any additional relocation (multiple relocation) remains to be applied to the current text word. Multiple relocation is indicated by the next one or two bits in the modification bits bit stream. The first bit indicates whether any additional relocation modification remains to be applied to the current text word. If this bit is clear (0), no further relocation remains to be applied to the current text word. This terminates the subset of modification bits from the relocation bits bit stream that applies to the current text word. The relocation information section of this word group will continue the relocation bits bit stream with more modification bits information for relocation to be applied to any remaining text words that still remain as part of this word group in the 14-word block. The next subset of modification bits for a subsequent text word (if another one exists for the same word group) immediately follows this clear (0) bit used to terminate the relocation information applied to the text word that was just modified

227 Relocatable Binary Format If this first bit after the modification type bits is set (1) instead of clear (0), this indicates that additional modification remains to be applied to the current text word being modified in this word group. Two multiple relocation options remain that can still be applied to this current text word. The second bit will be used to indicate which relocation option follows in the remaining modification bits for this text word. If the second bit is clear (0), additional relocation modification remains to be applied to another field in the current text word. In Figure 9 1 and Figure 9 2, this means that the following modification bits will be processed as they were after pointer A, where the function identifier bits are acquired to determine the next field to be modified. If the second bit is set (1), this indicates that the following relocation modification is to be applied to the same extracted field from the current text word that was just modified. In Figure 9 1 and Figure 9 2, this means that the following modification bits will be processed as they were after pointer B. The next bit will indicate whether the next modification will be added or subtracted followed by the modification type bits indicating the type of modification value to be used to modify the same text word field this time. Additional modification indicators are given in Table 9 8. Table 9 8. Additional Modification Indicators Relocation Option Bits Additional Relocation Modification to be Applied to the Current Text Word 0 Terminate modification of current text word. 10 Modify another field of the current text word. 11 Modify the same field of the current text word. The relocation bits bit stream for a word group terminates when all the relocation information to be applied to the text words in the same word group of the 14-word block has been supplied using subsets of text word modification bits for each relocated text word. Examples of modification bits bit streams for a single text word follow. 0101S Subtract the value of NC1 from the right half address text word field. 0110S S (K=10) Add the value of NC2 to the left half address text word field, and subtract the value of location counter 6 from the right half address text word field. 1SXX (standard format) Add the value of NC2 to the right address text word field. 1LLLS (enhanced format) (LLL=address size) Add the value of NC2 to the right address text word field of field size LLL

228 Relocatable Binary Format 1SXX (standard format) Add the value of location counter 4 to the right address text word field. 1LLLS (enhanced format) (LLL=address size) Add the value of location counter 4 to the right address text word field of field size LLL. 1SXX S (standard format) (K=10) Add NC1 to the right address text word field and subtract the second undefined symbol in the undefined symbol table from the left half address text word field. 1LLLS S (enhanced format) (LLL=address size) (K=10) Add NC1 to the right address text word field of field size LLL and subtract the second undefined symbol in the undefined symbol table from the left half address text word field S (K=10) Subtract NC2 from extracted text word field with upper bit 26 to lower bit 18 (internal numbering right to left), and add the value of location counter 5 to the same extracted text word field. Then subtract NC1 from the right half address field of the same text word Relocation Field Selection Figure 9 1 and Figure 9 2 provide a diagram of how to interpret the relocation information bit stream portion of a word group in the text section of a relocatable binary element. Each word group relocation information bit stream applies only to the text words within the text word portion of the same word group. There may be multiple word groups in the same 14-word block (see 9.2 through 9.2.3)

229 Section 10 Shift-Code Format (Kanji) Note: Shift-code format is an interim format to allow kanji characters to be embedded within ASCII/ISO character strings until the attributed character data (ACD) format is fully supported Shift-Code Format The bit representation, as shown in the following formats, is equivalent to two ASCII 9-bit characters. The format of the shift-code is defined as follows: CC 0 SP where: CC control character (0223 = 93H) SP selective parameters The format of the selective parameters (SP) is defined as follows: c b a The code selector is defined as follows: a code selector field (bit 17) 0 kanji shift 1 ASCII shift The multiple-block sequence indicator is defined as follows: b multiple block sequence indicator field (bit 16) 0 - no more blocks to come 1 - more blocks to come

230 Shift-Code Format (Kanji) The translate information descriptor (c) is defined as follows: d or e f The translate table number if a = 1 (ASCII shift): d translate table number field (bits 10 15) 0 3 translate table number not used 074 system standard (JIS 8) not used The character composition unit if a = 0 (kanji shift): e character pitch field (bits 10 12) 0 N/A characters per instruction (cpi) 2 10 cpi 3 5 cpi 4 N/A 5 6 cpi 6 N/A cpi (system standard) f character size field (bits 13 15) 0 2 N/A 3 7 points 4 9 points (system standard) 5 12 points 6 24 points 7 N/A

231 Shift-Code Format (Kanji) Shift-Code Examples The following are examples of two successive 9-bit characters CC: 0223 SP: 0360 a: 0 Kanji shift b: 0 No more blocks to come c: 074 e: CPI f: 4 9 Point CC: 0223 SP: 0361 a: 1 ASCII shift b: 0 No more blocks to come c: 074 d: 074 system standard Processing Shift-Code Format The SLIB symbolic read services process ASCII/ISO with embedded (shift-coded) kanji on input. The SLIB symbolic write services create ASCII/ISO with embedded (shift-coded) kanji on output. See the SLIB Programming Reference Manual. The SYSLIB SAR READ, ATREAD, and COM functions read ASCII/ISO with embedded (shift-coded) kanji on input and the SAR WRITE, ATREAD, and COM functions create ASCII/ISO with embedded (shift-coded) kanji on output. See the SYSLIB Programming Reference Manual

232 Shift-Code Format (Kanji)

233 Section 11 Symbolic Debugging Dictionary Format The Symbolic Debugging Dictionary (SDD) describes the data entities and statements of a program. This information is used by symbolic debugging systems during program development to enable the programmer to access program information in terms of the source program and by the Linking System for detailed parameter list checking. SDD is produced by compilers that support the use of Programmer's Advanced Debugging System (PADS). It is included in the generated object module as a bank which is marked as an SDD bank and which receives special handling by the Linking System. The contents of the SDD are used by PADS and FLIT to convert program addresses to symbolic form and to convert symbolic program references (entered by the user during a debugging session) into program addresses. Unlike versions of the SDD prior to the New Programming Environment, this version of the SDD supports the equivalent of "R"-option MAP, which is bank merging under the Linking System. Fields that contain offsets, which caused problems for "R"- option MAP have been associated with relocation information that allows the Linking System to keep them correctly updated when banks are merged. The SDD and its component tables are described in this section. A section is devoted to the overall SDD structure; one section is present for each component table. Data items within each component table are described in the corresponding section. Each section begins with a picture of the data structure described in that section. Words in the picture are represented graphically. Within each table or entry, whether currently fixed or variable in length, there is ordinarily a length field. The purpose of this field is to simplify automatic scanning of the SDD with a minimum of knowledge of the detailed SDD format. Exceptions have been made for fixed-length entries where insertion of a length field would have required significant expansion of an entry which may appear many times in a single SDD. When present, the length field ordinarily occupies Q4 of the first word of the table or entry. Again, exceptions have been made to accommodate length requirements exceeding 511 words (see SDD_LENGTH) and to accommodate short entries where no more than 63 words are required. In all cases, the length field occupies 112, Q4, or S6 of the first word; for tables and entries which specify their own lengths, one of these fields shall always be used

234 Symbolic Debugging Dictionary Notes: In this section the phrase "SDD address" is the word offset within the SDD of the related object. SDD addresses are not relocated; they are always relative to the beginning of an SDD and not to the beginning of the bank which contains it. In this document the phrase "LBN index" is an index into the SDD_LB_RELOCATION_TABLE. Certain fields of the SDD are described as requiring certain types of relocation. That means that the fields must be marked by the generating processor as receiving the indicated relocation. The indicated relocation (such as adjustment of logical BDIs or adjustment of offsets when banks are merged) is used during static linking. Reserved fields in the SDD entries (indicated by the word "reserved") must be set to zero Restrictions The following are the restrictions and the areas that are not covered by this design. ALGOL thunks are not supported in the current design. If ALGOL is added to the set of languages supported by PADS and the required ALGOL interfaces are designed, support for thunks can be added as a new addressing type. At most individual Logical Banks may be referenced in an SDD. Note that through the SDD LB_RELOCATION_TABLE, the Logical Bank Numbers themselves do not have this limit. The following are changes introduced in the SDD format after its initial definition: The procedure index is dropped; all links that used procedure index are converted to block number. VBL_FMT_TYPE = 10 is extended to include Pascal sets; FMT_HOST_TP is the (non-zero) host type of the set type for a set or zero for a bit string. VBL_FMT_TYPE = 13 is extended to include Pascal new user types (enumerated types); VBL ASSOC PTR identifies the permitted constants of the type. VBL_FMT_TYPE = 14 is extended to include Pascal subrange types; FMT_SGN_POS was overlaid with FMT_HOST_TP to define the base type of a subrange. VBL_FMT_TYPE = 37 is added for PLUS locator variables. VBL_FMT_TYPE = 38 is added for Pascal bound pointers. VBL_FMT_TYPE = 39 is added for typeless structures, VBL_FMT_TYPE = 40 is added for KANJI character strings. VBL_FMT_TYPE = 42 is added for variables that have been deleted by compiler optimization. VBL_FMT_TYPE = 43 is added for file definitions. For PLUS status variables (VBL_FMT_TYPE = 13), VBL_ASSOC_PTR was defined to be the SDD address of a nameless structure whose members are the permitted status constants of the variable. For Pascal subrange types (VBL_FMT_TYPE = 14), FMT HIGH_VALUE and FMT LOW VALUE are added to define the limits of the subrange, and FMT_FLAGS flag 3 is added to indicate whether the subrange bounds are present. FMT_HOST_TP is added to indicate the host type for subrange and set types

235 Symbolic Debugging Dictionary Level 10 This level provides the changes required for the New Programming Environment and for C-series (1100/60, 1100/90) extended mode. Some features of the old SDD format are removed because they become unnecessary in the new environment. Following are some specific changes: Level U Table blocking and table indexes. All provisions for overlay segments. The field PTRLOC_CTR_BDI is removed because location counter numbers are now logical bank numbers. References to location counters are changed to refer to banks and logical bank numbers. Where location counter numbers were in fields shorter than 18 bits, they are now expanded. All character string specifications are updated to allow specification of character attributes. VBL_FMT_TYPE = 40 is added for KANJI character strings. VBL_FMT_TYPE = 41 is added for UCS RTS pointers. VBL_FMT_TYPE = 42 is added for variables that have been deleted by compiler optimization. VBLFMTTYPE = 43 is added for UCS file definitions. VBL_FMT_TYPE = 44 is added for FORTRAN datalist. VBL_FMT_TYPE = 45 is added for FORTRAN entry variables. VBL_FMT_TYPE = 46 is added for UCS C strings. VBL_FMT_TYPE = 47 is added for UCS C pointers. VBL_FMT_TYPE = 48 is added for Pascal strings. VBL_FMT_TYPE = 49 is added for TIP Error History File time stamp. VBL_FMT_TYPE = 50 is added for TIP Error History File file name fields. The SDD_LINE_NUMBER table is re-formatted to support segmented line numbers as currently defined. An AFA_OFFSET_TABLE is added to permit access to specific fields in an AFA. Lexical level is added to the SDD VARIABLE TABLE. Static nesting level is added to the SDD_PROC_TABLE. Source program qualifier and file name is added to the SDD_HEADER TABLE. PROC_STACKTP = 5 (ISP stack) is added to the SDDPROCEDURE_TABLE to support the ISP. PROC_STACKTP = 6 (no activation stacking) is added to the SDD_PROCEDURE TABLE. REGSVREGI and REGSV_REGB is redefined when PROC_STACKTP = 5 to support ISP walkbacks. SDD_STATEMENT_TABLE LNM_TYPE = 5 is added to support the UFTN feature that permits subroutine calls to be replaced with a copy of the subroutine itself. This level extends the SDD to allow further functionality. The level number of the SDD is incremented to expand the block number fields in the procedure and variable tables. The size of the FMT_HOST_TP field in the Variable format table is incremented to 9 bits to agree with the size of VBL_FMT_TYPE

236 Symbolic Debugging Dictionary The block numbers in the procedure and variable tables are extended to 36 bits. The description of the implementation of PASCAL SET and ENUMERATED types are clarified. The description of the implementation of PLUS STATUS constants are clarified. An LB-relocation table is added to minimize the amount of relocation necessary during a static link, and to avoid the necessity of expanding all of the LBN fields in the SDD to 36 bits. References to LBNs are changed to LBN indexes. VBL_ADDR_TYPE = 15 is added to allow support of the PLUS and PASCAL TYPE definitions. Variable table entries with this addr type are presumed to be TYPE definitions. Addressing information is obtained from the variable table entries with VBL_FMT_TYPE = 48 that point to these entries. The PROC_PARM_TABLE is extended to include flags that allow a parameter to be identified as input, output, or inout. A flag is also defined to allow a PROC_PARM_TABLE entry to define a function result. A flag was added to the VBL_ARRAY_INFO header to allow a compiler to generate complete array information at each level of a structured variable (as occurs in prior SDD levels), or to generate the array information only at the appropriate higher levels. SDD address fields are extended to a full word to allow an SDD to grow beyond the word limit. File cycle and directory-id information are added to the file name information in the SDD HEADER Link String This is the format describing all strings contained within the SDD. 00 CODE_SET reserved STRING_LENGTH 01 TEXT Word 00 CODE_SET 9 bit unsigned integer. Figure Link String This field describes the code set in which TEXT is encoded. Current allowable values are: Value Code set 1 ASCII. Text will be in ASCII characters. Each character consists of 9 bits; a 0 bit followed by an 8-bit ASCII code. 16 JIS-16. Text is a string of KANJWIS-16 characters. Each character consists of two 8 bit values represented in 18 bits; a 0 bit followed by val1 followed by a 0 bit followed by val2 (where val1 and val2 represent the KANJIIJIS16 code)

237 Symbolic Debugging Dictionary STRING_LENGTH 18 bit integer. TEXT 17 Mixed ASCII and KANJI. The text is a series of link strings of type ASCII and KANJI/JIS-16. Currently this type is only found in an Item Entry of a Used-Set Table and used to represent items that consist of a mixture of ASCII and KANJI characters. For CODE_SETs 1 and 16 this is the length (in bytes) of the character string. For CODE_SET 17 this is the number of link strings contained in the text. n words SDD The text of the character string or link string. This field must be left justified. 00 SDD_VAL_CON 01 SDD_LEVEL reserved 02 SDD_ LENGTH 03 SDD_HEADER Word 00 SDD_VAL CON 4 ASCII characters. SDD_POINTER_TABLE SDD_PROCEDURE_TABLE SDD_VARIABLE_TABLE SDD_LABEL_TABLE SDD_STATEMENT_TABLE SDD_AFA_OFFSET_TABLE SDD_SOURCE_NANIE_TABLE SDD_USED_SET_TABLE SDD_LB_RELOCATION_TABLE Figure SDD This field is an identity validation constant. It contains the literal string value 'INFO'. SDD LEVEL 12 bit integer

238 Symbolic Debugging Dictionary This field is set to 11 in the version of the SDD described in this GDD. If changes are required in the SDD format, the value in SDD LEVEL will be incremented for each new SDD version. Word bit integer. This field gives the total length of the SDD in words. Word 02 SDD_HEADER This is the SDD header table. The header table identifies the element name and the processor name and the level which compiled the element. Word 03 SDD_POINTER_TABLE This table identifies and locates each of the following tables. All accesses to tables that follow the pointer table must be made through the pointers in this table. The tables that follow the pointer table may occur in any order; the identification and control information must appear at the beginning of the SDD as shown. SDD_ PROCEDURE_ TABLE This table describes each procedure of the element. The procedures are listed alphabetically to simplify the search for a name. SDD_VARIABLE_TABLE The variable table contains entries for variables and named constants declared or used in the element. Entries in the variable table are listed alphabetically. SDD_LABEL_TABLE The label table contains entries for all labeled statements in the element. The entries are listed by name according to the ASCII collating sequence (for alphanumeric labels) or numerically for languages with numeric labels. KANJI labels appear after all ASCII labels, ordered by the binary value of the KANJI character. A label table contains labels defined within a single bank; if there is more than one logical bank that contains generated code, there may be more than one label table. SDD_STATEMENT_TABLE The statement table identifies the starting and ending program relative addresses for the statements in the element. The entries are ordered by program-relative address. A statement table identifies code sequences within a single bank; if more than one logical bank contains code, there may be more than one statement table

239 Symbolic Debugging Dictionary Statements are identified by either an Internal Statement Number (ISN) or a source line number. ISN tables and source line number tables are not permitted to appear in an SDD. Refer to Section 11.7, SDD_POINTER_TABLE for more information on the PTR_TB_TYPE. SDD AFA_OFFSET_TABLE The AFA offset table provides the addresses, bit offsets, and bit lengths of fields in the AFA. There should be only one AFA offset table in an SDD. SDD_SOURCE_NAME_TABLE The source-name table contains link strings that contain the name of INCLUDE or COPY source elements. SDD USED_SET_TABLE The used-set table provides a link between the statement and variable tables. This allows a cross-reference showing where variables are set and used. There should be only one used-set table in an SDD. SDD_LB_RELOCATI ON_TABLE The lb-relocation table provides a means to reduce the amount of relocation necessary for items in the SDD. This table eliminates the necessity of relocation by the static or dynamic linker of other fields within the SDD. There must be only one lb-relocation table in an SDD. The SDD has been designed to allow easy modification for features that not supported by this version. In general, all variable-length fields within the SDD tables are located by pointer or offset fields. The result is that such variable- length fields can be re-ordered or can be preceded with new fields with little or no impact on existing code

240 Symbolic Debugging Dictionary SDD Header 00 reserved HDR_ID_LEN HDR_LENGTH 01 HDR_PROC_INFO 02 HDR FLAGS 03 HDR_PROC_NAME Word 00 HDR_ID LEN 12 bit integer HDR PROC_LEVEL HDR_ELEMENT NAME HDR VERSION NAME HDR_QUALIFIER HDR_FILE_NAME HDR_SOURCE_ELT_NAME HDRSOURCE_VER NAME HDR_SOURCE_QUAL_NAME HDR_SOURCEFILENAME HDR CWD PATHNAME HDR_OBJECT_PATHNAME HDR_SOURCE_PATHNAME HDR_TIME_STAMP Figure SDD_HEADER This field specifies the length to which user-supplied identifiers are truncated before comparison with identifiers in the SDD. This should be the maximum length that the compiler allows for identifiers in the source program. EIDR_LENGTH 12 bit integer The length in words of the Header Table including the first word. Word 01 HDR_PROC_INFO 36 bit integer This is the word offset in the SDD of a processor-defined information area. This information can be placed immediately after the Pointer Table. This is zero if there is no processor-define information

241 Symbolic Debugging Dictionary Word 02 HDR FLAGS 36 bit logical. Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 This field holds a set of one-bit flags that represent the processor call options of the compiler that produced the object module. Flags are defined only for certain specific options, which may have been obtained from sources other than the processor call option letters. If it is necessary for a processor to record its exact option set, that can be done in the area addressed by HDR PROC_INFO. Currently defined flags are: This flag is set if optimization may have caused movement or combination of code or if data entities may be retained in registers across statement boundaries. This flag is set if user names in the SDD are case-sensitive. This flag should be set only by compilers for case-sensitive languages. This flag is set if source names are present; HDR_SOURCE_ELT_NAME, HDR_SOURCE_VER_NAME, HDRSOURCE_QUAL_NAME, HDR_SOURCE_FILE_NAME, or HDR_SOURCE PATHNAME (depending on the value of bit 4). If the I option is specified on the compiler call line and no source name is specified, bit 3 is not set. This flag is set if pathnames are used instead of OS 2200 file names. If set, the source and object qualifier, file, element, and version names are replaced by HDRCWD_PATHNAME, HDROBJECTPATHNA1VIE, and HDR_SOURCE_PATHNAME (only if bit 3 set). This flag is set if SDD used-set information is present in the SDD. Bits 6 through 36 are reserved and must be set to zero. Word 03 HDR_PROC_NAME Link String The name of the processor that produced the object module

242 Symbolic Debugging Dictionary HDR PROC_LEVEL Link String The level identification of the processor that produced the object module. HDR_ELEMENT NAME HDR VERSION NAME HDR_QUALIFIER HDR_FILE_NAME Link_string The qualifier, file, element, and version names attached to the object module when it was compiled. These need not be the same as the element and version names at static link or execution time; these names are not updated if an element's name changes during operation. HDR_QUALIFIER should contain the directory-id if not STD. HDR_FILE_NAME should contain the absolute F-cycle of the file. HDR_SOURCE_ELT_NAME HDRSOURCE_VER NAME HDR_SOURCE_QUAL_NAME HDR_SOURCEFILENAME Link String The qualifier, file, element, and version name of the source program specified on the compiler call line. Present only if HDR_FLAGS bit 3 is set. HDR CWD PATHNAME Link String The pathname of the current working directory when the program was compiled. The current working directory concatenated with the source or object pathname identifies the source or object location. HDR_OBJECT_PATHNAME Link String The pathname of the object program as it appears on the compiler call line. HDR_SOURCE_PATHNAME Link String The pathname of the source program as it appears on the compiler call line. Only present if HDR_FLAGS bit 3 is set

243 Symbolic Debugging Dictionary HDR_TIME_STAMP 36 bit unsigned integer The creation date and time (in TDATE$ format) of this SDD. MONTH DAY YR(MOD64) Time in secs since midnight SDD Pointer Table 00 SDD_PTR_COUNT 01 SDD_PTR_LENGTH 02 Pointer table entries (one for each table in the SDD) Figure SDD Pointer Table Word 00 SDD_PTR_COUNT 36 bit integer This field contains the number of entries in the pointer table. Word 01 SDD_PTR_LENGTH 36 bit integer This field contains the number of words in the pointer table Pointer Table Entry 00 PTR_FLAGS PTR_TB_TYPE PTR_ENT_LEN 01 PTR_ TAB LEN 02 PTR_TAB_ENTRY_COUNT 03 PTR_TAB_ADDR 04 reserved PTR_BANK_NUM 05 PTR_CODE_ADDR Figure Pointer Table Entry Word 00 PTR_FLAGS 18 bit logical No flags are defined for this version of the SDD

244 Symbolic Debugging Dictionary PTR_TB_TYPE 9 bit integer The type of table pointed to. Table types are as follows: 1 Procedure Table 2 Variable Table 3 Label Table 4 Line Number Table 5 Internal Statement Number Table 6 AFA Offset Table 7 LB-relocation Table 8 Unit/OM Table 9 Used-Set Table (Only if HDR_FLAGS bit 5 is set) 10 Source Name Table Table types 4 and 5 are not permitted to appear in the same SDD. These tables are likely to be a major part of the size of an SDD; it seems unreasonable to burden a user with the mass storage overhead of retaining both. In addition, the logical bank entries in the procedure table contain pointers into the line number or ISN table. If that table is not unique for a given SDD, the logical bank entry format must be changed to provide pointers into both tables. Table type 10 contains the link strings for the INCLUDE and COPY element names in the code for this SDD. PTR_ENT_LEN 9 bit integer The length in words of this pointer table entry; all pointer table entries must have the same length, but that length may vary from one version of the SDD to another. Word 01 PTR_TAB_LEN 36 bit integer The length in words of the table identified by this entry in the pointer table. Word 02 PTR_TAB_ENTRY_COUNT 36 bit integer The number of entries in the table located by this entry

245 Symbolic Debugging Dictionary Word 03 PTR_TAB_ADDR 36 bit integer The SDD-relative word address of the table. Word 04 PTR_BANK_NUM 18 bit integer The LBN index in which addresses in the corresponding Label, Line Number, or ISN Table are located. This field is specified for table types 3, 4, and 5 only. There may be more than one Label, Line Number, or ISN Table in an SDD if code is generated under more than one bank. Word 05 PTR_CODE_ADDR 36 bit integer This field contains the offset from the beginning of the bank identified by PTR_BANK_NUNI of the first word described by the associated table. This field is specified for table types 3, 4, and 5 only SDD Procedure Table This table describes each procedure of the element. The procedures are ordered alphabetically to simplify name lookup. The SDD Procedure Table is a consecutive ordered list of SDD Procedure Table entries, one for each procedure. The number of entries is specified in PTR_TAB_ENTRY COUNT. 00 PROC_LINK_REG PROC_LB_OFF PROC NA ME_OFF PROC_ENT_LEN 01 PROC_STATIC_NEST PROC_LB_CNT 02 PROC_PARM_CNT PROC_PARM_OFF PROC_REGSV_OFF PROC_REGSV_CNT 03 PROC EP1 LB PROC_EPl_ADDR 04 PROC_EP2_LB PROC EP2 ADDR 05 PROC_EP3_LB PROC_EP3_ADDR 06 PROC_PROGTP PROC_SUBTP PROC_STACKTP reserved 07 PROC_BLOCK_NUM 08 PROC_PARENT_PTR PROC_LB_TABLE

246 Symbolic Debugging Dictionary PROC_NAME PROC_RE GSV_TABLE PROC_PARM_TABLE Figure SDD Procedure Table Note: The entries that follow word 8 are accessed through the offset fields in words 0-2. They may be generated in any order convenient for generating processor. Word 00 PROC_LINK_REG 9 bit unsigned integer The GRS address of the register which contains the return address when this procedure is entered. This field is zero for extended mode code, where the return address is not in a register. PROC_LB_OFF 9 bit integer The offset in the procedure table entry where the logical bank (LB) entries begin; zero if no LB entries exist. For example, for PROC_PROGTP = 4 (entry), the LB entries of the owner procedure are not duplicated. Also, if no code is generated for the program (for example, PROC_PROGTP = 5, block data), there will be no LB entries. PROC_NAME_OFF 9 bit integer Offset in procedure table entry where name begins. Zero if no name exists. PROC_ENT_LEN 9 bit integer The length in words of this procedure table entry. Word 01 PROC STATIC_NEST 18 bit integer The static nesting level of this block; describes the block nesting structure for this block described by this procedure table entry. This field is set only for PROC_PROGTP = 7 (Block) or 8 (Package), and is zero otherwise. It should be zero for blocks not contained within other blocks. This field contains the

247 Symbolic Debugging Dictionary count of parents defined by the chain of PROC PARENT_PTRs. The count identifies how far the parent chain goes up to find the storage owner of this Procedure Table entry's data. This field applies only to blocks and certain package types whose code is contained within the code range of another entity described in the Procedure Table entry and whose data is allocated in the storage owned by that entry or by one that contains it. PROC_LB_CNT 18 bit integer Number of logical bank entries that appear at offset PROC_LB_OFF in this Procedure Table entry. This will be the number of logical banks under which code is generated in the procedure and provided the procedure occupies a single contiguous sequence of words in each bank. Word 02 PROC_PARM_CNT 9 bit integer The number of entries in the Parameter Table. This is also the number of formal parameters for this procedure. PROC_PARM_OFF 9 bit integer The word offset in this Procedure Table entry where the parameter table (PROC PARM_TABLE) starts. Zero if no Parameter Table. PROC_REGSV OFF 9 bit integer The word offset in this Procedure Table entry where the register save table (PROC REGSV_TABLE) starts. Zero if there is no Register Save Table. PROC_RE GSV_CNT 9 bit integer The number of entries in the Register Save Table. Word 03 PROC_EP1_LB 18 bit integer The LBN index of the logical bank within which the Procedure entry point is located

248 Symbolic Debugging Dictionary PROC_EP1 ADDR 18 bit integer The word offset within the bank specified by PROC_EP_LB of the entry point of the procedure. This field is zero for procedures having instruction to be executed in the procedure after the prolog-type code (initialization, register saves, and so on) has been completed. This address is relative to the bank specified in PROC EP2 LB. This field is zero if there is no entry point. (This address is used if a break is set on a procedure name.) No entry point (for example, PROC_PROGTP = 5, block data). Word 04 PROC_EP2_LB 18 bit integer The number of the logical bank within which the first instruction after the prolog code of the procedure is located. For Ada, the entry point is before elaboration (elaboration is treated as user code). Word 05 PROC_EP3_LB 18 bit integer The number of the logical bank within which the first instruction of the epilog code of the procedure is located. PROC_EP3_ADDR 18 bit integer Relative address of the first instruction of the procedure's epilog code. Normally, this will be the address of the instruction which calls an epilog routine. This address is relative to the bank specified in PROC_EP 3_LB. This field is zero if there are no exit points. This address is included to allow setting a break on the exit of a procedure. Word 06 PROC_PROGTP 9 bit integer. Following table lists the types of the programs or procedures Type Description 1 Main Program 2 Subroutine (procedure)

249 Symbolic Debugging Dictionary Type Description 3 Function 4 Entry (alternate entry in FTN, ACOB) 5 Block Data (FTN) 6 Module (PLS) 7 BEGIN Block This is provided to serve as the owner procedure for module-level declarations. It is also used for module-level code. This is provided to serve as the owner procedure for module-level declarations. It is also used for module-level code. 8 Ada Package (specification or body) 9 *reserved* for Ada Task (body) 10 *reserved* for Ada Accept (body) PROC_SUBTP 9 bit unsigned integer The subtype of this Procedure Table entry is used only by Ada. Only packages can have specification in the SDD, but a package can have a specification and a body with the same name. Only this type distinguishes the two. Type Description 0 The Procedure Table entry is a body. 1 The Procedure Table entry is a specification. PROC_STACKTP 9 bit integer The type of stacks used are as follows: Type Description 0 No special activation record stacking. In that case, procedure call walkback can be done through PROC_LINK_REG and the register save information. 1 The PLS 1100 EXEC stack. 2 The ACOB walkback stack. 3 The basic mode UCS stack. 4 The extended mode UCS stack

250 Symbolic Debugging Dictionary Type Description 5 The ISP hardware stack (as used by UCS RTS). 6 No activation stack used. This is intended for blocks that are not called and are logically within a containing block. That means PROC_STATIC NEST is greater than zero and PROC_PARENT_PTR points to a higher level Procedure Table entry. This value is used for Ada (local) blocks and certain types of packages that are not called that are entered through the normal flow of the code. 7 Relative return 8 Virtual return 9 UCS Ada stack. This value is used for procedure entry types that are called: Ada subprograms, tasks, accept bodies, and certain types of packages (this is an extension to type 4, extended mode UCS stack ). Word 07 PROC_BLOCK_NUM 36 bit integer This is a unique identifying sequence number applied by the compiler to each block, subprogram, and package of the program. It is used when it is necessary to identify an unnamed block, such as an unlabelled BEGIN block in PL/I, during a debugging PROC_BLOCK_NUM which also links variable and label entries to their parent blocks. If PROC_PROGTP = 4 (entry), then PROC_BLOCK_NUM contains the block number of the owner. PROC_BLOCK_NUM = 0 for the outermost block of a compilation unit. The block number must be unique for all entries in a given Procedure table. The block number is the link between subprograms, blocks, and packages and the data they define or own, as described in the SDD Variable Table. Block numbers do not have to be ordered nor consecutive, but they must uniquely identify an entry in an SDD Procedure Table. Word 08 PROC_PARENT_PTR 36 bit integer The SDD address of the parent's Procedure Table entry, if the procedure is internal; zero otherwise. Special case, if PROC_PROGTP = 4 (entry), then this is a pointer to the owner's Procedure Table entry

251 Symbolic Debugging Dictionary A Procedure Table entry for Ada that does not have a parent, but is named, is the entity that defined the compilation unit. When null (0), PADS expects the entry to be the subprogram or package that defines the unit. (A corresponding entry always exists for such units in the Ada-Binder-generated Unit/OM Table in the SDD of the BINDER$ OM of an Ada program, whether the unit has an SDD or not). PROC_NAME Link String The name of the procedure in LINK_STRING format Procedure Logical Bank Table (PROC_LB_TABLE) The Procedure Logical Bank table is an array of 4-word entries; the upper bound is specified in PROC_LB_CNT. The entries in this table link a procedure to the code addresses and SDD_STATEMENT_TABLE entries corresponding to the statements of the procedure. A given word of code may be described by at the most one PROC_LB_TABLE entry at a given PROC_STATIC_NEST level. In general, each location should be associated with the innermost procedure which contains it. The individual entries are formatted as shown in the following figure. 00 LB NUMBER reserved LB_ENT_LEN 01 LB START ADDR LB END_ADDR 02 LB STMT_TABLE_START 03 LB_STMT_TABLE_END Word 00 LB_NUMBER 18 bit integer Figure PROC_LB_TABLE The LBN index of the code bank described by this entry. LB ENT_LEN 9 bit integer The length of this entry in words. For the current version of the SDD, this is always

252 Symbolic Debugging Dictionary Word 01 LB_START_ADDR 18 bit integer The starting relative address in the bank of the code for the associated procedure. LB_END_ADDR 18 bit integer The relative address of the code generated for the associated procedure in the bank of the last word. Word 02 LB_STMT_TABLE_START 36 bit integer The word offset in the line number or ISN table for this bank of the first entry for a statement in the associated procedure. Word 03 LB STMT_TABLE_END 36 bit integer The word offset in the line number or ISN table for this bank of the last entry for a statement in the associated procedure Register Save Table (PRO_REGSV TABLE) The Register Save table is an array of register save descriptors; the upper bound is in PROC_REGSV_CNT. The Register Save descriptors is processed in the order in which they are specified in the table. Order dependencies are permitted. REGSV_I REGSV_B REGSV_OFFSET REGSV_I and REGSV_B Figure PROC_REGSV TABLE Each split into two subfields: REGSV_Fx and REGSV REGx, of 2 and 7 bits, respectively

253 Symbolic Debugging Dictionary When PROC_STACKTP = 5, the GIB address in REGSV_REGx is interpreted to mean ISP registers with the following register-address correspondence: 0-15 The ISP v registers The ISP g registers The ISP vi registers The ISP el registers REGSV_FI The ISP s registers 2 bit unsigned integer. The following are the types of register restore mechanism required. Value Description 0 The register is saved and must be reloaded; the value specified by REGSV_B is loaded into the register. 1 The register must be decremented to obtain its previous value; the value specified by REGSV_B is the number to be subtracted from the current contents of this register. 2 The register must be incremented to obtain its previous value; the value specified by REGSV_B is the number to be added to the current contents of this register. REGSV_REG 7 bit unsigned integer. The address in GRS of the register for which the restoration mechanism is being described. REGSV_FB 2 bit unsigned integer. The following are the values to obtain the decrement or storage address

254 Symbolic Debugging Dictionary Value Description 0 Indirection to the automatic storage stack; in extended mode, REGSV_OFFSET plus the contents of the register REGSV_REGB is an offset relative to base register B1 and the indicated register is reloaded, decremented, or incremented from the indicated word. 1 Indirection; the value to be used as specified by REGSV_FI is the contents of the word whose address is REGSV_OFFSET plus the contents of register REGSV_REGB. The value is obtained directly; the value is REGSV_OFFSET plus the contents of register REGSV_REGB. 3 Indirection to the AFA. The value specified in REGSV_OFFSET is an index into the AFA_OFFSET_TABLE. The contents of the field described by that entry is used as the value. RE GSV_RE GB 7 bit unsigned integer. The GRS address of the register to use as register B. If REGSV_REGB = 0, zero is used for the contents of the register. REGSV_OFFSET 18 bit integer. The increment (REGSV_FI = 1) or offset (REGSV_FI = 0) to use in restoring the value of register I. Examples If register X11 is saved at offset 3 from the address in register X2, the five fields would be as follows: FI=0, REGI=013, FB=2, REGB=2, OFFSET=3 If offset 0 from X1 contains the address of a register save area, and A6 is saved at offset 5 in that area, the register save for A6 must be specified as two consecutive register save descriptors: FI=0, RE GI=022, FB=2, REGB=1, OFFSET=0 FI=0, REGI=022, FB=2, REGB=022, OFFSET=

255 Symbolic Debugging Dictionary In the previous example, if A6 is at offset 0 in the register save area, a single register save descriptor suffices: FI=0, REGI=022, FB=1, REGB=1, OFFSET=0 If XI was set by adding the contents of A15, which was saved at offset 1 from the updated address in Xl, the register save descriptor for A15 must be first. X1 can then be specified in either of two forms: FI=1, REGI=1, FB=2, REGB=033, OFFSET=0 or FI=1, REGI=1, FB=1, REGB=1, OFFSET= Procedure Parameter Table (PROC_PARM_TABLE) The Procedure Parameter table is an array of 2-word entries; the upper bound is specified in PROC_PARM_CNT. The entries in this table describe the formal parameters and the function result of the procedure. The individual entries are formatted as follows: REGSV_I PARM_VBL_ENT REGSV_OFFSET Figure PROC PARM TABLE FARM FLAGS 18 bit logical The first three bits have defined meanings. Num Name Description 0 Input 0 = The parameter value is undefined at procedure entry (the parameter is an output-only parameter). 1 = A value is defined for the parameter at procedure entry. 1 Output 0 = Changes to the parameter within the procedure do not affect the corresponding actual parameter (the parameter is input-only ). 1 = Changes to the parameter within the procedure affect the corresponding actual parameter (the parameter is declared output or inout ). Editing controls. 2 Result 0 = This entry describes a formal parameter for the procedure. 1 = This entry describes the result for a function (Input and Output flags are ignored)

256 Symbolic Debugging Dictionary PARM VBL_ENT 36 bit integer The SDD word address of an SDD variable-table entry which describes the formal parameter or function result Variable Table (SDELVARIABLE_TABLE) The Variable table contains entries for variables and named constants declared or used in the element. Entries in the variable table are ordered alphabetically. 00 VBL_FMT_OFF VBL STR_OFF VBL ARR OFF LB_ENT_LEN 01 VBL_FMT_TYPE VBL_NM_OFF VBL_ADDR_TYPE VBL_LEX_LEVEL 02 VBL ADDR1 03 VBLADDR2 04 VBL_BLOCK_NUMBER VBL ASSOC PTR overlaid with VBL_ENUM_OFF VBL ADDR3 overlaid with CONSTANT (used with VBL_ADDR_TYPE = 6) VBL ARRAY INFO VBL FORMAT INFO ITBL STRUCT INFO VBL NAME VBL ENUM INFO Figure SDD Variable Table The order of the array, format and structure information, and the name are arbitrary and can be modified as required to keep offsets from the beginning of the Variable table entry less than 512 words. VBL_ADDR3, if present, must be at offset 6 in the table. The only information which must be present for all entries is words 0-5; the name will also usually be present. VBL_FMT_OFF 9 bit integer The word offset from the beginning of this variable entry of the formatting and data type information for this variable. If the variable is a simple type not requiring additional information, VBL FMT OFF is zero

257 Symbolic Debugging Dictionary VBL_STR OFF 9 bit integer The word offset from the beginning of this variable entry of the structuring information for this variable. VBL_STRUCT INFO is present if the variable is structure or a member of a structure; otherwise, this field is zero. VBL_ARROFF 9 bit integer The word offset from the beginning of this variable entry of the array addressing information for this variable. If the variable is not dimensioned, VBL_ARR_OFF is zero. VBL_ENT_LEN 9 bit integer The length in words of this Variable table entry. VBL_FMT_TYPE 9 bit integer The type and editing characteristics of the variable. The value of this field determines the way in which this variable will be displayed by default and the way in which its value can be used. VBL_NM_OFF 9 bit integer The word offset from the beginning of this variable entry of the variable name field, VBL_NAME. Zero if there is no name. VBL_ADDR_TYPE 9 bit integer This is an addressing type code. This value determines the interpretation of the addressing field of the variable entry. VBL_LEX_LEVEL 9 bit integer The static lexical level of the block in which this variable is declared. A value of 0 specifies that lexical level is not to be used when processing this variable

258 Symbolic Debugging Dictionary VBL_ADDR1, VBL_ADDR2, VBL_ADDR3 36 bit integer. These fields are used to determine the address of the variable. The meaning of each field depends on the addressing type as described in a later section. VBL_ENUM_OFF 36 bit integer The word offset from the start of the variable table entry to the new Ada enumeration information section, VBL_ENUM_INFO, of a variable table entry. This field is only valid for VBL_FMT_TYPE - 55 (Ada enumeration). The new section, VBL_ENUM_INFO, contains seven fields that describe where the Ada runtime enumeration information is located. This field is overlaid with VBL_ASSOC_PTR. VBL BLOCK NUMBER 36 bit integer The number of the block in which this variable is declared. It identifies the package, subprogram, or block that owns the variable. The storage for a variable may be part of another containing block, package, or subprogram's storage. However, the other block, package, or subprogram does not own the variable (although it owns the owner). Variables declared at the global level have VBLBLOCKNUMBER = 0 (Pascal pre-defined identifiers are in block 0, the main program is block 1). VBL_ASSOC_PTR 36 bit integer The interpretation of this field depends on the value of VBL_FMT_TYPE. The values of VBL_FMT_TYPE for which the use of this field is currently defined are as follows. 10 PASCAL set type. When the host type is a new scalar type, VBL_ASSOC_PTR is used to identify the constants of the type. For the exact implementation, see the description for type PLUS status variables and PASCAL new scalar types. This field is used to identify the constants of the type. VBL_ASSOC_PTR is the SDD word address of a list of variable entries representing the constants. Each entry in the list has VBL_ADDR_TYPE = 6 and the integer value of the constant. The list is constructed through the VBL_STRUCT_INFO STR SIBLING link. The VBL_STRUCT_INFO STR_PARENT field for each entry points back to this variable table entry

259 Symbolic Debugging Dictionary 14 PASCAL subrange types. VBL_ASSOC_PTR is used when the variable's host type is a new scalar type to identify the constants of the type. For the exact implementation, see the description for type This field is used to distinguish between COBOL index-names and index data items. For an index-name, this field is the SDD word address of the variable table entry of the table indexed by this item. For an index data item, this field is zero to distinguish the item from an index- name. 37 PLUS locator variable. VBL_ASSOC_P FR is the SDD word address of the area in which the locator variable is bound. 38 PASCAL bound pointer. VBL_ASSOC_PTR is the SDD word address of an unnamed variable of the base type of the new pointer type. 47 VA-Bit-Word pointer (C pointer). If this pointer is bound to a variable, VBL_ASSOC_PTR contains the SDD word address of the variable. 54 Ada access variable. If this pointer is bound to a variable, VBLASSOC_PTR contains the SDD word address of the variable VBL_ADDRTYPE The VBL ADDR_TYPE field specifies how the fields VBL_ADDR1, VBL ADDR2, and VBL ADDR3 are used to find the starting location of a datum described by an SDD Variable Table entry. The following table describes the different addressing types supported by the SDD. When a field or value is enclosed in parentheses in the explanation, it denotes the contents of the field or of the word addressed by the value. For example, ((reg)+offset) denotes the address contained in the word whose address is given by the contents of reg plus the value of offset. Register values are the values of the registers in the procedure containing the variable. Addr type Addr1 Addr2 Addr3 Description 1 LBNI offset Static 2 LBN_I offset LVO Static banked 3 reg offset Based on register The variable is at offset from the beginning of the bank identified by LBN index LBN_I. Ada meaning: Datum start at offset word from the datum's compilation unit's global data frame. The variable is at offset offset from the word addressed by the link vector entry at offset LVO in the bank identified by the LBN index LBN I. The variable is at relative address (reg)+offset. In extended mode, basing on B1 is assumed. VBL_BLOCKNUMBER and VBL LEX LEVEL are used to determine where, the value of reg may be located in the walkback. addrl requires relocation by a UGS RTS defined tag

260 Symbolic Debugging Dictionary Addr type Addr1 Addr2 Addr3 Description 4 reg off off_2 Based indirect on register with offset 5 reg off_i off_2 Based on register The variable is at((reg)+off_1)+off_2. In extended mode, basing on B1 is assumed. Note: ((reg)+off_1) is a relative address. This is similar to type 3, but with an additional level of indirection. The variable is at(((reg)+off_1)±off_2). In extended mode, basing on B1 is assumed. Note: Both ((reg)+off_1) and (((reg) + off-1) + off_2) are relative addresses. 6 constant Short form immediate constant The entry is for a named computational constant (For example, PLUS define constant or FORTRAN parameter constant), and the value of the constant is short enough for the variable table entry to fit in 512 words. The constant's value begins in word 6 and replaces VBL_ADDR3. Variable position information, such as the name or VBL_FORMAT_INFO, follows the value. The type and length of the constant are indicated by VBL_FMT_TYPE and VBL_FORMAT_INFO. 7 0 ptr Long form immediate constant 8 offset ptr Based on variable 9 0 offset Explicitly based 10 offset ptr Member of structure The entry is for a named computational constant (For example, PLUS define constant or FORTRAN parameter constant), and the value of the constant is too long for the variable table entry to fit in 512 words. The value of ptr is the SDD address of the beginning of the constant. Long constants appear at the end of the variable table, after all variable table entries. The entry is for an implicitly based variable. The variable is located offset words after the address contained in the variable whose variable table entry is at SDD address ptr. The entry is for a based variable with no implicit base. The variable must have explicit pointer qualification when it is referenced; it is located offset words after the address in the explicit pointer. The variable is located offset words from the base of the variable whose Variable table entry is at SDD address ptr

261 Symbolic Debugging Dictionary Addr type Addr1 Addr2 Addr3 Description 11 reg off_1 off_2 Immediate RTS parameter The variable is contained within the SCS (Standard Calling Sequence) parameter packet located at relative address: $C($1 11(x)))'$C(SH2(x))+off_2; where, x is the location of the VA that points to the parameter list and is defined by $B1+$C(reg)+off_1. VBL_BLOCK_NUMBER and 12 reg off_1 off_2 RTS parameter VEL_LEX_LEVEL will be used to determine where the value of reg may be located in the walkback. Off_l and off_2 may require relocation by UCS RTS defined values. The variable is implicitly based on the SCS parameter packet located at relative address: $C($1-11(x))).$C($H2(x))+off_2; where, x is the location of the VA that points to the parameter list and is defined by $B1+$C(reg)+off_1. VBLBLOCKNUMBER and VBL_LEX_LEVEL will be used to determine where the value of reg may be located in the walkback. Off_l and off_2 may require relocation by UCS RTS defined values. 13 reg PLUS assigned to register Reg is the register to which the variable is assigned. This variable type is meaningful only when the program counter is within a block described by this SDD. 14 reg offset b-reg Based on register with B-register specified This address type is supported for extended mode only. The variable is at relative address (reg)+offset in the bank based on the specified B register. VBL_BLOCK_NUMBER and VBL_LEX_LEVEL are used to determine where the value of reg may be located in the walkback. Offset requires relocation by a UCS RTS defined tag. 15 b-reg PLUS assigned to B register B register to which the variable is assigned. Off_l and off_2 may require relocation by UCS RTS defined values

262 Symbolic Debugging Dictionary Addr type Addr1 Addr2 Addr3 Description 16 reg off off_2 RTS parameter on ALS The variable is implicitly based on the SCS parameter packet located at relative address: $B1+$C(x)+off_2; where, x is the location of the offset in the ALS that points to the parameter list and is defined by $B1+$C(reg)+off_l. VBL_BLOCK_NUMBER and VEL_LEX_LEVEL will be used to determine where the value of reg may be located in the walkback. Off_l and Off _2 may require relocation by a UCS RTS defined values. 17 reg off1 off_2 Immediate RTS parameter on ALS The variable is contained within the SCS (Standard Calling Sequence) parameter packet located at relative address: $B1+$C(x)+off_2; where, 18 offset in out Fixed Stack x is the location of the offset in the ALS that points to the parameter list and is defined by $B1 +$C(reg)+off, VBL_BLOCK NUMBER, and VBL_LEXLEVEL will be used to determine where in the walkback the value of reg may be located. off_l and off_2 may require relocation by UCS RTS defined values. Data starts at offset words in fixed stack frame of defining subprogram. FS_Base + FSF_Offset + offset Offset is word (Value is 1 bit to 2 words long.) In_out specifies the IN OUT status of the parameter

263 Symbolic Debugging Dictionary Addr type Addr1 Addr2 Addr3 Description 19 offset SDD_ptr DSP (Dynamic Separate Package) based on variable which involves a chain of addressing. FS_Base + FSF_Offset + offset Datum starts at offset word in fixed stack frame of defining subprogram. The datum is the start of an addressing chain used to access data declared in a separate package body. The data is in a separate dynamic stack frame allocated by the package body but owned by the containing subprogram. The DSP_Offset datum is the start of the addressing chain to the separate package body's data, but this chain of addressing is linked in the SDD in the reverse order of its processing; so PADS does not know that it must do special addressing until the end of that chain is examined. The first entry in the chain is an SDD entry for a user variable; its addressing information states that it is implicitly based on a compiler-generated Ada access variable. The Ada access variable is either implicitly based or its addressing type is DSP Offset (19); the chain always ends with an Ada access variable whose address type is DSP Offset. The number of entries in the chain tells PADS how deeply nested the variable is in separate packages. This is the number of entries in the Unit/OM Table PADS must run through to find the subprogram fixed stack frame containing the root pointer to the first dynamic stack frame of the chain. Each separate package of this chain has one dynamic stack frame associated with it. PADS uses the Unit/OM Table and the root subprogram's SDD Procedure Table entry to find the fixed stack frame which contains the root pointer whose address is specified by DSP Offset. To support symbolic debugging of separate packages, the separate package's root unit (the one with the starting pointer's fixed stack frame) must be compiled with at least the DEBUG/WALKBACK option if the separate package is compiled with any debug option on. Alternative: Issue a warning if the root unit needs to be recompiled with debug on. Late breaking news: The definition for DSP OFFSET has been changed to DSP_BASED_ON_VARIABLE

264 Symbolic Debugging Dictionary Addr type Addr1 Addr2 Addr3 Description Addrl is still zero, addr2 is still the offset, but addr3 is an SDD ptr to a variable entry in the SDD; this type now behaves like BASED_ON_VARIABLE but still signifies the start of an addressing chain through, although PADS will now know the DSP addressing is to take place when it first sees the variable and not when it gets to the end of the chain of variables. offset in_out Fixed Stack by Reference parameter (FSR) $C($H1(t)) = $C($H2(t)) t = FS Base + FSF_Offset + offset Offset is word (Contains a VA to the parameter.) In_out specifies the IN OUT status of the parameter. 21 offset in_out Parameter List by Value (PLV) Parameter begins at offset words from start of parameter list. Maximum allowed is two words. FS_Base + $C(FS_Base + FSF_Offset + PL_OFFSET) + offset In out specifies the IN OUT status of the parameter. 22 offset in_out Parameter List by Reference (PLR) Parameter pointed by VA at offset words from start of parameter list. $C($111(t)) = $C($H2(t)) t = FS_ Base + $C(FS_Base + FSF_Offset + PL_OFFSET) + offset In_out specifies the IN OUT status of the parameter

265 Symbolic Debugging Dictionary Addr type Addr1 Addr2 Addr3 Description 23 offset bit_off bit_len Member of Structure, Indirect (MoSI) 24 offsetl offset2 PLCOFF 25 Unknown address Used to address structure members whose offset within the structure is in another member of the structure (unknown start address). The bit_len sized cell located at offset words and bit_off bits from the start of the item's immediate parent contains the number of words of the offset of the start of this item from the start of its immediate parent. The cell and the item do not have to start on a word boundary, but the offset of the item from the start of its parent is always in words. Although this is runtime-known information, Ada Codegen says that they can generate this for, or due to, a limited number of data types, such as STRING(1..N). The Ada PRM must describe the cases. Offset of parameter is contained in the parameter list. The variable is at offset2 words from the VA contained in the word offset1 words from the start of the defining subprogram's parameter list. See VBL_ADDR_TYPE = 21 (PLAT). This status is reserved for future Ada support. Is used to mark variables in the SDD that exist in the Ada program but whose addresses the Ada compiler cannot yet be described in an SDD; PADS will issue a warning or remark to this effect when such a variable is used in a reference (DISPLAY ALL VARIABLES should just not display such variables and issue no messages). This is to avoid messages stating that the variable is not found or does not exist, which will occur if the Ada compiler puts nothing in the SDD for such variables. A variable whose address is not known may still have an SDD-described length, which could be used by a low-level debugging, Ada user

266 Symbolic Debugging Dictionary For Ada, the starting location described in the SDD is based on the four storage areas defined for UCS Ada runtime support: 1. Fixed Stack (FS) One per task. Current frame of task is pointed by X2. Stack base is pointed by B2. PADS saves the value of B2 in the PADS task information. 2. Dynamic Stack (DS) One per task. Pointed by the Fixed Stack of a task. Current frame of task is pointed by X3. Stack base is pointed by B3. PADS saves the value of B3 in the PADS task information. 3. Heap Bank (HB) A large data bank, but not based on MOD 64 BDI addressing. One per program. Contains Task Control Blocks (TCBs); TCB of current task is pointed to by B7. Heap bank base is pointed by B9. PADS saves the value of B9 in the PADS task information. 4. Global Data (GD) Can be a large data bank with MOD 64 BDI addressing. One per program. Contains TCB of main program. Global data bank base is pointed by B8. PADS saves the value of B8 in the PADS program information. Data is also passed as parameters. Parameter information resides in registers or in parameter lists. Data can also be renamed. Renamed data is treated as implicitly based data. The implicit pointer can point to data in any of the Ada data banks and can contain an offset, a VA, or a VA-Bit-Word value. When the implicit pointer contains an offset, the SDD entry must indicate which bank it is offset within

267 Symbolic Debugging Dictionary PADS uses the following names to refer to the addressing entities required to address the data in the four Ada bank types. These names represent the value required to do the addressing. The value is in a register during the program, but may not be in that register when PADS is required to address a datum based on it. The name refers to the value that PADS must acquire, but does not specify how PADS acquires that value. Names Addessing Entity FS Base FSF Offset DS_Base DSF_Offset GD Base GDA_Offset Fixed Stack Base VA: B2 Fixed Stack Frame offset: X2 Dynamic Stack Base VA: B3 Dynamic Stack Frame offset: X3 Global Data Base VA: B8 Heap_Base Heap Base VA: 139 TCB Base Display_Offset Global Data Area offset: X8 (This is a VA, but used often as an offset.) (Each unit has its own GDA.) Task Control Block Base VA: B7 Offset of static nesting display in TCB. Given to PADS by Ada RTS on call to PADSSINIT. The IN and OUT parameter attributes are specified by the VBL_ADDR3 field of the Ada SDD parameter addressing types. The values of VBL_ADDR3 are interpreted as follows. 0 IN OUT status unknown 1 IN only 2 OUT only 3 Both IN and OUT PL_OFFSET is the offset (5) of the word in the fixed stack frame that contains the offset of the parameter list in the same fixed stack bank. It is specified in the PADS/Ada Runtime Table. (The ADDR1 field could contain this value, if necessary) VBL Format Type The format type field defines the data type of an item and its formatting characteristics when displayed. If VBL_FMT_OFF is zero, then this field describes the item type and formatting completely. Otherwise, VBL FMT_OFF points to the VBL_FORMAT_INFO section of this variable table entry, where additional information is provided

268 Symbolic Debugging Dictionary The data and formatting types are as follows. Type Description 1 Single precision signed integer, one word. Modifiers: none. 2 Double precision signed integer, two words. Modifiers: none. 3 Single precision floating point, one word. Modifiers: none 4 Double precision floating point, two words. Modifiers: none 5 Single precision complex float, two words. Modifiers: none 6 Double precision complex float, four words. Modifiers: none 7 Condition (FORTRAN logical), one word. Modifiers: none 8 18 bit relative pointer, H2 of one word. Modifiers: none 9 Lock (Test-and-Set cell), one word. Modifiers: none 10 Loft justified hit Qtring (PUT) nr ant (PAgl'AT ). Modifiers: length, offset (bits), host type 11 Numeric logical (PLUS logical). Modifiers: length, offset (bits). 12 Condition (PLUS). Modifiers: length, offset (bits). 13 PLUS status or Pascal new user types. Modifiers: length, offset (bits). 14 Bit numeric (ACOB exact binary, PLUS integer, Pascal subrange,ada integer). Modifiers: length, offset (bits), sign type, host type, range. 15 ASCII character string. Modifiers: length, offset (characters), justification, editing. 16 FILEDATA character string. Modifiers: length, offset (characters), justification, editing. 17 ASCII character numeric. Modifiers: length, offset (characters), scale, sign position, sign type, scale sign, editing, decimal length

269 Symbolic Debugging Dictionary Type Description 18 FIELDATA character numeric (ACOB). Modifiers: length (characters), offset (characters), scale, sign position, sign type, scale sign, editing. 19 ASCII decimal scaled (ACOB computational). Modifiers: length (bits), offset (characters), scale, decimal length, sign type, scale sign. 20 FILEDATA decimal scaled (ACOB computational-4). Modifiers: length (bits), offset (characters), scale, decimal length, sign type, scale sign. 21 Packed decimal (ACOB computational-3). Modifiers: length, offset (characters), scale, sign type, scale sign, decimal length. 22 Binary scaled (PL/I fixed binary). Modifiers: length, offset (9-bit bytes), scale, decimal length (9-bit bytes), sign type, scale sign. 23 Common block (FORTRAN). Modifiers: none. 24 Miscellaneous aligned (PL/I, PLUS area variables). Modifiers: length (words). 25 Absolute pointer; this should always be 18, 24 or 36 bits in length. Modifiers: length, offset (bits). 26 PCT pointer. 27 Pointer. Modifiers: length, offset (bits). Modifiers: length, offset (bits). 28 Decimal scaled binary. Modifiers: length, offset (9-bit bytes), scale, decimal length (9-bit bytes), sign type, scale, sign. 29 Complex binary scaled. Modifiers: length, offset (9-bit bytes), scale, decimal length (9-bit bytes), sign type, scale sign. 30 Complex decimal scaled binary. Modifiers: length, offset (9-bit bytes), scale, decimal length (9-bit bytes), sign type, scale sign. 31 Complex ASCII character numeric. Modifiers: length, offset (characters), scale, sign position, sign type, scale sign, editing. 32 Queue lock, one word. Modifiers: none

270 Symbolic Debugging Dictionary Type Description 33 Source program error; this entry represents a variable for which a source program error was detected. The variable cannot be accessed during debugging. Modifiers: none. 34 COBOL index-names and index data items. For index-names, the variable table address of the table indexed by this item is contained in VBL_ASSOC_PTR. Modifiers: none. 35 Unaligned single precision floating point; length is one word. Modifiers: offset (bits). 36 Unaligned double precision floating point; length is two words. Modifiers: offset (bits). 37 PLUS locator variable. VBL_ASSOC_PTR is the SDD word address of the area within which the variable locates allocations. Modifiers: offset (bits), length. 38 PASCAL bound pointer. VBL_ASSOC_PTII is the SDD word address of a compiler-generated variable of the type identified by the pointer variable. Since the compiler-generated variable cannot be accessed directly on behalf of the user, there can be just a single variable for all pointer variables that identify allocations of that type. The name of the compiler-generated variable will be the identifier of the type to which the pointer is bound. Modifiers: offset (bits) and length. 39 Miscellaneous unaligned. Used for PL/I structures and Pascal records which need not begin on a word boundary. Modifiers: length, offset (bits). 40 KANJI character string. Each character is 18 bits long. Modifiers: length (characters), offset (units), editing, justification. See FMT_FLAG number 5 for the offset unit to use (9 or 18 bits). 41 UCS pointer. The structure described by this entry is a 3 word UCS RTS parameter packet. H1 of the second word of this packet contains the BDI of the variable located by the packet, H2 contains word offset and S6 of the first word contains bit offset. The third word of the packet contains a word value. 42 Deleted by compiler optimization. Modifiers: none. 43 UCS file. Used to permit qualification of variable references by filename. Modifiers: none. 44 FORTRAN DATALIST. Modifiers: TBD. 45 FORTRAN ENTRY variable. Modifiers: length, offset (bits)

271 Symbolic Debugging Dictionary Type Description 46 C string. UCS C character string. Modifiers: length, offset(characters). 47 VA-Bit_Word pointer (C pointer).the data type used by the UCS RTS to point to a C data item. This structure consists of two words on a word boundary. The first word is a 36 bit VA. The second word consists of three fields: The first 6 bits (S1) is a bit offset for the data item. The next 6 bits(s2) is reserved and should be zero. The next 24 bits (S3 through S6) is a word offset. If this pointer is bound to a variable, VBL_ASSOC_PTR contains the SDD word address of the variable. Modifiers: offset (bits). Ada generates these as one of the pointer types for implicitly based RENAMES data. Ada uses the unbound pointer form and does not name the pointer. The pointer contains a VA-Bit-Word pointer value, which can point to any bit; this is used to point to RENAMES data that is not word aligned. This pointer is always two words long and can start on any bit of a word, but Ada Codegen will always word align it because it is not user accessible. 48 Variable Length UCS Pascal string. The first word of the string is the current length of the string in bits, followed by an ASCII character string. Each character is 9 bits long. Modifiers: size (characters), offset (characters). 49 TIP Error History File Time Stamp. Two word binary representation of the time in nanoseconds from January 1st, Modifiers: none. 50 TIP Error History File Filename String format file qualifier left justified, space filled, FIELDATA character string in first two words (12 FIELDATA characters), followed by format file name left justified, space filled, FIELDATA character string in next two words (12 FIELDATA characters). Modifiers: none. 51 Ada fixed point. Modifiers: length(bit), offset (bit), scale, decimal length (decimal digits- Ada Codegen may not know this for the first release, a value of zero indicates the decimal length is unknown and that PADS can treat it as it wishes), sign type, scale sign, range (new for Ada). The length must be in the range of 0 to 36 bits. Note: Ada Codegen will not set the range information for the first release; the field is reserved for future use. (The decimal DELTA becomes a binary scale factor in the range 1059 to 988. With that and the decimal length, defined as the number of decimal digits in an arithmetic variable, PADS should be able to display the variable correctly.)

272 Symbolic Debugging Dictionary Type Description 52 Unaligned, unbound ASCII character. Modifiers: length (bits), offset (bits). The length must be in the range of 0 to 36 bits. The ASCII character is right-justified and zerofilled (on the left) within the given number of bits. If this type needs to be more generalized later, fill-type and justification modifiers can be added. The last dimension of any array information for a datum of this type is not treated as string information. PADS do not permit substring operations on data of this type. 53 Unaligned ASCII character string. Modifiers: offset (bits). The length is assumed to be 9 bits, but the offset can specify any bit of a word. The last dimension of any array information for a datum of this type is treated as string information. PADS permits substring operations on data of this type. To represent a string, the datum's SDD entry must have at least one dimension described in a VBL_ARRAY_INFO entry. The rightmost (last) dimension describes the string aspects of the datum. The lower bound specifies the starting index of the string (for Ada this must be one or greater, but PADS has no such restriction: the starting index can be zero or less). The upper bound specifies the ending index. The length of the string is the upper bound less the lower bound plus one: ub-lb +1. If the INQUIRE VARIABLE command were to display lengths, which it does not, it would display the length of a datum of this type as its string length and not as the length of one element, which is 9 bits. A DISPLAY $LLA (string-variable) shows the address and the bit length of the string-variable. The length in bits is the length of the string. For example, C: STRING(6..10) has a starting index of 5 and an ending index of 10; the lower bound of the string's last dimension is 5 and the upper bound is 10. Its length is 6 characters. If the string indexes are unknown, the last dimension specifies how to get their runtime values. 54 Ada access variable which contains a full VA or an offset into one of the four Ada runtime data banks. One bit to 36 bits (one word) long, depending on FMT_ACCESS_INTO. This is a bound pointer for normal Ada access variables and an unbound pointer when used for RENAMES variables and for other implicitly based data (such as data in the dynamic stack based by the compiler on a cell in the fixed stack). If this pointer is bound to a variable, VBL_ASSOC_PTR contains the SDD word address of the variable. Modifiers: offset (bits), length (bit), Ada bank type. Note: An Ada user's access variables are always bound and are a VA or a heap offset; all other types are compiler-generated

273 Symbolic Debugging Dictionary Type Description 55 Ada enumeration. Modifiers: length (bits), offset (bits). A new field, VI3L_ENUM OFF, is the word offset from the start of the variable table entry to the new Ada enumeration information section, VBL_ENUM_INFO, of a variable table entry. This field is only valid for VBL_FMT_TYPE = 55 (Ada enumeration) and it overlays the VBL_ASSOC_PTR field. The new section, VBL_ENUM_INFO, contains seven fields that describe where the Ada runtime enumeration information is located. These fields are described below in the VBL_ENUM_INFO section. An unnamed enumeration variable is used to describe the array bounds for a dimension that is specified by an enumeration type. The Ada runtime description of an enumeration datum is contained in the unit that defined the enumeration type. A cell in or at the end of the global data area of a unit that has a variable of that enumeration type points to the global data area of the unit that contains the runtime description. This extra cell is one of the few effects on generated code caused by providing debugging information. If the extra cell already exists because it was required by the generated Ada code, it does not need to be generated again by Ada Codegen. 56 Ada exception. Modifiers: None VBL Format Info The VBL_ADDR_TYPE field specifies the unique number for the exception in the Ada program: 6 (short form immediate constant). One word in length. 57 Ada task. Modifiers: length (bits). *Reserved* An Ada task variable contains information about a task that the user can display through the INQUIRE TASK task-name command. At a minimum, PADS expects the task variable to contain its taskid. The field location and size of the task-id is at a fixed location and length within the task variable at a location specified in the SDD (treating the task variable as a structure with the task-id as one component), at a location from the start of the task variable specified in the PADS/Ada Runtime Information table passed to PADS$INIT, pointed to by some information in the task variable, or in some other manner accessible from the task variable. There may not be a current method for doing this. The information in the variable format information section modifies the basic information held by VBL_FMT_TYPE. This information is addressed through VBL_FMT_OFF, the word offset from the beginning of the variable entry to the format information area. If VBL_FMT_OFF equals zero, this information is not present. 00 reserved FMT_SGN_POS FMT_HOST_TP FMT_ENT_LEN

274 Symbolic Debugging Dictionary 01 FMT_SCL FML DEC--TEN FMT_LEN_TP FMT_SGN_TP FMT_OFF_TP FMT_FLA GS 02 reserved FMT_ACCESS_INTO FMT ADASCALE 03 FMT_LEN_ADDR1 04 FMT_OFF_ADDR2 05 FMT LEN_ADDR2 06 FMT_LOW_VALUE FMT_HIGH_VALUE Figure VBL_FORMAT INFO Words beyond word 0 of this entry are present only if the information in them is required for the variable. The determination of which fields are present is based on VBL_FMT_TYPE in the main I body of the variable table entry. If a later field is present, all earlier fields must also be present. Word 00 FMT_SGN_POS 9 bit integer. The sign position in a character numeric item of length n. For a leading sign, FMT_SGN_POS = 1; for a trailing sign, FMT_SGN_POS = n. FMT_HOST_TP 9 bit integer. This field is used for VBL_FMT_TYPE = 10 to distinguish between bit strings and PASCAL sets. The value in this field is the host type of the set, selected from the set of values of VBL_FMT_TYPE. If the value of FMT_HOST_TP is zero, the variable is a bit string rather than a set

275 Symbolic Debugging Dictionary The values currently recognized for FMT_HOST_TP when VBL FMT TYPE = 10 are as follows. 13 SET OF PASCAL new scalar type. VBL ASSOC_PTR is used as for VBL_FMT_TYPE = 13 to identify the set of possible values of the host type. 14 SET OF INTEGER. The bit-field is interpreted as a set of integers, the bit offset corresponding to the integer value. 15 SET OF CHAR. The bit_field is interpreted as a set of character values, the bit offset corresponding to the ordinal value of the character. FMT_HOST_TP is used for VBL_FMT_TYPE = 14 to distinguish between bit numeric and Pascal subrange. FMT_HOST_TP = 0 indicates a bit numeric variable; non-zero values identify the host type. For FMT_HOST_TP = 13, VBL_ASSOC_PTR is used as for VBL_FMT_TYPE = 13 to identify the host type. FMT_ENT_LEN 9 bit integer. The number of words in this entry. Word 01 FMT SCL 6 bit unsigned integer. The scale factor for arithmetic variables. The sign of the scale factor is determined by a bit in FMT_ FLAGS. If positive, the radix location is moved left; if negative, the radix location is moved right. FMT_DEC_LEN 6 bit integer. The number of decimal digits in an arithmetic variable. FMT_LEN_TP, FMT_LEN_ADDR1, FMT_LEN_ADDR2 Defines the length of the variable. For an array, this is the length of one element

276 Symbolic Debugging Dictionary FMT_LEN_TP 6 bit integer. Determines the interpretation of FMT_LEN_ADDR1 and FMT_LEN_ADDR2 in computing the length of the variable. The meaning of the length types are as follows. Type Addr1 Addr2 Description 1 Const The length is constant. 2 LBN_I Addr Halfword-Static 3 Reg Off Quarterword-Static 4 Reg Off Halfword-Dynamic 5 Reg Off Word-Dynamic 6 0 Ptr Variable The length is contained in H2 of the word at address Addr in the bank identified by LBN index LBN_I. The length is contained in Q2 of the word at address Addr in the bank identified by the LBN index LBN_I. The length is contained in H2 of the word at address (Reg)+Off. The length is contained in the word at address (Reg)+Off. 7 0 Addr Length in RTS parameter. The length is contained in the variable whose variable table entry is at SDD address Ptr. 8 Offset Ptr Length is offset words from start of variable described in the Variable Table entry at offset Ptr. *reserved* 9 Offset Length is in the parameter list at word offset from the start. See VBL ADDRTYPE = 21 (PLV). *reserved* 10 Unknown length. It is used to mark variables in the SDD that exist in the Ada program whose length cannot yet be described in an SDD by the Ada compiler; PADS will issue a warning or remark to this effect. This is to avoid messages stating that the variable is not found or does not exist, which will occur if the Ada compiler puts nothing in the SDD for such variables. FMT_SGN_TP 6 bit integer. A variable whose length is not known can still be used to address a dependent variable; for example, a structure member's address and length may be known and its parent's address may be known but the parent structure may have an unknown length due to variable-extent members

277 Symbolic Debugging Dictionary The type of sign representation in an item. Type Description 0 Not present 1 Unsigned 2 Separate sign 3 "Overpunch" negative 4 "Overpunch" positive Used for COBOL numeric to indicate that the sign resides in a separate byte. Used for bit numeric (PLUS integer, PASCAL subrange,...) to indicate the existence of a sign bit. The sign is assumed to be positive unless the FMT SGN_POS character includes a negative indicator. The sign is assumed to be negative unless the FMT SGN_POS character includes a positive indicator. FMT OFF_TP 6 bit integer. This field determines the interpretation of FMT_OFF_ADDR1 and FMT_OFF_ADDR2 in the computation of the position of the variable in the first word it occupies. The meaning of the offset types are as follows: Type Addr1 Addr2 Description 0 Not present 1 0 Const The offset is a constant. 2 LBNI Addr The offset is contained in S2 of the word at address Addr in the bank identified by the bank identified by LBN index LBN_I. 3 LBN_I Addr The offset is contained in bits of the word at address Addr in the bank identified by the LBN index LBN_I. 4 Reg Off The offset is contained in S2 of the word at address (Reg)+Off. 5 Reg Off The offset is contained in bits of the word at address (Reg)+ Off. 6 0 Ptr The offset is contained in the variable whose variable table entry is at SDD address Ptr. 7 0 Addr Offset in RTS parameter

278 Symbolic Debugging Dictionary FMT OFF_TP 6 bit logical. Each of the six bits has the following defined meaning: Num Name Description 0 Justification 0 = the value is - left justified. 1 = the value is - right justified. 1 Scale Sign 0 = the scale factor is positive. 1 = the scale factor is negative. 2 Edited 0 = the item is not edited. 1 = the item's picture includes editing controls. 3 Range 0 = no range limits present 4 Date Time 0= edited as date 1 = lower and upper bounds are present in FMT LOW VALUE and FMTHIGHVALUE. 1 = edited as time (Valid only for VBL_FMT_TYPE = 49). 5 Offset Unit Unit to use for offset in VBL_FMT_TYPE = 40 FMT_ACCESS_INTO 9 bit integer. 0 = 18 bits (offset in Kanji characters). 1 = 9 bits (offset is in bytes). Determines the type of Ada bank that the access variable points into. Used only if VBL_FMT_TYPE = 54 (Ada access variable). Type Description 0 No bank. Although the value can be used and set, it cannot be directly used to point to data. (Ada may never use this value). 1 Unknown bank. The access variable is 36 bits long and contains a full VA. Only generated for user-defined access variables with the non_ada_access pragma applied. Not used for compiler-defined variables for RENAMES

279 Symbolic Debugging Dictionary Type Description 2 Ada runtime heap bank (stack base is in B9). The access variable is 1 to 36 bits in length and contains an offset into the heap bank. 3 Ada runtime global data bank (stack base is in B8). The access variable is 1 to 36 bits in length and contains an offset into the global data bank. 4 Ada runtime fixed stack bank (stack base is in B2). The access variable is 1 to 36 bits in length and contains an offset into a fixed stack bank. FMT_ADA SCALE 18 bit integer. The scale factor for Ada arithmetic variables. The range of valid Ada scale factors is to 988, which is too large to fit in FMT SCL. Therefore, this field was created. The sign of the scale factor is determined by a bit in FMT_FLAGS. If positive, the radix location is moved left; if negative, the radix location is moved right. FMT_OFF_TP, FMT OFF ADDR1, FMT_OFF_ADDR2 Defines the starting position of the variable in its first word of storage. FMT_LEN_ADDR1 18 bit integer Used in determining the length of the variable; see FMT_LEN_TP. FMT OFF_ADDR1 18 bit integer. Used in determining the offset of the variable from the beginning of its first word; see FMT OFF_TP. FMT_OFF_ADDR2 36 bit integer. This field is used in computing the position of the item; See FMT OFF TP. FMT_LEN_ADDR2 36 bit integer. This field is used in computing the length of the item; See FMTLENTP

280 Symbolic Debugging Dictionary FMT_LOW_VALUE N words. Word length is determined by variable length and variable type. This field holds the lowest value the described data item can legally hold. Arithmetic values are extended to be a multiple of a word in length, padded with zeroes or sign bits in the manner natural to the type. All other types are left-justified in a field to the nearest adequate multiple of a word in length with padding bits on the right set to zero. Only present if FMT_FLAGS(3=range) = 1. Ranges are used with VBL_FMT_TYPE = 14, and (reserved for Ada), 3,4,35,36,51. FMT_HIGH_VALUE N words. Word length is determined by variable length and variable type. This field holds the highest value the described data item can legally hold. See FMT_LOW_VALUE. Only present if FMT_FLAGS(3=range) = VBL Array Info The VBL_ARRAY INFO SDD entry contains the description of a datum's array attributes, such as bounds, spans (multipliers), and virtual origin. A dimension is specified by a range of values (upper and lower bound) or by an enumeration type whose range of values is its ordinal range (0 to n) but which can be indexed by the values of the enumeration type's literals. The array information section has a long and a short form. The short form is used if the virtual origin displacement, multipliers, and bounds are constants and the bounds fit into 18 bit fields. Otherwise the long form is used. If VBL_ARR_OFF equals zero, this information is not present. 00 ARR_TP ARR_DIM ARR_UNITS reserved ARRPROP ARR_ROW_ COL 01 ARR_VO_D I SP 02 ARR_MULT(1) 03 ARR_LBOUND(1) ARR_UB OUND (1) 04 ARR_ENUM(1) 05 Additional multipliers and bound pairs Figure VBL_ARRAY_INFO Short form

281 Symbolic Debugging Dictionary ARR_TP 6 bit integer. Array type. 1 Short form of array information entry. 2 Long form of array information entry. 3 Short form of array information for Ada array with at least on enumeration based dimension: ARR ENUM, if nonzero, points to an unnamed SDD Variable Table entry of VBL_FMT_TYPE = 55 (Ada Enumeration) that describes the upper and lower bound of the dimension. The normal upper and lower bound information must be filled in, since it describes the true upper and lower bound for the dimension. 4 Long form of array information for Ada array with atleast on enumeration based dimension: ARR_ENUM, if nonzero, points to an unnamed SDD Variable Table entry of VBL_FMT TYPE = 56 (Ada Enumeration) that describes the upper and lower bound of the dimension. The normal upper and lower bound information must be filled in, since it describes the true upper and lower bound for the dimension. ARR DIMS 6 bit integer. The number of dimensions for the variable. This is also the number of multipliers and bound pairs that follow. ARR UNITS 6 bit integer. The unit size (in bits) for ARR_VO_DISP and ARR MULT(i). The usual values are 1, 6, 9, 18, and 36. ARR_PROP 6 bit integer. This is a flag that identifies the structure of array information for the variable. If ARR_PROP = 0, complete array information for the array must be included at every level of a structured variable. If ARR_PROP = 1, the array information of the parents of the variable is used in calculating the address of this variable (array information is propagated downwards)

282 Symbolic Debugging Dictionary ARR_ROW_COL 6 bit integer. This is a flag that distinguishes between row-oriented arrays and column-oriented arrays. ARR_ROW_COL = 0 means that the last dimension varies most rapidly when the array is scanned in storage order (this is the most common format, as used in PL/I, COBOL, and so on.). ARR_ROW_COL = 1 means that the first dimension varies most rapidly when the array is scanned in storage order, as in FORTRAN. PL/I uses ARR_ROW_COL = 0 for isub-defined arrays as well, since they are treated like all other arrays in PL/I vector operations. ARR_VO_DISP 36 bit integer. The number of units (See ARR_UNITS) to subtract from the address of the first element of the array to get the address of the (0,...,0) element of the array (its virtual origin). ARR_MULT(i) 36 bit integer. The factor by which array index i is multiplied in calculating the address of an array element. The address of X(I,J,K) is calculated as: ADDR(X) + ARR_UNITS * ( I * ARR_MULT(1) + J * ARR_MULT(2) + K * ARR_MULT(3) ARR_VO_DISP ) ARR_LBOUND(i) 18 bit signed integer. The lower bound of dimension i of the array. ARR_UBOUND(i) 18 bit signed integer. The upper bound of dimension i of the array. ARR_ENUM(i) 36 bit unsigned integer. If nonzero, points to an unnamed SDD Variable Table entry of VBL_FMT_TYPE = 55 (Ada Enumeration) that describes the upper and lower bounds of the dimension. PADS uses this new field to accept array indexes that are references to enumeration literal names or the value of an enumeration literal

283 Symbolic Debugging Dictionary PADS goes to the unnamed Ada enumeration variable table entry, searches the tables described by that entry for a matching literal name or value, determines the corresponding ordinal value, and indexes that dimension with that ordinal value. Present only if ARR_TP = ARRTP ARR DIM ARR_UNITS reserved ARR_PROP ARR ROW_ COL 01 ARR_VO_D TP reserved ARR_VO_DADDR1 02 ARR_VO_DADDR2 03 ARR VOD= reserved ARR VOMADDR1(1) MTP(1) 04 ARR_VO_MADDR2(1) 05 ARR VOD= reserved ARR_VO_LBADDR1(1) LBTP(1) 06 ARR_VO_LBADDR2(1) 07 ARR VOD= reserved ARR_VO_UBADDR1(1) UBTP(1) 08 ARR_VO_UBADDR2(1) 09 ARR_LENUM(1) 10 Additional multipliers and bound pairs Figure VBL_ARRAY INFO - Long form ARR_TP 6 bit integer. Array type. 1 Short form of array information entry. 2 Long form of array information entry. 3 Short form of array information for Ada array with at least on enumeration based dimension: ARR_ENUM, if nonzero, points to an unnamed SDD Variable Table entry of VBL_FMT_TYPE = 55 (Ada Enumeration) that describes the upper and lower bound of the dimension. The normal upper and lower bound information must be filled in, since it describes the true upper and lower bound for the dimension. 4 Long form of array information for Ada array with at least on enumeration based dimension: ARR_ENUM, if nonzero, points to an unnamed SDD Variable Table entry of VBL_FMT_TYPE = 55 (Ada Enumeration) that describes the upper and lower bound of the dimension. The normal upper and lower bound information must be filled in, since it describes the true upper and lower bound for the dimension

284 Symbolic Debugging Dictionary ARR VOD_TP ARR_VOD_MTP(i) ARR_VOD_LBTP(i) ARR_VOD_UBTP(i) 6 bit integer These four fields define the addressing characteristics of the four value fields: virtual origin displacement, multiplier, lower bound, and upper bound. The ARR_VOD_MTP, ARR_VOD_LBTP, and the ARR_UI3TP fields can have the following values, which specify the values in the corresponding ARR_VO MADDRI, ARR_VO_MADDR2, ARR_VO_LBADDRI, ARR_VO_LBADDR2, ARR_VO_UBADDR1, and ARR_VO_UBADDR2 fields. The meaning of the ADDR1 and ADDR2 fields for each are determined by the type code as follows. Type Description 1 The field is a constant; ADDR2 contains a 36 bit signed integer value. 2 The value is the full word at offset ADDR2 from the logical bank identified by the logical bank number in ADDR1. 3 ADDR1 is a register number and ADDR2 is a word offset. The value is ((ADDR1)+ADDR2). 4 ADDR2 is the SDD address of the variable table entry for the variable that contains the value desired. ADDR1 = 0. 5 This is valid for ARR_UBTP(i) only; type 5 indicates an unknown upper bound (For example, PLUS asterisk bound). The corresponding ARR_UBADDR1 and ARR_UBADDR2 are zero. 6 This is used for FORTRAN arrays described by an array descriptor. The tenth entry in the AFA offset table is assumed to point to a field in the AFA which contains the address of the array descriptor list. ADDR1 is the offset from the beginning of that list of the word containing the appropriate multiplier, lower, or upper bound. ARRLENUM(i) 36 bit unsigned integer. Type Description upper names If nonzero, points to an unnamed SDD Variable Table entry of VBL_FMT_TYPE = 55 (Ada Enumeration) that describes the upper and lower bounds of the dimension. PADS uses this new field to accept array indexes that are references to enumeration literal names 7 This is valid for ARR_VOD_TP only. The value is calculate as for ARR_VOD_TP = 2, and then complemented (that is the calculated value is ADDED to the address of the first element to the array to get the virtual origin of the array)

285 Symbolic Debugging Dictionary For Ada, the virtual origin fields are not used; ARR_VOD_TP must be zero. MP and M refer to a dimensions multiplier (span), which is the distance between elements of that dimension. LB and UB are the dimensions lower and upper bounds. All three fields use the following new specifications for finding their values of multipliers and bounds of a dimension. TP ADDR1 ADDR2 Description 8 Unknown. The information about an array dimension may not be available for inclusion in the SDD (also see the unknown length and unknown address statuses for FMT_LEN_TP and VBL_ADDR TYPE). Only used for the long form (ARR_TP = 2 or 4) array information fields (ARR_VOD_TP, ARR MTP, ARR LBTP, and ARR_UBTP). 9 offset Ptr Value is offset words from start of variable described in the Variable Table entry at offset Ptr. 10 offset Value is in the parameter list at word offset from its start. See PLV under VBL_ADDRTYPE. ARRVO_DADDR1 ARRVO_DADDR2 24 bit integer, 36 bit integer. See ARR_VO_DISP. ARR_VO_MADDR1(i) ARR_VO_MADDR2(i) 24 bit integer, 36 bit integer. See ARR_VO_MULT(i). ARR_VO_LBADDR1(1) ARR_VO_LBADDR2(i) 24 bit integer, 36 bit integer. See ARR_VO_LBOUND(i). ARRVO UBADDR1(i) ARR_VO_UBADDR2(i) 24 bit integer, 36 bit integer. See ARR_VO_UBOUND(i). 36 bit unassigned integer or the value of an enumeration literal. PADS goes to the unnamed Ada enumeration variable table entry, searches the tables described by that entry for a matching literal name or value, determines the corresponding ordinal value, and indexes that dimension with that ordinal value. Present only if ARR_TP =

286 Symbolic Debugging Dictionary VBL Structure Info This entry is present for every variable which is a structure or a member of a structure. If VBL STR OFF equals zero, this information is not present. 00 reserved STR_LEN 01 STR PARENT 02 STR_SIBLING 03 STR_OFFSPRING 04 reserved STR_VARIANT - LEN 05 STR VARIANT_WORD_OFF 06 STR VARIANT_LB 07 STR_VARIANT_UB STR_LEN 18 bit integer. Figure VBL_STRUCT INFO STR VARIANT_- BIT OFF The length in words of this structure information entry, currently 4 for most structures, and 8 for Ada variant records. STR_PARENT 36 bit integer. The SDD address of the Variable table entry for the structure of which this variable is an immediate member. For example, a variable at logical level 3 in a structure would point to the entry for the logical level 2 structure which contains it. For level 1 structures, this field is zero. STR_SIBLING 36 bit integer. The SDD address of the Variable table entry for the next member of the structure of which this variable is an immediate member. This field is zero for level 1 variables and for a variable which is the last element at its level. The following variant record fields are optional. They are only present when the STR_LEN field is 8. The parents of a component can have these fields even when the component does not. That means a component can belong to a record that has no variants, but the record can in turn be the component of another record that has variants. Such a component is implicitly variant. If a component has these fields, its immediate parent must have these fields, unless the range is zero to zero. Refer to the figure Ada Variant Record SDD Information Linkages in appendix A of the Language Products Design Paper LP105 and PADS Ada Debugging Features, Version 1.1 shows what these fields point to

287 Symbolic Debugging Dictionary When STRVARIANT_LEN is zero and STR_OFFSPRING is not zero, then the record has no variant components (although the record itself may belong to a variant component of one of its parents). STR_VARIANT_LEN 9 bit unsigned integer. Specifies the bit length of the variant index field; zero (0) means that the record does not have a variant index and has no immediate variants. Only valid for parents of record components, that is when STR_OFFSPRING is <> 0. STR_VARIANT_BIT OFF 9 bit unsigned integer. Specifies the bit offset of the variant index field. The bit offset is from the starting address of the record described by this SDD entry. STR_VARIANT_WORD_OFF and STR_VARIANT_BIT_OFF specify the total offset. Only valid for parents of record components, that is when STR OFFSPRING is <> 0. STR_VARIANT_WORD_OFF word unsigned integer. Specifies the word offset of the variant index field. The word offset is from the starting address of the record described by this SDD entry, STR_VARIANT_WORD_OFF, and STR_VARIANT_BIT_OFF specify the total offset. Only valid for parents of record components, that is when STR_OFFSPRING is <> 0. STR_VARIANT_LB and STRVARIANT UB 36 bit unsigned integers. These fields specify the range of values of the variant index for which the component is active. When the fields are zero, then this component is always present when its parent is present. These two fields are valid for all record components (STR_PARENT <> 0). The parents of any active component must be searched to see if they are also active components. PADS must go to the topmost parent in the SDD (which it must do to address any components) and work its way back down the chain to determine which components and their variant indexes, if any, are active in order to be able to read the contents of the variant indexes to see when a lower level is also active VBL Enumeration Info This new variable table section contains seven fields that describe where the Ada runtime enumeration information is located. It is fixed in size at six words, and has no header. Refer to the figure Ada Enumeration Data Information Linkages in Appendix A

288 Symbolic Debugging Dictionary of the Language Products Design Paper LP105 and PADS Ada Debugging Features, Version 1.1 shows what these fields point to. If VBL_ENUM_OFF = 0, this information is not present. 00 ENUM_GDALBN ENUM COUNT 01 ENUM_UNIT_OFFSET 02 ENUM_STRING OFFSET 03 ENUM_INDEX OFFSET 04 ENUM_VAL_UNIT_OFFSET 05 ENUM_VAL_OFFSET ENUM_GDA_LBN 18 bit integer. Figure VBL Enumeration Info Entry The LBN index Global Data Area (GDA) of the current unit. Used in conjunction with ENUM_UNIT_OFFSET and ENUM_VAL_UNIT_OFFSET. ENUM COUNT 18 bit integer. The number of literals in the enumeration type. ENUM_UNIT_OFFSET 36 bit integer. The word offset into the GDA of the current unit that contains the offset into the global data bank of the GDA of the unit that contains the enumeration information for the names and the order of the names of the enumeration literals. If ENUM_UNIT_OFFSET = 0, then the GDA of the current unit contains the information. ENUM_STRING_OFFSET 36 bit integer. The word offset in the GDA specified by ENUM_UNIT_OFFSET of the start of the string that contains the Iist of enumeration literal names. Each enumeration literal name is a substring of this string. The first byte specifies the number of characters in the name. The enumeration literal name includes quotes when the name is a character literal. For example, a is 3 characters long. ENUM_INDEX_OFFSET

289 Symbolic Debugging Dictionary 36 bit integer. The word offset in the GDA specified by ENUM_UNIT_OFFSET of the start of an array of indexes into the enumeration literals names string. See ENUM_STRING_OFFSET. The array contains an 18-bit unsigned integer for each enumeration literal name. The array is ordinal. The third array element points to the starting byte offset of the third enumeration literal of the enumeration type's declaration. ENUIVIVAL_UNIT_OFFSET 36 bit signed integer. The signed, word offset GDA into the current unit that contains the offset into the global data bank of the GDA of the unit that contains the enumeration information for the values of the enumeration literals. ENUM_VAL_UNIT_OFFSET = 0, if one of the following is true: There is no value information (no representation specification). The values of the literals are the same as their order, but starting at zero. (ENUM_VAL_OFFSET = - 1) The value information is in the current unit. (ENUM_VAL OFFSET > 0 and ENUM_UNIT_OFFSET = 0) ENUM_VAL_OFFSET 36 bit signed integer. The signed word offset in the GDA specified by ENUM_VAL_UNIT_OFFSET of the start of the array that contains the list of enumeration literal names values. If ENUM_VAL_OFFSET = -1, then there is no such array and PADS can assume that the values of the enumeration literals is the same as the order with the first value as zero instead of one SDD Label Table 00 LBL_ADDR LBL_TYPE LBL_NM_OFELBL_ENT_LE 1 01 LBL_BLOCK_NUMBER 02 LBL_SECTION_PTR 03 LBL_NAME LBL ADDR 18 bit integer. Figure SDD_LABEL TABLE

290 Symbolic Debugging Dictionary The relative address of the first instruction of the statement which defines this label. This address is defined in terms of the virtual address identified by PTR_BANK_NUM and PTR_CODE_ADDR in the Pointer table entry for this label table. LBL_TYPE 6 bit integer. Indicates the kind of statement label described by this entry. 0 Label has been optimized out 1 Label (character string) 2 Statement number (Binary integer) 3 Paragraph name (character string) 4 Section name (character string) LBL_NM_OFF 6 bit integer. The word offset within this label entry of the name field. Currently it is 3. LBL_ENT LEN 6 bit integer. The number of words in this label entry. LBL_BLOCK_NUMBER 36 bit integer. The number of the block within which this label is defined. LBL_SECTION_PTR 36 bit integer. This field is used only for type 3 entries (COBOL paragraph names). It is the SDD address of the label table entry for the section name within which the paragraph name is defined. LBL NAME 36 bit integer or Link_String. For type 2 labels, this is a full-word integer representing the arithmetic value of the statement label number. For all other labels this is the name

291 Symbolic Debugging Dictionary SDD Internal Statement Number Table This form of the statement number table is used if PTRTAB_TYPE = 5. The entries in this table are 1 word in length. ISN_NUMBER ISN_ADDR Figure SDD Internal_Statement_Numbertable ISN_NUMBER 18 bit integer. The internal statement number. ISN_ADDR 18 bit integer. This is the relative address of the first instruction of the statement. This address is defined in terms of the virtual address identified by PTR_BANK NUM and PTR_CODE_ADDR in the pointer table entry for this statement table SDD Statement Table This form of the statement number table is used if PTR_TAB_TYPE = LNM_ADDR N T LNM_LEN 01 DIGITS Figure SDD_STATEMENT TABLE LNM_ADDR or offset to Used-Set Table 18 bit unsigned integer; 24 bit unsigned integer for T (LNM_TYPE) 8 and 9. For type 0 and type 3 entries, this is the relative address of the first instruction of the statement. This address is defined in terms of the virtual address identified by PTR_BANK_NUM and PTR_CODE_ADDR in the pointer table entry for this statement table. For type 1, 2, 4, and 5 entries, this is the number of entries (including this entry) which describe a copy statement and the copied text, a group of statements with the same line number to this segmentation level, a group of statements on the same source line, or a section of subroutine code which was generated inline. For type 8 entries, the first 24 bits of word 0 (lnm_addr and lnm_digit_count) make up the offset to the Used-Set entry for the last executable entry (type 0 or 3). This offset is relative to the start of the SDD bank. The DIGITS field does not exist for this entry type. This 24 bit overlayed field is called lnm_offset

292 Symbolic Debugging Dictionary For type 9 entries, the first 24 bits of word 0 (lnm_addr and -Mm digit_count) make up the offset of a link string which is the source name of an INCLUDE or COPY element that applies to the subsequent entries in the statement table. This offset is relative to the start of the SDD bank. The DIGITS field does not exist for this entry type. If the source does not exist (when I option is used and no SI field on the compilation) this entry points to a null link string entry. This 24 bit overlayed field is called lnm_offset. N (LNM_DIGIT_COUNT) 6 bit integer. Number of digits in the line number (or line number part) described by 0 < N < 46 entry. This value is always 0 for entry types 8 and 9. T (LNM_TYPE) 6 bit integer. This is the type of entry, which can be one of the following. Type Description 0 Executable statement. 1 Copy statement. 2 Segmented line number header. 3 Executable statement (more than one on a given line) 4 Copy replacing statement 5 Include header. 6 Unused. 7 Unused. 8 Used-Set offset. 9 Source name entry offset. LNM_LEN 6 bit integer. The word length of this entry. For all entry types except 8 and 9, it is always at least two words long and may extend to six words depending on the number of digits in a line number of line number part. For types 8 and 9, this length is always 1. DIGITS Array of N 4 bit integers

293 Symbolic Debugging Dictionary This is the line number or line number part. Entries of types 1, 2, 4, and 5 act as headers for structures of statements having some part of their line numbers in common. For example, for the following four source lines, the indicated values would result: Line Source Entry 10.1 A=B+C; B=A*C; 10,2,5 ---r 1,2,4, Level 1 1,3,addr I segment 2,3,addr I structure 10.2 PUT LIST (A); 2,0,addr ---I 11 GET LIST (B); 11,0,addr 12 COPY ('DEBUG'); 12,1,4 ---I Copied 12.C1.1.1 PUT LIST ('D'); 1,2,3 I source 1,0,addr I structure 12.C1.1.2 PUT DATA; 2,0,addr ---I 13 GO TO LOOP; 13,0,addr entry 1 entry 2 12 (entries 1-12) ( 10 in packed decimal ) 9 (entries 2-10) ( 1 in packed decimal ) Figure Header for line 10.1 entry 3 entry 4 entry 5 code addr ( 1 in packed decimal ) SDD addr of variable A SDD addr of variable B SDD addr of variable C Figure Statement 10.1.s1 entry 6 entry 7 entry 8 code addr ( 2 in packed decimal ) SDD addr of variable B SDD addr of variable A SDD addr of variable C Figure Statement 10.1.s

294 Symbolic Debugging Dictionary entry 9 entry 10 code addr ( 2 in packed decimal ) SDD addr of variable A Figure Statement 10.2 entry 11 entry 12 code addr ( 11 in packed decimal ) SDD addr of variable B Figure Statement 11 entry 13 entry 14 entry 15 7 (entries 13-18) ( 12 in packed decimal ) 6 (entries 14-18) (1 in packed decimal) 5 (entries 15-18) (1 in packed decimal) Figure Statement 12.c1.1 entry 16 entry 17 code addr ( 1 in packed decimal ) SDD addr of variable D Figure Statement entry 18 code addr ( 2 in packed decimal ) Figure Statement entry 19 code addr ( 13 in packed decimal ) Figure Statement

295 Symbolic Debugging Dictionary SDD Used-Set Table Entry This table entry type contains information about items that are used and modified within a user program. It consists of a header and multiple item entries. 00 Nbr_Used Nbr_Set 01 reserved Nbr Unresolved 02 Used_Table 03 Set_ Table 04 Unresolved_Table Nbr_Used 18 bit integer. Figure SDD Used-Set Table Entry The number of link string entries in the Used_Table entry. Nbr_Set 18 bit integer. The number of link string entries in the Set_Table entry. Nbr_Unresolved 18 bit integer. The number of link string entries in the Unresolved_Table entry. Used_Table 00 Item Entry (one for each item used in a statement.) Figure Used Table Item Entry 0 or more Item entries. Each Item entry represents a unique use of a user variable in a particular statement. If a line contains multiple unique uses of the same item, only one occurrence is contained in this table. A statement containing I -F AU) will have two entries, one for I and one for A(I). A statement containing I + I will have only one entry which is I. Set_Table 00 Item Entry (one for each item defined in a statement.) Figure Set Table Item Entry

296 Symbolic Debugging Dictionary 0 or more Item entries. Each Item entry represents a unique definition of a user variable in a particular statement. If a line contains multiple unique definitions of the same item, only one occurrence is contained in this table. A statement containing a(i) = i+ + will have two entries, one for i and one for a(i). A statement containing i = i++ will have only one entry which is I. Unresolvable Table 00 Item Entry (one for each item defined in a statement.) Figure Unresolvable Table Item Entry 0 or more link strings. Each link string entry represents a unique definition or use of a user variable in a particular statement. These are definitions and uses for which correct PADS expression syntax cannot be generated such as when an array contains a function call for one of its subscripts. If a line contains multiple unique definitions or uses of the same item only one occurrence is contained in this table. Item Entry 00 Item Type Item Offset Item_Type 9 bit integer. Figure Item Entry The type of item at the offset in Item_Offset. Type Description 0 In Error. 1 SDD Variable Table Entry Used to represent a scalar item whose entire addressing is contained in the SDD Variable Table entry for the item. 2 SDD Link String A link string entry in the SDD bank. Used to represent an item, such as a dimensioned item, which requires additional addressing information for PADS to display the item. This string is composed of legal PADS syntax which represents the occurrence of a user item in a user program. When the compiler is unable to determine the entire PADS syntax for a given item an attempt is made to put as much of it as possible into the link string entry. Question marks are used to indicate what the compiler is unable to determine. For example, A(2,?). The code set of the characters in the link string pointed by this item will have ASCII (type 01), KANJI (type 020), or Mixed (type 021) type. Refer to Section 11.1, LINK_STRING for more information

297 Symbolic Debugging Dictionary Item_Offset 27 bit integer. The offset of an item relative to the start of the SDD bank SDD Source Name Table Entry The entries in this table are link strings that contain the name of INCLUDE or COPY source elements. Refer to Section 11.1, LINK_STRING for more information on the format of a link string SDD AFA Offset Table The AFA offset table consists of an array of one-word entries describing fields in the AFAs associated with procedures described by this SDD. There should be only 1 AFA offset table for each SDD. 00 AF$TYPE 01 AF$NEST 02 AF$DOMID 03 AF$RTRN 04 AF$STAT2 05 AF$PARMLIST 06 AF$LV 07 AF$VALID 08 AF$LINK 09 AF$DESC 10 AF$STAT1 11 AF$LENGTH Figure SDD AFA_OFFSET_TABLB Each entry in the SDD_AFA_OFFSET_TABLE is an AFA_OFFSET_TABLE_ENTRY describing the appropriate field in the AFA allocated by the TICS RTS. The names used above are the RTS-defined tags for fields in the AFA. Note: AFWESC is not currently an RTS-defined tag. AFWESC is used to indicate the field in the AFA which points to an array descriptor list AFA Offset Table Entry An AFA_OFFSET_TABLE ENTRY describes a particular entry in a UCS RTS AFA. START_BIT BIT_LENGTH AFA_OFFSET Figure AFA_OFFSET TABLE ENTRY

298 Symbolic Debugging Dictionary START_BIT 9 bit integer. The bit offset from the word addressed by AFA offset in which the AFA field described by this table entry starts. BIT_LENGTH 9 bit integer. The bit length of the AFA field described by this table entry. AFA_OFFSET 18 bit integer. The word offset from the start of the AFA of the field described by this table entry SDD LB Relocation Table The LB-relocation table consists of an array of three word entries which provide relocation information for the SDD. This table contains an entry for each LBN referenced in the SDD. LBN index values referenced in other tables in the SDD are translated using this table to the actual LBNs known by the linking system. LBN offsets referenced in other tables in the SDD are presumed to be relocated by the corresponding entry in this table. The array of relocation table entries is zero-relative. The first entry in the table describes the relocation for LBN index zero as referenced elsewhere in the SDD. The entries in this table must be generated consecutively. If entries in the SDD reference LBN index 10, this table must contain an entry for LBN indexes 0 through RELOC_LBN 01 RELOC_LBN_OFFSET_0 02 RELOC_FLAGS Figure SDD_LB_RELOCATION TABLE Each entry in the SDD_LB_RELOCATION table consists of a 3 word entry describing offset zero in an LBN index used elsewhere in the SDD. The entries in this table are an array indexed by the LBN index. RELOC_LBN 36 bit integer. The LBN as generated by the compiler. This field requires LBN relocation. While calculating addresses based on LBNs used elsewhere in the SDD, those LBNs will be translated using this table into the relocated LBN

299 Symbolic Debugging Dictionary RELOC_LBN_OFFSET 0 36 bit integer. This field describes offset zero within the LBN. This field requires LBN offset relocation. RELOC FLAGS 36 bit logical. This field contains 36 one-bit flags which describe the Logical Bank. Currently defined flags are as follows. Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6-36 This flag is set if the corresponding LBN was not generated by the compiler. This will occur only if the compiler does not generate logical bank numbers consecutively. This flag is set if the corresponding LEN was generated by the compiler as a code bank. This flag is set if the corresponding LBN was generated by the compiler as a data bank. This flag is set if the corresponding LBN was generated by the compiler as a link-vector bank. This flag is set if the corresponding LBN was generated by the compiler as an SDD bank. Reserved and should be set to zero

300 Symbolic Debugging Dictionary

301 Section 12 System Data Format System data format (SDF) is a sequential access, variable-length record file format that is used by OS 2200 operating system software for some types of data storage. It is primarily used to store character data in program file elements or in data files. The text of symbolic elements of program files is in SDF. Some processors use SDF data files to store noncharacter (binary) data that is logically formatted into separate records. SDF files on mass storage are a continuous set of sequential data. SDF files or elements can be blocked; if they are, the blocking is normally 224 words per block with a continuation control word (051) being used to split the record that crosses the block, or a bypass control record (040) used to pad the unused part of the block. Some tape files (symbiont tapes) can be blocked at 1792 words per physical tape block. In addition, each tape block can be internally blocked in 224-word blocks. Data is recorded in variable-length records consisting of a control word followed by zero or more data words. There are two different types of SDF records: Data records A data record is any record whose control word does not have bit 0 set. The remaining portion of bits 0 11 of the control word contains the length of the record. A maximum record length of 2047 words can be defined with one control word. The contents of the remaining portion of the control word vary depending on the specific type of SDF file or element. Control records Control records provide special control information as needed by the system components processing the file or element. A control record has bit 0 set in the control word. The control record contains a code in the range in bits 0 5 of the control word. If data follows the control word, the data count is contained in bits If no data follows, the content of bits 6 11 is zero. The maximum length of a control record that can be defined with one control word is 63 words

302 System Data Format SDF Types SDF files and elements have types associated with them that determine the interpretation of parts of the control words. The SDF type (see Table 12 1) is identified by a Fieldata value in bits of the control word for the first record of the file, which is always a label control record (050). Table SDF Types Origin of SDF File or Element Bits of 050 Control Record Explanation (00) Unspecified file or element type. See Input Symbiont C (010) Produced by the input symbiont complex via READ$. Distinguished from other C types (Output Symbiont) by usage and label-record length. See Output Symbiont P (025) or C (010) Produced by the symbiont interface complex by using ERs such as SYMB$, PRINT$ (P = print file) and PUNCH$, (C = punch file). See (Symbiont) I (016) Produced by control statement. See FORTRAN V Library F (013) FORTRAN V library data file. See General Symbolic S (030) General symbolic file or element. See PCIOS X (035) Processor Common I/O System (PCIOS) created file or element. See Unspecified IPF 1100 creates untyped SDF files and elements. Before definition of the general symbolic (S) type, general symbolic files and elements were also untyped. Now an unspecified type indicates that only the data count length field of the data record control word contains valid information. Any information contained in bits of data record control words has meaning only for the application that created the SDF file or element

303 System Data Format Symbiont Complex (Types C, I, and P) The symbiont complex is a means of spooling input and output data streams to mass storage and, as such, is closely associated with mass storage files. There are three parts to the symbiont complex: input symbionts, symbiont interface ERs, and output symbionts. Input symbionts Create READ$ files for the symbiont interface ERs to read the runstream from, files for processors and runstreams to use. Symbiont interface ERs User interface to read READ$ and other SDF READA$) files and produce PRINT$ and PUNCH$ filesoutput symbionts Read PRINT$ or PUNCH$ files and produce paper output. All files used or produced by the symbiont complex are SDF files. These files share the common SDF record characteristics for differentiating data and control records, location of length fields, and definition of certain control records. Device or user-specified control records are, in general, unique control record types so that other users of the same file can bypass unknown information. READ$ The input symbiont complex produces two types of files: the READ$ file (which contains a runstream to be executed) and file (which is a means of producing a file for later use by processors or runstreams). These two file types are identical except for the label block. The name of the READ$ file is always SYS$*READ$Xrun-id, while file has a user-specified name. Except in on label control records (050), these two file types are discussed together in this manual. PRINT$ and PUNCH$ The symbiont interface ER complex produces print and punch output files via Executive requests PRINT$, PUNCH$, and SYMB$ (and variations of these). These files are then placed on system queues for printing or punching. These files are identified by the label control word, which is different from other SDF and symbiont files as follows: Standard print files contain only data records and 042, 050, 051, 054, 060, 061, and 077 control records. Bits of the data control word have meanings that are unique to print files. Standard punch files contain only data records and 042, 050, 051, 054, 070, and 077 control records. Bit 24 bit 35 of the data control word have meanings that are unique to punch files

304 System Data Format Symbiont Use of Other SDF Types The symbiont interface ER complex can use any type of SDF file or element and is sensitive to the cycle information that is available in the general symbolic type. The symbiont complex assumes character data unless a punch control record (070) is encountered that indicates a shift to binary data. The punch output symbionts can use any SDF files. If the file is not a symbiont punch file, this can limit the amount of recovery that occurs, the accuracy of keyin responses, and may produce incorrect results following repunches of mixed-mode files. The print output symbionts can print the data records from any SDF file, but the printout is limited if the file is not a symbiont print file. The print symbiont assumes a single space before every data record for nonprint files. File error recovery is inhibited. Symbiont keyins produce estimated values instead of accurate values for some responses. Translate table usage is not available. Reprints may produce the wrong results in mixed-mode (ASCII/Fieldata) files FORTRAN V Library (Type F) The FORTRAN V common bank I/O library uses SDF files to control formatted and nonformatted records for mass storage and tape. This function has been replaced by the PCIOS interface for ASCII FORTRAN (see ) General Symbolic (Type S) The general symbolic (S) type SDF indicates that bits of the data record control word contain element cycle information. This element cycle information applies to SDF elements only, not to SDF files. For a type S SDF file, bits of the data record control word are undefined. Type S SDF contains control record types 042, 050, 052, and 077. Type S SDF is created by the symbolic processing routines of the system libraries, including the SYSLIB symbolic access routine (SAR$), symbolic input/output routine (SIR$), symbolic output routine (SOR), and the SLIB symbolic read (S$READ) and symbolic write (S$WRITE) services. These routines are used by language processors and system processors such as the Collector, DATA, ELT, MASM, and PDP to produce type S SDF files and elements. Type S SDF files and elements are also produced by editors such as ED and IPF

305 System Data Format PCIOS (Type X) The OS 2200 Processor Common Input/Output System (PCIOS) is used with ASCII COBOL, ASCII FORTRAN, PL/I, QLP 2200, RPG/II, and Sort/Merge processors to produce compatible data files. The SDF files produced by PCIOS contain: An SDF label control record (050). If it is a direct file, sector 0 contains the label. For sequential files, the label record is the first record of the first data block of each file; more than one SDF file can be stacked in a mass storage file. An SDF end-of-file (EOF) record (077), which is the last record of the file. The EOF record is the last record of the last block SDF end-of-reel (EOR) records (054) when the file is a multi-reel file. The EOR record is the last record of the last block of every reel but the last SDF bypass records (040). If the file is sequential, bypass records are used in the last block to force the EOF or EOR record into the last word of the last block. If the file is direct, sectors 1, 2, and 3 contain bypass records, and bypass records are also used in the last block to force the EOF record into the last word of the last block SDF data records that may or may not be segmented. If the file is direct, the records are segmented at 2,047 words (see ). If the file is sequential, the records are segmented at the size specified by the processor interface module (PIM) in the file control superstructure (FCSS) field of the file control table (FCT). A record control word precedes each record or record segment. A deleted or dummy record is identified by a 077 code in bits of the record control word Data Record Formats The common control word format for data records is as follows: data count n where: Bit 0 Is always zero, indicating that this is a data record. data count The data count of the first segment of this data record. The data record can be continued by use of continuation control records (051). A maximum length for the first data record part is 2047 (03777), or the block size minus one, whichever is smaller

306 System Data Format n The information in bits of the data control word is variable depending on the SDF type as determined from the initial label control record (see ) READ$ Data Records The format for READ$ data records is as follows: 00 data count reserved character set 01 data word 1 02 data word n data word 3... data word n where: data count Is the number of words of data that follow. The allowable values are This field is limited to 223 words because all symbiont files are blocked with 224-word blocks. If a longer record is required, or if a record spans blocks, then continuation control records (051) are used to complete the record. character set A code of that specifies the character set of the data image. Refer to the description of the character set field for ER SYMB$ in the ER Programming Reference Manual. The character set code 076 is not currently supported. The character set specified in the data record is overridden by the character set specified in label control records (050) and character set change control records (042). For the Fieldata character set, the character size is 6 bits. For other supported character sets, the character size is quarter-word (9-bit bytes for character set types ). For kanji characters the size is 18 bits

307 System Data Format PRINT$ Data Records The format for PRINT$ data records is as follows: 00 data count space count translate table number character set 01 data word 1 02 data word 2 03 data word 3... n data word n where: data count Is the length of the following data area in words. The allowable values are This field is limited to 223 since print files are blocked at 224 words per block. space count The spacing value associated with this record: Indicates spacing to be done before printing this record Reserved for future development. Produces a page eject Indicates a page eject is to occur before printing this record. translate table number The translate table number associated with this record. character set A code of that specifies the character set of the data image. Refer to the description of the character set field for ER SYMB$ in the ER Programming Reference Manual. The character set code 076 is not currently supported. For the Fieldata character set, the character size is 6 bits. For other supported character sets, the character size is quarter-word (9-bit bytes for character set types ). During normal printing, the handler spaces the number of lines given in the space count unless spacing occurs over a page boundary. If spacing occurs over a page boundary, the handler ejects a page and spaces to the first printable line on the next page (even if the data count is 0)

308 System Data Format A space count of 4095 without data causes only a page eject, but if it is followed by a print record with a space count of zero, the print record is printed on the first printable line of the next page as if it were a print record with a space count of one. A space count of 4095 with data causes a page eject, and the data is printed on the first printable line of the following page. This ensures compatibility with the way L, B, S, and M print control records and eject pages; and it allows the symbiont handlers to eject to the physical home paper position for these page ejects. A negative spacing with no data, followed by a print record with a space count of n (n 0), prints on line n on the following page. If absolute line spacing is specified, the OS 2200 Exec system handles the spacing differently. If the line spacing count is less than 2048, the Exec system uses exactly that amount of line spacing without regard to page boundaries and margins. If the line spacing count is greater than 2048 and less than or equal to 4094, the count is truncated to a configured value (PRSPMX see the Exec Installation and Configuration Guide). If the line spacing count is 4095, the Exec does a form feed. If absolute line spacing is specified, Enterprise Output Manager (EOM formerly called DEPCON) handles the spacing differently: If the line spacing count is less than or equal to 512, EOM uses exactly that amount of line spacing without regard to page boundaries and margins. If the line spacing count is greater than 512 and less than or equal to 2047, EOM truncates the count to 512. If the line spacing count is greater than 2047, EOM does a form feed

309 System Data Format PUNCH$ Data Records The format for PUNCH$ data records is as follows: 00 data count reserved translate table number 01 data word 1 02 data word n data word 3... data word n character set where: data count Is the number of words of data that follow. The allowable values are This field is limited to 223 words because all symbiont files are blocked with 224-word blocks. If a longer record is required, or if a record spans blocks, then continuation control records (051) are used to complete the record. translate table number This is a value that can be used by some output devices to determine how to interpret the data in the record. It is normally used in conjunction with the code type field. character set A code of that specifies the character set of the data image. Refer to the description of the character set field for ER SYMB$ in the ER Programming Reference Manual. The character set code 076 is not currently supported. For the Fieldata character set, the character size is 6 bits. For other supported character sets, the character size is quarter-word (9-bit bytes for character set types ). The data can also be assumed to be binary if the proper punch control record (070) precedes the data records. If the data is binary, then the translate table and code type fields are ignored. Punch control records (070) also affect the translation of the data when it is sent to the device. For example, the ASCII data in the record can be punched as Fieldata card images. (See the description of ER SYMB$ in the ER Programming Reference Manual for possible values.)

310 System Data Format General Symbolic Data Records The format for general symbolic data records is as follows: 00 data count delete flag delete cycle add flag add cycle 01 data word 1 02 data word n data word 3... data word n where: data count Is the number of words of data that follow. The allowable values are This field is limited to 2047 words because bit 0 is used to indicate a control record. If a longer record is required, continuation records (051) are used to complete the record. delete flag A flag indicating that records were deleted before this record on the last update. delete cycle The cycle at which this record was deleted. add flag A flag indicating that this record was added on this update. add cycle The cycle at which this record was added

311 System Data Format PCIOS Data Records The format for PCIOS data records is as follows: 00 data count previous data count PCIOS caller dependent 01 data word 1 02 data word n data word 3... data word n segmentation flag where: data count Is the number of words of data that follow. The allowable values are This field is limited to 2047 words because bit 0 is used to indicate a control record. If a longer record is required, the segmentation flag is used to segment the record data. previous data count The data count of the previous record. PCIOS caller dependent This cell is 63 for deleted or dummy records and is a variable value from 0 to 62 (depending on the originator) for other records. If the originator is 1 (ASCII FORTRAN level 8R1 and lower), this is the FORTRAN record format: 01 Formatted record 02 Unformatted record 03 Namelist record 04 List-directed record 077 Dummy record for direct access If the file originator is 2 (PL/I), 3 (ASCII FORTRAN level 9R1 or higher) 1 or 4 (ASCII COBOL), this is the number of significant bits in the last word of the record; possible values are 9, 18, 27, and

312 System Data Format segmentation flag Indicates how this record is segmented: 0 The only segment for this record 1 The first segment of this record 2 The last segment of this record 3 An intermediate segment of this record PCIOS data records may not always contain symbolic data. The means of determining the type of data when it is not symbolic varies depending on the file originator. PCIOS does not normally produce continuation control records, but does accept them in input files. Segmentation of large records is handled by using multiple data records with the segmentation flag set appropriately. This means that some processors (such as the symbionts) may not handle large PCIOS records properly Control Record Formats The general control word format for control records is as follows: control code data count variable information Bit 0 is always 1. The data count in bits 6 11 is the number of data words that follow. It is zero if there are no data words. The maximum number of data words is 63. If the number of data words must exceed 63, the continuation record (051) must be used. The information in bits varies as defined for the control code. A control record contains a code in the range in bits 0 5 of the control word. Here are the currently defined control codes (octal values): 040 (Bypass record) This code indicates that this image is to be skipped. Bits 6 11 contain the number of words to skip. Skip to the next control word. See for format. 042 (Character set change control record) This code is used when an SDF file or element contains character data in more than one character set (for example, ASCII, Fieldata, JIS-16); it indicates a switch to the character set defined by bits Bits 6 11 are usually 0 since any data image included by this SDF control word is bypassed. If the file is a symbiont file, this code indicates a change in either bits (translate table number), or bits (character set), or both. The format is shown in

313 System Data Format 043 (FORTRAN V backspace record) Bits contains the length of the previous image. See for additional information. 050 (Label control record) This is the initial control word of an SDF file or element. If a label follows, its length is specified in bits The SDF format is dependent on the originator. Bits specify the SDF type of file or element (see Table 12 1). Bits specify the character set of the following data records in the file or element as does the 042 control record. The formats are shown in (Continuation record) This code indicates the following record is a continuation of the previous record. Bits 6 11 specify the number of words in this section of the record. This is used in symbiont files at the start of a 224-word block when an image spans blocks and to allow large control or data records. The format is shown in (SIR$ Line-Change record) If SIR$ applies corrections to the symbolic input, the symbolic output will contain 052 control records. If bits are nonzero, then bits contain the number of data records deleted before the next data record in the last update. If bits equal 0, this is a partial line-change or line-change statement. The format for 052 records is shown in (IPF line number record) See for format. 054 (End-of-reel record) This code is used for multireel tape files to indicate a tape swap is required at the end of reel. See for format. 060 (Print control record) This code is used in symbiont print files. It contains alphanumeric character print control information (free format character data). See for these special formats. 061 (Special Print control record) This code is used in print files. It is similar to 060 records, but contains binary noncharacter data. See for formats

314 System Data Format 070 (Punch control record) This code is used in symbiont punch files. S2 contains the number of words that compose the data submitted to the ERs SYMB$/PCHCN$ or their ASCII and alternate equivalents. This data is then interpreted when the file is output to determine any mode change required. For example, an ER PCHCN$ to change the character set to EBCDIC would produce the image See for format. 077 (End-of-file record) The end-of-file record code indicates termination of the SDF file or element. See for format Bypass Control Record (040) The bypass control record format (control code 040) is as follows: data count PCIOS previous count unused 01 data word 1 02 data word n data word 3... data word n where: data count This is the number of data words in this record. Although none of the data words are meaningful, the allowable values are PCIOS previous count This is the data count of the previous record. It is valid only in PCIOS files or elements. The bypass control record is used as a space-filler in files. A symbiont uses this record to pad the first block on a tape when doing an SV keyin to save a nonstandard print file so that a label can easily be added to the file. PCIOS uses this record type for padding the unused parts of sectors in direct-access files, and to allow placement of the end-offile and end-of-reel records as the desired positions in the file. Although the data section is ignored, use of a data section allows for skipping large sections of a file with fewer bypass control records

315 System Data Format Character Set Change Control Record (042) The character set change control record format (control code 042) is as follows: data count reserved translate table number 01 data word 1 02 data word n data word 3... data word n character set where: data count This is the number of words, if any, in the data part of this record. Although the data words are not meaningful or interpreted if included, the allowable values are translate table number This field is used in standard print or punch files only (symbiont output) to indicate which translate table to use with the following data records. Undefined for input symbiont and nonsymbiont SDF. character set A code of that specifies the character set of the data image. Refer to the description of the character set field for ER SYMB$ in the ER Programming Reference Manual. The character set code 076 is not currently supported. Character set change control records are used whenever a change is made to the character set (from bits of the data record control word) or translate table number (standard print/punch files only) of the data in the following records. Normally, these records have a data count of 0 and no data words to skip. These records are necessary for changing the character set when accessing a file normally, but the use of these records does not imply that the character set indicator in bits and bits of data records is not needed in standard print files. The reprint/repunch logic requires that bits and bits of all records contain the character set in order to use the correct translation after moving backward in the file. Some processors may not respond to the character set change control record and therefore do not properly handle files with more than one character set

316 System Data Format Label Control Records (050) Label control records are used as the initial record in a file to identify: The file as SDF The SDF type (see Table 12 1 in Section 12.1) The character set (see the description of the character set field for ER SYMB$ in the ER Programming Reference Manual) Conversational Time Sharing (CTS), in levels lower than 7R1, used 050 records to store the line number. The 053 control record is now used for this purpose. Bits 0 17 fields of the label record control word always contain valid information. The character set specified in bits of the control word of the label control record does not necessarily indicate the character set for any of the data records in the file. For example, a print file always starts with a label control record that specifies Fieldata, but can be immediately followed by a character set change control record (042) that changes all following data records to ASCII. READ$ Label Control Record (050) The READ$ label control record format is as follows: SDF type C (010) unused character set 01 filename (READ$X run-id) 02 input device 03 run-id 04 time in TDATE$ format spaces where: SDF type This is a Fieldata C (010) that indicates this is a symbiont input file. character set A code of that specifies the character set of the data image. Refer to the description of the character set field for ER SYMB$ in the ER Programming Reference Manual. The character set code 076 is not currently supported

317 System Data Format filename This is the filename of the file left-justified, space-filled Fieldata (always READ$Xrun-id). input device run-id This is the device name (left-justified, space-filled Fieldata) of the device the file images were read on. This is the run-id (left-justified, space-filled Fieldata) from control statement. time in TDATE$ format This is the time the images were read in TDATE$ format. spaces This is four words of Fieldata spaces. This type of file is created only by the input symbiont complex. A file that also has an SDF type of C but that has a 20-word data area for the label record is produced by the symbiont interface ER complex as a punch Label Control Record (050) label control record format is as follows: SDF type I (016) 01 *SDFF* unused character set where character set is a code of that specifies the character set of the data image. Refer to the description of the character set field for ER SYMB$ in the ER Programming Reference Manual. The character set code 076 is not currently supported. This type of file is produced only by the input symbiont complex when control record is being processed. FTP Label Control Records (050) The FTP label control record format is as follows: SDF type [ (01) 01 *SDFF*

318 System Data Format This type of file is produced during file transfer using FTP. PRINT$/PUNCH$ Label Control Records (050) The label control record for standard print files has changed several times. Two formats of print label control records are recognized as standard by the current symbiont handlers. The handler checks bits 0 17 of the control record to determine which type of file is being printed. If the file is of the old format, then bits (translate table number) of the 042 record control words and bits of data control words are not used during output. PRINT$/PUNCH$ Label Record Format (050) data count 024 SDF type P (025) or C (010) part number 0 character set filename (LJSF Fieldata) 03 input device or queued device (LJSF Fieldata) 04 run-id (LJSF Fieldata) 05 time in TDATE$ format user-id (LJSF Fieldata) (if configured, or else spaces) 010 SV area 011 page/card count account-id (LJSF Fieldata) project-id (LJSF Fieldata) 016 file s size in tracks banner (LJSF Fieldata) reserved reserved

319 System Data Format where: data count The number of data words following the control word. 024 The length of standard print file label blocks SDF type A Fieldata P (025) in bits of the label control word indicates that this is a print file. A Fieldata C (010) in bits of the label control word indicates that this is a punch file. part number The breakpoint part number of this file. Used for PRINT$/PUNCH$ files files only) that are breakpointed. character set A code of that specifies the character set of the data image. Refer to the description of the character set field for ER SYMB$ in the ER Programming Reference Manual. The character set code 076 is not currently supported. filename The file name in Fieldata (12 characters, left-justified, space-filled). This is the internal file name name) specified on control statement or in the alternate ER packet for user files. input device run-id date The name of the input device that initiated the run that created the file. If the file was saved (SV keyin), then this is either the device name that the file was queued to when the SV keyin occurred or spaces if the file was restored (SR keyin). The name is in left-justified, space-filled Fieldata. The run-id of the run that created the file (6 characters, left-justified, space-filled Fieldata). The date the file was created in TDATE$ format. user-id The user-id of the run that created the file (12 characters, left-justified, space-filled Fieldata). There may be spaces depending on the system configuration

320 System Data Format SV area An area used by the SV keyin to save information needed by SR keyin to restore the print file to the proper queue and priority. page/card count The number of pages or images that the operating system estimated were put into the file: 0 implies that this was a tape file, or the Exec was unable to update the label block at the closing of the file. 1 to 2 35 is the operating system s page/card estimate account-id is a value used as a flag by the SV keyin to indicate that there is not a good size estimate. The account number of the run that created the file (12 characters, left-justified, space-filled Fieldata). project-id size The project-id of the run that created the file (12 characters, left-justified, space-filled Fieldata). This is not necessarily the file qualifier. The size of the file in tracks. banner Specifies the banner to appear on the first page of the printout (12 characters, left-justified, space-filled Fieldata). reserved These words are reserved for future use by the Exec and should be set to zero

321 System Data Format SV Tape Label Control Record (050) The SV Tape label control record format is as follows: Data count 013 SDF type P (025) or C (010) part number 01 character set filename (LJSF Fieldata) 03 name of device queued to 04 run-id (LJSF Fieldata) qualifier 07 VER001 (previous versions ignore this word) 010 control bits part number priority 011 reserved user-id special handling flags clearance level 016 compartment set record reserved 017 SCD table version reserved 032 name of device queued to 033 reserved Smoque entry

322 System Data Format where: data count The number of data words following the control word. 013 The length of this print file label block. SDF type A Fieldata "P" (025) in bits of the label control word indicates that this is a print file. A Fieldata "C" (010) in bits of the label control word indicates that this is a punch file. part number The breakpoint part number of this file. Used for primary PRINT$/PUNCH$ files only. character set A code of that specifies the character set of the data image. Refer to the description of the character set field for ER SYMB$ in the ER Programming Reference Manual. The character set code 076 is not currently supported. filename The file name in Fieldata (12 characters, left-justified, space-filled). name of device queued to run-id The name in Fieldata (6 characters, left-justified, space-filled) of the device, group, or station that this entry is queued to. The run-id of the run that created the file (6 characters, left-justified, space-filled Fieldata). qualifier The qualifier of the file (12 characters, left-justified, space-filled Fieldata). VER001 The characters "VER001" in Fieldata indicate that this is version 1 of the SV label control record

323 System Data Format control bits The descriptions of the control bits are as follows: 0 Label control record block has page count 4 Decatalog user file after printing 8 Punch file 9 User file 10 Device name in Smoque entry is an input device 11 The queue name is a specific output device part number The part number. priority The priority index at which the file was queued. user-id The user-id of the run that created the file (12 characters, left-justified, space-filled Fieldata). special handling flags The descriptions of the special handling flags bits are as follows: 5 Object belongs to all defined compartments 6 Allow to be catalogued without an owner 7 Validate with security officer 8 Notify system console 9 Notify security console 10 Log access 11 Object has been disabled for security reasons. clearance level This is the clearance level of the file. compartment set record The compartment set record associated with the file. SCD table version The version of the compartment definition table when the compartment set record was created or modified. name of device queued to The name of the device, group, or station that this entry is queued to (6 characters, left-justified, space-filled Fieldata)

324 System Data Format Smoque Entry Refer to the following table for information on the Smoque Entry. 00 run-id account number file name 05 control bits part number priority 06 name of device queued to main item address 011 month day 0 initial smoque address 012 output-id 013 free options 014 free name 015 estimated pages 016 estimated cards qualifier 021 SMOQUE time * * absolute F-cycle user-id 024 read_key 025 write_key banner-id 030 project-id year 0 0 tape label address 033 time queued * 2 2 * directory index GENF$ recovery cycle run-id The run-id of the run that queued the file (6 Fieldata characters, left-justified and space-filled)

325 System Data Format account number The account number of the run that queued the file (12 Fieldata characters, left-justified and space-filled). file name The name of the queued file (12 Fieldata characters, left-justified and space-filled). control bits The descriptions of the control bits are as follows: 0 Label control record block has page count 4 Decatalog user file after printing 8 Punch file 9 User file 10 Device name in Smoque entry is an input device 11 The queue name is a specific output device part number The breakpoint part number of this file. Used for primary PRINT$/PUNCH$ files only. priority The priority index at which the file was queued. name of device queued to The name in Fieldata (6 characters, left-justified, space-filled) of the device, group, or station that this entry is queued to. main item address month day This is the main item address. The month when this file was queued to GENF$. The day when this file was queued to GENF$. initial smoque address This is the GENF$ sector address of the SMOQUE entry for the first instance of this file on the queue

326 System Data Format output-id The output-id (6 Fieldata characters, left-justified and space-filled) supplied by the program that set or is setting the in-progress bit. The output-id can use only those characters also available in Fieldata. This field prevents inadvertent deletion of queue entries. free options The Exec uses this to save the options (in master bit notation) it uses when freeing the file. free name The use name (6 characters, left-justified, space-filled Fieldata) that the Exec attached to the file. estimated pages The estimated number of pages in the queued file. estimated cards The estimated number of cards in the queued file. qualifier The qualifier of the queued file (12 Fieldata characters, left-justified and space-filled). Word 021 SMOQUE time The time the file was queued, in seconds past midnight. Bit 18 Bit 23 in S4 Bit 18 Bit 19 Bit 20 Bit 21 0 (undefined) The Exec should log any N-option sym. The security label should be printed on every page. Label-print-output is TRUE

327 System Data Format Bit 22 Bit 23 Bit 23 Bit 35 0 (undefined) 0 (undefined) absolute F-cycle The absolute F-cycle of the queued file. user-id Typically, this is the user-id associated with the run that queued the file (12 Fieldata characters, left-justified and space-filled). If the file is queued to a user-id, this field contains the user-id to which the file is queued. read_key write_key banner-id The characters to be placed in the block letters on the separator page (12 Fieldata characters, left-justified and space-filled). project-id year The project-id of the run that queued the file (12 FieIdata characters, left-justified and space-filled). The year when this file was queued to GENF$. Stored as modulo tape label address GENF$ address of the first sector of label identifiers

328 System Data Format Word 033 times queued The number of times the file is queued. This field is only meaningful if this is the initial SMOQUE entry. Bit 18 Bit 22 in S4 Bit 18 Bit 21 Bit 22 Bit 23 directory index 0 (undefined) Delete file after printing. 0 (undefined) The directory index of the queued file. GENF$ recovery cycle The number of recovery boots since the GENF$ file has been recatalogued (that is, since the last jump key 9 or jump key 13 boot). General Symbolic Label Control Record (050) The general symbolic label control record format is as follows: SDF type S (030) 01 *SDFF* zero character set where character set is a code of that specifies the character set of the data image. Refer to the description of the character set field for ER SYMB$ in the ER Programming Reference Manual. The character set code 076 is not currently supported

329 System Data Format PCIOS Label Control Record (050) The Processor Common I/O System (PCIOS) label control record format is as follows: SDF type X (035) zero character set 01 filename (LJSF Fieldata) type originator level recovery offset 04 block size record size 05 date 06 address of next file 07 largest relative record key allowed 010 largest relative record key written 011 rel-rec-1-offset segment size 012 FORTRAN format code skeletonization flag zero record length 013 address of previous file 014 record count 015 PCIOS level zero zero n (words 016 through 033 are written as they appear in the label area at open time) where: character set A code of that specifies the character set of the data image. Refer to the description of the character set field for ER SYMB$ in the ER Programming Reference Manual. The character set code 076 is not currently supported. filename The internal file name in Fieldata (12 characters, left-justified, space-filled) when the file was created

330 System Data Format type The type of PCIOS file: 01 Sequential 02 Direct originator level This field indicates the file originator: 00 Unknown 01 FTN (Level 8R1 and lower) 02 PL/I 03 FTN (Level 9R1 and higher) and APL 04 ACOB, RPG/II, and QLP Mixture of 01, with 02, 03, or 04. Sort merge uses this originator value as well. 06 Not used 07 Not used 010 PLUS If set, this field indicates that the file was created or extended by PCIOS level 4R1 or higher. recovery offset This field is valid only if level is set. It is used for output extend recovery in the event of system failure during an extend operation. block size Specifies the block size in words of the file. record size date Specifies the record size in words of the file. Contains the date when the file was created in MMDDYY format as Fieldata characters

331 System Data Format address of next file Contains the sector address of the next file for sequential stacked files on mass storage. This word is 0 for SDF direct files. largest relative record key allowed This field is the maximum relative record number which is allowed for the direct SDF file. This word is zero for sequential files. largest relative record key written This field is the largest relative record number written in the direct SDF file. This word is zero for sequential files. rel-rec-1-offset This field is valid only if level (bits of word 03) is set. PCIOS levels 4R1 and higher use this field for calculating record location from the beginning of a file. segment size The segment size (in words) used when creating this file. FORTRAN format code The FORTRAN record format control code. skeletonization flag The skeletonization flag, set at file creation time from the corresponding field in the file control table. record length The record length in characters of the file. address of previous file The address of the previous file if files are stacked on mass storage. For the first file, this field is -0, since there is no previous file

332 System Data Format Continuation Control Record (051) The continuation control record format is as follows: data count zero translate table number character set 01 data word 1 02 data word n data word 3... data word n where: data count The number of data words following the control word. translate table number The translate table that should be used with this record. (Only valid for standard print/punch files.) character set A code of that specifies the character set of the data image. (Only valid for standard print/punch files.) Refer to the description of the character set field for ER SYMB$ in the ER Programming Reference Manual. The character set code 076 is not currently supported. The continuation control records are used to continue any record when the data count field of its control word is too small or to allow error recovery in standard print files when the record spans 224-word blocks. More than one of these records can be used consecutively. For standard print file error recovery, a control word is required at the start of each 224-word block of the file. This is normally accomplished by splitting any records that cross a 224-word boundary with a continuation record. PCIOS uses a different means of continuing data images (see )

333 System Data Format SIR$ Line-Change Control Record (052) The SYSLIB SIR$ line-change control record format is as follows: data count 0 if data count = 0, contains number of deleted images; if data count 0, then H2 = 0 01 line-change statement word 1 02 line-change statement word n line-change statement word 3.. line-change statement (word n) CTS/IPF Line Number Control Record (053) The CTS/IPF line number control record format is as follows: CTS Control Record Format (053) 053 line number IPF Control Record Format (053) Segmented line number

334 System Data Format End-Of-Reel Control Record (054) The end-of-reel control record format is as follows: data count PCIOS previous count zero 01 data word 1 02 data word n data word 3 data word n The end-of-reel (EOR) control record is inserted on an unlabeled tape after the end-of-tape (EOT) mark has been detected on a write. The symbiont complex writes this record as the only record in a separate block that is written following a hardware end-of-file (EOF) mark. Therefore, processors reading unlabeled symbiont tapes must check the block following every EOF mark to verify the end of file. The EOR record on symbiont tapes is a 15-word record that contains in bits 0. Bit 11 of the first word. The remainder of the record is indeterminate. FURPUR also places the EOR record in a separate tape block that is preceded by an EOF mark, but the data in the remainder of the record is unique (see 5.4). FURPUR and the symbiont complex do not use EOR records when the tape is labeled, but instead rely on the tape-labeling EOR blocks. PCIOS places the EOR record in the main file as a normal file record instead of in a separate block. PCIOS can also place the EOR record in labeled tape files. Because of the differing usage of the end-of-reel control record, PCIOS tape files are not compatible with FURPUR or the symbiont complex. In addition, FURPUR and symbiont tape files are not compatible with PCIOS. In levels higher than 28R1 of FURPUR, symbiont unlabeled tape files are not compatible with FURPUR, but FURPUR unlabeled tape files are still compatible with the symbionts

335 System Data Format ER PRTCN$ Control Records (060) The ER PRTCN$ control record format is as follows: data count zero translate table number 01 data word 1 02 data word n data word 3... data word n character set The ER PRTCN$ control record consists of a control word with 060 in bits 0 5 and a special control record in the following data words. The special control word has the length of the special control record in bits 6 11 and the character set in bits See the description of ER SYMB$ in the ER Programming Reference Manual for the character set. The record consists of one or more print control functions to alter the printing of the file and has a maximum length of 63 words. The ER PRTCN$ print control functions are interpreted separately and acted on as if they were in separate records, so this manual treats them individually. Separate statements in the same record are separated by periods. A space-period-space sequence terminates the record scan. Therefore, the remainder of the record can be used as a comment field. Note that a period immediately following a nonspace character does not terminate the record even if followed by spaces. See the ER Programming Reference Manual for a complete explanation of these functions. LPI or Band (B) Control Functions Format B[,lpi] ctid[,eltname] Description The LPI or band (B) control function record affects line spacing and print band usage. An LPI request can have the values of 6, 8, 12, or *. Any LPI request causes a page eject equivalent to 4095 spacing without data, followed by a change in the vertical format buffer (0770 or 0776 printers). A value of 6, 8, or 12 changes the print density to 6, 8, or 12 lpi. An * resets the density to the default for the device. If lpi is not specified, no change of density (LPI) occurs. If ctid is specified, this is a request for a new load code or print band on an 0770 or 0776 printer; all other printers skip this part of this control record

336 System Data Format A request for a new print band causes an operator message to change the band and the transmission of the new load code to the printer, but does not result in any print spacing. Therefore, the operator should not home the paper while changing the band, and the user could use several different bands to print one page. The element name (eltname) on this control record is optional. If it is not included, the load code for the requested band comes from the standard load code element. If eltname is specified, the program controlling the printer may use eltname to determine where to find the print code. The element format is shown in the ER Programming Reference Manual. Logical Line (L) Control Function Format L,n Description The logical line (L) control function record is used to space to a specific printable line location on the page. It results in the same spacing for normal printing as it does when an M,X control function record has been executed. This control record positions the printer such that a space one and print record results in printing on the line specified after the comma. An L,n (n = 0 or 1) control record at or beyond line n results in a page eject followed by the same spacing that would result from the L,n control record after a page eject. An L,n (n = 0 or 1) control record when at line m (m < n) results in spacing where a space-one-and-print record prints on line n (spacing to printable line n-1 in general)

337 System Data Format An L,0 or L,1 record results in spacing to the bottom printable line of the page if currently positioned above the bottom margin, in spacing to the bottom physical line on the page if inside the bottom margin, or no spacing if already at the home paper position. Note that since spacing to the bottom physical line on the page is not the same as a home paper, a print record with a space count of n after an L,0 or L,1 record results in printing on the first printable line of the next page, even if n is greater than 1, unless the printer was positioned at home paper before the L,0 or L,1 record. Heading (H) Control Function Format H,options,page,text Description The heading (H) control function record allows the insertion of a heading record into the print file. This control record does not cause any special spacing to occur. It only inserts information into the file to be used the next time a top of page is encountered with enough top margin for a heading to be printed. The maximum size for a heading is 96 characters. The options field can be N or X. An N results in the record text being ignored. An X suppresses the printing of the page and date information. A value in the page field is used as the starting page number if page numbering is specified. The page value is incremented even if page numbering is suppressed. Therefore, an H command that specifies page numbering but does not give a page value has a page number that starts numbering from the last H command that did specify a page value. Special Forms (S) Control Function Format S,message-text Description The special forms (S) control function record is the equivalent of negative spacing without a record. It sends a message to the operator to place special forms in the printer. Even if the operator does not place new forms in the printer, the paper should be homed. A flag is set to cause a message at the end of the file to restore to standard forms. Margin (M) Control Function Format M,length -or- X,top,bottom,lpi

338 System Data Format Description The margin (M) control function record is equivalent to negative spacing without a record, followed by a change of one or more of: page length, top margin, bottom margin, lines per inch, or method of computing spacing (X option). If page length is being changed, the lpi field must be coded or a B,n command must be entered along with this control record to keep the printouts which follow properly aligned. An * can be used in place of any field and results in the device standard value being used. A blank field results in no change for that field. The top and bottom margin fields must be less than 63. The page length has a maximum determined by the printer used, or a configured value (PRSPMX), whichever is less (that is, 192 lines on an 0770 printer). The lpi field must be a 6, 8, or *. An M,X control record bypasses the normal end of page handling. It suppresses all headings, top margins, and bottom margins. The normal logic to truncate spacings that extend over page boundaries is inhibited, and the printer is spaced as far as requested, or a configured value (PRSPMX), whichever is less. A negative spacing is honored as a page eject, with the normal restrictions on the following record. All L,n commands are honored as if there are no top or bottom margins. This mode is terminated by doing another M command or B command. The length and lpi fields used in this mode are those in effect at the time of the M,X control record. The fields of the margin control function allow for up to 4 numeric decimal characters per field; if more are used, an error message results. Error Recovery (I and A) Control Functions Formats I A Description The error recovery (I and A) control function records have no effect on spacing; they affect only recovery from bad print records in the file. The I inhibits error recovery and the A allows error recovery. When error recovery is inhibited, any errors encountered that are file related result in termination of the print file with an error message. Transparent (D) Control Function Format

339 System Data Format Description This is a special remote symbiont interface (RSI) image that is ignored in most print files. It is used when the PRINT$ file is a demand terminal or when a PRINT$ file is being processed by RSI for a batch device to enter as a transparent control statement. Skip Break (R) Control Function Format R Description The skip break (R) control function record stops the reprint logic from skipping records when advancing through a print file (SM PRX Rnnn command). Spacing does not occur as a result of this record. Therefore it should be used only at the start of a page, such as after a negative spacing, B, lpi or M,length,top,bottom commands, and so on. When this record is encountered during a skip, a message is displayed at the system console. Width (W) Control Function Format W, line-width Description The width (W) control function record allows for changing the maximum allowed width of printing. If the requested width is more than the maximum for the printer, the output records are truncated to the maximum for the printer in use. A W,* command returns to the device default for the printer in use. Spacing does not occur as a result of this record. The line-width field is the maximum number of characters divided by 6; it has a maximum value of 63 (378 Fieldata characters or 252 ASCII characters). User (U) Control Function Reserved for site use Special Print Control Records PRINT$ (061) The PRINT$ special print control record (061) is inserted into a file via an Exec function CN$ from the ER SYMB$ packet. The following subsection describes the first word of an 061 record, which is common to all special print control records. Common Parts of the Special Print Control Record The first two words of the 061 control record are formatted as follows. The first word is common to all 061 records. Word 01 (the second word) varies with the subtype data count 0 0 translate table number character set

340 System Data Format 01 subtype varies where: data count The total length in words of this part of this record. The allowable values are If the record spans a 224-word block or needs more than 077 words, it can be continued with one or more continuation control records (051). translate table number The translate table as specified by the ER SYMB$ that generated the record. character set A code of that specifies the character set of the data image. Refer to the description of the character set field for ER SYMB$ in the ER Programming Reference Manual. The character set code 076 is not currently supported. subtype Determines the function and format of the record. These are the ER SYMB$, CN$ function, subfunction codes. The allowable values are , , , and 023. Subfunction codes 013, 016, 017, 022, 024, and 025 are not supported. See the following subsections for individual descriptions. The following subsections describe words 01 through n of each subtype of the 061 control record. File or Element References Several 061 images allow specification of a file name or element name from which to retrieve the information. If the printer that is printing the file is being driven by a host system (such as a V77 System) that does not have partitioned data files (such as program files), then this field specifies the name of a system file that contains the data. If the printer that is printing the file is being driven by a host with partitioned data files (such as program files on an OS 2200 system), then an element name from a system-standard file known to the program controlling the printer is specified. On some systems, it may be possible to modify the system file in which the elements are contained

341 System Data Format Load Translate Table (CNTT$, Subtype 01) The load translate table special print control record format is as follows: operation translate table number data length 01 data n unused or data where: operation Determines the type of operation for this image implies this is a 0777 or similar printer translate table. This implies the first data format, as shown on the following page. implies this is a 0770 type load code buffer description. This implies the second data format, as shown on the following page. implies this is a 0776 type load code buffer description. This implies the second data format, as shown on the following page. translate table number The number of the translate table to be affected: data length data The values allowable for the 0777 printer. The allowable values for 0770 or 0776 printers (0 implies replace the Fieldata load code in use; 1 implies replace the ASCII load code in use). The number of quarter-word bytes of data. The allowable lengths for the data section are The hardware requires at least 1 byte (the space byte), so the software also checks that it receives at least 1 byte to send. For 0770 or 0776 printers, the data length should be exactly the number of characters on the print band plus two, or if dualing is desired, the number of characters on the band plus

342 System Data Format This is the data for the translate table or load code buffer: Format 1 is an exact copy of a translate table as it would be sent to the printer in A format (9-bit bytes). The first byte is the space character value. The second byte is the underscore character value. This is followed by up to 256 bytes of data, each of which is the character generator location of the character that is to be printed when the number corresponding to this byte location is sent in the print data. Therefore, the third byte of data for a Fieldata translate table should be a pointer to the character generator location of character. The ninth byte of data for a Fieldata translate table should be a pointer to the character generator location of the A. Any locations that are not to be printed should contain an 0377 value. Format 2 is an exact copy of the load code buffer of a 0770 or 0776 printer in A format (9- bit bytes). The first byte is the cartridge-id. If the cartridge-id is different from that currently loaded, a console message changes bands and the other load code buffer (ASCII or Fieldata) is invalidated. If one of the load code buffers is invalidated, all data that is in that code is translated by the READ$ translate routines before printing. The second byte is the space code if dualing is not active, or the first byte of the dualing pairs if dualing is active. If dualing is active, there are four parts of dualing bytes and one data check dual, followed by the space character. Following the space character is an array of characters with a one-to-one correspondence to the characters on the print band. The load translate table special print control record (01) is used to allow user-selectable loading of translate/load code tables for converting the user s internal codes into characters for printing. The translate table used (in standard print files) for the actual printing is that specified in S5 of the data record. The load code table used for printing is determined by the setting of bit 0 of S6 of the data record, the last 042 record, or the last 050 control record. The offline system (0777) has a means of overriding the S5 test via a console keyin if print files created on older OS 2200 operating systems are to be printed. This always results in S6 specifying the translate table in addition to the character size. The translate table used for nonstandard print files is determined by the character set type field of the last 042 or 050 control record encountered in the file (table 0 for Fieldata and table 1 for ASCII). The system default is a Fieldata translate table in translate table 0, an ASCII translate table in translate table 1, and no translate tables in translate tables 2 or 3. There are several special uses for special translate tables in addition to different character sets (ASCII, EBCDIC, or Fieldata); for example, an italic character set and a normal character set loaded with one translate table mapping ASCII into one set, and another translate table mapping ASCII into the other set

343 System Data Format The load translate table command is primarily for development use while a new translate/load code table is being tested. After testing it is generally better to place the translate/load code table into a file/element and use the load character arrangement or B 060 record to load it. The load translate table command can be at any point in the file, but affects only data records following it. This record does not result in any spacing; only in the loading of a translate/load code table. If the translate/load code table to be loaded is different from that currently selected, the handler/subsystem reselects the originally selected translate/load code table before continuing with the next command. The translate table is analogous to the 0770/0776 load code buffer. Load Character Arrangement (CNCA$, Subtype 02) The load character arrangement special print control record has a multipart format; each section is shown separately. The first section contains the subtype in bits 0 5 of word 0. The remaining sections do not use bits 0 5 or word 0 of the section. Sections that contain operations of 0 to 2 can be placed in any order with up to eight sections allowed in one record. Sections with operation codes of 3, 4, or 5 must be the only section in the record. If fewer than eight sections are used, and the operation is not 3, 4, or 5, the length of the record passed in the SYMB$ packet must not include any data that is not valid for this record. For example, a seven-section record with four operation 0 sections followed by three operation 2 sections must be between 22 and 24 words long. The first section begins in word 0 of the record, and all sections except the last one must contain as many words as shown in the appropriate format. Load Character Table Format First Section (Subtype 02) see section descriptions see section descriptions Load Character Table Format Operation 0 Section 01 0 operation character generator font number 02 diskette-id 03 diskette-id

344 System Data Format Load Character Table Format Operation 1 Section 01 1 character generator unused 02 filename/element name 03 filename/element name (continued) 04 filename/element name (continued) Load Character Table Format Operation 2 Section 01 2 translate table number unused 02 filename/element name 03 filename/element name (continued) 04 filename/element name (continued) Load Character Table Format Operation 3 Section 01 3 operation unused cartridge-id 02 filename/element name 03 filename/element name (continued) 04 filename/element name (continued) Load Character Table Format Operation 4 Section 01 4 unused cartridge-id Load Character Table Format Operation 5 Section 01 5 unused unused where: character generator The character generator number to load. The allowable values are 0 3. font number The font number to load from diskette. The allowable values are diskette-id The volume ID (bytes 5 10 of sector 7, track 0) of the diskette containing the font. If the standard diskette is needed, this field can be zeros. The field is a 6-character ID that is left-justified, space-filled ASCII in the 2-word field

345 System Data Format translate table number The number of the translate table to load. The allowable values are 0 3. cartridge-id The cartridge-id to use if operation 3 or 4 is specified. filename/element name The name of the file (offline systems) or element (online systems) containing the translate table data if the operation is to load the translate table from a file or the font data if the operation is to load a character generator from a file/element. Filename/element name are ASCII (case independent). The load character arrangement control record (02) allows the user to load all of the character generators and translate tables with one instruction, provided all of the information is in a file or on the diskette. It also allows for a return to the system defaults so that processors can leave the file in a standard state for the processors that follow. This record should be the normal means of setting up special fonts and/or translate tables, with the load translate table record being used primarily for development of translate tables before they are included in a file or on a diskette. This record allows users to change fonts in the same way they can change bands on the 0770 printer. One danger of doing this is that the size of the character is fixed, and if a 6 lines per inch (lpi) font is loaded and the user prints at 12 lpi, the output may be truncated or overlapped. If the system default fonts are loaded, the system assumes responsibility for changing fonts for varying lpi, provided complete pages are printed with the same lpi. The use of operation code 0 and a diskette-id that is not all zeros implies a desire to use a nonstandard font diskette and results in an operator message to mount the diskette requested. A flag is set to send a message to remount the standard diskette when a return to the default font is requested (for the next file, if not earlier). If any character generator operations are performed with this record, a 2- to 3-second stop of the printer occurs. This record also results in a home paper action and any associated spacing

346 System Data Format Load Vertical Format Buffer (CNVFB$, Subtype 03) The load vertical format buffer (VFB) special print control record format is as follows: operation space type reserved (must be zero) 01 filename/element name 02 filename/element name (continued) 03 filename/element name (continued) 04 page length top margin bottom margin 05 line number lines per inch skip indicator 06 repeat of above word until the end of the record where: operation This field is used to determine how the VFB information is to be generated. 0 1 space type The VFB in its entirety is included in the following data. The VFB information is in the file specified by the file name. Indicates spacing mode to be used. 0 1 Indicates that normal spacing mode is to be used. This mode allows top and bottom margins, truncates spacing to the top of the page when crossing page boundaries, and allows headings. Indicates that absolute spacing mode is to be used. This mode does not allow top or bottom margins or headings. Spacing over the crease is allowed with the only restriction being a truncation if the space count is greater than a configuration tag (PRSPMX currently defaulted to 300 lines). Logical line commands and page ejects size for accounting purposes, logical lines, and page ejects is that specified in this record

347 System Data Format filename/element name The name of a file (offline systems) or element (online systems) that contain the description of a VFB. For proper accounting information to be generated at run time, the page length and margin information in this record must correspond to that in the file if the file is printed on an offline system. The file name is a 12-character ASCII name. page length This field contains the length of the VFB top margin These values are taken as actual page lengths in lines to use for setting up the VFB. Some values in this range may be invalid for certain devices and rejected at print time. For example, the 0777 printer requires a VFB of at least 8 inches but not more than 14 inches. The offline subsystem will probably insert some default case for out-of-range VFBs to allow a degraded printout. Indicates that the page length should not change from its current value. Use the system default value of page size. The size of the top margin: The actual size of the unprintable top margin in lines. This size cannot be larger than the page length minus the bottom margin. This size should correspond to one-half inch or more on 0777 printers to ensure good printing. Some devices may truncate this value to 077 or less internally. This value indicates the current top margin size should remain in effect. This value indicates that the default top margin value should be used

348 System Data Format bottom margin The size of the bottom margin: The actual size of the unprintable bottom margin in lines. This size cannot be larger than the page length minus the top margin. This size should correspond to one-half inch or more on 0777 printers to ensure good printing. Some devices may truncate this value to 077 or less internally. This value indicates the current bottom margin size should remain in effect. This value indicates that the default bottom margin value should be used. The following is the data for user-supplied VFBs. If this data is encountered by an older online printer, the first entry is checked for the lpi to use (12 results in 8). If the printer is a 0770 or 0776, the skip indicators may be used to set up the VFB. line number The line number on the page that this VFB entry corresponds to. Not all line numbers need be given. The system fills in missing entries by repeating the last entry without the skip code until the line number of the next entry or the line corresponding to the page length specified is reached. All line number entries must be in ascending order. The value of line number can be from 0 to n, where n is the value of page length. lines-per-inch The vertical density (lpi) associated with this line and all lines until the next specified line Six lines per inch. Eight lines per inch. Twelve lines per inch

349 System Data Format Use the same value as the previous line or page. If this is the first entry, use the same value as the previous page s first entry. Otherwise, use the value from the previous line. Use the device default value. skip indicator This flag indicates that this line should have a skip code associated with it if it is advantageous for that device. The handler determines the actual skip codes used, the number of skip codes used, and any other handler-dependent skip codes that are to be used. 0 1 This value indicates that no skip code needs to be associated with this line (it is a low frequency use line). This value indicates that the programmer believes this line is a good candidate for a skip code (it is a high-usage line). The load vertical format buffer record (03) results in positioning to the home paper position if not already there. Home paper is logically before the top printable line but after all lines on the preceding page. This is a flexible, expanded variant of the ER PRTCN$ with an M or B (for lpi) control function command. It is interpreted for current printers, but only the first five words are used for remote or old onsite printers. The complete record except those having 12 lpi (converted into 8 lpi) and more than one lpi per page are used for 0770 or 0776 printers. User-definable skip indicators let the user optimize the VFB for the forms being printed. On 0777 printers this can result in a decrease in the number of I/O requests sent to the device, since a well-designed form with the proper VFB does not require any advanceonly commands. Additionally, on 0770 or 0776 printers there is a slight speed advantage when fewer or no advance-only commands are used. Path length increases do not occur for this means of using the VFB unless the user specifies an improper VFB for the form that results in extra advance-only commands

350 System Data Format Load Graphic Character Modification (CNGRA$, Subtype 04) The load graphic character modification special print control record format is as follows: operation character number data count 01 filename/element name 02 filename/element name (continued) 03 filename/element name (continued) 04 width height reserved (must be 0) 05 data or unused where: operation This field determines the type of operation to perform: 0 1 indicates that the character modification data is to be loaded into the printer from the data in this record. indicates that the character modification data is to be found in the specified file for loading into the printer. character number The index into the character generator for the character to be modified. The allowable values for the 0777 printer are data count The exact number of significant bytes in the data area of this record. The allowable values for the 0777 printer are

351 System Data Format width The number of dots wide the character matrix is: height The allowable values for the 0777 printer. On 0777 printers the vertical column associated with the width specified contains the end-of-character code. This value indicates that a maximum width for the device is to be used without an end-of-character indication. The number of dots high of the given character matrix. If the device allows more dots than this, the extra height is filled as if it were nonprinting The allowable values for the 0777 printer. Use the maximum height for this printer. filename/element name data The name of the file (offline systems) or element (online systems) to use if the operation requires a file/element. The file name is in ASCII and has a maximum length of 12 characters, left-justified and space-filled. The data words are a series of bytes that map into dot positions in the character matrix. These bytes are 9-bit bytes (8 significant) that are packed four bytes to a word. Each bit in the byte maps into one dot position of the printed character. Each vertical column of the character starts on a byte boundary. Therefore, if a height of 20 characters is specified, three bytes are given for each vertical column. In the case of the 0777 printer, extra bits that are needed (more vertical bits and control information) are added by the subsystem or handler. The bytes specified in the data area are a subset of those required by the 0777 printer, but the subset allows full user definition of the character. The load graphic character modification command is used to modify one or more characters for the user s use. A standard font that includes the characters desired should be used, or a font on a separate diskette that can then be loaded into the printer should be created. This feature is useful when only a few characters need to be changed, or when the user wants to check the appearance of certain characters

352 System Data Format The load graphic character modification command results in the printer being positioned at the home paper position if not already there and results in a delay of approximately 2 to 3 seconds, since the printer must come to a complete halt while the operation is performed. Select Electronic Forms (CNEF$, Subtype 05) The format for the special print control record to select electronic forms is as follows: operation start copy number of copies 01 filename/element name 02 filename/element name (continued) 03 filename/element name (continued) where: operation The type of electronic forms operation to use: start copy Use only electronic forms on the following base page. Use this electronic form on all the following base pages until turned off or until the form is changed. Turn off any prior electronic forms. The number of the first copy of a page that is to get the electronic forms. For this command to be effective, a load copy number command with at least the starting copy number plus the number of copies as a copy number must be performed. The allowable values for 0777 printers are number of copies The number of copies of each page to which to apply the electronic forms. The allowable values for 0777 printers are This value plus the starting copy number must be less than 255. filename/element name A 12-character ASCII name of a file (offline systems) or element (online systems) that contains the electronic forms specification

353 System Data Format The select electronic forms record (05) merges the data in the named file, which is used to create an electronic form, with the data records from the file. This is not a true electronic form, because it uses special characters to generate the forms. Character locations that contain forms information cannot contain any print data other than spaces or underlines, or the results for those locations are unpredictable. This record results in positioning at home paper if not already at home paper. Load Copy Modification (CNCM$, Subtype 06) The load copy modification special print control record format is as follows: operation unused data count 01 start copy number of copies start line 02 number of lines start column dup factor 03 data where: operation The type of copy modification operation to perform: data count This data affects only the next base page of data that is sent. This data should be used with all future base pages until directed to stop. Stops all copy modifications being performed. The exact number of bytes of copy modification data in this record. Does not include words 1 and 2. The allowable values for 0777 printers are start copy The number of the first page to which this copy modification data applies. The allowable values for 0777 printers are number of copies The number of copies of this page to which to apply this data. The allowable values for 0777 printers are This value added to the start copy number must be less than

354 System Data Format start line The first line to which this data applies. The allowable values for 0777 printers are number of lines The number of print lines this data affects. The allowable values for 0777 printers are This value plus the start line value must be less than 168. start column The starting column number for positioning this data. The allowable values for 0777 printers are dup factor data The number of repetitions of the data to send for each line. The allowable values for 0777 printers are This value times the byte count plus the start column cannot exceed 204. The character data that is to overlay the selected portions of the data for the page. This data is in the format described by S6 of the control word and should use the translate table indicated in S5 of the control word. The load copy modification record (06) allows the user to send a page once, tell the printer to print several copies (via the load copy number command), and then modify selected portions of selected copies. This record results in positioning at home paper if not already at home paper. Allow/Inhibit Data Check (CNDC$, Subtype 07) The allow/inhibit data check special print control record format is as follows: operation reserved reserved

355 System Data Format where: operation Determines the actual handling of the record If a data check occurs, terminates the file immediately with an error message. DATA CHECK ERROR - FILE TERMINATED implies that data checks are to be enabled. If a data check occurs, inhibits data checks, prints the rest of the file, and prints a message at the end of the file that at least one data check occurred. ( AT LEAST 1 DATA CHECK OCCURRED WHILE OUTPUTING FILE file ). This implies an enabling of data checks until a data check occurs or a request is submitted to inhibit data checks. This value inhibits data checks. The allow/inhibit data check control record (07) allows a user to turn on the allow data check feature for the remainder of the file, until the first error occurs, or until data checks are inhibited. The default is that data checks are inhibited unless enabled by this command. This command is implemented for 0770 and 0776 printers. This record does not cause any spacing to be done. Special Forms (CNSF$, Subtype 010) The special print control format to receive special forms (write to console) is as follows: reserved 01 form-id 02 form-id 03 form-id

356 System Data Format where form-id is the local identification for the form. It consists of one, two, or three words of ASCII data (9-bit bytes). If only one or two words are given, the last words are assumed to be spaces. The special forms record is a means of informing the operator about the need for special forms. It results in a type-and-read operator message with the form-id inserted in an appropriate place. Once this command is received, a flag is set indicating that special forms are mounted. This results in a restore message before printing the next file. The restore message is not set if the printer is a 0777 subsystem and the next file is started without interruption and contains a similar command with the identical form-id before any print data records. This record results in the paper being spaced to the home paper position if not already there. If the print is to go to a NTR batch site that is operating under OS-3, then only an 8-character form-id should be used. This capability is implemented for all printers. Load Copy Number (CNCN$, Subtype 011) The format for the load copy number special print control command is as follows: operation reserved number of copies where: operation The type of operation to perform: 0 1 Use only the copy number for the next base page. Use the copy number for all subsequent base pages until a new load copy number command is received. number of copies The number of copies desired: Turns off the multicopy function. The allowable range of copy numbers for the 0777 printer

357 System Data Format The load copy number command allows common data for several pages to be transmitted once to the printer instead of once for each page. It is required if a load copy modification or load flash number command is used. This command does not result in any spacing, but does have certain restrictions regarding placement and use with other commands. This command results in home paper if not already positioned at home paper. Load Flash Number (CNFL$, Subtype 012) The format for the load flash number special forms command is as follows: operation reserved number of copies 01 flash-id 02 flash-id 03 flash-id where: operation This field determines the type of control desired: 0 1 Only the following base page is to be flashed. All subsequent pages are to be flashed until the next load copy number or load flash number command. number of copies The number of copies to flash: Turns off any flashing due to previous records. The number of copies to flash

358 System Data Format flash-id The name of the negative to use for flashing. The name is in ASCII. If this field is present, an operator message is sent to mount this negative in the printer. The absence of this field implies that the negative is already mounted. This command also implies that a message is not printed at the end of the file for removal of the negative. This does not create problems, since the subsystem does not flash the negative unless commanded to. If a subsequent file requires a forms flash, an operator message is sent before starting to flash the negative (if it is what the user wanted). The load flash number command is used in conjunction with the load copy number and load copy modification commands to place constant information from a negative onto the page. It has special restrictions as to the need for other commands to be active and positioning in the file. This command results in home paper positioning if not already at home paper. Use of Special Print Control Record Commands The load copy number, load flash number, load copy modification, and electronic forms commands are used together. If any one is to be used on a page, it must be sent prior to the base page data. If more than one of these commands are to be used on the same page, then all of the commands to be used must be contiguous with no spacing or data record intermixed. Any one of these commands results in the termination of the data for the last base page and a space to the home paper position. If a load flash number, load copy modification, or electronic forms command is used, a load copy number command must either be used or a previous one must still be in effect. A base page is the data records representing the common data for a number of pages that are produced by a load copy number command. The following control image subtypes are no longer supported: CNPC$, subtype 013 CNSP$, subtype 022 CNRG$, subtype 024 CNVG$, subtype

359 System Data Format Alternate Library Files (CNLIB$, Subtype 014) The format for the alternate library files command is as follows: reserved filename where filename specifies a fully qualified ASCII 2200 operating system file name. The file name must be left-justified and space-filled to a word boundary. The maximum length is 60 ASCII characters. The file should be a mass storage file, cataloged as public, and assigned at print time to the program controlling the printer. Mark Form (CNMF$, Subtype 015) The format for the mark form command is as follows: mark character This control image is used for printing a mark on the crease of pages. On 0777 printers, three lines of the specified character are printed across the perforations of the next three pages. The mark character is printed using the translate table specified in the control word. On printers, the mark character is a vertical bar. On 0780 printers, a one inch mark is printed on the two following page boundaries. Load Tab Buffer (CNTB$, Subtype 020) The format for the load tab buffer command is as follows: operation reserved (must be 0) number of tab positions element name 04 number of tab stops for tab index 1 number of tab stops for tab index 2 number of tab stops for tab index 3 number of tab stops for tab index 4 05 number of tab stops for tab index 5 number of tab stops for tab index 6 06 tab position array or unused tab positions

360 System Data Format where: operation Determines how the tab buffer information is obtained. Here are the allowable values: 0 1 The tab buffer in its entirety is included in the image. Loads the tab buffer from an element in an alternate library file. number of tab positions Specifies number of tab stop positions in the tab position array. The range of values is element name This is the 12-character, left-justified, space-filled ASCII name of the element in an alternate library containing tab buffer data. Specify element name if the operation is 1. number of tab stops Contains the number of tab stop positions in the tab position array for each tab index. tab positions An array containing the tab stop positions for all the tab indexes. These are sets of values between 1 and 815. The values correspond to positions 1/60 of an inch apart along a 13.6-inch page

361 System Data Format Left/Right Margin Adjust (CNLRM$, Subtype 021) The format for the left/right margin adjust command is as follows: Unused shift increment (n) where: shift increment (n) Determines if printing starts to the left or right from the normal left margin. Here are the allowable values: 0 +n -n This clears the shift parameter and starts printing on the normal left margin. Shifts n number in 1/10-inch (2.54-millimeter) increments to the right before printing the first character. The range for n is any whole number from 0 through 95. Shifts n number of characters to the left before printing the first character. The range for n is any whole number from -1 through Page Eject (CNPE$, Subtype 023) The format for the page eject command is as follows: operation (0 to 4) 0 Any operation will cause a page eject on all impact printers and the PCHCN$ Control Records (070) The punch control record format is as follows: data count reserved Character set 01 data word 1 02 data word 2 The ER PCHCN$ control record consists of a control word with a 070 in bits 0 5 and a special control record in the following several words. This section discusses these special control records. The special control word has the length of the special control record in bits 6 11 and the character set in bits Refer to the description of ER SYMB$ in the ER Programming Reference Manual for the character sets

362 System Data Format The record consists of one or more punch control functions to alter the punching of the file and has a maximum length of 63 words. The ER PCHCN$ punch control functions are interpreted separately and acted on as if they were in separate records. Separate statements in the same record are separated by periods. A space-period-space terminates the record scan. Therefore, the remainder of the record can be used as a comment field. Note that a period immediately following a nonspace character does not terminate the record even if followed by spaces. When the input symbionts encounter record, an 070 record with the appropriate C,code record is placed into the READ$ file as a type change record. Special Control Functions for PCHCN$ The special control functions for PCHCN$ are a subset of those functions used for the ER PRTCN$ control records (060). In addition to the card code (C) function, the special control functions for PCHCN$ are as follows: Special forms (S) Skip break (R) Width (W) User (U) Card Code (C) Control Function The format of the card code control function is as follows: C,code where code can have one of the following values: B E ASC Punch the following images in column binary. Punch the following images in the last character mode selected by an 070 record (end of binary data). Punch the following images in ASCII (Hollerith-A card punch format). Punch the following images in EBCDIC (9000 version). Punch the following images in Fieldata (Hollerith-H card punch format)

363 System Data Format Note: ASCII and Fieldata describe the pattern of holes punched in the cards. Do not confuse them with the internal representation of the characters (the familiar meaning of these terms) End-of-File Control Record (077) The end-of-file control record format is as follows: data count zero 01 data word 1 02 data word 2 n data word n The end-of-file control record is used to indicate the end of actual file data. Bits 0 5 of the control word contains 077. Any words in the file that follow this record are disregarded. Normal symbiont complex practice is to fill the last 224-word block to the end with end-of-file control records, since the symbionts require the last block to be at least 224 words long. Tapes must have the last block equal to 224 or 1792 (0777 only) words in length. PCIOS and the SYSLIB System Data Format Output (SDFO) routine normally place only one end-of-file record in the file. PCIOS places it as the last word of the last sector. The SDFO routine places it immediately following the last record

364 System Data Format

365 Section 13 System Library Structure This section provides information on how to create, maintain, and use the system library structure. The internal structure is described in Creating the System Library Structure The first time you use the SOLAR PRODLD utility or the COMUS INSTALL command to insert a software product into the system library, you create the system library structure. However, the steps you take before you can use the COMUS INSTALL command or the SOLAR PRODLD utility vary from site to site. For more information on the COMUS INSTALL command, see the COMUS End Use Reference Manual. For more information on the SOLAR PRODLD utility, see the SOLAR End Use Reference Manual. Most products are installed using SOLAR. However, some products are still installed with COMUS. To determine the products on a release tape, the tool you use (SOLAR or COMUS) to install a product, and the available installation modes for a product, you must use the SOLAR PKGREG utility. The SOLAR PKGREG utility produces a report containing this information. For more information on the SOLAR PKGREG utility, see the SOLAR End Use Reference Manual Maintaining the System Library Structure You can maintain the system library structure by using SOLAR and COMUS in conjunction with the LIBSAVE, LIBSAVE/FAS, LIBLOAD, and LIBLOAD/FAS runstreams. Use SOLAR and COMUS to install products in the system library. Use SOLAR to deinstall products. Use LIBSAVE and LIBSAVE/FAS to save the system library to tape. Use LIBLOAD and LIBLOAD/FAS to restore the saved system library to mass storage. For more information on SOLAR and the LIBSAVE, LIBSAVE/FAS, LIBLOAD, and LIBLOAD/FAS runstreams, see the SOLAR End Use Reference Manual. For more information on COMUS, see the COMUS End Use Reference Manual

366 System Library Structure The Exec Bootstrap and Its Effect on the System Library Structure This subsection lists the ways in which the Exec bootstrap affects the system library structure. The jump key 4 boot affects the library in the following ways: The Exec jump key 4 boot replaces the files SYS$*LIB$, SYS$*RUN$, and SYS$*RLIB$ on mass storage with the contents of the corresponding files from the boot tape. The jump key 4 boot does not alter SYS$*DATA$ or the product installation files. When the Exec references a common bank for the first time, it loads the common bank template using the search order described in When the Exec executes the SYS$*RUN$.BOOTELT runstream (SYS runstream), the Exec searches for all processors invoked The search process is described in If you used SOLAR or COMUS to install the product, processors invoked are not executed from the newly loaded SYS$*LIB$ file; rather, they are executed from the version SOLAR or COMUS installed. The jump key 4/13 boot affects the library in the following ways: The Exec jump key 4/13 boot reinitializes all fixed mass storage. After you execute a jump key 4/13 boot, you must perform a LIBLOAD to restore the system library structure. As with the jump key 4 boot, the files SYS$*LIB$ SYS$*RUN$, and SYS$*RLIB$ on disk are then replaced by the contents of those files from the boot tape. Once the LIBLOAD has been successfully executed, and a common bank is first referenced, the Exec loads that common bank template by using the search order process. All processors invoked in the SYS runstream are executed from the file SYS$*LIB$. This is an important difference from the jump key 4 boot Installation Status The SOLAR processor provides an online reports selection from its main menu that provides detailed online information for all products installed and all packages registered. The SOLAR PRODRT utility generates reports on software products installed on a system. The Product Summary Report provides a detailed summary of all products installed on the system. You can use this report to determine installation status. Example 13 1 shows the format of the Product Summary Report. See the SOLAR End Use Reference Manual for more information

367 System Library Structure Product_Name SSG Product_Level 23R7 Product_Mode A Date_Installed Time_Installed Method_of_Installation SOLAR Installation_Environment 2200 Package_Name CPHD-01 Package_Level "7.0" Logical_Package_Name CP02 Logical_Package_Level "7.0" File_Name ; SYS$LIB$*SSG(1) ; Attribute,PACK,NOPREP,NOTWRITEABLE,NOROLLOUT Processor ; Name,SSG ; File,SYS$LIB$*SSG(1). ******** End of Report for SSG 23R7 ******** Product_Name TPAS Product_Level 5R1B Product_Mode A Date_Installed Time_Installed Method_of_Installation SOLAR Installation_Environment 2200 Package_Name CPHD-01 Package_Level "7.0" Logical_Package_Name CP16 Logical_Package_Level "7.0" File_Name ; SYS$LIB$*TPAS(1) ; Attribute,PACK,PREP,NOTWRITEABLE,NOROLLOUT

368 System Library Structure Name,STATRN ; File,SYS$LIB$*TPAS(1) Processor ; Name,TPAS ; File,SYS$LIB$*TPAS(1) Bank ; BDI, ; Bank_Name, STATI$ ; Element, TQSTATI$ ; File,SYS$LIB$*TPAS(1) ; Attribute,STATIC, "TS QUEUING" ******** End of Report for TPAS 5R1B ******** Example SOLAR Product Summary Report The Internal Structure of the System Library The system library structure is composed of the following files: The library control file, SYS$*DATA$, contains table elements. The search for all software components residing in the system library begins with the SYS$*DATA$ file. Most system library procedure elements released with various software products reside in the file SYS$LIB$*PROC$. System runstreams released with various software products all reside in the file SYS$LIB$*RUN$. There are multiple product installation files, typically at least one file for each installed product. Each file contains all software components for the product, for instance, processors, common banks, and relocatable elements. Figure 13 1 shows an overview of the library structure

369 System Library Structure SYS$*DATA$ File The file SYS$*DATA$ contains a number of control elements. The major ones are CO$INSTALL$/COMUS$, LIB-ABS$, FILE-BDI$, LIB$NAMES, PACKAGE/PRODUCT, KEYTABLE$, SSDEF$, and ELMS-DIR$. SOLAR and COMUS create or update these elements during product installation, product deinstallation, package registrations, and various other system maintenance activities. The CO$INSTALL$/COMUS$ element is a symbolic element. It contains information that SOLAR and COMUS use when installing a product and provides a record of the product installations on the system. The LIB-ABS$ element registers processor names with the Exec. It is an omnibus format element containing the name of the processor, the name of the product installation file where the processor resides, and the sector address of the absolute element within the product installation file. The FILE-BDI$ element contains the location of the extended mode subsystems, alternate file common banks (AFCB), and security gate banks (SGB) used when you execute the Exec. It is an omnibus element that contains the bank descriptor indexes (BDI) and the name of the product installation file where the extended mode subsystems, AFCBs, and SGBs reside. The Exec searches this element during execution to satisfy BDI references from executing programs. The LIB$NAMES element registers the names of product installation files that the Collector must automatically search. It is an omnibus element that contains the names of product installation files and INFO group 12 keywords. The PACKAGE/PRODUCT element is a symbolic element. It contains information that describes the software packages registered on a system using the SOLAR PKGREG utility. The KEYTABLE$ element contains product authorizations for Unisys products released in a conditioned format. It is an omnibus element maintained by the SOLAR PKGREG processor. A symbolic KEYTABLE$ element is also generated by the SOLAR PKGREG processor. The symbolic element contains a sorted list of products for which the system is currently authorized. The SSDEF$ element defines the library search chain that the Linking System uses when dynamically or statically resolving references to undefined object module entry points. The library search chain directs the Linking System to external entry points and data items during static, load-time, or execution-time linking of extended mode programs. The SSDEF$ element is created by the Linking System s Subsystem Definition Processor (SSDP) during product installation. The ELMS-DIR$ element is loaded from SYS$*DATA$. ELMS-DIR$ is an object module recreated each time a product that uses the Extended Language Message System (ELMS) is installed by SOLAR. The ELMS-DIR$ element is loaded into the ELMS subsystem s security environment. ELMS references the directory (ELMS-DIR$) each time a message delivery request is made, to find the candidate message modules for the component

370 System Library Structure Figure Library Structure Overview

371 System Library Structure SYS$LIB$*PROC$ File The file SYS$LIB$*PROC$ contains system library copy and procedure elements. These elements are included on the master release tapes for some Unisys software products and are copied into SYS$LIB$*PROC$ when the product is installed. For example, DPS, Sort, SLIB, and TIP all have library elements, which are copied into the SYS$LIB$*PROC$ file when they are installed. All element names must be unique for the element type specified. When a product is removed, the appropriate copy and procedure elements are removed from the SYS$LIB$*PROC$ file SYS$LIB$*RUN$ File The file SYS$LIB$*RUN$ contains system runstreams. The release master tapes for some of the OS 2200 software products contain these runstreams. When you install a product with system runstreams, SOLAR or COMUS copies the runstreams into SYS$LIB$*RUN$. For example, COMUS and the MAPPER system have runstreams that are copied into the SYS$LIB$*RUN$ file when you install them. The SYS$LIB$*RUN$ file contains the element AUTO$START. When the system is booted, the Exec automatically initiates the runstreams images appear in this element. When a product is removed, the appropriate runstream elements are removed from the SYS$LIB$*RUN$ file. If image for a runstream appeared in the AUTO$START element, image is removed also Search Orders The system library satisfies requests for processors and common banks by following specified search orders. The following subsections present the search orders for Processors Common banks Universal Compiling System (UCS) System runstreams (RUN$) Collector processor)

372 System Library Structure Processor Search Order When you use SOLAR or COMUS to install a product, the table element SYS$*DATA$.LIB-ABS$ is updated to contain the names of all processors you want registered with the Exec. SOLAR or COMUS then performs the Executive request (ER) CONFIG$, and the Exec loads the updated LIB-ABS$ table element into the core. You can then invoke the newly installed processor or processors, Note: SYS$*LIB$ and/or SYS$LIB$*LIB$ are not necessarily being searched. A file with any qualifier and a filename of LIB$ can be set up to be searched, in which case SYS$*LIB$ will not be looked at. When you the Exec searches for the named processor in the following order: 1. The dynamic LIBT table. This table contains the processors you install using SOLAR and COMUS. It is created from the table element SYS$*DATA$.LIB-ABS$. 2. The static LIBT table. When you generate the Exec and include LIBTE stream generation statements (SGS) in the configuration element, you also create the static LIBT table. The processors that correspond to these SGSs reside in the file SYS$*LIB$. For more information on the LIBTE SGS, see the Exec Installation and Configuration Guide. 3. The table of contents of the alternate library search file. The name of this file is specified on an ALTERNATE_LIBRARY_FILE SGS during a SOLAR PRODLD, or directly to the SOLAR full-screen interface, or an ALTLIB SGS during a COMUS Local INSTALL. The advantage of using this mechanism is that you do not have to register each of the processors individually in the alternate library file with the Exec. For more information on using the SOLAR PRODLD utility or full-screen interface, see the SOLAR End Use Reference Manual. For more information on Local INSTALL, see the COMUS End Use Reference Manual. 4. The table of contents of SYS$*LIB$. The Exec searches the table of contents of the file SYS$*LIB$ to find processor names. This provides upward compatibility between levels of the Exec. 5. The table of contents of TPF$. If the processor reference is not satisfied in any of the previous places, Exec searches TPF$. If the processor is not found, Exec prints: PROGRAM NOT FOUND

373 System Library Structure Common Bank Search Order When the Exec searches to satisfy a common bank reference, it searches the Exec BDT first. If it does not find the bank, it continues the search according to the following sequence: 1. Does SYS$*DATA$ exist? Yes: Go to 2. No: Go to Does the element FILE-BDI$ exist in SYS$*DATA$? Yes: Go to 3. No: Go to Is the referenced BDI in SYS$*DATA$.FILE-BDI$? Yes: Go to 6. No: Go to Does the element BANK-BDI$ exist in SYS$*LIB$? Yes: Go to 5. No: Display error message. 5. Is the referenced BDI in SYS$*LIB$.BANK-BDI$? Yes: Go to 7. No: Display error message. 6. Is the referenced BDI in the element BANK-BDI$ in the product installation file pointed to by SYS$*DATA$.FILE-BDI$? Yes: Go to 7. No: Display error message. 7. Is the referenced BDI a security gate bank? Yes: Go to 8. No: Go to Does the user have the proper security clearance to pass through this gate? Yes: Go to 9. No: Display error message. 9. Load the AFCB that is the target of the security gate bank and continue processing

374 System Library Structure 10. Is the referenced BDI a fixed-gate subsystem? Yes: Go to 11. No: Go to Is the subsystem definition element specified in the BANK-BDI$ entry found in the installation file. Yes: Go to 12. No: Display error message. 12. Call the Linking System to create and load the fixed-gate bank defined in the subsystem definition element and continue processing. 13. Is the referenced BDI a bound shared subsystem? Yes: Go to 14. No: Go to Is the subsystem definition element specified in the BANK-BDI$ entry found in the installation file? Yes: Go to 15. No: Display error message. 15. Call the Linking System to create and load the bound banks defined in the subsystem definition element and continue processing. 16. Load the AFCB and continue processing. Once the Exec finds the AFCB, it loads the bank and dynamically updates the Exec BDT. The BANK$ ER retrieves information from the Exec BDT when you request common bank information. Until a program references a bank and information has been inserted into the Exec BDT, the BANK$ request for information on that bank will fail. Whenever the Exec does not find a common bank, the following error message appears on the console (usually accompanied by another, more specific message): COMMON BANK ERROR nn -#- > -#- > COMMON BANK "bank-name" with BDI bdi -#- > -#- > IS NOT INSTALLED. where: nn is the error number (see the following list)

375 System Library Structure # is the console message sequence number, between 0 and 9. The value is the same for all parts of the same message. The sequence number aids the site administrator in determining which lines of each message belong together in the case where multiple messages are being printed to the console simultaneously. bank-name bdi is the name of the referenced bank, if known; otherwise it is. is the bank descriptor index. The error messages are as follows: COMMON BANK ERROR 1. FILE qual*file(cycle) -#- > -#- > IS NOT CATALOGED. COMMON BANK ERROR 2. FILE qual*file(cycle) -#- > -#- > IS NOT A PROGRAM FILE. COMMON BANK ERROR 3. FILE qual*file(cycle) -#- > -#- > HAS CORRUPTED TABLE OF CONTENTS. COMMON BANK ERROR 4. FILE qual*file(cycle) -#- > -#- > IS EXCLUSIVELY ASSIGNED. COMMON BANK ERROR 5. FILE qual*file(cycle) -#- > -#- > IS UNLOADED. COMMON BANK ERROR 6. FILE qual*file(cycle) -#- > -#- > COULD NOT BE RECOVERED DURING SYSTEM RECOVERY. COMMON BANK ERROR 7. OMNIBUS ELEMENT elt NOT FOUND -#- > -#- > IN FILE qual*file(cycle). COMMON BANK ERROR 8. OMNIBUS ELEMENT elt HAS -#- > -#- > INVALID FORMAT IN FILE qual*file(cycle). COMMON BANK ERROR 9. BDI bdi NOT FOUND -#- > -#- > IN OMNIBUS ELEMENT elt -#- > -#- > IN FILE qual*file(cycle). COMMON BANK ERROR 10. BDI bdi NEEDS SYMBOLIC BANK NAME -#- > -#- > IN OMNIBUS ELEMENT BANK-BDI$ -#- > IN FILE qual*file(cycle). COMMON BANK ERROR 11. ABSOLUTE ELEMENT -#- >

376 System Library Structure -#- > elt[/version] NOT FOUND -#- > -#- > IN FILE qual*file(cycle). COMMON BANK ERROR 12. ABSOLUTE ELEMENT -#- > #- > elt[/version] HAS INVALID FORMAT -#- > -#- > IN FILE qual*file(cycle). COMMON BANK ERROR 13. OMNIBUS ELEMENT elt -#- > -#- > IN FILE qual*file(cycle) -#- > -#- > RECEIVED I/O ERROR nn DURING ACCESS ATTEMPT. COMMON BANK ERROR 14. BANK name WITH BDI bdi -#- > -#- > IN ABSOLUTE ELEMENT elt[/version] -#- > -#- > IN FILE qual*file(cycle) -#- > -#- > RECEIVED I/O ERROR nn DURING ACCESS ATTEMPT. COMMON BANK ERROR 15. CONTROL TABLES -#- > -#- > IN ABSOLUTE ELEMENT elt[/version] -#- > -#- > IN FILE qual*file(cycle) -#- > -#- > RECEIVED I/O ERROR nn DURING ACCESS ATTEMPT. To recover from all errors except error 5, reinstall the product associated with the BDI, bank name, or absolute element. Error 5 is resolved when you restore the installation file to mass storage, using ROLBAK. You can direct the common bank error messages to a console other than the main operator s console with a console class MGCMBK Universal Compiling System Library Search Order In the UCS environment, all linking functions are performed by the Linking System. Linking is the process of converting a program from the form produced by a compiler or assembler into a form that computer hardware can execute. This primarily involves uniting separate routines into a single program, translating symbolic references to addresses, and adjusting addresses as necessary. Symbolic references (also referred to as external references) are names in programs that refer to routines, data items, common blocks, and global constants. A definition is the value that defines the target address of a reference. A reference and its corresponding definition are usually in separate elements. During the linking process, the Linking System links a reference to its definition. It joins object modules making a reference with object modules providing the definitions. The process of finding a reference s corresponding definition and translating the reference to its definition address value is called resolution. Once the definition is found and the reference translated, the reference is resolved. To resolve a reference, the Linking System searches the file system for an element containing the definition with the same name as the reference. The files searched by the Linking System for a reference s definition are called library files. The process of finding the entry-point address (definition) of a routine is called a library search. Library searching is an integral part of the linking process

377 System Library Structure In the UCS environment, reference resolution is performed on an individual reference basis. The UCS compilers assign a library code name (LCN) to each symbolic reference in the generated object module. The LCN is a name given to a library search chain (LSC), which is an ordered list of files. The system s library search chains are defined in SYS$*DATA$.SSDEF$. This element automatically exists on all systems that have the Linking System installed. SOLAR provides the mechanisms to add to existing LSCs or to define new ones as new products are installed. The LCN thus provides the Linking System with the direction it needs to go about searching for the defining object module. Although generally not necessary, one or more of the LSC definitions in SYS$*DATA$.SSDEF$ can be redefined by creating local definitions in LINK$PF.SSDEF$ via the SSDP. For a brief overview of the Linking System, see the Linking System Programming Guide. The Linking System Programming Reference Manual describes the Linking System, what it does, and how you can use it efficiently through dynamic and static linking. The static linking system contains a complete description of library searching and how the Linking System resolves references. It also is the source of reference for the LINK processor For a description of subsystems and the Subsystem Definition Processor see the Linking System Subsystems Programming Guide System Runstream Search Order When you enter the unsolicited keyin ST element at the system console, the Exec searches the file SYS$LIB$*RUN$ for the first element that matches the element name specified by the keyin. If the Exec does not find the element name, it searches the file SYS$*RUN$. If the Exec does not find the element there, it displays ST KEY ERROR - FILE OR ELEMENT NOT FOUND Collector Search Order There are two approaches to the Collector search order: The way the Collector satisfies references to common banks. With this approach, the Collector uses CERU$ and CBEP$$ elements to search for specified elements. The way the Collector satisfies references to relocatable elements. With this approach, the Collector uses a relocatable search

378 System Library Structure Common Bank Search Order In the current library structure, multiple elements are sent out with each system processor that releases common banks. These products release an element whose name begins with the characters CBEP$$. The CBEP$$ element is a relocatable element that contains entry-point names or bank names and their corresponding BDIs. Use of separate elements allows all information required to use a product to be packaged and released with that product. For an explanation of the contents of the CBEP$$ element and the mechanism the Collector uses to satisfy references to common banks, see the Collector Programming Reference Manual. Relocatable Search Order The Collector performs two separate types of library searches: The search for elements specified with no file names on IN (include) directives. This is called the element search. The search for elements to satisfy the external references in those elements specified on IN directives. This is called the reference search. The library search sequence is as follows: 1. TPF$. 2. Files specified on LIB directives or RLIB directives in the order specified. 3. MAP$PF. This is the implied library file, if it exists. 4. Files specified by INFO group 12 keywords. These files are searched in the order in which the elements containing the INFO group 12 keywords are included in the collection. 5. Files appearing in the element SYS$*DATA$.LIB$NAMES. 6. SYS$*RLIB$. You can use the NOT directive to exclude any of these implicit or explicit files from the search. The files appearing in the element SYS$*DATA$.LIB$NAMES, the file SYS$*RLIB$, and files specified on INFO group 12 keywords are not searched during an R-option collection

379 System Library Structure The Collector searches sequentially through the LIB$NAMES element. It first searches the library preference order specification (also known as the file sequence number or group-sequence number) and then the order of the product installation files within LIB$NAMES. There are 10 preference order specifications available. The files with the lowest preference order specification are searched first, in the order they are installed at each preference order level. For example, suppose three installation files are installed in the following order, with the preference order level indicated in parentheses. 1. SYS$LIB$*SORT (7) 2. SYS$LIB$*ACOB (4) 3. SYS$LIB$*FTN (4) In the LIB$NAMES element, the three files appear in the following order: 1. SYS$LIB$*FTN Same (lowest) preference order level but installed after ACOB. 2. SYS$LIB$*ACOB Lowest preference order level and first file installed at that level. 3. SYS$LIB$*SORT Next higher preference order level and the last product installed at that level. It occurs after the files at a lower preference order level, even though SORT was installed first. Each installation you perform may change the order of the files in the LIB$NAMES element. For example, if SYS$LIB$*ACOB is installed again, the search order becomes 1. SYS$LIB$*ACOB 2. SYS$LIB$*FTN 3. SYS$LIB$*SORT Since FTN and ACOB had the same preference order specification, ACOB would now come before FTN because it was installed most recently. Within a preference order level, the files can appear in any order. The Collector searches forward through the files. Once it searches a library file, the Collector does not search the file again unless the file name appears on later LIB directives, or the file is referenced in more than one of the search sequence steps described in this example. The Collector terminates this search when all references are resolved or the forward search through the files ends

380 System Library Structure Altering the Search Sequence You can use INFO group 12 keywords to alter the Collector search sequence. You can specify them on the Meta-Assembler (MASM) $INFO 12 directive. When the Collector encounters an INFO group 12 keyword in a relocatable element, it includes the product installation file that corresponds to the INFO group 12 keyword in the INFO group 12 search chain, to satisfy any external references. If the Collector is already searching the LIB$NAMES element, this does not happen. Instead, the installation file corresponding to the INFO group 12 keyword is searched next. The element SYS$*DATA$.LIB$NAMES contains the INFO group 12 keywords defined on the system and their corresponding product installation files. The Collector searches files in the order in which the relocatable elements containing the keywords are included in the collection. After all files named by keywords are searched and if any unsatisfied references remain, all entries in the element SYS$*DATA$.LIB$NAMES are processed sequentially until all files have been searched, or all external references are satisfied. If you do not specify INFO group 12 keywords in an element, the Collector searches the library files in the order they appear in the element SYS$*DATA$.LIB$NAMES. The Collector skips library search sequence steps 4 and 5 if the element SYS$*DATA$.LIB$NAMES does not exist or is empty. This allows for upward compatibility. If you alter the search order with an INFO$ 12 directive, the files specified by the INFO group 12 keyword are searched twice during the same search pass: once in the position defined by the INFO group 12 keyword, and, if the reference is not satisfied, once during the sequential search of all the files listed in the element SYS$*DATA$.LIB$NAMES. When using INFO group 12 keywords, keep the following facts in mind: If there is more than one INFO group 12 keyword in a relocatable element, the Collector searches the corresponding files in the order the keywords appear in the element. If you specify the same INFO group 12 keyword more than once in an element, the Collector searches the corresponding file again if necessary. The Collector ignores an INFO group 12 keyword if it is the same as the previous INFO group 12 keyword the Collector encountered. If the Collector is searching through the SYS$*DATA$.LIB$NAMES element and encounters an INFO group 12 keyword, the corresponding installation file is searched next. If an element implicitly included (due to a previous external reference) contains an INFO group 12 keyword, the installation file corresponding to that keyword is added to the INFO group 12 search chain. The search is terminated as soon as the external reference is satisfied. To determine the INFO group 12 keywords defined on your system, consult the COMUSINSRPT Report 3 or the SOLAR PRODRT Collector Report

381 System Library Structure Determining the Search Sequences Used The files searched are listed in the long Collector output listing For example, assume the Collector directives are the following: LIB PLSLIB IN REL$.PROG-MAIN IN REL$.INFOR-SUB Assume also that the element PROG-MAIN contains the following directive: INFO 12 SYSLIB This causes the file SYS$LIB$*SYSLIB to appear twice in the resulting output listing, with the occurrence caused by the INFO group 12 keyword noted by an asterisk under the INFO 12 column. The file SYS$LIB$*SYSLIB is thus searched twice to satisfy external references. See Example 13 2 for an example of Collector output. Files Available for Element Inclusion (in Search Order): Search Element Reference Specified name External filename File Search Search RLIB INFO TPF$ COS*TPF$(0) * * * PLSLIB PLS*7R1(2) * * * REL$ MYFILE*REL(77) SYS$LIB$*SYSLIB(4) SYS$LIB$*SYSLIB(4) * * * * SYS$LIB$*DPS(4) SYS$LIB$*DPS(4) * * * SYS$LIB$*ACOB(10) SYS$LIB$*ACOB(10) * * * SYS$LIB$*FTN(5) SYS$LIB$*FTN(5) * * * UDS$$SRC*D$MR(2) UDS$$SRC*D$MR(2) * * * SYS$LIB$*PCIOS(3) SYS$LIB$*PCIOS(3) * * * SYS$LIB$*UCSRTS(4) SYS$LIB$*UCSRTS(4) * * * SYS$LIB$*SORT(4) SYS$LIB$*SORT(4) * * * SYS$LIB$*CML(3) SYS$LIB$*CML(3) * * * SYS$LIB$*SYSLIB(4) SYS$LIB$*SYSLIB(4) * * * SYS$*RLIB$ SYS$*RLIB$(1) * * * Example Collector Output for File Search

382 System Library Structure The column heads in the Collector output (Example 13 2) are defined as follows: Specified name is the internal file name specified on a LIB directive, an IN directive, a NOT directive, or included implicitly by the Collector. The order of the files is: 1. TPF$, unless TPF$ appears on a directive. 2. Files specified on LIB directives, NOT directives, or IN directives (in the order they are specified in the Collector symbolic input). Each file name appears once, except. files specified on more than one LIB directive The file.element specified on an IN directive when that file is specified elsewhere. 3. MAP$PF, if it exists. 4. Files specified by INFO group 12 keywords. The Collector searches in the order the elements containing the INFO group 12 keywords are included in the collection. 5. Files used from the element SYS$*DATA$.LIB$NAMES. 6. SYS$*RLIB$. External filename is the corresponding external file name. Search File indicates the file was available for an element search or reference search. Element Search indicates the files that were searched for elements, without file names specified on IN directives. The files are TPF$ Files specified on LIB directives MAP$PF Files specified by INFO group 12 keywords Files appearing in the element SYS$*DATA$.LIB$NAMES SYS$*RLIB$ The files are searched in the same order as they appear in the output listing

383 System Library Structure Reference Search RLIB indicates the files that were searched to satisfy external references in the elements specified on IN directives or implicitly included. The files are TPF$ Files specified on LIB directives (if the file has been prepped and contains an entry-point table) MAP$PF Files specified by INFO group 12 keywords Files appearing in the element SYS$*DATA$.LIB$NAMES SYS$*RLIB$ The files are searched in the same order as they appear in the output listing. indicates the file appeared on an RLIB directive or is registered with the Collector through SOLAR or COMUS in SYS$*DATA$.LIB$NAMES INFO 12 indicates that the file was referenced by an INFO group 12 keyword in an element. For more information on the Collector directives and the BDICALL$ and BDIREF$ mechanisms, see the Collector Programming Reference Manual SYS$*DATA$ Elements The file SYS$*DATA$ is the control file for the system library structure. The elements in this file provide a starting point for searches for system processors, relocatable elements, subsystems, and common banks. The SYS$*DATA$ file comprises the following elements: CO$INSTALL$/COMUS$ CO$INSTALL$/HISTORY FILE-BDI$ LIB-ABS$ LIB$NAMES PACKAGE/PRODUCT PROC$ELT RUN$ELT SSDEF$ ELMS-DIR$

384 System Library Structure KEYTABLE$ KEYTABLE$/HISTORY This file must always be cataloged on fixed mass storage CO$INSTALL$/COMUS$ The element CO$INSTALL$/COMUS$ is a symbolic element that records information about each product installation. The element contains the following stream generation statements (SGS): INSTALL, which records information on the installation of each product installed by SOLAR or COMUS ALTLIB, which contains the name of the alternate file that the Exec should search for processors before searching SYS$*LIB$ SUBSYSTEM, which records Linking System information on library search chains SSDP_LOCATION, which identifies the location of the Linking System s Subsystem Definition Processor (SSDP) used to install subsystems SSDEF$ELT, which identifies the input symbolic elements used by the Linking System s SSDP to compile new subsystem definition elements at installation time INSTALL SGS The INSTALL SGS records information on the installation of each product installed by SOLAR or COMUS. In the format described below, not all fields are used for each product. Some fields may appear multiple times. Format INSTALL PRODUCT,product,release-level ; MODE,installation-mode [,DEFAULT][,LOCAL] ; TIME,date,time ; FILE,installation-file,max-size,destination-file,descriptor, attribute[,attribute,... ] ; IPF-CONFIG,component,installation-file ; LIBD,installation-file,processor-name,attribute ; CBD,bdi,installation-file,element-name,bank-name, ; attribute[,attribute ]... ; COLLECTOR,keyword,installation-file,group-sequence ; SSDEF,installation-file,element,{FIXED_GATE BOUND DYNAMIC} ; ENVIRONMENT, {2200 OPE} ; DEINSTALL_ROUTINE, installation-file, element-name,order ; PACKAGE,package-name,package-level,package-source, logical-package-name, logical-package-level ; REGISTER,cbd,libd,collector, elms ; POINTER,date,time ; DBQUAL,qualifier ;

385 System Library Structure IVP,ivp_file,ivp_elt ; $FIN where: PRODUCT MODE product is the name of the product. release-level is the release level of the product, including a stability update level (for example, 31R1A). installation-mode is the installation mode indicator, usually an alphabetic character. The possible installation modes for a SOLAR-installable product are listed in the PKGREB summary report, the SOLAR full-screen Registered Package online report, and the PRODRT Registered Product Long Format Report. The possible installation modes for a COMUS-installable product are explained in the system registration log (SRL) for the product in the COMUS database. DEFAULT LOCAL TIME indicates that the installed mode is the default installation mode. indicates that the product was installed using the COMUS local install mechanism. date time is the date of execution (YYMMDD) of the installation runstream. is the time of execution (HHMMSS) of the installation runstream

386 System Library Structure FILE installation-file is the name of the file into which the product was installed. The format is qualifier*file(cycle). max-size is the maximum size (in sectors) specified when the installation-file was cataloged. destination-file is the installation file name as declared by the product development group. Normally this is the keyword $STANDARD, which signifies that COMUS should catalog the product installation file and that the file name should have the format SYS$LIB$*product. This subfield exists only if the product was installed by COMUS. descriptor is a descriptor that differentiates among installation file names. It is typically an integer and is incremented for each installation file required by the product. This subfield exists only if the product was installed by COMUS. attribute IPF-CONFIG can be any of the following: FIXED_NAME NOPACK NOPREP NOROLLOUT NOTWRITEABLE PACK PREP ROLLOUT WRITEABLE This field can be repeated for each IPF component to be configured with IPF. component is the IPF component name installation-file is the name of the file the component information resides in

387 System Library Structure LIBD CBD This field is replicated for each processor to be registered with the Exec. installation-file is the name of the file containing the processors that were registered with the Exec. processor-name is the name of the processor registered with the Exec. The names of processors that are registered with the Exec are contained in the table element SYS$*DATA$.LIB-ABS$ and can be invoked attribute is ACCELERATED or NOT ACCELERATED. ACCELERATED indicates that the starting sector address of the element processor-name and the corresponding control information from the program file table of contents are saved in the table element SYS$*DATA$.LIB-ABS$. This allows the Exec to load processors into core more quickly than if it first had to search the table of contents of installation-file for the starting sector address and other load-time information. This field can be repeated for each common bank installed. bdi is the bank descriptor index (BDI) for this alternate file common bank (AFCB). installation-file is the name of the file containing the AFCB to be registered with the Exec. The BDIs for AFCBs that are registered with the Exec are contained in the table elements SYS$*DATA$.FILE-BDI$ and installation-file.bank-bdi$. element-name is the name of the element containing the AFCB you want registered with the Exec. bank-name is the name of the bank corresponding to the bdi. This name is used on the unsolicited console keyin RL to reload AFCBs

388 System Library Structure attribute can be any of the following Attribute keywords: [NOT] DYNAMIC [NOT] STATIC [NOT] WRITE PROTECTED [NOT] TS QUEUING [NOT] CONTINGENCY PROCESSING [NOT] PROGRAM CONTINGENCY PROCESSING [NOT] GUARANTEED ENTRY POINT [NOT] POSITIONED [NOT] CREG CONTINGENCY PROCESSING FIXED GATE SUBSYSTEM GATE GATE TARGET BOUND SHARED SUBSYSTEM REPROG SGS attributes: D S W Q C A G NP R Dynamic bank Static bank Write-protected bank Test-and-set queuing for this bank Contingency processing for this bank Allows contingency routine in this bank to process contingencies that occur in program banks Guaranteed entry point No positioning on main storage edge CREG contingency processing For more information on the REPROG SGS, see the Exec Installation and Configuration Guide. For more information on common banks, see the Exec Common Banks Programming Guide. COLLECTOR keyword is the INFO group 12 keyword associated with this product. INFO group 12 keywords assist in efficient collection of absolute elements. See for more information on the effect of INFO group 12 keywords. installation-file is the name of the file containing the relocatable element library

389 System Library Structure SSDEF group-sequence is the relative order in which this installation-file is searched. There are 10 ordering positions defined. Files in position 1 are searched before files in position 2, and so on. Each position may have zero or more file names. Within a position, no search order may be assumed. See for more information on how this number is used by the Collector. By convention, language products use a group-sequence of 4. PCIOS, SORT, and other sets of common relocatable elements use a group-sequence of 7. Some examples of products and their group-sequence numbers are DPS 2 ACOB 4 FTN 4 DMS 4 SYSLIB 8 PCIOS 7 SORT 7 An SSDEF field is present for each shared subsystem that is installed with a product. installation-file is the name of the product installation file that contains the subsystem definition absolute element. element is the name of the subsystem definition element. FIXED_GATE BOUND DYNAMIC represents the type of shared subsystem that the subsystem definition element defines. ENVIRONMENT 2200 OPE This field exists only if the product was installed by SOLAR and the product explicitly identifies its installation environment. indicates the environment into which the product is installed

390 System Library Structure DEINSTALL_ROUTINE This field exists only if the product was installed by SOLAR. installation-file is the name of the product installation file that contains the deinstall element. element-name order PACKAGE is the name of the deinstall addstream element. is the order in which the deinstall addstream element is initiated relative to other deinstall routines. This field exists only if the product was installed by SOLAR. package-name is the name of the physical software package from which the product was loaded by SOLAR. package-level is the level of the physical software package from which the product was loaded by SOLAR. package-source REGISTER cbd libd is the physical software package source (such as reel-id and filename) is either REG_CBD to indicate that the product s common banks have been registered with the Exec, or to indicate that no common bank registration has occurred. is either REG_LIBD to indicate that the product s processors have been registered with the Exec, or to indicate that no processor registration has occurred

391 System Library Structure collector elms POINTER is either REG_COLLECTOR to indicate that the names of the product installation files have been registered with the Collector, or to indicate that no installation files have been registered with the Collector. is either REG_ELMS to indicate the product has been registered with ELMS or to indicate that it is not registered with ELMS. This field exists only if the product was installed by COMUS. date time DBQUAL IVP $FIN is the creation date of the INSTALL SGS. is the creation time of the INSTALL SGS. This field exists only if the product was installed by COMUS. qualifier is the qualifier for the COMUS database being used to install the product. This field exists only if the product was installed by COMUS. ivp_file ivp_elt $FIN is the name of the product installation file in which the product installation verification procedure (IVP) resides. is the name of the omnibus element in which a product IVP resides. is a sentinel to mark the end of the INSTALL SGS

392 System Library Structure ALTLIB SGS The ALTLIB SGS identifies the alternate library file whose table of contents is searched for processors before SYS$*LIB$ is searched. Only one alternate library file can exist on a system. Format ALTLIB file where file is the name of a file specified on an ALTLIB SGS during a COMUS Local INSTALL or an ALTERNATE_LIBRARY_FILE SGS during a SOLAR load. The file name is entered into the table element SYS$*DATA$.LIB-ABS$. The table of contents of file is searched to satisfy processor references. See for more information on the role of the ALTLIB file during the processor search. SUBSYSTEM SGS The SUBSYSTEM SGS records Linking System information on library search chains. This information is used to create the default library search chain element SSDEF$. In the following format, not all fields are used for each product. Some fields may appear multiple times. Format SUBSYSTEM LCN,lcn,default-search-chain ; TIME,date,time ; or SEARCH,library-file,search-sequence-number ; SUBSYSTEM LCN,lcn,default-search-chain ; TIME,date,time ; or SEARCH,LCN,lcn,search-sequence-number ; SUBSYSTEM LCN,lcn,default-search-chain ; TIME,date,time ; SOURCE, "input-statement" ;

393 System Library Structure where: LCN lcn TIME is the library code name. The lcn matches a library-code-name on one or more INSTALL SGSs. default-search-chain date time SEARCH is the name of the element where the Linking System begins by default when resolving link faults (external references). is the installation date (YYMMDD) of the product containing this subsystem. is the installation time (HHMMSS) of the product containing this subsystem. library-file is the name of a subsystem installation file. search-sequence-number lcn SOURCE specifies the relative search order for each subsystem with the specified library code name that is installed into the same default search chain. is a previously defined library code name. input-statement is the source statement that is to be input to the SSDP

394 System Library Structure SSDP_LOCATION SGS The SSDP_LOCATION SGS identifies the location of the SSDP that SOLAR and COMUS use during the installation of subsystems. SSDP is released with the Linking System. Format SSDP_LOCATION installation-file where installation-file is the name of the Linking System installation file containing the SSDP. SSDEF$ELT SGS The SSDEF$ELT SGS identifies the input symbolic subsystem definition elements used by the Linking System SSDP to create new absolute subsystem definition elements. Format where: PRODUCT TIME SSDEF$ELT PRODUCT,name,level,mode ; TIME,date,time ; FILE,file ; INPUT,sym_ssdef_elt_list ; OUTPUT, subsys_def_elt ; [USE,use-name,actual_name] name level mode is the name associated with the subsystem definition element. is the level associated with the subsystem definition element. is the mode associated with the subsystem definition element. date,time are the date and time that match the date and time on the TIME field of the INSTALL SGS of the product with which the SSDEF$ELT SGS is associated

395 System Library Structure FILE file is the name of the product installation file that contains the subsystem definition source element and the file in which the absolute element will be placed. INPUT sym_ssdef_elt_list OUTPUT USE is a list of source subsystem definition element names that are passed as input to the Linking System s SSDP. subsys_def_elt is the name of the subsystem definition absolute element. use-name the name in the source subsystem definition element. When the source subsystem definition elements are compiled by the SSDP, all occurrences of use-name are replaced by actual-name in the resultant absolute element. actual-name the name of one of a product s installation files CO$INSTALL$/HISTORY The element CO$INSTALL/HISTORY contains DEINSTALL SGSs. The format of the SGSs is similar to the INSTALL SGSs in the element CO$INSTALL$/COMUS$. The DEINSTALL SGS has an additional field, DEINSTALL_TIME, whose format is YYMMDD,HHMMSS. A DEINSTALL SGS is created whenever a product is removed from the system. Note: This element is for documentation purposes only. You can edit it or periodically erase its contents as needed by your site. The size of this element affects the performance of SOLAR load and COMUS INSTALL. The smaller this element, the faster a product can be installed. If desired, the SOLAR RECON processor will archive this element FILE-BDI$ The element FILE-BDI$ is an omnibus element containing The qualifier and file name of installation files containing common banks

396 System Library Structure A table indicating which installation file is related to the BDI The FILE-BDI$ element format is as follows: head 0 Identifier head 1 format type reserved 1 files head 2 file index table offset smallest BDI text 0 installation file qualifier.. text 2 text 3.. text 5 installation file file name index 0 file index(0) file index(1) where: identifier format type identifies a common bank definition (CBD) omnibus element. It must contain the character string AFCB. Format: 4 ASCII characters. indicates the format of the omnibus element; zero-filled. Format: 6-bit status. identifies this as a file definition element. The possible value for this variable is either of the following: 0 indicates that it is a FILE-BDI$ element. 1 indicates that it is a BANK-BDI$ element. Format: 6-bit status reserved files is reserved for future use; zero-filled. Format: 6-bit logical. is the number of files described in this table element. It is the number of times the text words repeat. Format: 18-bit unsigned integer

397 System Library Structure file index table offset is the word-relative address of the file index table. It is relative to the beginning of the omnibus element. Format: 18-bit unsigned integer. smallest BDI is the value of the smallest BDI defined in this omnibus element. Its value is subtracted from the BDI when calculating the index into the file index table. Format: 18-bit unsigned integer. installation file qualifier installation file file name is the name of a file containing AFCBs. Format for both of these fields is 12 ASCII characters, left-justified, space-filled. Text words 0 through 5 repeat to form the file table. file index is a table of indexes into the file table. Each entry in the table is an 18-bit unsigned integer. To find if a BDI is defined, the Exec uses the following procedure: Suppose a program references BDI The Exec takes the value in the smallest BDI (suppose it has the value ) and subtracts it from the BDI being searched. This gives a subscript into the file index of 5. The Exec then examines the value at file index (5). If the value is zero, the BDI is undefined on this system. If the value is nonzero (suppose it is 3), then the third file name listed in the text words contains BDI Listing the FILE-BDI$ Element The contents of the FILE-BDI$ element is reflected in the COMUSINSRPT Report 4. See the COMUS End Use Reference Manual for more information on COMUSINSRPT. You can also obtain this information from reports generated by the SOLAR PRODRT utility. See the SOLAR End Use Reference Manual for more information on the SOLAR PRODRT utility

398 System Library Structure LIB-ABS$ The element LIB-ABS$ is an omnibus element containing Name of the alternate library search file Names of processors registered with the Exec Name of the installation file containing the processor Starting sector address of the processor within the installation file (optional) During a product installation, SOLAR and COMUS use the ER CONFIG$ mechanism to set the CHANGELIBT bit in the Exec element DAILR. When this bit is set, the Exec reads the LIB-ABS$ element and re-creates the dynamic LIBT table. The LIB-ABS$ element format is as follows: head 0 Identifier head 1 format reserved 1 reserved 2 count head 2.. head 4 head 5.. head 7 alternate library qualifier alternate library file name text 0 processor name text 1 processor name continued executable element subtype text 2 descriptor bits text sector address text 3 Flag bits user banks common banks Text 4.. Installation file qualifier Text 6 text 7.. text 9 installation file file name where: identifier identifies this as the LIBT omnibus element. It must contain the character string LIBT. Format: 4 ASCII characters

399 System Library Structure format indicates the format of the element; zero-filled. Format: 6-bit status. reserved 1 is reserved for future use; zero-filled. Format: 6-bit logical. reserved 2 count is reserved for future use; zero-filled. Format: 6-bit logical. is the number of system processor entries in the element. It indicates how many times the text words repeat. Format: 18-bit unsigned integer. alternate library qualifier alternate library file name is the name of the file to search for a named processor after the search of the static LIBT table alternate and before the search of the table of contents of SYS$*LIB$. See for more information on the processor search. Format (both): 12 ASCII characters. processor name processor name continued is the name of the registered processor. It is the name of the element found in installation file file-name. The format for the entries in this field is 6 ASCII characters, left-justified, space-filled. executable element subtype indicates the executable element subtype (executable elements are element type 6). Valid subtypes are as follows: Absolute element produced by the Collector (MAP processor). Object module. SSDEF$ element created by the SSDP during product installation. It is used by the Linking System

400 System Library Structure 3 Zero overhead object module (ZOOM) created by the Linking System. The format for entries in this field is 18-bit unsigned integer. descriptor bits Deleted. If set to 1, the element is marked for deletion. Reserved. Reserved for future use. If set to 1, the processor is in arithmetic fault noninterrupt mode. If set to 1, the processor is in arithmetic fault compatibility mode. Reserved. Reserved for future use. Block size 64. If set to 1, the processor has 64-word granularity. Third-word mode. If set to 1, the processor is third-word sensitive. Quarter-word mode. If set to 1, the processor is quarter-word sensitive. Error flag. If set to 1, the processor is marked as being in error. The processor can still execute correctly even with collection errors. These bits are all set to zero if the processor is not accelerated. The bits correspond to T1 of word 5 of the program file table of contents entry for the processor. text sector is the sector address of the beginning of the processor

401 System Library Structure address in the installation file. This field is 0 if the processor is not an accelerated load processor. Format: 24-bit logical. flag bits New format. Always set to 1. The processor absolute format is the new format. Reserved. Reserved for future use. Dual processor state register (PSR). If set to 1, this bit indicates the element requires a dual-psr machine for execution. B-option map. If set to 1, the processor was collected using the B-option on the Collector. This indicates that the area is not cleared to zero before loading the program and any indirectly loaded segments. No start address. If set to 1, the processor has no starting address. A processor without a starting address cannot be executed. Reserved. Reserved for future use. user banks indicates the number of user banks in the processor. Format: 12-bit unsigned integer. common banks indicates the number of common banks in the processor. Format: 12-bit unsigned integer. Text word 3 corresponds to word 6 of the program file table of contents entry for the processor

402 System Library Structure installation file qualifier installation file file name indicates the name of the installation file containing the processor. Note that cycle information and read and write keys are not kept. Format (both): 12 ASCII characters, left-justified, space-filled. Text words 0 through 9 repeat for each processor registered with the Exec. Listing the LIB-ABS$ Element The contents of the LIB-ABS$ element are reflected in the COMUSINSRPT Report 2. See the COMUS End Use Reference Manual for more information on COMUSINSRPT. You can also obtain this information from reports generated by the SOLAR PRODRT utility. See the SOLAR End Use Reference Manual for more information on the SOLAR PRODRT utility LIB$NAMES The element LIB$NAMES is an omnibus element containing INFO group 12 keywords The names of files that the Collector should search to resolve relocatable references In Collector level 32R1, all LIB$NAMES files are marked as being RLIB files and are not written to the DIAG$ file processing. The LIB$NAME element format is as follows: head 1 key 0.. key 2 key 3 head 2 text 0.. text 2 text 3.. text 5 text 6 text 7 text 8 length of keyword table keyword keyword file entry offset number of file entries installation file qualifier installation file file name file cycle number file read key

403 System Library Structure where: length of keyword table is the length in words of the keyword table portion of the element. Each entry in the keyword table is 4 words long and is described as key words 0 through 3. Format: word-signed integer. keyword is an INFO group 12 keyword. Format: 12 ASCII characters, left-justified, space-filled. keyword file entry offset is a pointer to the installation file corresponding to this keyword. The first installation file has an offset of 0, the second has an offset of 1, and so on. Format: word-signed integer. number of file entries is the number of files in the file name table portion of the element. Each entry in the file name table is 9 words long and is described as text words 0 through 8. Format: word-signed integer. installation file qualifier installation file file name is the name of the file to be searched by the Collector to satisfy references to relocatable element name. Format (both): 12 ASCII characters, left-justified, space-filled. file cycle number is the absolute cycle number of the installation file. Format: 4 ASCII characters, left-justified, space-filled. file read key is the read key associated with the installation file. Format: 6 ASCII characters, left-justified, space-filled. The second half of text word 8 is ignored. Listing the LIB$NAMES Element You can see the contents of the LIB$NAMES element reflected in the COMUSINSRPT Report 3. See the COMUS End Use Reference Manual for more information on COMUSINSRPT. You can also obtain this information from reports generated by the SOLAR PRODRT utility. See the SOLAR End Use Reference Manual for more information on the SOLAR PRODRT utility

404 System Library Structure PACKAGE/PRODUCT and the PACKAGE_INFO SGS The element PACKAGE/PRODUCT is a symbolic element that contains information about all software packages that have been registered using the SOLAR PKGREG utility. The package information is used by the SOLAR PRODRT utility and SOLAR full-screen interface to produce software package reports. The element contains the PACKAGE_INFO SGSs. The PACKAGE_INFO SGS records information about the software packages registered with SOLAR. Format PACKAGE_INFO NAME,name ; LEVEL,level ; CREATOR,creator ; REGISTER_TIME,date,time ; CREATE_TIME,date,time ; TAPE,file-name,reels,assign-opts,type,expiration,comp,mmspec ; or FILE, file-name ; LOGICAL_PACKAGE,logical-package_name,logical-package-level ; PRODUCT,name,level,mode,time,date,product-attributes,; LOGICAL_PACKAGE,logical-package-name,logical-package level, ENVIRONMENT, {2200 OPE}, AUTHORIZED, {YES NO} TFD,name,level,,,,file-type,file-name,tape-pos where: NAME LEVEL name level CREATOR creator is the name of the physical software package. is the level of the physical software package. is the name of the user who created the software package

405 System Library Structure REGISTER_TIME date, time CREATE_TIME is the date (YYMMDD) and time (HHMMSS) the software package was registered. date, time TAPE FILE is the date (YYMMDD) and time (HHMMSS) the software package was created. If the package is the output from a COMUS BUILD, date and time will both be listed as UNKNOWN. file-name reels is the file name of either a cataloged software package tape or ````. the utility file name resulting from a COMUS disk output BUILD. are the names of the reels that the software package is contained on. assign-opts type are the tape assign options for the software package tape. is the type of tape for the software package tape. expiration comp Is the expiration value associated with the software tape. A value of 0 implies the system default. is the data compression mnemonic for the software package tape. A value of ```` implies the system default. mmspec is the Media Manager specification for the software package tape. A value of ```` implies no Media Manager specification

406 System Library Structure LOGICAL_PACKAGE This field is repeated once for each logical package comprising the physical software package. logical-package-name is the name of logical package. logical-package-level PRODUCT is the name of logical package. This field is present for each product that is contained on the software product tape. name level mode date time is the name of a product that is present on the software package tape. is the level of a product that is present on the software package tape. is the mode of a product that is present on the software package tape. is the date associated with a product that is present on the software package tape. is the time associated with a product that is present on the software package tape. product-attributes can be any of the following DEFAULT SLR INS BLD CIG indicates the default mode of the product indicates the product is SOLAR installable indicates the product is COMUS installable indicates the product is COMUS buildable indicates the product is COMUS configurable

407 System Library Structure TFD logical-package-name is the name of the logical package in which the product is located. logical-package-level is the level of the logical package in which the product is located. ENVIRONMENT, {2200 OPE} is the product s installation environment. AUTHORIZED, {YES NO} indicates whether or not the produce is authorized. This field is used to identify COMUS information files associated with products on the software package tape. name level file-type is the name of a product that is present on the software package tape. is the level of a product that is present on the software package tape. is generally IFILE. file-name is the corresponding COMUS file name. tape-pos is the position of the file on the tape

408 System Library Structure PROC$ELT and the PROC$ELT SGS The element PROC$ELT is a symbolic element that records information about the runstreams in SYS$LIB$*PROC$. The element contains the PROC$ELT SGSs. The PROC$ELT SGS records information about the library procedures associated with various products. Format PROC$ELT PRODUCT,product,release-level, installation-mode ; TIME,date,time ; [OMN_ELTS,elt[,elt,...];] [SYM_ELTS,elt[,elt,...]] where: PRODUCT product is the name of the product. release-level is the release level of the product, including a stability update level; for example 31R1A. installation-mode is the mode of the product. TIME date time OMN_ELTS elt is the date of execution (YYMMDD) of the installation runstream. is the time of execution (HHMMSS) of the installation runstream. is the omnibus element in SYS$LIB$*PROC$ that corresponds to the product specified on the SGS

409 System Library Structure SYM_ELTS elt is the symbolic element in SYS$LIB$*PROC$ that corresponds to the product specified on the SGS. RUN$ELT and the RUN$ELT SGS The element RUN$ELT is a symbolic element that records information about the runstreams in SYS$LIB$*RUN$. The element contains the RUN$ELT SGSs. The RUN$ELT SGS records information about the runstreams associated with various products. Format RUN$ELT PRODUCT,product,release-level, installation-mode ; TIME,date,time ; [NON_AUTO_ELTS,elt[,elt,...];] [AUTOSTART_ELTS,elt[,elt,...]] where: PRODUCT TIME product is the name of the product. release-level is the release level of the product, including a stability update level; for example 31R1A. installation-mode date time is the mode of the product. is the date of execution (YYMMDD) of the installation runstream. is the time of execution (HHMMSS) of the installation runstream

410 System Library Structure NON_AUTO_ELTS elt is the runstream in SYS$LIB$*RUN$ that corresponds to the product specified on the SGS. AUTOSTART_ELTS elt SSDEF$ is the runstream in SYS$LIB$*RUN$ that corresponds to the product specified on the SGS; also has image in SYS$LIB$*RUN$.AUTO$START. The SSDEF$ element contains library search chains for all installed subsystems. It is a subsystem definition (SSD) element (element type 6, subtype 2) and is created by the SSDP. COMUS and SOLAR invoke SSDP during product installation processing. The Linking System uses the SSDEF$ element for direction in its library searching tasks. A symbolic SSDEF$ element also is created, which contains the input to SSDP, when creating the executable SSDEF$ element ELMS-DIR$ The ELMS-DIR$ element is an ELMS-internal data structure used only by the ELMS message delivery subsystem, to identify and locate appropriate message modules for a delivery request. Whenever an ELMS-integrated product is installed, SOLAR calls the ELMSMDBREG utility processor with the ELMS-related information from its database about all ELMS-integrated product components and their message modules; the processor dynamically recreates the ELMS directory using this information. A directory-report utility processor named DIRDMP is provided as part of the ELMS system to provide a formatted report of the currently installed directory KEYTABLE$ The KEYTABLE$ element contains all product and feature authorizations for a particular site. This element is an omnibus element created when a Unisys key tape is registered with SOLAR. The KEYTABLE$ element is used to verify site authorizations for products being installed from Unisys conditioned package tapes. A symbolic KEYTABLE$ element is also created. The symbolic element contains a sorted list of products for which the system is currently authorized

411 System Library Structure KEYTABLE$/HISTORY The KEYTABLE$/HISTORY element contains a chronological record in SGS format of all keys registered and unregistered on the system. It contains more detailed information than can be obtained from any other key report. This additional information includes creation time and date, package source reel-id or utility file name (only on registration entries), remaining dynamic expiration if applicable, and registration/unregistration time and date. The KEYTABLE$/HISTORY element can be particularly helpful with keeping track of interrupted usage of keys with dynamic expirations. Example KEY ; KEY ; NAME,EXEC ; LEVEL,ITASCA2 ; STYLE_ID,IX6802 ; IDENTIFIER, ; PERFORMANCE,80 ; PROCESSORS,4 ; UPI,ALL ; PACKAGE,11917C ; CREATE_TIME, , ; REGISTER_TIME, , NAME,EXEC ; LEVEL,ITASCA2 ; STYLE_ID,IX6802 ; IDENTIFIER, ; OPTIONAL_MODEL_NUMBER,IX ; OPTIONAL_EXPIRATION, ; OPTIONAL_PERFORMANCE,100 ; OPTIONAL_PROCESSORS,8 ; OPTIONAL_PACKAGE,SCP*OPT-KEY ; OPTIONAL_CREATE_TIME, , ; OPTIONAL_DYNAMIC_EXPIRATION,90,DAYS ; REGISTER_TIME, ,163714KEY ; AME,WEBTS LEVEL,4R3 ; STYLE_ID,'' IXS 4000-WTS'' ; TYPE,FEATURE ; EXPIRATION, ; DYNAMIC_EXPIRATION,75,DAYS ; UNREGISTER_TIME, ,

412 System Library Structure KEY ; NAME,ACOB ; LEVEL,7R3E ; STYLE_ID,'' '' ; TYPE,MIXED ; PACKAGE,11821C ; CREATE_TIME, , ; REGISTER_TIME, , Symbolic Product and Feature Key Format KEY: name level style-id key-id max exp opt-max opt-exp key-type name level style-id key-id max exp opt-max opt-exp key-type is the product name. is the product level. is the product style-id. is the identifier. This field is currently unused is always. is the normal concurrency value. This field is currently unused and is always. is the normal expiration date (YYYYMMDD) for the key. This field is if the key does not have an expiration date. is the optional concurrency value. This field is currently unused is always. is the optional expiration date (YYYYMMDD). This field is currently unused and is always. Indicates the type of key, either MIXED, ABSOLUTE, or FEATURE

413 System Library Structure Symbolic Exec SCP Key Format KEY: level model-num serial-num perf exp ips opt-model-num opt-perf opt-exp opt-ips upi-num-list level model-num serial-num perf exp ips opt-model-num opt-perf opt-exp identifies the general Exec level. is the machine model number. is the MCN serial number. is the normal performance level represented as a percentage. is the normal expiration date (YYYYMMDD) for the key. This field is if the key does not have an expiration date. is the number of the instruction processors authorized by the key. is the optional machine model number. This field is if an optional performance key is not registered. is the optional performance level represented as a percentage. This field is if an optional performance key is not registered. is the optional expiration date (YYYYMMDD). This field is if an optional performance key is not registered

414 System Library Structure opt-ips upi-num-list is the optional number of the instruction processors authorized by the key. This field is if an optional performance key is not registered. is a list of UPI numbers identifying the IPs which are authorized by key. A value of ALL indicates that all IPs are authorized Product Installation Files The product installation files contain table elements as well as the product components. Each software product is installed in its own file. Some products may have more than one installation file. OS 2200 products usually have a default file name of SYS$LIB$*product-name. All the software components that the Exec needs for the product execution reside in the product installation file. Each product installation file may contain the BANK-BDI$ element. The BANK-BDI$ element records information on AFCBs and subsystem definition elements residing in the product installation file. It is an omnibus element. For AFCBs, BANK-BDI$ contains the BDI, the attributes of the common bank, the name of the absolute element containing the common bank, and the bank name. Subsystem entries in the BANK_BDI$ include the BDI; the name of the subsystem definition element; and an attribute that indicates the type of the subsystem, fixed-gate shared subsystem, or bound shared subsystem. The Exec searches the BANK-BDI$ element to locate common banks and subsystems referenced by executing programs. The Exec then calls the Linking System to load subsystems as necessary. Product installation files contain the information for products installed by SOLAR and COMUS. These files typically have the qualifier SYS$LIB$. Product installation files may also contain the control element, BANK-BDI$, which relates BDIs to element names The following elements contain pointers to product installation files: SYS$*DATA$.LIB-ABS$ contains the names of all product installation files that contain processors and pointers to the starting sector address of accelerated processors. SYS$*DATA$.LIB$NAMES contains the names of files that are to be searched by the Collector. SYS$*DATA$.CO$INSTALL$/COMUS$ contains the names of all product installation files. SYS$*DATA$.FILE-BDI$ contains the names of all product installation files containing common banks and the BDIs contained in those files. ELMS-DIR$ contains the names of all product installation files registered with ELMS. Note: Since some elements contain pointers to specific sector addresses, it is important not to modify the installation files in any way, except through the use of SOLAR or COMUS

415 System Library Structure BANK-BDI$ The element BANK-BDI$ is an omnibus element containing BDI Bank attributes Element and version name of the common bank absolute Bank name Gate target Linkage register Subsystem BDI The BANK-BDI$ element format is as follows: Head 0 identifier Head 1 Format type reserved 1 bank count Text 0 bdi value attribute bits Text 1 varies, depending on whether you are describing an AFCB or an SGB where: identifier format identifies this as the BANK-BDI$ omnibus element. It must contain the characters AFCB. Format: 4 ASCII characters. indicates the format of the element; zero-filled. Format: 6-bit status

416 System Library Structure type identifies this as a bank definition element. The possible value for this variable is one of the following: 0 indicates that it is a FILE-BDI$ element. 1 indicates that it is a BANK-BDI$ element. Format: 6-bit status reserved 1 reserved for future use; zero-filled. Format: 6-bit logical. bank count is the number of banks described in the element. It indicates how many times the text words repeat. Format: 18-bit unsigned integer. bdi value is the BDI being described. If the value is zero, this entry does not define a bank. Format: 18-bit unsigned integer. attribute bits Dynamic. If set to 1, the bank is dynamic. Static. If set to 1, the bank is static. Write protected. If set to 1, the bank is write protected. Write enabled. If set to 1, the bank is write enabled. Test-and-set queuing. If set to 1, the bank is registered for test-and-set queuing. No test-and-set queuing. If set to 1, the bank is not registered for test-andset queuing

417 System Library Structure 24 Contingency processing and CREG contingency processing. If set to 1 and bit 25 is 0, the bank is registered for contingency processing. If set to 1 and bit 25 is set to 1, the bank is registered for CREG contingency processing. 25 No contingency processing and CREG contingency processing. If set to 1 and bit 24 is 0, the bank is not registered for contingency processing. If set to 1 and bit 24 is set to 1, the bank is registered for CREG contingency processing. 26 Program contingency processing. If set to 1, the bank is registered for program contingency processing. 27 No program contingency processing. If set to 1, the bank is not registered for program contingency processing. 28 Guaranteed entry point. If set to 1, the bank is a guaranteed entry-point bank. 29 No guaranteed entry point. If set to 1, the bank is not a guaranteed entry-point bank. 30 Positioned. If set to 1, memory positioning is required. 31 Not positioned. If set to 1, memory positioning is not required. 32 Fixed gate subsystem. If set to 0, the bank is an AFCB. If set to 1, element-name is a subsystem definition element. Subsystems are created and manipulated using the Linking System. 33 Gate. If set to 0, the bank is an AFCB. If set to 1, the bank is a security gate bank (SGB)

418 System Library Structure Gate target. If set to 1, the bank is the target of an SGB. Bound shared subsystem. If set to 1, the element name is a subsystem definition element. The following paragraphs describe the format of text words 1 through 9 for AFCBs. Text words 1 through 6 element name version name indicate the absolute element or element and version that contains the specified BDI. The format for entries in this field is 12 ASCII characters. Text words 6 through 9 bank name is the symbolic name of the bank as defined on the IBANK or DBANK Collector directives. When the absolute element contains only one bank, this field can be zero-(nul) filled. Format: 12 ASCII characters. The following paragraphs describe the format of text words 1 through 9 for SGBs. Text word 1 gate bdi is the value of the BDI that will be used as an SGB. Format: 18-bit unsigned integer. other subsystem Text word 2 is the value of the BDI in a different file, which represents the SGB of another subsystem. Format: 18-bit unsigned integer. linkage register is the octal value of the X-register to be used to base the common bank that is the target of the SGB. Format: 4-bit unsigned integer

419 System Library Structure Words 3 through 9 are unused for SGBs. Listing the BANK-BDI$ Element The contents of the BANK-BDI$ element is reflected in the COMUSINSRPT Report 4. See the COMUS End Use Reference Manual for more information on COMUSINSRPT. You can also obtain this information from reports generated by the SOLAR PRODRT utility. See the SOLAR End Use Reference Manual for more information on the SOLAR PRODRT utility Subsystem Definition Elements An SSD element (element type 6, subtype 2) exists in each product installation file that contains a subsystem. The element contains a coded description of the characteristics of the subsystem. The SSD element is produced by SOLAR and COMUS invoke SSDP during installation processing File Security on Product Installation Files The SOLAR load utility provides the same type of file security as COMUS. Using the LOAD_FILE_SECURITY configuration SGS, you can specify the file security to be no security, random write keys, or cataloging private files. For more information about file security when using SOLAR, see the SOLAR End Use Reference Manual. The type of security provided by COMUS for product installation files is based on the value of the default variable SECURITY in the COMUS database. The possibilities are no security, random write keys, and cataloging private files. For more information about security on product installation files, see the INSTALL command in the COMUS End Use Reference Manual SYS$LIB$*PROC$ The file SYS$LIB$*PROC$ contains system library procedures. Library procedure elements are released with many system software products, including DPS 2200, Sort, and SYSLIB. SOLAR and COMUS create and update SYS$LIB$*PROC$ during product installation and deinstallation. System library procedures released with the various system software products are copied into this file when the product is installed. When the product is removed, the appropriate procedure elements are removed from the file SYS$*RUN$ and SYS$LIB$*RUN$ The files SYS$*RUN$ and SYS$LIB$*RUN$ contain system runstreams. These runstreams are generally invoked using the unsolicited keyin ST at the system console. Runstream elements are released with many system software products, including Exec, MAPPER, COMUS, UDS, and CMS. SOLAR and COMUS copy these runstreams to SYS$LIB$*RUN$ at product installation time

420 System Library Structure The file SYS$*RUN$ is one of the system files on the Exec boot tape. It is copied to the boot tape during an Exec product generation. The following runstreams must be included in SYS$*RUN$ on the boot tape: BOOTELT MSCP MSADD LIBLOAD LIBLOAD/FAS LIBSAVE LIBSAVE/FAS INSTALLSOLAR The file SYS$LIB$*RUN$ is created and updated by SOLAR and COMUS during product installation. System runstreams released with system software products are copied into this file when the product is installed. When the product is removed, the appropriate runstreams are removed from the file. Note: The elements B4ROLBAK or B4ROLBAK/FAS, AFROLBAK or AFROLBAK/FAS, B4ROLOUT or B4ROLOUT/FAS, and AFROLOUT or AFROLOUT/FAS are installed with ROLRUNS and must be in the file SYS$LIB$*RUN$. The Exec looks for these elements only in this file AUTO$START Elements The AUTO$START element in SYS$LIB$*RUN$ contains the names of runstreams that are to be initiated each time the system is booted. Each product that releases runstreams defines whether these runstreams should be included in the AUTO$START element. COMUS and SOLAR insert image at the beginning of the element. For SYS$LIB$*RUN$.CMR SYS$LIB$ and SYS$LIB$*LIB$ The files SYS$*LIB$ and SYS$LIB$*LIB$ contain system processors and common banks

421 System Library Structure SYS$*LIB$ The file SYS$*LIB$ is one of the system files on the Exec boot tape. It is copied to the Exec boot tape during an Exec product generation. Stand-alone versions of the following processors must be included in SYS$*LIB$ on the boot tape: DLL DPREP E$ORMSG ED level 16R1D or higher ELT level 8R1 or higher FURPUR level 28R3A or higher (This must be the non-reentrant version of FURPUR. On the FURPUR release tape, this is the element FURTST in the ABS$ file. You should copy it into the LIB$ file under the element name FURPUR.) MSB MSCP PMD level 32R2 or higher (PMD is required only with SB1R1 and SB1R1A. Subsequent SBs do not require PMD.) SAUFILBUILD (mandatory for the 1100/90 system only) SAUTRIGGER (mandatory for the 1100/90 system only) FAS level 2R1 or higher SSG level 22R1 or higher Other processors can be included in SYS$*LIB$ to fulfill site-specific requirements SYS$LIB$*LIB$ With the old library structure, the file SYS$LIB$*LIB$ was created by the LIB$CONVERT mechanism. This mechanism has been replaced in the new library structure by the system generation for AFCBs feature in the Exec. See for more information on this feature SYS$*RLIB$ SYS$*RLIB$ is released on the Exec boot tape. It contains the Executive request (ER) mnemonic definitions (ERU$), the assembler procedures used to call ERs (PROC$ER), and the common bank definitions (CERU$). The file SYS$*RLIB$ is automatically searched by Meta-Assembler (MASM), the Collector, and the Linking System

422 System Library Structure

423 Section 14 Zero Overhead Object Module Format This section defines the format of the Zero Overhead Object Module (ZOOM). The ZOOM is an object file type created by the Linking System in OS The linking system creates a ZOOM when you include any of the following statements in your static link: process for extended zoom process for extended fast_load output zoom output fast_load output hvtip output hvtip ZOOM Format Overview The ZOOM format differs from the OM format because it includes bank descriptor structures which are not included in the OM. These structures allow the Exec to load a ZOOM for execution without having to invoke the Linking System. The ZOOM header is pointed to the ZOOM header offset field of the Object Module Control Header (it is a word offset from the beginning of the element). The ZOOM header starts on a sector boundary and contains or points to all the other data structures in the ZOOM control information. It also contains pointers to the text of the banks. ZOOM Level StructuresFigure 14 1 shows an overview of the ZOOM structure and how they are related. This view does not show the OM Control Header since it has the same fields as the Program File Table of Contents (TOC) entry for the ZOOM ZOOM Level Structures Figure 14 1 shows an overview of the ZOOM structure and how they are related. This view does not show the OM Control Header since it has the same fields as the Program File Table of Contents (TOC) entry for the ZOOM

424 Zero Overhead Object Module Figure Zoom Structure Program File Table of Contents (TOC) Section 8.6.3, Executable Element Table Item, describes the format for the program file table of contents entry for an executable element which includes ZOOMs. Word 06 points to OM Header. It is a sector offset from the beginning of the element to the beginning of the OM Header. Word 07, bits 12-17, if non-zero, is the sector offset from the beginning of the OM Header to the ZOOM Header. This 6-bit field is called the zoom header offset in the OM Control Header and appears at Word 010 in the OM Control Header. The TOC entry provides a short-cut to the ZOOM header. Refer to Section 7.2.3, OM Header for more information on the OM Header. Word 010 points to the OM Control Header. It is a sector offset relative to the beginning of the element. The linking system also embeds a copy of the initial TOC entry within the OM Control Header. Refer to Section 7.2.2, OM Control Header for more information on the OM Control Header ZOOM Header Figure 14 2 shows the format of the ZOOM Header. The ZOOM Header contains general load information about the OM and pointers to other structures. 00 version number bank group count 01 bank id table offset 02 bank id table size bank load table size bank group table size 03 start dollar 04 latent parameter value start bank group

Distributed Data Processing (DDP-PPC) TCP/IP Interface COBOL

Distributed Data Processing (DDP-PPC) TCP/IP Interface COBOL !()+ OS 2200 Distributed Data Processing (DDP-PPC) TCP/IP Interface COBOL Programming Guide Copyright ( 1997 Unisys Corporation. All rights reserved. Unisys is a registered trademark of Unisys Corporation.

More information

unisys OS 2200 Shared File System (SFS 2200) Administration and Support Reference Manual imagine it. done. Release Level 4R1 June 2010 7831 0786 003

unisys OS 2200 Shared File System (SFS 2200) Administration and Support Reference Manual imagine it. done. Release Level 4R1 June 2010 7831 0786 003 unisys imagine it. done. OS 2200 Shared File System (SFS 2200) Administration and Support Reference Manual Release Level 4R1 June 2010 7831 0786 003 NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT.

More information

UNISYS. ClearPath Enterprise Servers. Authentication Sentinel for OS 2200 User Guide. ClearPath OS 2200 Release 8.2

UNISYS. ClearPath Enterprise Servers. Authentication Sentinel for OS 2200 User Guide. ClearPath OS 2200 Release 8.2 ClearPath Enterprise Servers Authentication Sentinel for OS 2200 User Guide UNISYS 2004 Unisys Corporation. All rights reserved. ClearPath OS 2200 Release 8.2 Printed in USA September 2004 4729 2016 000

More information

Streaming Lossless Data Compression Algorithm (SLDC)

Streaming Lossless Data Compression Algorithm (SLDC) Standard ECMA-321 June 2001 Standardizing Information and Communication Systems Streaming Lossless Data Compression Algorithm (SLDC) Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch

More information

Server Sentinel Monitored Server

Server Sentinel Monitored Server Server Sentinel Monitored Server Installation and Reinstallation Guide for Systems Monitoring Third-Party Products Server Sentinel 4.4.3 and Higher April 2007 . unisys imagine it. done. Server Sentinel

More information

Embedded Systems. Review of ANSI C Topics. A Review of ANSI C and Considerations for Embedded C Programming. Basic features of C

Embedded Systems. Review of ANSI C Topics. A Review of ANSI C and Considerations for Embedded C Programming. Basic features of C Embedded Systems A Review of ANSI C and Considerations for Embedded C Programming Dr. Jeff Jackson Lecture 2-1 Review of ANSI C Topics Basic features of C C fundamentals Basic data types Expressions Selection

More information

Name: Class: Date: 9. The compiler ignores all comments they are there strictly for the convenience of anyone reading the program.

Name: Class: Date: 9. The compiler ignores all comments they are there strictly for the convenience of anyone reading the program. Name: Class: Date: Exam #1 - Prep True/False Indicate whether the statement is true or false. 1. Programming is the process of writing a computer program in a language that the computer can respond to

More information

Motorola 8- and 16-bit Embedded Application Binary Interface (M8/16EABI)

Motorola 8- and 16-bit Embedded Application Binary Interface (M8/16EABI) Motorola 8- and 16-bit Embedded Application Binary Interface (M8/16EABI) SYSTEM V APPLICATION BINARY INTERFACE Motorola M68HC05, M68HC08, M68HC11, M68HC12, and M68HC16 Processors Supplement Version 2.0

More information

Faculty of Engineering Student Number:

Faculty of Engineering Student Number: Philadelphia University Student Name: Faculty of Engineering Student Number: Dept. of Computer Engineering Final Exam, First Semester: 2012/2013 Course Title: Microprocessors Date: 17/01//2013 Course No:

More information

unisys ClearPath Enterprise Servers Remote Database Backup Planning and Operations Guide ClearPath MCP 14.0 April 2012 8600 2052 309

unisys ClearPath Enterprise Servers Remote Database Backup Planning and Operations Guide ClearPath MCP 14.0 April 2012 8600 2052 309 unisys ClearPath Enterprise Servers Remote Database Backup Planning and Operations Guide ClearPath MCP 14.0 April 2012 8600 2052 309 NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product

More information

Server Sentinel Client Workstation

Server Sentinel Client Workstation Server Sentinel Client Workstation Installation and Reinstallation Guide Server Sentinel 4.4.3 and Higher April 2008 . unisys imagine it. done. Server Sentinel Client Workstation Installation and Reinstallation

More information

UNISYS. Business Information Server. MRI Administration and User s Guide. Printed in USA May 2004 7846 0391 013

UNISYS. Business Information Server. MRI Administration and User s Guide. Printed in USA May 2004 7846 0391 013 Business Information Server MRI Administration and User s Guide UNISYS 2004 Unisys Corporation. All rights reserved. Printed in USA May 2004 7846 0391 013 NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS

More information

DATA ITEM DESCRIPTION

DATA ITEM DESCRIPTION DD Form 1664, APR 89 Previous editions are obsolete Page 1 of 4 Pages 135/123 DATA ITEM DESCRIPTION Form Approved OMB NO.0704-0188 Public reporting burden for collection of this information is estimated

More information

First Bytes Programming Lab 2

First Bytes Programming Lab 2 First Bytes Programming Lab 2 This lab is available online at www.cs.utexas.edu/users/scottm/firstbytes. Introduction: In this lab you will investigate the properties of colors and how they are displayed

More information

unisys Distributed Processing Middleware Open Distributed Transaction Processing Administration Guide Volume 2: Building Applications

unisys Distributed Processing Middleware Open Distributed Transaction Processing Administration Guide Volume 2: Building Applications unisys Distributed Processing Middleware Open Distributed Transaction Processing Administration Guide Volume 2: Building Applications ClearPath OS 2200 Release 13.1 February 2012 7833 5080 009 NO WARRANTIES

More information

ERserver. DB2 Universal Database for iseries SQL Programming with Host Languages. iseries. Version 5

ERserver. DB2 Universal Database for iseries SQL Programming with Host Languages. iseries. Version 5 ERserver iseries DB2 Universal Database for iseries SQL Programming with Host Languages Version 5 ERserver iseries DB2 Universal Database for iseries SQL Programming with Host Languages Version 5 Copyright

More information

Expedite for Windows Software Development Kit Programming Guide

Expedite for Windows Software Development Kit Programming Guide GXS EDI Services Expedite for Windows Software Development Kit Programming Guide Version 6 Release 2 GC34-3285-02 Fifth Edition (November 2005) This edition replaces the Version 6.1 edition. Copyright

More information

Accounts Receivable. Chapter

Accounts Receivable. Chapter Chapter 7 Accounts Receivable The Accounts Receivable module displays information about individual outstanding income sources. Use this screen to verify that invoice receipts, cash receipts, and other

More information

Chapter 2 Assemblers http://www.intel.com/multi-core/demos.htm

Chapter 2 Assemblers http://www.intel.com/multi-core/demos.htm Chapter 2 Assemblers http://www.intel.com/multi-core/demos.htm Source Program Assembler Object Code Linker Executable Code Loader 1 Outline 2.1 Basic Assembler Functions A simple SIC assembler Assembler

More information

IBM Gentran:Server for Microsoft Windows. HIPAA and NCPDP Compliance Guide

IBM Gentran:Server for Microsoft Windows. HIPAA and NCPDP Compliance Guide IBM Gentran:Server for Microsoft Windows HIPAA and NCPDP Compliance Guide Version 5.3 4232-520-USER29-0001 Copyright This edition applies to the 5.3 Version of IBM Sterling Gentran:Server for Microsoft

More information

2. Compressing data to reduce the amount of transmitted data (e.g., to save money).

2. Compressing data to reduce the amount of transmitted data (e.g., to save money). Presentation Layer The presentation layer is concerned with preserving the meaning of information sent across a network. The presentation layer may represent (encode) the data in various ways (e.g., data

More information

Glossary of Object Oriented Terms

Glossary of Object Oriented Terms Appendix E Glossary of Object Oriented Terms abstract class: A class primarily intended to define an instance, but can not be instantiated without additional methods. abstract data type: An abstraction

More information

KB_SQL SQL Reference Guide Version 4

KB_SQL SQL Reference Guide Version 4 KB_SQL SQL Reference Guide Version 4 1995, 1999 by KB Systems, Inc. All rights reserved. KB Systems, Inc., Herndon, Virginia, USA. Printed in the United States of America. No part of this manual may be

More information

UNISYS. Server Management 2.0. Software Release Announcement. imagine it. done. Server Management 2.0 and Higher. May 2008 8216 3445 000

UNISYS. Server Management 2.0. Software Release Announcement. imagine it. done. Server Management 2.0 and Higher. May 2008 8216 3445 000 UNISYS imagine it. done. Server Management 2.0 Software Release Announcement Server Management 2.0 and Higher May 2008 8216 3445 000 NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product

More information

For OS/390, VM, VSE. Extended Reporting Facility Guide 6.2 SP3

For OS/390, VM, VSE. Extended Reporting Facility Guide 6.2 SP3 For OS/390, VM, VSE Extended Reporting Facility Guide 6.2 SP3 Release 6.2, May 1996 Updated: April 1999 This documentation and related computer software program (hereinafter referred to as the Documentation

More information

VISUAL GUIDE to. RX Scripting. for Roulette Xtreme - System Designer 2.0

VISUAL GUIDE to. RX Scripting. for Roulette Xtreme - System Designer 2.0 VISUAL GUIDE to RX Scripting for Roulette Xtreme - System Designer 2.0 UX Software - 2009 TABLE OF CONTENTS INTRODUCTION... ii What is this book about?... iii How to use this book... iii Time to start...

More information

Banking Back-Office Processing

Banking Back-Office Processing Banking Back-Office Processing Guide to Setting Up the Retail System Copyright 2002, Unisys Corporation. All rights reserved Unisys is a trademark of Unisys Corporation Release 9.000 October 2003 Printed

More information

Advanced Computer Architecture-CS501. Computer Systems Design and Architecture 2.1, 2.2, 3.2

Advanced Computer Architecture-CS501. Computer Systems Design and Architecture 2.1, 2.2, 3.2 Lecture Handout Computer Architecture Lecture No. 2 Reading Material Vincent P. Heuring&Harry F. Jordan Chapter 2,Chapter3 Computer Systems Design and Architecture 2.1, 2.2, 3.2 Summary 1) A taxonomy of

More information

1 The Java Virtual Machine

1 The Java Virtual Machine 1 The Java Virtual Machine About the Spec Format This document describes the Java virtual machine and the instruction set. In this introduction, each component of the machine is briefly described. This

More information

Introduction. What is an Operating System?

Introduction. What is an Operating System? Introduction What is an Operating System? 1 What is an Operating System? 2 Why is an Operating System Needed? 3 How Did They Develop? Historical Approach Affect of Architecture 4 Efficient Utilization

More information

Instruction Set Architecture (ISA)

Instruction Set Architecture (ISA) Instruction Set Architecture (ISA) * Instruction set architecture of a machine fills the semantic gap between the user and the machine. * ISA serves as the starting point for the design of a new machine

More information

ASSEMBLY LANGUAGE PROGRAMMING (6800) (R. Horvath, Introduction to Microprocessors, Chapter 6)

ASSEMBLY LANGUAGE PROGRAMMING (6800) (R. Horvath, Introduction to Microprocessors, Chapter 6) ASSEMBLY LANGUAGE PROGRAMMING (6800) (R. Horvath, Introduction to Microprocessors, Chapter 6) 1 COMPUTER LANGUAGES In order for a computer to be able to execute a program, the program must first be present

More information

Experiment #3 Programming the PLC Via Ladder logic. OBJECTIVES After successfully completing this laboratory, you should be able to:

Experiment #3 Programming the PLC Via Ladder logic. OBJECTIVES After successfully completing this laboratory, you should be able to: Experiment #3 Programming the PLC Via Ladder logic OBJECTIVES After successfully completing this laboratory, you should be able to: to convert a simple electrical ladder diagram to a PLC program. Know

More information

NiCE Log File Management Pack. for. System Center Operations Manager 2012. Quick Start Guide

NiCE Log File Management Pack. for. System Center Operations Manager 2012. Quick Start Guide NiCE Log File Management Pack for System Center Operations Manager 2012 Version 1.30 March 2015 Quick Start Guide Legal Notices NiCE IT Management Solutions GmbH makes no warranty of any kind with regard

More information

Exceptions in MIPS. know the exception mechanism in MIPS be able to write a simple exception handler for a MIPS machine

Exceptions in MIPS. know the exception mechanism in MIPS be able to write a simple exception handler for a MIPS machine 7 Objectives After completing this lab you will: know the exception mechanism in MIPS be able to write a simple exception handler for a MIPS machine Introduction Branches and jumps provide ways to change

More information

Volume I, Section 4 Table of Contents

Volume I, Section 4 Table of Contents Volume I, Section 4 Table of Contents 4 Software Standards...4-1 4.1 Scope...4-1 4.1.1 Software Sources...4-2 4.1.2 Location and Control of Software and Hardware on Which it Operates...4-2 4.1.3 Exclusions...4-3

More information

AEI RAIL NETWORK SERVER User Manual

AEI RAIL NETWORK SERVER User Manual AEI RAIL NETWORK SERVER User Manual Copyright 2000 Signal Computer Consultants All rights reserved Signal Computer Consultants P.O. Box 18445 Pittsburgh, PA 15236 Tel. 888 872-4612 (toll free US and Canada

More information

DBF Chapter. Note to UNIX and OS/390 Users. Import/Export Facility CHAPTER 7

DBF Chapter. Note to UNIX and OS/390 Users. Import/Export Facility CHAPTER 7 97 CHAPTER 7 DBF Chapter Note to UNIX and OS/390 Users 97 Import/Export Facility 97 Understanding DBF Essentials 98 DBF Files 98 DBF File Naming Conventions 99 DBF File Data Types 99 ACCESS Procedure Data

More information

2) Write in detail the issues in the design of code generator.

2) Write in detail the issues in the design of code generator. COMPUTER SCIENCE AND ENGINEERING VI SEM CSE Principles of Compiler Design Unit-IV Question and answers UNIT IV CODE GENERATION 9 Issues in the design of code generator The target machine Runtime Storage

More information

Z80 Instruction Set. Z80 Assembly Language

Z80 Instruction Set. Z80 Assembly Language 75 Z80 Assembly Language The assembly language allows the user to write a program without concern for memory addresses or machine instruction formats. It uses symbolic addresses to identify memory locations

More information

Rational Rational ClearQuest

Rational Rational ClearQuest Rational Rational ClearQuest Version 7.0 Windows Using Project Tracker GI11-6377-00 Rational Rational ClearQuest Version 7.0 Windows Using Project Tracker GI11-6377-00 Before using this information, be

More information

unisys OS 2200 Relational Data Management System (RDMS 2200) and IPF SQL Interface End Use Guide imagine it. done. ClearPath OS 2200 12.

unisys OS 2200 Relational Data Management System (RDMS 2200) and IPF SQL Interface End Use Guide imagine it. done. ClearPath OS 2200 12. unisys imagine it. done. OS 2200 Relational Data Management System (RDMS 2200) and IPF SQL Interface End Use Guide ClearPath OS 2200 12.1 Release June 2010 7831 0778 003 NO WARRANTIES OF ANY NATURE ARE

More information

This section describes how LabVIEW stores data in memory for controls, indicators, wires, and other objects.

This section describes how LabVIEW stores data in memory for controls, indicators, wires, and other objects. Application Note 154 LabVIEW Data Storage Introduction This Application Note describes the formats in which you can save data. This information is most useful to advanced users, such as those using shared

More information

INFORMATION TECHNOLOGY STANDARD

INFORMATION TECHNOLOGY STANDARD COMMONWEALTH OF PENNSYLVANIA DEPARTMENT OF PUBLIC WELFARE INFORMATION TECHNOLOGY STANDARD Name Of Standard: DMS 2200 Physical Implementation Domain: Data Date Issued: 08/14/2007 Date Revised: Number: STD-DMS002

More information

PART B QUESTIONS AND ANSWERS UNIT I

PART B QUESTIONS AND ANSWERS UNIT I PART B QUESTIONS AND ANSWERS UNIT I 1. Explain the architecture of 8085 microprocessor? Logic pin out of 8085 microprocessor Address bus: unidirectional bus, used as high order bus Data bus: bi-directional

More information

Enterprise Server. Application Sentinel for SQL Server Installation and Configuration Guide. Application Sentinel 2.0 and Higher

Enterprise Server. Application Sentinel for SQL Server Installation and Configuration Guide. Application Sentinel 2.0 and Higher Enterprise Server Application Sentinel for SQL Server Installation and Configuration Guide Application Sentinel 2.0 and Higher August 2004 Printed in USA 3832 1097 000 . Enterprise Server Application Sentinel

More information

CPU Organization and Assembly Language

CPU Organization and Assembly Language COS 140 Foundations of Computer Science School of Computing and Information Science University of Maine October 2, 2015 Outline 1 2 3 4 5 6 7 8 Homework and announcements Reading: Chapter 12 Homework:

More information

TeamQuest SMFII and TeamQuest Online for Unisys MCP Systems

TeamQuest SMFII and TeamQuest Online for Unisys MCP Systems TeamQuest SMFII and TeamQuest Online for Unisys MCP Systems ADMINISTRATION GUIDE Copyright 2012 TeamQuest Corporation. All Rights Reserved. April 2012 Levels 54.017 and 55.017 TQ 02211.16 The names, places

More information

Chapter 12 File Management

Chapter 12 File Management Operating Systems: Internals and Design Principles, 6/E William Stallings Chapter 12 File Management Dave Bremer Otago Polytechnic, N.Z. 2008, Prentice Hall Roadmap Overview File organisation and Access

More information

Chapter 12 File Management. Roadmap

Chapter 12 File Management. Roadmap Operating Systems: Internals and Design Principles, 6/E William Stallings Chapter 12 File Management Dave Bremer Otago Polytechnic, N.Z. 2008, Prentice Hall Overview Roadmap File organisation and Access

More information

PeopleSoft HR 9.1 PeopleBook: Administer Compensation

PeopleSoft HR 9.1 PeopleBook: Administer Compensation PeopleSoft HR 9.1 PeopleBook: Administer Compensation March 2012 PeopleSoft HR 9.1 PeopleBook: Administer Compensation SKU hcm91fp2hhac-b0312 Copyright 1988, 2012, Oracle and/or its affiliates. All rights

More information

MICROPROCESSOR AND MICROCOMPUTER BASICS

MICROPROCESSOR AND MICROCOMPUTER BASICS Introduction MICROPROCESSOR AND MICROCOMPUTER BASICS At present there are many types and sizes of computers available. These computers are designed and constructed based on digital and Integrated Circuit

More information

JD Edwards World. Advanced Programming Concepts and Skills Guide Release A9.3 E21952-02

JD Edwards World. Advanced Programming Concepts and Skills Guide Release A9.3 E21952-02 JD Edwards World Advanced Programming Concepts and Skills Guide Release A9.3 E21952-02 April 2013 JD Edwards World Advanced Programming Concepts and Skills Guide, Release A9.3 E21952-02 Copyright 2013,

More information

Using Oracle Time Management. Release 11.i A77086-01

Using Oracle Time Management. Release 11.i A77086-01 Using Oracle Time Management Release 11.i A77086-01 Using Oracle Time Management, Release 11.i (A77086-01) Copyright Oracle Corporation 1999 Primary Author: Joycelyn Smith. Contributing Authors: Linda

More information

Getting Started with IntelleView POS Administrator Software

Getting Started with IntelleView POS Administrator Software Getting Started with IntelleView POS Administrator Software Administrator s Guide for Software Version 1.2 About this Guide This administrator s guide explains how to start using your IntelleView POS (IntelleView)

More information

Instruction Set Architecture

Instruction Set Architecture Instruction Set Architecture Consider x := y+z. (x, y, z are memory variables) 1-address instructions 2-address instructions LOAD y (r :=y) ADD y,z (y := y+z) ADD z (r:=r+z) MOVE x,y (x := y) STORE x (x:=r)

More information

Ohio University Computer Services Center August, 2002 Crystal Reports Introduction Quick Reference Guide

Ohio University Computer Services Center August, 2002 Crystal Reports Introduction Quick Reference Guide Open Crystal Reports From the Windows Start menu choose Programs and then Crystal Reports. Creating a Blank Report Ohio University Computer Services Center August, 2002 Crystal Reports Introduction Quick

More information

The University of Nottingham

The University of Nottingham The University of Nottingham School of Computer Science A Level 1 Module, Autumn Semester 2007-2008 Computer Systems Architecture (G51CSA) Time Allowed: TWO Hours Candidates must NOT start writing their

More information

Memory Systems. Static Random Access Memory (SRAM) Cell

Memory Systems. Static Random Access Memory (SRAM) Cell Memory Systems This chapter begins the discussion of memory systems from the implementation of a single bit. The architecture of memory chips is then constructed using arrays of bit implementations coupled

More information

A single register, called the accumulator, stores the. operand before the operation, and stores the result. Add y # add y from memory to the acc

A single register, called the accumulator, stores the. operand before the operation, and stores the result. Add y # add y from memory to the acc Other architectures Example. Accumulator-based machines A single register, called the accumulator, stores the operand before the operation, and stores the result after the operation. Load x # into acc

More information

INTRODUCTION TO FLOWCHARTING

INTRODUCTION TO FLOWCHARTING CHAPTER 1 INTRODUCTION TO FLOWCHARTING 1.0 Objectives 1.1 Introduction 1.2 Flowcharts 1.3 Types of Flowcharts 1.3.1 Types of flowchart 1.3.2 System flowcharts 1.4 Flowchart Symbols 1.5 Advantages of Flowcharts

More information

The programming language C. sws1 1

The programming language C. sws1 1 The programming language C sws1 1 The programming language C invented by Dennis Ritchie in early 1970s who used it to write the first Hello World program C was used to write UNIX Standardised as K&C (Kernighan

More information

HIPAA Compliance and NCPDP User Guide

HIPAA Compliance and NCPDP User Guide IBM Sterling Gentran:Server for UNIX IBM Sterling Gentran:Server for UNIX - Workstation HIPAA Compliance and NCPDP User Guide Version 6.2 Copyright This edition applies to the 6.2 Version of IBM Sterling

More information

CHAPTER 7: The CPU and Memory

CHAPTER 7: The CPU and Memory CHAPTER 7: The CPU and Memory The Architecture of Computer Hardware, Systems Software & Networking: An Information Technology Approach 4th Edition, Irv Englander John Wiley and Sons 2010 PowerPoint slides

More information

Sentinel Management Server

Sentinel Management Server Sentinel Management Server Installation, Reinstallation, and Upgrade Guide Server Sentinel 4.4.3 and Higher April 2007 . unisys imagine it. done. Sentinel Management Server Installation, Reinstallation,

More information

Audit Trail Administration

Audit Trail Administration Audit Trail Administration 0890431-030 August 2003 Copyright 2003 by Concurrent Computer Corporation. All rights reserved. This publication or any part thereof is intended for use with Concurrent Computer

More information

Intel Retail Client Manager Audience Analytics

Intel Retail Client Manager Audience Analytics Intel Retail Client Manager Audience Analytics By using this document, in addition to any agreements you have with Intel, you accept the terms set forth below. You may not use or facilitate the use of

More information

Example of Standard API

Example of Standard API 16 Example of Standard API System Call Implementation Typically, a number associated with each system call System call interface maintains a table indexed according to these numbers The system call interface

More information

Bachelors of Computer Application Programming Principle & Algorithm (BCA-S102T)

Bachelors of Computer Application Programming Principle & Algorithm (BCA-S102T) Unit- I Introduction to c Language: C is a general-purpose computer programming language developed between 1969 and 1973 by Dennis Ritchie at the Bell Telephone Laboratories for use with the Unix operating

More information

Informatica e Sistemi in Tempo Reale

Informatica e Sistemi in Tempo Reale Informatica e Sistemi in Tempo Reale Introduction to C programming Giuseppe Lipari http://retis.sssup.it/~lipari Scuola Superiore Sant Anna Pisa October 25, 2010 G. Lipari (Scuola Superiore Sant Anna)

More information

TN203. Porting a Program to Dynamic C. Introduction

TN203. Porting a Program to Dynamic C. Introduction TN203 Porting a Program to Dynamic C Introduction Dynamic C has a number of improvements and differences compared to many other C compiler systems. This application note gives instructions and suggestions

More information

Chapter 7D The Java Virtual Machine

Chapter 7D The Java Virtual Machine This sub chapter discusses another architecture, that of the JVM (Java Virtual Machine). In general, a VM (Virtual Machine) is a hypothetical machine (implemented in either hardware or software) that directly

More information

Server Management 2.0

Server Management 2.0 Server Management 2.0 Installation and Configuration Guide Server Management 2.0 and Higher May 2008 . unisys imagine it. done. Server Management 2.0 Installation and Configuration Guide Server Management

More information

THREE YEAR DEGREE (HONS.) COURSE BACHELOR OF COMPUTER APPLICATION (BCA) First Year Paper I Computer Fundamentals

THREE YEAR DEGREE (HONS.) COURSE BACHELOR OF COMPUTER APPLICATION (BCA) First Year Paper I Computer Fundamentals THREE YEAR DEGREE (HONS.) COURSE BACHELOR OF COMPUTER APPLICATION (BCA) First Year Paper I Computer Fundamentals Full Marks 100 (Theory 75, Practical 25) Introduction to Computers :- What is Computer?

More information

VERITAS NetBackup 6.0 for Oracle

VERITAS NetBackup 6.0 for Oracle VERITAS NetBackup 6.0 for Oracle System Administrator s Guide for UNIX and Linux N15262B September 2005 Disclaimer The information contained in this publication is subject to change without notice. VERITAS

More information

Visual Logic Instructions and Assignments

Visual Logic Instructions and Assignments Visual Logic Instructions and Assignments Visual Logic can be installed from the CD that accompanies our textbook. It is a nifty tool for creating program flowcharts, but that is only half of the story.

More information

Modbus Communications for PanelView Terminals

Modbus Communications for PanelView Terminals User Guide Modbus Communications for PanelView Terminals Introduction This document describes how to connect and configure communications for the Modbus versions of the PanelView terminals. This document

More information

13-1. This chapter explains how to use different objects.

13-1. This chapter explains how to use different objects. 13-1 13.Objects This chapter explains how to use different objects. 13.1. Bit Lamp... 13-3 13.2. Word Lamp... 13-5 13.3. Set Bit... 13-9 13.4. Set Word... 13-11 13.5. Function Key... 13-18 13.6. Toggle

More information

Application Note. Introduction AN2471/D 3/2003. PC Master Software Communication Protocol Specification

Application Note. Introduction AN2471/D 3/2003. PC Master Software Communication Protocol Specification Application Note 3/2003 PC Master Software Communication Protocol Specification By Pavel Kania and Michal Hanak S 3 L Applications Engineerings MCSL Roznov pod Radhostem Introduction The purpose of this

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

PeopleSoft Enterprise Human Resources 9.1 PeopleBook: Administer Compensation

PeopleSoft Enterprise Human Resources 9.1 PeopleBook: Administer Compensation PeopleSoft Enterprise Human Resources 9.1 PeopleBook: Administer Compensation November 2010 PeopleSoft Enterprise Human Resources 9.1 PeopleBook: Administer Compensation SKU hrms91hhac-b1110 Copyright

More information

Packet Capture. Document Scope. SonicOS Enhanced Packet Capture

Packet Capture. Document Scope. SonicOS Enhanced Packet Capture Packet Capture Document Scope This solutions document describes how to configure and use the packet capture feature in SonicOS Enhanced. This document contains the following sections: Feature Overview

More information

Introduction to Wireshark Network Analysis

Introduction to Wireshark Network Analysis Introduction to Wireshark Network Analysis Page 2 of 24 Table of Contents INTRODUCTION 4 Overview 4 CAPTURING LIVE DATA 5 Preface 6 Capture Interfaces 6 Capture Options 6 Performing the Capture 8 ANALYZING

More information

1995 Microprocessor Development Systems

1995 Microprocessor Development Systems User s Guide 1995 Microprocessor Development Systems Printed in U.S.A., March 1995 SDS SPRU018D User s Guide 1995 TMS320C1x/C2x/C2xx/C5x Assembly Language Tools User s Guide Printed on Recycled Paper IMPORTANT

More information

BrightStor ARCserve Backup for Windows

BrightStor ARCserve Backup for Windows BrightStor ARCserve Backup for Windows Agent for Microsoft SQL Server r11.5 D01173-2E This documentation and related computer software program (hereinafter referred to as the "Documentation") is for the

More information

Section of DBMS Selection & Evaluation Questionnaire

Section of DBMS Selection & Evaluation Questionnaire Section of DBMS Selection & Evaluation Questionnaire Whitemarsh Information Systems Corporation 2008 Althea Lane Bowie, Maryland 20716 Tele: 301-249-1142 Email: mmgorman@wiscorp.com Web: www.wiscorp.com

More information

unisys ClearPath Enterprise Servers User Authentication Administration Guide ClearPath OS 2200 Release 15.0 February 2014 7850 4586 008

unisys ClearPath Enterprise Servers User Authentication Administration Guide ClearPath OS 2200 Release 15.0 February 2014 7850 4586 008 unisys ClearPath Enterprise Servers User Authentication Administration Guide ClearPath OS 2200 Release 15.0 February 2014 7850 4586 008 NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product

More information

SAS 9.4 Logging. Configuration and Programming Reference Second Edition. SAS Documentation

SAS 9.4 Logging. Configuration and Programming Reference Second Edition. SAS Documentation SAS 9.4 Logging Configuration and Programming Reference Second Edition SAS Documentation The correct bibliographic citation for this manual is as follows: SAS Institute Inc. 2014. SAS 9.4 Logging: Configuration

More information

OPERATING SYSTEM SERVICES

OPERATING SYSTEM SERVICES OPERATING SYSTEM SERVICES USER INTERFACE Command line interface(cli):uses text commands and a method for entering them Batch interface(bi):commands and directives to control those commands are entered

More information

MACHINE ARCHITECTURE & LANGUAGE

MACHINE ARCHITECTURE & LANGUAGE in the name of God the compassionate, the merciful notes on MACHINE ARCHITECTURE & LANGUAGE compiled by Jumong Chap. 9 Microprocessor Fundamentals A system designer should consider a microprocessor-based

More information

Overview. CISC Developments. RISC Designs. CISC Designs. VAX: Addressing Modes. Digital VAX

Overview. CISC Developments. RISC Designs. CISC Designs. VAX: Addressing Modes. Digital VAX Overview CISC Developments Over Twenty Years Classic CISC design: Digital VAX VAXÕs RISC successor: PRISM/Alpha IntelÕs ubiquitous 80x86 architecture Ð 8086 through the Pentium Pro (P6) RJS 2/3/97 Philosophy

More information

IBM. REXX/400 Programmer s Guide. AS/400 Advanced Series. Version 4 SC41-5728-00

IBM. REXX/400 Programmer s Guide. AS/400 Advanced Series. Version 4 SC41-5728-00 AS/400 Advanced Series IBM REXX/400 Programmer s Guide Version 4 SC41-5728-00 AS/400 Advanced Series IBM REXX/400 Programmer s Guide Version 4 SC41-5728-00 Take Note! Before using this information and

More information

Adapting the PowerPC 403 ROM Monitor Software for a 512Kb Flash Device

Adapting the PowerPC 403 ROM Monitor Software for a 512Kb Flash Device Adapting the PowerPC 403 ROM Monitor Software for a 512Kb Flash Device IBM Microelectronics Dept D95/Bldg 060 3039 Cornwallis Road Research Triangle Park, NC 27709 Version: 1 December 15, 1997 Abstract

More information

1 Description of The Simpletron

1 Description of The Simpletron Simulating The Simpletron Computer 50 points 1 Description of The Simpletron In this assignment you will write a program to simulate a fictional computer that we will call the Simpletron. As its name implies

More information

TMS320C3x/C4x Assembly Language Tools User s Guide

TMS320C3x/C4x Assembly Language Tools User s Guide TMS320C3x/C4x Assembly Language Tools User s Guide Literature Number: SPRU035D June 1998 Printed on Recycled Paper IMPORTANT NOTICE Texas Instruments and its subsidiaries (TI) reserve the right to make

More information

POLYCENTER Software Installation Utility Developer s Guide

POLYCENTER Software Installation Utility Developer s Guide POLYCENTER Software Installation Utility Developer s Guide Order Number: AA Q28MD TK April 2001 This guide describes how to package software products using the POLYCENTER Software Installation utility.

More information

MetroPro Remote Access OMP-0476F. Zygo Corporation Laurel Brook Road P.O. Box 448 Middlefield, Connecticut 06455

MetroPro Remote Access OMP-0476F. Zygo Corporation Laurel Brook Road P.O. Box 448 Middlefield, Connecticut 06455 MetroPro Remote Access OMP-0476F Zygo Corporation Laurel Brook Road P.O. Box 448 Middlefield, Connecticut 06455 Telephone: (860) 347-8506 E-mail: inquire@zygo.com Website: www.zygo.com ZYGO CUSTOMER SUPPORT

More information

#820 Computer Programming 1A

#820 Computer Programming 1A Computer Programming I Levels: 10-12 Units of Credit: 1.0 CIP Code: 11.0201 Core Code: 35-02-00-00-030 Prerequisites: Secondary Math I, Keyboarding Proficiency, Computer Literacy requirement Semester 1

More information

Infor LN User Guide for Setting Up a Company

Infor LN User Guide for Setting Up a Company Infor LN User Guide for Setting Up a Company Copyright 2015 Infor Important Notices The material contained in this publication (including any supplementary information) constitutes and contains confidential

More information

System Monitoring and Diagnostics Guide for Siebel Business Applications. Version 7.8 April 2005

System Monitoring and Diagnostics Guide for Siebel Business Applications. Version 7.8 April 2005 System Monitoring and Diagnostics Guide for Siebel Business Applications April 2005 Siebel Systems, Inc., 2207 Bridgepointe Parkway, San Mateo, CA 94404 Copyright 2005 Siebel Systems, Inc. All rights reserved.

More information