NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/bit/listserv/ibmtcpl/3247

Text File | 1993-01-27 | 5.7 KB | 121 lines

Comments: Gated by [e-mail]
Path: sparky!uunet!uvaarpa!darwin.sura.net!paladin.american.edu!auvm!RICEVM1.RICE.EDU!TROTH
Message-ID: <[e-mail]>
Newsgroups: bit.listserv.ibmtcp-l
Date:         Tue, 26 Jan 1993 13:09:34 CST
Sender:       IBM TCP/IP List <[e-mail]>
From:         Rick Troth <[e-mail]>
Subject:      Re: IBM TCP/IP inadequacies ...
In-Reply-To:  Message of 23 Dec 1992 16:08:00 PST from <CSP1DWD@UCLAMVS>
Lines: 109

        [I'm sorry,  y'all;  finger-checked on that last one]

On Wed, 23 Dec 1992 16:08:00 PST Denis DeLaRoca 825-4580 (310) said:
>                                                                 What
>triggered this and other messages is the fact that severe and well
>known problems in fundamental areas of the product (ie, IUCV/VMCF)
>persist   ...
>
>You might ask why is IUCV/VMCF so important?  As it turns out IUCV/VMCF
>(and the VM platform) make up the essential bridge between user
>processes and the TCPIP kernel, every single TCPIP transaction goes
>thru that bridge, but this bridge is neither solid nor ample, you can
>fall from it very easily.

        Now you know.   Now you know from experience how we  (VMers)
feel,  how we've felt for the last twenty years.   NOTE:  this is *not*
an OS Wars trigger;  consider MVS and VM to be brothers in this thread.
Every other IBM-supplied application either must run stand-alone
(thank God for virtual machines)  or has some kind of  "bridge"
between it and the support system or kernel,  emulating OS/MVS on CMS.

> ... application in one split of my ISPF session and then start another
>tcp/ip app (whether it be from IBM or not) in a second split... I can't
>have that same tcp/ip app multitask and use tcp/ip services without the
>risk of losing access to IUCV from within my address space.

        Note that this doesn't happen in CMS.   (well ... maybe it does,
but it doesn't have to;  depends on how well the app was written)

        Denis,  what I think you want to ask for is a higher-level tool
for IBM Mainframe TCP/IP to be built on.   Under the covers,  this would
use IUCV on VM,  but use  (sorry I don't know what you've got)  whatever
is native to MVS inter-process comm when running on MVS.

>                    ...           any other tcp/ip applications that
>multitasks and/or shells out to other tcp/ip applications without
>running into some TCPIP problem, usually an IUCV/VMCF problem.  We have
>observed complex crashes in IUCV cleanup, we have observed user address
>spaces being left non-swappable by IUCV, the list goes on...

        It really smarts,  doesn't it.   Shout it;  scream it.
On the VM side,  we don't like it either,  but we've been getting it
for,  like I said,  most of twenty years now.

>The starting point for TCPIP was the VM work done at Wisconsin, but
>what was a virtuous, simple and glorified hack, in those days, has
>become totally obsolete and regressive.

        Whoa whoa whoa ... you frighten me.   While I agree that there
must be ongoing development in IBM TCP/IP,  *my* concern is that there
might be serious negative effects on the VM implementation if they
abandon what we have now.

>the fact that TCPIP for MVS is hosted by means of a badly engineered
>(and buggy) VM emulator platform is absolutely mind boggling...

        And,  you're gonna get sick of this,  we've had to put up with
a badly engineered (and buggy) OS emulator platform for twenty years.
(sorry,  I just hope that IBM will get the word that emulation ain't
as good as virtualization and that hacking MVS onto CMS or hacking C
onto either is stupid  (C compiler; another thread that doesn't belong
on IBMTCP-L,  though IBM TCP/IP hurts from it))

        You mentioned good engineering and modern operating systems.
Do you mean modular design and "micro kernel" concepts like found in CP?
That would argue for continued,  though certainly with some improvement,
use of the VM emulation you don't want.   Unless you're telling me that
MVS is now a micro kernel and no longer a monolith.   (no offense;
I really don't know;  been away from MVS for too long)

>It is clear that market pressures pushed IBM for an early release of
>TCPIP in what I'd consider a fundamentally flawed implementation, an
>implementation with inherent functional, performance and reliability
>limits.

        The VM implementation  (here I mean real VM,  not emulated)
is not a bad performer.   It could use some help,  but it's no where
near as bad as you describe MVS TCP/IP.

>I think these last requirements: performance, low resource utilization
>and rational network systems support are essential, nothing strange
>about them, and I would contend should be the areas that IBM should
>be putting all their resources and expertise to provide. I don't much
>care if they give me NFS and X-Windows support, I want the absolutely
>best tcp/ip engine that MVS is capable of hosting, with that building
>block in place the rest can be build around.

        Amen!

>But if today, right this minute you want a mainframe tcp/ip that can
>go 700-800Mb/s easily without overwhelming your CPU you go to the Cray
>folks not IBM. This at a time when gigabit networking and applications
>are just over the horizon doesn't argue too well for the future of
>tcp/ip on IBM mainframes.

        Which makes me ask,  when will we get OSI?

>                          Remember, part of this discussion was tri-
>gerred by the guy trying to do some real networking and trying to
>diminish the ensuing 90% overhead on his computer!

        Excellent point!

>Something radical has to happen, what will it be?

Stop BASIC before it stops you.   -- Dijkstra
Stop UNIX before it stops you.   -- Troth

Rick Troth <[e-mail]>, Rice University, Information Systems