IBM BOOK format

From Try-AS/400
Revision as of 02:56, 27 August 2023 by PoC (talk | contribs) (+link, +info from that link)
Jump to navigation Jump to search
Qsicon Fixme.png This article isn't finished yet or needs to be revised. Please keep in mind that thus it may be incomplete.

Reason: Rework, add information

IBM BookManager Softcopy is IBM's legacy online documentation system, created in the 1980s. It was historically used mostly on mainframes, midrange (AS/400) and OS/2, although it also saw some use in other areas including AIX.

IBM no longer uses it for new documentations of its products, but there is an immense quantity of legacy electronic documentation from the period when IBM actively used it (from the 1980s thru 2010s), particularly documentation CD-ROMs/DVD-ROMs and images thereof.

The file-internal format apparently is called IBMIDDOC.

The standard DOS style extension is BOO, and "application/book" is sometimes used as MIME type, but was never officially registered.

Internal structure

The header of BOO files commonly contains an EBCDIC copyright notice (this is true even for books for ASCII-based platforms such as OS/2). The file contents is almost certainly also in EBCDIC, but is not readable beyond the header. Most likely this due to compression with an unknown algorithms (a relative of IBM's well-known proprietary algorithms such as TERSE?). However, the data seems too repetitive to be compressed–possibly it is just some obfuscation mechanism then?

  • Bytes 1-2: unknown 2 bytes probably flags. second byte never zero, first byte often is (but not always). probably not a size, since 0001 is a common value.
  • Bytes 3-6: these 4 bytes appear to always be zero
  • Bytes 7: unknown, can be zero, probably more flags???

Bytes 8+: EBCDIC copyright string. Can start with one or more EBCDIC spaces (0x40), sometimes also (0xB4) (some kind of control character?)

The header is 256 bytes long. The copyright string is padded to the end of the header with 0x40 (EBCDIC space). However, it seems to have a null terminator (0x00) at the end of the actual text, before the space padding.

What follows from 256 bytes onwards looks like it could be some kind of compression dictionary. Not clear.

It looks like the file is composed of 256 byte records (so file size should be an integer multiple of 256), often with some all-zeros records appended to the end.

There is weak evidence that the file format might be record oriented with 4096 byte records: IBM upload instructions into MVS datasets hint towards that. All known files so far have a file size which can be divided by 4096 without remainder. If the file size doesn't match, it's padded with binary zeros.

See also

Weblinks

Footnotes