GOFF

From Just Solve the File Format Problem
(Difference between revisions)
Jump to: navigation, search
(Created page with "{{FormatInfo |formattype=electronic |subcat=Executables |released=~1995 }} ''GOFF'' (Generalized Object File Format) is the current executable format for the IBM mainframe ope...")
 
 
Line 5: Line 5:
 
}}
 
}}
 
''GOFF'' (Generalized Object File Format) is the current executable format for the IBM mainframe operating systems z/OS and z/VM. It supersedes the original [[OS/360 Object File Format]], although the later is still supported.
 
''GOFF'' (Generalized Object File Format) is the current executable format for the IBM mainframe operating systems z/OS and z/VM. It supersedes the original [[OS/360 Object File Format]], although the later is still supported.
 +
 +
On z/OS, GOFF exists in two subtypes:
 +
* '''load module''': this is code which can be dynamically loaded into memory – similar in concept to a DLL or shared library on other operating systems. GOFF is the successor to XOBJ, the earlier object format for load modules, which in turn was successor to OBJ
 +
* '''program object''': this is an executable format
 +
 +
=== Program Objects ===
 +
 +
Note the "program object" format has never been fully and officially documented outside of IBM confidential materials (possibly available under NDA, but certainly not to the general public). That said, significant chunks of it are composed out of data structures which are documented in public z/OS manuals. The biggest missing component is the initial "IEWPLMH" header. However, several of those non-public bits have been revealed in an open source project, an incomplete port of GNU binutils/GDB to z/OS:
 +
 +
There is an [https://github.com/ambitus/binutils incomplete port of GNU binutils to z/OS]. The most important files are [https://github.com/ambitus/binutils/blob/program-object/bfd/po64-s390.c po64-s390.c] and [https://github.com/ambitus/binutils/blob/program-object/include/po/external.h po/external.h]
 +
 +
The file starts with an 8-byte EBCDIC header ("eyecatcher" in IBM-speak) which is "IEWPLMH" followed by a single EBCDIC space. In hex that is c9c5e6d7d3d4c840.
 +
 +
z/OS has two main filesystems: the traditional "dataset" filesystem, and a POSIX filesystem (originally HFS, more recently replaced by zFS; also supporting network file systems such as NFS and previously others such as DCE DFS). The traditional filesystem is based on very different concepts from POSIX; instead of files, it has "datasets", which have explicit record structure (such as fixed vs variable). One type of dataset is known as a "partitioned dataset" (PDS), later also PDSE (Partitioned Data Set Extended), which is like a ZIP file. Anyway, traditional z/OS load modules could not be stored directly in the POSIX filesystem, only in partitioned datasets; you could archive the partitioned dataset into a POSIX file (using utilities such as IEBCOPY and XMIT), but z/OS could not actually use it until it was turned back into a partitioned dataset. By contrast, z/OS Program Objects can be stored in a Unix file directly, as well as in partitioned datasets (which have to be the new PDSE format)
  
 
== Links ==
 
== Links ==

Latest revision as of 02:02, 3 March 2024

File Format
Name GOFF
Ontology
Released ~1995

GOFF (Generalized Object File Format) is the current executable format for the IBM mainframe operating systems z/OS and z/VM. It supersedes the original OS/360 Object File Format, although the later is still supported.

On z/OS, GOFF exists in two subtypes:

  • load module: this is code which can be dynamically loaded into memory – similar in concept to a DLL or shared library on other operating systems. GOFF is the successor to XOBJ, the earlier object format for load modules, which in turn was successor to OBJ
  • program object: this is an executable format

[edit] Program Objects

Note the "program object" format has never been fully and officially documented outside of IBM confidential materials (possibly available under NDA, but certainly not to the general public). That said, significant chunks of it are composed out of data structures which are documented in public z/OS manuals. The biggest missing component is the initial "IEWPLMH" header. However, several of those non-public bits have been revealed in an open source project, an incomplete port of GNU binutils/GDB to z/OS:

There is an incomplete port of GNU binutils to z/OS. The most important files are po64-s390.c and po/external.h

The file starts with an 8-byte EBCDIC header ("eyecatcher" in IBM-speak) which is "IEWPLMH" followed by a single EBCDIC space. In hex that is c9c5e6d7d3d4c840.

z/OS has two main filesystems: the traditional "dataset" filesystem, and a POSIX filesystem (originally HFS, more recently replaced by zFS; also supporting network file systems such as NFS and previously others such as DCE DFS). The traditional filesystem is based on very different concepts from POSIX; instead of files, it has "datasets", which have explicit record structure (such as fixed vs variable). One type of dataset is known as a "partitioned dataset" (PDS), later also PDSE (Partitioned Data Set Extended), which is like a ZIP file. Anyway, traditional z/OS load modules could not be stored directly in the POSIX filesystem, only in partitioned datasets; you could archive the partitioned dataset into a POSIX file (using utilities such as IEBCOPY and XMIT), but z/OS could not actually use it until it was turned back into a partitioned dataset. By contrast, z/OS Program Objects can be stored in a Unix file directly, as well as in partitioned datasets (which have to be the new PDSE format)

[edit] Links

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox