HDTenEightyP/NetNews huggingface dataset:
Return-Path: <TOM@PENNDRLS.UPENN.EDU>
Newsgroups: bit.listserv.ibmtcp-l
Date:         Thu, 17 Dec 1992 11:39:46 EST
From:         "Thomas D. Denier" <TOM@PENNDRLS.UPENN.EDU>
Subject:      Message TCPPC3001I under MVS

We are running MVS TCP 2.2.1 under MVS 4.2. We are seeing thousands of copies
of the following message:

TCPPC3001I PCCA3 device L3172A: FindLineNumber fails for NetType 1
AdapterNumber 1

in the SYSDEBUG data set from the TCPIP started task. The message appears on
single line in that data set, but has been split into two lines above to
fit comfortably into mail viewing screens. The documentation claims that no
response is required (which leads me to wonder why IBM bothers issuing the
message once, much less thousands of times). However, I cannot afford to
simply ignore these messages, if only because of the spool space they use.

The device name notwithstanding, the LAN interface is an 8232 with two
Ethernet cards. Even though the message makes reference to AdapterNumber 1,
the adapter is the first one installed, which is described as number 0 in
the LINK statement in TCPIP.PROFILE.TCPIP.

Is there any good way of getting rid of these messages? I have thought of
changing the SYSDEBUG DD statement to DUMMY, but I would prefer a method
that preserves useful messages sent to that DDNAME.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Tue, 15 Dec 1992 10:46:09 -0500
From:         eas4@POP.CWRU.EDU
Subject:      Re: APAR/PTF Release numbers

>
>> I am about to install TCP/IP V2R2.1 for MVS.  Program number 5735-HAL.
>> My boss show me an APAR (PN26803), and said to make sure it is applied
>> when I do the install.  The APAR says that a PTF is available for this
>> APAR.  Then it lists Release numbers (201, 202, 203, & 204).  How do
>> these numbers relate to my level?  I thought I was installing Version 2
>> Release 2.1?  Please explain!
>
>That PTF is for the previous version of the product (V2.2? or
>V2.1?).  You either need a new fix (PTF) or else it's already
>been included in V2.2.1.

It's confusing.  Sometimes the "Release Number" seems to coincide nicely
with the release you're installing (1.3.1 = release 301) and sometimes not
(1.3.1 = release 304).  I've never figured out an exact rhyme or reason to
it.  It seems to be an internal IBM thing.  (Perhaps to distinguish
TCPIP/MVS 2.2.1 from TCPIP/VM 2.2.1???  Things like that?)  But as you
pointed out, there is often a need to figure out which "release number" (I
put it in quotes because it does not always correspond to the
release.modification) you are dealing with, in order to determine the
correct PTF to install.

Get very familiar with the program directory (PGMDIR) for the product (it
should've come with the tape).  I'm looking at the PGMDIR for MVS TCPIP
2.2.1.  Chapter 3, "Program Support" lists all of TCPIP V2.2's parts, along
with their FMIDs, Component IDs, and "Release Numbers".

Also, check in the very back of the program directory (mine is Appendix B)
- there should be an appendix that lists all of the PTFs that have been
incorporated into the release that you are installing.  If the PTF in
question is not on that list, did you receive a service tape with the
product?  Is it on that tape?  If not, call IBM.

One final hint that may be useful in situations where you can't get your
hands on the PGMDIR for one reason or another...Do you have access to
IBMLink?  There is a shortcut selection (I've never found it on any menu)
called PSGIM.  It's like a little database access routine that lets you
enter either the Component ID, program number, or Component Name, (or masks
of any of the aforementioned), and get back all of the "hits" in their
database.  One of the pieces of information that comes back is the "Release
Number".  SO if you know the component ID, you can find out "Release
Number".  Warning: try not to depend on "Component Name".  It's extremely
inconsistent, and often  terse.  Stick to the more precise and reliable
Component ID and FMID as search keys when possible.

Also, I believe PSGIM requires a special (read billable) IBMLink type of
service.  Some of my friends at other datacenters can't get to it.  I think
if you can submit ETRs, you should be able to get to PSGIM.

Hope this helps.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Fri, 11 Dec 1992 10:12:00 PST
From:         Michael Stein <CSYSMAS@UCLAMVS.BITNET>
Subject:      Re: APAR/PTF Release numbers

> I am about to install TCP/IP V2R2.1 for MVS.  Program number 5735-HAL.
> My boss show me an APAR (PN26803), and said to make sure it is applied
> when I do the install.  The APAR says that a PTF is available for this
> APAR.  Then it lists Release numbers (201, 202, 203, & 204).  How do
> these numbers relate to my level?  I thought I was installing Version 2
> Release 2.1?  Please explain!

That PTF is for the previous version of the product (V2.2? or
V2.1?).  You either need a new fix (PTF) or else it's already
been included in V2.2.1.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: bit.listserv.ibmtcp-l
Date:         Wed, 16 Dec 1992 10:07:02 CST
From:         Frank Vance <fvance@WG.WAII.COM>
Subject:      Re: IBMLink
              92 2:41 pm

Steve Perez writes:
>
> Is there an Internet access point into IBMLink? If so, besides terminal
> access, is it possible to FTP fixes, announcements, etc?
>
> I bet my boss that I'd get an answer from this list before he'd get one
> from our SE.
>
I am not aware of one.  We have one internally, but it is not available for
outside use.

It is very easy to set one up.  Run TCP/IP on your MVS host, which has a
connection to IBMLINK.  Telnet works great.


--
Frank Vance  +1.713.963.2426            Western Geophysical
fvance@airgun.wg.waii.com               10001 Richmond Avenue
Fax: +1.713.963.2758                    Houston, TX 77042   USA
From: ost@uni-muenster.de (Stefan Ost)
Newsgroups: bit.listserv.ibmtcp-l
Subject: Re:      re: apar 30384
Date: 18 Dec 1992 12:57:08 GMT
Organization: Westf. Wilh.-Universitaet Muenster, Germany
Distribution: world
NNTP-Posting-Host: sysix1.uni-muenster.de

In article <IBMTCP-L%92121613550721@PUCC.PRINCETON.EDU>,         Ron Lane <RONLANE@YKTVMV.BITNET> writes:
|> An append yesterday mentioned the 'security problems' with
|> apar 30384 with FTP in release 2.2.1.  The extent of this problem
|> is that sometimes, though not too often, a person will be
|> doing a DIR under the authority of another userid because the
|> TCBSENV ACEE field has not been cleared up from a previous
|> user, and because DIR did set the TCBSENV field itself to change it.
|> This does not affect GET and PUT, because they always change the
|> TCBSENV field when they run.
|> 
That is not the hole story. If you try to purge job output via FTP, the
same symptons occur sometimes, though very often.
|> Ron Lane
|> TCP/IP Development

Stefan 
 
Universitaetsrechenzentrum der Westfaelischen Wilhelms-Universitaet
Einsteinstrasse 60, D-4400 Muenster, Germany        +49(251)83-2681
Bitnet: ost@dmswwu2e           Internet: ost@obelix.uni-muenster.de
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Wed, 16 Dec 1992 13:43:54 EST
From:         Ron Lane <RONLANE@YKTVMV.BITNET>
Subject:      re: apar 30384

An append yesterday mentioned the 'security problems' with
apar 30384 with FTP in release 2.2.1.  The extent of this problem
is that sometimes, though not too often, a person will be
doing a DIR under the authority of another userid because the
TCBSENV ACEE field has not been cleared up from a previous
user, and because DIR did set the TCBSENV field itself to change it.
This does not affect GET and PUT, because they always change the
TCBSENV field when they run.

Ron Lane
TCP/IP Development
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Wed, 16 Dec 1992 00:12:00 PST
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: FTP & ANONYMOUS

You might be able to write a RACF exit to disallow access by the
anonymous userid to all but the desired index level.  I don't think
that restricting CD would do it, because the remote user could simply
enter a fully qualified dataset name for get/put/delete.

It would be easier to use exit FTCHKCMD to examine the dsname and
userid, and reject things there, but having the code in the security
system gives me a warmer fuzzy feeling.  On the other hand, FTCHKCMD
can easily be changed without an IPL, unlike RACF exits.  (If you
really know what you're doing, ACF2 exits can be changed without an
IPL.)

Of course, I would claim that if most datasets on your system are
unprotected, you have more to worry about than anonymous FTP.

WARNING:  Anyone running ACF2 needs a small usermod to FTP before
allowing anonymous FTP on MVS, or you will have a huge security hole.
If IBM would add an FTP init parm to allow the installation to specify
the security system userid to be used for anonymous, this mod would be
unnecessary.  I believe that I submitted a SHARE requirement for this;
I don't know what happened to it.

/Leonard
Organization: Penn State University
Date: Wed, 16 Dec 1992 09:42:47 EST
From: Peter M. Weiss <PMW1@psuvm.psu.edu>
Newsgroups: bit.listserv.ibmtcp-l
Subject: Re: Is ALTTCPHOSTNAME repeatable?

In article <IBMTCP-L%92121517302704@PUCC.PRINCETON.EDU>, "TCP/IP Maintenance
(408) 656-3313" <TCPMAINT@NAVPGS.BITNET> says:

>ALTTCPHOSTNAME cc.nps.navy.mil

While you're at it, it would be nice if your NAD used the UPDATE
procedure so that your Bitearn Nodes entry added an _additional_
operand to your :internet.  tage of vm1.cc.nps.navy.mil

This is a listserv-friendly thing to do.

/Pete (pmw1@psuvm.psu.edu)
--
Peter M. Weiss                     | not affiliated with psuvm.psu.edu|psuvm
31 Shields Bldg -- Penn State Univ.| "Connectivity is more than a Connection"
University Park, PA USA 16802-1202 | E. Michael Staman, _The Circuit_, Apr 92
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: State University of New York at Buffalo
Newsgroups: bit.listserv.ibmtcp-l
Date:         Fri, 18 Dec 1992 14:18:33 EST
From:         "Steven P. Roder" <TKSSTEVE@UBVM.CC.BUFFALO.EDU>
Subject:      LPD "transparent mode"

Am I missing some maintenance?, or perhaps have something misconfigured?
I need to accept TexRox files from a UNIX machine, and need to bypass
translation on these files.  They are in a binary format (actually, I think
they are in Xerox Metacode).  LPD always wants to translate to EBCIDIC.
How can I tell LPD to not translate the files?  Do I really have to modify
LPD to allow binary files to passthru untouched?  I see APAR PN16345 added
a BINARY|NOBINARY option to LPR, isn't there a corresponding APAR to do
the same thing for LPD?

Thanks,

Steve Roder
(tkssteve@ubvm.bitnet | tkssteve@ubvm.cc.buffalo.edu | (716)645-3564
Newsgroups: bit.listserv.ibmtcp-l
From: SYS0008@MVS.UDEL.EDU
Subject: MVS FTP server problem
Organization: University of Delaware
Date: Mon, 14 Dec 1992 15:27:00 GMT

Here at the UD we've ran across a security problem with the MVS 2.2.1
FTP server, and feel it's serious enough that other people ought to be
aware of it too.  For more info, check out APAR PN30384.  We've
experienced the problem several times over the last few weeks and
although the APAR implies that only the DIR command is a problem, for us
it appears that it's a problem with PUT/GET as well.

Hopefully there'll be a fix for it soon!

Shawn.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: bit.listserv.ibmtcp-l
Date:         Thu, 17 Dec 1992 13:08:47 CST
From:         Frank Vance <fvance@WG.WAII.COM>
Subject:      Re: IBMLink
              "eas4@nextsun.INS.CWRU.Edu" at Dec 17, 92 10:53 am

eas4@nextsun.INS.CWRU.Edu writes:
>
> Frank - am I correct in assuming that you have an SNI connection (VTAM
> subarea to subarea) to IBMLink via a 37x5 FEP running NCP?  I've been
> thinking about your response ever since I saw it and that's the only way I
> can figure that would support your description.
Yes, this is correct.

> If wishes were thousands of dollars, I'd have that set-up, too.  It's the
> superior way to communicate with IBM and the way I accessed them in my
> previous job.  But that solution is absolutely cost prohibitive, and I
> don't believe a 3745 is in MY immediate future.  (Unless Santa Claus has
> really upped the sophistication of those elves...)  So I'm stuck with
> dial-up access, screen captures, and 3480 cartridges in the mail for now.
>
I've been pondering whether one couldn't do some of this with an RS/6000
and the SNA capabilities it has.  Anyone know?  Of course, getting the
RS/6000 to speak SNA is only the first part.  You also need:

3270 emulation (I think this capability is available with the SNA products)
NJE support (for exchanging mail and printout with IBMLINK. Ugh.)
program to do the download [Host Exchange]

and the circuit to IBMLINK.

I confess that I have never investigated the SNA capabilities of the RS.

--
Frank Vance  +1.713.963.2426            Western Geophysical
fvance@airgun.wg.waii.com               10001 Richmond Avenue
Fax: +1.713.963.2758                    Houston, TX 77042   USA
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Fri, 18 Dec 1992 08:46:00 EST
From:         "George_J.Haddad" <GEORGEH@MSU.BITNET>
Subject:      Re: Why no NFS on 9370 Integrated Ethernet Controller?

Here's a reply I got from IBM when I asked the same question a few
months back:

>
> The problem is that the ICA cannot process frames as fast as they are
> delivered by an Ethernet.  NFS clients commonly emit bursts of frames
> when writing a file that overflow the local memory on the ICA card.
>
> Yes, an external Ethernet controller, such as the IBM 3172 or something
> else that attaches via the channel interface, avoids this problem.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Fri, 18 Dec 1992 07:26:43 LCL
From:         CGDG07@LMSC.IS.LMSC.LOCKHEED.COM
Subject:      FTP SECURITY PROBLEM

 Ron Lane <RONLANE@YKTVMV.BITNET> writes:

 >An append yesterday mentioned the 'security problems' with
 >apar 30384 with FTP in release 2.2.1.  The extent of this problem
 >is that sometimes, though not too often, a person will be
 >doing a DIR under the authority of another userid because the
 >TCBSENV ACEE field has not been cleared up from a previous
 >user, and because DIR did set the TCBSENV field itself to change it.
 >This does not affect GET and PUT, because they always change the
 >TCBSENV field when they run.
 >
 >Ron Lane
 >TCP/IP Development

 Shawn writes:

 >In our situation, both GETS and PUTS were affected as well. (that's how
 >we found the problem;  users were complaining of RACF violations on
 >datasets that they owned when doing GETS and PUTS.)
 >
 >For us, the problem is not related to "occasional" DIR commands; once
 >the FTP server gets into that condition all connections seem have the
 >authority of that previous user. Restarting the server was the only way
 >we could figure out how to get out of the situation.  We didn't think
 >that 30384 sounded like our problem, but level 2 insisted it's the
 >same...

 >Shawn.

 I can only add that our experience here also occured on an FTP get
 of a migrated file. The userid id field was incorrect in RACF on the
 a first attempt of the get and although migration occurred a RACF error
 resulted. Upon the second get attempt the user was able to read the
 data because his userid information was now correct. This is a security
 problem and we backed out to version (2.1) of FTPSERVE. IBM assured me
 that the apar discussed above would address this problem. I hope
 this is the case.


 RUSS             CGDG07@lmsc.is.lmsc.lockheed.com
From: $MAS@CLVM.CLARKSON.EDU (Michael A. Short)
Newsgroups: bit.listserv.ibmtcp-l
Subject: 4381 to RS/6000 connection
Date: 18 Dec 92 15:42:00 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

I have the block multiplexor adapter option for the RS/6000 connected to
a 4381. FAL fails with an assertion check when the statements referencing
this device are put into the profile.

A call to the support center indicated the problem was that we are runing
FAL in V=V mode and that the CLAW mode of operation required V=R mode.
I can't find this in documantation. Is there anyone using the adapter
who has the experience or documentation to verify this? We are running
with a 10M virtual machine and can't afford to tie up that much real estate
on a 32M machine.

We are currently running FAL 2.2 in XA mode with DIAG98. Everything seems
to be OK except for the CLAW mode failure.

Any help would be appreciated.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Thu, 17 Dec 1992 08:15:22 EST
Comments:     Converted from PROFS to RFC822 format by PUMP V2.2X
From:         "REED, ROD USAISC-P,
              ASQNS-SESS-S RM BD987 703-695-9974"
              <REEDR@PENTAGON-HQDADSS.ARMY.MIL>
Subject:      SMTP: 451 message clogs queue

SUBJECT: SMTP: 451 message clogs queue


Reply to NLAFLAMM's concern about smtp's que management, or lack thereof.

My experience has been that SMTP on VM is prone to que constipation where,
for some reason, a remote site is unable to accept mail and ALL mail for
that site gets stuck behind the offending message.

Since IBM has not supplied even the most basic operator commands for
managing the que, I have had to resort to brute force and manually
reorder (rename, edit appropriate addrblok, note files on smtp 191) or
delete the files.

My sympathies.

*
************************
*   HAVE A NICE DAY    *
************************
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Fri, 11 Dec 1992 15:13:45 EST
From:         "Daniel M. Barton" <dmbarton@VNET.IBM.COM>
Subject:      3172-003

> I know the 3172 Model 3 supports up to four LAN adapter cards, but
> does anyone know if they all can be of the same type, i.e. Ethernet
> (or T/R), and I if they can how/where can this fact be verified?

The 3172 Model 3 running ICP will support any mixture of Token Ring
and Ethernet adapters, with up to a total of 4 LAN adapters per
3172-3.  So yes, you can have 4 Ethernet adapters.

With Offload, the 3172 Model 3 supports the above as well.  In
addition, one FDDI adapter can be substituted for 2 of the LAN
adapters.  (the FDDI adapter takes 2 slots).  In other words, you can
have one FDDI adapter with 2 other LAN adapters (either Token Ring or
FDDI).

Sorry this is so confusing!

Daniel



=====-=====-=====-=====-=====-=====-=====-=====-=====-=====-=====-=====-=====

Daniel M. Barton                 Internet:  dmbarton@vnet.ibm.com
TCP/IP Development
IBM Research Triangle Park, NC  USA
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.ibmtcp-l
Date:         Wed, 16 Dec 1992 12:39:55 MDT
From:         "Matthew Ling" <626022@UCDASVM1.ADMIN.UCALGARY.CA>
Subject:      Problems in setting up a Caching-only Domain Name Server

FROM: Matthew Ling
      The University of Calgary              Phone: (403) 220-5441
      Department of Administrative Systems     FAX: (403) 282-9361
     I am having some problem in setting up a Caching-Only Domain
     Name Server.

     If possible, could someone send me a sample of a configuration for
     the RR records that works?

     My problem is as follows:
        When I try to use the command,
          NSLOOKUP <my host name>
        The query terminates with the following messages:

     res_mkquery(0, <my IP address>.in-addr.arpa, 1, 12)
     ------------
     Got answer:
     HEADER:
        opcode = QUERY, id = 1, rcode = SERVFAIL
        header flags:  response, want recursion, recursion avail.
        questions = 1, answers = 0, authority records = 1, additional = 1

     QUESTIONS:
         <my IP address>.in-addr.arpa, type = PTR, class = IN
     AUTHORITY RECORDS:
     ->  <my IP address>.IN-ADDR.ARPA
         nameserver = <my host name>
         ttl = 604800 (7 days)
     ADDITIONAL RECORDS:
     ->  <my host name>
         internet address = <my IP address>
         ttl = 604800 (7 days)

     *** Can't find server name for address <my IP address>: Server failed

     ------------------------------------------------------------------

     My configuration is as follows:

        NSINTERADDR  <my host IP address> (in the TCPIP.DATA file)

     And the RR records defined are

     ; Root servers
         .                    999999 IN NS   NS.NIC.DDN.MIL.
             (... Standard root servers ...)
         .                    999999 IN NS   NIC.NORDU.NET.
     ; Root Server addresses
         NS.NIC.DDN.MIL.               999999 IN A   192.112.36.4
             (... Standard root server address ...)
         NIC.NORDU.NET.                999999 IN A   192.36.148.17
    ; Local information
        <my IP address>.IN-ADDR.ARPA    604800 IN NS   <my host name>
        <my host name>                  604800 IN A    <my IP address>

 Regards Matthew.
                                                         Date: 92/12/16
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Return-Path: <TOM@PENNDRLS.UPENN.EDU>
Newsgroups: bit.listserv.ibmtcp-l
Date:         Fri, 18 Dec 1992 11:28:51 EST
From:         "Thomas D. Denier" <TOM@PENNDRLS.UPENN.EDU>
Subject:      Re: Message TCPPC3001I under MVS

As Alan Flavell suggested, I checked my 8232 configuration against my
TCPIP.PROFILE.TCPIP. As it turned out, my 8232 had both of its Ethernet
cards associated with the same pair of subchannel addresses. I could
find this out by issuing an 'L' command on the 8232 keyboard. I added a
LINK statement for the second Ethernet card. The DEVICE and LINK
statements for this situation are coded just as Alan Flavell suspected
they would be. This got rid of the infinite succession of TCPPC3001I
messages, but gave rise to an infinite succession of TCPPKT001I messages.
The series of messages began as follows:

TCPPKT001I Device L8232A: PCCA reports home hardware address 00DD0102A693
for link ETH0
TCPPKT001I Device L8232A: PCCA reports home hardware address 00DD01074763
for link ETH1
TCPPAR098I AddHomeTranslation: Cannot find home internet address for
link ETH1
TCPPKT001I Device L8232A: Cannot process ARP packet for link ETH1 --
don't know home hardware address

The final message about the ARP packets is repeated indefinitely. There
is an obvious contradiction between the second message, which announces
the home hardware address for ETH1, and the fourth message, which claims
that the home hardware address for ETH1 is not known. I have never been
able to find the TCPPKT series of messages in the TCP/IP messages
manual. Does anyone know where these messages are documented?

I managed to get rid of the new message loop by assigning the second
Ethernet adapter an IP address in the HOME statement.

The two message loops mentioned above have the effect of turning
easily recoverable conditions into fatal errors. This is clearly a
design error on IBM's part. What is the appropriate channel for
bringing this to IBM's attention?
From: Rolf_Gustavsson_MIC%MICFORUM@MICA.MIC.KI.SE
Newsgroups: bit.listserv.ibmtcp-l
Subject: FTP & ANONYMOUS
Date: 16 Dec 92 09:38:00 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Posted-Date: Wed, 16 Dec 92 08:38 -0100

Hello!

We are planning to let people use the userid ANONYMOUS with FTP, but
then we get security problems.

In FTP you can easily change directory to another prefix.

This means that before you let ANONYMOUS logon to the system, you
have to protect everything in RACF to prevent unauthorized access.

The question now is, are there any other solutions to this problem,
for example to change the function of CD (Change Directory) in FTP
so that it is not possible to change to another high-level-index
than ANONYMOUS.

Is there any solution to this?

/Rolf Gustavsson
 MIC-KIBIC
 Stockholm
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU