Part of my DRM package on VM's download lib is DIRMW. You enter DIRMW
and you'll get a selection list of all Workunit and WUCCFAIL requests,
including the command issuer and the command that was issued. You can
then XEDIT, Retry, Query or Erase the files. With QUERY you get a
chance to see easily why a disk cleanup doesn't end (in fact the QUERY
command sends a request to DATAMOVE to execute an EXEC, this EXEC
links the disk to be cleaned/moved and then issues Q LINKS so one can
see prohibitor).
WUCCFAIL files for cases where DIRMAINT could not fully recover the
failure (and manual intervention is required) are listed in red.
2008/3/12, Bruce Hayden <[EMAIL PROTECTED]>:
> That is a failure of an Add Minidisk request - and it is telling you
> that it can't find a free space ("gap") to allocate the disk in.
> Check your EXTENT CONTROL file for the GRPLNX group and see if it has
> free space.
>
> Frequently an error purging an id is due to cleaning up the minidisks,
> and the problem is that some userid still has the disk linked. The
> DATAMOVE machine won't do anything to the disk if any id has it
> linked. It retries on a regular interval, and it should send you
> messages at each retry telling you why it is still failing. One other
> way it to check the DATAMOVE console file.
>
>
> On Wed, Mar 12, 2008 at 1:39 PM, KEETON Dave * OR SDC
> <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > Hi Everyone,
> >
> > I'm new at using DirMaint, so please excuse the ignorance of my question. I
> > have a user account I created that I can't seem to purge correctly. I told
> > it to purge the account, but it hasn't completed yet. It's been several
> days
> > and I'm not sure why it hasn't completed yet.
> >
> > There are quite a few WUCFFAIL files on DirMaint's 1DF disk that don't seem
> > to be getting cleaned up automatically.
> >
> > Here's an example of one of them:
> >
> > DMM: &DMM.NAME &DMM.NODE
> > DEV.ONE: &DEV.ONE
> > DEV.TWO: &DEV.TWO
> > ORIGNODE: ZVMV5R20
> > ORIGUSER: <OBSCURED>
> > ORIGSEQ#: 200.9
> > ORIGCMD: AMDISK 0109 3390 AUTOG 3338 GRPLNX MR PWS XXXXXXXX
> > SYSAFFIN: *
> > TARGETID: ZAPAPP03
> > LANG: AMENG
> > CMDLEVEL: 140A
> > ASUSER: <OBSCURED>
> > ASNODE: ZVMV5R20
> > MSGUSER: <OBSCURED>
> > MSGNODE: ZVMV5R20
> > REQUEST: 200.9
> > ORIGEXTENT: N/A
> > BEGINCMDS:
> > DONE00000000 WORKUNIT ENABLE
> > DONE32980000 AMDISK FOR ZAPAPP03 0109 3390 AUTOG 3338 GRPLNX MR MULTIPLE
> > NTRIED UNLOCK 0109 ZAPAPP03 NOMSG
> > NTRIED WORKUNIT RESET
> > NTRIED DIRECT
> > DVHALC3297E No gap of sufficient size found in candidate area(s).
> > DVHAMD3298E DASD allocation attempt failed.
> > DVHAMD3298E For: ZAPAPP03 0109 Request: 3390 AUTOG 3338 GRPLNX MR
> > DVHSRL3414I Workunit 11145155 has failed. It is being saved as 11145155
> > DVHSRL3414I WUCFFAIL.
> > FORUSER ZAPAPP03 ATNODE * UNLOCK 0109
> > DVHSRL3414I Workunit 11145155 is being rolled back by DIRMAINT.
> > DVHSMA3212E Unexpected RC= 3298, from: EXEC DVHSSHND 11145155
> >
> > A quick search of the list archive seemed to indicate that doing a DIRM
> > BACKUP might clear things up, but it didn't make any difference for me.
> >
> > Thanks all,
> >
> > Dave
>
>
>
>
> --
> Bruce Hayden
> Linux on System z Advanced Technical Support
> Endicott, NY
>
--
Kris Buelens,
IBM Belgium, VM customer support
