Newsgroups: bit.listserv.ibmtcp-l
Date:         Sat, 3 Oct 1992 18:41:00 PDT
From:         Michael Stein <CSYSMAS@UCLAMVS.BITNET>
Subject:      Re: restricting .../ P TCPIP,NETSTAT

> I assume the SYSIN/SYSPRINT stuff is because these pieces of TCP/IP
> were written in PASCAL.

And Pascal doesn't have "real" TSO support?  Or the IBM TCPIP
group doesn't know MVS TSO?

> IBM deserves credit for moving away from assembler in their
> system code, but this has all kinds of fallout:

No, IBM deserves credit when they deliver working products in the
needed time/price point.  The language the product is written in
is just another part of the product offering.  Something to be
considered and important but not an end itself.

> depending on the language and the product we have seen SMP/E
> screwups, unpopular languages, grossly inefficient code, and/or
> failure to utilize traditional OS resources or facilities.

Right.  And before Pascal.  Remember PL/S?  Also ever get SMP
control statements with some script control statements included
for good measure?

> These are not insoluble problems - IBM's system-programmer-C
> business shows that they know which way to go - but you can't
> change a behemoth overnight.  (That could refer to IBM, your
> mainframe, or TCP/IP, as your discretion.)

What system-programer-C-business?  Where in the documentation
does it say how to write C code which can't issue *any* SVCs?
Which of the following or combination of the following should
be used to avoid C issuing *any* SVCs:

 - #pragma environment?
 - NOSTART compiler option?
 - the various EDCX*** alternate startup routines?
 - some other option(s) not listed here?

The text has some examples of some things, but no non-SVC case.
And since it's all "how to use" rather than what the options
actually do it's impossible to figure it out from the manual.

And after all that (and the CSECT option), you'll find out that
the included library routines have private code in them.

Where are the "system interfaces" for C?
SVC 99 is there, what about the other 100+ system services?

C is useful today, and has passed the Pascal support in
capability and usability, but it has a long way to go to really
be a systems language.  And as a HLL it still needs better code
generation for the simple stuff like "if (memcmp(a,b,l) == 0) ".

Pascal is dead.  (No AGGR compiler option - I have no idea what
all those records look like and I'm NOT about to play or write a
Pascal compiler to find out...)

> Eh?  I've used WTOR because I didn't want to make my started tasks
> require authorization.  Can you be more specific about why this is bad
> (there's a first time for everything, isn't there:-)?

Accepting MVS MODIFY and STOP commands does not require being
authorized.  Just some code, *any* batch job can do it.  TSO
sessions can't because the TMP is already using the interface
(communications ECB).  It's been this way since MVT at least...

There were even some messages on this topic in the last few weeks
on the JES2 list...

> Dang.  I was just about to blame PASCAL for the lack of MODIFY, and
> you just blew that theory away.

The modify commands to TCPIP go to the VM simulation "platform".
So the operator communication interface (only one per job) is in
use by the time the TCPIP module gets control from the platform.
The platform code would have to have some additional interface to
pass commands down to TCPIP as well as decide which commands
belonged to which (Platform or platform subject).

I'd rather the "platform" (as a "task") was junked.  Some special
subroutines are all that's needed, assuming you really absolutely
require simulating VM on MVS.  Certainly something less
monolithic than the mountain of PL/S code, most of which runs
authorized but doesn't really need to.

Going back to the HLL thread -- I'm convinced that if the
platform was in assembler instead of PL/S it would run better.
Either IBM or some customer would fix it.  As it is, IBM hasn't
the time-people-knowledge combination and the customers don't
have PL/S compilers.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU