We've run into a sticky problem at my site. I'm wondering if anyone else has
stepped in this one
yet. In the process of cleaning up some flat files after an update process, we
loop through the
files doing a PURGE of the destination to ensure it's not there and then a
RENAME. The PURGE is
fine. It finds no dest and moves on. However, we get this message on the RENAME
that follows...
 
        User lacks delete directory (DD) access. (FSERR 462)
        RENAME failed due to file system error. Not renamed. (CIERR 373)
 
The original PURGE and RENAME commands were executing MPE's versions. That
would stop at the
first error without processing the rest of the list. We changed it to run the
MPEX version. That
would process the entire list but still wouldn't work. (Same error.)
 
Here are the particulars for all involved. (The groups and user are all in the
same account)
The user -  CAP=AL,GL,LG,ND,SF,BA,IA
Source group - ACCESS=(R,S:AC;W,A,L,X:AL),CAP=BA,IA
Dest group - ACCESS=(R,S:AC;W,A,L,X:AL,GU);CAP=BA,IA
The account - CAP=AM,AL,GL,LG,ND,SF,BA,IA,MR,DS,PH;ACCESS=(R,L,X:ANY;W,A:AC)
 
The files that are being moved are not created by the user submitting the job
but that user is an
AL. (This worked fine and dandy until we put in 5.0) To confuse thing even
more, once the RENAME
fails, it 1) changes the creator for the files to the submitting user and 2)
plugs in ACD
information for the files where before we had none. (This doesn't bother us
since we don't use
the ACD information currently. POSIX is looming in the distance for us right
now...)
 
HP recognizes there is a bug in the RENAME for MPE and they're working on it.
We've been talking
VESOFT's ears off trying to find out how to get around it. They claim the MPEX
RENAME should work
with the setup we have here. (One official Pat-on-the-back for VESOFT's
patience with this.)
We've exhausted just about all the options VESOFT has suggested. (ie. adding PH
to the user,
adding ;LOCAL to the rename)
 
At VESOFT's suggestion, we added ;DELACD to the RENAME and that's taken care of
the ACDs but we
still can't get the RENAME to work for the user. Currently, we've changed the
submitter of the
job from the user to MGR for the account and that's running fine but that's
just a quick fix.
 
Does any one have any other suggestions of where else we can look or anything
else to try? We'd
also really like to know what option controls the 'delete directory (DD)'
access.
 
TIA
 
--
=             Mike Vealey            |\/|      University of Maryland        =
=           [log in to unmask]          |..|         Baltimore County           =
=                                     \/                                     =
="In the Grand Canyon National Park in Arizona, rangers are killing mule     =
= deer that have become hooked on junk food left over by tourists. Doesn't   =
= make sense. Shouldn't they shoot the tourists instead?"                    =
=                                                         -- Andrei Codrescu =
=  All opinions expressed are mine and mine alone. You can't have them!      =