[Info-vax] ISAM on disk layout. Was: Re: HP wins Oracle Itanium case

[Jan-Erik Soderholm]

abrsvc wrote 2012-08-29 18:14:
> On Wednesday, August 29, 2012 11:45:02 AM UTC-4, Paul Sture wrote:
>> On Tue, 28 Aug 2012 20:12:38 +0000, glen herrmannsfeldt wrote: >
>> Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote: >> On 2012-08-28
>> 16:58:35 +0000, Bob Koehler said: > >>> Blows away folks when I access
>> a keyed-indexed file "sequentially". > >> You're either being humored
>> with that "blown away", or you're >> discussing this with folks that
>> are ignorant of how databases work. >> What you're discussing goes
>> back to the S in the IBM Indexed Sequential >> Access Method ISAM
>> scheme, and which well predates RMS. > > And which uses IBM CKD (Count
>> Key Data) disks where keys are written > before data blocks on the
>> disk. You can ask the disk hardware to search > for a block with a
>> given key, or with a key greater than or equal to the > given key.
>> (The index is sorted to make the search easier.) > > ISAM files are
>> also interesting in that the index contains disk block > addresses
>> such that the files are unmovable. (There are special programs > that
>> know how to backup and restore an ISAM file, and rewrite the index >
>> as needed.) This highlights a problem with RMS. On mainframe systems I
>> was used to placing files carefully on disk, aligning by cylinder etc.
>> I cannot remember whether the compatibility mode RMS utilities (IFL -
>> Initial File Load and friends) could do file placement, but once FDL
>> came along you could. However, another black mark for BACKUP/IMAGE was
>> that it doesn't honour FDL file placement. If you were going to use
>> FDL's file placement functionality, you had better not use
>> BACKUP/IMAGE. We chose to ignore file placement in favour of the
>> convenience BACKUP/IMAGE brought us for defragmenting disks. -- Paul
>> Sture
>
> The "smart" controllers also made file placement less important.  The
> UDA50 was the first to "re-order" disk reads such that the heads moved
> in one direction to collect the data rather than the "normal" in-out
> movement.  I recall testing this with the 780 and confirmed that for
> small reads (1-3 blocks) the Unibus outperformed the Massbus even though
> the transfer rate for the Massbus was twice as fast.
>
> Dan
>

Even more so in todays SAN's where you get a number of "gigs"
out of some undefined disk array. Placement of files, as in
MVS and other older systems, is mostly an non-issue today,
from a performance standpoint. The fact that MVS still needs
BLOCKSIZE, LRECL and so on, is mostly a compatibility issue.

Jan-Erik.