From:	SMTP%"Info-VAX-Request@Mvb.Saic.Com" 14-SEP-1994 17:09:01.85
To:	EVERHART
CC:	
Subj:	Re: Large cluster-size problem for large disk

From: vandenheuvel@eps.enet.dec.com (Hein RMS van den Heuvel)
X-Newsgroups: comp.os.vms,vmsnet.alpha,vmsnet.misc,comp.sys.dec
Subject: Re: Large cluster-size problem for large disk
Date: 14 SEP 94 16:21:13
Organization: Digital Equipment Corporation
Lines: 25
Message-ID: <357mf9$b4s@jac.zko.dec.com>
NNTP-Posting-Host: AMUZED
To: Info-VAX@Mvb.Saic.Com
X-Gateway-Source-Info: USENET


>In article <PREP.94Sep14232044@yarrow.wt.uwa.edu.au>, prep@yarrow.wt.uwa.edu.au (Paul Repacholi) writes...
>In article <351qqa$4u4@jac.zko.dec.com> vandenheuvel@eps.enet.dec.com (Hein RMS van den Heuvel) writes:
> 
>> Sorry, this can NOT be patched. It is an inherent restriction of 
>> the ODS-II on disk file structure as maintained by the XQP.
> 
>It is *NOT* an inherent ODS-2 restriction. It s a result
>of the way the XQP and ACP before it are implemented. I
>could be changed.

I spoke to soon. I stand corrected. 
BITMAP.SYS > 255 blocks does NOT seem to be prohibited by the ODS-2 spec. 
As Paul replies, the XQP implementation was limitted by using a byte 
sized VCB$B_SBMAPSIZE but that was lifted in 1987 by being upped to a word. 
So the XQP appears ready for a larger BITMAP.SYS (but is untested).
Now MOUNT deliberatly verifies MAXBLOCK/(4096*CLUSTER_SIZE) not to be > 255.
This should be easy enough to address (or even patch :^).
That leaves INIT. That's where the missing bits appear to concentrate.
Hmmm....

Hope this helps,               +--------------------------------------+
                               | All opinions expressed are mine, and |
Hein van den Heuvel            | may not reflect those of my employer |
vandenheuvel@eps.enet.dec.com  +--------------------------------------+