home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / bit / listserv / ibmmain / 1812 < prev    next >
Encoding:
Text File  |  1992-07-27  |  4.6 KB  |  114 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!USCMVSA.BITNET!LDW
  3. Message-ID: <IBM-MAIN%92072718545419@RICEVM1.RICE.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Mon, 27 Jul 1992 16:53:00 PDT
  6. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  7. From:         Leonard D Woren <LDW@USCMVSA.BITNET>
  8. Subject:      Re: Esoteric Device Message in ESA 4.2
  9. Lines: 103
  10.  
  11. On Mon, 27 Jul 1992 14:53:00 PDT,
  12.    Dave Friedman 510-642-5823 <SPGDNF@UCBCMSA.BITNET> said:
  13. > (...)
  14. > If the dataset is cataloged via UNIT=DISK and DISP=(,CATLG) in jcl, the
  15. > catalog shows a DEVICETYPE of X'3010200F'.  The same thing happens if we
  16.  
  17. 3010200F is the UCB device type for 3390.
  18.  
  19. > catalog the dataset using IDCAMS DEFINE ... NONVSAM DEVTYPE(3390), and
  20. > if we catalog the dataset with a WYLBUR command (apologies to Leonard).
  21.  
  22. Whether it's JCL, IDCAMS, or Wylbur (a horse is, uh, oh never mind),
  23. it's the CATALOG SVC that's doing the real work, so getting the same
  24. value in the catalog entry is to be expected.
  25.  
  26. > However, if we catalog the dataset using IDCAMS DEFINE ... NONVSAM
  27. > DEVTYPE(DISK), the catalog shows a DEVICETYPE of X'0003200'.
  28.  
  29. However, in this particular case (the same would happen with IEHPROGM),
  30. the program has no way of knowing the correct device type.  Duh, why
  31. not scan the online volumes to locate it?  Because this logic hasn't
  32. changed since most disks were removable, and they had to make it work
  33. for non-mounted disks.  An interesting exercise would be to try to get
  34. IBM to fix IDCAMS and IEHPROGM to look for an online volume in the
  35. specified unit group and pick up the correct device type.  Good luck.
  36. (Why do I have to specify UNIT= *at all* if I specify VOL=SER= for an
  37. online disk???  That's one of my pet peeves with MVS.)
  38.  
  39. > I guess the first question is why is IDCAMS using X'0003200'?  However,
  40.  
  41. This is documented somewhere, but I don't remember where.  The X'20'
  42. in the third byte is the device type (dasd), the same as in 3010200F.
  43. The first halfword (0003) is the relative entry number in your
  44. UNITNAME macros of the UNITNAME DISK.
  45.  
  46. > this is also true in our ESA 3.1.1 system, and it does not generate any
  47. > JES2 messages there.
  48.  
  49. Must be a new feature, or maybe just a higher maintenance level.
  50.  
  51. >     IEF348I dsname WAS FOUND TO BE CATALOGED USING ESOTERIC DISK
  52. >             INSTEAD OF A GENERIC
  53.  
  54. Well, that's true.
  55.  
  56. > The ESA 4.2 messages manual says that this is to warn the user in case
  57. > the system I/O configuration changes.
  58.  
  59. Yep.  If you change the *relative* position of the UNITNAME=DISK in
  60. your gen, all datasets cataloged using 00032000 will likely get
  61. catalog errors when access is attempted.
  62.  
  63. > The manual seems to be advising
  64. > the systems programmer to recatalog the dataset using a generic.
  65.  
  66. You should apar the manual (i.e., send in a reader comment form) if
  67. that's what it says.  The person responsible for creating the dataset
  68. should fix it.
  69.  
  70. > In our shop the systems programmer does not mess around with
  71. > application files.
  72.  
  73. That's probably the norm.
  74.  
  75. > Anyway, it would be a never-ending task, since we recommend to
  76. > our application staff that they use esoterics rather than generics.
  77.  
  78. Esoterics are definitely preferable for creating new datasets.  But
  79. for cataloging existing datasets, the actual device type should
  80. *always* be used, for exactly the above reason.
  81.  
  82. > ...  However, I wonder if anyone else has encountered this problem and
  83. > found a way to suppress the JES2 message.
  84.  
  85. Maybe you could use console automation to intercept the message and
  86. recatalog the dataset correctly?  Then you'd only get the message once
  87. per incorrect catalog entry, and there would be no ongoing manual
  88. effort involved in correcting them.
  89.  
  90. > Is there some reason why JES2 should be giving people this "reminder"
  91. > every time they access a file cataloged with IDCAMS and an esoteric?
  92.  
  93. Yep.
  94.  
  95. > It seems like nagging.
  96.  
  97. Yep.  Using an esoteric in IDCAMS or IEHPROGM should be considered an
  98. error.  This is IBM's way of convincing you to do it right, without
  99. actually making it fail.
  100.  
  101. > Is this message a result of the IBM
  102. > orientation toward SMS?  We are not yet an SMS shop.
  103.  
  104. Either that or a response to constant problems caused by the UNITNAME
  105. positions changing.  The manual says that the systems programmer can
  106. never move or delete UNITNAMEs once they're defined, because it'll
  107. cause problems.  Most systems programmers don't know this.  I've
  108. always ignored it, because I've always considered those catalog
  109. entries to be erroneous.  When I first came here, I recataloged
  110. thousands of incorrectly cataloged datasets so that I could clean up
  111. the UNITNAMEs.
  112.  
  113. /Leonard
  114.