On 29 Sep 2005 at 5:48, John Bawden wrote:

> You can test the "multi reel" store to disc as
> follows:
> FILE STD1=STORE1.BACKUP.SYS;DEV=DISC
> FILE STD2=STORE2.BACKUP.SYS;DEV=DISC
> 
> STORE some small file set;;RESTORESET=(*STD1),(*STD2);
> COMPRESS=HIGH (or LOW, your choice);SHOW
> 
> This will create two disc files or you can create more if you
> choose, I have used up to 5 for large databases. 

Thank you for your suggestion.  Evidently I am not making myself 
clear on what I wish to do.  What I wish to test is the mix of MPE 
and HFS namespace files that STORE creates when it exceeds the 
maximum file size for a single reel, whether or not this 
eventuality is anticipated.  The method proposed above retains all 
files in the MPE namespace, which is fine so long as one is aware 
that the incremental step point has not been reached with the 
underlying data.  My question for you is what happens if one 
actually requires three reels when only providing for the two 
anticipated?  Does one then end up with STORE1.GROUP.ACCT, 
STORE2.GROUP.ACCT, and \ACCT\GROUP\STORE1.2 or is it 
\ACCT\GROUP\STORE2.2?  How do you test and find out what happens 
absent 9 Gb of data to store and as much surplus disc capacity?  
How do you test and verify your recovery procedures?  How much time 
does this testing take with 9Gb of data moving over the network 
vice some arbitrary lesser amount?  

In our case, an FTP transfer that takes 15 minutes between two 
linux boxes on the same switch as the HP3000 takes 2 hours and 38 
minutes between the HP3000 and the first Linux host.  This is for a 
single reel that is not quite yet 4GB (nominal).  A second 4 Gb 
reel would take another 2.75 hours.  This is more than 5.5 hours 
one-way (and 11 overall) just to verify behaviour that could be 
equally well assured with three 1Kb STD files and take an 
insignificant amount of transmission time.

Thus I find it most disconcerting that such an important MPE tool 
as STORE appears written in such a fashion as that it declines to 
fully implement the elegance and entire functionality of the FILE 
command.  Had this standard behaviour been adhered to then much of 
the time and effort I have expended this past month testing STD 
either would have been avoided altogether, or much reduced.  
Consider the present difficulties encountered testing mixed 
namespace disc reel sets.  Had FILE been fully implemented then 
this would have been a trivial exercise. As it is one is required 
to create enough data to exceed the hardcoded limit.  Similarly, 
allowing one to set the block size for the STD would have made 
moving the resulting STD reels to tape a simple exercise using 
TAPECOPY (although I may have found a Linux solution to this 
difficulty). 

We are headed off the HP3000 over the next few years and I do not 
expect that this (in my view) defect in STORE will ever be 
addressed. Nonetheless, I find it disturbing that such inconsistent 
behaviour with respect to MPE was introduced into such an essential 
part of the OS. It can only speak to the infrequency of STD use and 
the availability of manual work-arounds such as the proposal above 
that the situation persists.  It is important to me that I see our 
backup and recovery procedures actually provide the expected 
behaviour under our operating conditions and are robust enough to 
function reliably in the absence of continuous monitoring.  The 
multi-namespace behaviour of STORE and the presence of hard limits 
make this testing much more time consuming and difficult than is 
otherwise necessary.

An alternative design approach would not have been so difficult 
either. I can easily conceive of STORE STD filesets as being 
analogous to IMAGE datasets.  It surely would have posed no 
hardship to fixing the user specified portion of an STD to six 
characters and then have STORE completely manage the data reels 
from 00 to 99, yielding 0.4Tb of disc store while keeping the 
entire thing comfortably inside the MPE namespace.  I imagine that 
there exist some HP3000 users whose STORE STD requirements exceed 
this, but I doubt that there are very many that even have this 
amount of disc space connected to their HP3000.  For those that do 
require STDs greater than 400Gb then the logical thing is to 
require multiple STORE reel-sets specified as above, yielding 
essentially an infinite amount of STD entirely within the MPE 
namespace.

Posix and the HFS was, in my opinion, a great addition to MPE but I 
wish that programmers of MPE FOS utilities had avoided visibly 
mixing the the two namespaces.  An HP3000 user should have retained 
the option of staying "pure" MPE without concerning themselves with 
default behaviour of FOS utilities that involve the HFS namespace.

Sigh,
Jim

--   
     *** e-mail is not a secure channel ***
mailto:byrnejb.<token>@harte-lyne.ca
James B. Byrne                Harte & Lyne Limited
vox: +1 905 561 1241          9 Brockley Drive
fax: +1 905 561 0757          Hamilton, Ontario
<token> = hal                 Canada L8E 3C3

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *