home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / bit / listserv / ibmmain / 2850 < prev    next >
Encoding:
Text File  |  1992-12-15  |  1.7 KB  |  42 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%92121522082255@RICEVM1.RICE.EDU>
  4. Newsgroups: bit.listserv.ibm-main
  5. Date:         Tue, 15 Dec 1992 20:08:00 PST
  6. Sender:       IBM Mainframe Discussion list <IBM-MAIN@RICEVM1.BITNET>
  7. From:         Leonard D Woren <LDW@USCMVSA.BITNET>
  8. Subject:      Re: WTO strings need not be inline anymore
  9. Lines: 31
  10.  
  11. (Please note that I'm not picking on the IBMer who posted the message
  12. that I'm quoting; I'm picking on IBM Corp.)
  13.  
  14. >   The WTO macro was used as an example of:
  15. >  'IBM's often limited interfaces (like WTO, with its requirement that you
  16. > you code the WTO string inline)'
  17. >
  18. >   This limitation was removed in MVS/ESA SP4.1.0 with the addition of the
  19. > TEXT parameter on the WTO macro.
  20.  
  21. Oh good.  So we can expect IBM to fix one boneheaded design error in
  22. OS every 25+ years?
  23.  
  24. Right now I'm trying to get TSO/E to remove the forced blksize=3120
  25. for log files in TRANSMIT and RECEIVE.  They claim this is a major
  26. design change, and are refusing to do it.  Since the replacement for
  27. the linkage editor finally removes the blksize=3200 restriction for
  28. its input, I expect to see TRANSMIT and RECEIVE fixed in the year
  29. 2022, based on my estimate of when TRANSMIT and RECEIVE came out.
  30. Of course, IBM will not be in business by then due to things like
  31. this.
  32.  
  33. From a very old "The Wizard of Id":  A sign on the wall behind the
  34. store clerk says "The customer is always wrong."  Rodney tells the
  35. clerk:  "There's something wrong with your sign."  The clerk says "No
  36. there isn't."
  37.  
  38. TSO/E development has already spent more time arguing with me over
  39. this than would be required to actually fix the code.
  40.  
  41. /Leonard
  42.