Re: OMVS

[Ron Wells]

In OMVS how can you send a control-c (SIGINT) to a foreground process?

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

[Ron Wells]

John---
Yes---TSO>> OMVS

as for pref of what the Linux guys want...do not think they would care..if 
easier to get into OMVS that would be better/easier they would be happy...

How would that be setup>>not familiar with what you are saying ...

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

[Mark Jacobs]

Ron Wells wrote:

John---
Yes---TSO>> OMVS

as for pref of what the Linux guys want...do not think they would care..if 
easier to get into OMVS that would be better/easier they would be happy...


How would that be setup>>not familiar with what you are saying ...

  
Setup and run the SSH daemon under OMVS. Then they can ssh to the 
mainframe and it will look and act like any other unix box. Thats what I 
do all the time from my workstation when I don't need TSO services.


--
Mark Jacobs
Technical Services
Time Customer Service - Tampa, FL
--

"The secret of life is honesty and fair dealing. 
If you can fake that, you've got it made."


--  Julius (Groucho) Henry Marx

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

[Ron Wells]

Mark

Yes I did...only because the control-c did not work for user...they are on 
Linux logged into OMVS and was running java and could not interupt 
it..(control-c)

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

[Mark Jacobs]

Ron Wells wrote:

In OMVS how can you send a control-c (SIGINT) to a foreground process?

-

Have you tried the kill command with the pid number of the process?

--
Mark Jacobs
Technical Services
Time Customer Service - Tampa, FL
--

"The secret of life is honesty and fair dealing. 
If you can fake that, you've got it made."


--  Julius (Groucho) Henry Marx

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

[Peter X. DeFabritus]

In OMVS, at the bottom of the screen you should see definitions for various PF 
keys, and also the esacpe character.  This usually shows as "ESC=cents 
sign".  To send SIGINT, enter the escape character followed by the letter c.

On Fri, 3 Aug 2007 11:24:12 -0500, Ron Wells <[EMAIL PROTECTED]> 
wrote:

>In OMVS how can you send a control-c (SIGINT) to a foreground process?
>
>--
>Email Disclaimer
>This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  
for  the use of the individual or entity addressed above.  If you are not  the  
intended  recipient, or  an  employee  or  agent responsible for delivering it 
to 
the intended recipient, you are hereby notified that any disclosure,  copying, 
distribution, or the taking of any action in reliance on the contents of the E-
mail or attached files is strictly prohibited.
>
>--
>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

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ron Wells
> Sent: Friday, August 03, 2007 12:07 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: OMVS
> 
> 
> John---
> Yes---TSO>> OMVS
> 
> as for pref of what the Linux guys want...do not think they 
> would care..if 
> easier to get into OMVS that would be better/easier they 
> would be happy...
> 
> How would that be setup>>not familiar with what you are saying ...
> 

If you want a regular "telnet", like a "normal" UNIX would use, then you
need to pick a port that is not already in use. Port 23 is what UNIX
people are used to and is the default, but we already had that in use.
So I use port 2023. You need to have the INETD daemon set up per the
manual. My setup is rather basic. I have one line in /etc/rc to start it
up at IPL time:

# Start the INET daemon for remote login activity
_BPX_JOBNAME='INETD',/usr/sbin/inetd /etc/inetd.conf &

(the first line is a comment, the second line actually starts INETD when
z/OS UNIX System Services starts up at IPL time).

In /etc/inetd.conf, I have:

2023  stream tcp nowait BPXROOT /usr/sbin/otelnetd otelnetd -l -D
login

And that is basically that. Once you have this set up, the Linux people
can do:

telnet zos.ip.address 2023

When they do this, it causes inet to fork() and run the "otelnetd"
client. This client asks for the user's RACF userid and password. Once
validates, it starts up the shell program contained in the user's OMVS
segment, just as the TSO OMVS does.

If you want (as I do), and your users need the z/OS UNIX program to be
able to do X graphics on their desktop, you can automatically set up the
DISPLAY environment variable to point back to their desktop. Well, at
least it works for me. You do this by putting the following lines in the
/etc/profile startup script:

set . $(ps -o args -p $PPID)
case "$3" in
*telnet*) DISPLAY="$5";;
*rlogin*) DISPLAY="$8";;
*).DISPLAY="None";;
esac
DISPLAY="$DISPLAY:0"
if [ "$DISPLAY" = "None:0" ]
then
.unset DISPLAY
else
.export DISPLAY
fi

I cannot guarantee that this will work for you. It does on my z/OS 1.6
system. Oh, and the Linux users must authorize the z/OS system to
connect to the X server on their desktop via the xhost command.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

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

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ron Wells
> Sent: Friday, August 03, 2007 11:40 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: OMVS
> 
> 
> Mark
> 
> Yes I did...only because the control-c did not work for 
> user...they are on 
> Linux logged into OMVS and was running java and could not interupt 
> it..(control-c)

Hum, when you say OMVS, do you mean the TSO OMVS command? If so, why not
allow your users to have a direct z/OS UNIX shell? It is not difficult
to set up. And things work more the way that Linux people are used to.
Having to log onto TSO in order to get a UNIX command line is not very
intuitive. Of course, if the Linux people like OEDIT and OBROWSE, then
you must do it this way.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

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

[Ron Wells]

John
Thanks...will look into thiswe use por 23 for tn3270
thought the older telnet had to be defined in BPXparm and TCPIP parm's for 
port to use?? not just in OMVS...guess I'm wrong??

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

[Edward Jaffe]

Ron Wells wrote:

In OMVS how can you send a control-c (SIGINT) to a foreground process?
  


If you logon to the same system where the user's process is running, you 
can issue the "kill -s INT pid" command from the OMVS shell or 
telnet/ssh session. To find out the pid, you can issue "ps -A" or use 
other software you might have available to provide this information.



The 'UINT' line command, issued next to any line on the (E)JES Process 
Status display, will send SIGINT (signal 2) to the associated process, 
even if running on another system in the JESplex. It can send any valid 
UNIX signal e.g., HUP (signal 1) by name or number.



--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ron Wells
> Sent: Friday, August 03, 2007 12:32 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: OMVS
> 
> 
> John
> Thanks...will look into thiswe use por 23 for tn3270
> thought the older telnet had to be defined in BPXparm and 
> TCPIP parm's for 
> port to use?? not just in OMVS...guess I'm wrong??

I don't know about the past, but in my z/OS 1.6 system, the BPXPRMnn
members didn't need anything set up other than what is needed for TCPIP.
If you have IBM's TCPIP going, then you have what you need outside of
the INETD setup that I gave in the previous email.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

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

[Mark Jacobs]

Ron Wells wrote:

John
Thanks...will look into thiswe use por 23 for tn3270
thought the older telnet had to be defined in BPXparm and TCPIP parm's for 
port to use?? not just in OMVS...guess I'm wrong??


-
You might want to check with your security officer about using telnet 
even in your internal network since telnet sends userid's and passwords 
in the clear. Our corporate mandate is to encrypt all sign-on traffic 
using ssh, SSL/TLS TN3270, or other methods.


Your company might have the same rules.

--
Mark Jacobs
Technical Services
Time Customer Service - Tampa, FL
--

"The secret of life is honesty and fair dealing. 
If you can fake that, you've got it made."


--  Julius (Groucho) Henry Marx

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

[Edward Jaffe]

Ron Wells wrote:

John
Thanks...will look into thiswe use por 23 for tn3270
thought the older telnet had to be defined in BPXparm and TCPIP parm's for 
port to use?? not just in OMVS...guess I'm wrong??
  


We use port 23 for TN3270 and port 1023 for OMVS telnet. We continue to 
configure things this way for historical reasons.


For services we've configured more recently, we share the *same* port 
number between the native z/OS server and the z/OS UNIX server by using 
VIPA. For example, here's our TCPIP port definition for REXECD/RSHD:


512 TCP OMVS BIND 192.168.1.129 ; z/OS Unix REXECD
514 TCP OMVS BIND 192.168.1.129 ; z/OS Unix RSHD
512 TCP RXSERVE ; Remote Execution Server
514 TCP RXSERVE ; Remote Execution Server

192.168.1.129 is the VIPA address. This same port sharing technique 
ought to work for any server, including telnet.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

[Ron Wells]

John...
Below conflicts with something else that is there ..??
2023  stream tcp nowait BPXROOT /usr/sbin/otelnetd otelnetd -l -D
login

Below is what is currently in etc/inetd.conf

otelnet   stream tcp nowait OMVSKERN /usr/sbin/otelnetd otelnetd -l
shell stream tcp nowait OMVSKERN /usr/sbin/orshd orshd -LV 
login stream tcp nowait OMVSKERN /usr/sbin/rlogind rlogind -m 
exec  stream tcp nowait OMVSKERN /usr/sbin/orexecd orexecd -LV 
rse   stream tcp nowait OMVSKERN /usr/lpp/wd4z/rse/lib/fekfrsed rsed

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

[Ron Wells]

Also conflict with what is in 

# Start the INET daemon for remote login activity
_BPX_JOBNAME='INETD',/usr/sbin/inetd /etc/inetd.conf &

the>>>/\ comma is not present ??? typo ??

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

[Mark Zelden]

On Fri, 3 Aug 2007 10:47:56 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:

>For services we've configured more recently, we share the *same* port
>number between the native z/OS server and the z/OS UNIX server by using
>VIPA. For example, here's our TCPIP port definition for REXECD/RSHD:
>
>512 TCP OMVS BIND 192.168.1.129 ; z/OS Unix REXECD
>514 TCP OMVS BIND 192.168.1.129 ; z/OS Unix RSHD
>512 TCP RXSERVE ; Remote Execution Server
>514 TCP RXSERVE ; Remote Execution Server
>
>192.168.1.129 is the VIPA address. This same port sharing technique
>ought to work for any server, including telnet.
>

So if I opened a dos window on my win-doze system and wanted to use
telnet to get into z/OS UNIX (or used a telnet client), how would it know 
where to go to?

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
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

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ron Wells
> Sent: Friday, August 03, 2007 3:42 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: OMVS
> 
> 
> Also conflict with what is in 
> 
> # Start the INET daemon for remote login activity
> _BPX_JOBNAME='INETD',/usr/sbin/inetd /etc/inetd.conf &
> 
> the>>>>>>>>>>>>>>>/\ comma is not present ??? typo ??

Damn cut-n-paste from Hummingbird. The comman should not be there. It
should be a space. Hummingbird replaces 3270 attribute characters with
commas when I cut from a 3270 screen.

# Start the INET daemon for remote login activity
_BPX_JOBNAME='INETD' /usr/sbin/inetd /etc/inetd.conf &

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

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

[Ron Wells]

john..

the BPXparm has BPXROOT as superuser ...

does the etc/services have to be updated to point to telnet at a port?? 
right now it is 23...but the TN3270 is using that---per TCPparms for TCPIP 

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ron Wells
> Sent: Friday, August 03, 2007 3:39 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: OMVS
> 
> 
> John...
> Below conflicts with something else that is there ..??
> 2023  stream tcp nowait BPXROOT /usr/sbin/otelnetd otelnetd -l -D
> login
> 
> Below is what is currently in etc/inetd.conf
> 
> otelnet   stream tcp nowait OMVSKERN /usr/sbin/otelnetd otelnetd -l
> shell stream tcp nowait OMVSKERN /usr/sbin/orshd orshd -LV 
> login stream tcp nowait OMVSKERN /usr/sbin/rlogind rlogind -m 
> exec  stream tcp nowait OMVSKERN /usr/sbin/orexecd orexecd -LV 
> rse   stream tcp nowait OMVSKERN 
> /usr/lpp/wd4z/rse/lib/fekfrsed rsed
> 

Well, it looks like you need to use OMVSKERN where I used BPXROOT. What
you need is the RACF id which is defined in the BPXPRMnn member as the
SUPERUSER().

What message did you get?

Also the line that says:

otelnet   stream tcp nowait OMVSKERN /usr/sbin/otelnetd otelnetd -l

tell INETD to listen on port 23. This will fail if you use port 23 for
something else, as many do. If you are already using port 23, you can
comment this out by making the first character and octothrope (#).

#otelnet   stream tcp nowait OMVSKERN /usr/sbin/otelnetd otelnetd -l


--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

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

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ron Wells
> Sent: Friday, August 03, 2007 3:57 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: OMVS
> 
> 
> john..
> 
> the BPXparm has BPXROOT as superuser ...
> 
> does the etc/services have to be updated to point to telnet 
> at a port?? 
> right now it is 23...but the TN3270 is using that---per 
> TCPparms for TCPIP 

You can do that if you want, but it should not be necessary. At least, I
did not bother. I just comment'ed out the line previously mentioned. If
you don't then you will have a conflict because the TCPIP stack will be
listening on port 23 and the INETD daemon will try to listen on port 23
as well. This is "not allowed" (OK, there are ways to do it, but it is
outside my knowledge).

You might want to change the OMVSKERN to BPXROOT in all the
/etc/inetd.conf lines.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

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

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ron Wells
> Sent: Friday, August 03, 2007 4:13 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: OMVS
> 
> 
> So I changed all that had the omvskern to bpxroot..
> 
> 2023  stream tcp nowait BPXROOT /usr/sbin/otelnetd otelnetd -l -D 
> login
> 
> just put this inplace of the telnet one I commoneted out ??

That should work. Just to let you know, I'll be leaving soon and not
back until Monday (hopefully!!!)

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

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

[Ron Wells]

have a good weekend---let ya know how it went.thanks again...

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

[Ron Wells]

So I changed all that had the omvskern to bpxroot..

2023  stream tcp nowait BPXROOT /usr/sbin/otelnetd otelnetd -l -D 
login

just put this inplace of the telnet one I commoneted out ??

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

[Natarajan Mohan]

I am not sure how it would work with same IP address to both z/OS stack and USS 
TCP/IP stack. I have defined the same way here, except I have two VIPA 
addresses.
My primary VIPA is TCP/IP on z/OS host and secondary vipa address is bind to 
OMVS services. When you go to a line mode telnet and key in the seondary VIPA, 
it takes
you straight into USS and you get a standard unix C Shell or Bourne Shell (if 
installed and configured). That would allow you to share the ports not IP 
address.

Natarajan

>>> Mark Zelden <[EMAIL PROTECTED]> 8/3/2007 1:45 PM >>>
On Fri, 3 Aug 2007 10:47:56 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:

>For services we've configured more recently, we share the *same* port
>number between the native z/OS server and the z/OS UNIX server by using
>VIPA. For example, here's our TCPIP port definition for REXECD/RSHD:
>
>512 TCP OMVS BIND 192.168.1.129 ; z/OS Unix REXECD
>514 TCP OMVS BIND 192.168.1.129 ; z/OS Unix RSHD
>512 TCP RXSERVE ; Remote Execution Server
>514 TCP RXSERVE ; Remote Execution Server
>
>192.168.1.129 is the VIPA address. This same port sharing technique
>ought to work for any server, including telnet.
>

So if I opened a dos window on my win-doze system and wanted to use
telnet to get into z/OS UNIX (or used a telnet client), how would it know 
where to go to?

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED] 
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ 
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

NOTICE OF CONFIDENTIALITY
The information contained in this communication, including but not limited to 
any accompanying document(s) and/or attachment(s), is privileged and 
confidential and is intended solely for the above-named individual(s). If you 
are not the intended recipient, please be advised that any distribution, 
copying, disclosure, and/or use of the information contained herein is strictly 
prohibited.  If you received this communication in error, please destroy all 
copies of the communication, whether in electronic or hard copy format, and 
immediately contact the Information Security Office at EDFUND at (916) 526-8961 
or [EMAIL PROTECTED]  Thank you.

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

[Edward Jaffe]

Mark Zelden wrote:

So if I opened a dos window on my win-doze system and wanted to use
telnet to get into z/OS UNIX (or used a telnet client), how would it know 
where to go to?
  


Which server you get depends on entirely which host IP address you use 
when you connect. That's the beauty of it.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

[Chris Mason]

 of SOURCEVIPA 
causing a response to use a source address that is different from the one 
specified on the corresponding previous request goes away, because the 
socket is bound solely to the designated address.


The specified address can also be a Dynamic VIPA, and need not already be 
active on the stack at the time that the application establishes its 
listening socket. In other words, applications that bind to INADDR_ANY can 
now use application-initiated Dynamic VIPAs, with all the benefits of such 
use, including the ability to restart the application on another OS/390 
image (with an appropriate TCP/IP configuration already in place) and have 
the Dynamic VIPA move with the application. This configuration is available 
for both TCP and UDP applications, because the PORT statement differentiates 
between the two.




Normally if I see someone either in IBM-MAIN or IBMTCP-L - obviously only 
the threads which catch or retain my attention - suffering under the 
delusion that they are obliged to pluck a non-standard port number out of 
the aether in order to run one of  two server applications in order to 
connect with which the client will default to trying to use the same port 
number, I endeavour to encourage the use of VIPAs and the PORT statement 
entry BIND parameter so kindly introduced by IBM with APAR PQ37421 - so long 
ago. One more time won't hurt!


Chris Mason

- Original Message - 
From: "Edward Jaffe" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Saturday, August 04, 2007 12:38 AM
Subject: Re: OMVS



Mark Zelden wrote:

So if I opened a dos window on my win-doze system and wanted to use
telnet to get into z/OS UNIX (or used a telnet client), how would it know 
where to go to?




Which server you get depends on entirely which host IP address you use 
when you connect. That's the beauty of it.


--
Edward E Jaffe


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

[Chris Mason]

John

If you want a regular "telnet", like a "normal" UNIX would use, then you 
need to pick a port that is not already in use.


Not true, "can" I will accept but not "need". I guess I'm being picky!

See my post to Edward regarding another - and to my mind a *far* superior - 
way.


Chris Mason

- Original Message - 
From: "McKown, John" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Friday, August 03, 2007 7:25 PM
Subject: Re: OMVS

...

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

[Chris Mason]

Edward

 This same port sharing technique ought to work for any server, including 
telnet.


If the APAR PQ37421 example is to be believed, you can remove "ought to" and 
replace with "does".


Chris Mason

- Original Message - 
From: "Edward Jaffe" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Friday, August 03, 2007 7:47 PM
Subject: Re: OMVS

...

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

[Chris Mason]

Mark

Please see my post in reply to Edward's post which is his reply to this 
post - if you can line up all the posts!


The specific answer to your question is that, in order to connect to the 
traditional "TCP/IP for MVS" REXECD and RSHD services, you will use the IP 
address of one of interfaces to the IP instance and , in order to connect to 
the OMVS REXECD and RSHD services, you will use the VIPA 192.168.1.129, 
using the VIPA in Edward's example.


As I point out in the other post, I - and APAR PQ37421 - prefer that you use 
VIPAs as the destination for all services. Thus you would also use a VIPA in 
order to connect to the traditional "TCP/IP for MVS" REXECD and RSHD 
services.


On review I see you are interested only in TELNET. You need simply to 
substitute port number 23 - and the name of your TN3270 server - in one set 
from Edward's example. Or you can use the example in APAR PQ37421:


 23 TCP INTCLIEN BIND 9.67.113.109   ;3270 TELNET
 23 TCP OMVS BIND 9.67.116.55;UNIX TELNET

Chris Mason

- Original Message - 
From: "Mark Zelden" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Friday, August 03, 2007 10:45 PM
Subject: Re: OMVS


On Fri, 3 Aug 2007 10:47:56 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:


For services we've configured more recently, we share the *same* port
number between the native z/OS server and the z/OS UNIX server by using
VIPA. For example, here's our TCPIP port definition for REXECD/RSHD:

512 TCP OMVS BIND 192.168.1.129 ; z/OS Unix REXECD
514 TCP OMVS BIND 192.168.1.129 ; z/OS Unix RSHD
512 TCP RXSERVE ; Remote Execution Server
514 TCP RXSERVE ; Remote Execution Server

192.168.1.129 is the VIPA address. This same port sharing technique
ought to work for any server, including telnet.



So if I opened a dos window on my win-doze system and wanted to use
telnet to get into z/OS UNIX (or used a telnet client), how would it know
where to go to?

Mark

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

[Chris Mason]

Ron and John

I believe the story with etc/services is that it is used only as a last 
resort when there has been no other customization which supplies the port 
number that the server - or I guess a client - should use. Since you are 
specifying port number 23 somewhere - I think, I haven't followed every last 
comma of the discussion - there will be no reference to etc/services - if my 
belief is true.


Chris Mason

- Original Message - 
From: "McKown, John" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Friday, August 03, 2007 11:01 PM
Subject: Re: OMVS



-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Ron Wells
Sent: Friday, August 03, 2007 3:57 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: OMVS


john..

the BPXparm has BPXROOT as superuser ...

does the etc/services have to be updated to point to telnet
at a port??
right now it is 23...but the TN3270 is using that---per
TCPparms for TCPIP


You can do that if you want, but it should not be necessary. At least, I
did not bother. I just comment'ed out the line previously mentioned. If
you don't then you will have a conflict because the TCPIP stack will be
listening on port 23 and the INETD daemon will try to listen on port 23
as well. This is "not allowed" (OK, there are ways to do it, but it is
outside my knowledge).

You might want to change the OMVSKERN to BPXROOT in all the
/etc/inetd.conf lines.

--
John McKown

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

[Chris Mason]

Mark

Apart from the *genuine* opportunity for misunderstanding over the use of 
USS here - a USS message, specifically USS message 10, is what you may very 
well receive when you connect to what I believe Natarajan refers to as the 
"z/OS stack", meaning the Communications Server IP component TN3270 server I 
expect, rather than what he refers to as the "USS TCP/IP stack", meaning 
"otelnet" I expect - I think Natarajan is accessing his two different TELNET 
services in the preferred manner, namely by means of a VIPA each.


Of course, I'm a touch confused over why he images there are two "stacks" 
involved here since the underlying IP instance could be the same for both 
servers. It may be he is running two instances of the CS IP component in the 
same z/OS image in which case he's a bit off the topic under discussion - as 
I understand it.


Chris Mason

- Original Message - 
From: "Natarajan Mohan" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Saturday, August 04, 2007 12:26 AM
Subject: Re: OMVS


I am not sure how it would work with same IP address to both z/OS stack and 
USS TCP/IP stack. I have defined the same way here, except I have two VIPA 
addresses.
My primary VIPA is TCP/IP on z/OS host and secondary vipa address is bind to 
OMVS services. When you go to a line mode telnet and key in the seondary 
VIPA, it takes
you straight into USS and you get a standard unix C Shell or Bourne Shell 
(if installed and configured). That would allow you to share the ports not 
IP address.


Natarajan


Mark Zelden <[EMAIL PROTECTED]> 8/3/2007 1:45 PM >>>

On Fri, 3 Aug 2007 10:47:56 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:


For services we've configured more recently, we share the *same* port
number between the native z/OS server and the z/OS UNIX server by using
VIPA. For example, here's our TCPIP port definition for REXECD/RSHD:

512 TCP OMVS BIND 192.168.1.129 ; z/OS Unix REXECD
514 TCP OMVS BIND 192.168.1.129 ; z/OS Unix RSHD
512 TCP RXSERVE ; Remote Execution Server
514 TCP RXSERVE ; Remote Execution Server

192.168.1.129 is the VIPA address. This same port sharing technique
ought to work for any server, including telnet.



So if I opened a dos window on my win-doze system and wanted to use
telnet to get into z/OS UNIX (or used a telnet client), how would it know
where to go to?

Mark
--
Mark Zelden

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

[Paul Gilmartin]

On Fri, 3 Aug 2007 11:24:12 -0500, Ron Wells wrote:

>In OMVS how can you send a control-c (SIGINT) to a foreground process?
>
(depending on terminal emulator) I use the mouse to copy the ESC
character from the lower left of the screen; paste it into the command
entry field; type 'c'; then ENTER.

-- gil

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

[Kenneth E Tomiak]

For those willing to be less specific about terminology and still want to 
understand the answer-

There is no port sharing, the combination of ipaddress:port is unique to an 
application. In order to share ipaddress:port the two applications vying to 
receive the packets coming inbound would have to talk to each other and 
resolve who should do what with them. Consider trying to share port 12345 
between a web server and a tn3270 server, not going to work. But qualify it 
as shown in the examples previously shown as ipaddress:port and get each to 
listen for their ipaddress AND port and the perception you are sharing the port 
can be realized. If you really shared the port it would be like two jobs 
reading 
the same tape at the same time. They are not going to each get every record.

Some applications are designed to listen for traffic by port on all your host's 
ipaddresses so 'sharing' is not going to work as you wish.

You can run, I believe, up to eight TCP/IP stacks. They would be using unique 
ipaddress:port combinations for the applications they support. 

On Sat, 4 Aug 2007 02:21:42 +0200, Chris Mason 
<[EMAIL PROTECTED]> wrote:

>Mark
>
>Please see my post in reply to Edward's post which is his reply to this
>post - if you can line up all the posts!
>
>The specific answer to your question is that, in order to connect to the
>traditional "TCP/IP for MVS" REXECD and RSHD services, you will use the IP
>address of one of interfaces to the IP instance and , in order to connect to
>the OMVS REXECD and RSHD services, you will use the VIPA 192.168.1.129,
>using the VIPA in Edward's example.
>
>As I point out in the other post, I - and APAR PQ37421 - prefer that you use
>VIPAs as the destination for all services. Thus you would also use a VIPA in
>order to connect to the traditional "TCP/IP for MVS" REXECD and RSHD
>services.
>
>On review I see you are interested only in TELNET. You need simply to
>substitute port number 23 - and the name of your TN3270 server - in one set
>from Edward's example. Or you can use the example in APAR PQ37421:
>
>  23 TCP INTCLIEN BIND 9.67.113.109   ;3270 TELNET
>  23 TCP OMVS BIND 9.67.116.55;UNIX TELNET
>

>On Fri, 3 Aug 2007 10:47:56 -0700, Edward Jaffe
><[EMAIL PROTECTED]> wrote:
>
>>For services we've configured more recently, we share the *same* port
>>number between the native z/OS server and the z/OS UNIX server by using
>>VIPA. For example, here's our TCPIP port definition for REXECD/RSHD:
>>
>>512 TCP OMVS BIND 192.168.1.129 ; z/OS Unix REXECD
>>514 TCP OMVS BIND 192.168.1.129 ; z/OS Unix RSHD
>>512 TCP RXSERVE ; Remote Execution Server
>>514 TCP RXSERVE ; Remote Execution Server
>>

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

[Chris Mason]

X System Services server applications, OMVS is often seen.


So I hope that enables the answer to be understood without reservation. On 
the other hand, if it isn't, you know what to do. I'll be "listening"!


Chris Mason

[1] Or, in fact, any other interfaces - or vice versa - see my comment about 
Edward's example.


- Original Message - 
From: "Kenneth E Tomiak" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Saturday, August 04, 2007 4:25 PM
Subject: Re: OMVS


For those willing to be less specific about terminology and still want to
understand the answer-

There is no port sharing, the combination of ipaddress:port is unique to an
application. In order to share ipaddress:port the two applications vying to
receive the packets coming inbound would have to talk to each other and
resolve who should do what with them. Consider trying to share port 12345
between a web server and a tn3270 server, not going to work. But qualify it
as shown in the examples previously shown as ipaddress:port and get each to
listen for their ipaddress AND port and the perception you are sharing the 
port
can be realized. If you really shared the port it would be like two jobs 
reading

the same tape at the same time. They are not going to each get every record.

Some applications are designed to listen for traffic by port on all your 
host's

ipaddresses so 'sharing' is not going to work as you wish.

You can run, I believe, up to eight TCP/IP stacks. They would be using 
unique

ipaddress:port combinations for the applications they support.

On Sat, 4 Aug 2007 02:21:42 +0200, Chris Mason
<[EMAIL PROTECTED]> wrote:


Mark

Please see my post in reply to Edward's post which is his reply to this
post - if you can line up all the posts!

The specific answer to your question is that, in order to connect to the
traditional "TCP/IP for MVS" REXECD and RSHD services, you will use the IP
address of one of interfaces to the IP instance and , in order to connect 
to

the OMVS REXECD and RSHD services, you will use the VIPA 192.168.1.129,
using the VIPA in Edward's example.

As I point out in the other post, I - and APAR PQ37421 - prefer that you 
use
VIPAs as the destination for all services. Thus you would also use a VIPA 
in

order to connect to the traditional "TCP/IP for MVS" REXECD and RSHD
services.

On review I see you are interested only in TELNET. You need simply to
substitute port number 23 - and the name of your TN3270 server - in one set
from Edward's example. Or you can use the example in APAR PQ37421:

 23 TCP INTCLIEN BIND 9.67.113.109   ;3270 TELNET
 23 TCP OMVS BIND 9.67.116.55;UNIX TELNET




On Fri, 3 Aug 2007 10:47:56 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:


For services we've configured more recently, we share the *same* port
number between the native z/OS server and the z/OS UNIX server by using
VIPA. For example, here's our TCPIP port definition for REXECD/RSHD:

512 TCP OMVS BIND 192.168.1.129 ; z/OS Unix REXECD
514 TCP OMVS BIND 192.168.1.129 ; z/OS Unix RSHD
512 TCP RXSERVE ; Remote Execution Server
514 TCP RXSERVE ; Remote Execution Server



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

[Hunkeler Peter (KIUK 3)]

>Also the line that says: 
>
>otelnet   stream tcp nowait OMVSKERN /usr/sbin/otelnetd otelnetd -l 
>
>tell INETD to listen on port 23.  
>[snip] 

Not correct! This tells INETD to lookup the service "otelnet" in 
/etc/services and listen on thatever port is specified there for 
incoming telnet connections.

If you specify a "service name" in the inted.conf file, you must 
map this "service name" to a "service port number" via /etc/services. 
As an alternatie, you can specify the "service port number" directly 
in the inted.conf in place of the "service name". You don't need 
the /etc/services then (at least not for the inet daemon).



I suggest you add the -m option to allow the shell to share the 
address space with the otelnet daemon process.


Peter Hunkeler
Credti 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

[Hunkeler Peter (KIUK 3)]

It has been suggeted to configure a telnet/sshd/rlogin kind of 
was to let people login to z/OS UNIX.

If you ever need to run an shell throught TSO - OMVS you can still 
send those "special characters" like ctrl-c, ctrl-z, etc to a running 
foregroung process. Here is how and why this is so "complicated":

When logged in through TSO, you're logged in using "3270 data stream". 
This protocol does not know about the UNIX special keys like ctrl-c, 
etc. You simply can't type them (there was no CTRL key on real 3270
keyboards). 

The OMVS command processor "invented" a workaround: Send me the so called 
"escape character" followed by a single character and I'll convert these 
two characters into a single "UNIX control character" ans pass that one 
along to the shell.

You define the "escape character" when staring the TSO OMVS command. The 
default is the character that will be shown as "cent sign" (x'4A') if your 
emulator is running with code page 037. (It is shown as "[" on my CP500 
emulator session; it is shown as "Ä" in Germany/Austria with CP273).

To send a ctrl-c, type ¢c (cent-c) and hit enter. Note, however, that 
this will send a "ctrl-c" followed by a "CR" to the shell. If you want 
to avoid the "CR", type ¢c¢ (append another escape character). This will 
send only the "ctrl-c". 

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

[Mark Zelden]

On Fri, 3 Aug 2007 15:38:36 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:

>Mark Zelden wrote:
>> So if I opened a dos window on my win-doze system and wanted to use
>> telnet to get into z/OS UNIX (or used a telnet client), how would it know
>> where to go to?
>>
>
>Which server you get depends on entirely which host IP address you use
>when you connect. That's the beauty of it.
>

Thanks,  I get it now.  The IP address is the controlling factor, not the port. 

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
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

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind
> Sent: Thursday, June 09, 2005 2:07 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: OMVS
> 
> 
> Hello,
>  
> Can any tell me if thee is a listserv something like OMVS and 
> if so the sign up URL.
>  
> I know about MVS-OE but I don't know if this is the same as OMVS.
>  
> Thanks.

MVS-OE is for OMVS which, if you are like Shmuel, you will hereinafter
refer to as "UNIX System Services for z/OS" and never as USS 


--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

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

[Edward E. Jaffe]

McKown, John wrote:


MVS-OE is for OMVS which, if you are like Shmuel, you will hereinafter
refer to as "UNIX System Services for z/OS" and never as USS 
 



z/OS UNIX

--
-
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
-

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

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
06/09/2005
   at 02:09 PM, "McKown, John" <[EMAIL PROTECTED]> said:

>MVS-OE is for OMVS which, if you are like Shmuel, you will
>hereinafter refer to as "UNIX System Services for z/OS" and never as
>USS 

The address space is still called OMVS, even though the facility no
longer is.
 
-- 
 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

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
06/09/2005
   at 12:07 PM, Howard Rifkind <[EMAIL PROTECTED]> said:

>I know about MVS-OE but I don't know if this is the same as OMVS.

It's the same; MVS-OE is the proper list.
 
-- 
 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

[Howard Rifkind]

Thanks folks

"McKown, John" <[EMAIL PROTECTED]> wrote:> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind
> Sent: Thursday, June 09, 2005 2:07 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: OMVS
> 
> 
> Hello,
> 
> Can any tell me if thee is a listserv something like OMVS and 
> if so the sign up URL.
> 
> I know about MVS-OE but I don't know if this is the same as OMVS.
> 
> Thanks.

MVS-OE is for OMVS which, if you are like Shmuel, you will hereinafter
refer to as "UNIX System Services for z/OS" and never as USS 


--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

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


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

[jagadishan perumal]

Hi,

Adding to the below when the user is given the SECLABEL with SYSHIGH then
the JVM invocation is successful but providing a SECLABEL of SYSHIGH to a
normal user wont be right choice so I am just trying to understand the
correct level of SECLABEL that needs to be given to the user. IBM manual
Says the ZFS dataset has the capability of adopting the SECLABEL option
when it is active if so how can we know the right SECLABEL of a OMVS ZFS
dataset ?

Jags

On Wed, Jan 18, 2012 at 12:24 PM, jagadishan perumal
wrote:

> Hi,
>
> In of our Webservice a user is not able to Invoke JVM, below are the
> following error messages :
>
>  java version "1.6.0"
>
> Java(TM) SE Runtime Environment (build pmz3160_26sr1-2014_01(SR1))
>
> IBM J9 VM (build 2.6, JRE 1.6.0 z/OS s390-31 2013_94967 (JIT enabled,
> AOT en
> J9VM - R26_Java626_SR1_2013_1649_B94967
>
> JIT  - r11_20111028_21230
>
> GC   - R26_Java626_SR1_2013_1649_B94967
>
> J9CL - 2013_94967)
>
> JCL  - 2012_01
>
> JVMSHRC020E An error has occurred while opening semaphore
>
> JVMSHRC336E Port layer error code = -197225
>
> JVMSHRC337E Platform error message: semget : *EDC5163I SAF/RACF extract
> error*.
> JVMJ9VM015W Initialization error for library j9shr26(11): JVMJ9VM009E
> J9VMDllMai
>  Could not create the Java virtual machine
>
> System Information :
> Z/OS : 1.12
>
> *some of my try :*
> I tried keeping *Xshareclasses:none *but no luck.
> User has the Unique UID and GID assigned.
> User has access to the Java Directory.
> /tmp has the sufficient space
> I even tried Killing the JAVASHARED resource but still no luck.
> There were no ICH messages in the LOG to see if there are any Challenges
> with RACF.
>
> *Historical Details :*
> Recently The system was upgraded to Z/OS 1.12, seclabel option got
> activated but not sure how it happened since the prior RACF database didnt
> had those options enabled.
>
> *BPX setting interms of Parmlib :*
>  1) d omvs,l
> D OMVS,L
> BPXO051I 15.38.38 DISPLAY OMVS 335
> OMVS 000E ACTIVE OMVS=(00,FS,CI
> SYSTEM WIDE LIMITS: LIMMSG=NONE
>   CURRENT  HIGHWATER SYSTEM
> USAGE  USAGE  LIMIT
> MAXPROCSYS 21 34900
> MAXUIDS 0  3200
> MAXPTYS 0  3800
> MAXMMAPAREA 0  0  40960
> MAXSHAREPAGES 302   2748 131072
> IPCMSGNIDS  0  0500
> IPCSEMNIDS 15 16500
> IPCSHMNIDS  5  6500
> IPCSHMSPAGES0  0 262144
> IPCMSGQBYTES  ---  0 2147483647
> IPCMSGQMNUM   ---  0  1
> IPCSHMMPAGES  ---   4096  25600
> SHRLIBRGNSIZE   0   32505856   67108864
> SHRLIBMAXPAGES  0  0   4096
>
>
> 2) d omvs,o
>
> BPXO043I 15.39.35 DISPLAY OMVS 348
> OMVS 000E ACTIVE OMVS=(00,FS,CI)
> CURRENT UNIX CONFIGURATION SETTINGS:
> MAXPROCSYS  =900MAXPROCUSER = 25
> MAXFILEPROC =  64000MAXFILESIZE = NOLIMIT
> MAXCPUTIME  =   1000MAXUIDS =200
> MAXPTYS =800
> MAXMMAPAREA =  40960MAXASSIZE   =  209715200
> MAXTHREADS  =200MAXTHREADTASKS  =   1000
> MAXCORESIZE =4194304MAXSHAREPAGES   = 131072
> IPCMSGQBYTES= 2147483647IPCMSGQMNUM =  1
> IPCMSGNIDS  =500IPCSEMNIDS  =500
> IPCSEMNOPS  = 25IPCSEMNSEMS =   1000
> IPCSHMMPAGES=  25600IPCSHMNIDS  =500
> IPCSHMNSEGS =500IPCSHMSPAGES= 262144
> SUPERUSER   = BPXROOT   FORKCOPY= COW
> STEPLIBLIST =
>
>
> # java -Xshareclasses:listAllCaches
> JVMSHRC005I No shared class caches available
>
> Could not create the Java virtual machine.
>
> To check if /tmp had enough space :
>
>  1) # ls -ld /tmp
>
> lrwxrwxrwx   1 IBMUSER  OMVSGRP   12 May 12  2011 /tmp -> $SYSNAME/tmp
>
>
> # df /tmp/
>
> Mounted on FilesystemAvail/TotalFiles  Status
>
> /SYSTEM/tmp(/tmp)204584/204800  25573
>  Available
>
> Some Research :
> Using this error message : JVMSHRC337E Platform error message: semget : 
> "*EDC5163I
> SAF/RACF extract error*." I ended up searching the IBM manual "
>
> Language Environment Run-Time Messages " with below explanation
> *EDC5163I SAF/RACF extract error. Explanation: *An authorization failure
> occurred when attempting the service. This message is equivalent to the
> z/OS UNIX System Services errno, EMVSSAFEXTRERR. *Programmer response: *Refer
> to *z/OS XL C/C++ Run-Time Library Reference *for the function being
> attempted for the specific reason for failure. *System action: *The
> request fails. The application continues to run. *Symbolic Feedback Code:
> *EDC51B
>
> Using

Re: OMVS query

[jagadishan perumal]

Hi,

I have found that MLIPCOBJ option was stopping the user to open SEMAPHORE,
so just made the MLIPCOBJ inactive by issuing : SETROPTS
MLIPCOBJ(INACTIVE). Now the user is able to invoke the JVM with no error.

Jags



On Wed, Jan 18, 2012 at 12:29 PM, jagadishan perumal
wrote:

> Hi,
>
> Adding to the below when the user is given the SECLABEL with SYSHIGH then
> the JVM invocation is successful but providing a SECLABEL of SYSHIGH to a
> normal user wont be right choice so I am just trying to understand the
> correct level of SECLABEL that needs to be given to the user. IBM manual
> Says the ZFS dataset has the capability of adopting the SECLABEL option
> when it is active if so how can we know the right SECLABEL of a OMVS ZFS
> dataset ?
>
> Jags
>
>   On Wed, Jan 18, 2012 at 12:24 PM, jagadishan perumal <
> jagadish...@gmail.com> wrote:
>
>> Hi,
>>
>> In of our Webservice a user is not able to Invoke JVM, below are the
>> following error messages :
>>
>>  java version "1.6.0"
>>
>> Java(TM) SE Runtime Environment (build pmz3160_26sr1-2014_01(SR1))
>>
>> IBM J9 VM (build 2.6, JRE 1.6.0 z/OS s390-31 2013_94967 (JIT enabled,
>> AOT en
>> J9VM - R26_Java626_SR1_2013_1649_B94967
>>
>> JIT  - r11_20111028_21230
>>
>> GC   - R26_Java626_SR1_2013_1649_B94967
>>
>> J9CL - 2013_94967)
>>
>> JCL  - 2012_01
>>
>> JVMSHRC020E An error has occurred while opening semaphore
>>
>> JVMSHRC336E Port layer error code = -197225
>>
>> JVMSHRC337E Platform error message: semget : *EDC5163I SAF/RACF extract
>> error*.
>> JVMJ9VM015W Initialization error for library j9shr26(11): JVMJ9VM009E
>> J9VMDllMai
>>  Could not create the Java virtual machine
>>
>> System Information :
>> Z/OS : 1.12
>>
>> *some of my try :*
>> I tried keeping *Xshareclasses:none *but no luck.
>> User has the Unique UID and GID assigned.
>> User has access to the Java Directory.
>> /tmp has the sufficient space
>> I even tried Killing the JAVASHARED resource but still no luck.
>> There were no ICH messages in the LOG to see if there are any Challenges
>> with RACF.
>>
>> *Historical Details :*
>> Recently The system was upgraded to Z/OS 1.12, seclabel option got
>> activated but not sure how it happened since the prior RACF database didnt
>> had those options enabled.
>>
>> *BPX setting interms of Parmlib :*
>>  1) d omvs,l
>> D OMVS,L
>> BPXO051I 15.38.38 DISPLAY OMVS 335
>> OMVS 000E ACTIVE OMVS=(00,FS,CI
>> SYSTEM WIDE LIMITS: LIMMSG=NONE
>>   CURRENT  HIGHWATER SYSTEM
>> USAGE  USAGE  LIMIT
>> MAXPROCSYS 21 34900
>> MAXUIDS 0  3200
>> MAXPTYS 0  3800
>> MAXMMAPAREA 0  0  40960
>> MAXSHAREPAGES 302   2748 131072
>> IPCMSGNIDS  0  0500
>> IPCSEMNIDS 15 16500
>> IPCSHMNIDS  5  6500
>> IPCSHMSPAGES0  0 262144
>> IPCMSGQBYTES  ---  0 2147483647
>> IPCMSGQMNUM   ---  0  1
>> IPCSHMMPAGES  ---   4096  25600
>> SHRLIBRGNSIZE   0   32505856   67108864
>> SHRLIBMAXPAGES  0  0   4096
>>
>>
>> 2) d omvs,o
>>
>> BPXO043I 15.39.35 DISPLAY OMVS 348
>> OMVS 000E ACTIVE OMVS=(00,FS,CI)
>> CURRENT UNIX CONFIGURATION SETTINGS:
>> MAXPROCSYS  =900MAXPROCUSER = 25
>> MAXFILEPROC =  64000MAXFILESIZE = NOLIMIT
>> MAXCPUTIME  =   1000MAXUIDS =200
>> MAXPTYS =800
>> MAXMMAPAREA =  40960MAXASSIZE   =  209715200
>> MAXTHREADS  =200MAXTHREADTASKS  =   1000
>> MAXCORESIZE =4194304MAXSHAREPAGES   = 131072
>> IPCMSGQBYTES= 2147483647IPCMSGQMNUM =  1
>> IPCMSGNIDS  =500IPCSEMNIDS  =500
>> IPCSEMNOPS  = 25IPCSEMNSEMS =   1000
>> IPCSHMMPAGES=  25600IPCSHMNIDS  =500
>> IPCSHMNSEGS =500IPCSHMSPAGES= 262144
>> SUPERUSER   = BPXROOT   FORKCOPY= COW
>> STEPLIBLIST =
>>
>>
>> # java -Xshareclasses:listAllCaches
>> JVMSHRC005I No shared class caches available
>>
>> Could not create the Java virtual machine.
>>
>> To check if /tmp had enough space :
>>
>>  1) # ls -ld /tmp
>>
>> lrwxrwxrwx   1 IBMUSER  OMVSGRP   12 May 12  2011 /tmp -> $SYSNAME/tmp
>>
>>
>> # df /tmp/
>>
>> Mounted on FilesystemAvail/TotalFiles  Status
>>
>> /SYSTEM/tmp(/tmp)204584/204800  25573
>>  Available
>>
>> Some Research :
>> Using this error message : JVMSHRC337E Platform error message: semget : "
>> *EDC5163I SAF/RACF extract error*." I ended up searching the IBM manual
>> "
>>
>> Language Environment Run-Time Messages " with below explanation
>> *EDC5163I 

Re: OMVS S213-FC

[Lizette Koehler]

> Hi, we have a problem in a rexx function that send data using ftpapi and 
> after start
> ssh using bpxbatch.
> The problem occurs randomly and appare as a S213-FC when we try to make
> operation on output files(i.e. ftp log) This happens rarely and we have just 
> checked the
> correct syntax of rm/alloc/open/write/close I see many processes under sdsf 
> and the
> sequence is:
> -sh -c ssh userATremote
> ssh userATremote command
> ssh-rand-helper
> ssh-rand-helper
> 
> How can this be possible? is a problem returning control from omvs?
> 
> Thanks in advance and happy Easter.
> 
> Marco
>

The 213-FC says
FC
The OPEN function for BSAM or QSAM access to a UNIX file found that the 
file does not exist.

Have you verified that your file is valid?

Lizette 

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

Re: OMVS S213-FC

[Marco Gianfranco Indaco]

Hi Lizette, yes, we traced and verified spool for allocation of that file...
It's removed, allocated and written sequentially and used only to write
after checks ftpapi's stem.
I can't understand..

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

Re: OMVS S213-FC

[Marco Gianfranco Indaco]

This is from my spool:
IGD103I SMS ALLOCATED TO DDNAME FTPOUT
IGD104I HFS FILE WAS RETAINED, DDNAME IS (FTPOUT  )
FILENAME IS (/tmp/jobssh/test.ftp)
IGD103I SMS ALLOCATED TO DDNAME FTPOUT
IEC104I 0009,TEST,XCOMPROC,FTPOUT  -000,BPX1STA
,0081,053B006C,
/tmp/jobssh/test.ftp
IEC143I 213-FC,IGG0199G,TEST,XCOMPROC,FTPOUT
IEA995I SYMPTOM DUMP OUTPUT
SYSTEM COMPLETION CODE=213  REASON CODE=00FC
 TIME=18.47.56  SEQ=07170  CPU=  ASID=009B
 PSW AT TIME OF ERROR  075C1000   80E690DA  ILC 2  INTC 0D
   NO ACTIVE MODULE FOUND
   NAME=UNKNOWN
   DATA AT PSW  00E690D4 - 41003B9A  0A0D41F0  38C256F0
   AR/GR 0: 93B67DCA/_00E693BC   1: /_A4213000
 2: /_D350   3: /_00E68822
 4: /_00876D60   5: /_0087633C
 6: /_008762E4   7: /_0087633C
 8: /_00876304   9: /_008910A0

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

Re: OMVS S213-FC

[Walter Marguccio]

FC  The OPE
> SYSTEM COMPLETION CODE=213  REASON CODE=00FC

FC  The OPEN function for BSAM or QSAM access to a UNIX file found 
    that the file does not exist.  


How did you code the PATHDISP for /tmp/jobssh/test.ftp ?
 


Walter Marguccio
z/OS Systems Programmer
BELENUS LOB Informatic GmbH
Munich - Germany


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

Re: OMVS S213-FC

[Marco Gianfranco Indaco]

PATHDISP are  KEEP,KEEP

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

Re: OMVS S213-FC

[Walter Marguccio]

I'm sorry, PATHDISP doesn't help us fur
> PATHDISP are  KEEP,KEEP


I'm sorry, PATHDISP doesn't help us further.
What did you code as PATHOPTS ?

Walter Marguccio
z/OS Systems Programmer
BELENUS LOB Informatic GmbH
Munich - Germany


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

Re: OMVS S213-FC

[Marco Gianfranco Indaco]

Ok, those are values for allocation.
PathOPTS(OWRONLY,OCREAT)
PathMode(SIRWXU,SIRWXG,SIRWXO)
PathDisp(KEEP,KEEP)

This problem does not happen everytime

At the moment I've bypassed the problem using echo instead of execio.

Regards

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

Re: OMVS S213-FC

[Michael Klaeschen]

IEC143I with system completion code 213, return code FC is clearly 
explained in MVS System Messages, Vol7: Open for HFS file which is not 
existing. Further reading: For return code FC, change the file name or 
create the file. 

But how comes, your file gets lost on the way? You allocated the HFS file 
properly with disposition keep as we see from IGD104I. But now for the 
neat details:
You allocated the HFS file with name '/tmp/jobssh/test.ftp' which has two 
points:
(a) Sysplex considerations: The '/tmp' portion of HFS tree is system 
specific. When you exec the allocation step on system A but exec the usage 
step on system B, the file will not be present because '/tmp' is a symlink 
link to '/$SYSNAME/tmp'. Have a look to your sysplex root. For instance 
this is possible if system A is shutting down "the wrong time" and WLM 
moves your ASID to system B.
(b) Serialisation: The HFS file name is not unique. When you exec multiple 
instances of your job concurrently, every job will use the same name. I am 
pretty sure that Unix does not care, the last accessor is winning. Try out 
with two concurrent ISPF editor tasks on the same HFS file. I use shell 
symbols in the file name like $$ for the process ID (which is sysplex 
unique) as an example.

Cheers
Michael




Marco Gianfranco Indaco  
Gesendet von: IBM Mainframe Discussion List 
2011-04-26 14:56
Bitte antworten an
IBM Mainframe Discussion List 


An
IBM-MAIN@bama.ua.edu
Kopie

Thema
Re: OMVS S213-FC






This is from my spool:
IGD103I SMS ALLOCATED TO DDNAME FTPOUT
IGD104I HFS FILE WAS RETAINED, DDNAME IS (FTPOUT  )
FILENAME IS (/tmp/jobssh/test.ftp)
IGD103I SMS ALLOCATED TO DDNAME FTPOUT
IEC104I 0009,TEST,XCOMPROC,FTPOUT  -000,BPX1STA
,0081,053B006C,
/tmp/jobssh/test.ftp
IEC143I 213-FC,IGG0199G,TEST,XCOMPROC,FTPOUT
IEA995I SYMPTOM DUMP OUTPUT
SYSTEM COMPLETION CODE=213  REASON CODE=00FC
 TIME=18.47.56  SEQ=07170  CPU=  ASID=009B
 PSW AT TIME OF ERROR  075C1000   80E690DA  ILC 2  INTC 0D
   NO ACTIVE MODULE FOUND
   NAME=UNKNOWN
   DATA AT PSW  00E690D4 - 41003B9A  0A0D41F0  38C256F0
   AR/GR 0: 93B67DCA/_00E693BC   1: /_A4213000
 2: /_D350   3: /_00E68822
 4: /_00876D60   5: /_0087633C
 6: /_008762E4   7: /_0087633C
 8: /_00876304   9: /_008910A0

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OMVS HFS/zFS

[Ron Wells]

Best practice suggestions when doing Maint.

Going to new Rel 1.9 to 1.11z/OS

Have modifications in HFS off root file system
as well as dir off root...

we have in the past ...copy back our changes (first checking any 
additional changes needed)...

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

Re: OMVS file Access

[Paul Gilmartin]

On Tue, 29 Nov 2011 12:30:35 +0530, saurabh khandelwal wrote:

>Hello,
> I want to move some of the user files from one path to another
>path. but before that I want to make sure that user is not editing any
>files currently, so that I can move this files safely.
>
> Is it possible to do this. Using
>
>1) OMVS,ASID=ALL* --- it shows me that the user is active in the system
>
>2) *ps -ef | grep username  --- I can use this command to know the process
>name and then I can kill that. But I don't want to use this option.
>
>
> I just want to know, if user is accessing or editing any files under
>/u/saurabh directory before safely move
> 
o Check the command fuser(1) to see whether it's any help to you.

  - but beware the timing window.

o If the move is within a single filesystem, and the editor holds the
  file open, there's no problem -- the handle (descriptor) is valid
  after the move even as it was before.

o You could create a hard link to the file before the move; after the
  move use fuser(1) to verify the file is not in use, then compare the
  content of the hard link to the moved file.  If they match, you're
  OK; unlink the hard link.  If they differ, investigate and reconcile.

Have I missed something?  Does fuser(1) base its result on the i-number
or on the pathname?

-- gil

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

Re: OMVS file Access

[Paul Gilmartin]

On Tue, 29 Nov 2011 12:30:35 +0530, saurabh khandelwal 
 wrote:

>Hello,
> I want to move some of the user files from one path to another
>path. but before that I want to make sure that user is not editing any
>files currently, so that I can move this files safely.
>
> Is it possible to do this. Using
>
>1) OMVS,ASID=ALL* --- it shows me that the user is active in the system
>
>2) *ps -ef | grep username  --- I can use this command to know the process
>name and then I can kill that. But I don't want to use this option.
>
>
> I just want to know, if user is accessing or editing any files under
>/u/saurabh directory before safely move
>
>
>
>--
>Thanks & Regards
>Saurabh Khandelwal
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OMVS INIT WAIT

[Terri E Shaffer]

Depending on how you have the ZFS address space option setup. ZFS files need to 
do recovery if errors/verifications are required and require RDRW.  There was 
an PTF about 1 yrs ago that allowed

romount_recovery=on  option to be set in the IOEPRMxx, to perform this task 
even if the file system was mounted as READ.

Thanks

Ms. Terri E. Shaffer 
terri.e.shaf...@jpmchase.com
Engineer
J.P.Morgan Chase & Co.
GTI DCT ECS Core Services zSoftware Group / Emerging Technologies 
Office: # 614-213-3467
Cell: # 412-519-2592 


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Miklos Szigetvari
Sent: Thursday, September 24, 2009 9:12 AM
To: IBM-MAIN@bama.ua.edu
Subject: OMVS INIT WAIT

Hi

In our "production" LPAR I had a terrible experience(you can't restart 
the system, it has worked 10 minutes before )

After some DISK errors I  made an IPL , but TCPIP etc. has not started , 
and after a while of panic I have seen the
OMVS is in init wait :
OMVS 000E ETC/INIT WAIT
In the third attempt,  the OMVS (and everything)  has started normally.
We have every file system in zFS.
I guess the OMVS zFS made the recovery ?
If it would give a message about this ...

-- 
Miklos Szigetvari

Development Team
ISIS Information Systems Gmbh 
tel: (+43) 2236 27551 570
Fax: (+43) 2236 21081 

E-mail: miklos.szigetv...@isis-papyrus.com 

Info: i...@isis-papyrus.com 
Hotline: +43-2236-27551-111 

Visit our Website: http://www.isis-papyrus.com 
---
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS accepts
no responsibility for malicious or inappropriate content.
--- 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.

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

Re: OMVS INIT WAIT

[Mark Zelden]

On Thu, 24 Sep 2009 15:12:21 +0200, Miklos Szigetvari
 wrote:

>Hi
>
>In our "production" LPAR I had a terrible experience(you can't restart
>the system, it has worked 10 minutes before )
>
>After some DISK errors I  made an IPL , but TCPIP etc. has not started ,
>and after a while of panic I have seen the
>OMVS is in init wait :
>OMVS 000E ETC/INIT WAIT
>In the third attempt,  the OMVS (and everything)  has started normally.
>We have every file system in zFS.
>I guess the OMVS zFS made the recovery ?
>If it would give a message about this ...
>

I thought zFS did write these types of messages.  Did you attempt to 
take any console dumps during the time?  

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OMVS INIT WAIT

[Paolo Cacciari]

Miklos wrote:

...snip
In our "production" LPAR I had a terrible experience(you can't restart 
the system, it has worked 10 minutes before )

After some DISK errors I  made an IPL , but TCPIP etc. has not started , 
and after a while of panic I have seen the
OMVS is in init wait :
OMVS 000E ETC/INIT WAIT 
In the third attempt,  the OMVS (and everything)  has started normally.
We have every file system in zFS.
I guess the OMVS zFS made the recovery ?
If it would give a message about this ...
...snip

Miklos, you must be aware that when ZFS tries a restart after some system 
failure (or sometimes when
ZFS filesystem wasn't properly closed...) it discovers this situation and 
want to be sure that original owner(s)
aren't still in charge of filesystem. For this, ZFS waits for about 90 
seconds (per filesystem) awaiting for
previous owner activity on filesystem (internal timestamps are updated in 
case of activity on filesystem).
This is for EVERY ZFS filesystem; as per your configuration (all ZFS fsys) 
you may expect long delays on
OMVS restart after failure or abnormal end of original ZFS owner.

Hope this helps. 
Ciao.

_
Paolo Cacciari
IBM Italia S.p.A.
Business Continuity and Resiliency Services, IBM Global Services - South 
Region, EMEA


IBM Italia S.p.A.
Sede Legale: Circonvallazione Idroscalo - 20090 Segrate (MI)
Cap. Soc. euro 384.506.359,00
C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153
Società soggetta all?attività di direzione e coordinamento di 
International Business Machines Corporation

(Salvo che sia diversamente indicato sopra / Unless stated otherwise 
above)

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

Re: OMVS INIT WAIT

[Miklos Szigetvari]

Hi

Thank you, I understand this.
I would like to have some message if this kind of wait occurs .
I have noticed that something wrong,  as I got some FSS messages .


Paolo Cacciari wrote:


Miklos wrote:

...snip
In our "production" LPAR I had a terrible experience(you can't restart 
the system, it has worked 10 minutes before )


After some DISK errors I  made an IPL , but TCPIP etc. has not started , 
and after a while of panic I have seen the

OMVS is in init wait :
OMVS 000E ETC/INIT WAIT 
In the third attempt,  the OMVS (and everything)  has started normally.

We have every file system in zFS.
I guess the OMVS zFS made the recovery ?
If it would give a message about this ...
...snip

Miklos, you must be aware that when ZFS tries a restart after some system 
failure (or sometimes when
ZFS filesystem wasn't properly closed...) it discovers this situation and 
want to be sure that original owner(s)
aren't still in charge of filesystem. For this, ZFS waits for about 90 
seconds (per filesystem) awaiting for
previous owner activity on filesystem (internal timestamps are updated in 
case of activity on filesystem).
This is for EVERY ZFS filesystem; as per your configuration (all ZFS fsys) 
you may expect long delays on

OMVS restart after failure or abnormal end of original ZFS owner.

Hope this helps. 
Ciao.


_
Paolo Cacciari
IBM Italia S.p.A.
Business Continuity and Resiliency Services, IBM Global Services - South 
Region, EMEA


   
IBM Italia S.p.A.

Sede Legale: Circonvallazione Idroscalo - 20090 Segrate (MI)
Cap. Soc. euro 384.506.359,00
C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153
Società soggetta all?attività di direzione e coordinamento di 
International Business Machines Corporation


(Salvo che sia diversamente indicato sopra / Unless stated otherwise 
above)


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

 



--
Miklos Szigetvari

Development Team
ISIS Information Systems Gmbh 
tel: (+43) 2236 27551 570
Fax: (+43) 2236 21081 

E-mail: miklos.szigetv...@isis-papyrus.com 

Info: i...@isis-papyrus.com 
Hotline: +43-2236-27551-111 

Visit our Website: http://www.isis-papyrus.com 
---

This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS accepts
no responsibility for malicious or inappropriate content.
--- 


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

Re: OMVS Telnet Client

[Chris Mason]

Bill

You might like to see how far you get using the old "TCP/IP for MVS" - 
originally "TCP/IP for VM" and strictly now the IP 
component of z/OS Communications Server (CS) - TELNET command. I always used to 
believe that this operated according to the original TELNET "network virtual 
terminal" (NVT) but I have seen a recent post which throws doubt on this belief.

However, let's just go by what the excellent manuals say - the old-fashioned 
manuals that is - none of your UNIX-impregnated "MAN" stuff here, thank you 
very much!

Incidentally, you didn't actually say, but I can guess, that you didn't enter 
the TELNET command in simple old-fashioned antediluvian TSO because, assuming 
an unmodified installation of TSO, you should have had a response from entering 
the TELNET command and, assuming that the server addressed by the IP address - 
assuming the address actually identified a server rather than an interface as 
is possible with more highly-developed CS IP servers - or an interface to an IP 
node where the TELNET server is running is actually running under an UNIX 
platform, you *should* have succeeded - if the following text from the z/OS 
V1R13 Communications Server IP User's Guide and Commands manual is to be 
believed:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B9A0/2.1



2.1 Using the TSO TELNET command

When you use the TSO TELNET command you are running a Telnet client to connect 
to a remote host running a Telnet server. The data that is displayed on your 
terminal is managed by the Telnet client, which communicates using TCP/IP with 
the Telnet server at the remote host. As a result, the operation of your 
terminal can differ from what you are used to seeing when you are directly 
logged on to TSO or to another MVS application. For example, the remote host 
might be running UNIX, VM, or another operating system that provides a Telnet 
server. You need to use the terminal operation procedures of the remote host 
operating system while you have a TELNET session with that remote host.

TELNET management of your terminal for the remote host can also cause 
operational differences. For example, the function keys that are described in 
"Using the TELNET function keys" in topic 2.13 can result in different actions.

When all of the display data does not fit on your screen, Linemode displays the 
HOLDING message in the lower right corner of your screen. If this message 
appears, press the CLEAR key to see the rest of the data.

If your TELNET session ends for any reason, the following message is displayed:

 Session ended.   to return to TSO.

If you invoke the services of the MVS Telnet 3270 server from a Telnet client 
that is not Telnet 3270 capable, you cannot use applications in full-screen 
mode. Once in line-mode, all nested Telnet sessions continue to be line mode. 
If you use TELNET in line-mode to access an MVS or VM TELNET server, all 
subsequent nested TELNET requests are automatically connected in line-mode as a 
start-stop TTY terminal, and transparent (full-screen) operations are not 
possible.

When you return to TSO, a message explaining why the TELNET session ended is 
displayed. The following is an example of what is displayed when you return to 
TSO:

 TELNET terminated -- Foreign host is no longer responding

Restrictions:

- The z/OS TELNET client does not support the Secure Sockets Layer (SSL) 
protocol.

- The TELNET client uses the Pascal socket API, so VMCF must be started for the 
command to be successful. If VMCF is not started, an ABEND0D6 can occur.

- The TELNET client does not use the TCPSTACKSOURCEVIPA value for its local 
address. It uses any applicable SOURCEVIPA or SRCIP configuration.



Incidentally, you don't have TELNET *sessions*, you have TELNET TCP 
*connections*. In a context which can involve SNA, it seems reasonable to try 
to avoid confusion by reserving the word "session" for any SNA involvement.

I leave it to you to read further and verify that TELNET negotiation should 
have led both parties to conclude that a basic - as I used to believe - NVT 
TELNET connection would finally be agreed.

Actually I checked and I cannot actually see where this is properly explained. 
I'm obliged to quote some of the notes from when I used to teach this topic 
regarding the option of adding the "(LINEMODE" or "(L" at the end of the TELNET 
command:



Not entering "(LINEMODE" or the abbreviation "(L" will result in attempting to 
"negotiate", using the TELNET application
protocols, a 3270 full-screen connection, called "transparent" mode in the 
User's Guide. If a 3270 full-screen connection cannot be "negotiated", a 
line-by-line mode connection will be used. The purpose of having the option to 
specify the LINEMODE parameter is to force the "negotiation" of a line-by-line 
mode connection when a 3270 full-screen connection would be agreed by the 
partner TELNET server.

A line-by-line mode connection is often the only possible conn

Re: OMVS Telnet Client

[Paul Gilmartin]

On Mon, 3 Oct 2011 09:17:40 -0500, Chris Mason wrote:
>
>However, let's just go by what the excellent manuals say - the old-fashioned 
>manuals that is - none of your UNIX-impregnated "MAN" stuff here, thank you 
>very much!
> 
It was pretty clear that the OP wants a telnet client running under USS as 
opposed to
TSO.  One likely reason is that he wants to connect to a Curses application on 
the
host.  A condescending and needlessly voluminous quotation of manual text, 
impregnated
with your scarcely-veiled contempt of UNIX isn't going to help him.

-- gil

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

Re: OMVS Telnet Client

[Kirk Wolf]

I'm not sure why you would want to telnet from z/OS to a host instead of
from your workstation to that host: perhaps there are network/firewall
issues?

If that is the case, you could log into z/OS using ssh from your workstation
and start a local port forwarder from your worstation through the z/OS host
to the target server.   Then simply use telnet from your local workstation
through the forwarder.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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

Re: OMVS Telnet Client

[Chris Mason]

Paul

> ... impregnated with your scarcely-veiled contempt of UNIX ...

It's always a problem when dealing with the inhabitants of the land between the 
shining seas that, despite being the source of some superb humour - or should 
that be humor? - there are vast areas which are irony-free!
 
I'm actually quite keen on UNIX and all who sail in her ever since I was set up 
to run a class dealing with NetView/6000 many years ago. Unfortunately - in the 
eyes of some - I never went through the cloud chamber treatment one can see in 
many science fiction films where a perfectly normal ordinary human being was 
transformed into an UNIX geek, a being characterised by being able to do the 
most amazing things with strings of characters - usually including "grep" and 
"pipe" and the like. I was always consumed with admiration regarding the skill 
but had something of a dread of becoming such a being.[1]

It just so happens that in this case, available from what I know as the armoury 
available from IBM, there is no equivalent to the "telnet" command as I seem to 
recall I used to use in an AIX context - was it normally from an X-windows 
device perhaps?

There may be some non-IBM offering or an offering from an obscure IBM source. 
It's just an IP-based application after all.

If so I would have thought responding in this thread would require actually to 
be able to propose such an answer rather than carping about a genuine 
contribution - but maybe I just adopt the wrong attitude regarding what 
contributors to IBM-MAIN are supposed to contribute - am I wrong or am I wrong?

-

> A condescending and needlessly voluminous quotation of manual text, ...

That's your opinion and it's my style and I don't believe I've had any 
complains which actually make sense rather than reflecting deficiencies on 
behalf of the author.

You can always attempt to redeem yourself by taking the trouble actually to 
point out what you found "condescending" and "needlessly voluminous" - you can 
try ...

No response will, of course, be taken as an admission of guilt accompanied by 
crawling back into the corner from which you "needlessly" emerged.

-

> ... isn't going to help him.

Insofar as I quite clearly pointed out how he could use a TELNET command 
available to a TSO user, I believe this constituted a helpful contribution. I 
would be interested whether there are any other sensible opinions on the 
matter. Note that the little joke about "MAN-pages" was for the purposes of 
emphasising that Bill needed to be directing his attention to TSO - to which I 
applied the counterbalancing "slur" of "antediluvian" in case you didn't 
notice. Like Lauren Bacall, I feel like adding "You know what 'antediluvian' 
means, don't you?".

Incidentally, I was in the process of putting together an additional post - no 
doubt to be condemned as "condescending" and "needlessly voluminous" in some 
quarters - regarding something interesting which appeared at the end of Chapter 
2, "Logging on to a host using TELNET" of the z/OS Communications Server (CS) 
IP User's Guide and Commands manual.

Eventually I realised that the two sections at the end of the chapter, "Using 
TELNET 3270 DBCS transform mode" and "Terminal and conversion type", were 
misleadingly placed. They should have been more clearly identified as an 
extension of "linemode" support involving the SNA-oriented TELNET server, 
particularly curiously named the TN3270E server in this context. What these 
last two sections cover is how a suitably configured SNA-oriented TELNET server 
can be configured so that, say, a workstation emulating VT100, as the likely 
implementation these days, could access SNA 3270 applications by 
"transformation" of VT100 full-screen to 3270 full-screen data streams.

This "trick" used to be a capability of "Communication Subsystem for 
Interconnection" (CSFI).

http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&appname=Demonstration&htmlfid=897/ENUS299-371



- Gives you native access from 3270 terminals to VT100, VT220, TTY, and Minitel 
applications, and Dynamic Keyboard Mapping  and printing functions.

- Enables access from a number of supported ASCII terminals to SNA 
applications, and to ...



I got the impression that the sections at the end of Chapter 2 might be 
describing the first capability but it's actually the second capability. Tant 
pis!

At this point I was debating with myself simply to warn him off this apparently 
temping possibility when this highly flawed post appeared. Thus I can 
incorporate the warning within the rebuttal.
 
-

> One likely reason is that he wants to connect to a Curses application on the 
> host.

While I will agree that the Irish peasant's observation that "If oi were goin' 
to go t'ere, oi wouldn't be startin' from here, so oi wouldn't!" applies to 
very many queries on the list, when an OP does not actually detail his reasons 
for wanting any particular capability, I believe we are entitled t

Re: OMVS Telnet Client

[Bill Hecox]

>I'm not sure why you would want to telnet from z/OS to a host instead of
>from your workstation to that host: perhaps there are network/firewall
>issue

I am telnet hopping to bypass an interface that is down. Nothing illegal going 
on here.
When I get where I want, I can fix the interface and I will then be able to 
telnet directly.

I tried doing a telnet to TSO in line mode. Then when I entered telnet under 
TSO I got
a message that indicated that telnet would only work from a 327x terminal.

The SSH port forwarding sounds interesting. Not sure I know how to make it work 
in my case.
I do not have SSH on my windows XP machine so I guess I can not try it.

So I did the foillowing:
Did a telnet directly to z/OS USS in line mode from my XP machine. Port 123 on 
our host.
Then used SSH under OE to get to my target host. Works fine.

Fortunately my target machine supports SSH connections.

Thanks,
Bill

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

Re: OMVS Telnet Client

[Grinsell, Don]

Putty will give you an ssh client for your workstation.  

http://www.chiark.greenend.org.uk/~sgtatham/putty/

Once you have the windows executable installed, ssh to your z/OS system and 
from there use the mainframe's ssh client to get to your other system.  This 
assumes you have openssh on your mainframe.

--
 
Donald Grinsell
State of Montana
406-444-2983
dgrins...@mt.gov

"They have computers, and they may have other weapons of mass destruction."
-- Janet Reno

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Bill Hecox
Sent: Monday, 03 October 2011 13:01
To: IBM-MAIN@bama.ua.edu
Subject: Re: OMVS Telnet Client

>I'm not sure why you would want to telnet from z/OS to a host instead 
>of from your workstation to that host: perhaps there are 
>network/firewall issue

I am telnet hopping to bypass an interface that is down. Nothing illegal going 
on here.
When I get where I want, I can fix the interface and I will then be able to 
telnet directly.

I tried doing a telnet to TSO in line mode. Then when I entered telnet under 
TSO I got a message that indicated that telnet would only work from a 327x 
terminal.

The SSH port forwarding sounds interesting. Not sure I know how to make it work 
in my case.
I do not have SSH on my windows XP machine so I guess I can not try it.

So I did the foillowing:
Did a telnet directly to z/OS USS in line mode from my XP machine. Port 123 on 
our host.
Then used SSH under OE to get to my target host. Works fine.

Fortunately my target machine supports SSH connections.

Thanks,
Bill

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OMVS copy files

[Staller, Allan]

This is most likely an error in BPXPRMxx.  Possibly some sort of catalog
error.
The x'7A; return code in the BPXF029E message indicates an IO error
In addition:

Verify the correct mount attributes in BPXPRMxx (R or R/W)
Verify that you have started the ZFS address space correctly.
Verify the VSAM files are defined w/the LINEAR attribute.
Verify the files have data in them. Issue a IDCAMS LISTC ALL against the
entry and check the HURBA

IMO, the /tmp error message is a secondary symptom.

HTH,


We are z/OS V1R11. I am trying to copy the OMVS (ZFS) files to my TEST
system. I used DFDSS logical dump and restore and I also renamed the
files using IDCAMS. When I IPL the test system I get the following
messages:

IEC161I 037(186,000,IGG0CLFT)-003,ZFS,ZFS,SYS2,,,OMVS.PRDB.ROOT,,
834
IEC161I CATALOG.Z11.PRDB.MASTER
IOEZ3E While opening minor device 1, could not open dataset
OMVS.PRDB.ROOT.
BPXF029E ROOT FILE SYSTEM OMVS.PRDB.ROOT 836
WAS NOT MOUNTED.  RETURN CODE = 007A, REASON CODE = EF096058
BPXF002I FILE SYSTEM /tmp WAS 837
NOT MOUNTED.  RETURN CODE = 0086, REASON CODE = 052C04DC


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

Re: OMVS copy files

[Shmuel Metz (Seymour J.)]

In
<701728a732d7324294b9ef836edbb7700114989...@msmail02.luv.ad.swacorp.com>,
on 07/26/2010
   at 10:57 AM, Mark Steely  said:

>We are z/OS V1R11. I am trying to copy the OMVS (ZFS) files to my
>TEST system. I used DFDSS logical dump and restore and I also renamed
>the files using IDCAMS. 

Did you catalog OMVS.PRDB.ROOT in the correct catalog for the test
system?
 
-- 
 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 lists...@bama.ua.edu 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

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

[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,

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

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

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

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

[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

[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

[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

[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

[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

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

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

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

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

[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

[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

[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

[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

[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

[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

[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 spawned tasks

[Shane Ginnane]

> When I add IEFUJI
> to the SUBSYS pararmeter in SMFPRM00 for OMVS, I get errors like this:
>
> BPXP005I A FORK OR SPAWN ERROR WAS ENCOUNTERED. RETURN CODE 0070
> REASON CODE 0BFC0434
>
> This was when I just entered the ishell.  By what I've read, it
> sounds like the spawned task inherits accounting data from the
> parent task, so I don't need to reverify this info.  Therefore, I
> need a different IEFUJI routine for OMVS??  I'm at a loss as to how
> to code it or what exactly it should do.

I would have thought section 32.8 (in my 1.4 manual) of the manual you
referred to covered that *explicitly*.
Looks like your UJI is failing OMVS tasks - probably by omission.
If it's typical of historical exits I've seen at various sites it checks
for known types, and fails the task otherwise. At the time the code was
written subsystem type OMVS was unknown, so simply adding the (unmodified)
exit to SMPPRMxx will fail all OMVS work.
Should be easy enough to cater for - check word 8 in the passed parm for
OMVS, and if yes, branch to exit. You probably already have code to check
for STC and/or TSO etc, so add it there.

Shane ...

--
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 "find" command

[Paul Gilmartin]

In a recent note, Shane Ginnane said:

> Date: Mon, 27 Jun 2005 10:19:06 +1000
> 
> This just has to be too easy - what am I missing   ???.
>
You're missing GNU find.

> How do I do the equivalent of a "find -iname ..." under z/OS UNIX ???.
> Currently I just pipe the output of a global find into grep (with -i). Is
> there an option to "find" I'm missing  ???.
> 
-iname isn't required by POSIX; there's little hope that IBM will provide it.
I built GNU find for myself.  I don't remembet all the pitfalls; one is that
z/OS has 32 mode bits; traditional UNIX has 16.  I may yet have a cheat sheet
around, or it may be on the Tools and Toys Redbook CD.

You're also missing:

o -ls
o -print0
o -follow that doesn't loop on symlink cycles

etc.  See:

File that you are currently viewing
   Linkname: IBM: z/OS UNIX System Services ported tools
URL: http://www-1.ibm.com/servers/eserver/zseries/zos/unix/bpxa1ty1.html

Link that you currently have selected
   Linkname: findutils
URL: 
http://www-1.ibm.com/servers/eserver/zseries/zos/unix/redbook/index.html#findutils

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
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 "find" command

[Shane Ginnane]

Thanks gil - due to my general dis-enchantment with the z/OS
implementation, I've not chased the tools at all.
Maybe I'll have to get off my butt, and have a look at installing some (at
long last).

Cheers ...  Shane

> >
> > This just has to be too easy - what am I missing   ???.
> >
> You're missing GNU find.

--
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 "find" command

[Shane Ginnane]

In a recent note, gil said:
>
> You're missing GNU find.
> ... it may be on the Tools and Toys Redbook CD.
>
It was, and it (the binary) works fine on limited testing at z/OS 1.5
although allegedly compiled only on a OS/390 2.9 system.

Thanks - will keep looking around.

Shane ...

--
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 "find" command

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Shane Ginnane
> Sent: Sunday, June 26, 2005 8:10 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: OMVS "find" command
> 
> 
> Thanks gil - due to my general dis-enchantment with the z/OS
> implementation, I've not chased the tools at all.
> Maybe I'll have to get off my butt, and have a look at 
> installing some (at
> long last).
> 
> Cheers ...  Shane
> 
> > >
> > > This just has to be too easy - what am I missing   ???.
> > >
> > You're missing GNU find.
> 

Porting the GNU Toolchain was one of my dreams some time ago.
Unfortunately, I cannot afford a FlexES system with ADCD on it. I was
close thanks to an IBMer. But it died when I said "Hercules/390" was the
system upon which I would run it.

Oh, well, I likely don't have the talent. Although I did get GNU Make
working once I convinced my management to license the C compiler.
Unfortunately, "Mr. I-make-my-points-by-saving-money" unconvinced
management so I've lost the license. OK, I understand, but $12,000/month
is not a back breaker in my opinion. They waste more than that daily on
"the dark side" of the house.

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

--
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 txt file problem

[Paul Gilmartin]

On Fri, 25 Sep 2009 17:31:01 -0500, Ward, Mike S wrote:

>Hello all, I'm kind of new to the OMVS world and I'd like a little help
>if possible. I have a directory in the OMVS segment that programs write
>their logs to.
>
This question is probably better asked on MVS-OE than on IBM-MAIN,
but I'll give it a try:

>How could I automate the ftping of those files to a windows ftp server
>for archive purposes then clear out the text file so that it can
>start fresh?
>
Suppose your transactions append their logs to "log.txt".  In your
crontab commands, call a script like:

# Create a second handle to the log:

ln log.txt oldlog.txt ||
  { # somehow report error to process owner.  This most likely
# happens because the previous day's log rotate failed, then:
echo "rename of log failed" >&2
exit 1;  }

# Create new log file and replace the active log file.
# Transactions which have opened the active log file will
# unknowingly continue to write to that file, now called
# oldlog.txt.  POSIX specification of mv guarantees tnat
# no starting transaction will fail to observe a log.txt:

touch newlog.txt
mv newlog.txt log.txt

# Wait long enough for transactions in progress to complete.
# Ugh.  Timing dependent.  There may be a better way.  Then
# FTP to Windows server; delete if successful:

sleep 1000
echo 'put oldlog.txt windows.log.txt
  quit' |
ftp windows-server '(exit' ||
  { # Somehow report error to process owner, then.
echo "ftp of log failed" >&2
exit 1;  }

rm oldlog.txt
exit 0

If two transactions run concurrently, their records will appear
interleaved in the log file.  This can be avoided by either:

o Each transaction's buffering its log records and writing all
  to the log with a single call to write(), or

o Prefixing each record with a unique transaction ID and later
  sorting on that field,

or some combination of both.

This script should write nothing to stdout, and write to stderr
only if errors occur.  Crontab mails the combined content of
stdout and stderr to the process owner, but not if both are
empty.  So you'll get email notification of failure but not
of success.  If you want notification of success, add an
echo command before the "exit 0".

-- gil

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

Re: OMVS txt file problem

[Paul Gilmartin]

On Fri, 25 Sep 2009 17:31:01 -0500, Ward, Mike S wrote:
>
>How could I automate the ftping of those files to a windows ftp server
>
A couple afterthoughts:

I didn't provide for supplying the ID and password to the FTP server.
Use .netrc.  Better, if you have the server, use sftp or ssh.

If your program is not expected to close its log file in a reasonable
time, it should trap SIGHUP and write its process ID to a flle,
program-name.pid.  The log rotation script should read that file and
"kill -HUP $PID".  On catching SIGHUP, your program should close and
reopen its log file.

-- gil

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

Re: OMVS txt file problem

[Jan MOEYERSONS]

On Fri, 25 Sep 2009 21:41:15 -0500, Paul Gilmartin  
wrote:

>only if errors occur.  Crontab mails the combined content of
>stdout and stderr to the process owner, but not if both are
>empty.  So you'll get email notification of failure but not
>of success.  If you want notification of success, add an

You may prefer your regular z/OS work scheduler to submit the job instead of 
crontab. Way easier for operations.

Cheers,

Jantje.

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

Re: OMVS txt file problem

[Ward, Mike S]

Gil, excellent reply. Thank you. I didn't realize there was such a beast
as cron, but there it is in the manuals and there appears to be a lot of
info on it in the internet.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Friday, September 25, 2009 9:41 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: OMVS txt file problem

On Fri, 25 Sep 2009 17:31:01 -0500, Ward, Mike S wrote:

>Hello all, I'm kind of new to the OMVS world and I'd like a little help
>if possible. I have a directory in the OMVS segment that programs write
>their logs to.
>
This question is probably better asked on MVS-OE than on IBM-MAIN,
but I'll give it a try:

>How could I automate the ftping of those files to a windows ftp server
>for archive purposes then clear out the text file so that it can
>start fresh?
>
Suppose your transactions append their logs to "log.txt".  In your
crontab commands, call a script like:

# Create a second handle to the log:

ln log.txt oldlog.txt ||
  { # somehow report error to process owner.  This most likely
# happens because the previous day's log rotate failed, then:
echo "rename of log failed" >&2
exit 1;  }

# Create new log file and replace the active log file.
# Transactions which have opened the active log file will
# unknowingly continue to write to that file, now called
# oldlog.txt.  POSIX specification of mv guarantees tnat
# no starting transaction will fail to observe a log.txt:

touch newlog.txt
mv newlog.txt log.txt

# Wait long enough for transactions in progress to complete.
# Ugh.  Timing dependent.  There may be a better way.  Then
# FTP to Windows server; delete if successful:

sleep 1000
echo 'put oldlog.txt windows.log.txt
  quit' |
ftp windows-server '(exit' ||
  { # Somehow report error to process owner, then.
echo "ftp of log failed" >&2
exit 1;  }

rm oldlog.txt
exit 0

If two transactions run concurrently, their records will appear
interleaved in the log file.  This can be avoided by either:

o Each transaction's buffering its log records and writing all
  to the log with a single call to write(), or

o Prefixing each record with a unique transaction ID and later
  sorting on that field,

or some combination of both.

This script should write nothing to stdout, and write to stderr
only if errors occur.  Crontab mails the combined content of
stdout and stderr to the process owner, but not if both are
empty.  So you'll get email notification of failure but not
of success.  If you want notification of success, add an
echo command before the "exit 0".

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
==
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity
to which they are addressed. If you have received this email in error please 
notify the system manager. This message
contains confidential information and is intended only for the individual 
named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the 
sender immediately by e-mail if you
have received this e-mail by mistake and delete this e-mail from your system. 
If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this
information is strictly prohibited.

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