System Files:QFILEIML - Revision history

Friedkiwi: Restore Module headers section lost to a section-index shift; reorder; fold in V7R2 second-sample findings

2026-08-08T18:49:12Z

Restore Module headers section lost to a section-index shift; reorder; fold in V7R2 second-sample findings

Friedkiwi: Update tooling and open questions from the V7R2 sample; add release-comparison section (via update-page on MediaWiki MCP Server)

2026-08-08T18:47:07Z

Update tooling and open questions from the V7R2 sample; add release-comparison section (via update-page on MediaWiki MCP Server)

@@ Line 194: / Line 194: @@
 <blockquote>'''Caveat.''' The LID identifier at <code>+0x04</code> of a <code>PGPM</code> header frequently disagrees with the container LID that the sequential payload layout assigns to that region. Most of these values are valid LID identifiers from the directory, and in one region a run of 21 consecutive modules is spaced exactly by the directory lengths of the LIDs they name. Either the layout is displaced there, or modules are stored under a delivery LID distinct from their own. Findings about module ''contents'' are unaffected, since they come from the headers themselves — but do not quote a byte offset against a specific LID until this is resolved.</blockquote>
-=== What is not in the file ===
+== Tooling ==
-Notably, the service processor's own '''supervisor is absent'''. All 632 payloads were searched for <code>rfi</code> (<code>0x4C000064</code>), which any PowerPC exception-returning kernel must contain, and for exception vector tables at the architectural <code>0x100</code>, <code>0x200</code> and subsequent offsets of every 4&thinsp;KiB boundary. Exactly one payload contains a single <code>rfi</code> in 289&thinsp;KiB, which is a data coincidence, and no payload has a vector table.
+No IBM-supplied tool for reading this file outside the machine is known. A parser must, at minimum:
-Consistent with that, LID <code>80900702</code> begins mid-function, with a function ''tail'' rather than an entry point, and manipulates no privileged state anywhere: no <code>mtmsr</code>, no segment or TLB or cache operations, and only LR, CTR and XER touched. It does contain 31 <code>sc</code> supervisor calls.
+Step 2 is the one that catches people. An implementation that hardcodes the V4R4 directory offset of <code>0x420</code> does not fail loudly on a V7R2 container — it reports zero records and a nonsensical payload start. Deriving the offsets costs nothing and works on both.
-The conclusion is that the service processor runs a resident supervisor of its own, held in flash on the card, and that this file supplies only loadable task modules that sit on top of it. That is consistent with the hardware — the operator panel carries its own flash, and SLIC has an explicit message for instructing the service processor to IPL itself.
+== Across releases ==
 === Directory extents ===

Friedkiwi: Replace the file-size payload-start rule with one derivable from the directory alone (via update-page on MediaWiki MCP Server)

2026-08-08T18:46:48Z

Replace the file-size payload-start rule with one derivable from the directory alone (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 20:46, 8 August 2026
Line 94:		Line 94:
	<blockquote>'''Note!''' This is the single point on which it is easiest to go wrong, and doing so silently produces plausible-looking nonsense.</blockquote>		<blockquote>'''Note!''' This is the single point on which it is easiest to go wrong, and doing so silently produces plausible-looking nonsense.</blockquote>

	The <code>offset</code> field in each record is '''not''' an offset into ~~<code>QFILEIML</code>~~. It is a load-source LBA, describing where the payload sits on the installation medium, and it has no useful meaning inside the ~~container~~ file.		The <code>offset</code> field in each record is '''not''' an offset into the container. It is a load-source LBA, describing where the payload sits on the installation medium, and it has no useful meaning inside the file.

	Reading it as a file offset is superficially attractive and definitively wrong. Doing so on ~~this~~ image yields 608 overlapping extents out of 632, a maximum extent of 34,550 blocks against a 158,765-block file, and a minimum offset of block 3, which lands inside the header. That the lengths happen to sum to approximately the file size is a coincidence and should not be taken as confirmation.		Reading it as a file offset is superficially attractive and definitively wrong. Doing so on a V4R4 image yields 608 overlapping extents out of 632, a maximum extent of 34,550 blocks against a 158,765-block file, and a minimum offset of block 3, which lands inside the header. That the lengths happen to sum to approximately the file size is a coincidence and should not be taken as confirmation.

	The actual rule is simpler: '''payloads are stored sequentially, in directory order, immediately after the directory''', each one <code>length</code> blocks long. There are no gaps and no padding between them.		The actual rule is simpler: '''payloads are stored sequentially, in directory order, immediately after the directory''', each one <code>length</code> blocks long. There are no gaps and no padding between them.

	~~This~~ is ~~exact rather than approximate~~. ~~The lengths sum to 158~~,~~723 blocks against~~ a ~~158~~,~~765-block~~ file, ~~placing~~ the ~~start~~ of ~~data at block 42 — that~~ is, ~~<code>0x5400</code>, immediately past~~ the ~~directory terminator — and~~ the ~~payloads then tile~~ to the ~~final~~ byte of the ~~file with nothing left over~~.		'''Payloads begin at the next 512-byte block boundary after the directory terminator.''' That is block 42 for the V4R4 sample and block 69 for the V7R2 one. This rule needs only the directory, so it also works on a container embedded in a larger image — an install ISO, for instance — where the file size is not a meaningful quantity.

			An older formulation, ''file size in blocks minus the sum of all lengths'', gives the same answer for a standalone file and is a useful cross-check: on the V4R4 sample the two agree exactly, and the implied container size matches the real file size to the byte at 81,287,680. But it cannot be used on an embedded container, so prefer the terminator rule.

	To locate a payload, therefore, walk the directory from the beginning and accumulate lengths; do not index by the offset field.		To locate a payload, therefore, walk the directory from the beginning and accumulate lengths; do not index by the offset field.

Friedkiwi: Generalise the file layout from a second (V7R2) sample: the header carries its own offsets (via update-page on MediaWiki MCP Server)

2026-08-08T18:46:37Z

Generalise the file layout from a second (V7R2) sample: the header carries its own offsets (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 20:46, 8 August 2026
Line 8:		Line 8:

	== File layout ==		== File layout ==
			The layout is '''not at fixed offsets'''. It is carried in the header, and it differs between releases — a decoder that assumes the V4R4 offsets will read a V7R2 container as having no entries at all, without reporting an error.

			The field at <code>+0x08</code>, low 24 bits, is the offset to the Licensed Internal Code banner. The directory header sits at exactly '''twice''' that offset, its records <code>0x20</code> further on, and the build label at header <code>+0x10</code>.

			{\|class="wikitable"
			!Release
			!<code>+0x08</code>
			!Banner
			!Directory header
			!Records
			!Build label
			\|-
			\|V4R4
			\|<code>ff000200</code>
			\|<code>0x200</code>
			\|<code>0x400</code>
			\|<code>0x420</code>
			\|<code>v4r4m01204.0.03</code>
			\|-
			\|V7R2
			\|<code>ff000800</code>
			\|<code>0x800</code>
			\|<code>0x1000</code>
			\|<code>0x1020</code>
			\|<code>v7r2m00000.0.00</code>
			\|}

			So the general layout is:

	{\|class="wikitable"		{\|class="wikitable"
	!Offset		!Offset
Line 13:		Line 42:
	\|-		\|-
	\|<code>0x000</code>		\|<code>0x000</code>
	\|Magic <code>C9 D4 C4 F1</code>, which is <code>IMD1</code> in EBCDIC~~, followed by a short and largely unexplored header~~		\|Magic <code>C9 D4 C4 F1</code>, which is <code>IMD1</code> in EBCDIC
	\|-		\|-
	\|<code>~~0x200~~</code>		\|<code>0x008</code>
			\|Low 24 bits: offset to the banner. The rest of the header is not understood
			\|-
			\|''banner''
	\|Licensed Internal Code banner in EBCDIC, carrying the LIC product identifiers		\|Licensed Internal Code banner in EBCDIC, carrying the LIC product identifiers
	\|-		\|-
	\|~~<code>0x400</code>~~		\|''banner'' × 2
	\|Directory header: a four-byte preamble, the literal string <code>Directory.</code>, two zero bytes, then a 16-byte build label		\|Directory header: a four-byte preamble, the literal string <code>Directory.</code>, two zero bytes, then a 16-byte build label
	\|-		\|-
	\|<code>~~0x420~~</code>		\|''banner'' × 2 + <code>0x20</code>
	\|The directory: a run of 32-byte LID records		\|The directory: a run of 32-byte LID records
	\|-		\|-
	\|''varies''		\|''varies''
	\|Terminator record, identifier <code>0xC5D5C440</code> (<code>END </code> in EBCDIC)		\|Terminator record, identifier <code>0xC5D5C440</code> (<code>END </code> in EBCDIC)
	\|-
	~~\|<code>0x5400</code>~~
	~~\|Payload area~~
	\|}		\|}

	The first sixteen bytes of ~~the file~~ are:		The first sixteen bytes of a V4R4 container are:

	<pre>		<pre>
Line 37:		Line 66:
	</pre>		</pre>

	~~The banner at~~ <~~code~~>~~0x200~~</~~code~~> reads, in EBCDIC:		and of a V7R2 one:

			<pre>
			00000000: c9d4 c4f1 0000 0000 ff00 0800 0010 0000
			</pre>

			The banner reads, in EBCDIC:

	<pre>		<pre>
Line 44:		Line 79:
	</pre>		</pre>

	The ~~three~~ seven-digit numbers are LIC product identifiers, and the same ~~three~~ appear in <code>QFILEMCD</code>. The build label ~~at <code>0x410</code>~~ is ~~<code>v4r4m01204.0.03</code>,~~ likewise identical between the two files, which is a convenient way to confirm that a given <code>QFILEIML</code> and <code>QFILEMCD</code> ~~came off~~ the ~~same media~~.		The seven-digit numbers are LIC product identifiers, and the same ones appear in <code>QFILEMCD</code>. The build label is likewise identical between the two container files from the same media, which is a convenient way to confirm that a given <code>QFILEIML</code> and <code>QFILEMCD</code> belong together.

			The field at <code>+0x0C</code> differs between the two samples (<code>00e00000</code> against <code>00100000</code>) and is not understood. Two samples are not enough to fit it.

	== The directory ==		== The directory ==

Friedkiwi: Strengthen the no-supervisor section with the independent link-table evidence (via update-page on MediaWiki MCP Server)

2026-08-08T17:37:59Z

Strengthen the no-supervisor section with the independent link-table evidence (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 19:37, 8 August 2026
Line 97:		Line 97:
	About 30 payloads carry an <code>AJS</code> build identifier and are service-processor code, ranging from a few tens of kilobytes to a few hundred. A further handful carry <code>AJG</code> identifiers and are I/O offload (MFIOP) code instead; several of those carry an <code>ATM</code> marker, i.e. ATM networking, which is not something a service processor does. The two families are ''mostly'' disjoint but not perfectly: at least one payload contains both identifiers.		About 30 payloads carry an <code>AJS</code> build identifier and are service-processor code, ranging from a few tens of kilobytes to a few hundred. A further handful carry <code>AJG</code> identifiers and are I/O offload (MFIOP) code instead; several of those carry an <code>ATM</code> marker, i.e. ATM networking, which is not something a service processor does. The two families are ''mostly'' disjoint but not perfectly: at least one payload contains both identifiers.

	===~~= Module headers =~~===		=== What is not in the file ===
	~~Each of these images~~ is ~~not a monolithic firmware blob but a collection~~ of '''~~linkable modules~~''', ~~each introduced by~~ a ~~header~~ with ~~the EBCDIC eyecatcher~~ '''<code>~~PGPM~~</code>''' (<code>~~D7 C7 D7 D4~~</code>~~). There~~ are ~~119 such headers in~~ the ~~container~~. ~~The useful fields~~ are:		Notably, the service processor's own '''supervisor is absent'''. Two independent lines of evidence agree on this.

			'''From the instruction stream.''' All payloads were searched for <code>rfi</code> (<code>0x4C000064</code>), which any PowerPC exception-returning kernel must contain, and for exception vector tables at the architectural <code>0x100</code>, <code>0x200</code> and subsequent offsets of every 4 KiB boundary. Across 4.1 MB of service-processor code there is not one <code>rfi</code>, and no payload has a vector table. Privileged operations are almost as scarce: six instructions of the <code>mtmsr</code> family and four cache or TLB operations in the whole set.

			Consistent with that, LID <code>80900702</code> begins mid-function, with a function ''tail'' rather than an entry point, and manipulates no privileged state at all — only LR, CTR and XER are touched. It does contain 31 <code>sc</code> supervisor calls.

			'''From the link tables.''' As described above, the numbered module names are imported by many modules and defined by none. The code that provides them is therefore not on this medium.

			The conclusion is that the service processor runs a resident supervisor of its own, held in flash on the card, and that this file supplies only loadable task modules that sit on top of it. That is consistent with the hardware — the operator panel carries its own flash, and SLIC has an explicit message for instructing the service processor to IPL itself.

			==== The supervisor call interface ====
			Since the supervisor itself is absent, the <code>sc</code> instructions are the entire visible boundary between these modules and the firmware they run on. Across the family there are 668 supervisor calls using just 9 distinct call numbers, with the number in <code>r0</code> and arguments from <code>r3</code>:

	{\|class="wikitable"		{\|class="wikitable"
	!~~Offset~~		!Call
	!~~Contents~~		!Count
			!Observed arguments
	\|-		\|-
	\|<code>~~+0x00~~</code>		\|<code>0x020C</code>
	\|~~<code>PGPM</code> eyecatcher~~		\|262
			\|—
	\|-		\|-
	\|<code>~~+0x04~~</code>		\|<code>0x0208</code>
	\|~~A LID identifier — but see the caveat below~~		\|131
			\|<code>r3 = 0x16</code> in every instance
	\|-		\|-
	\|<code>~~+0x24~~</code>		\|<code>0x03A4</code>
	\|~~EBCDIC version string~~, ~~e.g.~~ <code>~~0100~~</code>		\|106
			\|<code>r3 = 0x64</code>, <code>r4 = 5</code>; unique to one module
	\|-		\|-
	\|<code>~~+0x30~~</code>		\|<code>0x0358</code>
	\|~~8-byte build identifier, e.g. <code>AJSFGVB3</code>~~		\|
	\|-		\|<code>r3</code> is one of exactly three values: <code>0x83010000</code>, <code>0x83020000</code>, <code>0x83030000</code>
	\|<code>~~+0x54~~</code>
	~~\|8-byte name~~ of ~~the module this header '''defines'''~~
	\|-
	\|<code>~~+0x60~~</code>
	~~\|Slot table~~, ~~4-byte values~~
	\|-
	\|<code>~~+0xC0~~</code>
	~~\|Import table: 12-byte entries, each an 8-byte name and a 4-byte linkage slot~~, ~~terminated by eight EBCDIC~~ <code>F</code> ~~characters~~
	\|}		\|}

	<~~blockquote~~>'''~~Note!~~''' ~~Strings such as~~ <code>~~SP MOPT1~~</code>, <code>~~SP SPCI3~~</code> or <code>~~SP WT~~</code> ~~are~~ '''~~module names~~ in ~~a link table'''~~, ~~not feature or capability tags~~. An earlier version of this article described them as component tags whose differing sets indicated capability tiers across the hardware range. That reading was wrong: the sets differ because different modules import different things.</blockquote>		The first two are the interesting pair: <code>0x0208</code> occurs exactly half as often as <code>0x020C</code>, and always on the same resource number, which is the signature of an acquire/release pair around a critical section. The <code>0x0358</code> window is the only region passed explicitly to a supervisor call, which is what registering or mapping a device or shared-memory window looks like.

			Beyond that the call numbers cannot be decoded, because the code that implements them is not on this medium.

			==== A caution about what this firmware does ====
			It is tempting to assume this firmware covers the obvious service-processor duties — power control, thermal and fan management, SPCN, driving the panel and its LCD, VPD storage, error logging and SRC posting. '''No such claim is supported by this file.'''

			These modules contain almost no descriptive text. The complete inventory of readable strings is the Licensed Internal Code banner, the copyright boilerplate, the EBCDIC-to-ASCII translation tables, and the <code>PGPM</code> link names. A search for the entire relevant vocabulary — <code>POWER</code>, <code>FAN</code>, <code>THERMAL</code>, <code>SPCN</code>, <code>VPD</code>, <code>PASSWORD</code>, <code>SECUR</code>, <code>SERIAL</code> and more, in both EBCDIC and ASCII, over every byte — returns nothing in any service-processor module. The same vocabulary ''is'' present elsewhere in the container, but only inside SLIC payloads.

	~~Worked example, from~~ the ~~header at <code>+0x59C</code>~~ of LID <code>A07008C2</code>: build <code>AJSFGVB3</code>, defines <code>SP SB</code>, and imports <code>SP SPCI1</code> through <code>SP SPCI5</code> and <code>CUANSI</code>, with the import table running to its terminator at <code>+0x1B4</code>.		So the honest position is that the functional surface visible here is nine supervisor call numbers into firmware nobody has. What the service processor actually does is implemented on the other side of that boundary.

	~~Both families share a common utility layer, which is why their vocabulary overlaps~~: ~~<code>CUANSI</code>, <code>CUCONV</code>, <code>CUIO</code>, <code>CUMEMORY</~~code>, ~~<code>CUMISC</code>~~ and ~~<code>CUSTO</code>~~, ~~plus <code>SRASCOMN</code> for RAS common code~~.		One bound on that negative: readable code averages about 46 % of 1 KiB blocks across these images, and one 119 KiB payload is entirely opaque. The supported statement is that nothing is visible in the readable portion, not that nothing exists.

	==== Reading the dependency graph ====		==== Reading the dependency graph ====

Friedkiwi: Correct the SP firmware section: SP xxx are link-table module names, not component tags; fix family counts (via update-page on MediaWiki MCP Server)

2026-08-08T17:37:37Z

Correct the SP firmware section: SP xxx are link-table module names, not component tags; fix family counts (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 19:37, 8 August 2026
Line 91:		Line 91:

	=== Service processor firmware ===		=== Service processor firmware ===
	LID <code>80900702</code> is service processor Licensed Internal Code: 128 KiB, stored uncompressed, staged at SLS <code>FFFFFFFF9A 001000</code>. Its EBCDIC strings include a ''9400 Licensed Internal Code'' banner, a 1998 copyright, and a table of component tags of the form <code>SP MOPT1</code>, <code>SP SPCI1</code>, <code>SP SBL</code>, <code>SP SM</code> and so on, alongside build identifiers such as <code>AJSFGWC3</code> and <code>AJSRWP32</code>. Its code is unambiguously 32-bit.		LID <code>80900702</code> is service processor Licensed Internal Code: 128 KiB, stored uncompressed, staged at SLS <code>FFFFFFFF9A 001000</code>. Its EBCDIC strings include a ''9400 Licensed Internal Code'' banner and a 1998 copyright, and its code is unambiguously 32-bit.

	This confirms a long-standing claim in the trade press that AS/400 service processor firmware is loaded from the load source rather than residing wholly in flash on the card.		This confirms a long-standing claim in the trade press that AS/400 service processor firmware is loaded from the load source rather than residing wholly in flash on the card. As the rest of this section shows, that turns out to be only half true.

	~~The picture is more subtle than "the service processor firmware is in this file", however. Scanning all 632~~ payloads ~~for the LIC banner, a~~ <code>~~SP ~~</code> ~~component tag table~~ and ~~a 32~~-~~bit-only instruction profile finds roughly 19 such images~~, ranging from ~~34 KiB~~ to ~~395&thinsp~~;~~KiB~~, ~~with differing component-tag sets —~~ which is ~~what one would expect of capability tiers across~~ a ~~hardware range where the~~ service processor ~~is entirely invisible to the user~~.		About 30 payloads carry an <code>AJS</code> build identifier and are service-processor code, ranging from a few tens of kilobytes to a few hundred. A further handful carry <code>AJG</code> identifiers and are I/O offload (MFIOP) code instead; several of those carry an <code>ATM</code> marker, i.e. ATM networking, which is not something a service processor does. The two families are ''mostly'' disjoint but not perfectly: at least one payload contains both identifiers.

	~~Those~~ images ~~separate cleanly into two families~~ by ~~their build identifier prefix, and no image carries both prefixes~~:		==== Module headers ====
			Each of these images is not a monolithic firmware blob but a collection of '''linkable modules''', each introduced by a header with the EBCDIC eyecatcher '''<code>PGPM</code>''' (<code>D7 C7 D7 D4</code>). There are 119 such headers in the container. The useful fields are:

	{\|class="wikitable"		{\|class="wikitable"
	!~~Family~~		!Offset
	!~~Count~~		!Contents
	~~!Build ID prefix~~
	~~!Distinguishing markers~~
	\|-		\|-
	~~\|Service processor~~		\|<code>+0x00</code>
	~~\|16~~		\|<code>PGPM</code> eyecatcher
	\|<code>~~AJS…~~</code>
	\|~~8 to 24~~ <code>~~SP ~~</code> ~~component tags per image~~
	\|-		\|-
	\|I/~~O offload (MFIOP)~~		\|<code>+0x04</code>
	\|6		\|A LID identifier — but see the caveat below
	\|<code>~~AJG…~~</code>		\|-
	\|No <code>~~SP ~~</code> ~~tags at all; several carry an~~ <code>~~ATM~~</code> ~~marker~~, i.e. ~~ATM networking~~ code		\|<code>+0x24</code>
			\|EBCDIC version string, e.g. <code>0100</code>
			\|-
			\|<code>+0x30</code>
			\|8-byte build identifier, e.g. <code>AJSFGVB3</code>
			\|-
			\|<code>+0x54</code>
			\|8-byte name of the module this header '''defines'''
			\|-
			\|<code>+0x60</code>
			\|Slot table, 4-byte values
			\|-
			\|<code>+0xC0</code>
			\|Import table: 12-byte entries, each an 8-byte name and a 4-byte linkage slot, terminated by eight EBCDIC <code>F</code> characters
	\|}		\|}

	Both families share a common ~~runtime library — tags~~ <code>CUANSI</code>, <code>CUCONV</code>, <code>CUIO</code>, <code>CUMEMORY</code>, <code>CUMISC</code>, <code>CUSTO</code>, plus <code>SRASCOMN</code> for RAS common code — which is ~~why~~ their ~~vocabulary overlaps~~ and ~~why~~ the ~~build-ID prefix~~, ~~rather than~~ the ~~string content~~, is ~~the reliable discriminator~~.		<blockquote>'''Note!''' Strings such as <code>SP MOPT1</code>, <code>SP SPCI3</code> or <code>SP WT</code> are '''module names in a link table''', not feature or capability tags. An earlier version of this article described them as component tags whose differing sets indicated capability tiers across the hardware range. That reading was wrong: the sets differ because different modules import different things.</blockquote>

			Worked example, from the header at <code>+0x59C</code> of LID <code>A07008C2</code>: build <code>AJSFGVB3</code>, defines <code>SP SB</code>, and imports <code>SP SPCI1</code> through <code>SP SPCI5</code> and <code>CUANSI</code>, with the import table running to its terminator at <code>+0x1B4</code>.

			Both families share a common utility layer, which is why their vocabulary overlaps: <code>CUANSI</code>, <code>CUCONV</code>, <code>CUIO</code>, <code>CUMEMORY</code>, <code>CUMISC</code> and <code>CUSTO</code>, plus <code>SRASCOMN</code> for RAS common code.

			==== Reading the dependency graph ====
			Because every module declares what it defines and what it imports, the link tables can simply be read off as a dependency graph — which is more informative than any amount of disassembly, and is the main reason the <code>PGPM</code> header is worth knowing about.

			Doing so reveals a clean pattern. The '''numbered''' names — <code>SP SPCI1</code> to <code>SPCI5</code>, <code>SP MOPT1</code> to <code>MOPT9</code>, <code>SP MOPD1</code> — are imported by many modules and '''defined by none'''. The '''lettered''' members of the same families — <code>MOPTA</code>, <code>MOPTB</code>, <code>MOPTC</code>, <code>MOPD2</code> — each import their immediate predecessor and are present as real modules.

			The natural reading is that numbered names are resident firmware on the card and lettered ones are downloadable extensions layered on top. Which is exactly what the next section establishes by a completely independent route.

			<blockquote>'''Caveat.''' The LID identifier at <code>+0x04</code> of a <code>PGPM</code> header frequently disagrees with the container LID that the sequential payload layout assigns to that region. Most of these values are valid LID identifiers from the directory, and in one region a run of 21 consecutive modules is spaced exactly by the directory lengths of the LIDs they name. Either the layout is displaced there, or modules are stored under a delivery LID distinct from their own. Findings about module ''contents'' are unaffected, since they come from the headers themselves — but do not quote a byte offset against a specific LID until this is resolved.</blockquote>

	=== What is not in the file ===		=== What is not in the file ===

Friedkiwi: Document the QFILEIML / IMD1 container: layout, directory, payload addressing, contents (via create-page on MediaWiki MCP Server)

2026-08-08T16:57:53Z

Document the QFILEIML / IMD1 container: layout, directory, payload addressing, contents (via create-page on MediaWiki MCP Server)

New page

'''<code>QFILEIML</code>''' is one of the two large container files found on AS/400 SAVSYS and Licensed Internal Code installation media. It holds the machine's ''loadable'' microcode: IOP and adapter firmware, service processor firmware, and a quantity of SLIC modules. Its internal format is identified by the four-byte magic '''<code>IMD1</code>''' and is a container of [[Data Structures:LID|LIDs]].

The companion file <code>QFILEMCD</code> holds SLIC proper, via a directory called <code>COPYDIR</code>. Both files use the same 32-byte [[Data Structures:LID|LID directory record]], and a record present in both is byte-for-byte identical, so the two are two views of one packaging scheme rather than two unrelated formats.

The name is not documented by IBM as far as is known here. <code>IML</code> almost certainly stands for ''Initial Microprogram Load'' — the phase in which the machine's microcode is brought up, before OS/400 itself exists — which matches the file's contents. Treat the expansion as an inference.

Everything below was determined by inspection of a V4R4 image and should be read as applying to that release. The figures quoted are from a single <code>QFILEIML</code> of 81,287,680 bytes (77.5 MiB), build label <code>v4r4m01204.0.03</code>.

== File layout ==
{|class="wikitable"
!Offset
!Contents
|-
|<code>0x000</code>
|Magic <code>C9 D4 C4 F1</code>, which is <code>IMD1</code> in EBCDIC, followed by a short and largely unexplored header
|-
|<code>0x200</code>
|Licensed Internal Code banner in EBCDIC, carrying the LIC product identifiers
|-
|<code>0x400</code>
|Directory header: a four-byte preamble, the literal string <code>Directory.</code>, two zero bytes, then a 16-byte build label
|-
|<code>0x420</code>
|The directory: a run of 32-byte LID records
|-
|''varies''
|Terminator record, identifier <code>0xC5D5C440</code> (<code>END </code> in EBCDIC)
|-
|<code>0x5400</code>
|Payload area
|}

The first sixteen bytes of the file are:

<pre>
00000000: c9d4 c4f1 0000 0000 ff00 0200 00e0 0000
</pre>

The banner at <code>0x200</code> reads, in EBCDIC:

<pre>
LICENSED INTERNAL CODE - PROPERTY OF IBM 5763999, 5716999, 5769999
(C) COPYRIGHT IBM CORP. 1980, 1998. ALL RIGHTS RESERVED. ...
</pre>

The three seven-digit numbers are LIC product identifiers, and the same three appear in <code>QFILEMCD</code>. The build label at <code>0x410</code> is <code>v4r4m01204.0.03</code>, likewise identical between the two files, which is a convenient way to confirm that a given <code>QFILEIML</code> and <code>QFILEMCD</code> came off the same media.

== The directory ==
The directory begins at <code>0x420</code> and runs, in this image, for 632 records before the <code>END </code> terminator at <code>0x5320</code>. The record layout is documented at [[Data Structures:LID]] and is not repeated here.

Of the 632 records:
* 341 carry the compressed flag.
* 631 name an SLS staging address in the <code>FFFFFFFFxx</code> band. Exactly one does not: LID <code>80900818</code> stages at <code>000000024A 000000</code>.
* 7 have payloads that are themselves runs of LID records — see ''Directory extents'' below.

== Payload addressing ==
<blockquote>'''Note!''' This is the single point on which it is easiest to go wrong, and doing so silently produces plausible-looking nonsense.</blockquote>

The <code>offset</code> field in each record is '''not''' an offset into <code>QFILEIML</code>. It is a load-source LBA, describing where the payload sits on the installation medium, and it has no useful meaning inside the container file.

Reading it as a file offset is superficially attractive and definitively wrong. Doing so on this image yields 608 overlapping extents out of 632, a maximum extent of 34,550 blocks against a 158,765-block file, and a minimum offset of block 3, which lands inside the header. That the lengths happen to sum to approximately the file size is a coincidence and should not be taken as confirmation.

The actual rule is simpler: '''payloads are stored sequentially, in directory order, immediately after the directory''', each one <code>length</code> blocks long. There are no gaps and no padding between them.

This is exact rather than approximate. The lengths sum to 158,723 blocks against a 158,765-block file, placing the start of data at block 42 — that is, <code>0x5400</code>, immediately past the directory terminator — and the payloads then tile to the final byte of the file with nothing left over.

To locate a payload, therefore, walk the directory from the beginning and accumulate lengths; do not index by the offset field.

== Contents ==
Laid out correctly, the payloads fall into two clear populations, distinguishable without decompression by looking for 32-bit <code>stwu r1,-x(r1)</code> prologues versus 64-bit <code>std</code> stores:

{|class="wikitable"
!Population
!Count
!Identification
|-
|32-bit PowerPC
|75
|<code>stwu</code> prologues present, no <code>std</code> at all
|-
|64-bit PowerPC AS (SLIC)
|210
|<code>std</code> present, no <code>stwu</code> at all
|-
|Neither
|347
|Compressed payloads, data, tables, and directory extents
|}

The split is clean — no payload shows both — which is what makes the heuristic trustworthy. The 32-bit population is the interesting one: the main processor of these machines is 64-bit PowerPC AS, so 32-bit code in this file is by definition destined for something else. That is the IOP, adapter and service processor microcode.

=== Service processor firmware ===
LID <code>80900702</code> is service processor Licensed Internal Code: 128 KiB, stored uncompressed, staged at SLS <code>FFFFFFFF9A 001000</code>. Its EBCDIC strings include a ''9400 Licensed Internal Code'' banner, a 1998 copyright, and a table of component tags of the form <code>SP MOPT1</code>, <code>SP SPCI1</code>, <code>SP SBL</code>, <code>SP SM</code> and so on, alongside build identifiers such as <code>AJSFGWC3</code> and <code>AJSRWP32</code>. Its code is unambiguously 32-bit.

This confirms a long-standing claim in the trade press that AS/400 service processor firmware is loaded from the load source rather than residing wholly in flash on the card.

The picture is more subtle than "the service processor firmware is in this file", however. Scanning all 632 payloads for the LIC banner, a <code>SP </code> component tag table and a 32-bit-only instruction profile finds roughly 19 such images, ranging from 34 KiB to 395 KiB, with differing component-tag sets — which is what one would expect of capability tiers across a hardware range where the service processor is entirely invisible to the user.

Those images separate cleanly into two families by their build identifier prefix, and no image carries both prefixes:

{|class="wikitable"
!Family
!Count
!Build ID prefix
!Distinguishing markers
|-
|Service processor
|16
|<code>AJS…</code>
|8 to 24 <code>SP </code> component tags per image
|-
|I/O offload (MFIOP)
|6
|<code>AJG…</code>
|No <code>SP </code> tags at all; several carry an <code>ATM</code> marker, i.e. ATM networking code
|}

Both families share a common runtime library — tags <code>CUANSI</code>, <code>CUCONV</code>, <code>CUIO</code>, <code>CUMEMORY</code>, <code>CUMISC</code>, <code>CUSTO</code>, plus <code>SRASCOMN</code> for RAS common code — which is why their vocabulary overlaps and why the build-ID prefix, rather than the string content, is the reliable discriminator.

=== What is not in the file ===
Notably, the service processor's own '''supervisor is absent'''. All 632 payloads were searched for <code>rfi</code> (<code>0x4C000064</code>), which any PowerPC exception-returning kernel must contain, and for exception vector tables at the architectural <code>0x100</code>, <code>0x200</code> and subsequent offsets of every 4 KiB boundary. Exactly one payload contains a single <code>rfi</code> in 289 KiB, which is a data coincidence, and no payload has a vector table.

Consistent with that, LID <code>80900702</code> begins mid-function, with a function ''tail'' rather than an entry point, and manipulates no privileged state anywhere: no <code>mtmsr</code>, no segment or TLB or cache operations, and only LR, CTR and XER touched. It does contain 31 <code>sc</code> supervisor calls.

The conclusion is that the service processor runs a resident supervisor of its own, held in flash on the card, and that this file supplies only loadable task modules that sit on top of it. That is consistent with the hardware — the operator panel carries its own flash, and SLIC has an explicit message for instructing the service processor to IPL itself.

=== Directory extents ===
Seven payloads are not data but further runs of 32-byte LID records, largely duplicating entries from the root directory byte for byte. The two largest hold 294 and 133 records. They appear to be indexes rather than nested containers, and a tool walking this file should recognise them so as not to mistake an index for a firmware image. A payload whose first few records parse as plausible LID records, with identifiers matching known LIDs, is an extent.

== Compression ==
341 of the 632 payloads are flagged compressed. The codec is the LZW variant used throughout SLIC and is described at [[Data Structures:LID#The compressed flag]]. It has not been needed to read the service processor firmware, which is stored plain, but it stands between the reader and roughly half the file.

== Tooling ==
No IBM-supplied tool for reading this file outside the machine is known. A parser must, at minimum:
# check the <code>IMD1</code> magic at offset 0;
# read 32-byte records from <code>0x420</code> until an identifier of <code>0xC5D5C440</code> or zero;
# compute the payload start as ''file size in blocks minus the sum of all lengths'', rather than trusting the offset field;
# lay payloads out sequentially in directory order.

Step 3 is what makes extraction correct, and it is worth asserting: if the computed start is not 42 on a V4R4 image, something has been misread.

== Open questions ==
* The meaning of the header bytes at <code>0x004</code>–<code>0x1FF</code>, and of the four-byte preamble before <code>Directory.</code>.
* The meaning of most LID identifier families.
* Why 31 payloads carry the compressed flag yet begin with plainly readable 32-bit code.
* Whether the load-source LBAs in the offset field can be used to reconstruct the physical layout of the original installation medium.
* Classification of the remaining 32-bit payloads: several are adapter microcode, but others may be operator panel or SPCN code.

== See also ==
* [[Data Structures:LID]]
* [[CISC AS/400 LIC Tapes]]
* [[Copying disks with Linux]]

== Weblinks ==
* [https://www.mcpressonline.com/ MC Press Online], which carries older documentation describing service processor microcode as being loaded from the load source

== Footnotes ==
<references />

[[Category: System Internals]]