Data Structures:LID

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.

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

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

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 IMD1 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.

Worked example

The first record of the IMD1 directory in a V4R4 QFILEIML, at file offset 0x420:

00000420: 8070 0830 0000 0210 0000 0004 0000 0000
00000430: ffff ffff 9300 1000 0000 1757 1997 0318

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

That same record appears byte for byte as the sixth LID of QFILEMCD's nested COPYDIR 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 FFFFFFFF93, offset 0x001000. This is the same notation the DST Display/Alter storage panel accepts.

The FFFFFFFFxx 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 FFFFFFFFxx 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 QFILEIML the most populous families are:

Family	Records	Observed contents
a170	144	Not established
a0b0	66	Not established
a100	56	Not established
8190	54	Not established
a0c0	37	Not established
8390	36	Not established
a090	33	Largely 32-bit PowerPC firmware images
8590	30	Largely 32-bit PowerPC firmware images
8090	29	Mixed; includes the service processor firmware and the two large SLIC LIDs

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

The compressed flag

Bit 0x80000000 marks a payload as compressed. The codec is the LZW variant implemented in SLIC by the routines LZdcomp and cpdcomp, which supports 9-, 10- and 12-bit codes and dispatches on a leading format byte of 0x11 or 0x21. It is not any of the OS/400 *LOW, *MEDIUM or *HIGH 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 QFILEIML, 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

• COPYDIR, the directory in QFILEMCD, carries SLIC itself as a nested LID directory.
• IMD1, the format of System Files:QFILEIML, carries IOP, adapter and service processor microcode alongside SLIC modules.
• SLIC contains an interactive LID filesystem. The commands IdeLidFileSystem, IdeCopyLidCmd, IdeFindLidCmd, IdeVerifyLid, IdeCompressLidCmd, IdeDecompressLidCmd, IdeLidListCmd and IdeMakeTempLidCmd 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 downLoadLid 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.

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