System Internals:SLIC DASD device recognition

This article has been generated or amended by AI and not yet been checked for correctness.

The SLIC DASD device recognition table is the static list, inside the OS/400 Licensed Internal Code (SLIC), of which SCSI disk drives the system will accept as a DASD (disk) unit. This page describes how that recognition works, how to find and decode the table in a SLIC image, and — as a worked example — the complete list a V4R4 machine accepts. The method generalises to any release and to other SLIC device tables.

Understanding it matters for preservation: OS/400 refuses ordinary SCSI disks, so keeping a machine alive after a disk failure means presenting a drive (real or emulated) that answers the SCSI bus the way SLIC expects.

How SLIC decides a disk is acceptable

A disk becomes an eligible DASD unit only if it passes three independent gates, all implemented in the SLIC disk device driver:

1. SCSI INQUIRY must match a static table. SLIC compares the drive's INQUIRY vendor id (bytes 8–15) and product id (bytes 16–31) against a built-in table. Only IBM-badged units qualify: the vendor id is normally IBMAS400 (a handful of early units use IBM␠␠␠␠␠ and two OEM units use QUANTUM␠). An off-the-shelf drive reports its own vendor and is rejected. This is exactly what the "custom firmware" on IBM's 660x/671x disks does: IBM reflashed standard Ultrastar/Corsair mechanisms to answer INQUIRY with an IBM vendor id and an IBM product id.
2. Vendor-unique SKIP READ / SKIP WRITE. The driver issues IBM vendor-unique SCSI commands that read or write a run of sectors while skipping masked ones, used by the Single-Level Store paging path. A faithful drive must implement these, not just standard READ/WRITE.
3. Capacity from VPD. The unit's size is taken at run time from the drive's Vital Product Data / READ CAPACITY, not from the table — the table has no capacity column. An impersonating drive must report a capacity that is legal for the feature type it claims.

Finding and decoding the table

In a SLIC image the table is a run of fixed-size records. On V4R4 each record is 40 bytes:

bytes  0- 3  feature type    EBCDIC digits, e.g. F6F6F0F7 = "6607"
bytes  4- 5  model           EBCDIC, e.g. "1 "
byte      6  class flag      0x00 normal; 0x80 on the 18 GB Ultra2/LVD units
bytes  7-15  reserved        0x40 (EBCDIC space) padding
bytes 16-23  INQUIRY vendor  ASCII, matched against INQUIRY bytes 8-15
bytes 24-39  INQUIRY product ASCII, matched against INQUIRY bytes 16-31

The type and model are EBCDIC (digit n = byte 0xFn); the INQUIRY strings are ASCII. To locate the table, search the image for the ASCII vendor strings IBMAS400 / QUANTUM␠: the records sit at a fixed 40-byte stride around them. The same trick — anchor on a known ASCII string, then read the fixed-width record around it — recovers other SLIC hardware tables (IOP/controller CCIN tables, adapter tables, and so on).

The V4R4 list

Every drive a V4R4 system accepts, decoded from the image.

Feature/Model
6109 / 0
6109 / 1
6105 / 0
6107 / 0
6603 / 0
6603 / 1
6602 / 0
6602 / 1
6605 / 1
6606 / 1
6607 / 1
6713 / 1
6714 / 1
6717 / 1
6730 / 0
6731 / 0

Notes

• "Ide" in SLIC symbol names (e.g. the driver classes handling these disks) is the disk device-driver namespace, not ATA/IDE.
• Numbers like 2748, 6502, 6512, 6751, 6753, 6754 that appear on other SLIC symbols are IOP / disk-controller CCINs, not drive models.
• An emulated target (for example on open SCSI-emulator firmware) must present one of the vendor+product pairs above verbatim, space-padded to the SCSI field widths, implement the vendor-unique SKIP commands, and report a legal capacity via READ CAPACITY.