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 <r...@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 <khandy2...@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 <ba...@usgs.gov>
>> Date: 1/25/18 7:17 PM (GMT-07:00) To: heal...@avanthar.com Cc: SIMH
>> <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
>> ba...@usgs.gov
>>
>>
>>
>>
>>
>>
>> On 25 Jan 2018, at 6:04:06 PM, simh-requ...@trailing-edge.com wrote:
>> Message: 3
>> Date: Thu, 25 Jan 2018 18:01:41 -0800
>> From: Zane Healy <heal...@avanthar.com>
>> To: Dennis Boone <d...@msu.edu>
>> Cc: simh <simh@trailing-edge.com>
>> Subject: Re: [Simh] VAX Tape Emulation?
>> Message-ID: <fb0095e0-4ec6-46ca-aeeb-52eee3152...@avanthar.com>
>> Content-Type: text/plain; charset=utf-8
>>
>>
>> On Jan 25, 2018, at 2:22 PM, Dennis Boone <d...@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@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.
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
