home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / bit / listserv / ibmtcpl / 3062 < prev    next >
Encoding:
Text File  |  1992-12-29  |  3.7 KB  |  82 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!USCMVSA.BITNET!LDW
  3. Message-ID: <IBMTCP-L%92122817204530@PUCC.PRINCETON.EDU>
  4. Newsgroups: bit.listserv.ibmtcp-l
  5. Date:         Mon, 28 Dec 1992 14:20:00 PST
  6. Sender:       IBM TCP/IP List <IBMTCP-L@PUCC.BITNET>
  7. From:         Leonard D Woren <LDW@USCMVSA.BITNET>
  8. Subject:      Re: IBM's MVS TCP/IP problems
  9. Lines: 71
  10.  
  11. On Mon, 28 Dec 1992 11:09:31 EST,
  12.    Ron Lane <RONLANE@YKTVMV.BITNET> said:
  13. > When I entered the TCP/IP group three years ago (specializing in
  14. > the MVS side of things), all the talk was
  15. > on its slow performance.  That has been improved tremendously.
  16.  
  17. Right.  It now uses only 5 times instead of 10 times the amount of CPU
  18. that it should.  When we converted from another vendor product to IBM
  19. MVS TCP/IP, our total CPU usage for all TCP/IP functions went up by a
  20. factor of 7-10 over the previous product.
  21.  
  22. > Since that time we have added:
  23. > (...)
  24. >  5. Multitasking support for Sockets.
  25.  
  26. This is what I'm complaining doesn't work, and I was told by L2 that
  27. this isn't going to be fixed, at least not in this release.
  28.  
  29. > (...)
  30.  
  31. Now, all the stuff you listed that I've replaced with (...) isn't
  32. worth anything to my site, and I suspect a number of other sites.
  33.  
  34. > talked with Leonard Woren personally to assure him that IUCVMULT will
  35. > soon be reentrant, and I think that will allow him to run his
  36.   ~~~~
  37. > PIE/TSO.
  38.  
  39. That's half of the solution.  You must anchor the table somewhere
  40. that's not dependent on a TCB that might go away, and you have to
  41. solve the problem of the IRB belonging to a TCB that may go away.
  42. Oh... can you define "soon"?  You've been promising us privately and
  43. publicly for a good part of a year that fixing this is your "highest
  44. priority project", yet we've seen nothing.  That's why we're upset.
  45.  
  46. Our last communication on this subject was a proposal from you to
  47. front-end the IUCVMULT front-end.  I pointed out why that solution
  48. wouldn't work, and I never heard from you again.  (You also told me
  49. that making IUCVMULT rent wouldn't happen in the near future.)  Try to
  50. understand why I feel the way I do.
  51.  
  52. > We are always open to suggestions or constructive criticism, because
  53. > we improve through feedback. But venting spleen does not
  54. > create a healthy atmosphere for cooperation and dialogue.
  55.  
  56. When I have problems which have been open for a long time, and/or
  57. major usability problems that shouldn't be any big deal to fix, and
  58. when I'm told that IBM is closing *all* of them as "submit a
  59. requirement," I get a bit pissed.
  60.  
  61.  
  62. Bitnet has just raised the minimum limit for mail to 1M, with a
  63. recommendation to support at least 3M.  With MIME coming into use even
  64. 3M could be much too small.  But IBM MVS TCP/IP out of the box doesn't
  65. support 3M without a zap, which is not acceptable.  (Note that the
  66. manual states that the range for MAXMAILBYTES is 1 to 2**31-1, but
  67. the product doesn't actually support this.  This is non-trivial to fix
  68. due to broken design, so IBM is not going to fix it.  Do you think
  69. that "Submit a requirement" is a reasonable response for this???  If
  70. this was fixed right, it would improve the abysmal performance of
  71. SMTP a bit.  Most customers probably aren't aware that SMTP goes
  72. through EOV for every piece of mail larger than one track.  EOV is
  73. expensive.  And if the mail is large, SMTP could go through EOV 15
  74. times!  And if it's a bit bigger, SMTP abends with an SB37.  The
  75. remote host requeues the mail for later retransmission, TCPIP auto-
  76. restarts SMTP, the mail is retransmitted, and SMTP abends again.  And
  77. the only thing that the receiving site can do is change MAXMAILBYTES
  78. downward to whatever fits in 1+15*3 tracks.  How many customers out
  79. there feel that this is reasonable and doesn't need to be fixed now?
  80.  
  81. /Leonard
  82.