home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / bit / listserv / ibmmain / 2698 < prev    next >
Encoding:
Text File  |  1992-11-23  |  4.2 KB  |  87 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!GMUVAX.BITNET!JURASCHEK
  3. Original_To:  JNET%"ibm-main@ricevm1"
  4. Original_cc:  JURASCHEK
  5. Message-ID: <IBM-MAIN%92112312044814@RICEVM1.RICE.EDU>
  6. Newsgroups: bit.listserv.ibm-main
  7. Date:         Mon, 23 Nov 1992 12:54: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 (Revisited)
  11. Lines: 74
  12.  
  13. "Mark C. Lawrence" <M.Lawrence@STANFORD.BITNET> provides:
  14.  
  15. >>There is no console request to mount any ML2 tape, and there is no delay
  16. >>in the IEFBR14 step which ends RC=0.
  17. >>(It would appear that the DSN has therefore been deleted.)
  18. >
  19. >I'm not an expert in DFHHSM, but one thing I can tell you is that when
  20. >IEFBR14 ends, the return code is going to be 0.  IEFBR14 is a NULL PROGRAM,
  21. >
  22.  
  23. Right.
  24. Notice I said the "IEFBR14 step" ends RC=0.  Regardless of what BR14 does,
  25. if there had been a file allocation/deallocation problem the -step- would
  26. have abended with a system abend code other than zero.  The point I was
  27. making is that this step ends with the appearance that it has completed
  28. it's mission - implying that the file was HDELETEd (or at least recalled
  29. and then deleted). (But see below ...)
  30.  
  31. >When you "use IEFBR14" to delete or allocate a data set. you are using MVS
  32. >step allocation/termination services, not a utility program.  These MVS
  33. >services don't always do what you want.  For example, if you have a
  34. >disposition of DELETE and the data set isn't on the volume, you will get
  35. >         IEF283I dsn    NOT DELETED 8
  36. >at step termination.
  37.  
  38. And, the point I was trying to make was that there was NO indication of
  39. failure or problem in doing the delete.
  40.  
  41. >Now, suppose that you specified UNIT and VOL on the DD statement.  Since
  42. >volume information is available, MOD is treated (for allocation/disposition
  43. >purposes) like OLD.  And, the data set won't be uncataloged at step
  44. >termination, because it wasn't referenced via the catalog.  So, (a) will
  45. >result in the catalog entry remaining, (b) gets NOT DELETED 8, (c) scratches
  46. >it (if it was on the specified vol.), (d) gets NOT DELETED 8 but doesn't
  47. >remove the catalog entry.  You now also have a case (e) where the data set is
  48. >on some other volume.  You'll get NOT DELETED 8 and of course will still have
  49. >the catalog entry, if there was one.
  50.  
  51. And, this appears to be in the crux of the problem.  If I specify a UNIT
  52. and VOL on the DD statement, which we do, it appears that catalog management
  53. never gets involved - and so DFHSM never actually does a HRECALL.  This
  54. allocates space on the volume for the non-catalogged dataset named in the
  55. DSN and then deletes it at step completion (because of the step normal and
  56. abnornal disposition specifications of DELETE)  and the step completes looking
  57. just fine.  It would appear then, that the next step blows at it's step
  58. completion because it's trying to do a DISP=(NEW,CATLG,whatever) and the
  59. dataset is already cataloged as DFHSM Migrated.  A non-cataloged dataset
  60. was created and deleated in the IEFBR14 step.  At least, this is the
  61. most plausible explanation we can come up with.  (Sound reasonable?)
  62.  
  63. The weird thing is that on several occasions, trying to subsequently
  64. HRECALL this dataset fails - DFHSM says there is nothing to recall even
  65. though there is a catalog entry with VOLSER=MIGRATE, or DFHSM won't recall
  66. because a non-catalogged DSN of the same name has somehow appeared on the
  67. destination volume.  That was the impetus for my question.
  68.  
  69. So, let me ask a different question:
  70.  
  71. Do you have a foolproof (or user proof) way of insuring that a dataset is
  72. deleted in a preamble step - whether or not it previously exists - whether
  73. or not it is DFHSM Migrated - such that this step will end with a step
  74. return code of zero - and such that any future attempt to re-create
  75. this dataset in a subsequent step will not fail because of the physical
  76. pre-existance or pre-catalogged instance of this same DSN?  Oh - because
  77. SMS and storage classes are not involved, the VOL=SER absolutely
  78. needs to be defined as well.
  79.  
  80. Obviously IEFBR14 with DISP=(MOD,DELETE,DELETE) is not the answer since that's
  81. what we're doing now.
  82.  
  83. Thanks again.
  84.  
  85. -Dave
  86.  IBM Systems, George Mason University
  87.