Re: Omvs/tcpip question

[Ed Rabara]

On Thu, 2 Feb 2006 16:33:03 -0600, Pommier, Rex R.
<[EMAIL PROTECTED]> wrote:

>I have 1 other step to chase down here and then I will be talking to IBM
>about it.  I wanted to try this group first because you are really fast
>on helping out and I wanted to check to make sure I wasn't overlooking
>something obvious (the forest and tree thing).  I'll let you know
>when/if I find out what happened.
>
>Rex

I was following the exchange on this topic and came to the end of the thread
without knowing the resolution.

Am I to understand that the client in this FTP connection is the z/OS and
the Win server provides the FTP serving?

I've often get called in at my shop in similar cases and majority of the
time the Win FTP server is not responding, requiring intervention by the
Windows guys to recycle their FTP server. I wonder if you asked the Windows
guy at your shop to check his FTP server during this problem.

Another thing when it comes to TCP connections to Windows, a positive
response to ping initiated by z/OS is not a positive confirmation that the
Windows FTP server is not disabled in one fashion or another. With a
successful ping, all I can count on is that the Windows IP stack is active.

Were you able to find the root cause to your issue and how did you resolve it?

Regards, Ed R.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 02/02/2006
   at 01:30 PM, "Pommier, Rex R." <[EMAIL PROTECTED]> said:

>You know, my first thought was to simply delete your ranting

Feel free.

>because it seems there are a few people on this board
>who seem to think their sole purpose is to blast others rather than
>to try to help. 

And there are some people too pigheaded to accept help when it is
offered.

>but I am looking for help,

Obviously not. I offered you help; I won't make that mistake again.
It's not my dog.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Mark Zelden]

On Thu, 2 Feb 2006 15:29:27 -0600, Doug Henry <[EMAIL PROTECTED]> wrote:

>On Wed, 1 Feb 2006 16:41:50 -0600, Pommier, Rex R.
><[EMAIL PROTECTED]> wrote:
>
>>Only have 1 IKJTSOxx member, last modified July 2005.  It does not have
>>PING defined to AUTHCMD.
>>
>>
>
>From z/OS Comm Svr: IP Sys Admin Commands
>
>For PING to be authorized to use RAW sockets, add the command name,
>PING, to the AUTHCMD NAMES section of the member IKJTSOxx of
>SYS1.PARMLIB. TSO user IDs with UNIX System Services superuser
>authority are able to execute the command even without this
>SYS1.PARMLIB modification. If PING is not authorized to use RAW
>sockets, PING will fail with message EZZ3115I Unable to open RAW
>socket: EDC5139I Operation not permitted. For other authorization
>considerations, refer to MVS-related considerations in the z/OS
>Communications Server: IP Configuration Guide.
>

My notes from the last 1.4 upgrade I did said to add NETSTAT as well,
but that isn't mentioned in the 1.4 migration guide, so I'm not sure
when that was needed.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Pommier, Rex R.]

I have 1 other step to chase down here and then I will be talking to IBM
about it.  I wanted to try this group first because you are really fast
on helping out and I wanted to check to make sure I wasn't overlooking
something obvious (the forest and tree thing).  I'll let you know
when/if I find out what happened.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Zelden
Sent: Thursday, February 02, 2006 3:26 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Omvs/tcpip question


On Thu, 2 Feb 2006 14:49:17 -0600, Pommier, Rex R.
<[EMAIL PROTECTED]> wrote:

>I agree with you completely.  Quite frankly it scares me that I can't 
>find anything as having changed to cause this problem - especially when

>I got multiple good suggestions as to what I could check and everything

>seems to be set up properly.  That was why I came to the list - to see 
>if anybody anywhere could give me a suggestion as to what could be 
>causing this behavior, not to tell me the obvious that I opened up a 
>big hole in my system.
>
>Rex
>

Well, it appears to me you have done due diligence, so why not open a
PMR with IBM TCP/IP support?  They have access to a lot of doc of past
problems (including customer configuration errors)and I'm sure they will
get to the bottom of it.  They'll help with setting up all the right
traces if need be.

It's the M$SOFT "techies" that have to rely on NG's to get help, we have
vendors that you can actually talk to.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Pommier, Rex R.]

Sorry, no IPLs in there.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Chase, John
Sent: Thursday, February 02, 2006 3:12 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Omvs/tcpip question


> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex R.
> 
> I agree with you completely.  Quite frankly it scares me that
> I can't find anything as having changed to cause this problem 
> - especially when I got multiple good suggestions as to what 
> I could check and everything seems to be set up properly.  
> That was why I came to the list - to see if anybody anywhere 
> could give me a suggestion as to what could be causing this 
> behavior, not to tell me the obvious that I opened up a big 
> hole in my system.  

I doubt I could suggest anything you haven't already checked, but two
questions I haven't seen raised yet are (1) did you IPL between when it
worked and when it "broke", and (2) was something cold-started that you
"normally" warm-start between when it worked and when it "broke"? (might
have been a forgotten dynamic change that didn't get propagated to a
PARMLIB or equivalent.)

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Doug Henry]

On Wed, 1 Feb 2006 16:41:50 -0600, Pommier, Rex R.
<[EMAIL PROTECTED]> wrote:

>Only have 1 IKJTSOxx member, last modified July 2005.  It does not have
>PING defined to AUTHCMD.
>
>

>From z/OS Comm Svr: IP Sys Admin Commands

For PING to be authorized to use RAW sockets, add the command name,
PING, to the AUTHCMD NAMES section of the member IKJTSOxx of
SYS1.PARMLIB. TSO user IDs with UNIX System Services superuser
authority are able to execute the command even without this
SYS1.PARMLIB modification. If PING is not authorized to use RAW
sockets, PING will fail with message EZZ3115I Unable to open RAW
socket: EDC5139I Operation not permitted. For other authorization
considerations, refer to MVS-related considerations in the z/OS
Communications Server: IP Configuration Guide.

Doug Henry

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Mark Zelden]

On Thu, 2 Feb 2006 14:49:17 -0600, Pommier, Rex R.
<[EMAIL PROTECTED]> wrote:

>I agree with you completely.  Quite frankly it scares me that I can't
>find anything as having changed to cause this problem - especially when
>I got multiple good suggestions as to what I could check and everything
>seems to be set up properly.  That was why I came to the list - to see
>if anybody anywhere could give me a suggestion as to what could be
>causing this behavior, not to tell me the obvious that I opened up a big
>hole in my system.
>
>Rex
>

Well, it appears to me you have done due diligence, so why not open a PMR
with IBM TCP/IP support?  They have access to a lot of doc of past
problems (including customer configuration errors)and I'm sure they
will get to the bottom of it.  They'll help with setting up all the
right traces if need be.

It's the M$SOFT "techies" that have to rely on NG's to get help, we
have vendors that you can actually talk to.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex R.
> 
> I agree with you completely.  Quite frankly it scares me that 
> I can't find anything as having changed to cause this problem 
> - especially when I got multiple good suggestions as to what 
> I could check and everything seems to be set up properly.  
> That was why I came to the list - to see if anybody anywhere 
> could give me a suggestion as to what could be causing this 
> behavior, not to tell me the obvious that I opened up a big 
> hole in my system.  

I doubt I could suggest anything you haven't already checked, but two
questions I haven't seen raised yet are (1) did you IPL between when it
worked and when it "broke", and (2) was something cold-started that you
"normally" warm-start between when it worked and when it "broke"? (might
have been a forgotten dynamic change that didn't get propagated to a PARMLIB
or equivalent.)

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Pommier, Rex R.]

I agree with you completely.  Quite frankly it scares me that I can't
find anything as having changed to cause this problem - especially when
I got multiple good suggestions as to what I could check and everything
seems to be set up properly.  That was why I came to the list - to see
if anybody anywhere could give me a suggestion as to what could be
causing this behavior, not to tell me the obvious that I opened up a big
hole in my system.  

Rex

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex R.
> 
> For everybody else on the list, I apologize in advance for my
> ranting back but I am looking for help, not ranting about 
> everything I apparently did wrong.

Be all that as it may, it remains that you reported a significant change
in behavior of a computing system about which you state that, to the
best of your knowledge so far, "nothing was changed".

However, ALL of us **RELY ON** consistent behavior from unchanged
computing systems; indeed, most if not all of us would bet our salaries
that it is impossible for a computing system to change its behavior
without some behavioral parameter having been changed.

Thus, the inescapable conclusion is that SOMETHING, SOMEWHERE on or
affecting your system got changed, and you just haven't found it yet.
If you can truly refute that conclusion, then we are ALL in VERY SERIOUS
TROUBLE!

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex R.
> 
> For everybody else on the list, I apologize in advance for my 
> ranting back but I am looking for help, not ranting about 
> everything I apparently did wrong.

Be all that as it may, it remains that you reported a significant change in
behavior of a computing system about which you state that, to the best of
your knowledge so far, "nothing was changed".

However, ALL of us **RELY ON** consistent behavior from unchanged computing
systems; indeed, most if not all of us would bet our salaries that it is
impossible for a computing system to change its behavior without some
behavioral parameter having been changed.

Thus, the inescapable conclusion is that SOMETHING, SOMEWHERE on or
affecting your system got changed, and you just haven't found it yet.  If
you can truly refute that conclusion, then we are ALL in VERY SERIOUS
TROUBLE!

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Pommier, Rex R.]

You know, my first thought was to simply delete your ranting but then I
decided to respond because it seems there are a few people on this board
who seem to think their sole purpose is to blast others rather than to
try to help.  If I sound like I'm ticked, it is because I'm sick of
having my in-box cluttered up by these type of posts.


For everybody else on the list, I apologize in advance for my ranting
back but I am looking for help, not ranting about everything I
apparently did wrong.


In <[EMAIL PROTECTED]>,
on 02/01/2006
   at 11:40 AM, "Pommier, Rex R." <[EMAIL PROTECTED]> said:

>I have a strange one.  z/OS 1.4 on a Multiprise 3000 H50 box.  Last 
>night I got a call from operations that a FTP job blew on the 390 
>trying to FTP to a wintel server with a "connection refused" error. In 
>trying to diagnose the problem I had the operator try a ping to the 
>same machine and then to a couple others.  Each time, they received 
>this error: "EZZ3115I Unable to open RAW socket: EDC5139I Operation not

>permitted."  I logged on and was able to ping and ftp all I wanted 
>without any errors.  What I discovered was that I have an OMVS segment 
>in RACF giving me UID 0 access and the IDs the operators are using have

>no OMVS segment at all.  Giving them UID 0 in newly-created OMVS 
>segments allowed them to now run ping and FTP.

WTF? Talk about killing a fly with a sledge hammer, and begging to be
written up by the next auditor to come in the door. If someone couldn't
get into his office because he had no key, would you give him a master
key that let him open any door in the building instead of a key to his
office? Well, that's what you just did. You need to RTFM, then create an
*appropriate* OMVS segment.

My response:  No kidding!  Thanks for all your help!  NOT!  I got a call
in the night about a FTP job that has been working for years then it
went down with the "connection refused".  No changes had been made to
the job or to the security definitions on the system.  I had the
operator try a ping to the box they were trying to FTP to and got the
"raw socket" problem.  Working production job stops working with as best
I can see no changes.  I patched it up by giving access to the operator
IDs so they could CONTINUE PRODUCTION.  I know I opened up a huge hole.
Do you suppose that just maybe that was one reason I asked this group
what could be causing the problem and how I could fix it to close the
hole back up and continue allowing production to work???   I have
RTFM'ed as you so glibly suggested and from my later posts, it looks
like everything was/is set up as it should be.  That's why I'm confused
as to what caused it and how to fix it.

>I made NO changes to RACF yet these things worked 1 day and not
>the next.

What things worked? Had the operator ever done a ping before? 

My response:  What things worked?  Uh, FTP and PING??!!! Yes, they have
done ping before from the 390 and yes they have worked.  

>The only thing that I can see that changed was one of my network
>associates started working on building pools into a pair of F5 load 
>balancers to allow me to load balance telnet and ftp traffic across 
>both of the BusTech appliances we front-end the MP3000 with.

Aside from that, Mrs. Licoln, how was the play? That should have been
the first thing you looked at.

My response:  "started working on".  He had not completed building the
pools much less activating them, and further, to actually use them, we
would have to modify the client machines to access the pool rather than
straight to the 390 IP addresses.  When FTP broke, I had him remove the
changes from the F5's and it didn't help.


In <[EMAIL PROTECTED]>,
on 02/01/2006
   at 02:43 PM, "Pommier, Rex R." <[EMAIL PROTECTED]> said:

>Thanks for the hints, but as you can see from above, it all looks OK
>- except that all the sudden I need UID 0.

Nothing that you described supports such a belief.

Response:  What part of "On my playground system I just changed the UID
of OEDFLTU to 0 and mortal users can PING.  If I set the UID to 7, they
can't." is not understandable?

In <[EMAIL PROTECTED]>,
on 02/01/2006
   at 03:25 PM, "Pommier, Rex R." <[EMAIL PROTECTED]> said:

>That's the problem.  It broke on all 3 LPARs

What broke? FTP? That had nothing to do with RACF. As for ping, nothing
that you wrote suggests that the operator was ever able to use it.

My response:  The operator could and did use PING before.  Is that plain
enough?  Yes, I left it implied, and if that confused you, I'm sorry
about that.  When I said it "broke", FTP worked before and now it
doesn't.  Ping worked, now it doesn't.  To me, that's a pretty good
definition of "broke".  From the helpful reply that Peggy sent me, it
looks like it is a security issue on both parts.  That has a lot to do
with RACF.  I have double-checked all my RACF settings and I can't see
anything wrong.  I dug through the SMF records related to RACF and they
show that nothing was changed in the RACF envir

Re: Omvs/tcpip question

[Peggy Andrews]

Rex,
Found the following on the IBM support site.  Maybe something in there
explains and/or helps.
Regards,
Peggy

"Problem
Users in the Unix (OMVS) environment that are not superusers (UID is other
than 0) cannot perform ping (oping) or traceroute (otracert).

Cause
Ping receives the following error:

EZZ3115I Unable to open RAW socket: EDC5139I Operation not permitted.

Traceroute receives the following error:

EZZ6354I otracert: Recv socket() error detected (139/743C00B0)

Other commands requiring APF authorization might also fail.

Superusers (UID(0)) can use these commands without any errors. It is also
possible that only some of the normal users experience problems while most
others can use these commands without error. Review the following checklist
(which is part of a normal installation) to aid in problem resolution:

Ensure that all attributes normally associated with a program having APF
authorization are set correctly. Confirm that SEZALINK (or SEZALOAD for
V1R4 and higher), LINKLIB and SCEERUN data sets are listed in the PROGxx
PARMLIB member. Confirm that the sticky (t) bit is set for the command
names in the /usr/lpp/tcpip/bin directory.

If these are correct, especially if some non-superusers can use these
commands, check for the existence of the environment variable
_BPX_PTRACE_ATTACH.
If _BPX_PTRACE_ATTACH=YES for that user, or if it is defined to be set for
all users, this causes programs to lose their APF authorization, which in
turn causes services that require APF authorization to fail. Superusers are
unaffected when using these commands, because privileged TCP/IP operations
are allowed with or without APF authorization.

Solution
Change the setting of the _BPX_PTRACE_ATTACH environment variable to NO, or
remove it from the list initialized for the user(s). If this user needs the
functions associated with this setting, then include it in a command
procedure (REXX exec)to be used when that function is needed in a session
and inform them that they will lose the ability to perform PING and TRACRTE
commands (and probably some others as well) while this is in effect."

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Pommier, Rex R.]

Peter,

Thanks for the suggestions.  Ping behaves the same whether I telnet into
a line-mode TSO session, log on through normal tn3270, or run oping from
an OMVS shell.


BTW, I had the network guy remove the changes he made to the F% load
balancers and it made no difference.

Rex





>Did anyone change IKJTSOxx or issue the PARMLIB command or
>SET IKJTSO=xx command? Is PING defined to AUTHCMD?

Does ping behave the same from a shell session? Log-in
through telnet and try "oping some.host.name"


Peter Hunkeler
CREDIT SUISSE

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 02/01/2006
   at 11:40 AM, "Pommier, Rex R." <[EMAIL PROTECTED]> said:

>I have a strange one.  z/OS 1.4 on a Multiprise 3000 H50 box.  Last
>night I got a call from operations that a FTP job blew on the 390
>trying to FTP to a wintel server with a "connection refused" error. 
>In trying to diagnose the problem I had the operator try a ping to
>the same machine and then to a couple others.  Each time, they
>received this error: "EZZ3115I Unable to open RAW socket: EDC5139I
>Operation not permitted."  I logged on and was able to ping and ftp
>all I wanted without any errors.  What I discovered was that I have
>an OMVS segment in RACF giving me UID 0 access and the IDs the
>operators are using have no OMVS segment at all.  Giving them UID 0
>in newly-created OMVS segments allowed them to now run ping and FTP.

WTF? Talk about killing a fly with a sledge hammer, and begging to be
written up by the next auditor to come in the door. If someone
couldn't get into his office because he had no key, would you give him
a master key that let him open any door in the building instead of a
key to his office? Well, that's what you just did. You need to RTFM,
then create an *appropriate* OMVS segment.

>I made NO changes to RACF yet these things worked 1 day and not 
>the next.

What things worked? Had the operator ever done a ping before?

>The only thing that I can see that changed was one of my network 
>associates started working on building pools into a pair of F5 load 
>balancers to allow me to load balance telnet and ftp traffic across 
>both of the BusTech appliances we front-end the MP3000 with.

Aside from that, Mrs. Licoln, how was the play? That should have been
the first thing you looked at.


In <[EMAIL PROTECTED]>,
on 02/01/2006
   at 02:43 PM, "Pommier, Rex R." <[EMAIL PROTECTED]> said:

>Thanks for the hints, but as you can see from above, it all looks OK
>- except that all the sudden I need UID 0.

Nothing that you described supports such a belief.


In <[EMAIL PROTECTED]>,
on 02/01/2006
   at 03:25 PM, "Pommier, Rex R." <[EMAIL PROTECTED]> said:

>That's the problem.  It broke on all 3 LPARs 

What broke? FTP? That had nothing to do with RACF. As for ping,
nothing that you wrote suggests that the operator was ever able to use
it.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Hunkeler Peter (KRDO 4)]

>Did anyone change IKJTSOxx or issue the PARMLIB command or
>SET IKJTSO=xx command? Is PING defined to AUTHCMD? 

Does ping behave the same from a shell session? Log-in
through telnet and try "oping some.host.name"


Peter Hunkeler
CREDIT SUISSE

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Hunkeler Peter (KRDO 4)]

>I have BPX.DEFAULT.USER defined and FACILITY class is active.
>BPX.DEFAULT.USER has as the application data OEDFLTU/OEDFLTG.  
>The UID associated with OEDFLTU is  and the GID with 
>OEDFLTG is 77. 

Not related to the problem but nevertheless not a good idea, IMHO.
It's kind a like asking all TSO users to use the same userid to
log on to TSO. Its not what the default user was meant to be used
for. Assign (at least) each TSO user a discrete OMVS profile.


Peter Hunkeler
CREDIT SUISSE

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[tony babonas]

this brings back a faint memory, though I can assure
you our problem symptoms were identical.  we went
through the entire diagnosis, as did you, exactly in
the same sequence.  this occurred when we installed zos
1.4 several years ago.

the solution (here's the sketchy part) involved the
location of the PING load module, relative to its LPA
location. one of our MVS mavens "fixed it" .
 sorry I can't be more specific though I know the
security systems weren't part of the problem.  I'll dig
through my old archives and see if I can find something
more concrete.

tb

  

-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Pommier, Rex
R.
Sent: Wednesday, February 01, 2006 4:42 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Omvs/tcpip question

Only have 1 IKJTSOxx member, last modified July 2005.
It does not have PING defined to AUTHCMD.

-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden
Sent: Wednesday, February 01, 2006 3:54 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Omvs/tcpip question


On Wed, 1 Feb 2006 15:25:48 -0600, Pommier, Rex R.
<[EMAIL PROTECTED]> wrote:

>That's the problem.  It broke on all 3 LPARs and one
of the three I'm 
>the only one who even logged onto it - and that only
because I used the

>LPAR to test and see how far the problem went.  I get
a daily report 
>out of SAS/MXG that shows all security events and
nothing showed up.
>That's the minor part of the problem, though.  The
more pressing issue 
>is how do I get it back to working without giving OMVS
segments to all 
>the users who use FTP and/or ping?
>
>I'll double-check the security report to see if I can
come up with 
>anything.
>
>Thanks.
>
>Rex


Did anyone change IKJTSOxx or issue the PARMLIB command
or SET IKJTSO=xx command? Is PING defined to AUTHCMD?

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at
http://expertanswercenter.techtarget.com/
Mark's MVS Utilities:
http://home.flash.net/~mzelden/mvsutil.html

---
---
For IBM-MAIN subscribe / signoff / archive access
instructions, send email to [EMAIL PROTECTED] with
the message: GET IBM-MAIN INFO Search the archives at
http://bama.ua.edu/archives/ibm-main.html

---
---
For IBM-MAIN subscribe / signoff / archive access
instructions, send email to [EMAIL PROTECTED] with
the message: GET IBM-MAIN INFO Search the archives at
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Pommier, Rex R.]

Only have 1 IKJTSOxx member, last modified July 2005.  It does not have
PING defined to AUTHCMD.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Zelden
Sent: Wednesday, February 01, 2006 3:54 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Omvs/tcpip question


On Wed, 1 Feb 2006 15:25:48 -0600, Pommier, Rex R.
<[EMAIL PROTECTED]> wrote:

>That's the problem.  It broke on all 3 LPARs and one of the three I'm 
>the only one who even logged onto it - and that only because I used the

>LPAR to test and see how far the problem went.  I get a daily report 
>out of SAS/MXG that shows all security events and nothing showed up.  
>That's the minor part of the problem, though.  The more pressing issue 
>is how do I get it back to working without giving OMVS segments to all 
>the users who use FTP and/or ping?
>
>I'll double-check the security report to see if I can come up with 
>anything.
>
>Thanks.
>
>Rex


Did anyone change IKJTSOxx or issue the PARMLIB command or
SET IKJTSO=xx command? Is PING defined to AUTHCMD?

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Mark Zelden]

On Wed, 1 Feb 2006 15:25:48 -0600, Pommier, Rex R.
<[EMAIL PROTECTED]> wrote:

>That's the problem.  It broke on all 3 LPARs and one of the three I'm
>the only one who even logged onto it - and that only because I used the
>LPAR to test and see how far the problem went.  I get a daily report out
>of SAS/MXG that shows all security events and nothing showed up.  That's
>the minor part of the problem, though.  The more pressing issue is how
>do I get it back to working without giving OMVS segments to all the
>users who use FTP and/or ping?
>
>I'll double-check the security report to see if I can come up with
>anything.
>
>Thanks.
>
>Rex


Did anyone change IKJTSOxx or issue the PARMLIB command or
SET IKJTSO=xx command? Is PING defined to AUTHCMD?

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Pommier, Rex R.]

That's the problem.  It broke on all 3 LPARs and one of the three I'm
the only one who even logged onto it - and that only because I used the
LPAR to test and see how far the problem went.  I get a daily report out
of SAS/MXG that shows all security events and nothing showed up.  That's
the minor part of the problem, though.  The more pressing issue is how
do I get it back to working without giving OMVS segments to all the
users who use FTP and/or ping?

I'll double-check the security report to see if I can come up with
anything.

Thanks.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ulrich Krueger
Sent: Wednesday, February 01, 2006 2:50 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Omvs/tcpip question


Rex,

> Yesterday it all broke and I didn't touch it!

If not you then who else did, or what else did change on your system?
Changed some RACF rules, perhaps? Are you getting any RACF Violation
messages? Check SMF records written by RACF since the time from just
before it broke ... you might be able to see who did what when where?

Regards,
Ulrich

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Ulrich Krueger]

Rex,

> Yesterday it all broke and I didn't touch it!

If not you then who else did, or what else did change on your system? Changed
some RACF rules, perhaps?
Are you getting any RACF Violation messages?
Check SMF records written by RACF since the time from just before it broke ...
you might be able to see who did what when where?

Regards,
Ulrich

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Pommier, Rex R.]

I checked it all out:

I have BPX.DEFAULT.USER defined and FACILITY class is active.
BPX.DEFAULT.USER has as the application data OEDFLTU/OEDFLTG.  The UID
associated with OEDFLTU is  and the GID with OEDFLTG is 77.

On my playground system I just changed the UID of OEDFLTU to 0 and
mortal users can PING.  If I set the UID to 7, they can't.  

This is part of what has me so confused about it.  I am the RACF
administrator (VERY part time) and I set this stuff up years ago and
haven't touched it since.  Yesterday it all broke and I didn't touch it!


Thanks for the hints, but as you can see from above, it all looks OK -
except that all the sudden I need UID 0.  Where else can I look?

Rex




Ulrich wrote:


Rex,
you don't need UID 0 - OMVS segments for users who just need to FTP or
PING or REXEC something from z/OS to the outside world. You need
specifics only for users who do actual OMVS work and/or need to access
HFS files, like sysprogs, etc. Check your security system's setup ...
are the OMVS default userid and group ID defined? You need a working
default UID and GID setup for everyone. For details, refer to your
Security system's installation or Administration manual.

Regards,
Ulrich Krueger

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Ulrich Krueger]

Rex,
you don't need UID 0 - OMVS segments for users who just need to FTP or PING or
REXEC something from z/OS to the outside world. You need specifics only for
users who do actual OMVS work and/or need to access HFS files, like sysprogs,
etc.
Check your security system's setup ... are the OMVS default userid and group ID
defined? You need a working default UID and GID setup for everyone.
For details, refer to your Security system's installation or Administration
manual.

Regards,
Ulrich Krueger

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Omvs/tcpip question

[Brian France]

We had this happen when we MOVED to I think z/OS 1.3 from ( sorry, I forget 
which release ). We're an ACF2 shop and the change I needed to make was to 
set up a default uid and gid. Then, FTP was okay for the "masses".


At 12:40 PM 2/1/2006, you wrote:

Hi.

I have a strange one.  z/OS 1.4 on a Multiprise 3000 H50 box.  Last
night I got a call from operations that a FTP job blew on the 390 trying
to FTP to a wintel server with a "connection refused" error.  In trying
to diagnose the problem I had the operator try a ping to the same
machine and then to a couple others.  Each time, they received this
error: "EZZ3115I Unable to open RAW socket: EDC5139I Operation not
permitted."  I logged on and was able to ping and ftp all I wanted
without any errors.  What I discovered was that I have an OMVS segment
in RACF giving me UID 0 access and the IDs the operators are using have
no OMVS segment at all.  Giving them UID 0 in newly-created OMVS
segments allowed them to now run ping and FTP.  I made NO changes to
RACF yet these things worked 1 day and not the next.  This is consistent
across all 3 LPARs on our machine.  The only thing that I can see that
changed was one of my network associates started working on building
pools into a pair of F5 load balancers to allow me to load balance
telnet and ftp traffic across both of the BusTech appliances we
front-end the MP3000 with.

Now my questions:

What could have caused working FTP and PING to suddenly break due to
security violations - with no changes to RACF?

I don't relish the thought of giving operations UID 0.  How do I give
them access to FTP and PING without it?  I saw something that I need to
put oping into the IKJTSOxx member of PARMLIB to allow the ping command
to work.  That may be so, but it doesn't help batch FTP work.  What do I
need to change in RACF to allow these commands to work by mere mortals
(ie non-root)?  Or at least point me to the doc that will tell me.

I have the network guy removing the F5 configuration changes he had to
see if that makes a difference, but since he didn't even activate any of
it I can't see how this could have done it.

Any suggestions - even bizarre ones - will be considered.

TIA

Rex

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/Sysarc
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
[EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Omvs/tcpip question

[Pommier, Rex R.]

Hi.

I have a strange one.  z/OS 1.4 on a Multiprise 3000 H50 box.  Last
night I got a call from operations that a FTP job blew on the 390 trying
to FTP to a wintel server with a "connection refused" error.  In trying
to diagnose the problem I had the operator try a ping to the same
machine and then to a couple others.  Each time, they received this
error: "EZZ3115I Unable to open RAW socket: EDC5139I Operation not
permitted."  I logged on and was able to ping and ftp all I wanted
without any errors.  What I discovered was that I have an OMVS segment
in RACF giving me UID 0 access and the IDs the operators are using have
no OMVS segment at all.  Giving them UID 0 in newly-created OMVS
segments allowed them to now run ping and FTP.  I made NO changes to
RACF yet these things worked 1 day and not the next.  This is consistent
across all 3 LPARs on our machine.  The only thing that I can see that
changed was one of my network associates started working on building
pools into a pair of F5 load balancers to allow me to load balance
telnet and ftp traffic across both of the BusTech appliances we
front-end the MP3000 with.

Now my questions:

What could have caused working FTP and PING to suddenly break due to
security violations - with no changes to RACF?

I don't relish the thought of giving operations UID 0.  How do I give
them access to FTP and PING without it?  I saw something that I need to
put oping into the IKJTSOxx member of PARMLIB to allow the ping command
to work.  That may be so, but it doesn't help batch FTP work.  What do I
need to change in RACF to allow these commands to work by mere mortals
(ie non-root)?  Or at least point me to the doc that will tell me.

I have the network guy removing the F5 configuration changes he had to
see if that makes a difference, but since he didn't even activate any of
it I can't see how this could have done it.

Any suggestions - even bizarre ones - will be considered.

TIA

Rex

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html