Friedkiwi: Document the LID (Load ID) container record format shared by COPYDIR and IMD1 (via create-page on MediaWiki MCP Server)

2026-08-08T16:57:06Z

Document the LID (Load ID) container record format shared by COPYDIR and IMD1 (via create-page on MediaWiki MCP Server)

New page

A '''LID''' (''Load ID'') is IBM's general-purpose container for shipping a blob of code or data to a machine. It is not specific to any one file, release, or processor architecture: the same 32-byte directory record describes SLIC modules, IOP and adapter microcode, and service processor firmware, and the same idea survives into modern POWER hardware.

Because the record format is shared between several container files, it is documented here once rather than repeated in each. The container that uses it is described in [[System Files:QFILEIML]].

== The directory record ==
A LID container consists of a header, a directory of fixed 32-byte records, and the payloads. Every record has the following layout. All fields are big endian.

{|class="wikitable"
!Offset
!Size
!Field
!Notes
|-
|<code>+0x00</code>
|4
|LID identifier
|Not a sequence number. The high halfword is a ''family'' — see below.
|-
|<code>+0x04</code>
|4
|Offset
|In 512-byte blocks. '''Base and meaning depend on the container''' — see the warning below.
|-
|<code>+0x08</code>
|4
|Length
|In 512-byte blocks.
|-
|<code>+0x0C</code>
|4
|Flags
|<code>0x80000000</code> = compressed. No other bit has been observed set.
|-
|<code>+0x10</code>
|8
|SLS address
|Where the payload is to be staged in single-level store.
|-
|<code>+0x18</code>
|4
|Time
|Packed BCD <code>HHMM</code>; read the field as hexadecimal to display it. <code>0x00001757</code> is 17:57.
|-
|<code>+0x1C</code>
|4
|Date
|Packed BCD <code>YYYYMMDD</code>, likewise. <code>0x19970318</code> is 1997-03-18.
|}

The directory is terminated by a record whose identifier field is <code>0xC5D5C440</code>, which is the EBCDIC string <code>END </code>. A zero identifier also terminates.

<blockquote>'''Note!''' The '''offset''' field is the field most likely to mislead. It is ''not'' universally a byte or block offset into the container file. In the <code>IMD1</code> container it is a load-source LBA — an address on the installation medium — and is meaningless as a file offset; payloads there are instead laid out sequentially in directory order. See [[System Files:QFILEIML]] for the worked case. Always establish the addressing base for a given container before extracting anything.</blockquote>

=== Worked example ===
The first record of the <code>IMD1</code> directory in a V4R4 <code>QFILEIML</code>, at file offset <code>0x420</code>:

<pre>
00000420: 8070 0830 0000 0210 0000 0004 0000 0000
00000430: ffff ffff 9300 1000 0000 1757 1997 0318
</pre>

decodes as LID <code>80700830</code>, offset block 528, length 4 blocks (2 KiB), flags 0 (not compressed), SLS address <code>FFFFFFFF93 001000</code>, timestamp 1997-03-18 17:57.

That same record appears byte for byte as the sixth LID of <code>QFILEMCD</code>'s nested <code>COPYDIR</code> LID directory, which is what establishes that the two containers share one record format.

== The SLS address field ==
The 8-byte address is a single-level store address, split 40/24 into a segment identifier and a byte offset within the segment, so segments are 16 MiB. Printed with that split, the example above is segment <code>FFFFFFFF93</code>, offset <code>0x001000</code>. This is the same notation the DST ''Display/Alter storage'' panel accepts.

The <code>FFFFFFFFxx</code> band is resident Licensed Internal Code. Note that a segment identifier recorded in a directory is the ''load source'' segment — where the payload was saved from, or is staged into — which is not necessarily the segment the code eventually executes in. Payloads destined for an IOP or the service processor are staged into a SLIC segment first and then transferred over the bus to the target card, so an <code>FFFFFFFFxx</code> address does '''not''' imply the payload is SLIC code.

== LID identifier families ==
The identifier is structured rather than sequential: the high halfword groups LIDs into families, and members of a family share a purpose. In a V4R4 <code>QFILEIML</code> the most populous families are:

{|class="wikitable"
!Family
!Records
!Observed contents
|-
|<code>a170</code>
|144
|Not established
|-
|<code>a0b0</code>
|66
|Not established
|-
|<code>a100</code>
|56
|Not established
|-
|<code>8190</code>
|54
|Not established
|-
|<code>a0c0</code>
|37
|Not established
|-
|<code>8390</code>
|36
|Not established
|-
|<code>a090</code>
|33
|Largely 32-bit PowerPC firmware images
|-
|<code>8590</code>
|30
|Largely 32-bit PowerPC firmware images
|-
|<code>8090</code>
|29
|Mixed; includes the service processor firmware and the two large SLIC LIDs
|}

The purpose of most families has not been established. The <code>80xxxxxx</code> range is the only one <code>QFILEMCD</code> uses.

== The compressed flag ==
Bit <code>0x80000000</code> marks a payload as compressed. The codec is the LZW variant implemented in SLIC by the routines <code>LZdcomp</code> and <code>cpdcomp</code>, which supports 9-, 10- and 12-bit codes and dispatches on a leading format byte of <code>0x11</code> or <code>0x21</code>. It is '''not''' any of the OS/400 <code>*LOW</code>, <code>*MEDIUM</code> or <code>*HIGH</code> save-file compression methods, nor zlib or raw deflate; all of those have been tried against real payloads and fail immediately.

The flag should be treated as advisory rather than exact. In one V4R4 <code>QFILEIML</code>, 31 payloads carry the compressed flag yet begin with clean, plainly readable 32-bit PowerPC function prologues. Whatever the flag governs, it is not a simple "this entire payload is one compressed stream".

== Containers and consumers ==
* '''<code>COPYDIR</code>''', the directory in <code>QFILEMCD</code>, carries SLIC itself as a nested LID directory.
* '''<code>IMD1</code>''', the format of [[System Files:QFILEIML]], carries IOP, adapter and service processor microcode alongside SLIC modules.
* SLIC contains an interactive '''LID filesystem'''. The commands <code>IdeLidFileSystem</code>, <code>IdeCopyLidCmd</code>, <code>IdeFindLidCmd</code>, <code>IdeVerifyLid</code>, <code>IdeCompressLidCmd</code>, <code>IdeDecompressLidCmd</code>, <code>IdeLidListCmd</code> and <code>IdeMakeTempLidCmd</code> all appear in a V4R4 name index, so a LID is a first-class object to the machine rather than merely an installation-media artefact.
* Adapter and IOP classes in SLIC expose a <code>downLoadLid</code> method, which is the mechanism by which a staged LID reaches the card.
* On modern POWER hardware the '''flexible service processor''' holds a filesystem of LIDs containing the hypervisor, the Open Firmware image used by AIX and Linux partitions, the component that replaces the physical front panel, and adapter firmware for several third-party network and storage cards.<ref>Reported by a machine owner familiar with FSP internals; not independently verified here, but consistent with IBM's evident reuse of the container across generations.</ref>

== Scope of this description ==
Everything above was read from a single V4R4 installation image and cross-checked between its two container files. Field offsets, sizes and the terminator are considered established. Family meanings, and the exact semantics of the compressed flag, are not.

== See also ==
* [[System Files:QFILEIML]]
* [[CISC AS/400 LIC Tapes]]

== Footnotes ==
<references />

[[Category: System Internals]]

Data Structures:LID - Revision history

Friedkiwi: Document the LID (Load ID) container record format shared by COPYDIR and IMD1 (via create-page on MediaWiki MCP Server)