I have a Charon-VAX disk image of an RZ59 which I am trying to use on SimH v3.9.

I can configure the disk in the SimH ini file using "set rq0 rauser=9114" which should (?) indicate that it is a 8.9GB storage device. When I start OpenVMS 7.3 I can mount the disk, but it is full of read errors... other Charon-VAX disks (all less than or equal to 2GB) are fine.

I think there is a problem with the disk geometry... SimH $show dev/fu shows the disk as an RA82 with:
Total blocks 17755614
Sectors per track 57
Total cylinders 20767
Tracks per cylinder 15

While on the "real" Charon-VAX, it is:
Total blocks 17755614
Sectors per track 193
Total cylinders 5111
Tracks per cylinder 18

Is there some magic incantation in SimH to specify disk geometry?

Gremlin,

could you be a little bit more specififc than 'full of read errors' ? Maybe post some messages from ANALYZE/DISK/READ ? OpenVMS VAX version used ?

Volker.

On Sunday, 1 May 2022 at 15:09:54 UTC+10, Volker Halle wrote:
> Gremlin,
>
> could you be a little bit more specififc than 'full of read errors' ? Maybe post some messages from ANALYZE/DISK/READ ? OpenVMS VAX version used ?
>
> Volker.
VAX/VMS 7.3 on SimH trying to use an disk image from VAX/VMS 7.1

On SimH:
mou/over=id $2$dub2
%MOUNT-W-VOLSHDWMEM, mounting a shadow set member volume; volume write locked
%MOUNT-F-BADSECSYS, failed to create or access SECURITY.SYS
-SYSTEM-W-BADIRECTORY, bad directory file format

It was copied when the system was gracefully shut down, all the other shadow set copied disks mount without error, but they are all under 2GB...

Did a mount/over=sec and I get...

$sho dev/fu $2$dub2

Disk $2$DUB2: (VAXB), device type RA82, is online, allocated, deallocate on
dismount, mounted, software write-locked, file-oriented device, shareable,
served to cluster via MSCP Server, error logging is enabled.
Error count 0 Operations completed 33
Owner process "GREMLIN" Owner UIC [SYSTEM]
Owner process ID 20E00220 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 2 Default buffer size 512
Total blocks 17755614 Sectors per track 57
Total cylinders 20767 Tracks per cylinder 15
Allocation class 2
Volume label "USER" Relative volume number 0
Cluster size 17 Transaction count 1
Free blocks 744379 Maximum files allowed 800000
Extend quantity 5 Mount count 1
Mount status Process Cache name "_$2$DUA0:XQPCACHE"
Extent cache size 64 Maximum blocks in extent cache 74437
File ID cache size 64 Blocks currently in extent cache 0
Quota cache size 0 Maximum buffers in FCP cache 1283
Min ret. period 18-00:00:00.00 Max ret. period 23-00:00:00.00
Volume owner UIC [1,1] Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD
Volume Status: ODS-2, subject to mount verification, write-back caching
enabled.

Running analyze/disk gives lots of -ANALDISK-I-BAD_DIRSIZE and -ANALDISK-I-BAD_DIRTYPE - ... definitely size related...

Gremlin,

if you want and/or can, you could change the disk geometry on the CHARON-VAX to reflect what SimH is setting up as the geometry and see, if the same errors then also show up on CHARON-VAX. The geometry information is not stored in the .vdisk file, it's being 'made up' by the emulator.

set dub geometry[2]="57/15/20767"

Does ANALYZE/DISK/READ complain about every directory on the disk ? Just provide an example of the real messages...

Volker.

On Sunday, 1 May 2022 at 16:41:53 UTC+10, Volker Halle wrote:
> Gremlin,
>
> if you want and/or can, you could change the disk geometry on the CHARON-VAX to reflect what SimH is setting up as the geometry and see, if the same errors then also show up on CHARON-VAX. The geometry information is not stored in the .vdisk file, it's being 'made up' by the emulator.
>
> set dub geometry[2]="57/15/20767"
>
> Does ANALYZE/DISK/READ complain about every directory on the disk ? Just provide an example of the real messages...
>
> Volker.
I can't change anything on the CHARON-VAX installation as it is a production site. Although the ANALYZE/DISK errors may be interesting, the *,ain* issue is that SimH has the disk geometry all wrong and therefore ANALYZE/DISK will produce errors as well as the disk being unusable. Before anything else I need to get the disk geometry correct on SimH.

So... how to do that?

On Sunday, 1 May 2022 at 16:49:13 UTC+10, Gremlin wrote:
> On Sunday, 1 May 2022 at 16:41:53 UTC+10, Volker Halle wrote:
> > Gremlin,
> >
> > if you want and/or can, you could change the disk geometry on the CHARON-VAX to reflect what SimH is setting up as the geometry and see, if the same errors then also show up on CHARON-VAX. The geometry information is not stored in the .vdisk file, it's being 'made up' by the emulator.
> >
> > set dub geometry[2]="57/15/20767"
> >
> > Does ANALYZE/DISK/READ complain about every directory on the disk ? Just provide an example of the real messages...
> >
> > Volker.
> I can't change anything on the CHARON-VAX installation as it is a production site. Although the ANALYZE/DISK errors may be interesting, the *,ain* issue is that SimH has the disk geometry all wrong and therefore ANALYZE/DISK will produce errors as well as the disk being unusable. Before anything else I need to get the disk geometry correct on SimH.
>
> So... how to do that?

Here's some output...

Analyze/Disk_Structure for _$2$DUB2: started on 1-MAY-2022 17:24:45.04

%ANALDISK-W-CHKSCB, invalid storage control block, RVN 1
%ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS
-SYSTEM-W-BADIRECTORY, bad directory file format
%ANALDISK-W-INVEXTBACK, file (3534,9571,0)
invalid extension file header back link
%ANALDISK-W-DELHEADER, file (6468,3775,0) SQS_ECVAX1_DATABA0110006.COM;1
marked for delete
%ANALDISK-W-BADHEADER, file (6479,175,0)
invalid file header
-ANALDISK-I-HEADER_DEL, deleted file header
-ANALDISK-I-DELHEADER_BUSY, deleted file header marked "busy"
in index file bitmap
%ANALDISK-W-DELHEADER, file (9746,8055,0) KEUNG.JPL;1
marked for delete
%ANALDISK-W-DELHEADER, file (10857,377,0) SQS_ECVAX1_INVENT0150001.COM;1
marked for delete
%ANALDISK-W-BADHEADER, file (11066,7,0)
invalid file header
-ANALDISK-I-HEADER_DEL, deleted file header
-ANALDISK-I-DELHEADER_BUSY, deleted file header marked "busy"
in index file bitmap
%ANALDISK-W-BADHEADER, file (11093,55,0)
invalid file header
-ANALDISK-I-HEADER_DEL, deleted file header
-ANALDISK-I-DELHEADER_BUSY, deleted file header marked "busy"
in index file bitmap
%ANALDISK-W-BADHEADER, file (11113,188,0)
invalid file header
-ANALDISK-I-HEADER_DEL, deleted file header
-ANALDISK-I-DELHEADER_BUSY, deleted file header marked "busy"
in index file bitmap
%ANALDISK-W-BADHEADER, file (11126,258,0)
invalid file header
-ANALDISK-I-HEADER_DEL, deleted file header
-ANALDISK-I-DELHEADER_BUSY, deleted file header marked "busy"
in index file bitmap
%ANALDISK-W-BADHEADER, file (11132,517,0)
invalid file header
-ANALDISK-I-HEADER_DEL, deleted file header
-ANALDISK-I-DELHEADER_BUSY, deleted file header marked "busy"
in index file bitmap
%ANALDISK-W-BADHEADER, file (11196,630,0)
invalid file header
-ANALDISK-I-HEADER_DEL, deleted file header
-ANALDISK-I-DELHEADER_BUSY, deleted file header marked "busy"
in index file bitmap
%ANALDISK-W-DELHEADER, file (11209,376,0) SQS_ECVAX1_DETFAU00P0005.COM;3
marked for delete
%ANALDISK-W-BADHEADER, file (11238,955,0)
invalid file header
-ANALDISK-I-HEADER_DEL, deleted file header
-ANALDISK-I-DELHEADER_BUSY, deleted file header marked "busy"
in index file bitmap
%ANALDISK-W-BADHEADER, file (11275,3543,0)
invalid file header
-ANALDISK-I-HEADER_DEL, deleted file header
-ANALDISK-I-DELHEADER_BUSY, deleted file header marked "busy"
in index file bitmap
%ANALDISK-W-BADHEADER, file (11277,260,0)
invalid file header
-ANALDISK-I-FIDNUM_ZERO, file number zero but not a valid deleted header
-ANALDISK-I-INVHEADER_BUSY, invalid file header marked "busy"
in index file bitmap
%ANALDISK-W-BADHEADER, file (11367,307,0)
invalid file header
-ANALDISK-I-HEADER_DEL, deleted file header
-ANALDISK-I-DELHEADER_BUSY, deleted file header marked "busy"
in index file bitmap

I think incorrect geometry will cause all these...

Gremlin,

OpenVMS does not care much about disk geometry, except in some cases relating to file placement. Did you run ANALYZE/DISK on the original disk ? Do you see the same error messages ?

If you believe, there is a problem caused by geometry on SimH, why not dump some specific blocks of the CHARON-VAX disk and on SimH and compare the results ? DUMP disk:/BLOCK=(START=nnnn,COUNT=1) ?

The CHKSCB message indicates a possible problem with the SCB (Storage Control Block). That block is the first block of the Storage Bitmap, i.e. [000000]BITMAP.SYS.

$ dump disk-on-CHARON:[000000]bitmap.sys/header/bl=count=1

will give you the location of the SCB (from the file header)

Map area
Retrieval pointers
Count: 90 LBN: nnnnnnnn

and also the contents of the 1st block of that file - the SCB.

Now on SimH, try:

$ DUMP disk-on-simh:/BL=(start=nnnnnnnn,COUNT=1)

Same contents as shown on CHARON-VAX ?

Volker.

On Sunday, May 1, 2022 at 1:56:05 AM UTC-7, Volker Halle wrote:
> Gremlin,
>
> OpenVMS does not care much about disk geometry, except in some cases relating
> to file placement. Did you run ANALYZE/DISK on the original disk ? Do you see the same error messages ?

I remember in the early days of using SCSI disks with Unix systems, we had to
make up disk geometry. The only important thing was getting the total number of
sectors right.

The product of the numbers above for Simh doesn't give the right
total number of sectors. If it is using those, and tries to find a sector
that doesn't exist, there could be disk errors.

On 5/1/2022 1:36 AM, Gremlin wrote:
> On Sunday, 1 May 2022 at 15:09:54 UTC+10, Volker Halle wrote:
>> Gremlin,
>>
>> could you be a little bit more specififc than 'full of read errors' ? Maybe post some messages from ANALYZE/DISK/READ ? OpenVMS VAX version used ?
>>
>> Volker.
> VAX/VMS 7.3 on SimH trying to use an disk image from VAX/VMS 7.1
>
> On SimH:
> mou/over=id $2$dub2
> %MOUNT-W-VOLSHDWMEM, mounting a shadow set member volume; volume write locked
> %MOUNT-F-BADSECSYS, failed to create or access SECURITY.SYS
> -SYSTEM-W-BADIRECTORY, bad directory file format

It's been a while, and my memory isn't always so good, but I believe that
VAX/VMS V7.2 had some changes to directories. Never heard of a problem using
disks from prior versions.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2022-05-01, Gremlin <milton.baar@gmail.com> wrote:
> On Sunday, 1 May 2022 at 15:09:54 UTC+10, Volker Halle wrote:
>> Gremlin,
>>
>> could you be a little bit more specififc than 'full of read errors' ? Maybe post some messages from ANALYZE/DISK/READ ? OpenVMS VAX version used ?
>>
>> Volker.
> VAX/VMS 7.3 on SimH trying to use an disk image from VAX/VMS 7.1
>
> On SimH:
> mou/over=id $2$dub2
> %MOUNT-W-VOLSHDWMEM, mounting a shadow set member volume; volume write locked
> %MOUNT-F-BADSECSYS, failed to create or access SECURITY.SYS
> -SYSTEM-W-BADIRECTORY, bad directory file format
>
> It was copied when the system was gracefully shut down, all the other shadow set copied disks mount without error, but they are all under 2GB...
>

_How_ exactly was it copied ?

On the disks that work ok, does the disk geometry match or is it
different ?

If it's different for the working disks and they still work, then that
might indicate the geometry isn't the problem.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-05-01 04:46, Gremlin wrote:
> I have a Charon-VAX disk image of an RZ59 which I am trying to use on SimH v3.9.
>
> I can configure the disk in the SimH ini file using "set rq0 rauser=9114" which should (?) indicate that it is a 8.9GB storage device. When I start OpenVMS 7.3 I can mount the disk, but it is full of read errors... other Charon-VAX disks (all less than or equal to 2GB) are fine.
>
> I think there is a problem with the disk geometry... SimH $show dev/fu shows the disk as an RA82 with:
> Total blocks 17755614
> Sectors per track 57
> Total cylinders 20767
> Tracks per cylinder 15
>
> While on the "real" Charon-VAX, it is:
> Total blocks 17755614
> Sectors per track 193
> Total cylinders 5111
> Tracks per cylinder 18
>
> Is there some magic incantation in SimH to specify disk geometry?

Disk geometry is just arbitrary information with no impact here. Your
problem is something else.

A SCSI disk (or MSCP) is just a stream of blocks numbered from 0 to n-1.

What you absolutely need to do is make sure the number of blocks are
identical (well, you could have extra, that won't hurt you), otherwise
you will be screwed.

But first of all, you also need to check that simh, and the OS you are
using, allows files larger than 2G, or else you'll never succeed here.

This might even require some options when you build simh...

Johnny

On Sunday, 1 May 2022 at 23:58:05 UTC+10, Simon Clubley wrote:
> On 2022-05-01, Gremlin <milto...@gmail.com> wrote:
> > On Sunday, 1 May 2022 at 15:09:54 UTC+10, Volker Halle wrote:
> >> Gremlin,
> >>
> >> could you be a little bit more specififc than 'full of read errors' ? Maybe post some messages from ANALYZE/DISK/READ ? OpenVMS VAX version used ?
> >>
> >> Volker.
> > VAX/VMS 7.3 on SimH trying to use an disk image from VAX/VMS 7.1
> >
> > On SimH:
> > mou/over=id $2$dub2
> > %MOUNT-W-VOLSHDWMEM, mounting a shadow set member volume; volume write locked
> > %MOUNT-F-BADSECSYS, failed to create or access SECURITY.SYS
> > -SYSTEM-W-BADIRECTORY, bad directory file format
> >
> > It was copied when the system was gracefully shut down, all the other shadow set copied disks mount without error, but they are all under 2GB...
> >
> _How_ exactly was it copied ?
>
> On the disks that work ok, does the disk geometry match or is it
> different ?
>
> If it's different for the working disks and they still work, then that
> might indicate the geometry isn't the problem.
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
" _How_ exactly was it copied ? "

On the Charon emulator, OpenVMS was gracefully shutdown, Charon was closed, vdisks were copied to USB. Charon restarted, OpenVMS restarted, emulated system still happily running... All copied disks other than those >2GB can be read fine on SimH.

On Monday, 2 May 2022 at 04:51:46 UTC+10, Johnny Billquist wrote:
> On 2022-05-01 04:46, Gremlin wrote:
> > I have a Charon-VAX disk image of an RZ59 which I am trying to use on SimH v3.9.
> >
> > I can configure the disk in the SimH ini file using "set rq0 rauser=9114" which should (?) indicate that it is a 8.9GB storage device. When I start OpenVMS 7.3 I can mount the disk, but it is full of read errors... other Charon-VAX disks (all less than or equal to 2GB) are fine.
> >
> > I think there is a problem with the disk geometry... SimH $show dev/fu shows the disk as an RA82 with:
> > Total blocks 17755614
> > Sectors per track 57
> > Total cylinders 20767
> > Tracks per cylinder 15
> >
> > While on the "real" Charon-VAX, it is:
> > Total blocks 17755614
> > Sectors per track 193
> > Total cylinders 5111
> > Tracks per cylinder 18
> >
> > Is there some magic incantation in SimH to specify disk geometry?
> Disk geometry is just arbitrary information with no impact here. Your
> problem is something else.
>
> A SCSI disk (or MSCP) is just a stream of blocks numbered from 0 to n-1.
>
> What you absolutely need to do is make sure the number of blocks are
> identical (well, you could have extra, that won't hurt you), otherwise
> you will be screwed.
>
> But first of all, you also need to check that simh, and the OS you are
> using, allows files larger than 2G, or else you'll never succeed here.
>
> This might even require some options when you build simh...
>
> Johnny
"But first of all, you also need to check that simh, and the OS you are
> using, allows files larger than 2G, or else you'll never succeed here.
>
> This might even require some options when you build simh... "
Can't find anything in the user documentation... :(

On 01/05/2022 19:51, Johnny Billquist wrote:
> On 2022-05-01 04:46, Gremlin wrote:
>> I have a Charon-VAX disk image of an RZ59 which I am trying to use on
>> SimH v3.9.
>>
>> I can configure the disk in the SimH ini file using "set rq0
>> rauser=9114" which should (?) indicate that it is a 8.9GB storage
>> device.  When I start OpenVMS 7.3 I can mount the disk, but it is full
>> of read errors... other Charon-VAX disks (all less than or equal to
>> 2GB) are fine.
>>
>> I think there is a problem with the disk geometry... SimH $show dev/fu
>> shows the disk as an RA82 with:
>> Total blocks 17755614
>> Sectors per track 57
>> Total cylinders 20767
>> Tracks per cylinder 15
>>
>> While on the "real" Charon-VAX, it is:
>> Total blocks 17755614
>> Sectors per track 193
>> Total cylinders 5111
>> Tracks per cylinder 18
>>
>> Is there some magic incantation in SimH to specify disk geometry?
>
> Disk geometry is just arbitrary information with no impact here. Your
> problem is something else.
>
> A SCSI disk (or MSCP) is just a stream of blocks numbered from 0 to n-1.
>
> What you absolutely need to do is make sure the number of blocks are
> identical (well, you could have extra, that won't hurt you), otherwise
> you will be screwed.
>
> But first of all, you also need to check that simh, and the OS you are
> using, allows files larger than 2G, or else you'll never succeed here.
>
> This might even require some options when you build simh...
>
>   Johnny

The docs for SIMH 3.10

http://simh.trailing-edge.com/pdf/simh_doc.pdf

says:-

"The PDP-11 and VAX simulators optionally support disks and serial
devices files greater than 2GB. To include large device support, both
USE_INT64 and USE_ADDR64 must be defined as part of the compilation
command line"

so no mention of the Alpha simulator, and specific instructions on
building PDP-11 and VAX to include such support

Dave

On Monday, May 2, 2022 at 8:08:13 AM UTC+10, David Wade wrote:
> On 01/05/2022 19:51, Johnny Billquist wrote:
> > On 2022-05-01 04:46, Gremlin wrote:
> >> I have a Charon-VAX disk image of an RZ59 which I am trying to use on
> >> SimH v3.9.
> >>
> >> I can configure the disk in the SimH ini file using "set rq0
> >> rauser=9114" which should (?) indicate that it is a 8.9GB storage
> >> device. When I start OpenVMS 7.3 I can mount the disk, but it is full
> >> of read errors... other Charon-VAX disks (all less than or equal to
> >> 2GB) are fine.
> >>
> >> I think there is a problem with the disk geometry... SimH $show dev/fu
> >> shows the disk as an RA82 with:
> >> Total blocks 17755614
> >> Sectors per track 57
> >> Total cylinders 20767
> >> Tracks per cylinder 15
> >>
> >> While on the "real" Charon-VAX, it is:
> >> Total blocks 17755614
> >> Sectors per track 193
> >> Total cylinders 5111
> >> Tracks per cylinder 18
> >>
> >> Is there some magic incantation in SimH to specify disk geometry?
> >
> > Disk geometry is just arbitrary information with no impact here. Your
> > problem is something else.
> >
> > A SCSI disk (or MSCP) is just a stream of blocks numbered from 0 to n-1.
> >
> > What you absolutely need to do is make sure the number of blocks are
> > identical (well, you could have extra, that won't hurt you), otherwise
> > you will be screwed.
> >
> > But first of all, you also need to check that simh, and the OS you are
> > using, allows files larger than 2G, or else you'll never succeed here.
> >
> > This might even require some options when you build simh...
> >
> > Johnny
> The docs for SIMH 3.10
>
> http://simh.trailing-edge.com/pdf/simh_doc.pdf
>
> says:-
>
> "The PDP-11 and VAX simulators optionally support disks and serial
> devices files greater than 2GB. To include large device support, both
> USE_INT64 and USE_ADDR64 must be defined as part of the compilation
> command line"
>
> so no mention of the Alpha simulator, and specific instructions on
> building PDP-11 and VAX to include such support
>
> Dave

Thanks, will try recompiling the VAX with the additional compiler directives and see what happens :)

On 2022-05-01, David Wade <g4ugm@dave.invalid> wrote:
> The docs for SIMH 3.10
>
> http://simh.trailing-edge.com/pdf/simh_doc.pdf
>
> says:-
>
> "The PDP-11 and VAX simulators optionally support disks and serial
> devices files greater than 2GB. To include large device support, both
> USE_INT64 and USE_ADDR64 must be defined as part of the compilation
> command line"
>
> so no mention of the Alpha simulator, and specific instructions on
> building PDP-11 and VAX to include such support
>

The Alpha simulator in simh is not usable so that's probably why. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-05-01, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
> The Alpha simulator in simh is not usable so that's probably why. :-)
>

For anyone interested, the reason why the Alpha simulator is not
usable is because there are none of the devices implemented that
would be required in order to turn it into a full system emulator.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-05-01 02:46:06 +0000, Gremlin said:

> Is there some magic incantation in SimH to specify disk geometry?

The only remaining part of OpenVMS that cares about disk geometry was
part of the alternate home-block lookup support within mount-related
processing, and newer volume initialization no longer use geometry to
determine the alternate homeblock location, and updates for V8.0 made
the primary home block optional and all homeblocks are effectively now
if not actually alternates. The existing support was intended to find
alternates placed with an older algorithm.

Nowadays... if the mount logic is even looking for alternate home
blocks (past the first alternate, when there's no primary), the storage
is probably too badly corrupted to bother with.

And even on rotating media, the numbers of sectors per track can vary
by placement, so the CHS fields aren't sufficient to describe the
actual physical storage layout; C and S can now be variable, and H
isn't reliably one-per-arm-per-platter.

Most OpenVMS device drivers just made up geometry numbers, as the
fields involved were increasingly inadequate for even Y2K-era HDDs.

There was a discussion of removing the related APIs a while back, but
the APIs were preserved for compatibility; some app was going to be
doing something "important" with HDD geometry "for reasons", and that
app would break.

The APIs should probably still be deprecated and removed to the
obsolete obsolete features manual, as the geometry contents are
entirely fictional for SSDs, and are fictional for any rotating media
and past the existing field sizes, and probably fictional for some
media within the limits.

Unrelated to disk geometry, there's an 8.58 GB limit here for SCSI-2
support, too; IBM cleverly re-used some SCSI tape-related fields for
disks, IIRC. The associated SCSI-2 driver support was subsequently
phased in back then, and was patched into versions somewhere between
V7.0 and V8.0. See the OpenVMS FAQ. There are other addressing limits
listed in the old FAQ.

TL;DR: If you're looking at CHS-style HDD geometry, you're being told a
story, and a story that OpenVMS itself cares little about.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-05-02 17:28, Stephen Hoffman wrote:
> Unrelated to disk geometry, there's an 8.58 GB limit here for SCSI-2
> support, too; IBM cleverly re-used some SCSI tape-related fields for
> disks, IIRC. The associated SCSI-2 driver support was subsequently
> phased in back then, and was patched into versions somewhere between
> V7.0 and V8.0. See the OpenVMS FAQ. There are other addressing limits
> listed in the old FAQ.

Uh? Say what? Are you claiming that SCSI-2 and older would not support
disks larger than 8.58GB???

I can't even see how any SCSI command could have an 8.58GB limit.
8.58GB limit would imply a 24-bit block address upper bound. However, in
SCSI you have the 6 byte CDB format, which, while on the surface might
have looked like it had a 24-bit block number in fact only have a 21-bit
block number, thus limiting disks to 1.07GB (this is also the infamous
limitation of the boot roms on some old VAXstations). Then comes 10 byte
CDB format, which have a 32-bit block number, and thus sets the size
limit to 2TB.
But the 10-byte CDB format is definitely supported by SCSI-2, and as far
as I can remember, is also supported by SCSI-1 devices. (Maybe not all,
but definitely some.)
Basically, any disk larger than about 1GB must support 10 byte CDBs, or
else it won't be larger than 1GB.

> TL;DR: If you're looking at CHS-style HDD geometry, you're being told a
> story, and a story that OpenVMS itself cares little about.

Indeed.

Johnny

On 2022-05-02 16:28:54 +0000, Johnny Billquist said:

> On 2022-05-02 17:28, Stephen Hoffman wrote:
>> Unrelated to disk geometry, there's an 8.58 GB limit here for SCSI-2
>> support, too; IBM cleverly re-used some SCSI tape-related fields for
>> disks, IIRC. The associated SCSI-2 driver support was subsequently
>> phased in back then, and was patched into versions somewhere between
>> V7.0 and V8.0. See the OpenVMS FAQ. There are other addressing limits
>> listed in the old FAQ.
>
> Uh? Say what? Are you claiming that SCSI-2 and older would not support
> disks larger than 8.58GB???

Skim what material was explicitly referenced.

Particularly the two sections that describe how the OpenVMS SCSI-2
implementation (and other SCSI-2 implementations) _added_ that
addressing support.

The original question is back in the general range when that storage
addressing support was _added_ to SCSI-2, and that support was patched
into the SCSI-2 in some contemporaneous OpenVMS versions.

TL;DR: OpenVMS FAQ http://www.hoffmanlabs.com/vmsfaq and search for "8.58".

--
Pure Personal Opinion | HoffmanLabs LLC

On 2022-05-06 18:06, Stephen Hoffman wrote:
> On 2022-05-02 16:28:54 +0000, Johnny Billquist said:
>
>> On 2022-05-02 17:28, Stephen Hoffman wrote:
>>> Unrelated to disk geometry, there's an 8.58 GB limit here for SCSI-2
>>> support, too; IBM cleverly re-used some SCSI tape-related fields for
>>> disks, IIRC. The associated SCSI-2 driver support was subsequently
>>> phased in back then, and was patched into versions somewhere between
>>> V7.0 and V8.0. See the OpenVMS FAQ. There are other addressing limits
>>> listed in the old FAQ.
>>
>> Uh? Say what? Are you claiming that SCSI-2 and older would not support
>> disks larger than 8.58GB???
>
> Skim what material was explicitly referenced.
>
> Particularly the two sections that describe how the OpenVMS SCSI-2
> implementation (and other SCSI-2 implementations) _added_ that
> addressing support.
>
> The original question is back in the general range when that storage
> addressing support was _added_ to SCSI-2, and that support was patched
> into the SCSI-2 in some contemporaneous OpenVMS versions.
>
> TL;DR:  OpenVMS FAQ http://www.hoffmanlabs.com/vmsfaq and search for
> "8.58".

I think you partially missed my point.
SCSI-2 itself will either place a limit of roughly 1GB, or else 2TB
(unless we go to even bugger sizes). There is no way that SCSI-2 itself
would ever have a limit of 8.58GB.

Sure, the VMS driver might have a limit there, but it don't have
anything to do with SCSI-2 as such.

The 6 byte commands, as mentioned, only actually have a 21-bit LBA, so
the limit is roughly 1GB, and it's still the problem with some old boot
roms for some (old) VAXstations...

But I don't have a problem believing that the VMS driver might have been
using a 24 bit LBA. Which then place such a limit. But it's not really
anything about the SCSI-2. RSX usually have the same limit/problem. LBAs
are commonly 24 bits...

Johnny

On 2022-05-08 10:17:32 +0000, Johnny Billquist said:

> There is no way that SCSI-2 itself would ever have a limit of 8.58GB.

Alas, it once did. Until IBM cleverly re-allocated parts of data
structures reserved for tapes for disks, and the change got adopted as
part of the spec.

--
Pure Personal Opinion | HoffmanLabs LLC