[Info-vax] bound volume set limits

[Jan-Erik Soderholm]

Den 2017-07-04 kl. 14:30, skrev Baldrick:
> On Tuesday, 4 July 2017 03:38:01 UTC+1, David Froble  wrote:
>> 
>> Well, we don't know why he's running VAX/VMS, nor do we know if he's
>> already using an emulator.  Regardless, it's VAX/VMS V7.3 or earlier
>> that determines what types of devices can be handled.
>> 
>> Without that information, other configurations cannot be part of this
>> discussion.
>> 
>> It seems to be conventional wisdom (CW) that for say a terabyte disk,
>> or larger, wasted space should not be a concern.  Maybe I'm just old
>> school, but I don't like that CW.
>> 
>> Nor do I have a clue what I'd do with a terabyte of storage, except
>> for backup save sets, which would be rather large files.  But that is
>> just me.
>> 
>> Nor do I have much use for bound volumes.  I'd be looking hard for
>> another option.  Perhaps logical names representing multiple disks.
>> Perhaps other solutions.
> 
> Hello all,
> 
> Thank you EVERYONE for your suggestions.
> 
> Why are we using VAX? because we NEED to. Let's just say it was the
> development platform for something important that is in current use and
> will be for many years so it'll need to be kept running. Why is it
> frozen at that version? Company politics. Why is it not an emulator?
> They have their limitations and quite frankly introduces FAR more issues
> than they solve, expensive being one, and the other main one being it
> still does not address the real issue... which is (as someone else
> pointed out) the cluster size wastage. We'd have to go WELL beyond the 2
> TB limit to squish on 1.5 TB of 'small' files.
> 
> Right now, the terabyte PLUS of data is on *dozens* of DLT cartridges.
> voluminous amounts of data which has to be kept and is still being
> generated, so serendipity struck and we've increased the storage area.
> They are not 'backups' it's an archive.
> 
> Why can't we use logicals? because the retrieval software has to be
> 'fooled' to work properly, and logicals break it. Company made the
> developers of that (dodgy) code redundant many years ago. Same old
> story.
> 
> Jan-Erik: Yes we can do that. In fact we've gone for reducing the total
> number and increasing the space. When I discussed it with the storage
> engineer, my allocation almost isn't even a drip in his pool so he's
> made me some bigger ones taking account of the wastage, but its a fine
> balance. Having fewer in a BVS is neater overall.
> 
> OSUV.. (don't have your name): Thank you for your insights. Interesting
> this 'bug' is still present in 8.4 (Hello VSI? -though I know Andy is
> working on a vNext of ODS for VMS and I had a discussion with him at the
> bootcamp last year) and there's new detail to be shared.
> 
> So thank you so much for all your inputs, and Hoff didn't even once
> shake his head at me, but doubtless he will at the bootcamp !
> 
> I now have 25 off 75 GB volumes. Now the hard work begins of unpicking
> and unloading all those DLT's and HOPING we can still successfully read
> them (however offsite second copies were made).
> 

Fine that you found a solution that seems to work! And yes, when we moved
to the corporate SAN environment and specified our storage requrements,
the guy there first thought of putting it all on the SDD pool. And he could
not create smaller disks volumes then what I specified (24 GB). :-)