Each LU contains certain required files. As a fairly typical example,
the following table shows the general layout of a Diablo 31 drive LU0.
|4||INDEX||1st Index data|
|17||(swap)||Discusbs swap area|
|20||(swap)||Discusbs swap area|
|21||(swap)||Discusbs swap area|
|22||(swap)||Discusbs swap area|
|23||(swap)||Discusbs swap area|
|24||(swap)||Discusbs swap area|
|25||??||from here on anything goes|
Every LU regardless of drive, assigns RDA 0, 1, and 3 as shown.
LU0 requires the REX header to be in RDA 2. REX is the Real Time Executive (what Unix would call the Kernal).
The boot sector’s job is to load the REX header into memory and pass control to a small executable loop in the REX header which uses the boot driver to load the rest of REX into memory.
INDEX contains one record for every file on the disk, each record consisting of the name and header RDA.
The ACCOUNTS file keeps track of users who can LOGIN, run programs, and save files on a given LU. The LU0 file includes all users, and is used to verify logins, track # blocks assigned to each account, etc.
Every LU has a DMAP file (Disk Map) which keeps track of what blocks are in use and which are available.The DMAP header is always on Cylinder 0, Track 1, Sector 0, and is always hybrid in format (random design with contiguous RDA’s). But since different drives have different numbers of sectors per track, the RDA of the DMAP header will vary from one model drive to another.The DMAP will also vary in size, depending on how many blocks are on the LU.
LU0 also reserves 6 blocks immediately following DMAP to hold nested DISCSUB blocks. Other LU’s would have these available for any other file. These blocks must be contiguous. However, they not considered to be a read file, and do not have a header or an INDEX entry.
Migrating from One Drive Type to Another
In theory, one could back up an LU on one drive type and restore it on another drive type with different physical characteristics, setup the correct disk driver routine, and everything would run normally since the RDA’s are independent of the number of cylinders, tracks, and sectors.
However, if the two drives have a different size tracks (ie. number of sectors per track) then the system will expect DMAP to begin at a different RDA (track 1, sector 0). Whatever files currently occupy the target RDA’s for DMAP (and on LU 0, the discsub nesting area) would need to move.
The second biggest challenge is that DMAP could grow in size if the target LU is considerably larger, since it maps all RDA’s on the LU. Any allocated blocks that follow the original DMAP would need to be moved or else they would get overwritten.
Moving part of any file, including DMAP also requires updating the file header. If the header block is moved to a different RDA, the INDEX entry (which could be in any block of the INDEX file) must be updated.
Complicating this is the fact that the LU0 DMAP is rebuilt and written to disk with every IPL, and DMAP on installed LU’s is rebuilt with every INSTALL. So any needed space must be created prior to the migration.
These challenges are why migration was never easy, and no one to my knowledge ever created utilities to make this any better. In the early days, you had to get out your paper tape reader and to a complete Sysgen from scratch. Otherwise, you had to hire Point 4 (EDS) or a specialist to perform the migration.
On our version of IRIS 7.5, we have written a special program XGEN that helps with migration, although as of Sept. 2017 it still cannot perform the entire task. In particular, it helps with binary files that were recovered from QIC tapes, converting them to working logical units.