HP3000-L Archives

February 1999, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Andreas Schmidt <[log in to unmask]>
Reply To:
Date:
Tue, 2 Feb 1999 14:13:38 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (28 lines)
Folks,

working with Private Volumes may create (at least) two hidden problems:

(1) some groups of an account on PrivVol1, do not reside on this Volume but
on another PrivVol# or (in most of the cases) on the SysVol,
(2) some groups are still known on the PrivVol1 but are no longer known in
the system's directory.

ad (1): This happens by creating new groups. As long as no System Wide UDCs
are in place to automatically perform the needed ;ONVS and ;HOMEVS option
in NEWGROUP commands, the Operating System will create a group always
logically and physically on the SysVol.
UDCs are available, and we also have a Checkjob in place.

ad (2): This happens by deleting a group. As long as no System Wide UDCs
are in place to automatically perform the needed PURGEGROUP commands (one
for the SysVol, one for the PrivVol) the group entry will stay in the
PrivVol's directory. You may check this via FSCHECK, CHECKALL option - or
via a special job I wrote "quick and dirty" having realized this. So far,
the job requires MPEX to read a file sequentially ...

If someone is interested in to get our UDCs for NEWGROUP (different from
the one well known here) or the two check jobs, just send an eMail to
[log in to unmask]

Best regards, Andreas Schmidt, CSC, Germany

ATOM RSS1 RSS2