System Internals:SLIC DASD device recognition: Difference between revisions

From Try-AS/400
Jump to navigation Jump to search
+cat
±Cat/AI heading
 
Line 1: Line 1:
{{AI generated not reviewed}}
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.
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.


Line 75: Line 76:


[[Category:System Internals]]
[[Category:System Internals]]
[[Category:AI generated not reviewed]]

Latest revision as of 21:22, 16 August 2026

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. "Physical drive" is identification from IBM/Quantum model nomenclature, not read from the binary; the feature type, model and INQUIRY strings are.

Feature/Model INQUIRY vendor INQUIRY product Physical drive
6109 / 0 IBM␠␠␠␠␠ 0663H12 IBM 0663 "Corsair", ~2 GB
6109 / 1 IBM␠␠␠␠␠ 0661371 IBM 0661 "Pixie", ~0.37 GB
6105 / 0 IBM␠␠␠␠␠ 0661467 IBM 0661 "Pixie", ~0.47 GB
6107 / 0 IBMAS400 0664M1H IBM 0664 "Corsair-4", ~4 GB
6603 / 0 IBMAS400 0664N1H IBM 0664 "Corsair-4", ~4 GB
6603 / 1 IBMAS400 0662S12 IBM 0662 "Corsair", ~1.2 GB
6602 / 0 IBMAS400 0662SW1 IBM 0662 "Corsair", ~1.0 GB
6602 / 1 IBMAS400 DFHSS1W IBM Ultrastar XP, ~1 GB
6605 / 1 IBMAS400 DFHSS2W IBM Ultrastar XP, ~2 GB
6606 / 1 IBMAS400 DFHSS4W IBM Ultrastar XP, ~4 GB
6607 / 1 IBMAS400 DCHS09W IBM Ultrastar 2XP, ~9 GB
6713 / 1 IBMAS400 DGHS18U IBM Ultrastar 18XP, ~18 GB
6714 / 1 IBMAS400 DGVS09U IBM Ultrastar 9ES/9LZX, ~9 GB
6717 / 1 QUANTUM␠ SSQD107 Quantum, ~10.7 GB
6730 / 0 QUANTUM␠ SSQD160 Quantum, ~16.0 GB
6731 / 0 IBMAS400 DRVS18D IBM Ultrastar 18ES/18LZX, ~18 GB, Ultra2/LVD

Feature-type numbers do not track capacity linearly: the type encodes the AS/400 usable-capacity class (after 520-byte-sector overhead), not the drive's native size. The much-cited 6607 is here as IBMAS400 / DCHS09W.

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.