home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / bit / listserv / ibmmain / 2686 < prev    next >
Encoding:
Text File  |  1992-11-20  |  2.2 KB  |  50 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%92112021082897@RICEVM1.RICE.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Fri, 20 Nov 1992 19:05:00 PST
  6. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  7. From:         Leonard D Woren <LDW@USCMVSA.BITNET>
  8. Subject:      Re: IEFBR14
  9. Lines: 39
  10.  
  11. On Fri, 20 Nov 1992 12:56:00 CST,
  12.    Dave Ulrick <A01DGU1@NIU.BITNET> said:
  13. > I've heard of two bugs, actually:
  14. >
  15. > (a)  Originally, IEFBR14 did only a "BR  14".  ... Therefore, a PTF
  16. >      was issued to add the "SR  15,15" prior to the "BR 14".  Thus,
  17. >      the size of IEFBR14 was doubled overnight. :-)
  18.  
  19. I doubt if it was overnight, even though it only required adding one
  20. instruction.  Most of us could have done it overnight...  IBM
  21. probably closed it "Sugg", then upon appeal marked it "Under Study",
  22. then eventually changed it to "Long Range Consideration", and
  23. eventually fixed it in release n+2.  If you think I'm joking, call up
  24. and open an incident over TRANSMIT and RECEIVE having BLKSIZE=3120
  25. hard-coded for the LOG files.  That's closed SUGG.  It will not be
  26. fixed in TSO/E V2R4, scheduled for delivery 1Q93.
  27.  
  28. > (b)  It was not originally link-edited as being refreshable and
  29. >      reusuable.  Another PTF was issued (or so the story goes) to
  30. >      relink-edit IEFBR14 with those attributes.
  31. >
  32. > I heard all of this second-hand, of course, so I will happily
  33. > stand corrected.  If I'm right, though, there have been a total
  34. > of *two* bugs in IEFBR14.
  35.  
  36. I think this topic pops up on this list periodically.  And I also have
  37. some recollection of someone claiming there's now a new problem with
  38. IEFBR14 -- it's not marked RMODE(ANY) AMODE(ANY).  Anyone wanna try
  39. for another APAR?  ;-)
  40.  
  41. Suppose that you're running AMODE31, and you LOAD and BASSM to
  42. IEFBR14.  Won't you get control back in AMODE24?  This is a "rock and
  43. a hard place" problem, and as such it's probably not APAR-able.  If
  44. IEFBR14 were changed to return via BSM, then someone else would APAR
  45. the fact that if you call it via BALR, it fails, and they'd have to
  46. mark the PTF PE and change the code back.  Anyway, IEFBSM14 doesn't
  47. have the same ring...
  48.  
  49. /Leonard
  50.