Re: Multiple FTP Problems

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
10/26/2006
   at 09:12 AM, Hal Merritt <[EMAIL PROTECTED]> said:

>You and I know that. But it seems some PC/network folks don't fully
>grasp the concepts. When they say FTP, they visualize data flowing
>from here to there via an interactive dialog using the well known
>ports.

The well known ports apply only to the servers; they have to have a
pool of anonymous ports for the clients. Then take into account the
fact that a server sometimes has to fulfill the role of a client.

>The symptoms seen by the OP seemed to be consistent with some sort
>of constraint, such as limited port ranges in a network appliance.
>Such constraints may never be an issue if there were only PC's in
>the loop.

I would expect a web server on a PC top burn a lot of ports. Possibly
even a mail server on a PC.

-- 
 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: Multiple FTP Problems

[Hal Merritt]

You and I know that. But it seems some PC/network folks don't fully
grasp the concepts. When they say FTP, they visualize data flowing from
here to there via an interactive dialog using the well known ports. When
we say FTP, we refer to the hundreds of fully automated concurrent
transfers using arbitrary ports. 

The symptoms seen by the OP seemed to be consistent with some sort of
constraint, such as limited port ranges in a network appliance. Such
constraints may never be an issue if there were only PC's in the loop.  

 
 
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Wednesday, October 25, 2006 5:09 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Multiple FTP Problems

In <[EMAIL PROTECTED]>, on
10/24/2006
   at 10:47 AM, Hal Merritt <[EMAIL PROTECTED]> said:

>I like your thought. This might point to a firewall somewhere that
>constrains the number of ports to a small range. PC people have a
>very hard time understanding why you need more than one port for
>anything.

WTF? You need multiple ports on a PC for the same reason that you do
on z/OS.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
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
NOTICE: This electronic mail message and any files transmitted with it are 
intended exclusively
for the individual or entity to which it is addressed. The message, together 
with any attachment, may contain confidential and/or privileged
information. Any unauthorized review, use, printing, saving, copying, 
disclosure 
or distribution is strictly prohibited. If you have received this message in 
error, please immediately
advise the sender by reply email and delete all copies.

--
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: Multiple FTP Problems

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.)
> Sent: Wednesday, October 25, 2006 5:07 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Multiple FTP Problems
> 
> 
> In <[EMAIL PROTECTED]>,
> on 10/23/2006
>at 08:04 AM, "McKown, John" <[EMAIL PROTECTED]> said:
> 



> >It would also violate our current policy of "no custom code" for
> >things like this.
> 
> How is the REXX code you described not custom code?
> 
> [1] Just the tee shirt, no scars.
>  
> -- 
>  Shmuel (Seymour J.) Metz, SysProg and JOAT

I did not describe any REXX code. That was another person's response. I
wanted IF/THEN/ELSE and SET MAXCC= type commands from IDCAMS put into
the z/OS ftp client so that it could be scripted. That is allowed here.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
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: Multiple FTP Problems

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
10/24/2006
   at 10:47 AM, Hal Merritt <[EMAIL PROTECTED]> said:

>I like your thought. This might point to a firewall somewhere that
>constrains the number of ports to a small range. PC people have a
>very hard time understanding why you need more than one port for
>anything.

WTF? You need multiple ports on a PC for the same reason that you do
on z/OS.
 
-- 
 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: Multiple FTP Problems

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 10/23/2006
   at 08:04 AM, "McKown, John" <[EMAIL PROTECTED]> said:

>I do hope you're kidding.

Not at all. It's easy as pie. BTDTGTTS[1]

>Try to get a legacy z/OS COBOL programmer to
>learn Perl and NET::FTP?!?

It might be easier to write the Perl code yourself ;-)

>It would also violate our current policy of "no custom code" for 
>things like this.

How is the REXX code you described not custom code?

[1] Just the tee shirt, no scars.
 
-- 
 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: Multiple FTP Problems

[Hal Merritt]

I like your thought. This might point to a firewall somewhere that
constrains the number of ports to a small range. PC people have a very
hard time understanding why you need more than one port for anything.  

No doubt they simply observed the number of ports in use and used that
to configure the firewall constraints. 

I am a bit reluctant to blame all such problems on network appliance
configurations, but they seem to be at fault more often than not. More,
they seem to lack tools to discover these kinds of issues.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Hunkeler Peter (KIUK 3)
Sent: Friday, October 20, 2006 7:27 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Multiple FTP Problems

I may be on the wrong track again, but anyway I can't get rid
of the thought about "not enough TCP ports" available.

- You define the ephemeral port range in TCPIP's profile
- Each transfer of a file needs a new port.
- A TCP connection stays in Close-Wait state for some time
  (2 minutes?) after the close, so the port is still blocked

Too many file transfers in a short time and too small an
empeheral port range might lead to no port available.

Glad if someone corrects me if I'm mixing up things again.


Peter Hunkeler
CREDIT SUISSE

 
NOTICE: This electronic mail message and any files transmitted with it are 
intended exclusively
for the individual or entity to which it is addressed. The message, together 
with any attachment, may contain confidential and/or privileged
information. Any unauthorized review, use, printing, saving, copying, 
disclosure 
or distribution is strictly prohibited. If you have received this message in 
error, please immediately
advise the sender by reply email and delete all copies.

--
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: Multiple FTP Problems

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.)
> Sent: Sunday, October 22, 2006 7:11 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Multiple FTP Problems
> 
> 
> In <[EMAIL PROTECTED]>, on 10/20/2006
>at 07:04 AM, Edward Jaffe <[EMAIL PROTECTED]> said:
> 
> >It seems like there are a couple of options here. The first is to
> >split  all transfers up into individual ftp sessions, invoke each ftp
> >session  from REXX, interrogate the output, and make conditional
> >decisions based  on the results of each invocation. The other option,
> >extremely powerful  but not so easy, is to roll your own client code
> >using the REXX Sockets API:
> 
> Isn't RXFTP available in z/OS? If not, use NET::FTP in Perl.
>  
> -- 

I do hope you're kidding. Try to get a legacy z/OS COBOL programmer to
learn Perl and NET::FTP?!? I haven't tried, can z/OS Perl read/write
z/OS legacy datasets as well as UNIX files? If it can, then I guess that
I could write a user-runable Perl script. But it would still be "weird"
to them due to the unavoidable UNIX stuff if anything "goes wrong". It
would also violate our current policy of "no custom code" for things
like this.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
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: Multiple FTP Problems

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 10/20/2006
   at 07:04 AM, Edward Jaffe <[EMAIL PROTECTED]> said:

>It seems like there are a couple of options here. The first is to
>split  all transfers up into individual ftp sessions, invoke each ftp
>session  from REXX, interrogate the output, and make conditional
>decisions based  on the results of each invocation. The other option,
>extremely powerful  but not so easy, is to roll your own client code
>using the REXX Sockets API:

Isn't RXFTP available in z/OS? If not, use NET::FTP in Perl.
 
-- 
 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: Multiple FTP Problems

[Ed Gould]

Charles,

I guess I always thought that it was easier to to use shift left to  
get the desired return code.

In any case now for 20+ years its worked fine why change it?

Ed

On Oct 21, 2006, at 9:41 AM, Charles Mills wrote:

No idea. UNIX certainly has a *similar* "exit value" (as they call  
return
codes) culture: 0 = success, etc. They tend to use 1, 2, 3, ... not  
4, 8,
12, 16, and I don't think there is any equivalent to the MVS  
culture of 4 =

warning, 16 = disaster.

BTW, another "how come" question would be "how come" MVS has always  
used
return codes of 4, 8, 12, ... and not 1, 2, 3, ...? I have this  
vague notion
it was so the caller could use the return code to index into a  
branch table,

but I may be imagining that.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]  
On Behalf

Of Ed Gould
Sent: Friday, October 20, 2006 8:08 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Multiple FTP Problems

Charles,

Just curious as to why that is. I know the IBM unix people don't play
(all the time) by the MVS world, would it be a good thing to try and
create a SHARE requirement to do so (play be the rules)?

--
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: Multiple FTP Problems

[Charles Mills]

No idea. UNIX certainly has a *similar* "exit value" (as they call return
codes) culture: 0 = success, etc. They tend to use 1, 2, 3, ... not 4, 8,
12, 16, and I don't think there is any equivalent to the MVS culture of 4 =
warning, 16 = disaster.

BTW, another "how come" question would be "how come" MVS has always used
return codes of 4, 8, 12, ... and not 1, 2, 3, ...? I have this vague notion
it was so the caller could use the return code to index into a branch table,
but I may be imagining that.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Ed Gould
Sent: Friday, October 20, 2006 8:08 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Multiple FTP Problems

Charles,

Just curious as to why that is. I know the IBM unix people don't play  
(all the time) by the MVS world, would it be a good thing to try and  
create a SHARE requirement to do so (play be the rules)?

--
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: Multiple FTP Problems

[Ed Gould]

Charles,

Just curious as to why that is. I know the IBM unix people don't play  
(all the time) by the MVS world, would it be a good thing to try and  
create a SHARE requirement to do so (play be the rules)?


Ed

On Oct 20, 2006, at 7:43 AM, Charles Mills wrote:

Be aware that the FTP authors didn't view return codes the way,  
say, the
writers of the COBOL compilers or IEBCOPY did. It's entirely  
possible to get

a zero return code from an FTP jobstep that has gone terribly wrong.

Yes, there are circumventions. Just be warned that all FTP zero  
return codes

do not equal data processing success.

Charles

-SNIP-

--
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: Multiple FTP Problems

[Ted MacNEIL]

>So it must be deleted it via a "del" command in the ftp command stream.

Batch file:

@echo off
ftp -s:delete.scr
ftp -s:ftp.scr. <-- I don't remember the WIN equivalent for '(EXIT'
ftp -s:rename.scr

Where each .scr has sign on info and the individual commands.

But, if they aren't willing to take your advice on how to do it based on what 
works, the s***w'm.
You sound like you've done everything to help them.
If they don't listen/implement why is it still your problem.

I had a programmer come to me with a problem, and I showed him a simple 
solution (not even a kludge).
He came back the next day with the same problem.
I looked at the listing. He had not implemented the change.
He said he "didn't like" it!
I told him that if wasn't going address the solution that I wasn't going to 
solve it for him, again.
He reported me as uncooperative.
I pointed out to my manager, that I had given him a solution, but he didn't 
want to implement it.
So, what could I do?
Rarely happens: he backed me.
The programmer implemented.
It worked.

The next time, the programmer tried the same stunt.
I told him to take his problem to somebody else.

When in doubt.
PANIC!!  

--
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: Multiple FTP Problems

[Richard Peurifoy]

"McKown, John" wrote:

> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin
> > Sent: Friday, October 20, 2006 2:35 PM
> > To: IBM-MAIN@BAMA.UA.EDU
> > Subject: Re: Multiple FTP Problems
> >
> >
> > In a recent note, McKown, John said:
> >
>
> 
>
> > >
> > What about:
> >
> >   put mainframe.file temp.output.file
> >   put empty.file output.file
> >   del output.file
> >   rename temp.output.file output.file
> >
> > Not perfect, but it reduces the timing window to the duration
> > of transferring an empty file, and the Windoze side can be
> > instructed to try again if:
>
> Interesting. That may be acceptable to the people who will make the
> decision. Thanks. And the Windows people might even be convinced to
> check for and ignore a file with 0 bytes.
>

I don't know much about Windows, can it read the file while it is being
updated?
If not, why not APPEND the file rather than PUT.
If the file doesn't exist it will be created, and if it does the data will
be added to
the end of it.

Depending on how your processing works, maybe this isn't acceptable.

Richard

--
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: Multiple FTP Problems

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin
> Sent: Friday, October 20, 2006 2:35 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Multiple FTP Problems
> 
> 
> In a recent note, McKown, John said:
> 



> > 
> What about:
> 
>   put mainframe.file temp.output.file
>   put empty.file output.file
>   del output.file
>   rename temp.output.file output.file
> 
> Not perfect, but it reduces the timing window to the duration
> of transferring an empty file, and the Windoze side can be
> instructed to try again if:

Interesting. That may be acceptable to the people who will make the
decision. Thanks. And the Windows people might even be convinced to
check for and ignore a file with 0 bytes. 

> 
> o output.file doesn't exist (i.e. between the del and the rename).
> 
> o output.file is empty (i.e. between the put and the del).
> 
> I know, it doesn't solve your problem, but UNIX is glorious.
> To a UNIX server, I routinely do simply:
> 
>   put mainframe.file temp.output.file
>   rename temp.output.file output.file
> 
> Works every time; by specification the UNIX recipient can't detect
> either a missing or an incomplete "output.file" (but I have gotten
> complaints when they happen to detect the "temp.output.file").
> 
> Friends don't let friends do Windows.

I guess that I don't have many friends. Certainly not on "the other side
of the house". 

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
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: Multiple FTP Problems

[Ted MacNEIL]

>We (z/OS and Windows) get paid by the same company, but we are definately not 
>on the same team.

A problem on their part does not constitute an emergency on their part.

Tell'm to go twist in the wind.
You gave'm a suggestion; it's not your problem if they don't imnplement it.

When in doubt.
PANIC!!  

--
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: Multiple FTP Problems

[Charles Mills]

> the Windoze side can be instructed to try again 

Except his Windows folks don't take instructions :-(

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Paul Gilmartin
Sent: Friday, October 20, 2006 12:35 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Multiple FTP Problems

In a recent note, McKown, John said:

> Date: Fri, 20 Oct 2006 10:00:36 -0500
> 
> Unfortunately the (EXIT means that any error or warning will result in a
> non-zero return code. We cannot use it in some ftps because we have:
> 
> put mainframe.file temp.output.file
> del output.file
> rename temp.output.file output.file
> 
> If "output.file" does not exist, then the "del" command will give a
> message which causes the ftp step to get a non-zero return code. As to
> why we do this, there is a process which looks for a new "output.file"
> and when it sees it, it processes it. So we cannot ftp directly to that
> name because it is possible for the off-site process to "fire up" before
> the ftp is complete. But the rename will fail if "output.file" already
> exists, so we must attempt to delete it. this is basically a "no win"
> situation. If "output.file" does not exist then (EXIT will cause a
> non-zero due to the "del". If "output.file" does exist and the "del" is
> not done, then the "rename" will fail.
> 
What about:

  put mainframe.file temp.output.file
  put empty.file output.file
  del output.file
  rename temp.output.file output.file

Not perfect, but it reduces the timing window to the duration
of transferring an empty file, and the Windoze side can be
instructed to try again if:

--
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: Multiple FTP Problems

[Paul Gilmartin]

In a recent note, McKown, John said:

> Date: Fri, 20 Oct 2006 10:00:36 -0500
> 
> Unfortunately the (EXIT means that any error or warning will result in a
> non-zero return code. We cannot use it in some ftps because we have:
> 
> put mainframe.file temp.output.file
> del output.file
> rename temp.output.file output.file
> 
> If "output.file" does not exist, then the "del" command will give a
> message which causes the ftp step to get a non-zero return code. As to
> why we do this, there is a process which looks for a new "output.file"
> and when it sees it, it processes it. So we cannot ftp directly to that
> name because it is possible for the off-site process to "fire up" before
> the ftp is complete. But the rename will fail if "output.file" already
> exists, so we must attempt to delete it. this is basically a "no win"
> situation. If "output.file" does not exist then (EXIT will cause a
> non-zero due to the "del". If "output.file" does exist and the "del" is
> not done, then the "rename" will fail.
> 
What about:

  put mainframe.file temp.output.file
  put empty.file output.file
  del output.file
  rename temp.output.file output.file

Not perfect, but it reduces the timing window to the duration
of transferring an empty file, and the Windoze side can be
instructed to try again if:

o output.file doesn't exist (i.e. between the del and the rename).

o output.file is empty (i.e. between the put and the del).

I know, it doesn't solve your problem, but UNIX is glorious.
To a UNIX server, I routinely do simply:

  put mainframe.file temp.output.file
  rename temp.output.file output.file

Works every time; by specification the UNIX recipient can't detect
either a missing or an incomplete "output.file" (but I have gotten
complaints when they happen to detect the "temp.output.file").

Friends don't let friends do Windows.

-- 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: Multiple FTP Problems

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL
> Sent: Friday, October 20, 2006 1:23 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Multiple FTP Problems
> 
> 
> >If "output.file" does not exist, then the "del" command will 
> give a message which causes the ftp step to get a non-zero return code
> 
> I CANNOT believe you haven't figured a work around for this.
> Here's a simple one:
> 
> STEP 1: delete the file with IDCAMS or IEFBR14
> STEP 2: FTP with (EXIT
> STEP 3: rename
> 
> When in doubt.
> PANIC!!  
> 

The file to be deleted is not local. It is remote, on a Windows box. I
cannot run IDCAMS or IEFBR14 on a Windows box . So it must be
deleted it via a "del" command in the ftp command stream. And
programming staff refuses write the JCL to run this as two separate
steps, the one with the "del" being without the (EXIT so that the RC
will be 0 even if the "del" fails. I could make more comments, but they
would indicate a "bad attitude" of a "poor team player".

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
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: Multiple FTP Problems

[Ted MacNEIL]

>If "output.file" does not exist, then the "del" command will give a message 
>which causes the ftp step to get a non-zero return code

I CANNOT believe you haven't figured a work around for this.
Here's a simple one:

STEP 1: delete the file with IDCAMS or IEFBR14
STEP 2: FTP with (EXIT
STEP 3: rename

When in doubt.
PANIC!!  

--
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: Multiple FTP Problems

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Walt Farrell
> Sent: Friday, October 20, 2006 12:03 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Multiple FTP Problems
> 
> 

> 
> Couldn't you put the "del" in a separate FTP step, executed 
> first?  Yes, 
> that's a change to your JCL, but it seems like a fairly simple one to 
> resolve the problem.

I agree that this is a simple way to solve that problem. Too bad that
nobody wants to be bothered to do it. They'd rather complain to me about
ftp "being broken" because it doesn't do what they want it to do, only
what it is documented to do.

> 
> Or couldn't you leave the output.file around normally, and do:
>put mainframe.file output.file   (would not trigger anything)
>rename output.file temp.output.file
>rename temp.output.file output.file (would trigger processing)

What happens on the Windows side is not under my control. And there is
approximately a 99.5273% probability that anything I suggest would be
summarily rejected. No, not a good working relationship there. 
We (z/OS and Windows) get paid by the same company, but we are
definately not on the same team.

> 
> 
>   Walt


--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
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: Multiple FTP Problems

[Walt Farrell]

On 10/20/2006 11:00 AM, McKown, John wrote:

Unfortunately the (EXIT means that any error or warning will result in a
non-zero return code. We cannot use it in some ftps because we have:

put mainframe.file temp.output.file
del output.file
rename temp.output.file output.file

If "output.file" does not exist, then the "del" command will give a
message which causes the ftp step to get a non-zero return code. As to
why we do this, there is a process which looks for a new "output.file"
and when it sees it, it processes it. So we cannot ftp directly to that
name because it is possible for the off-site process to "fire up" before
the ftp is complete. But the rename will fail if "output.file" already
exists, so we must attempt to delete it. this is basically a "no win"
situation. If "output.file" does not exist then (EXIT will cause a
non-zero due to the "del". If "output.file" does exist and the "del" is
not done, then the "rename" will fail.


Couldn't you put the "del" in a separate FTP step, executed first?  Yes, 
that's a change to your JCL, but it seems like a fairly simple one to 
resolve the problem.


Or couldn't you leave the output.file around normally, and do:
  put mainframe.file output.file   (would not trigger anything)
  rename output.file temp.output.file
  rename temp.output.file output.file (would trigger processing)


Walt

--
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: Multiple FTP Problems

[Walt Farrell]

On 10/20/2006 9:38 AM, Warren wrote:
FTP can be done in REXX or JCL but I don't know if it can 'GET' files from 
the C: drive, of a PC.  It may be limited to mainframe datasets.


It can get files from the C: drive of a PC, but only if the PC is 
running an FTP server.


Walt

--
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: Multiple FTP Problems

[Walt Farrell]

On 10/20/2006 11:42 AM, Edward Jaffe wrote:

Walt Farrell wrote:
Here's a pointer to the z/OS R8 documentation.  I'll leave finding 
z/OS R6 documentation as an exercise for you, John:


That's for the pointer Walt. This link seems to describe the REXX 
interface of which I was originally thinking. The vertical bars seem to 
suggest it's new for z/OS V1R8. No?


http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1D360/12.10



In z/OS R6 and R7 the documentation is in the IP Programmer's Guide 
rather than the IP User's Guide.  On the other hand, in the z/OS R6/R7 
IP Programmer's Guide they do not describe a REX interface.  They 
describe a program you can call from assembler, PL/I, or COBOL.


They may have added the specific REXX interface program in z/OS R8, but 
in many cases if you can call a module from assembler you can also can 
also call it from REXX with a little cleverness.  That is possibly true 
in this case, too.  Again, an exercise for the reader, but probably a 
simpler one than playing around directly with the REXX socket programming.


Walt

--
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: Multiple FTP Problems

[Edward Jaffe]

McKown, John wrote:

Ah, thanks. Splitting the ftp into separate steps is not going to
happen. And writing my own ftp client in REXX ain't going to happen
neither . Actually, the latter violates our current directives of
"no custom code". We are trying to become a COTS (Commercial Off The
Shelf) software only shop. Once there, I guess we fire all our
programmers. Of course, once there, we will likely be off of z/OS
entirely.

So I will stand by my original request for a scriptable ftp client that
comes ready-to-run from IBM. Or from any other software vendor who will
give it to us for no cost, with lifetime support included.


This link seems to reference the function I was thinking of ...

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1D360/12.10

--
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: Multiple FTP Problems

[Edward Jaffe]

Walt Farrell wrote:

On 10/20/2006 9:26 AM, McKown, John wrote:

REXX can be used to script ftp sessions.

--
Edward E Jaffe


It can?!? Would you please give me an example. Pretty please, with sugar
on it!  I would love to get our programmers to use it, if it is
easy enough. z/OS 1.6 .


Here's a pointer to the z/OS R8 documentation.  I'll leave finding 
z/OS R6 documentation as an exercise for you, John:


That's for the pointer Walt. This link seems to describe the REXX 
interface of which I was originally thinking. The vertical bars seem to 
suggest it's new for z/OS V1R8. No?


http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1D360/12.10

--
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: Multiple FTP Problems

[John S. Giltner, Jr.]

Hunkeler Peter , KIUK 3 wrote:

I think this will depend on whether you are using "active" or


"passive"


ftp. With "active" ftp, all data connections are originated from the
__server__ to the client, using port 20 on the server. There are no
ephemeral ports used. Ephemeral ports are only used for "passive" ftp
transfers. That's where an ephermeral port is allocated by the ftp
server, which listens on that port, and connected to by the client. Or
do I have that backwards again??


Nope, you have it correct.  When using active ftp the server is really 
the client and the client is really the sever for the actual data 
transfer connection.  The sever always uses port 20 as the source port 
and the client side uses ephemeral ports. 



But in passive mode both sides are using ephemeral ports, right? Isn't
passive mode more often used in todays firewalled environments?


Peter Hunkeler
CREDIT SUISSE




Correct, passive uses ephemeral ports on both sides.  I am not sure 
which is use more, the ftp client that Windows provides does not support 
passive and I would say that for non-interactive transfered that are 
initiated on a Window box that the MS provided client would be use the 
majority of the time.


Most other platforms support passive ftp from the command line out of 
the box, so the *nix world may be passive.


SSL'ed FTP only supports passive so anything that does SSL is only passive.

It is really weird, passive was to help resolve issues with firewalls, 
as it prevents allowing inbound connections to the client.  However it 
assume that the ftp sever was in-front of a firewall.  If the ftp sever 
is behind a firewall then it required a rule to allow inbound 
connections from any ephemeral port to any ephemeral ports.  Doesn't 
sound to secure does it?  So the firewall people started monitoring the 
control session to intercept the PORT command and dynamically created a 
rule for the specific IP addresses and the source port from the client.


Now for SSL'ed ftp the control session is encrypted so you have issues 
when doing SSL'ed ftp when the server is behind a firewall.  But there 
are ways around the issues.


--
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: Multiple FTP Problems

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Walt Farrell
> Sent: Friday, October 20, 2006 9:52 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Multiple FTP Problems
> 
> 
> On 10/20/2006 8:43 AM, Charles Mills wrote:
> > Be aware that the FTP authors didn't view return codes the 
> way, say, the
> > writers of the COBOL compilers or IEBCOPY did. It's 
> entirely possible to get
> > a zero return code from an FTP jobstep that has gone terribly wrong.
> > 
> > Yes, there are circumventions. Just be warned that all FTP 
> zero return codes
> > do not equal data processing success.
> 
> Have you considered using PARM='(EXIT' on your batch FTP job 
> steps? That 
> will cause FTP to set meaningful return codes.
> 

Unfortunately the (EXIT means that any error or warning will result in a
non-zero return code. We cannot use it in some ftps because we have:

put mainframe.file temp.output.file
del output.file
rename temp.output.file output.file

If "output.file" does not exist, then the "del" command will give a
message which causes the ftp step to get a non-zero return code. As to
why we do this, there is a process which looks for a new "output.file"
and when it sees it, it processes it. So we cannot ftp directly to that
name because it is possible for the off-site process to "fire up" before
the ftp is complete. But the rename will fail if "output.file" already
exists, so we must attempt to delete it. this is basically a "no win"
situation. If "output.file" does not exist then (EXIT will cause a
non-zero due to the "del". If "output.file" does exist and the "del" is
not done, then the "rename" will fail.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
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: Multiple FTP Problems

[Walt Farrell]

On 10/20/2006 8:43 AM, Charles Mills wrote:

Be aware that the FTP authors didn't view return codes the way, say, the
writers of the COBOL compilers or IEBCOPY did. It's entirely possible to get
a zero return code from an FTP jobstep that has gone terribly wrong.

Yes, there are circumventions. Just be warned that all FTP zero return codes
do not equal data processing success.


Have you considered using PARM='(EXIT' on your batch FTP job steps? That 
will cause FTP to set meaningful return codes.


See 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B960/4.11?SHELF=EZ2ZO10H&DT=20060622162500 
or http://makeashorterlink.com/?J5851220E for more details.


Walt

--
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: Multiple FTP Problems

[Walt Farrell]

On 10/20/2006 9:26 AM, McKown, John wrote:

REXX can be used to script ftp sessions.

--
Edward E Jaffe


It can?!? Would you please give me an example. Pretty please, with sugar
on it!  I would love to get our programmers to use it, if it is
easy enough. z/OS 1.6 .


Here's a pointer to the z/OS R8 documentation.  I'll leave finding z/OS 
R6 documentation as an exercise for you, John:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1D360/12.0?SHELF=&DT=20060622161331 
or http://makeashorterlink.com/?Z4454320E


Walt

--
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: Multiple FTP Problems

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
> Sent: Friday, October 20, 2006 9:05 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Multiple FTP Problems
> 
> 
> McKown, John wrote:
> > It can?!? Would you please give me an example. Pretty 
> please, with sugar
> > on it!  I would love to get our programmers to use 
> it, if it is
> > easy enough. z/OS 1.6 .
> >   
> 
> It seems like there are a couple of options here. The first 
> is to split 
> all transfers up into individual ftp sessions, invoke each 
> ftp session 
> from REXX, interrogate the output, and make conditional 
> decisions based 
> on the results of each invocation. The other option, 
> extremely powerful 
> but not so easy, is to roll your own client code using the 
> REXX Sockets API:
> 
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a
1d450/3.5

-- 
Edward E Jaffe

Ah, thanks. Splitting the ftp into separate steps is not going to
happen. And writing my own ftp client in REXX ain't going to happen
neither . Actually, the latter violates our current directives of
"no custom code". We are trying to become a COTS (Commercial Off The
Shelf) software only shop. Once there, I guess we fire all our
programmers. Of course, once there, we will likely be off of z/OS
entirely.

So I will stand by my original request for a scriptable ftp client that
comes ready-to-run from IBM. Or from any other software vendor who will
give it to us for no cost, with lifetime support included.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
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: Multiple FTP Problems

[Hunkeler Peter (KIUK 3)]

>>I think this will depend on whether you are using "active" or
"passive"
>>ftp. With "active" ftp, all data connections are originated from the
>>__server__ to the client, using port 20 on the server. There are no
>>ephemeral ports used. Ephemeral ports are only used for "passive" ftp
>>transfers. That's where an ephermeral port is allocated by the ftp
>>server, which listens on that port, and connected to by the client. Or
>>do I have that backwards again??
>
>Nope, you have it correct.  When using active ftp the server is really 
>the client and the client is really the sever for the actual data 
>transfer connection.  The sever always uses port 20 as the source port 
>and the client side uses ephemeral ports. 

But in passive mode both sides are using ephemeral ports, right? Isn't
passive mode more often used in todays firewalled environments?


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: Multiple FTP Problems

[Edward Jaffe]

McKown, John wrote:

It can?!? Would you please give me an example. Pretty please, with sugar
on it!  I would love to get our programmers to use it, if it is
easy enough. z/OS 1.6 .
  


It seems like there are a couple of options here. The first is to split 
all transfers up into individual ftp sessions, invoke each ftp session 
from REXX, interrogate the output, and make conditional decisions based 
on the results of each invocation. The other option, extremely powerful 
but not so easy, is to roll your own client code using the REXX Sockets API:


http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1d450/3.5

--
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: Multiple FTP Problems

[John S. Giltner, Jr.]

McKown, John wrote:

-Original Message-
From: IBM Mainframe Discussion List 
[mailto:[EMAIL PROTECTED] On Behalf Of Hunkeler Peter (KIUK 3)

Sent: Friday, October 20, 2006 7:27 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Multiple FTP Problems


I may be on the wrong track again, but anyway I can't get rid
of the thought about "not enough TCP ports" available.

- You define the ephemeral port range in TCPIP's profile
- Each transfer of a file needs a new port.
- A TCP connection stays in Close-Wait state for some time
 (2 minutes?) after the close, so the port is still blocked

Too many file transfers in a short time and too small an
ephemeral port range might lead to no port available.

Glad if someone corrects me if I'm mixing up things again.


Peter Hunkeler
CREDIT SUISSE




I think this will depend on whether you are using "active" or "passive"
ftp. With "active" ftp, all data connections are originated from the
__server__ to the client, using port 20 on the server. There are no
ephemeral ports used. Ephemeral ports are only used for "passive" ftp
transfers. That's where an ephermeral port is allocated by the ftp
server, which listens on that port, and connected to by the client. Or
do I have that backwards again??

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
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. 
 



Nope, you have it correct.  When using active ftp the server is really 
the client and the client is really the sever for the actual data 
transfer connection.  The sever always uses port 20 as the source port 
and the client side uses ephemeral ports.


--
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: Multiple FTP Problems

[Warren]

FTP can be done in REXX or JCL but I don't know if it can 'GET' files from 
the C: drive, of a PC.  It may be limited to mainframe datasets.

--
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: Multiple FTP Problems

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
> Sent: Friday, October 20, 2006 8:22 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Multiple FTP Problems
> 
> 
> McKown, John wrote:
> > ... I wish that IBM had included a "scriptable" ftp
> > client on z/OS. Something with a "control language", 
> perhaps similar to
> > IDCAMS, with IF and EXIT and other control "verbs" for conditional
> > processing.
> >   
> 
> REXX can be used to script ftp sessions.
> 
> -- 
> Edward E Jaffe

It can?!? Would you please give me an example. Pretty please, with sugar
on it!  I would love to get our programmers to use it, if it is
easy enough. z/OS 1.6 .

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
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: Multiple FTP Problems

[Edward Jaffe]

McKown, John wrote:

... I wish that IBM had included a "scriptable" ftp
client on z/OS. Something with a "control language", perhaps similar to
IDCAMS, with IF and EXIT and other control "verbs" for conditional
processing.
  


REXX can be used to script ftp sessions.

--
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: Multiple FTP Problems

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills
> Sent: Friday, October 20, 2006 7:43 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Multiple FTP Problems
> 
> 
> Be aware that the FTP authors didn't view return codes the 
> way, say, the
> writers of the COBOL compilers or IEBCOPY did. It's entirely 
> possible to get
> a zero return code from an FTP jobstep that has gone terribly wrong.
> 
> Yes, there are circumventions. Just be warned that all FTP 
> zero return codes
> do not equal data processing success.
> 
> Charles

Very true. That is why I wish that IBM had included a "scriptable" ftp
client on z/OS. Something with a "control language", perhaps similar to
IDCAMS, with IF and EXIT and other control "verbs" for conditional
processing.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
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: Multiple FTP Problems

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Hunkeler Peter (KIUK 3)
> Sent: Friday, October 20, 2006 7:27 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Multiple FTP Problems
> 
> 
> I may be on the wrong track again, but anyway I can't get rid
> of the thought about "not enough TCP ports" available.
> 
> - You define the ephemeral port range in TCPIP's profile
> - Each transfer of a file needs a new port.
> - A TCP connection stays in Close-Wait state for some time
>   (2 minutes?) after the close, so the port is still blocked
> 
> Too many file transfers in a short time and too small an
> ephemeral port range might lead to no port available.
> 
> Glad if someone corrects me if I'm mixing up things again.
> 
> 
> Peter Hunkeler
> CREDIT SUISSE
> 

I think this will depend on whether you are using "active" or "passive"
ftp. With "active" ftp, all data connections are originated from the
__server__ to the client, using port 20 on the server. There are no
ephemeral ports used. Ephemeral ports are only used for "passive" ftp
transfers. That's where an ephermeral port is allocated by the ftp
server, which listens on that port, and connected to by the client. Or
do I have that backwards again??

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
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: Multiple FTP Problems

[Charles Mills]

Be aware that the FTP authors didn't view return codes the way, say, the
writers of the COBOL compilers or IEBCOPY did. It's entirely possible to get
a zero return code from an FTP jobstep that has gone terribly wrong.

Yes, there are circumventions. Just be warned that all FTP zero return codes
do not equal data processing success.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Warner Mach
Sent: Friday, October 20, 2006 4:33 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Multiple FTP Problems

To return to the original problem:



So I checked, in JCL, for a good return code from the FTP step. If
the return code was bad I: (1) Passed control to a 'wait' job that 
would wait x number of minutes. (2) Retried the FTP ... This solution 
worked very well.

--
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: Multiple FTP Problems

[Hunkeler Peter (KIUK 3)]

I may be on the wrong track again, but anyway I can't get rid
of the thought about "not enough TCP ports" available.

- You define the ephemeral port range in TCPIP's profile
- Each transfer of a file needs a new port.
- A TCP connection stays in Close-Wait state for some time
  (2 minutes?) after the close, so the port is still blocked

Too many file transfers in a short time and too small an
empeheral port range might lead to no port available.

Glad if someone corrects me if I'm mixing up things again.


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: Multiple FTP Problems

[Jim McAlpine]

Yes, we are coming the other way ie from windoze to z/OS, but have
circumvented the problem in a similar manner for the moment.

Jim McAlpine


On 10/20/06, Warner Mach <[EMAIL PROTECTED]> wrote:


To return to the original problem:


We have an application that does some client server stuff then attempts
to
ftp some files back to z/OS.  Mostly this works fine except it seems
when 2
or more ftps are attempted at the same time with the same userid.  Then
we
get "failed to connect" to the z/OS ftp server.  Is there an ftp
parameter
that would stop multiple ftps from the same user taking place.


I had the following FTP problem whose resolution may be of some value
in your case:

We were, overnight, FTPing a large number of files from the mainframe
to Windoze servers. It seemed that some of the jobs were interfering
with each other (problems on the Windoze side of course) ... I
realized that: (1) The problems were transient. (2) The data to be
transmitted was accumulated through a number of steps. This data was
still 'available' after the FTP failure.

So I checked, in JCL, for a good return code from the FTP step. If
the return code was bad I: (1) Passed control to a 'wait' job that
would wait x number of minutes. (2) Retried the FTP ... This solution
worked very well.

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

Multiple FTP Problems

[Warner Mach]

To return to the original problem:


We have an application that does some client server stuff then attempts 
to
ftp some files back to z/OS.  Mostly this works fine except it seems 
when 2
or more ftps are attempted at the same time with the same userid.  Then 
we
get "failed to connect" to the z/OS ftp server.  Is there an ftp 
parameter
that would stop multiple ftps from the same user taking place.
 

I had the following FTP problem whose resolution may be of some value 
in your case:

We were, overnight, FTPing a large number of files from the mainframe
to Windoze servers. It seemed that some of the jobs were interfering
with each other (problems on the Windoze side of course) ... I
realized that: (1) The problems were transient. (2) The data to be
transmitted was accumulated through a number of steps. This data was
still 'available' after the FTP failure.

So I checked, in JCL, for a good return code from the FTP step. If
the return code was bad I: (1) Passed control to a 'wait' job that 
would wait x number of minutes. (2) Retried the FTP ... This solution 
worked very well.

--
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: multiple FTP problems

[Jim McAlpine]

Yes, MAXPROCUSER is correctly  limited to 3, but ftp doesn't seem to be
affected.

D OMVS,L,PID=33620039
BPXO051I 15.49.13 DISPLAY OMVS 635
OMVS 000D ACTIVE  OMVS=(RW)
USER JOBNAME  ASIDPID   PPID STATE   START CT_SECS
TSO01TSO0100CA   33620039   16842769 1FI--- 15.47.43   .40
 LATCHWAITPID= 0 CMD=/usr/sbin/ftpdns 2137213608
PROCESS LIMITS:LIMMSG=NONE
 CURRENT  HIGHWATERPROCESS
   USAGE  USAGE  LIMIT
MAXFILEPROC 7  8  1
MAXFILESIZE   ------NOLIMIT
MAXPROCUSER 1  1  3
MAXQUEUEDSIGS   0  1   1000
MAXTHREADS  0  0  1
MAXTHREADTASKS  0  0   5000
IPCSHMNSEGS 0  0500
MAXCORESIZE   ------4194304

Jim McAlpine


On 10/18/06, Hunkeler Peter (KIUK 3) <[EMAIL PROTECTED]>
wrote:


You see me puzzled.

What does a "D OMVS,L,PID=" say, ( is the PID of
one of you test-user ftp processes)? It should display
the limit of 3 in the "process limits" column (although
this value is not a process but a uid limit).


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: multiple FTP problems

[Hunkeler Peter (KIUK 3)]

You see me puzzled.

What does a "D OMVS,L,PID=" say, ( is the PID of
one of you test-user ftp processes)? It should display
the limit of 3 in the "process limits" column (although
this value is not a process but a uid limit).


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: multiple FTP problems

[Jim McAlpine]

No, fraid not.

Jim McAlpine


On 10/18/06, Hunkeler Peter (KIUK 3) <[EMAIL PROTECTED]>
wrote:


Are you a superuser (uid=0)? uid=0 processes don't
have that limit.


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: multiple FTP problems

[Hunkeler Peter (KIUK 3)]

Are you a superuser (uid=0)? uid=0 processes don't
have that limit. 


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: multiple FTP problems

[Jim McAlpine]

Well, that didn't give the expected results.  I set up a user with
PROCUSERMAX set to 3 (the lowest allowed value) but I was able to connect
via ftp from windoze with 4 and 5 sessions.

Jim McAlpine


On 10/18/06, Jim McAlpine <[EMAIL PROTECTED]> wrote:


Thanks Peter, I'll check those out.

Jim McAlpine


 On 10/18/06, Hunkeler Peter (KIUK 3) <[EMAIL PROTECTED]>
wrote:
>
> The FTP Server starts a new process for each client connection.
> The z/OS UNIX parameter MAXPROCUSER limits the number of processes
> a user (userid) can have active simultaneously. This can be the
> limiting factor and might lead to the connection being refused
> (While I'm sure about the former point, I'm not sure how ftp
> will respond to such a limitation. Just never tried.)
>
> MAXPROCUSER is systemwide and is specified in BPXPRMxx, there is
> also a corresponding OMVS segment field called PROCUSERMAX which
> can allow different values for different userids
>
>
> 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: multiple FTP problems

[Jim McAlpine]

Thanks Peter, I'll check those out.

Jim McAlpine


On 10/18/06, Hunkeler Peter (KIUK 3) <[EMAIL PROTECTED]>
wrote:


The FTP Server starts a new process for each client connection.
The z/OS UNIX parameter MAXPROCUSER limits the number of processes
a user (userid) can have active simultaneously. This can be the
limiting factor and might lead to the connection being refused
(While I'm sure about the former point, I'm not sure how ftp
will respond to such a limitation. Just never tried.)

MAXPROCUSER is systemwide and is specified in BPXPRMxx, there is
also a corresponding OMVS segment field called PROCUSERMAX which
can allow different values for different userids


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: multiple FTP problems

[Hunkeler Peter (KIUK 3)]

The FTP Server starts a new process for each client connection.
The z/OS UNIX parameter MAXPROCUSER limits the number of processes
a user (userid) can have active simultaneously. This can be the
limiting factor and might lead to the connection being refused
(While I'm sure about the former point, I'm not sure how ftp
will respond to such a limitation. Just never tried.)

MAXPROCUSER is systemwide and is specified in BPXPRMxx, there is 
also a corresponding OMVS segment field called PROCUSERMAX which
can allow different values for different userids


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

multiple FTP problems

[Jim McAlpine]

We have an application that does some client server stuff then attempts to
ftp some files back to z/OS.  Mostly this works fine except it seems when 2
or more ftps are attempted at the same time with the same userid.  Then we
get "failed to connect" to the z/OS ftp server.  Is there an ftp parameter
that would stop multiple ftps from the same user taking place.  I've RTFM
but can't find anything.

Jim McAlpine

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