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