[Simh] Simh Digest, Vol 168, Issue 38

[Johnny Billquist]

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 


Bob Eager <rde at tavi.co.uk> skrev: (26 januari 2018 09:49:46 CET)
>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
>khandy21yo <khandy21yo at gmail.com> wrote:
>
>> 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 <baker at usgs.gov>
>> Date: 1/25/18  7:17 PM  (GMT-07:00) To: healyzh at avanthar.com Cc: SIMH
>> <simh at 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
>> baker at usgs.gov
>> 
>> 
>> 
>> 
>> 
>> 
>> On 25 Jan 2018, at 6:04:06 PM, simh-request at trailing-edge.com wrote:
>> Message: 3
>> Date: Thu, 25 Jan 2018 18:01:41 -0800
>> From: Zane Healy <healyzh at avanthar.com>
>> To: Dennis Boone <drb at msu.edu>
>> Cc: simh <simh at trailing-edge.com>
>> Subject: Re: [Simh] VAX Tape Emulation?
>> Message-ID: <FB0095E0-4EC6-46CA-AEEB-52EEE315239E at avanthar.com>
>> Content-Type: text/plain; charset=utf-8
>> 
>> 
>> On Jan 25, 2018, at 2:22 PM, Dennis Boone <drb at 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
>> 
>
>_______________________________________________
>Simh mailing list
>Simh at trailing-edge.com
>http://mailman.trailing-edge.com/mailman/listinfo/simh

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180126/157203e1/attachment.html>