OS/360 Object File Format

The OS/360 Object File Format is the standard object module file format for the IBM DOS/360, OS/360 and VM/370, Univac VS/9, and Fujitsu BS2000 mainframe operating systems. In the 1990s, the format was given an extension with the XSD-type record for the MVS Operating System to support longer module names in the C Programming Language. This format is still in use by the z/VSE operating system. In contrast, it has been superseded by the GOFF file format on the MVS Operating System and on the z/VM Operating System. Since the MVS and z/VM loaders will still handle this older format, some compilers have chosen to continue to produce this format instead of the newer GOFF format.

Use

This format provides for the description of a compiled application's object code, which can be fed to a linkage editor to be made into an executable program, or run directly through an object module loader. It is created by the Assembler or by a programming language compiler. For the rest of this article, unless a reason for being explicit in the difference between a language compiler and an assembler is required, the term "compile" includes "assemble" and "compiler" includes "assembler."

Weaknesses

This format was considered adequate for the time it was originally developed, around 1964. Over time, it had a number of weaknesses, among which is that

it supports only 8-byte long names.
alignment cannot be specified.
a module that is pure data and is not executable cannot be specified.
a reentrant module cannot be specified.
cannot distinguish between a subroutine vs. a function.
a module designed so that it is movable cannot be specified.
address constants can't be identified as pointers as opposed to, say, access to a table or to a virtual method in a dynamic record.
attributes cannot be assigned to external references.
no means to allow procedures or functions to check or validate argument types or validate external structures.
no means to declare an object, where part of the structure is data and part is code.
the SYM symbolic table is limited in the information it can provide.

These and other weaknesses caused this format to be superseded by the GOFF module file format. But, it was a good choice as it was satisfactory for the needs of programming languages being used at the time, it did work and was simple to implement, simple to use and for simple programs, can still be adequate. Also, the format is still satisfactory to continue to be used for older programs that either were never changed, or where the source code is unavailable and the object files are the only part of the program remaining.
Note that the GOFF file format merely superseded this format, the format is still valid, may still continue to be used, and was not deprecated. This format has the advantage that it is easy and simple to create, and a compiler for a language that can live with its restrictions, which are maximum 8-character upper-case only module names, applications no larger than 2^24 in size for code and data, means that any programming language that can write 80-byte fixed-format binary files, can be used to create a compiler for this object format. In fact, the Australian Atomic Energy Commission's Pascal 8000 Compiler for the IBM 360/370, itself written in Pascal as a self-hosting compiler back in 1978–1980, directly created its own object files without using the Assembler as an intermediate step.

Record Types

There are 6 different record types:

ESD records define main programs, subroutines, functions, dummy sections, Fortran Common, and any module or routine that can be called by another module. They are used to define the program or program segments that were compiled in this execution of the compiler, and external routines used by the program in C, CALL EXIT in Fortran; new and dispose in Pascal). ESD records should occur before any reference to an ESD symbol.
TXT records contain the machine instructions or data which is held by the module.
RLD records are used to relocate addresses. For example, a program referencing an address located 500 bytes inside the module, will internally store the address as 500, but when the module is loaded into memory it's bound to be located someplace else, so an RLD record informs the linkage editor or loader what addresses to change. Also, when a module references an external symbol, it will usually set the value of the symbol to zero, then include an RLD entry for that symbol to allow the loader or linkage editor to alter the address to the correct value.
SYM records were added to allow for providing additional information about a symbol, such as the type of data and the size of the item.
XSD records were added to provide additional information beyond that provided in the ESD record about public symbols such as procedures and functions, and to expand the size of a procedure or function name to more than 8 characters.
END records indicate the end of a module, and optionally where the program is to begin execution.

Format

All records are exactly 80 bytes long; unused fields should be blank-filled. The first byte of every record is always the binary value 02. The next 3 bytes are always the record type. Character values are in EBCDIC. The remainder of each record's fields are dependent on the record type. By convention, if the module was named in the TITLE statement of an assembly language program, its name appears left-justified in positions 73–80 of each record; if the name is shorter than 8 characters or no name was given, a sequence number appears for the remainder of each record. In actual practice, the sequence number field may be blank or contain anything the language translator wants to put there, and is essentially a comment field.
The assembler,, would create an ESD record for each subroutine, function, or program, and for Common Blocks in the case of Fortran programs. Additional ESD entries in ESD records would be created for ENTRY statements, for additional subroutines, functions or Fortran named or blank COMMON blocks included as part of a compiled or assembled modules, and for names of external subroutines and functions called by a module.
Note that there are two kinds of public symbol types, ESDID entries and LDID entries. ESDID entries are CSECTS and DSECTS and LDID entries are ENTRY statements. The ESDID numbering space is separate from the LDID numbering space, and thus two different named symbols, one an ESDID and one an LDID can both have the binary value of 0001.
The program's executable object code and data would be stored in TXT records. Calls to other subroutines, functions or COMMON blocks are resolved through RLD records, which modify the address as stored in a TXT record to determine the complete address of the subroutine or function. Optionally, a language can provide symbolic reference information such as object names and data type information or debugging symbols through SYM records, and then the END statement indicates the end of an Object module file and the optional start address for the subroutine, function or program that this file should be started at, if the starting address for the routine is not the first byte of the first routine As has been reported, some people discovered because of the way older assemblers worked, a program compiled faster if you put data "above" a program before the code for the program, once the assembler started to notice instructions, it was much slower, so, programmers would write routines where they put the data and constants first, then included code for the program. When assembling a program could take 30 minutes to an hour instead of a few seconds as now, this was a big difference.
Note that while not required, it is a convention that module and symbolic names are in all upper case, that the first character of a name field is a letter or the symbols @,# or $, and that subsequent characters of a name consist of those characters plus the character digits 0 through 9, although older software may or may not correctly process object module files which used lower-case identifiers. Most programming languages other than Assembly cannot call modules that have names containing @ or #, so most programs, subroutines, or functions were written to use only a letter for the first character, and if the name was longer than 1 character, to use only letters and digits for the 2nd through 8th character. While most non-assembler languages can't handle $ in the name, an exception is Fortran which can recognize subroutine names with $ in them. Also, modules written to be used as subroutines typically restricted themselves to 6 characters or less as versions of Fortran before about 1978 also can't use subroutines or modules using more than 6 characters in length. The COBOL compiler typically discards the dash character if it appears in a program's PROGRAM-ID or a CALL statement to an external module.
In the 1990s, a new record type, the XSD record was added to extend the use of this object module format to encompass longer module names than 8 characters and to permit mixed-case names, as required by the C programming language.