Newsgroups: bit.listserv.ibmtcp-l
Date:         Tue, 22 Dec 1992 19:49:00 PST
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      MVS TCPIP problems (was Re: Usage of vector facility for TCP/IP?)

> >  "You're selling me the fastest general available computer on the
> >   planet and it connects to my network via this straw?"...

And the straw is kinked, restricting how much you can force through it.

> ...and that straw many times plain doesn't work. The current release
> of TCPIP continues to offer unsurmountable impediments to the develop-
> ment and deployment of client/server applications using concurrent
> tcp/ip services...

After a very discouraging phone call with TCPIP L2 and then with the
TCPIP services manager, I will publicly say that I agree.  For most of
the problems that I've had open for months, I was told they're not
going to be fixed, and that I can submit requirements.  By the time
MVS TCPIP is usable, MVS won't be around.  Certainly not here.  Lack
of a decent MVS TCPIP will do more to kill off MVS than cheap unix
workstations are doing.  The future of computing (actually, it's here
now) is networked computing.  Any system that doesn't play in that
networked world will die.  Just because MultiTSO doesn't come from IBM
is no justification for refusing to make IBM products work with it.
If IBM had vision, TSO/E from IBM would look something like MultiTSO.
MVS/DFP has just sent me a PTF to fix a very old VIO problem under
MultiTSO.  For years they refused to fix it.  At least *they* have
seen the light.  But if TCP/IP isn't usable under MultiTSO, if you
can't write multitasking servers, then that work will move elsewhere,
to platforms where it does work.


Here's a sampling of what I'm talking about:

Problem:   Simultaneous FTP/TELNET/any_VMCF_client in different Pie
           MultiTSO sessions results in address space termination with
           S40D.
Response: "Submit a requirement."

Problem:   SMTP abends SB37 on incoming mail > 1.9MB due to hard-
           coded space value.
Response: "Submit a requirement."

Problem:   IUCVMULT kludge doesn't allow multiple applications in
           different pie sessions.
Response: "Submit a requirement."

Problem:   FTP TSO client doesn't honor dsprefix when looking for
           FTP.DATA.
Response: "Submit a requirement."


Note that these problems are *all* specific to the MVS version of
TCP/IP.  Most of them are difficult to fix due to the internal design
of TCP/IP.  The inability to reasonably do sockets applications under
different TCBs in an address space is the show-stopper that Denis
referred to above.  The design of the whole IUCV interrupt mechanism
is fatally flawed.  It has taken me a while, but I now think that I
know how to kludge it up some more to make it work.  But IBM isn't
interested, and since TCP/IP is a source-distributed OCO product, I
don't think I can fix it myself.

> it is an acknowledged problem and I am beginning to develop the
> suspicion that IBM doesn't give a hoot about these defficiencies.

Yep.  They have "higher priority" problems that must be fixed.  But
the problem is that this multitasking issue never rises high enough on
the list to be worked on seriously.  A solution was proposed to me.
When I pointed out why that solution wouldn't work, that seemed to be
the end of it.  I have been told in no uncertain terms that these
problems are not going to be fixed in this release, if at all.


I won't even comment on the performance problems which prompted this
thread, except to say that the salespeople selling the big iron must
be happy with the product.

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