Newsgroups: bit.listserv.ibmtcp-l
Date:         Sat, 3 Oct 1992 01:55:00 PDT
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: restricting .../ P TCPIP,NETSTAT

On Fri, 2 Oct 1992 16:47:50 MEZ,
   Ernst-Axel Knabbe <R01KNA@DHHDESY3.BITNET> said:
> > Come on IBM, how about providing some tools for TSO?  Throw away all
> > the TPUTs and TGETs and use PUTLINE/GETLINE/PUTGET everywhere.  Then
> > we'd at least have a chance to develop some of these things.
>
> I find it very annoying, that our operators cannot use a
> MODIFY TCPIP,NETSTAT ... command to check the status of TCPIP or
> MODIFY TCPIP,STOP/START LCS1  to restart an interface.

Yeah.  I had to give obey authority to an operator TSO id so they
could restart the driver without calling me when the hardware rolls
over.  I don't like that idea.  What I wanted was to implement a TSSO
command to do the START.  But for some reason OBEYFILE won't work
under TSSO.  I don't remember why not.  (TSSO runs the TMP in batch
mode under a started task.)  I'm just sort of resigned to the fact
that nothing with this product ever works in a reasonable manner on
MVS.  And it doesn't have to be that way...  Some small changes could
help a lot.  SPECIFICALLY, USING PUTLINE/GETLINE/PUTGET.

Well, I tried playing with this some more just now, and I've
determined that I can get OBEYFILE to run under TSSO by running an
exec that allocates SYSIN to DUMMY and SYSPRINT to a work file which
is printed by the exec after obeyfile ends.  It's not at all obvious
why SYSIN is required, since whatever is in it seems to be ignored.
NETSTAT abends with IEC212I 414-08 when run this way.  Apparently
somebody forgot to close SYSPRINT...  Of course, all of this SYSPRINT/
SYSIN nonsense (including whatever FTP uses) could be thrown away if
everything was changed to use PUTLINE/GETLINE/PUTGET.  Getting the
idea yet?  I.e., use PUTLINE etc and all the batch-specific code can
be deleted, and the usability of everything is improved since the TSO
commands would then be usable in "smart" clists.

> All MVS program products I know offer either MODIFY or use a WTOR to
> control their address space(s).

Whoa!  *ALL* software that has an outstanding WTOR is *broken*.  In
fact, just about any use of WTOR is a design error.  I think that the
WTOR service itself should be restricted to MVS internal use.

Yes, MODIFY is the way this should be done.  In fact there are a
number of MODIFY commands that are accepted by TCPIP V2 (enter
F TCPIP,HELP for a list.)  But START and NETSTAT are not among them.
They should be.  I'd suggest submitting a PASR and/or SHARE
requirement.  I'm not going to bother... I'm getting too burned out
with this product and the lack of MVS consideration in its design and
implementation.

> The primary MVS operating tool is a MCS system console, not a TSO
> terminal.

I'm not sure I agree with this part...  For example, I'd much rather
have an operator hitting enter in SDSF DA than repeatedly entering
D A,L and cluttering syslog.  In general, it's much easier to provide
better operator interfaces on TSO than via MCS consoles.  However, the
need for MVS TCP/IP to have a MODIFY interface still stands, since
most operators feel more comfortable with the MCS console.

The OBEYFILE scheme is very cumbersome, particularly on MVS.  It is
useful for changing config parameters, but for doing things like START
there need to be alternative means.  And another problem with
OBEYFILE, like the rest of MVS TCP/IP, is that it doesn't accept input
from PDS members.  (MVSNFS did, but it's no longer part of TCPIP!)  So
we have to have the clutter of lots of very tiny sequential datasets.
And OBEYFILE is an all-or-nothing thing.  Once operators are given
OBEY authority, the door is open.  Sort of like *ix -- only one
privilege (root) exists.

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