Discussion:
[Simh] Simh Digest, Vol 168, Issue 38
Larry Baker
2018-01-26 02:17:24 UTC
Permalink
We ran into this on a real VAX when we added a 20GB SCSI disk, as I recall. Either VAX/VMS or the hardware (I think it was VAX/VMS) only looks at the low-order 24 bits of the disk size. So, our 20GB disk was viewed as a 3+GB drive on the VAX. Alpha/VMS has no problem handling larger drives. I think I've used 100GB drives on an Alpha. I know I have a 72GB and a 50GB drive on our Alpha now.

Larry Baker
US Geological Survey
650-329-5608
Message: 3
Date: Thu, 25 Jan 2018 18:01:41 -0800
Subject: Re: [Simh] VAX Tape Emulation?
Content-Type: text/plain; charset=utf-8
If you're venturing into unix technology, it's possible to mount nfs
shares on the VMS machines. Then you can use BACKUP to write save sets
onto the nfs share. There seems to be some care needed with ADF
metadata. Multinet seems to write this to a hidden file or
subdirectory; not sure what UCX/TCPIP do.
I actually looked into this option around 2008 (for the same Alpha). If I remember correctly I ran into a problem on the VMS side of the file size limit (I have the same disk size now I had in 2008). This can work, but you have to break larger disks up into chunks. I’m hoping to avoid that, with the solution I’m looking at.
Zane
khandy21yo
2018-01-26 02:35:24 UTC
Permalink
The MicroVAX 3100 had a bug in the boot Rom that limited it to a 1.06? Disk. I don't know if it also occurred on other systems.


Sent from my Galaxy Tab® A
-------- Original message --------From: Larry Baker <***@usgs.gov> Date: 1/25/18 7:17 PM (GMT-07:00) To: ***@avanthar.com Cc: SIMH <***@trailing-edge.com> Subject: Re: [Simh] Simh Digest, Vol 168, Issue 38
We ran into this on a real VAX when we added a 20GB SCSI disk, as I recall.  Either VAX/VMS or the hardware (I think it was VAX/VMS) only looks at the low-order 24 bits of the disk size.  So, our 20GB disk was viewed as a 3+GB drive on the VAX.  Alpha/VMS has no problem handling larger drives.  I think I've used 100GB drives on an Alpha.  I know I have a 72GB and a 50GB drive on our Alpha now.

Larry Baker
US Geological Survey
650-329-5608
***@usgs.gov






On 25 Jan 2018, at 6:04:06 PM, simh-***@trailing-edge.com wrote:
Message: 3
Date: Thu, 25 Jan 2018 18:01:41 -0800
From: Zane Healy <***@avanthar.com>
To: Dennis Boone <***@msu.edu>
Cc: simh <***@trailing-edge.com>
Subject: Re: [Simh] VAX Tape Emulation?
Message-ID: <FB0095E0-4EC6-46CA-AEEB-***@avanthar.com>
Content-Type: text/plain; charset=utf-8


On Jan 25, 2018, at 2:22 PM, Dennis Boone <***@msu.edu> wrote:

If you're venturing into unix technology, it's possible to mount nfs
shares on the VMS machines.  Then you can use BACKUP to write save sets
onto the nfs share.  There seems to be some care needed with ADF
metadata.  Multinet seems to write this to a hidden file or
subdirectory; not sure what UCX/TCPIP do.

I actually looked into this option around 2008 (for the same Alpha).  If I remember correctly I ran into a problem on the VMS side of the file size limit (I have the same disk size now I had in 2008).  This can work, but you have to break larger disks up into chunks.  I’m hoping to avoid that, with the solution I’m looking at.

Zane
Bob Eager
2018-01-26 08:49:46 UTC
Permalink
I know I've hacked larger SCSI disks in the past, for the 3100. I made
them report a smaller size so that they would boot.

On Thu, 25 Jan 2018 19:35:24 -0700
Post by khandy21yo
The MicroVAX 3100 had a bug in the boot Rom that limited it to a
1.06? Disk. I don't know if it also occurred on other systems.
Sent from my Galaxy Tab® A
Issue 38 We ran into this on a real VAX when we added a 20GB SCSI
disk, as I recall.  Either VAX/VMS or the hardware (I think it was
VAX/VMS) only looks at the low-order 24 bits of the disk size.  So,
our 20GB disk was viewed as a 3+GB drive on the VAX.  Alpha/VMS has
no problem handling larger drives.  I think I've used 100GB drives on
an Alpha.  I know I have a 72GB and a 50GB drive on our Alpha now.
Larry Baker
US Geological Survey
650-329-5608
Message: 3
Date: Thu, 25 Jan 2018 18:01:41 -0800
Subject: Re: [Simh] VAX Tape Emulation?
Content-Type: text/plain; charset=utf-8
If you're venturing into unix technology, it's possible to mount nfs
shares on the VMS machines.  Then you can use BACKUP to write save
sets onto the nfs share.  There seems to be some care needed with ADF
metadata.  Multinet seems to write this to a hidden file or
subdirectory; not sure what UCX/TCPIP do.
I actually looked into this option around 2008 (for the same Alpha).
 If I remember correctly I ran into a problem on the VMS side of the
file size limit (I have the same disk size now I had in 2008).  This
can work, but you have to break larger disks up into chunks.  I?m
hoping to avoid that, with the solution I?m looking at.
Zane
Johnny Billquist
2018-01-26 09:22:32 UTC
Permalink
That is not solving the sctual problem.
And it's also unrelated to the 24 bit size for block numbers in VMS.

The boot issue is specific to some 3100 models and has to do with the scsi commands the boot prom uses. The driver in the boot prom uses group 0 commands, which only have a 21 bit field for block number. This leads to a 1G limit. This is only neede for booting and it actually only means that whatever is involved in the boot phase needs to be in the first 1G of the disk. If you can ensure that, then there is no problem having a larger disk even for booting. Unix with its partitioning of the disk can easily guarantee this for example. Once the system have booted the device driver in the boot prom is not used anyway so then the limit does not apply anymore.

The second issue is the 24 bit block number. This is a parameter setup when the file system is initialized and is the size of retrieval pointers. ODS1 pretty much only supports 24 bit retrieval pointers, but ODS2 can also have 32 bit retrieval pointers. But it has to be decided at file system initialization, and cannot be changed afterwards.

Johnny
Post by Bob Eager
I know I've hacked larger SCSI disks in the past, for the 3100. I made
them report a smaller size so that they would boot.
On Thu, 25 Jan 2018 19:35:24 -0700
Post by khandy21yo
The MicroVAX 3100 had a bug in the boot Rom that limited it to a
1.06? Disk. I don't know if it also occurred on other systems.
Sent from my Galaxy Tab® A
Issue 38 We ran into this on a real VAX when we added a 20GB SCSI
disk, as I recall.  Either VAX/VMS or the hardware (I think it was
VAX/VMS) only looks at the low-order 24 bits of the disk size.  So,
our 20GB disk was viewed as a 3+GB drive on the VAX.  Alpha/VMS has
no problem handling larger drives.  I think I've used 100GB drives on
an Alpha.  I know I have a 72GB and a 50GB drive on our Alpha now.
Larry Baker
US Geological Survey
650-329-5608
Message: 3
Date: Thu, 25 Jan 2018 18:01:41 -0800
Subject: Re: [Simh] VAX Tape Emulation?
Content-Type: text/plain; charset=utf-8
If you're venturing into unix technology, it's possible to mount nfs
shares on the VMS machines.  Then you can use BACKUP to write save
sets onto the nfs share.  There seems to be some care needed with ADF
metadata.  Multinet seems to write this to a hidden file or
subdirectory; not sure what UCX/TCPIP do.
I actually looked into this option around 2008 (for the same Alpha).
 If I remember correctly I ran into a problem on the VMS side of the
file size limit (I have the same disk size now I had in 2008).  This
can work, but you have to break larger disks up into chunks.  I?m
hoping to avoid that, with the solution I?m looking at.
Zane
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh
--
Skickat från min Android-enhet med K-9 Mail. UrsÀkta min fåordighet.
Johnny Billquist
2018-01-26 09:24:02 UTC
Permalink
It's not really a bug. It's a limitation. A bit unfortunate, but a design choice made by the proframmer who wrote the firmware.

Johnny
Post by khandy21yo
The MicroVAX 3100 had a bug in the boot Rom that limited it to a 1.06?
Disk. I don't know if it also occurred on other systems.
Sent from my Galaxy Tab® A
Issue 38
We ran into this on a real VAX when we added a 20GB SCSI disk, as I
recall.  Either VAX/VMS or the hardware (I think it was VAX/VMS) only
looks at the low-order 24 bits of the disk size.  So, our 20GB disk was
viewed as a 3+GB drive on the VAX.  Alpha/VMS has no problem handling
larger drives.  I think I've used 100GB drives on an Alpha.  I know I
have a 72GB and a 50GB drive on our Alpha now.
Larry Baker
US Geological Survey
650-329-5608
Message: 3
Date: Thu, 25 Jan 2018 18:01:41 -0800
Subject: Re: [Simh] VAX Tape Emulation?
Content-Type: text/plain; charset=utf-8
If you're venturing into unix technology, it's possible to mount nfs
shares on the VMS machines.  Then you can use BACKUP to write save sets
onto the nfs share.  There seems to be some care needed with ADF
metadata.  Multinet seems to write this to a hidden file or
subdirectory; not sure what UCX/TCPIP do.
I actually looked into this option around 2008 (for the same Alpha).
 If I remember correctly I ran into a problem on the VMS side of the
file size limit (I have the same disk size now I had in 2008).  This
can work, but you have to break larger disks up into chunks.  I’m
hoping to avoid that, with the solution I’m looking at.
Zane
--
Skickat från min Android-enhet med K-9 Mail. UrsÀkta min fåordighet.
Loading...