MR> Which is more likely, that in rare cases the above would not read LSN
 MR> 16 at all, or that in rare cases the SuperBlock doesn't reside at LSN
 MR> 16 at all?

The former.

As I said before, when one opens a volume for reading using category 0x08
DosDevIOCtl, logical sector 0 is in fact the start of the "drive" that
contains the volume.  This sector contains the MBR for that "drive".  

For primary partitions, this "drive" is the actual physical drive and the MBR
is the primary MBR.  The first primary partition usually starts on the next
track boundary (because FDISK utilities try to align partitions on track
boundaries).  This was the cause of your previous problem.

For secondary partitions, the "drive" is the "logical drive" (defined by a
type 0x05/0x0F entry in the preceding MBR) containing the volume, and the MBR
is the secondary MBR at the start of that "logical drive" that both defines
any volumes within that "logical drive" and points to the next logical drive
(and secondary MBR) in the partition table chain.

By convention there is only one actual volume per "logical drive".  Only two
of the entries in the MBR at the start of the "logical drive" are used (one
for the type 0x05/0x0F entry pointing to the next MBR).  But there can be many 
volumes in the "drive" that encompasses the physical disc -- the one that
starts with the primary MBR and that one sees when one attempts to access a
volume that is a primary partition.

Primary partitions apart from the first start further along within the
"drive".  In the case where the first primary partition is Boot Manager and
the actual volume is the second primary partition, for example, the start of
the area visible via category 0x08 will be the primary MBR and the whole of
the Boot Manager partition is visible before the actual volume.  (On my
machine, this is in fact the case, and in the Graham Utilities' DISKEDIT to
edit the boot sector of drive C:, logical block 0 of the volume, I have to
skip 16065 logical sectors from the start of the "drive".)

This is why on some machines you are seeing Boot Manager code.  You are
skipping one track to locate what you believe to be the start of the volume
that you want, but this is taking you to the Boot Manager partition.  Sector
16 within that partition thus contains Boot Manager code/data.

For generic code that should work in all situations, therefore, what one has
to do is to locate the actual volume within the "drive" by scanning the MBR at 
its start (logical sector 0 in the area accessible to you).   One checks that
the drive is partitionable and that the MBR contains a valid partition table,
and if it is one scans the four partition table entries in the MBR for an
entry with the correct type (i.e. skip Boot Manager, type 0x0A, and extended
partition, type 0x05/0x0F, entries) and uses the sector offset field of that
entry to locate the actual start of the volume.

As you have found, however, asking the operating system for the BPB does this
for you, since the operating system has itself already done all of this work
when OS2DASD.DMD read the partition table during initialisation.

If these mechanics still aren't clear, crank up DISKEDIT from the Graham
Utilities, or use PARTLIST from the OS/2 Command Line Utilities version 2.0
(OS2CLU02.ZIP), and have a look at the raw structure of the partition "table".

 ¯ JdeBP ®

--- FleetStreet 1.22 NR