Try-AS/400 - User contributions [en]

Reverse engineering SLIC

2026-08-13T20:34:31Z

Friedkiwi: Add a section on decoding conditional branches (BO/BI, and two disassembler rendering traps), and two traps: decode branches from the raw word, and a field the machine rebuilds at startup is an output (via update-page on MediaWiki MCP Server)

Reverse engineering '''SLIC''' — the Licensed Internal Code below the Machine Interface — is mostly a problem of turning addresses into names and getting bytes off the machine. This article collects the techniques that work, in the order you would actually use them, and the traps that cost the most time.

It assumes access to a machine's DST or SST service tools, and installation media or a SAVSYS for offline work.

== Start with the machine's own link map ==
Before writing any tooling, get the '''SLIC link map''' from the machine. It is reached through Display/Alter/Dump and can be printed to a spooled file, then exported.

The printed format is one row per module:

<pre>
NICKNAME ADDRESS(10+6) PART NAME VERSION RELEASE REL DATE/TIME INST DATE/TIME
###FLITE FFFFFFFFF4 C29820 SRVC_MACRO_FLIGHTLOG 0007 0400 20190217 094024 ...
</pre>

A V7R4 machine yields around 21,000 distinct modules. This single artefact answers "what is at this address" and "where is this module" authoritatively, for that machine, and it is the first thing to obtain.

Two properties make it more useful than it first appears:

* '''The spacing between consecutive entries equals the module's text length.''' Verified against the lengths ''Find LIC Module'' reports — exact matches. So the map gives extents as well as bases, which means any address can be resolved to a module ''and'' an offset within it.
* '''Module names are stable across PTFs; addresses are not.''' Look modules up by name whenever possible.

<blockquote>'''Note!''' Part names are upper-cased in the printout but the ''Find LIC Module by name'' panel is '''case-sensitive'''. <code>IoHriTaggedVpd</code> resolves; <code>IOHRITAGGEDVPD</code> does not. Take the spelling from the on-screen display, not the print.</blockquote>

== Getting bytes off the machine ==
Display/Alter/Dump can print a storage range to a spooled file. Exported as PDF and run through <code>pdftotext -layout</code>, each line is an address and 32 bytes:

<pre>
FFFFFFFFC5 943160 3C40CC4DFBC1FFF0 FBE1FFF87C0802A6 F8010028F821FF01 3C000010F8010008
</pre>

<blockquote>'''Note!''' The formatter '''collapses repeated lines''':
<pre>
127 LINES FFFFFFFF84 11B020 TO FFFFFFFF84 11BFE0 SAME AS ABOVE
</pre>
A naive parser silently sees a fraction of the data — in one case 44 % of a 1 MiB region — and reports no error. Any parser must expand these runs.</blockquote>

Dumping a whole module at once is usually better than dumping the function you think you want: module extents are known from the link map, and the surrounding code frequently answers the next question.

== Addresses ==
An SLS address is a '''40-bit segment identifier and a 24-bit offset''', which is exactly how the ''Specify Address'' panel splits it, so segments are 16 MiB.

'''Probe before dumping.''' Entering an address in an unmapped segment returns

<pre>
80 exception, segment does not exist.
</pre>

This is a free existence oracle. But probe the '''address you actually care about''', not offset zero of its segment — segments are sparsely populated, and offset 0 being unmapped says nothing about the rest. A segment can be mapped at <code>0x010000</code> and raise the exception at <code>0x120000</code>.

For a mapped address, the '''ADDRESSINFO''' Advanced Analysis command reports the page-directory entry and hardware page-table entries, confirming backing and page size.

=== Runtime and staged addresses differ ===
The same module may appear at one address in the link map and another as its runtime text. Where these differ, '''module-relative offsets are stable''': a symbol at <code>+0x26d0</code> in the staged image is at <code>+0x26d0</code> in the runtime image. Deriving runtime addresses this way works reliably; assuming a constant delta between two images does not.

== Names from the code ==
Two structures let a container image be turned into a link map offline.

* '''Traceback trailers.''' Every compilation unit ends with a <code>TBTB</code> eyecatcher (<code>E3C2E3C2</code>) followed by a pointer to a descriptor. A trailer covers a whole compilation unit, so it localises rather than pinpoints — and a forward scan for "the next trailer" will silently attribute a ''later'' function's name if the target has no trailer of its own.
* '''Link-loader descriptors.''' Richer: one per procedure, with the entry address at <code>+0x08</code> and the name at <code>+0x38</code>. Names beginning <code>#</code> are SLIC-internal modules; the rest are C++ mangled symbols.

<blockquote>'''Note!''' Two mistakes here are expensive. First, '''do not require the entry address to fall inside a segment the container carries''' — runtime-only segments exist, and filtering on containment silently drops every module in them. Second, the name is not always at a fixed offset from the descriptor; scanning for the longest identifier run within the descriptor is more robust than assuming one.</blockquote>

== Module metadata ==
''Find LIC Module'' reports, for any address: module name, nickname, compile and link/load timestamps, version and release level, '''PTF level''', and the text, data and BSS extents plus the TOC address.

The same record exists on media, anchored by the EBCDIC PTF-level string (<code>SYSBASE</code> for an unpatched module):

<pre>
+0x00 PTF level 7 bytes "SYSBASE"
+0x07 version 4 bytes "0007" = V7
+0x0B release/mod 4 bytes "0400" = R4M0
+0x0F nickname 8 bytes
+0x27 build id 7 bytes "AJDG301"
</pre>

These records cluster in their own segments rather than sitting beside the code they describe. A V7R4 SAVSYS yields about 34,000 of them.

The '''PTF level''' field is the useful one: it distinguishes base modules from patched ones without a changelog, which is exactly what you need when a running machine and its install media disagree on addresses.

<blockquote>'''Note!''' <code>SYSBASE</code> means "no PTF applied to this module" — '''not''' "identical to your install media". Two machines can both report <code>SYSBASE</code> and differ, because base levels themselves differ between RS releases. Compile and link dates make this checkable.</blockquote>

== Calls between modules ==
External calls do not go through a table you can read off.

A call is a two-instruction sequence — an ordinal loaded into <code>r11</code>, then a <code>bla</code> into the '''BLA vector''' at the top of the address space. IBM's own term, from the Static Directory, is ''Pageable BLA'' for the pageable half.

<pre>
V4R4 ori r11,r13,<ordinal> ; bla <vector>
V7R4 li r11,<ordinal> ; bla <vector>
</pre>

The stub reached by the <code>bla</code> computes the target arithmetically:

<pre>
rldicr r11,r11,sh,59 ; ordinal x 4 (V4R4) or x 16 (V7R4)
addis r11,r11,<simm>
mtctr r11
bctr
</pre>

so <code>callee = (sext16(simm) << 16) + (ordinal << sh)</code>. The <code>simm</code> values are not derivable and must be read from the vector — which is not carried in any container, so a dump is required once per build.

The stub array is findable '''structurally''' — runs of 16-byte blocks with three constant words and one varying — which locates it without knowing the shift. Searching for a specific opcode pattern from another release will not find it.

== Reading conditional branches ==

Every policy decision in SLIC is a conditional branch, and getting one backwards silently inverts whatever it decides — the listing looks the same either way. The encoding is ordinary PowerPC, but two things about it are easy to get wrong when reading a listing rather than writing an assembler.

'''<code>BO</code> selects the sense, <code>BI</code> selects the bit.''' <code>BO = 12</code> is branch-if-true and <code>BO = 4</code> is branch-if-false. <code>BI</code> numbers the condition register's bits end to end — <code>BI = 4 × field + bit</code> — and the four bits of a field are, in order, '''LT, GT, EQ, SO'''. So within <code>CR0</code>, <code>BI = 0</code> is LT, '''<code>BI = 1</code> is GT''' and <code>BI = 2</code> is EQ; within <code>CR1</code> the EQ bit is <code>BI = 6</code>.

That matters most after the idiom SLIC tests a policy bit with:

LWZ 4, 1148(16) ; a flag byte out of an object
RLDICL. 3, 4, 0, 63 ; r3 = byte & 0x01, and set CR0
BC 4, 1, ... ; BO=4 branch-if-false, BI=1 GT

<code>RLDICL.</code> leaves 0 or 1 and sets <code>CR0</code> by comparing it against zero, so GT is set exactly when the bit is on, and '''branch-if-not-GT is taken when the bit is CLEAR'''. Read <code>BI = 1</code> as EQ instead and the same branch appears to be taken when the bit is '''set''' — the exact opposite, with nothing in the listing to show which reading is in force.

A routine that uses two condition register fields settles the numbering without any external reference: a dispatch chain alternating <code>CMPI 0,…</code> / <code>BCLR 12,2</code> with <code>CMPI 1,…</code> / <code>BCLR 12,6</code> is comparing a value against a series of constants and returning on each match, which is only a dispatch if <code>BI</code> 2 and 6 are the EQ bits of <code>CR0</code> and <code>CR1</code>.

'''Two rendering traps make listings read backwards.''' Both apply to any disassembler that prints raw encoding fields instead of assembler syntax:

* '''The destination is not always the first operand.''' <code>ADDI</code>, <code>ADD</code> and <code>SUBF</code> print it first; the logical forms <code>ORI</code>, <code>AND</code> and <code>ANDC</code> print <code>rS</code> first and the destination <code>rA</code> '''second'''. A load/modify/store triple is the giveaway: <code>LBZ 27,28(28)</code> / <code>ORI 27,26,1</code> / <code>STB 26,28(28)</code> only makes sense as "load into r27, or in 1 giving r26, store r26". Read left to right, whole routines look like a run of dead stores.
* '''The <code>Rc</code> dot can go missing.''' <code>rlwinm.</code> and <code>rlwimi.</code> do set <code>CR0</code>, but a decoder that appends the dot only for primary opcode 31 prints them without it — and then the branch after them looks like it is testing a condition register nothing wrote. Check bit 31 of the raw word before concluding a test is stale.

== Traps worth knowing ==
* '''Never resolve a live pointer against a container image.''' A pointer read from a running machine names a runtime address; dereferencing it in a saved image lands on unrelated data and produces a plausible, wrong answer.
* '''Verify cross-image mappings by content, at the address you intend to use.''' A delta confirmed at one address does not hold across a segment.
* '''A positional coincidence looks exactly like a structural fact.''' Runs of plausible-looking pointers, matching offsets and familiar constants all occur by chance in images this size. Confirm with bytes.
* '''TOC contents are filled in at IPL.''' Container images hold unrelocated placeholders, so a TOC walk is only meaningful against live storage.
* '''Decode <code>BO</code> and <code>BI</code> from the raw word before believing a branch, and record the sense you decoded.''' A branch that decides a policy bit is worth the thirty seconds; getting it wrong produces working-looking code that does the opposite of what the machine does, and the mistake survives review because the reasoning around it was written to match. See [[#Reading conditional branches]].
* '''A field the machine rebuilds at startup is an output, not an input.''' Configuration areas on disk are often regenerated from the machine's live configuration during power-on, and the code that later reads one may also stamp it on the way past. Reading such a field back as though it decided something is the same tautology as a model agreeing with its only caller, moved from code into data — and it is unusually convincing, because the value really is there and really is self-consistent. Establish who last wrote a field before deciding what it means.

== See also ==
* [[System Files:QFILEMCD]]
* [[System Files:QFILEIML]]
* [[Data Structures:LID]]
* [[SRC]]

[[Category: System Internals]]

Reverse engineering SLIC

2026-08-09T13:29:48Z

Friedkiwi: Remove the instruction-decoding section (via update-page on MediaWiki MCP Server)

Reverse engineering SLIC

2026-08-09T13:27:03Z

Friedkiwi: Add "Reading the instructions": PowerPC AS instruction set, why stock disassemblers fail silently, the patched tools, and the opcode map (via update-page on MediaWiki MCP Server)

Reverse engineering '''SLIC''' — the Licensed Internal Code below the Machine Interface — is mostly a problem of turning addresses into names and getting bytes off the machine. This article collects the techniques that work, in the order you would actually use them, and the traps that cost the most time.

It assumes access to a machine's DST or SST service tools, and installation media or a SAVSYS for offline work.

== Start with the machine's own link map ==
Before writing any tooling, get the '''SLIC link map''' from the machine. It is reached through Display/Alter/Dump and can be printed to a spooled file, then exported.

The printed format is one row per module:

<pre>
NICKNAME ADDRESS(10+6) PART NAME VERSION RELEASE REL DATE/TIME INST DATE/TIME
###FLITE FFFFFFFFF4 C29820 SRVC_MACRO_FLIGHTLOG 0007 0400 20190217 094024 ...
</pre>

A V7R4 machine yields around 21,000 distinct modules. This single artefact answers "what is at this address" and "where is this module" authoritatively, for that machine, and it is the first thing to obtain.

Two properties make it more useful than it first appears:

* '''The spacing between consecutive entries equals the module's text length.''' Verified against the lengths ''Find LIC Module'' reports — exact matches. So the map gives extents as well as bases, which means any address can be resolved to a module ''and'' an offset within it.
* '''Module names are stable across PTFs; addresses are not.''' Look modules up by name whenever possible.

<blockquote>'''Note!''' Part names are upper-cased in the printout but the ''Find LIC Module by name'' panel is '''case-sensitive'''. <code>IoHriTaggedVpd</code> resolves; <code>IOHRITAGGEDVPD</code> does not. Take the spelling from the on-screen display, not the print.</blockquote>

== Getting bytes off the machine ==
Display/Alter/Dump can print a storage range to a spooled file. Exported as PDF and run through <code>pdftotext -layout</code>, each line is an address and 32 bytes:

<pre>
FFFFFFFFC5 943160 3C40CC4DFBC1FFF0 FBE1FFF87C0802A6 F8010028F821FF01 3C000010F8010008
</pre>

<blockquote>'''Note!''' The formatter '''collapses repeated lines''':
<pre>
127 LINES FFFFFFFF84 11B020 TO FFFFFFFF84 11BFE0 SAME AS ABOVE
</pre>
A naive parser silently sees a fraction of the data — in one case 44 % of a 1 MiB region — and reports no error. Any parser must expand these runs.</blockquote>

Dumping a whole module at once is usually better than dumping the function you think you want: module extents are known from the link map, and the surrounding code frequently answers the next question.

== Addresses ==
An SLS address is a '''40-bit segment identifier and a 24-bit offset''', which is exactly how the ''Specify Address'' panel splits it, so segments are 16 MiB.

'''Probe before dumping.''' Entering an address in an unmapped segment returns

<pre>
80 exception, segment does not exist.
</pre>

This is a free existence oracle. But probe the '''address you actually care about''', not offset zero of its segment — segments are sparsely populated, and offset 0 being unmapped says nothing about the rest. A segment can be mapped at <code>0x010000</code> and raise the exception at <code>0x120000</code>.

For a mapped address, the '''ADDRESSINFO''' Advanced Analysis command reports the page-directory entry and hardware page-table entries, confirming backing and page size.

=== Runtime and staged addresses differ ===
The same module may appear at one address in the link map and another as its runtime text. Where these differ, '''module-relative offsets are stable''': a symbol at <code>+0x26d0</code> in the staged image is at <code>+0x26d0</code> in the runtime image. Deriving runtime addresses this way works reliably; assuming a constant delta between two images does not.

== Names from the code ==
Two structures let a container image be turned into a link map offline.

* '''Traceback trailers.''' Every compilation unit ends with a <code>TBTB</code> eyecatcher (<code>E3C2E3C2</code>) followed by a pointer to a descriptor. A trailer covers a whole compilation unit, so it localises rather than pinpoints — and a forward scan for "the next trailer" will silently attribute a ''later'' function's name if the target has no trailer of its own.
* '''Link-loader descriptors.''' Richer: one per procedure, with the entry address at <code>+0x08</code> and the name at <code>+0x38</code>. Names beginning <code>#</code> are SLIC-internal modules; the rest are C++ mangled symbols.

<blockquote>'''Note!''' Two mistakes here are expensive. First, '''do not require the entry address to fall inside a segment the container carries''' — runtime-only segments exist, and filtering on containment silently drops every module in them. Second, the name is not always at a fixed offset from the descriptor; scanning for the longest identifier run within the descriptor is more robust than assuming one.</blockquote>

== Module metadata ==
''Find LIC Module'' reports, for any address: module name, nickname, compile and link/load timestamps, version and release level, '''PTF level''', and the text, data and BSS extents plus the TOC address.

The same record exists on media, anchored by the EBCDIC PTF-level string (<code>SYSBASE</code> for an unpatched module):

<pre>
+0x00 PTF level 7 bytes "SYSBASE"
+0x07 version 4 bytes "0007" = V7
+0x0B release/mod 4 bytes "0400" = R4M0
+0x0F nickname 8 bytes
+0x27 build id 7 bytes "AJDG301"
</pre>

These records cluster in their own segments rather than sitting beside the code they describe. A V7R4 SAVSYS yields about 34,000 of them.

The '''PTF level''' field is the useful one: it distinguishes base modules from patched ones without a changelog, which is exactly what you need when a running machine and its install media disagree on addresses.

<blockquote>'''Note!''' <code>SYSBASE</code> means "no PTF applied to this module" — '''not''' "identical to your install media". Two machines can both report <code>SYSBASE</code> and differ, because base levels themselves differ between RS releases. Compile and link dates make this checkable.</blockquote>

== Calls between modules ==
External calls do not go through a table you can read off.

A call is a two-instruction sequence — an ordinal loaded into <code>r11</code>, then a <code>bla</code> into the '''BLA vector''' at the top of the address space. IBM's own term, from the Static Directory, is ''Pageable BLA'' for the pageable half.

<pre>
V4R4 ori r11,r13,<ordinal> ; bla <vector>
V7R4 li r11,<ordinal> ; bla <vector>
</pre>

The stub reached by the <code>bla</code> computes the target arithmetically:

<pre>
rldicr r11,r11,sh,59 ; ordinal x 4 (V4R4) or x 16 (V7R4)
addis r11,r11,<simm>
mtctr r11
bctr
</pre>

so <code>callee = (sext16(simm) << 16) + (ordinal << sh)</code>. The <code>simm</code> values are not derivable and must be read from the vector — which is not carried in any container, so a dump is required once per build.

The stub array is findable '''structurally''' — runs of 16-byte blocks with three constant words and one varying — which locates it without knowing the shift. Searching for a specific opcode pattern from another release will not find it.

== Reading the instructions ==
SLIC is compiled for '''PowerPC AS''', IBM's variant of the architecture. It is the open PowerPC ISA plus a set of tagged-pointer and 16-byte-atomic instructions, and '''no stock disassembler knows them''':

{| class="wikitable"
! group !! mnemonics
|-
| 16-byte load/store || <code>stmd</code> <code>lmd</code> <code>lq</code> <code>stq</code>
|-
| tagged (space-descriptor) load/store || <code>lsdi</code> <code>lsdx</code> <code>stsdi</code> <code>stsdx</code>
|-
| tag and XER-tag manipulation || <code>settag</code> <code>txer</code> <code>cmpla</code> <code>mcrxrt</code> <code>ltptr</code> <code>dsixes</code>
|-
| conditional select || <code>selii</code> <code>selir</code> <code>selri</code> <code>selrr</code>
|-
| supervisor call || <code>scv</code>
|}

These are common — around 16 % of words in a typical object — and they appear early, so the failure is not a scattering of question marks.

<blockquote>'''Note!''' '''This fails silently, and it does not look like a decoding problem.''' In one sample object the first <code>stq</code> sits four bytes after a <code>settag</code>. The tool decodes the <code>settag</code>, cannot decode its fall-through, and ends the function there — reporting a clean 235-instruction function for a 9332-instruction program, with no error and no warning. The symptom presents as "the program is tiny". Any instruction count from a stock PowerPC disassembler on IBM i code is meaningless.</blockquote>

Two tools have been extended to cover this set:

* '''Ghidra''' with a <code>powerpcas.sinc</code> processor extension. This is the tool for ''reading'' code, because it decompiles. It still lacks <code>stq</code>, <code>lq</code> and <code>scv</code>, which is exactly the gap described above.
* '''capstone''', in the fork at <code>github.com/cyberdotgent/capstone</code>, branch <code>powerpc-as-support</code>. A pre-pass decoder covering all of the above, tried ahead of the generated tables so nothing that already decoded changes. Use it for sweeps, statistics and scripted scans.

Two build details cost time: the CMake option is <code>CAPSTONE_PPC_SUPPORT</code>, not <code>CAPSTONE_POWERPC_SUPPORT</code> — the wrong name builds cleanly and then fails at runtime with <code>CS_ERR_ARCH</code> — and the mode is <code>ppc64be</code>, since plain <code>ppc64</code> is little-endian and decodes every word as garbage rather than erroring.

<blockquote>'''Note!''' <code>cstool</code> '''stops at the first word it cannot decode'''. A batch sweep therefore silently reports only the prefix before the first AS instruction, which makes an unpatched tool look serviceable. Disassemble word-by-word, or resume past each stall.</blockquote>

=== The machine is the ground truth ===
Display/Alter/Dump of an MI program prints a <code>RISC INSTRUCTIONS</code> listing produced by SLIC itself, which knows the whole instruction set. When an offline tool disagrees with that listing, the tool is wrong. Two disagreements are '''not''' faults:

* '''Absolute branch targets.''' The machine prints the raw encoded field, offline tools sign-extend it: <code>4B800C43</code> is <code>BLA 0X3800C40</code> on the machine and <code>bla 0xffffffffff800c40</code> offline. The offline tools are right about the effective address — PowerPC sign-extends the <code>AA=1</code> displacement, which is precisely why the BLA vector lives at the top of the address space.
* '''Extended mnemonics.''' The machine prints raw forms where offline tools print the extended one: <code>ADDI 12,0,25</code> vs <code>li r12,0x19</code>, <code>BCCTR 20,0,0</code> vs <code>bctr</code>, <code>ORI 0,0,0</code> vs <code>nop</code>. Any automated comparison must normalise these or drown in false positives.

The opcode map, taken from the machine's own listing:

{| class="wikitable"
! mnemonic !! primary !! XO
|-
| <code>SELII</code> || 30 || 12
|-
| <code>SELIR</code> || 30 || 13 / 461
|-
| <code>SELRI</code> || 30 || 14 / 590
|-
| <code>SELRR</code> || 30 || 15 / 463
|-
| <code>CMPLA</code> || 31 || 64
|-
| <code>SETTAG</code> || 31 || 499
|-
| <code>MCRXRT</code> || 31 || 544
|-
| <code>TXER</code> || 31 || 612
|-
| <code>LQ</code> || 56 || 1, 2
|-
| <code>LMD</code> || 58 || 3
|-
| <code>STQ</code> || 62 || 2
|-
| <code>STMD</code> || 62 || 3
|-
| <code>SCV</code> || 17 || bit 30 clear, bit 31 set
|}

The <code>SEL*</code> family occupies primary 30, with the low XO bits selecting whether each of the two sources is a register or an immediate and the fourth operand naming an XER bit. Primary 56 is shared with the stock Power ISA <code>lq</code>, so an AS decoder must gate on the low two bits being non-zero or it will break ordinary code; note also that the machine's <code>LQ</code> takes a '''third operand''' (<code>LQ rt,d(ra),n</code>) and so is not simply Power ISA 2.07 <code>lq</code>.

== Traps worth knowing ==
* '''Never resolve a live pointer against a container image.''' A pointer read from a running machine names a runtime address; dereferencing it in a saved image lands on unrelated data and produces a plausible, wrong answer.
* '''Verify cross-image mappings by content, at the address you intend to use.''' A delta confirmed at one address does not hold across a segment.
* '''A positional coincidence looks exactly like a structural fact.''' Runs of plausible-looking pointers, matching offsets and familiar constants all occur by chance in images this size. Confirm with bytes.
* '''TOC contents are filled in at IPL.''' Container images hold unrelocated placeholders, so a TOC walk is only meaningful against live storage.

== See also ==
* [[System Files:QFILEMCD]]
* [[System Files:QFILEIML]]
* [[Data Structures:LID]]
* [[SRC]]

[[Category: System Internals]]

Reverse engineering SLIC

2026-08-09T13:06:12Z

Friedkiwi: Practical techniques for SLIC reverse engineering: link map, dumps, addressing, names, calls

File Formats:PGM

2026-08-09T11:54:41Z

Friedkiwi: Document the MI *PGM object: segments, SLS pointers, header chain, and where the instruction stream lives (via create-page on MediaWiki MCP Server)

A '''<code>*PGM</code>''' is a Machine Interface ''program object''. It is not a file with a text section and a symbol table. It is a set of single-level store '''segments''', chained together by 8-byte SLS pointers, with the executable instructions embedded in the first segment among the metadata that describes them.

This page describes enough of that structure to walk a program object offline — that is, without a console session and without printing a storage dump for every object of interest. The bytes can come from a [[File Formats:SAVF|save file]], which makes any distribution medium, PTF or backup a source of real program objects to examine.

Everything below is big endian, and text fields are EBCDIC.

== Addressing ==
Pointers are 8 bytes: a 40-bit segment identifier in the high bits and a 24-bit offset in the low bits, so a segment is 16 MiB. This is the same split used throughout the machine, including by the DST ''Display/Alter storage'' panel and by the SLS address field of a [[Data Structures:LID|LID]] directory record.

<pre>
segment = pointer >> 24
offset = pointer & 0xFFFFFF
</pre>

An all-zero pointer means the object has no data for that structure. That is precisely what the <code>###INFO: OBJECT DOES NOT CONTAIN DATA FOR THIS SECTION</code> line in a Display/Alter/Dump printout is reporting.

Some fields are not pointers but '''<code>SEGOFF</code>''' pairs: a 4-byte segment ''index'', counting from one into the object's own segment table, followed by a 4-byte offset. These appear where a genuine pointer would have to be relocated when the object moves.

The segments of one program have unrelated segment identifiers. A decoder therefore needs the whole set: a single segment cannot resolve its own pointers.

== Segments ==
A single-module bound program typically has four segments, distinguished by the type field in each segment's own header:

{|class="wikitable"
!Type
!Role
|-
|<code>0x0001</code>
|The program object proper: all headers, tables, and the instruction stream.
|-
|<code>0x0022</code>
|Module constants and the module string directory.
|-
|<code>0x0018</code>
|Static storage.
|-
|<code>0x0028</code>
|Trace-back and mapping data.
|}

Note that a program's segment table records a segment ''use'' code, while each segment's own header records a ''type''. They are different numberings and should not be conflated.

=== Segment header ===
Every MI segment opens with a header, called <code>YYSGHDR</code> in IBM's own dump formatting.

{|class="wikitable"
!Offset
!Size
!Field
|-
|<code>+0x00</code>
|2
|Segment type
|-
|<code>+0x02</code>
|2
|Size, in 512-byte units
|-
|<code>+0x04</code>
|1
|New flags
|-
|<code>+0x05</code>
|1
|Flags
|-
|<code>+0x08</code>
|8
|Address of the owning object
|-
|<code>+0x18</code>
|8
|Space address
|}

=== Object header ===
Immediately after it, at <code>+0x20</code> of the first segment, sits the object header, <code>YYEPAHDR</code>. Offsets below are relative to it.

{|class="wikitable"
!Offset
!Size
!Field
!Notes
|-
|<code>+0x02</code>
|1
|MI object type
|Together with the next byte, <code>0x0201</code> for a program.
|-
|<code>+0x03</code>
|1
|MI object subtype
|
|-
|<code>+0x04</code>
|30
|Object name
|EBCDIC.
|-
|<code>+0x24</code>
|4
|Space size
|
|-
|<code>+0x30</code>
|8
|Creation timestamp
|
|-
|<code>+0x38</code>
|8
|Owning user profile
|A pointer to the profile object.
|-
|<code>+0x48</code>
|8
|Context
|That is, the library.
|-
|<code>+0x50</code>
|8
|Object space
|'''The pointer to the program header.''' Everything else hangs off this.
|-
|<code>+0x5A</code>
|2
|ASP
|
|-
|<code>+0x60</code>
|8
|Last-modified timestamp
|
|}

The type and subtype pair uses the same code space as the item descriptors in a save file, so one table of MI type codes serves both.

== The program header ==
Found through the object header's object-space pointer; in practice it sits at offset <code>0x1000</code> of the first segment.

{|class="wikitable"
!Offset
!Size
!Field
|-
|<code>+0x00</code>
|8
|Program attributes
|-
|<code>+0x08</code>
|8
|Pointer to the version table
|-
|<code>+0x10</code>
|8
|Pointer to the segment table
|-
|<code>+0x18</code>
|8
|Pointer to the activation header
|-
|<code>+0x20</code>
|8
|Pointer to the signature table
|-
|<code>+0x28</code>
|8
|Pointer to the program string directory
|-
|<code>+0x30</code>
|8
|Pointer to activation group information
|-
|<code>+0x40</code>
|8
|Activation start
|-
|<code>+0x48</code>
|8
|Activation end
|-
|<code>+0x50</code>
|8
|'''Activation and PEP end''' — the last byte of the code
|-
|<code>+0x58</code>
|2
|Flags
|-
|<code>+0x5C</code>
|2
|Program state
|-
|<code>+0x90</code>
|1
|Program type
|-
|<code>+0x94</code>
|4
|Program entry procedure module number
|-
|<code>+0x9C</code>
|4
|Program entry procedure string ID
|-
|<code>+0xA0</code>
|2
|Minimum parameters
|-
|<code>+0xA2</code>
|2
|Maximum parameters
|-
|<code>+0xD0</code>
|8
|Pointer to the program header extension
|-
|<code>+0xD8</code>
|8
|Pointer to the trace-back locator
|-
|<code>+0xE0</code>
|8
|Pointer to the module table
|-
|<code>+0xE8</code>
|8
|Pointer to observability information
|-
|<code>+0xF0</code>
|8
|Pointer to the maintenance header
|}

The header extension adds a pointer to the GLU code list, <code>SEGOFF</code> pairs for the program history and the segment table extension, and a 16-byte hardware feature set at <code>+0x50</code>.

=== Version table ===
Forty bytes of packed version-release-modification halfwords, where <code>0x0740</code> reads as V7R4M0. Among them are the binder's internal and MI levels at <code>+0x02</code> and <code>+0x04</code>, the '''target''' release at <code>+0x06</code>, the '''created-on''' release at <code>+0x08</code>, the language release at <code>+0x10</code>, the CCSID at <code>+0x1E</code> and the low and high optimisation levels at <code>+0x20</code> and <code>+0x22</code>.

The target and created-on values here are what decide whether an object will restore onto a given release, so they are worth reading before attempting a restore that might fail.

=== Segment table ===
A header of allocated size, entry count and version, then the entries beginning at <code>+0x10</code>. '''Entries are a fixed 48 bytes'''; the size field is the allocation, not header plus count times entry, so deriving the stride from it gives the wrong answer.

Each entry holds the segment address at <code>+0x00</code>, a limbo address at <code>+0x08</code>, a declared page count at <code>+0x10</code>, and a one-byte ''segment use'' at <code>+0x12</code>: <code>0x01</code> static storage, <code>0x02</code> the program object, <code>0x04</code> constants, <code>0x06</code> trace-back.

A parallel ''segment table extension'', reached by a <code>SEGOFF</code> in the program header extension, records how much of each segment is actually used as opposed to allocated. Its entries begin at <code>+0x18</code> and are 24 bytes, of which the first four are the byte count.

=== Activation header ===
{|class="wikitable"
!Offset
!Size
!Field
|-
|<code>+0x00</code>
|8
|'''Program entry procedure entry point''' — the first instruction
|-
|<code>+0x08</code>
|4
|PBV size
|-
|<code>+0x10</code>
|8
|Pointer to the PBV relocation array
|-
|<code>+0x18</code>
|8
|Pointer to the static PBV array
|-
|<code>+0x20</code>
|4
|PBV relocation count
|-
|<code>+0x24</code>
|4
|Dependent service program count
|-
|<code>+0x28</code>
|8
|Pointer to the dependent service program array
|-
|<code>+0x4C</code>
|4
|Constant frame count
|-
|<code>+0x50</code>
|8
|Pointer to the constant frame definition array
|-
|<code>+0x58</code>
|8
|Pointer to the program export array
|-
|<code>+0x60</code>
|4
|Export count
|}

For a bound program with no exports most of these are zero. For a service program they are the published interface, and the dependent service program array is the object's dependency list — which makes it possible to work out what a program binds to without a machine to run <code>DSPPGM</code> on.

=== Maintenance header ===
Holds the copyright list size and count and a <code>SEGOFF</code> to the copyright text — a 4-byte length followed by EBCDIC — along with <code>SEGOFF</code> pairs for the external object list, static activation and export information, the last non-observable segment and size, and the lowest and highest PBV identifiers.

== Modules ==
The module table has the same shape as the segment table: header, then 48-byte entries from <code>+0x10</code>, each giving a pointer to a module header, a module domain and a module subtype.

A module header is a long run of pointers: to the program header it belongs to, the copyright table, the module version table, binding information, static information, the end-of-line table, observability information, the module string directory, the entry point table, the VLIC table, the procedure table, module constants, and the module header extension. It also carries the module type at <code>+0x01</code> — <code>0x01</code> for OPM and <code>0x03</code> for ILE — the module attributes at <code>+0xA8</code>, and the program entry procedure's dictionary ID, string ID, procedure number and parameter counts from <code>+0xAC</code> to <code>+0xBC</code>.

Two of its pointers characteristically leave the program segment: the module string directory and the module constants both live in the <code>0x0022</code> segment. When hunting for literal data referenced by the code — message identifiers, format names, table constants — that is the segment to search, and these two pointers give its exact extent.

=== Module version table ===
This is the most immediately informative structure in the whole object.

{|class="wikitable"
!Offset
!Size
!Field
|-
|<code>+0x02</code>
|2
|Language release
|-
|<code>+0x0A</code>
|2
|Instruction release
|-
|<code>+0x0C</code>
|2
|Target release
|-
|<code>+0x0E</code>
|2
|Created-on release
|-
|<code>+0x10</code>
|2
|Optimisation level
|-
|<code>+0x14</code>
|30
|Source module name
|-
|<code>+0x32</code>
|30
|Source module qualifier
|-
|<code>+0x50</code>
|20
|Compiler name
|-
|<code>+0x64</code>
|2
|Earliest compiler release
|}

Read the compiler name before spending any time on a disassembly. A module reporting <code>MX CONVERTED</code> was ''translated'' from an older object rather than compiled from source at this release, and the generated code will not resemble what a current compiler emits.

== The instruction stream ==
The code is a single contiguous run inside the first segment, bounded by two fields already listed above:

<pre>
start = activation header, program entry procedure entry point
end = program header, activation and PEP end (inclusive)
</pre>

It is 64-bit big-endian '''PowerPC AS'''. A stock disassembler invoked as <code>objdump -D -b binary -m powerpc:common64 -EB</code>, with the load address adjusted to the start offset, will produce a listing whose addresses line up with anything printed by Display/Alter/Dump.

Two caveats apply, and both matter.

PowerPC AS is not plain PowerPC. The tagged-pointer instructions and other AS-only operations have no encoding in a stock PowerPC disassembler and will appear as invalid, or worse, as an unrelated mnemonic that looks plausible. Treat such a listing as a starting point rather than as authority.

The run is also not pure code. Trace-back tables and constants are interleaved with instructions, so a linear sweep will decode data as code somewhere. For an object that still has its observability information, the trace-back locator and the module tables provide the boundaries needed to separate the two; for an object whose observability has been removed, they do not, and the separation has to be inferred from the code itself.

== Scope of this description ==
Field offsets were derived by lining a printed Display/Alter/Dump of a program object up against the same object's bytes extracted from a save file, and then checked by decoding the object independently and comparing every field against the printout. Structures that the dump prints but that were empty in the object used — the signature table, the export and import arrays, the service program tables and the secondary entry point table — are located by pointer but their contents are not described here; establishing those needs a service program to work from.

Only <code>*PGM</code> is covered. <code>*SRVPGM</code> and <code>*MODULE</code> share much of this layout but have additional tables of their own.

== See also ==
* [[File Formats:SAVF]] — how to get a program object's bytes off a machine or out of a distribution medium
* [[Data Structures:LID]] — the same single-level store address split, in a different container

[[Category: System Internals]]

File Formats:SAVF

2026-08-09T11:53:42Z

Friedkiwi: Document the SAVF container: chunk layer and checksum, item descriptors, sections, SRDS catalogue (via create-page on MediaWiki MCP Server)

A '''SAVF''' (''save file'') is the container OS/400 and IBM i write with <code>SAVOBJ</code> and <code>SAVLIB</code>, and read back with <code>RSTOBJ</code> and <code>RSTLIB</code>. It holds Machine Interface objects — programs, files, data areas, libraries — in the form they have on disk, together with a catalogue describing what was saved and from which machine.

Understanding the format is useful well beyond restoring a save file on a machine. It is the only practical way to get at the bytes of an MI object ''offline'': the same byte stream also appears inside optical images and tape images, so a distribution medium, a PTF, or a backup is an extractable archive of real MI objects. What can be done with one once it is extracted is described in [[File Formats:PGM]] for programs.

Everything below is big endian, and every text field is EBCDIC.

== Three layers ==
It helps to separate three things that are often run together:

* the '''chunk''' layer, which wraps the save stream in 528-byte units with a checksum on each;
* the '''item''' layer, which is a chain of saved objects, each a 512-byte descriptor followed by that object's segments;
* the '''catalogue''', a single special item per save that lists the library and its objects.

Only the chunk layer is specific to a save file held in <code>QSYS</code>. When the same save is carried on optical or tape media, the chunk wrapper is absent and the item chain sits in the medium directly. A reader that separates the layers handles all three media with one item parser.

== The chunk layer ==
A save file is exactly ''chunk count'' × 528 bytes. Chunk ''n'', counting from zero, begins at file offset <code>n × 528</code> and consists of 512 bytes of save-stream data followed by a 16-byte checksum. The logical save stream is the concatenation of the data halves, so translating a stream offset to a file offset is

<pre>
file_offset = (stream_offset / 512) * 528 + (stream_offset % 512)
</pre>

=== File header ===
The first 512 bytes of the stream — which are also the data half of chunk 1 — describe the container.

{|class="wikitable"
!Offset
!Size
!Field
!Notes
|-
|<code>+0x00</code>
|8
|MI creation timestamp
|Also the seed for every chunk checksum.
|-
|<code>+0x08</code>
|4
|Chunk count
|32-bit form.
|-
|<code>+0x10</code>
|8
|Machine type and model
|EBCDIC, model first: <code>42A 8286</code> is an 8286-42A.
|-
|<code>+0x30</code>
|4
|Release level
|-
|<code>+0x34</code>
|4
|Header length
|The first item starts here. Zero means 512.
|-
|<code>+0x38</code>
|8
|Chunk count
|64-bit form, used when the 32-bit field would overflow.
|-
|<code>+0x40</code>
|16
|Global checksum backup
|See below.
|}

A valid file satisfies <code>chunk count == file size / 528</code>; anything else means truncation. Because the header is itself chunk 1, verifying its checksum is the cheapest reliable test of whether a file is a save file at all.

=== The global checksum displaces real data ===
This is the trap worth knowing about before writing any extractor. The last 16 bytes of the ''logical'' stream, at <code>chunk count × 512 − 16</code>, are overwritten with a whole-file checksum. The data bytes they replaced are preserved in the file header at <code>+0x40</code>, and a reader must put them back. A reader that does not will silently corrupt the tail of the last object it extracts, in a way that no chunk checksum will catch, because the chunk checksums are computed over the overwritten bytes.

=== The chunk checksum ===
Each chunk's 16-byte trailer is the chunk number, counting from one, as a 4-byte big-endian integer, followed by a 12-byte digest. The digest is two folding passes built from a single primitive:

<pre>
chkadd(a, b): # b is exactly one byte longer than a
b[1:] += a << 1 # big-endian magnitudes, carry propagated
b[0] += carry + (the bit shifted out of the top of a)
</pre>

The first pass takes the chunk number followed by the 512 data bytes and cuts them into eight parts of 61, 62, 63, 64, 65, 66, 67 and 68 bytes, then folds them in ascending order: <code>chkadd</code> of the 61-byte part into the 62-byte part, that into the 63-byte part, and so on. The second pass takes the resulting 68 bytes, cuts them into parts of 5, 6, 7, 8, 9, 10, 11 and 12 bytes, and folds them the same way, leaving 12 bytes. The first 8 of those are then XORed with the file header's MI timestamp.

There is one non-obvious detail. In both passes the parts are ''filled'' from the input in the order 61, 62, 63, 64, 65, 66, '''68, 67''' — and 5, 6, 7, 8, 9, 10, '''12, 11''' — while being ''folded'' in ascending order. An implementation that fills them in plain ascending order produces a plausible-looking wrong answer.

The construction is a checksum, not a cryptographic hash. It detects media damage. It is not a tamper seal, and it carries no secret beyond a timestamp printed in the same header.

== The item layer ==
Items are chained: parse the descriptor at the header length, add the item's computed length, repeat, and stop when the next item would begin past <code>(chunk count − 1) × 512</code>. Every descriptor begins with <code>FFFFFFFF</code>, which makes resynchronising after damage feasible.

=== Item descriptor ===
{|class="wikitable"
!Offset
!Size
!Field
!Notes
|-
|<code>+0x00</code>
|4
|<code>FFFFFFFF</code>
|Eyecatcher.
|-
|<code>+0x04</code>
|10
|Object name
|EBCDIC. Replaced by a file ID for integrated file system objects.
|-
|<code>+0x0E</code>
|20
|Member name
|Empty unless the object has members.
|-
|<code>+0x22</code>
|2
|MI object type
|The same code space used throughout the machine: <code>0x0201</code> <code>*PGM</code>, <code>0x0401</code> <code>*LIB</code>, <code>0x1901</code> <code>*FILE</code>, <code>0x19DB</code> <code>*SRDS</code>.
|-
|<code>+0x24</code>
|1
|Flags
|Bit <code>0x40</code> or <code>0x80</code> means the item is an IFS object.
|-
|<code>+0x25</code>
|3
|Catalogue offset
|Where this object's entry sits inside the catalogue.
|-
|<code>+0x44</code>
|4
|Header occupation
|Bytes of the descriptor page actually used.
|-
|<code>+0x48</code>
|4
|Stored length
|In 512-byte units, minus one.
|-
|<code>+0x54</code>
|2
|Release created for
|Governs the section-entry layout below.
|-
|<code>+0x56</code>
|4
|Metadata length
|For a catalogue item, the size of the catalogue.
|-
|<code>+0x64</code>
|4
|Section count
|-
|<code>+0xC0</code>
|8
|Save timestamp
|-
|<code>+0xCC</code>
|4
|Total length
|In 512-byte units.
|-
|<code>+0xD4</code>
|4
|Data length
|In 512-byte units. Always the total length less 4096 bytes.
|-
|<code>+0x100</code>
|14 × 8
|Pointer array
|See below.
|-
|<code>+0x170</code>
|8
|Packed length
|Stored as the length less 512.
|}

The pointer array holds single-level store addresses, but only the low 24 bits matter: they are an offset into the item, biased by 4096, so <code>(pointer & 0xFFFFFF) − 4096</code> gives an offset within the descriptor page. Index 1 locates the section length table and index 8 the section type table.

=== Sections ===
A saved MI object is a set of segments, and each segment is one ''section'' of the item. Sections start at the first 4096-byte boundary after the descriptor and run consecutively, which is why the data length is always the total length less one page.

The length table has one entry per section. On any modern release — when the ''release created for'' field exceeds 32 — an entry is 16 bytes: capacity, length, and the segment's single-level store address. Older saves use a 10-byte entry with a shifted 6-byte address and no separate length.

The type table has one 8-byte entry per section, of which the first halfword is the segment type. This is the '''same value as the first halfword of the segment's own segment header''', which is a useful consistency check when extracting: the item's idea of what a section is must agree with the segment's own.

=== Item length and compression ===
An uncompressed item occupies its stored length. A packed item records a non-zero packed length, and the writer then realigns the following item on the enclosing 512-byte boundary, so the step from one item to the next is

<pre>
if packed == 512: step = stored
elif packed > stored: step = packed
else:
slack = stored - packed
within = item_offset % 512
if within == 0: step = stored
elif within < slack: step = packed + slack - within
else: step = stored + 512 - within
</pre>

The compression method is identifiable from the first six bytes of the packed data, which are EBCDIC eyecatchers:

{|class="wikitable"
!Bytes
!EBCDIC
!<code>DTACPR</code>
|-
|<code>D3C46DE3D9E2</code>
|<code>LD_TRS</code>
|<code>*MEDIUM</code>, the TERSE algorithm
|-
|<code>D3C46DD3E9F1</code>
|<code>LD_LZ1</code>
|<code>*HIGH</code>, IBM's LZ1
|-
|<code>D3C46DE9D3C2</code>
|<code>LD_ZLB</code>
|<code>*ZLIB</code>; the deflate stream begins 12 bytes in
|-
|none
|
|<code>*LOW</code>, an SNA-style run-length scheme, recognisable only by decoding it
|}

Note that these are ''not'' the compression used for a compressed LID payload; see [[Data Structures:LID]], where all four of these were tried and rejected.

== The catalogue ==
Every save writes one save/restore descriptor space item, MI type <code>0x19DB</code>, named <code>QSRDSSPC.''n''</code>, ahead of the objects it describes. Items named <code>QSR.ADDITIONAL_INFO.*</code> or <code>QSRDSSPC.EA SRD*</code> are continuation blocks belonging to the preceding descriptor, not new saves.

The catalogue itself is the '''last''' ''metadata length'' bytes of that item's data. Its first byte is the save command, and that selects the shape: a library save has the layout below, while a save of the integrated file system produces a different, tree-structured descriptor.

{|class="wikitable"
!Offset
!Size
!Field
|-
|<code>+0x00</code>
|1
|Save command
|-
|<code>+0x01</code>
|1
|Target release
|-
|<code>+0x02</code>
|30
|Saved library name
|-
|<code>+0x20</code>
|2
|Base object type, <code>0x0401</code>
|-
|<code>+0x22</code>
|8
|Save timestamp
|-
|<code>+0x2A</code>
|4
|Object count
|-
|<code>+0x34</code>
|8
|System serial number
|-
|<code>+0x3C</code>
|2
|ASP number
|-
|<code>+0x3E</code>
|10
|Create authority
|-
|<code>+0x4C</code>
|1
|Save-while-active indicator
|-
|<code>+0x50</code>
|10
|ASP name, target release 66 and later only
|}

Object descriptors follow, at <code>+0x50</code> or at <code>+0x70</code> when the ASP name is present. Each is 151 bytes on target release 49 and later, and 87 bytes before that. The first fields are the object name at <code>+0x00</code> for 30 bytes, the MI object type at <code>+0x1E</code>, and the owning user profile at <code>+0x20</code> for 10 bytes. The size is a 4-byte field at <code>+0x43</code>, multiplied by a second 4-byte field at <code>+0x79</code> when that is non-zero. The remainder of the descriptor holds offsets, into the same buffer, of chains of length-prefixed records carrying the object's text description, service description, usage information, work-unit references and user information.

Worth noticing for its own sake: the catalogue records the '''serial number of the machine that produced the save'''. A save file is not anonymous.

== Practical consequences ==
* Any MI object can be lifted out of a save file byte for byte, with its segments separated and their segment identifiers intact. That is what makes offline analysis of a program object possible without console access to a machine and without printing a storage dump.
* Verifying the chunk checksums is a genuine integrity check on an archived save file, and can be done without a machine.
* The item chain and the catalogue are independent descriptions of the same set of objects. Where they disagree, the file has been damaged or truncated.
* Because the chunk layer is only present for a save file held in <code>QSYS</code>, a save carved out of an optical or tape image is parsed by the same code with the chunk translation switched off.

== Scope of this description ==
The layout was mapped with reference to jSAVF, an independently developed third-party reader, and then verified field by field against a real V7R4 save file. Where an object in that file also had a printed Display/Alter/Dump available, the bytes extracted here matched the printout exactly. The chunk checksum was reimplemented from scratch and verifies every chunk of the test file.

Not established: the meaning of the 4-byte field at <code>+0x0C</code> of the file header, the layout of the integrated file system catalogue, and the LZ1 and TERSE decompressors.

== Weblinks ==
* [https://www.anerty.net/software/file/jSAVF/?lang=en jSAVF] — a maintained third-party reader for save files, and the starting point for the layout described here.

[[Category: System Internals]]

System Files:QFILEMCD

2026-08-08T20:38:12Z

Friedkiwi: Correct the header field at 0x26: it carries the system serial number, not a build id

'''<code>QFILEMCD</code>''' is the larger of the two container files found on AS/400 SAVSYS and Licensed Internal Code installation media. It is a backup of '''SLIC''' itself — the System Licensed Internal Code that sits below OS/400 — stored as a small number of very large memory segments. Its internal format is called '''<code>COPYDIR</code>''' after the eyecatcher at offset zero.

Practically, this is the file to reach for if you want to read the machine's own code without touching a running system. Its segments are a byte-for-byte image of what the link loader maps into memory, so an address recovered from a crash, a trace or a [[SRC|system reference code]] can be looked up directly in a file on your workstation. The companion file [[System Files:QFILEIML]] carries the loadable IOP, adapter and service processor microcode instead.

Both files are containers of [[Data Structures:LID|LIDs]], but at different granularities, and the relationship between them is described under ''Two directories, two granularities'' below.

The figures quoted here come from one V4R4 image of 472,846,336 bytes (451 MiB). Treat structure as general and numbers as release-specific; the format is unchanged from V4R4 through V7R4, across install media and SAVSYS output alike.

== Header ==
{|class="wikitable"
!Offset
!Contents
|-
|<code>0x00</code>
|Eyecatcher <code>COPYDIR </code> in EBCDIC (<code>C3 D6 D7 E8 C4 C9 D9 40</code>), a zero byte, then the two EBCDIC characters <code>00</code>
|-
|<code>0x1C</code>
|32-bit total size of the payload area — see below. Confirmed on three independent samples
|-
|<code>0x26</code>
|Release level, then the '''system serial number''', EBCDIC
|-
|<code>0x50</code>
|Licensed Internal Code banner, EBCDIC, in 48-character chunks
|-
|<code>0x1C0</code>
|Start of the directory
|}

The string in a V4R4 image reads:

<pre>
V4R4M044-C6295 2606071417
</pre>

and in a V7R4 one taken by SAVSYS from a running machine:

<pre>
V7R4M021-7886W
</pre>

The first field is the release and modification level. '''The five characters after the hyphen are the system serial number.''' That is not an inference: the owner of the V7R4 machine confirms its serial is <code>7886W</code>.

On '''installation media''' the same field carries a build or media tag instead — a V7R4 install ISO reads <code>V7R4M021-821BV</code> — so what the field means depends on how the image was produced. Both forms are five characters, which makes them easy to confuse.

<blockquote>'''Note!''' A LIC backup is therefore '''not anonymous''': it records the serial number of the machine it came from. The serial is also one of the values the system password is keyed on (see [[CISC AS/400 LIC Tapes]]), so treat these files as identifying if you share them.</blockquote>

In the V4R4 sample the ten digits after the serial parse naturally as a timestamp of the form <code>YYMMDDHHMM</code>, making that backup 2026-06-07 14:17. That part '''is''' an inference from the shape of the field, and the V7R4 sample carries binary rather than digits in the same place, so the layout after the serial is not fixed.

<blockquote>'''Note!''' The header is '''not''' a fixed 192 (<code>0xC0</code>) bytes, despite older format notes saying so. The IBM legal banner runs on well past that point, and in this V4R4 image the directory does not begin until <code>0x1C0</code>. A parser should locate the directory by scanning for the first 64-byte-aligned block that has the shape of an entry, rather than seeking to a constant.</blockquote>

The 32-bit field at <code>0x1C</code> holds <code>0x1C2F0000</code>, which is exactly the end of the last segment's data. It is a total-payload-size field and makes a good consistency check after parsing the directory: accumulate the entries and you should arrive at the same number.

== The directory ==
The directory is a run of 64-byte entries beginning at <code>0x1C0</code>.

{|class="wikitable"
!Offset
!Size
!Field
|-
|<code>+0x00</code>
|8
|Always zero in observed data
|-
|<code>+0x08</code>
|8
|Flags. See the bit-numbering warning below
|-
|<code>+0x10</code>
|8
|SLS address of the saved segment
|-
|<code>+0x18</code>
|8
|Segment attributes; the top 16 bits carry the useful value
|-
|<code>+0x20</code>
|8
|Always zero in observed data
|-
|<code>+0x28</code>
|8
|Offset to the segment data, '''absolute from the start of the file'''
|-
|<code>+0x30</code>
|4
|Segment length, in '''raw bytes''' — not blocks
|-
|<code>+0x34</code>
|4
|Always zero in observed data
|-
|<code>+0x38</code>
|8
|Always zero in observed data
|}

Two details cause most of the trouble people have with this structure, and both were originally got wrong here:

* '''Flags use IBM's MSB-first bit numbering.''' Older notes describe the field as <code>bbt 0:3</code>, and a reader used to LSB-first numbering will look in the bottom nibble and find nothing. Bit 0 is the ''most'' significant bit, so the value lives in the '''top''' nibble of the 8-byte field. A normal entry reads <code>0x1000000000000000</code>; the end-of-directory marker reads <code>0xF000000000000000</code>.
* '''The data offset is absolute.''' It is measured from the start of the file, not from the end of the directory. Reading it as relative shifts every extracted segment by the size of the directory, which produces code that disassembles almost plausibly and is wrong everywhere.

In this image the directory holds '''32 entries''', with the terminator at <code>0x9C0</code> and the directory ending at <code>0xA00</code>. The first entry has a data offset of zero, which means the header and directory physically occupy the first <code>0xA00</code> bytes of the first segment's stored image. This is expected rather than a bug, but a tool that extracts that segment will see the container's own header at the front of it.

Segment lengths are consistently a whole number of 4 KiB pages less than a power-of-two boundary: <code>0xFFF000</code> is 16 MiB minus one page, <code>0x7FF000</code> is 8 MiB minus one page, and so on.

== Contents of a typical backup ==
The 32 segments of this image, with names from a community-maintained SLS address reference. Where the name column is blank, the segment's purpose has not been established.

{|class="wikitable"
!SLS address
!Length
!Name
|-
|<code>FFFFFFFFB1 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFFB2 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFFB3 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFFB5 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFFC1 000000</code>
|16 MiB
|Link Loader — LIC Code
|-
|<code>FFFFFFFFC2 000000</code>
|16 MiB
|Link Loader — LIC Data
|-
|<code>FFFFFFFFC3 000000</code>
|16 MiB
|Link Loader — LIC Code (2)
|-
|<code>FFFFFFFFC4 000000</code>
|16 MiB
|Link Loader — LIC Code (3)
|-
|<code>FFFFFFFFC5 000000</code>
|16 MiB
|Link Loader — LIC Code (4)
|-
|<code>FFFFFFFFC6 000000</code>
|8 MiB
|Link Loader — LIC Code (5)
|-
|<code>FFFFFFFFC7 000000</code>
|16 MiB
|Mixed — component code and NLS text pools
|-
|<code>FFFFFFFFC8 000000</code>
|8 MiB
|Mixed — bignum/JVM code and NLS text pools
|-
|<code>FFFFFFFFF1 000000</code>
|4 MiB
|Link Loader TOC
|-
|<code>FFFFFFFFF2 000000</code>
|16 MiB
|Service LID
|-
|<code>FFFFFFFFF4 000000</code>
|16 MiB
|Service LID (2)
|-
|<code>FFFFFFFFFE 000000</code>
|15 MiB
|Pageable BLA
|-
|<code>FFFFFFFFD1 000000</code>
|16 MiB
|Link Loader Information
|-
|<code>FFFFFFFFD2 000000</code>
|16 MiB
|Link Loader Information, Code, Data
|-
|<code>FFFFFFFFD3 000000</code>
|16 MiB
|Link Loader Information (2)
|-
|<code>FFFFFFFFD4 000000</code>
|16 MiB
|Mixed — JVM strings and DST debug symbol table
|-
|<code>FFFFFFFF90 010000</code>
|60 KiB
|LID Directory
|-
|<code>FFFFFFFF91 000000</code>
|16 MiB
|LID NUC2 A-Side
|-
|<code>FFFFFFFF92 000000</code>
|16 MiB
|LID NUC2 B-Side
|-
|<code>FFFFFFFF93 000000</code>
|16 MiB
|LID NUC1 A-Side
|-
|<code>FFFFFFFF94 000000</code>
|16 MiB
|LID NUC1 B-Side
|-
|<code>FFFFFFFF95 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFF96 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFF9A 000000</code>
|8 MiB
|
|-
|<code>FFFFFFFF9B 000000</code>
|8 MiB
|
|-
|<code>FFFFFFFFA1 000000</code>
|16 MiB
|LID Manager
|-
|<code>FFFFFFFFA2 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFF69 000000</code>
|16 MiB
|IDE
|}

So a backup of this shape is the SLIC boot and loader nucleus: link loader code and data, the loader's table of contents, the LID subsystem's own bookkeeping, and both IPL sides of the two nucleus LIDs. It is not the whole of the machine's code.

=== A and B sides ===
Several segments appear twice, distinguished as ''A-side'' and ''B-side''. An AS/400 keeps two copies of its Licensed Internal Code so that an update can be applied to one while the other remains a fallback. A normal, unattended IPL runs the '''B side''', so B is what a running machine is executing and B is what static analysis should be done against. Because the two sides are normally near-identical, a byte comparison against the A side is not evidence that A is the live one — the test only means something on a segment that actually differs between them.

== Two directories, two granularities ==
A common source of confusion is that <code>QFILEMCD</code> appears to have two completely different directory formats. It does, and they nest:

* The '''coarse''' level is <code>COPYDIR</code>'s own directory, documented above: 64-byte entries, one per 16 MiB-class memory segment, 32 of them.
* The '''fine''' level is a catalogue of individual LIDs, thousands of entries, using the 32-byte record described at [[Data Structures:LID]].

The fine level is not a second header in the file. It is simply '''the contents of one particular segment''' — the one named ''LID Directory'', at <code>FFFFFFFF90 010000</code>. Extract that segment and you find, after a preamble of about 1536 bytes, an EBCDIC <code>Directory.</code> eyecatcher, a version label, and then the records. In this image the label reads <code>v4r4m01204.0.03</code>, which is the same label carried by [[System Files:QFILEIML]] — a quick way to confirm that two files came off the same media.

That is also why tools which dump this file emit two dissimilar-looking listings: a short table of large memory extents, and a long list of LIDs. They are two levels of one structure, not two formats.

== Extracting a segment ==
The practical recipe, and the reason this file is worth knowing about:

# Read the <code>COPYDIR</code> eyecatcher at offset 0 to confirm the format.
# Find the directory by scanning 64-byte-aligned offsets for the first entry-shaped block, rather than assuming <code>0xC0</code> or <code>0x1C0</code>.
# Walk entries until the flags field has <code>0xF</code> in its '''top''' nibble.
# For the segment you want, seek to the data offset '''as an absolute file offset''' and read ''length'' raw bytes.
# Load the result at its SLS address in a disassembler. The bytes are what the link loader maps, so addresses match.

Step 5 is the payoff. A 64-bit address such as <code>FFFFFFFFC6 1F1690</code> can be typed straight into the DST ''Display/Alter storage'' panel on a live machine of the same build, and the sixteen rows it displays will match the extracted file byte for byte. Static and live analysis share one address space, which means you can do the slow work offline and use the machine only for confirmation.

Two caveats on addresses. They are per-'''build''', not per-release, so comparisons are only meaningful between identical builds; the same class sits at a quite different address on a V5R4 machine. And the SLS address recorded in the directory is the address the segment was '''saved from''', which is not always where it runs — the resident nucleus segment, for instance, is stored in the container under the SID of the B-side nucleus LID rather than its runtime SID.

== Reading the code ==
Once a segment is loaded, two structures make it navigable, and both are worth knowing because they turn addresses into names:

* '''Traceback trailers.''' Every compilation unit ends its code with a <code>TBTB</code> trailer, and many carry the module's name. A trailer names a whole compilation unit rather than a single function, so a hit means "this address is inside module X", not "this address is function X".
* '''Link-loader descriptor blocks.''' Considerably richer: one block per procedure, carrying the entry address at <code>+0x08</code> and the name in EBCDIC at <code>+0x38</code>. Names beginning with <code>#</code> are SLIC-internal modules; the rest are C++ mangled symbols.

Merging both across every segment of this V4R4 image yields roughly 184,000 named records, which is enough to name a substantial fraction of any address you encounter. See [[SRC]] for how to use that to get from a reference code back to a module.

Calls between modules do not go through a conventional dispatch table, which surprises people disassembling SLIC for the first time. An external call is a two-instruction sequence — <code>ori r11,r13,''ordinal''</code> followed by <code>bla</code> into a transfer vector at the very top of the address space — and the 16-byte stub it lands on computes the target arithmetically. There is no table to read off; the ordinal ''is'' the callee's word offset within a window, and the stub supplies the window. The stub constants cannot be derived and must be read from a dump of the transfer vector.

== The trailing page ==
The payload area ends at <code>0x1C2F0000</code>, but the file is one 4 KiB page longer than that. The final page is not padding: it holds 468 non-zero 8-byte records, which appear to be address-and-value pairs.

They fall into two clear populations. The first 110 are in ascending address order with a value of 8, addressing the ''Link Loader — LIC Data'' segment among others. The remaining 256 are identical to each other: the same address <code>0xFE911220</code>, in the ''Pageable BLA'' segment, paired with the value <code>0x48000002</code> — which as PowerPC is a branch-absolute to zero, the shape of a deliberately poisoned entry.

This has the flavour of a fixup or relocation list applied after the segments are restored, but that is a guess from shape alone. It is recorded here because it is real, reproducible and unexplained, and because a parser that assumes the file ends with the payload will silently ignore it.

== Open questions ==
* The purpose of the trailing page.
* The header bytes other than the eyecatcher, size field, release string and banner.
* The meaning of the segment attribute field's top 16 bits, which take values <code>0x0001</code>, <code>0x0040</code>, <code>0x0080</code> and <code>0x0100</code> and correlate loosely with segment size.
* Names for the nine segments left blank in the table above.

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

== Footnotes ==
<references />

[[Category: System Internals]]

System Files:QFILEIML

2026-08-08T18:49:12Z

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

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

This description is based on two samples: a V4R4 image of 81,287,680 bytes (77.5 MiB), build label <code>v4r4m01204.0.03</code>, and a V7R2 one of 288.7 MiB, label <code>v7r2m00000.0.00</code>, taken from an installation ISO. Unless a figure is attributed to a release, it comes from the V4R4 sample; the section ''Across releases'' sets out what is format and what merely happened to be true of one image.

== 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"
!Offset
!Contents
|-
|<code>0x000</code>
|Magic <code>C9 D4 C4 F1</code>, which is <code>IMD1</code> in EBCDIC
|-
|<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
|-
|''banner'' × 2
|Directory header: a four-byte preamble, the literal string <code>Directory.</code>, two zero bytes, then a 16-byte build label
|-
|''banner'' × 2 + <code>0x20</code>
|The directory: a run of 32-byte LID records
|-
|''varies''
|Terminator record, identifier <code>0xC5D5C440</code> (<code>END </code> in EBCDIC)
|}

The first sixteen bytes of a V4R4 container are:

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

and of a V7R2 one:

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

The banner reads, in EBCDIC:

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

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

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

== 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 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. As the rest of this section shows, that turns out to be only half true.

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 ====
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>) — 119 of them in a V4R4 container and 104 in a V7R2 one, decoding identically. The useful fields are:

{|class="wikitable"
!Offset
!Contents
|-
|<code>+0x00</code>
|<code>PGPM</code> eyecatcher
|-
|<code>+0x04</code>
|A LID identifier — but see the caveat below
|-
|<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
|}

<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 following 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 ===
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"
!Call
!Count
!Observed arguments
|-
|<code>0x020C</code>
|262
|—
|-
|<code>0x0208</code>
|131
|<code>r3 = 0x16</code> in every instance
|-
|<code>0x03A4</code>
|106
|<code>r3 = 0x64</code>, <code>r4 = 5</code>; unique to one module
|-
|<code>0x0358</code>
|
|<code>r3</code> is one of exactly three values: <code>0x83010000</code>, <code>0x83020000</code>, <code>0x83030000</code>
|}

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.

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.

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.

=== 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 the banner offset from <code>+0x08</code> and '''derive''' the directory position from it, rather than assuming a constant;
# read 32-byte records until an identifier of <code>0xC5D5C440</code> or zero;
# place the payload area at the next block boundary after that terminator;
# lay payloads out sequentially in directory order.

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.

== Across releases ==
Comparing a V4R4 image with a V7R2 one shows how much of this is format and how much was accident of a single sample.

{|class="wikitable"
!
!V4R4
!V7R2
|-
|Records
|632
|961
|-
|Compressed
|341
|557
|-
|Payload
|77.5 MiB
|288.7 MiB
|-
|<code>PGPM</code> module headers
|119
|104
|}

The record format, the <code>PGPM</code> module header and its field offsets, the payload tiling rule and the <code>END </code> terminator are all unchanged. What varies is the header offsets, which the header itself declares.

The service processor module namespace is also strikingly stable. Fourteen <code>SP</code> module names are defined in both releases, and the pattern of numbered names being imported but never defined — the evidence that they live in flash on the card — reproduces exactly sixteen years apart. So does the supervisor call vocabulary, with V7R2 adding one new call number.

What did change is on the SLIC side, and it is what you would expect once the service processor and panel stop being discrete cards. The concrete hardware driver classes are simply gone in V7R2, while the message protocol and resource model that sat on top of them survive and grow. In their place, the panel and service processor objects are constructed from new ''virtual'' VPD providers. The interface is preserved and the implementation behind it is virtualised — which is why code written against the older message classes still reads as recognisable on a modern machine.

== Open questions ==
* The header field at <code>+0x0C</code>, which differs between samples (<code>00e00000</code> against <code>00100000</code>).
* The rest of the header between <code>+0x0C</code> and the banner.
* The meaning of most LID identifier families.
* Why some 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.
* The <code>PGPM</code> identifier discrepancy described above.

== 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]]

System Files:QFILEIML

2026-08-08T18:47:07Z

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

'''<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 ==
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"
!Offset
!Contents
|-
|<code>0x000</code>
|Magic <code>C9 D4 C4 F1</code>, which is <code>IMD1</code> in EBCDIC
|-
|<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
|-
|''banner'' × 2
|Directory header: a four-byte preamble, the literal string <code>Directory.</code>, two zero bytes, then a 16-byte build label
|-
|''banner'' × 2 + <code>0x20</code>
|The directory: a run of 32-byte LID records
|-
|''varies''
|Terminator record, identifier <code>0xC5D5C440</code> (<code>END </code> in EBCDIC)
|}

The first sixteen bytes of a V4R4 container are:

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

and of a V7R2 one:

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

The banner reads, in EBCDIC:

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

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

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

== 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 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. As the rest of this section shows, that turns out to be only half true.

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.

=== What is not in the file ===
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"
!Call
!Count
!Observed arguments
|-
|<code>0x020C</code>
|262
|—
|-
|<code>0x0208</code>
|131
|<code>r3 = 0x16</code> in every instance
|-
|<code>0x03A4</code>
|106
|<code>r3 = 0x64</code>, <code>r4 = 5</code>; unique to one module
|-
|<code>0x0358</code>
|
|<code>r3</code> is one of exactly three values: <code>0x83010000</code>, <code>0x83020000</code>, <code>0x83030000</code>
|}

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.

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.

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 ====
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>

== 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 the banner offset from <code>+0x08</code> and '''derive''' the directory position from it, rather than assuming a constant;
# read 32-byte records until an identifier of <code>0xC5D5C440</code> or zero;
# place the payload area at the next block boundary after that terminator;
# lay payloads out sequentially in directory order.

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.

== Across releases ==
Comparing a V4R4 image with a V7R2 one shows how much of this is format and how much was accident of a single sample.

{|class="wikitable"
!
!V4R4
!V7R2
|-
|Records
|632
|961
|-
|Compressed
|341
|557
|-
|Payload
|77.5 MiB
|288.7 MiB
|-
|<code>PGPM</code> module headers
|119
|104
|}

The record format, the <code>PGPM</code> module header and its field offsets, the payload tiling rule and the <code>END </code> terminator are all unchanged. What varies is the header offsets, which the header itself declares.

The service processor module namespace is also strikingly stable. Fourteen <code>SP</code> module names are defined in both releases, and the pattern of numbered names being imported but never defined — the evidence that they live in flash on the card — reproduces exactly sixteen years apart. So does the supervisor call vocabulary, with V7R2 adding one new call number.

What did change is on the SLIC side, and it is what you would expect once the service processor and panel stop being discrete cards. The concrete hardware driver classes are simply gone in V7R2, while the message protocol and resource model that sat on top of them survive and grow. In their place, the panel and service processor objects are constructed from new ''virtual'' VPD providers. The interface is preserved and the implementation behind it is virtualised — which is why code written against the older message classes still reads as recognisable on a modern machine.

== Open questions ==
* The header field at <code>+0x0C</code>, which differs between samples (<code>00e00000</code> against <code>00100000</code>).
* The rest of the header between <code>+0x0C</code> and the banner.
* The meaning of most LID identifier families.
* Why some 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.
* The <code>PGPM</code> identifier discrepancy described above.

=== 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]]

System Files:QFILEIML

2026-08-08T18:46:48Z

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

'''<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 ==
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"
!Offset
!Contents
|-
|<code>0x000</code>
|Magic <code>C9 D4 C4 F1</code>, which is <code>IMD1</code> in EBCDIC
|-
|<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
|-
|''banner'' × 2
|Directory header: a four-byte preamble, the literal string <code>Directory.</code>, two zero bytes, then a 16-byte build label
|-
|''banner'' × 2 + <code>0x20</code>
|The directory: a run of 32-byte LID records
|-
|''varies''
|Terminator record, identifier <code>0xC5D5C440</code> (<code>END </code> in EBCDIC)
|}

The first sixteen bytes of a V4R4 container are:

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

and of a V7R2 one:

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

The banner reads, in EBCDIC:

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

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

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

== 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 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. As the rest of this section shows, that turns out to be only half true.

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.

=== What is not in the file ===
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"
!Call
!Count
!Observed arguments
|-
|<code>0x020C</code>
|262
|—
|-
|<code>0x0208</code>
|131
|<code>r3 = 0x16</code> in every instance
|-
|<code>0x03A4</code>
|106
|<code>r3 = 0x64</code>, <code>r4 = 5</code>; unique to one module
|-
|<code>0x0358</code>
|
|<code>r3</code> is one of exactly three values: <code>0x83010000</code>, <code>0x83020000</code>, <code>0x83030000</code>
|}

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.

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.

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 ====
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 ===
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]]

System Files:QFILEIML

2026-08-08T18:46:37Z

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

'''<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 ==
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"
!Offset
!Contents
|-
|<code>0x000</code>
|Magic <code>C9 D4 C4 F1</code>, which is <code>IMD1</code> in EBCDIC
|-
|<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
|-
|''banner'' × 2
|Directory header: a four-byte preamble, the literal string <code>Directory.</code>, two zero bytes, then a 16-byte build label
|-
|''banner'' × 2 + <code>0x20</code>
|The directory: a run of 32-byte LID records
|-
|''varies''
|Terminator record, identifier <code>0xC5D5C440</code> (<code>END </code> in EBCDIC)
|}

The first sixteen bytes of a V4R4 container are:

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

and of a V7R2 one:

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

The banner reads, in EBCDIC:

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

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 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 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. As the rest of this section shows, that turns out to be only half true.

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.

=== What is not in the file ===
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"
!Call
!Count
!Observed arguments
|-
|<code>0x020C</code>
|262
|—
|-
|<code>0x0208</code>
|131
|<code>r3 = 0x16</code> in every instance
|-
|<code>0x03A4</code>
|106
|<code>r3 = 0x64</code>, <code>r4 = 5</code>; unique to one module
|-
|<code>0x0358</code>
|
|<code>r3</code> is one of exactly three values: <code>0x83010000</code>, <code>0x83020000</code>, <code>0x83030000</code>
|}

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.

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.

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 ====
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 ===
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]]

System Files:QFILEIML

2026-08-08T17:37:59Z

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

'''<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 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. As the rest of this section shows, that turns out to be only half true.

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.

=== What is not in the file ===
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"
!Call
!Count
!Observed arguments
|-
|<code>0x020C</code>
|262
|—
|-
|<code>0x0208</code>
|131
|<code>r3 = 0x16</code> in every instance
|-
|<code>0x03A4</code>
|106
|<code>r3 = 0x64</code>, <code>r4 = 5</code>; unique to one module
|-
|<code>0x0358</code>
|
|<code>r3</code> is one of exactly three values: <code>0x83010000</code>, <code>0x83020000</code>, <code>0x83030000</code>
|}

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.

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.

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 ====
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 ===
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]]

System Files:QFILEIML

2026-08-08T17:37:37Z

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)

SRC

2026-08-08T17:05:36Z

Friedkiwi: Document the SRC concept and the method for tracing a reference code back to a LIC module (via create-page on MediaWiki MCP Server)

A '''system reference code''' ('''SRC''') is the AS/400's primary way of telling you what it is doing or what went wrong. It is the string of hexadecimal characters shown on the operator panel's display, and the same codes appear in the system's logs and on the console. Because the platform is designed to be serviced by someone who may not have a working console, the SRC is deliberately the lowest-common-denominator channel: it works when nothing else does.

This article covers what an SRC ''is'' and, more usefully, '''how to work back from one to the piece of Licensed Internal Code that produced it'''. Individual codes are catalogued elsewhere — see [[Disk device related system reference codes]], [[Tape device related system reference codes]] and [[SRC 0000BBBB]] for worked cases.

== What an SRC looks like ==
The panel displays eight hexadecimal characters. That display is only the first of several ''words'' the machine has available; the remainder are reached with the panel's extended functions, and all of them are recorded in the logs.

The leading character is the most informative part, because it identifies what kind of event you are looking at:

{|class="wikitable"
!Leading character
!Meaning
|-
|<code>A</code>
|Attended IPL — the machine is waiting for you
|-
|<code>B</code>
|A problem was detected, most often by Licensed Internal Code
|-
|<code>C</code>
|IPL progress; the machine is working normally
|-
|<code>D</code>
|Power-down progress
|}

The distinction that matters when something appears stuck is between <code>C</code> and <code>B</code>. A <code>C</code> code is a progress report, and a machine sitting on one for a long time may simply be doing something slow. A <code>B</code> code is a failure, and it will not clear itself.

Progress codes are genuinely informative about sequence. The IPL-time verification sequence, for instance, runs:

{|class="wikitable"
!SRC
!Meaning
|-
|<code>C600 4500</code>
|Verifying network attributes
|-
|<code>C600 4504</code>
|Verifying system serial number
|-
|<code>C600 4505</code>
|Verifying system type
|-
|<code>C600 4506</code>
|Verifying system-unique ID
|-
|<code>C600 4507</code>
|Starting 'before DST' DASD checker
|-
|<code>C600 4508</code>
|Verifying system password
|-
|<code>C600 450A</code>
|Starting 'after DST' DASD checker
|}

Read as a whole, that tells you the order of dependency inside the IPL — serial number, then type, then unique ID, then disk state, then the system password — which is information you will not find stated anywhere as prose. Progress codes are a free execution trace of the boot path, and reading a long capture of them is a cheap way to understand a sequence you cannot otherwise observe.

== Where SRCs are recorded ==
The panel shows the current one. Everything else is in the machine:

* '''Panel extended functions''' step through the additional words of the current SRC.
* The '''Product Activity Log''', under DST or SST, holds hardware-detected events with their full word set and timestamps.
* The '''Licensed Internal Code log''' holds LIC-detected events. This is the one that matters for the technique below, because for a LIC-detected error it records the failing '''module''' — not just a code.
* '''Main storage dumps''' capture machine state at the point of failure.

If you are trying to understand a failure rather than merely clear it, go to the logs. The panel gives you one word of what may be a nine-word record.

== How SRCs are produced ==
Inside SLIC there is a family of classes that construct reference codes, one per flavour of event:

<pre>
IoMFSystemRefCode base
IoMFGenericSystemRefCode generic
IoMFAttentionSystemRefCode attention
IoMFIplStatusSystemRefCode IPL status
IoMFRunStatusSystemRefCode run-time status
IoMFTerminalSystemRefCode terminal
IoMFExtendedSrc / IoMFExtendedSrcHyp
</pre>

alongside a set of categories that amount to the machine's error taxonomy — <code>IoMFSrcDeviceFailure</code>, <code>IoMFSrcIoError</code>, <code>IoMFSrcIopCodeDetectedFailure</code>, <code>IoMFSrcSlicDetectedError</code>, <code>IoMFSrcIopFailureNoDeviceVpd</code> and several more. Persistent logging goes through an entry point named <code>putSrc</code> on the persistent-machine class.

Getting the code onto the panel is a separate step, handled by a request/acknowledge message protocol to the service processor. The panel-related messages include <code>IoMFCEMessageSRCDisplay</code> to display a code and <code>IoMFCEMessagePNLClearSRC</code> to clear it, in among messages for panel button notifications, power control and IPL mode. The panel is a small subassembly with its own microcontroller, driven over what appears from the software side to be a simple serial link.

The practical consequence is that '''posting an SRC is an ordinary function call''' made from ordinary code. It is not a hardware trap or a magic register. So the code that posted a given SRC is findable by the same means as any other caller.

== Working back from an SRC to a LIC module ==
This is the part worth generalising, because the same route serves any question of the form "which code did this?" — not only SRCs.

=== On the machine ===
For a LIC-detected error, the Licensed Internal Code log entry names the failing module directly. That is the short path and should always be tried first: DST or SST, the LIC log, then the detailed display for the entry in question. You are looking for a module name and an offset within it.

Module names follow visible conventions once you have seen a few. Names beginning with <code>#</code> are SLIC-internal modules; the rest are C++ symbols and are mangled, so a name like <code>putSrc__16NuPersistMachineFUtPv</code> decomposes into a method <code>putSrc</code> on class <code>NuPersistMachine</code> taking an unsigned halfword and a pointer.

=== Offline, from installation media ===
When the log does not name a module, or when you want to read the code rather than just identify it, the route runs through [[System Files:QFILEMCD]]:

# '''Extract the segments.''' <code>QFILEMCD</code> contains SLIC as large memory segments stored at the addresses the link loader maps them to.
# '''Build a name index.''' Two structures in the code give you addresses paired with names. Every compilation unit ends with a <code>TBTB</code> traceback trailer, many carrying the unit's name; and the link loader leaves a descriptor block per procedure, with the entry address at <code>+0x08</code> and the name in EBCDIC at <code>+0x38</code>. Merging both across every segment of a V4R4 image gives on the order of 184,000 named records.
# '''Look the address up.''' Prefer descriptor hits, which name exactly one procedure, over traceback hits, which cover a whole compilation unit and so only tell you which module an address is in.
# '''Find who posts the code.''' Because SRC posting is a normal call, you can find every site that posts one by resolving the calls to the <code>IoMF*SystemRefCode</code> constructors and reading what the caller places in the code fields just beforehand.

Step 4 needs one piece of SLIC-specific knowledge. External calls do not go through a dispatch table you can read off. A call is <code>ori r11,r13,''ordinal''</code> followed by <code>bla</code> into a transfer vector at the top of the address space, and the 16-byte stub it lands on computes the target arithmetically from the ordinal. To resolve calls you need the stub constants, which are not derivable and must be read from a dump of the transfer vector segment. With them, every external call in a segment resolves mechanically.

=== A worked example ===
The DST module that verifies the system password illustrates the whole path. Immediately before it calls <code>IoMFGenericSystemRefCode</code>, it does this:

<pre>
li r0, 0x12 ; 18
li r31, 0x21 ; 33
lhz r6, 0x18(r29) ; the password status halfword
cmpwi r6, 0x30
bne ...
sth r0, 0x44(r1) ; status == 0x30 -> code 0x12
b ...
sth r31, 0x44(r1) ; otherwise -> code 0x21
ori r11, r13, 0xd45c
bla ... ; IoMFGenericSystemRefCode
</pre>

Read backwards, this is exactly the inference you want to be able to make. The reference code is chosen from a status halfword; a status of <code>0x30</code> produces one code and anything else produces another. So the two codes are not two unrelated faults but two branches of one test, and knowing which one appeared tells you which branch was taken. Working ''forward'' from the SRC list would never reveal that relationship.

=== What the method will not give you ===
Two honest limits. A traceback trailer names a compilation unit, which may contain many entry points, so it localises rather than pinpoints. And addresses are per-'''build''', not per-release: the same class sits at a completely different address on a machine of another build, so a name index is only valid against the media it was built from. Always match your extracted image to the machine you are investigating, using the build label carried in both container files.

== Why this is worth learning ==
The technique generalises well beyond diagnosing faults. An SRC sequence is an execution trace with names attached, and the machine emits one on every IPL whether or not anything is wrong. Combined with a name index over the LIC image, it lets you ask questions the documentation does not answer — what the machine checks and in what order, which subsystem owns a given behaviour, where a slow phase is actually spending its time — using only a panel display and a copy of the installation media.

== See also ==
* [[System Files:QFILEMCD]]
* [[System Files:QFILEIML]]
* [[Data Structures:LID]]
* [[SRC 0000BBBB]]
* [[Disk device related system reference codes]]
* [[Tape device related system reference codes]]
* [[Panel Usage]]

== Weblinks ==
* [https://www.ibm.com/docs/en/i/7.4.0?topic=finder-system-reference-code-list System reference code list], IBM Documentation
* [https://www.ibm.com/resources/publications/OutputPubsDetails?PubID=SY44590100 AS/400e Service Functions], which documents the panel functions and the IPL progress code sequences

== Footnotes ==
<references />

[[Category: System Internals]]

System Files:QFILEMCD

2026-08-08T17:04:39Z

Friedkiwi: Document the QFILEMCD / COPYDIR container: header, directory, segment extraction (via create-page on MediaWiki MCP Server)

'''<code>QFILEMCD</code>''' is the larger of the two container files found on AS/400 SAVSYS and Licensed Internal Code installation media. It is a backup of '''SLIC''' itself — the System Licensed Internal Code that sits below OS/400 — stored as a small number of very large memory segments. Its internal format is called '''<code>COPYDIR</code>''' after the eyecatcher at offset zero.

Practically, this is the file to reach for if you want to read the machine's own code without touching a running system. Its segments are a byte-for-byte image of what the link loader maps into memory, so an address recovered from a crash, a trace or a [[SRC|system reference code]] can be looked up directly in a file on your workstation. The companion file [[System Files:QFILEIML]] carries the loadable IOP, adapter and service processor microcode instead.

Both files are containers of [[Data Structures:LID|LIDs]], but at different granularities, and the relationship between them is described under ''Two directories, two granularities'' below.

The figures quoted here come from one V4R4 image of 472,846,336 bytes (451 MiB). Treat structure as general and numbers as release-specific; the format is known to have survived at least to V7R2 with the same shape.

== Header ==
{|class="wikitable"
!Offset
!Contents
|-
|<code>0x00</code>
|Eyecatcher <code>COPYDIR </code> in EBCDIC (<code>C3 D6 D7 E8 C4 C9 D9 40</code>), a zero byte, then the two EBCDIC characters <code>00</code>
|-
|<code>0x1C</code>
|32-bit total size of the payload area — see below
|-
|<code>0x26</code>
|Release and build string, EBCDIC
|-
|<code>0x50</code>
|Licensed Internal Code banner, EBCDIC, in 48-character chunks
|-
|<code>0x1C0</code>
|Start of the directory
|}

The release string in this image is:

<pre>
V4R4M044-C6295 2606071417
</pre>

The first part identifies the release and build. The ten digits that follow parse naturally as a timestamp of the form <code>YYMMDDHHMM</code>, which would make this backup 2026-06-07 14:17 — plausible, since the image was produced by a SAVSYS on a running machine rather than shipped by IBM. That reading is an inference from the shape of the field.

<blockquote>'''Note!''' The header is '''not''' a fixed 192 (<code>0xC0</code>) bytes, despite older format notes saying so. The IBM legal banner runs on well past that point, and in this V4R4 image the directory does not begin until <code>0x1C0</code>. A parser should locate the directory by scanning for the first 64-byte-aligned block that has the shape of an entry, rather than seeking to a constant.</blockquote>

The 32-bit field at <code>0x1C</code> holds <code>0x1C2F0000</code>, which is exactly the end of the last segment's data. It is a total-payload-size field and makes a good consistency check after parsing the directory: accumulate the entries and you should arrive at the same number.

== The directory ==
The directory is a run of 64-byte entries beginning at <code>0x1C0</code>.

{|class="wikitable"
!Offset
!Size
!Field
|-
|<code>+0x00</code>
|8
|Always zero in observed data
|-
|<code>+0x08</code>
|8
|Flags. See the bit-numbering warning below
|-
|<code>+0x10</code>
|8
|SLS address of the saved segment
|-
|<code>+0x18</code>
|8
|Segment attributes; the top 16 bits carry the useful value
|-
|<code>+0x20</code>
|8
|Always zero in observed data
|-
|<code>+0x28</code>
|8
|Offset to the segment data, '''absolute from the start of the file'''
|-
|<code>+0x30</code>
|4
|Segment length, in '''raw bytes''' — not blocks
|-
|<code>+0x34</code>
|4
|Always zero in observed data
|-
|<code>+0x38</code>
|8
|Always zero in observed data
|}

Two details cause most of the trouble people have with this structure, and both were originally got wrong here:

* '''Flags use IBM's MSB-first bit numbering.''' Older notes describe the field as <code>bbt 0:3</code>, and a reader used to LSB-first numbering will look in the bottom nibble and find nothing. Bit 0 is the ''most'' significant bit, so the value lives in the '''top''' nibble of the 8-byte field. A normal entry reads <code>0x1000000000000000</code>; the end-of-directory marker reads <code>0xF000000000000000</code>.
* '''The data offset is absolute.''' It is measured from the start of the file, not from the end of the directory. Reading it as relative shifts every extracted segment by the size of the directory, which produces code that disassembles almost plausibly and is wrong everywhere.

In this image the directory holds '''32 entries''', with the terminator at <code>0x9C0</code> and the directory ending at <code>0xA00</code>. The first entry has a data offset of zero, which means the header and directory physically occupy the first <code>0xA00</code> bytes of the first segment's stored image. This is expected rather than a bug, but a tool that extracts that segment will see the container's own header at the front of it.

Segment lengths are consistently a whole number of 4 KiB pages less than a power-of-two boundary: <code>0xFFF000</code> is 16 MiB minus one page, <code>0x7FF000</code> is 8 MiB minus one page, and so on.

== Contents of a typical backup ==
The 32 segments of this image, with names from a community-maintained SLS address reference. Where the name column is blank, the segment's purpose has not been established.

{|class="wikitable"
!SLS address
!Length
!Name
|-
|<code>FFFFFFFFB1 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFFB2 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFFB3 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFFB5 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFFC1 000000</code>
|16 MiB
|Link Loader — LIC Code
|-
|<code>FFFFFFFFC2 000000</code>
|16 MiB
|Link Loader — LIC Data
|-
|<code>FFFFFFFFC3 000000</code>
|16 MiB
|Link Loader — LIC Code (2)
|-
|<code>FFFFFFFFC4 000000</code>
|16 MiB
|Link Loader — LIC Code (3)
|-
|<code>FFFFFFFFC5 000000</code>
|16 MiB
|Link Loader — LIC Code (4)
|-
|<code>FFFFFFFFC6 000000</code>
|8 MiB
|Link Loader — LIC Code (5)
|-
|<code>FFFFFFFFC7 000000</code>
|16 MiB
|Mixed — component code and NLS text pools
|-
|<code>FFFFFFFFC8 000000</code>
|8 MiB
|Mixed — bignum/JVM code and NLS text pools
|-
|<code>FFFFFFFFF1 000000</code>
|4 MiB
|Link Loader TOC
|-
|<code>FFFFFFFFF2 000000</code>
|16 MiB
|Service LID
|-
|<code>FFFFFFFFF4 000000</code>
|16 MiB
|Service LID (2)
|-
|<code>FFFFFFFFFE 000000</code>
|15 MiB
|Pageable BLA
|-
|<code>FFFFFFFFD1 000000</code>
|16 MiB
|Link Loader Information
|-
|<code>FFFFFFFFD2 000000</code>
|16 MiB
|Link Loader Information, Code, Data
|-
|<code>FFFFFFFFD3 000000</code>
|16 MiB
|Link Loader Information (2)
|-
|<code>FFFFFFFFD4 000000</code>
|16 MiB
|Mixed — JVM strings and DST debug symbol table
|-
|<code>FFFFFFFF90 010000</code>
|60 KiB
|LID Directory
|-
|<code>FFFFFFFF91 000000</code>
|16 MiB
|LID NUC2 A-Side
|-
|<code>FFFFFFFF92 000000</code>
|16 MiB
|LID NUC2 B-Side
|-
|<code>FFFFFFFF93 000000</code>
|16 MiB
|LID NUC1 A-Side
|-
|<code>FFFFFFFF94 000000</code>
|16 MiB
|LID NUC1 B-Side
|-
|<code>FFFFFFFF95 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFF96 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFF9A 000000</code>
|8 MiB
|
|-
|<code>FFFFFFFF9B 000000</code>
|8 MiB
|
|-
|<code>FFFFFFFFA1 000000</code>
|16 MiB
|LID Manager
|-
|<code>FFFFFFFFA2 000000</code>
|16 MiB
|
|-
|<code>FFFFFFFF69 000000</code>
|16 MiB
|IDE
|}

So a backup of this shape is the SLIC boot and loader nucleus: link loader code and data, the loader's table of contents, the LID subsystem's own bookkeeping, and both IPL sides of the two nucleus LIDs. It is not the whole of the machine's code.

=== A and B sides ===
Several segments appear twice, distinguished as ''A-side'' and ''B-side''. An AS/400 keeps two copies of its Licensed Internal Code so that an update can be applied to one while the other remains a fallback. A normal, unattended IPL runs the '''B side''', so B is what a running machine is executing and B is what static analysis should be done against. Because the two sides are normally near-identical, a byte comparison against the A side is not evidence that A is the live one — the test only means something on a segment that actually differs between them.

== Two directories, two granularities ==
A common source of confusion is that <code>QFILEMCD</code> appears to have two completely different directory formats. It does, and they nest:

* The '''coarse''' level is <code>COPYDIR</code>'s own directory, documented above: 64-byte entries, one per 16 MiB-class memory segment, 32 of them.
* The '''fine''' level is a catalogue of individual LIDs, thousands of entries, using the 32-byte record described at [[Data Structures:LID]].

The fine level is not a second header in the file. It is simply '''the contents of one particular segment''' — the one named ''LID Directory'', at <code>FFFFFFFF90 010000</code>. Extract that segment and you find, after a preamble of about 1536 bytes, an EBCDIC <code>Directory.</code> eyecatcher, a version label, and then the records. In this image the label reads <code>v4r4m01204.0.03</code>, which is the same label carried by [[System Files:QFILEIML]] — a quick way to confirm that two files came off the same media.

That is also why tools which dump this file emit two dissimilar-looking listings: a short table of large memory extents, and a long list of LIDs. They are two levels of one structure, not two formats.

== Extracting a segment ==
The practical recipe, and the reason this file is worth knowing about:

# Read the <code>COPYDIR</code> eyecatcher at offset 0 to confirm the format.
# Find the directory by scanning 64-byte-aligned offsets for the first entry-shaped block, rather than assuming <code>0xC0</code> or <code>0x1C0</code>.
# Walk entries until the flags field has <code>0xF</code> in its '''top''' nibble.
# For the segment you want, seek to the data offset '''as an absolute file offset''' and read ''length'' raw bytes.
# Load the result at its SLS address in a disassembler. The bytes are what the link loader maps, so addresses match.

Step 5 is the payoff. A 64-bit address such as <code>FFFFFFFFC6 1F1690</code> can be typed straight into the DST ''Display/Alter storage'' panel on a live machine of the same build, and the sixteen rows it displays will match the extracted file byte for byte. Static and live analysis share one address space, which means you can do the slow work offline and use the machine only for confirmation.

Two caveats on addresses. They are per-'''build''', not per-release, so comparisons are only meaningful between identical builds; the same class sits at a quite different address on a V5R4 machine. And the SLS address recorded in the directory is the address the segment was '''saved from''', which is not always where it runs — the resident nucleus segment, for instance, is stored in the container under the SID of the B-side nucleus LID rather than its runtime SID.

== Reading the code ==
Once a segment is loaded, two structures make it navigable, and both are worth knowing because they turn addresses into names:

* '''Traceback trailers.''' Every compilation unit ends its code with a <code>TBTB</code> trailer, and many carry the module's name. A trailer names a whole compilation unit rather than a single function, so a hit means "this address is inside module X", not "this address is function X".
* '''Link-loader descriptor blocks.''' Considerably richer: one block per procedure, carrying the entry address at <code>+0x08</code> and the name in EBCDIC at <code>+0x38</code>. Names beginning with <code>#</code> are SLIC-internal modules; the rest are C++ mangled symbols.

Merging both across every segment of this V4R4 image yields roughly 184,000 named records, which is enough to name a substantial fraction of any address you encounter. See [[SRC]] for how to use that to get from a reference code back to a module.

Calls between modules do not go through a conventional dispatch table, which surprises people disassembling SLIC for the first time. An external call is a two-instruction sequence — <code>ori r11,r13,''ordinal''</code> followed by <code>bla</code> into a transfer vector at the very top of the address space — and the 16-byte stub it lands on computes the target arithmetically. There is no table to read off; the ordinal ''is'' the callee's word offset within a window, and the stub supplies the window. The stub constants cannot be derived and must be read from a dump of the transfer vector.

== The trailing page ==
The payload area ends at <code>0x1C2F0000</code>, but the file is one 4 KiB page longer than that. The final page is not padding: it holds 468 non-zero 8-byte records, which appear to be address-and-value pairs.

They fall into two clear populations. The first 110 are in ascending address order with a value of 8, addressing the ''Link Loader — LIC Data'' segment among others. The remaining 256 are identical to each other: the same address <code>0xFE911220</code>, in the ''Pageable BLA'' segment, paired with the value <code>0x48000002</code> — which as PowerPC is a branch-absolute to zero, the shape of a deliberately poisoned entry.

This has the flavour of a fixup or relocation list applied after the segments are restored, but that is a guess from shape alone. It is recorded here because it is real, reproducible and unexplained, and because a parser that assumes the file ends with the payload will silently ignore it.

== Open questions ==
* The purpose of the trailing page.
* The header bytes other than the eyecatcher, size field, release string and banner.
* The meaning of the segment attribute field's top 16 bits, which take values <code>0x0001</code>, <code>0x0040</code>, <code>0x0080</code> and <code>0x0100</code> and correlate loosely with segment size.
* Names for the nine segments left blank in the table above.

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

== Footnotes ==
<references />

[[Category: System Internals]]

System Files:QFILEIML

2026-08-08T16:57:53Z

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

Data Structures:LID

2026-08-08T16:57:06Z

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

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]]