Newsgroups: bit.listserv.ibmtcp-l
Date:         Thu, 28 Jan 1993 02:10:00 PST
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: IBM TCP/IP inadequacies

(You can never re-can a can of worms using the same size can...)

On Wed, 27 Jan 1993 10:30:32 EST,
   Gary Buhrmaster <TJF@CORNELLC.CIT.CORNELL.EDU> said:
> On Wed, 27 Jan 1993 01:54:00 PST, Leonard D Woren <LDW@USCMVSA.BITNET>
>    said:
> >On Tue, 26 Jan 1993 13:09:34 CST,
> >   Rick Troth <TROTH@RICEVM1.RICE.EDU> re-opened a can of worms:
> >> whatever is native to MVS inter-process comm when running on MVS.
> >
> >Well, there really isn't one, so every product has to invent their own.
> >This is one of the most glaring deficiencies in MVS.
> >

> Well, actually, IBM seems to be promoting APPC for communication, which

Bletch.  Another complex thing with an incomprehensible programmer
interface.  APPC/MVS needs to speak TCP/IP;  the APPC/MVS product
people don't seem to understand this.  (Also, there should be another
TIOC to support TSO logon through TCP/IP without going through VTAM.
And JES2(RSCS) should support JES2-JES2(RSCS) connections over TCP.
How much of this is likely to happen?  Why do I get the idea that most
of IBM regards TCP/IP as a wart on the side of MVS?)

> would allow you to run the server elsewhere in the gaggle of (smaller,
> cost effective) MVS/ESA machines in your sysplex.  However, when you

I'm sure there's an oxymoron in there somewhere.

> can be assured the server and client are within the same physical
> machine, the architected solution would seem to be AR mode where the
> server could directly access the private area(s) of the client, or a
> special TCP/IP dataspace used to exchange data between the client and
> the server using normal instructions without all the extra DAS
> overhead of moving data between the secondary and primary address
> spaces.  The performance could be outstanding.  As I recall that was

Yeah, right, all well and good, except for one thing.  AR mode
requires that you have an active addressing bind to the other
addressing space, or that you have it's local lock, or that it be
non-swappable.  These are generally Bad Things (tm).

> one of the big performance gains in the original UNIX TCP/IP
> implementations (passing pointers to the buffers rather than moving the
> buffer data).  Unfortunately, these features only work at current
> MVS/ESA levels, and IBM seems committed to continuing TCP/IP support
> for MVS/XA, which means they are limited to using facilties that it
> supports.

"I pray daily that programmers will be freed from the curses of
compatibility."  -- Edgar Dykstra  [I hope I remembered this correctly.]

It sure would be nice if MVS TCP/IP exploited some MVS/ESA features as
suggested above.  To do this IBM would either have to have dual path
code, or drop support for pre-ESA MVS.  I suspect there are enough XA
shops who would scream too loud for the latter to be a possibility.
For the former, in some cases there might be features which wouldn't
work pre-ESA.  But I think it's appropriate to try to provide the best
possible performance when running on a current MVS release.
Comments, IBM?

/Leonard

P.S.  Hmmm... how about connecting two MVS TCPIPs via XCF?
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU