Newsgroups: bit.listserv.ibmtcp-l
Date:         Mon, 28 Dec 1992 14:20:00 PST
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: IBM's MVS TCP/IP problems

On Mon, 28 Dec 1992 11:09:31 EST,
   Ron Lane <RONLANE@YKTVMV.BITNET> said:
> When I entered the TCP/IP group three years ago (specializing in
> the MVS side of things), all the talk was
> on its slow performance.  That has been improved tremendously.

Right.  It now uses only 5 times instead of 10 times the amount of CPU
that it should.  When we converted from another vendor product to IBM
MVS TCP/IP, our total CPU usage for all TCP/IP functions went up by a
factor of 7-10 over the previous product.

> Since that time we have added:
> (...)
>  5. Multitasking support for Sockets.

This is what I'm complaining doesn't work, and I was told by L2 that
this isn't going to be fixed, at least not in this release.

> (...)

Now, all the stuff you listed that I've replaced with (...) isn't
worth anything to my site, and I suspect a number of other sites.

> talked with Leonard Woren personally to assure him that IUCVMULT will
> soon be reentrant, and I think that will allow him to run his
  ~~~~
> PIE/TSO.

That's half of the solution.  You must anchor the table somewhere
that's not dependent on a TCB that might go away, and you have to
solve the problem of the IRB belonging to a TCB that may go away.
Oh... can you define "soon"?  You've been promising us privately and
publicly for a good part of a year that fixing this is your "highest
priority project", yet we've seen nothing.  That's why we're upset.

Our last communication on this subject was a proposal from you to
front-end the IUCVMULT front-end.  I pointed out why that solution
wouldn't work, and I never heard from you again.  (You also told me
that making IUCVMULT rent wouldn't happen in the near future.)  Try to
understand why I feel the way I do.

> We are always open to suggestions or constructive criticism, because
> we improve through feedback. But venting spleen does not
> create a healthy atmosphere for cooperation and dialogue.

When I have problems which have been open for a long time, and/or
major usability problems that shouldn't be any big deal to fix, and
when I'm told that IBM is closing *all* of them as "submit a
requirement," I get a bit pissed.


Bitnet has just raised the minimum limit for mail to 1M, with a
recommendation to support at least 3M.  With MIME coming into use even
3M could be much too small.  But IBM MVS TCP/IP out of the box doesn't
support 3M without a zap, which is not acceptable.  (Note that the
manual states that the range for MAXMAILBYTES is 1 to 2**31-1, but
the product doesn't actually support this.  This is non-trivial to fix
due to broken design, so IBM is not going to fix it.  Do you think
that "Submit a requirement" is a reasonable response for this???  If
this was fixed right, it would improve the abysmal performance of
SMTP a bit.  Most customers probably aren't aware that SMTP goes
through EOV for every piece of mail larger than one track.  EOV is
expensive.  And if the mail is large, SMTP could go through EOV 15
times!  And if it's a bit bigger, SMTP abends with an SB37.  The
remote host requeues the mail for later retransmission, TCPIP auto-
restarts SMTP, the mail is retransmitted, and SMTP abends again.  And
the only thing that the receiving site can do is change MAXMAILBYTES
downward to whatever fits in 1+15*3 tracks.  How many customers out
there feel that this is reasonable and doesn't need to be fixed now?

/Leonard
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU