Original_To:  JNET%"ibm-main@ricevm1"
Original_cc:  JURASCHEK
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 23 Nov 1992 12:54:00 EST
From:         "David F. Juraschek" <JURASCHEK@GMUVAX.BITNET>
Subject:      DFHSM Recalls & Batch (Revisited)

"Mark C. Lawrence" <M.Lawrence@STANFORD.BITNET> provides:

>>There is no console request to mount any ML2 tape, and there is no delay
>>in the IEFBR14 step which ends RC=0.
>>(It would appear that the DSN has therefore been deleted.)
>
>I'm not an expert in DFHHSM, but one thing I can tell you is that when
>IEFBR14 ends, the return code is going to be 0.  IEFBR14 is a NULL PROGRAM,
>

Right.
Notice I said the "IEFBR14 step" ends RC=0.  Regardless of what BR14 does,
if there had been a file allocation/deallocation problem the -step- would
have abended with a system abend code other than zero.  The point I was
making is that this step ends with the appearance that it has completed
it's mission - implying that the file was HDELETEd (or at least recalled
and then deleted). (But see below ...)

>When you "use IEFBR14" to delete or allocate a data set. you are using MVS
>step allocation/termination services, not a utility program.  These MVS
>services don't always do what you want.  For example, if you have a
>disposition of DELETE and the data set isn't on the volume, you will get
>         IEF283I dsn    NOT DELETED 8
>at step termination.

And, the point I was trying to make was that there was NO indication of
failure or problem in doing the delete.

>Now, suppose that you specified UNIT and VOL on the DD statement.  Since
>volume information is available, MOD is treated (for allocation/disposition
>purposes) like OLD.  And, the data set won't be uncataloged at step
>termination, because it wasn't referenced via the catalog.  So, (a) will
>result in the catalog entry remaining, (b) gets NOT DELETED 8, (c) scratches
>it (if it was on the specified vol.), (d) gets NOT DELETED 8 but doesn't
>remove the catalog entry.  You now also have a case (e) where the data set is
>on some other volume.  You'll get NOT DELETED 8 and of course will still have
>the catalog entry, if there was one.

And, this appears to be in the crux of the problem.  If I specify a UNIT
and VOL on the DD statement, which we do, it appears that catalog management
never gets involved - and so DFHSM never actually does a HRECALL.  This
allocates space on the volume for the non-catalogged dataset named in the
DSN and then deletes it at step completion (because of the step normal and
abnornal disposition specifications of DELETE)  and the step completes looking
just fine.  It would appear then, that the next step blows at it's step
completion because it's trying to do a DISP=(NEW,CATLG,whatever) and the
dataset is already cataloged as DFHSM Migrated.  A non-cataloged dataset
was created and deleated in the IEFBR14 step.  At least, this is the
most plausible explanation we can come up with.  (Sound reasonable?)

The weird thing is that on several occasions, trying to subsequently
HRECALL this dataset fails - DFHSM says there is nothing to recall even
though there is a catalog entry with VOLSER=MIGRATE, or DFHSM won't recall
because a non-catalogged DSN of the same name has somehow appeared on the
destination volume.  That was the impetus for my question.

So, let me ask a different question:

Do you have a foolproof (or user proof) way of insuring that a dataset is
deleted in a preamble step - whether or not it previously exists - whether
or not it is DFHSM Migrated - such that this step will end with a step
return code of zero - and such that any future attempt to re-create
this dataset in a subsequent step will not fail because of the physical
pre-existance or pre-catalogged instance of this same DSN?  Oh - because
SMS and storage classes are not involved, the VOL=SER absolutely
needs to be defined as well.

Obviously IEFBR14 with DISP=(MOD,DELETE,DELETE) is not the answer since that's
what we're doing now.

Thanks again.

-Dave
 IBM Systems, George Mason University
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU