NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/bit/listserv/ibmmain/2677

Text File | 1992-11-20 | 6.7 KB | 124 lines

Comments: Gated by [e-mail]
Path: sparky!uunet!paladin.american.edu!auvm!STANFORD.BITNET!M.LAWRENCE
Message-ID: <[e-mail]>
Newsgroups: bit.listserv.ibm-main
Date:         Fri, 20 Nov 1992 10:18:54 PST
Sender:       IBM Mainframe Discussion list <[e-mail]>
From:         "Mark C. Lawrence" <[e-mail]>
Subject:      IEFBR14
Comments: To: [e-mail]
Lines: 112

REPLY TO 11/19/92 10:53 FROM [e-mail] "IBM Mainframe Discussion
list": DFHSM Recalls & Batch

On Thu, 19 Nov 1992 "David F. Juraschek" <[e-mail]> said,
>DFHSM does space management on a number of our non-SMS volumes.
>A batch job runs which attempts to delete a DSN in the first step via
>IEFBR14.  The DSN happens to have been migrated sometime in the past by
>DFHSM's space management activities.
>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.)
>A later step attempts to create the DSN anew.  This step abends for one of
>two reasons:
>   The DSN is still cataloged (but physically is non-existant)
>or The DSN is not cataloged (but physically exists).
>
>This phenonema has occured several times with differing job streams, but
>the scenario is the same.  The first step attempts to delete a migrated
>DSN and ends RC=0 with no console indication that a physical recall has
>actually occured.  A later step (may be the next job step) blows because
>for some reason it can't create this DSN anew.  No other job stream or
>human activity creates these DSN's.  Post abend inspection indicates an
>uncataloged DSN or a cataloged DSN with no physical entity.  The obvious
>problem is that somehow there is a syncronization problem with DFHSM and
>a delete via IEFBR14.  (The IEFBR14 shouldn't really end RC=14 until the
                                                          ¢¢¢¢¢
>DSN is physically removed and the catalog entry deleted, should it not?)

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,
to wit,
         SR    15,15    Set return code=0
         BR    14       Return

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.  This does not affect any condition codes or the
processing of subsequent steps.  Assuming a nonspecific volume request, a
status of MOD will be treated as NEW if the file isn't in the catalog, because
MOD is treated as NEW *if no volume information is available*.  In this case
if the file is not cataloged, the system will try to create it (and then
delete it at step termination, since you had a disposition of DELETE).  The
conditional disposition is irrelevant, since IEFBR14 will never ever ever ever
ever ABEND.  [for extra credit:  IEFBR14 is the only program to have had only
one bug in its entire history.  What was it?]

>We have a number of pre-DFHSM job streams that use IEFBR14 and
>DISP=(MOD,DELETE,DELETE) to delete old copies of files that are re-created
>in the same job stream.

OK, let's look at this process.  You have a status of MOD, a disposition of
DELETE, a conditional disposition of DELETE.  Status=MOD means:

1.  If volume information is available, treat as old (and position to the
    end of the data set when it is opened, but you're not going to open it).
2.  If no volume information is available, treat as NEW and allocate it.
    Assuming you did not specify a volume on the DD statement, volume info
    will be available iff the data set is in the catalog (or pass queue).

The following assumes that you don't specify a volume on the DD statement.

If the data set (a) existed and was properly cataloged, the actual data set was
allocated; if you ran a real program, it could open the data set.  If the
data set (b) did not exist and was not cataloged, it has now been created.  If
the data set (c) existed but was not cataloged, a duplicate has now been created
(unless a duplicate exists on all eligible volumes, in which case your step
fails in alloation).  If the data set (d) was cataloged but did not exist, the
nonexistant data set has been allocated; if you ran a real program, it would
get a 213 ABEND when it tried to open.

At step termination, the system attempts to perform disposition processing,
namely, DELETE.  In case (a), it will be scratched and uncataloged.  In case
(b), the newly created data set will be deleted.  In either of these cases
subsequent attempts to create a new version should succeed.  In case (c), the
newly created duplicate is scratched; a subsequent attempt to create it should
succeed (creating a new duplicate) and you will be able to catalog it.  In
case (d) you will get the IEF283I dsn NOT DELETED 8 and also IEF283I dsn
UNCATALOGED 8, and the data set will be uncataloged.  Subsequent attempts to
allocate and catalog it should succeed.

All of the above assumes that SMS isn't affecting the process...you said these
were non-SMS volumes, I'm not sure if SMS still gets in there...
Also, in case (b) you could fail in allocation if there wasn't enough informatio
n
(SPACE, for example) to allocate the new data set.

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.

>It is unacceptable to rewrite these job streams to also include a TSO
>batch step that issued HDELETEs for all these same DSNs.

Lotsa luck.  If you find the behavior of MVS allocation/disposition services
unacceptable, your only alternative is to use a program that does do what you
want.  Batch TSO might be a solution.  I wrote a program to scratch and
uncatalog a file, so I could make it fail cleanly (and with return code) when
the file wasn't there.

It does seem odd that HSM would leave you with data sets and catalog entries
out of sync.  Perhaps there is an HSM guru out there who can enlighten us...

To:  [e-mail]