On 11 Nov 2005 at 10:34, Doug Werth wrote:

> Don't misinterpret LOGON GROUP to be the same as HOME GROUP.

I was not aware that I had.  I believe that I only stated my belief 
that one can only create a logid disc file in ones logon group.  

Our log files do not reside in any users' home groups but I was 
required to logon/chgroup to the directory where they reside to 
create the logids.  If your original description is taken at face 
value ("Any group that the log file owner has write access to. In 
fact, multiple databases from accounts A and B can all point to a 
log file that exists in account C if you like.") then one might 
reasonably infer that one can create a logid for any group that the 
userid has save access to.

This is not the case.  One must also be in that particular 
directory at the time of creating the logid regardless of the 
security matrix.  Accessibility of logging processes to the log 
file after the logid is created is not the point in question.

One can conceive of the case where a userid has w,a,a,l,x,r access 
to a password protected group other than their home, but does not 
possess the password to it.  In the absence of AM, SM or PM then 
one would be hard pressed to create a user logid having a disc file 
in that directory.

I realize that this is one of MPE's artifacts, similar to having to 
logon to the same group as a database in order to use dbutil, and 
that this is never going to change.  While this behaviour is 
annoying (as well as pointless in my opinion and, given the 
existence of mpex, evidently that of others as well), I was not 
complaining about it, rather seeking confirmation that this was 
indeed the case.  I am revisiting a lot of very old territory in a 
very cursory manner and the help I receive here in recovering lost 
skills and long forgotten information is greatly appreciated.

Our solution to the logid file names situation is simply to have 
two different nomenclatures for the same logid on the two machines, 
one HALDB### and the other DRLDB###.  This way a namespace conflict 
is avoided and recovery/synchronization issues much simplified.  We 
are not looking for an instantaneous fail-over solution, just a 
very speedy transfer capability.  A restore of the data files from 
the most current backup is accepted as the minimum amount of delay 
before switching hosts.  Currently this takes about 50 minutes 
after the transfer is completed.  So, reasonably, we are looking at 
about three to six hours to effect a switch over, which is well 
within the tolerance level our business can accept.

Since prior to this past summer a disaster recovery would have 
necessitated locating a replacement HP3000 to begin with, this is a 
considerable improvement.

Regards,
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 *