home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / bit / listserv / ibmmain / 2670 < prev    next >
Encoding:
Text File  |  1992-11-19  |  2.7 KB  |  57 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!gatech!destroyer!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!paladin.american.edu!auvm!GMUVAX.BITNET!JURASCHEK
  3. Original_To:  JNET%"ibm-main@ricevm1"
  4. Original_cc:  JURASCHEK
  5. Message-ID: <IBM-MAIN%92111912541608@RICEVM1.RICE.EDU>
  6. Newsgroups: bit.listserv.ibm-main
  7. Date:         Thu, 19 Nov 1992 13:43:00 EST
  8. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  9. From:         "David F. Juraschek" <JURASCHEK@GMUVAX.BITNET>
  10. Subject:      DFHSM Recalls & Batch
  11. Lines: 44
  12.  
  13. DFHSM 2.6 MVS/ESA JES2 4.2.2 DFP 3.3.1
  14. DFHSM does space management on a number of our non-SMS volumes.
  15. A batch job runs which attempts to delete a DSN in the first step via
  16. IEFBR14.  The DSN happens to have been migrated sometime in the past by
  17. DFHSM's space management activities.
  18. There is no console request to mount any ML2 tape, and there is no delay
  19. in the IEFBR14 step which ends RC=0.
  20. (It would appear that the DSN has therefore been deleted.)
  21. A later step attempts to create the DSN anew.  This step abends for one of
  22. two reasons:
  23.    The DSN is still cataloged (but physically is non-existant)
  24. or The DSN is not cataloged (but physically exists).
  25.  
  26. This phenonema has occured several times with differing job streams, but
  27. the scenario is the same.  The first step attempts to delete a migrated
  28. DSN and ends RC=0 with no console indication that a physical recall has
  29. actually occured.  A later step (may be the next job step) blows because
  30. for some reason it can't create this DSN anew.  No other job stream or
  31. human activity creates these DSN's.  Post abend inspection indicates an
  32. uncataloged DSN or a cataloged DSN with no physical entity.  The obvious
  33. problem is that somehow there is a syncronization problem with DFHSM and
  34. a delete via IEFBR14.  (The IEFBR14 shouldn't really end RC=14 until the
  35. DSN is physically removed and the catalog entry deleted, should it not?)
  36.  
  37. We have a number of pre-DFHSM job streams that use IEFBR14 and
  38. DISP=(MOD,DELETE,DELETE) to delete old copies of files that are re-created
  39. in the same job stream.  It is unacceptable to rewrite these job streams
  40. to also include a TSO batch step that issued HDELETEs for all these same
  41. DSNs.
  42.  
  43. I don't have access to IBMLINK (please no discussions about that).  Is
  44. this phenonema a known DFHSM "feature".  Is there a work-around?  (The
  45. same thing used to happen occasionally under DFHSM 2.4 and DFHSM 2.5.
  46. The problem is getting worse now as DFHSM is doing significantly more
  47. in the area of space management than it used to have to do in those
  48. days.)
  49.  
  50. Any ideas?
  51.  
  52. Thanks.
  53. -Dave Juraschek
  54.  IBM Systems, George Mason University
  55.  
  56. (Do I maybe have some obscure SETSYS option wrong in DFHSM?)
  57.