HDTenEightyP/NetNews huggingface dataset:
From: SEB1525@MVS.draper.com (Steve Bacher)
Newsgroups: bit.listserv.ibmtcp-l
Subject: Re: restricting .../ P TCPIP,NETSTAT
Date: 3 Oct 92 18:57:00 GMT
Organization: Draper Laboratory

In article <IBMTCP-L%92100304553546@PUCC.PRINCETON.EDU>,
Leonard D Woren <LDW@USCMVSA.BITNET> writes:

>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.

I assume the SYSIN/SYSPRINT stuff is because these pieces of TCP/IP
were written in PASCAL.  IBM deserves credit for moving away from
assembler in their system code, but this has all kinds of fallout:
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.  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.)

>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.

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:-)?

>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.

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

>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.

Not to mention that a year from now it'll be moot for you...?

>/Leonard

Btw, we use AutoMate/MVS rather than TSSO, and I don't know offhand if
OBEYFILE works therefrom, or even if we try to control TCP/IP therevia.
I'll have to find out.

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Fri, 2 Oct 1992 16:47:50 MEZ
From:         Ernst-Axel Knabbe <R01KNA@DHHDESY3.BITNET>
Subject:      re: restricting .../ P TCPIP,NETSTAT

> 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.  This is
> not a new request.  CMS users can pipe NETSTAT output.  Why can't TSO
> users have analogous functionality???
>
> /Leonard

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.
All MVS program products I know offer either MODIFY or use a WTOR to
control their address space(s).

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

A.Knabbe
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Sun, 27 Sep 1992 14:16:00 PDT
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: Printing Problem of TCP/IP (2.2) for MVS

> I am also running TCP/IP V2.2 on MVS but I am able to print
> both ways.  I have noticed that the printer definitions for
> inbound printing to MVS from other hosts (UN*X) is case sensitive
> so if I want a laser printer on MVS accessible from other
> systems I need to define the printer name in lower case or have
> the users use upper case for the printer name.

I guess I could make some comment about how stupid the unix design of
bletch being different from Bletch is, but I won't.  ;-)

Anyway, we don't have printer names with upper case, so all printers
are defined once in lower case and once in upper case, pointing to the
same place.  (I'm not running LPSERVE on MVS at this time, but this
seems to work fine for LPR.  I've been told that we've run into some
problem on VM's LPSERVE with this double definition.)

> I have been able to make outbound printing work however, MVS LPD
> seems to convert all remote printer names into upper case.  In

I don't understand this.  We haven't seen this problem, although it
would be masked by the double definitions.

> essence I cannot print to a remote printer name which is in lower
> case.

We have no problem with LPR printer to remote printers which have
lower case names.  On the other hand, we're doing things a bit
differently:  Since unix users here don't have to know which remote
system a particular printer is attached to, I didn't think it was
reasonable for MVS users to have to know that either.  So I renamed
LPR/LPQ/LPRM/LPSET and front ended them with a Rexx exec.  That exec
looks for a host specification on the command line, which will
normally be missing.  If the host is missing, it reads the LPSERVE
config file (even though we're not running MVS LPSERVE) and finds the
remote host corresponding to the specified printer, and adds the host
specification to the command line, then issues the real command.
One thing that I had to do because of limitations in Rexx PARSE is I
force the whole command line to lower case, which effectively lower
cases the printer name.

Note that if you're entering LPR from the ISPF command line, most ISPF
panels have the command line defined with CAPS(ON), so you can't enter
TSO commands with lower case.  Dumb.

/Leonard
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Tue, 29 Sep 1992 13:05:41 MEZ
From:         Ernst-Axel Knabbe <R01KNA@DHHDESY3.BITNET>
Subject:      FTP autolog problem with MVS TCP/IP V2R2

After cancelling the FTP server, it does not come up again by itself,
although defined as AUTOLOGged. Also, it does not disappear from the
continuous NETSTAT display. Nevertheless, trying to do FTP from a
client is successful with the third try. Apparently the FTP request
triggers the AUTOLOG function. Does this work as designed?
Second question : Having APPLYed, but not yet ACCEPTed HCTP221 -
should I wait for V2R2M1; will it come as PTF or as a new function
sysmod?
A.Knabbe
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Tue, 29 Sep 1992 12:17:46 CET
Comments:     Converted from PROFS to RFC822 format by PUMP V2.2X
From:         "Llorente, Santiago" <SLLORENT@ESOC.BITNET>
Subject:      TCP/IP Dataset allocations

> Is is possible to define the parameters as members of a PDS
> rather than as individual sequential datasets ?

We've collected most of the TCPIP/NFS parameter files into a PDS.
For those configuration files that are dynammically allocated by TCPIP,
we add an extra step in the TCPIP procedure with an IEBGENER to copy
a member from our configuration pds to the dataset that TCPIP expects
to have. The member name is a parameter in the procedure so that we
can start tcpip with different configurations.

I think IBM should collect all the tcpip configuration files into a single pds.

> It is possible to direct a TELNET user to a specific TCPIP address space
> by defining a 'userid.TCPIP.DATA' dataset pointing to the specific
> TCPIP address space.
> If for any reason that TCPIP address space is not available is it
> possible to globally switch the users to a different TCPIP address space
> without manually editing the 'userid.TCPIP.DATA' datasets?

We don't use userid.TCPIP.DATA to select a TCP/IP address space for
the user. Instead we maintain 2 TCPIP.LINKLIB libraries. Each one
with a different DSPREFIX in CMMVSYS, this is the default prefix for
the TCPIP.DATA dataset. We use LIBDEF to allow the user to allocate
one of the 2 LINKLIBs, which, in the end, decides the tcpip address
space the user is going to work with:

     LIBDEF                DSPREFIX                   TCPIPUSERID
user -----> TCPIPx.LINKLIB -------> TCPIPx.TCPIP.DATA ----------> TCPIPx
                                                                  address space

In this way you only have to maintain a TCPIP.DATA dataset per tcpip
address space.
You can implement the global switch by updating TCPIPx.LINKLIB or
TCPIPx.TCPIP.DATA according to your needs.

> We have an environment consisting of two processors running MVS/ESA
> in a shared JES spool environment with shared DASD.
> Our requirement is to run multiple TCPIP address spaces on both
> of the machines.
> When a user on the SNA network selects TSO from his menu he may be
> logged on to TSO running on either machine.
> His TELNET request needs to be directed to a specific TCPIP address
> space depending on which machine he has been logged onto.
> Please could you suggest what parameters could be created to achieve
> this flexibility ?

I would allocate a different tcpip.linklib in the TSO initialization
depending on the machine where the user is logged on.


> Under TELNET the attention key may be used to invoke a TELNET command.
> Is it possible to pass the attention to an application ?

Press Attention and then type PA1 at the Telnet command query

Santiago Llorente                                SLLORENT AT ESOC.BITNET
European Space Operations Centre                 DE27PXNP AT IBMMAIL
Darmstadt (Germany)                              Phone: 49-6151-902517

End of Message
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Heidelberg University Computing Center
Newsgroups: bit.listserv.ibmtcp-l
Date:         Mon, 5 Oct 1992 11:36:45 CET
From:         Michael Hebgen <X02@VM.URZ.UNI-HEIDELBERG.DE>
Subject:      Re: Restricting Entry access in TCPIP V2.2 ESA
              2 Oct 1992 10:16:11 PDT from <YOSSIE@UCSFVM.UCSF.EDU>

In this context I also would like to bring in an idea I have sent to the
list about a year ago:

Today you have 3 choices to restrict access in TCP/IP:
- either nobody will get access (do not start FTPSERVE)
- or everybody valid on the host will get acces (start FTPSERVE)
- or limit the access via the exits (new in MVS TCP/IP V2R2)

At least in MVS we have a component called RACF (Resource Access Control
facility) which is more or less a database describing resources and users
and some rights. It would be nice to have standard exits in TCP/IP which
acknowledge corresponding entries in the RACF database - this way
an installation could denie access via TELNET/FTP/SMTP and so on on a
user basis with the normal methods (like terminal restriction we have
in RACF for TSO access).

In addition to this exits are necessary to enable specific restrictions
like IP number checking etc..

Regards, Michael Hebgen
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Mon, 5 Oct 1992 12:53:57 EDT
From:         Bill Rubin <rubinm@WATSON.IBM.COM>
Subject:      Re: Cum PTF tape for HTCP221

> A cum maint tape was included with the shipment.  Assuming there are
> 2.2.1 PTFs on it, are they all supposed to be installed as part of the
> initial 2.2.1 install?

No!  No!  No!  There are no PTFs available for 2.2.1 yet (but there should
be some built within a week or so, I hope).  I would imagine that this is
the same bad service tape which was shipped with 2.2 (ie, it had 2.1 PTFs
on it so nothing got received).  I will try to put a stop to this
immediately.  Unfortunately I suspect it is too late for the autoshipped
copies of 2.2.1 which went to US customers.  If you receive 2.2.1 without
the service tape, please let me know.  I'm not sure about the date for
non-US shipments, I will try to get that information and will post it
here.  I would imagine it will be one month from now, isn't that usually
the case?

> Can I test 2.2.1 using the 2.2 LPA modules?

You should be able to use the 2.2 LPA modules with 2.2.1 code, I am not
aware of anything that has changed that would prevent this from working.

Bill Rubin
IBM TJ Watson Research
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Wed, 30 Sep 1992 08:20:03 EDT
From:         TOSDRST@GE1VM.SCHDY.GE.COM
Subject:      NVAS-L@CUVMC (Netview Access Services-VTAM session manager)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From:
Subject: NVAS-L@CUVMC (Netview Access Services-VTAM session manager)
Good morning netters,
 I mention this NEW list here since many IBM/TELNET installations LOGAPPL
to this IBM session manager.
Regards,
Don Smith GE-Schenectady Megacenter

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From The Desk of Don Smith.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Tue, 29 Sep 1992 08:18:30 EDT
From:         "Louis J. Wiesemann" <LJWIES01@ULKYVM.BITNET>
Subject:      Assigning Ports to Applications

   We are trying to set up some terminal servers so that a user can select a
specific IP address and port to get to a specific VTAM application.  We have
the "DIAL VTAM" mods installed to automatically dial TCPIP connections to
VTAM.  Does anyone have any ideas that might help?

   We are running TCPIP V2R1 in VM/XA 2.1.

   Thanks for any hints.  I'm still a novice with TCPIP.


Louis J. Wiesemann
University of Louisville
Bitnet: LJWIES01@ULKYVM        Internet: LJWIES01@ULKYVM.LOUISVILLE.EDU
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Office: 324 Thorndike
Phone: (212) 854-8027
Newsgroups: bit.listserv.ibmtcp-l
Date:         Fri, 2 Oct 1992 09:31:21 EDT
From:         "Kenneth H. Lee" <khl@CUNIXF.CC.COLUMBIA.EDU>
Subject:      TTU DIAL mods for version 2

Has anyone gotten the TTU DIAL VTAM mods written for VM/XA V2 to work reliably
with VM/SP HPO 5 and VM TCP/IP V2R2?

As written, the mod to TNSTMAS PASCAL doesn't compile cleanly.  I had to make
some changes to the code so that it compiles.  Once beyond that hump, I was
able to generate a new TCPIP MODULE, but unfortunately it didn't work.  All it
did was leave me at a CP READ screen.

I had to go into the code and make some changes using the code for the version
1/HPO 5 mods as an example.  Once I had figured out what to do, I was able to
generate a TCPIP MODULE which worked properly sent the dial command.
Unfortunately for us, it doesn't work reliably.  There are times where we get
the VTAM MSG 10 and there are times where we end up with a CP READ screen.

Does anyone have any suggesions on how to make this mod stable and bulletproof?
We need to be able to guarantee that we will never end up at a CP READ screen
before we can make this available to the masses.  We are going to be LOGAPPLing
all our LUs to a multi-session software monitor so that everyone has to log
into the monitor before gaining access into our systems.


Kenneth H. Lee                          khl@cunixf.cc.columbia.edu
Columbia University                     rutgers!columbia!cunixf!khl
Box 700 Central Mail Room               khlcu@cuvmc.bitnet
535 West 120 Street, 324 Thorndike
New York, NY 10027-6629                 (212) 854-8027
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Tue, 6 Oct 1992 10:46:10 EDT
From:         Bill Rubin <rubinm@WATSON.IBM.COM>
Subject:      Re: TSO Notification for SMTP Inbound Mail

Frank Vance <FrankVance@AIRGUN.WG.WAII.COM> writes in response to:

> Lionel B. Dyck writes:
> >Is there an exit available with the MVS TCP/IP that will enable an
 installation
> >to send a message to a TSO user to inform them that they have mail to
 receive.
> >This exit would be analogous to JES2 Exit 13 or JES3 user exit IATUX42.
>
> I certainly have not found one.  I tried to open an APAR against this, and
> IBM told me it was not a defect (i.e. B.A.D.).   We have PASRed it.
> The PASR number is RKG5118.  On 2 Jun 92, it was closed ACCEPTED, so at
> least there is some hope it will get fixed before December 1993.

I have a question here, and please don't take it the wrong way.  When a
file arrives in the JES spool from NJE, the user is sent a message by JES,
correct?  If that is the case, then why doesn't JES also send a message
when a file arrives from the local system?  The spool file is certainly
being allocated in the DEST=node.user form.  Why should it be up to each
individual application to send a message when a file is sent?  Why doesn't
JES do it, he's the one delivering the file!

Bill Rubin
IBM TJ Watson Research
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Original_To:  JNET%"IBMTCP-L@PUCC"
Original_cc:  JURASCHEK
Newsgroups: bit.listserv.ibmtcp-l
Date:         Wed, 30 Sep 1992 16:33:00 EST
From:         "David F. Juraschek" <JURASCHEK@GMUVAX.BITNET>
Subject:      Re: Restricting Entry access in TCPIP V2.2 ESA

With respect to my original plea for information...

Someone noted that many times faculty and staff need to access a system
from the outside.
This is NOT the case here.  As I stated in my original post - we do NOT
want outside users to gain access to our system.  This is our administrative
(not academic) system, so user's outside the university have no need to
access the administrative functions on it.

Someone else noted that he hoped all our users would have userid's - so
what's the problem?
Again - NOT the case here.  Our administrative users do have userid's
with one exception.  We have an on-line library system on this box.  And,
we're connected to a consortium that expands the functionality of that
library system.  User's of the library system require NO signon.
Therein lies the rub.  We have people telneting into us from who-knows-where
and doing massive queries on our library system.  This is eating up resources
we can't afford to use.  Furthermore, since we are connected to a larger
library facility at the aformentioned consortium, people are telneting
into us to gain access to the consortium.  This may legally be a breach
of our access agreement to the library consortium.  (We're only allowed to
let OUR students and staff get to them.)  The problem is bad enough that
our internet address and connection information has been widely distributed
nationally as the method to get to this massive library consortium
system.  (Not by us, mind you.)
We can not change our software locally (VTAM, CICS or NCP) to restrict our
local users for other reasons.
Since the only breach is by users telnetting into us (and then skipping from
us to the consortium as if they were a legitimate local user) the solution
has to be for us to restrict entry telnet from IP addresses not within our
domain.

Again - the solution here is NOT for us to change the other software or
other configurations for a number of other reasons that are NOT important
to this request.  We need a solution in our TCP/IP system.

It's appreciated that some of you are only trying to clarify the problem
but it's been stated fairly clearly.

So again, how do I specify that non-subnet B type locations which match
our own can not gain entry to our system?

(Thanks SLLORENT@ESOC for the only useable response so far.)

Frustrated ...
-Dave
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Return-Path: <lbdyck@osreq48.rockwell.com>
Newsgroups: bit.listserv.ibmtcp-l
Date:         Tue, 6 Oct 1992 08:20:01 PDT
From:         "Lionel B. Dyck" <lbdyck@OSREQ48.ROCKWELL.COM>
Subject:      Re: TSO Notification for SMTP Inbound Mail

Bill Rubin writes:

        I have a question here, and please don't take it the wrong way.  When a
        file arrives in the JES spool from NJE, the user is sent a message by
        JES, correct?  If that is the case, then why doesn't JES also send a
        message when a file arrives from the local system?  The spool file is
        certainly being allocated in the DEST=node.user form.  Why should it be
        up to each individual application to send a message when a file is sent?
        Why doesn't JES do it, he's the one delivering the file!

The answer is simply that JES does not know that the message is a message. SMTP
just writes the message into the JES SPOOL.  For messages that arrive via NJE
the NJE reception routines are able to detect the fact that it is an inbound
message and thus invoke an exit to notify the recipient.


>>>  One of the most dangerous forms of human error is forgetting   <<<
>>>       what one is trying to achieve......Paul Nitze             <<<
*---------------------------------------------------------------------*
* Lionel B. Dyck              | Rockwell TSO:      WCC1.$A1238        *
* M/C:       110-SE28         | Rockwell VM:       ISCEMS(LBDYCK)     *
* Comnet:    797-1125         | IBMLink:           ROK2027            *
* Phone:     (310) 797-1125   | IBM Mail:          USROKNTN           *
* Fax:       (310) 797-3511   | Internet: LBDyck@osreq48.Rockwell.Com *
*---------------------------------------------------------------------*
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Addr: IBM, T.J. Watson Research Center Yorktown Heights,
        NY  10598 Phone (914)945-1869  Tieline 862-1869
Newsgroups: bit.listserv.ibmtcp-l
Date:         Wed, 30 Sep 1992 16:48:37 EDT
From:         Jay Elinsky <ELINSKY@YKTVMV.BITNET>
Subject:      Re: Restricting Entry access in TCPIP V2.2 ESA

Ref:  Your note of Wed, 30 Sep 1992 16:33:00 EST

You could set up TCPIP's routing table (GATEWAY statement) so it knows how to
route only to the networks that should have access.  The SYN packet from
outsiders' connection attempts will get to your system, but your system's
SYN ACK won't get out, so a usable connection won't be established.

                                       Jay Elinsky
                                       IBM T.J. Watson Research Center
                                       Yorktown Heights, NY
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Wed, 30 Sep 1992 15:41:09 -0500
From:         David Lippke <lippke@UTDALLAS.EDU>
Subject:      Re: selectex parameters
              92 6:11 am

> The C routine 'selectex' takes one ECB. But it is implemented by waiting on
> a list of ECBs, one of which is the one posted by the IRB scheduled on
> completion of the 'select' IUCV socket call. It wouldn't be hard to hack up
> a version of common_select (in CMIUCSOC) that took a list of user ECBs
> instead of just one.

True.  We have done this for a CMS version of selectex().
  Contact David Spano <spano@utdallas.edu> if you're interested in getting
  a copy of that.  It's really unfortunate that the original version doesn't
  operate that way.

/David
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Tue, 29 Sep 1992 22:21:00 EDT
From:         Fitch@DOCKMASTER.NCSC.MIL
Subject:      selectex parameters

Could someone post the parameters and types for calling selectex() ?
I'm using MVS TCPIP V2R1M0.  Our documentation is from a preliminary
release and has some typos.  The typos on the vanilla select() were easy
to fix - we looked at the Unix version - but we're stuck on the ECB
parameter of selectex().

If the ECB parameter allows for an array of ECBs, how is the number of
ECBs specified?

--Jack

Fitch@dockmaster.ncsc.mil