IBM Mainframe Forum

Hi
I want to transfer text file from Mainframe to windows on a shared drive.
I have this written on my code:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000021 //FTPLOC EXEC PGM=FTP
000022 //OUTPUT DD SYSOUT=*,RECFM=FB,LRECL=0,BLKSIZE=0
000023 //SYSPRINT DD SYSOUT=*
000024 //INPUT DD *
000025 FTP -p 99.999.999.99
000026 USERNAME
000027 PASSWORD
000028 cd /C/TEMP
000029 PUT 'DBKPNMRA.AAAAAA.A.TXT' a.txt
000030 CLOSE
000031 QUIT
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
99.999.999.99 is my computer's IP Address.
USERNAME is my computer's username
PASSWORD is my computer's password.
"DBKPNMRA.AAAAAA.A.TXT" is the mainframe file name.
a.txt is the windows file name that i want.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

This is the error that I get:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
EZA1736I FTP
EZY2640I Using 'SYS1.TCPPARMS(FTPDATA)' for local site configuration parameters.
EZA1450I IBM FTP CS V1R10
EZA1456I Connect to ?
EZA1736I FTP -p MY_IP_ADDRESS
EZA1554I Connecting to: FTP.crdc.XX.org SOME_OTHER_IP_ADDRESS port: 21.
220-TCPCFTP1 IBM FTP CS V1R10 at MVSP20F.CRDC.XX.ORG, 15:06:40 on 2011-12-22.
220 Connection will close if idle for more than 5 minutes.
EZA1459I NAME (FTP:[b]MY_USER_ID):
EZA1701I >>> USER MY_USER_ID
331 Send password please.
EZA1789I PASSWORD:
EZA1701I >>> PASS
530 PASS command failed
EZA1460I Command:
[/b]EZA1736I cd /C/TEMP
EZA1701I >>> CWD /C/TEMP
530 You must first login with USER and PASS.
EZA1460I Command:
EZA1736I PUT 'DBKPNMRA.AAAAAA.A.TXT' a.txt
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Please Help

If you are saying that you have given one IP address and the ftp has connected to a different IP address, then you'd need to talk first to your Network Support people. Assuming that you have already double-checked the IP address you are providing as being correct.

Is your mainframe FTP connecting to a SERVER or a DESKTOP? The distinction is critical since desktop machines do not run the software required to act as an FTP server, and in that case what you want to do cannot be done -- period. If you are attempting to connect to a server, then your site support group MUST be involved since obviously your DNS resolution either is not right, or the IP address is being forced to a different one -- and only your site support group will know which.

The "SOME_OTHER_IP_ADDRESS" is related in someway to my mainframe.
the 9 digit ip address that appears on my mainframe on the left side bottom is same as the "SOME_OTHER_IP_ADDRESS"
EXCEPT FOR THE LAST DIGIT.
THE FIRST EIGHT DIGITS MATCH.
LIKE if "some_other_ip_addresss" is ========999.99.999.9
at my bottom left on mainframe screen it is=999.99.999.8

I hope it makes sense now.
I am sorry. I should have mentioned it earlier itself.

OK, at least that is less spooky. Same advice. You need to talk to your support. You'll probably get a quick, "yes, sorry, forgot about that", because they know your setup. We know nothing about your setup. Even if someone wanted to try to walk you through it, you wouldn't have access to the right stuff to find it, let alone fix it, because it is not your job, it is "theirs".

Many times the mainframe is set up with multiple IP addresses so the TCP/IP stack is not a single point of failure. This could be the difference you're seeing since the DNS resolver may "round robin" between the various IP addresses -- but as has been mentioned, only your site support group can say for sure.

Hello and welcome to the forum,

If this is not yet resolved with your support people, and you want the file on your desktop quickly, i suggest you use the ftp client software on your pc to "pull" the file to your desktop rather than trying to "push" the file via batch ftp from the mainframe.

Once the issues have been resolved, the manual "pull" would be discontinued.

Umm, it looks like a simple wrong userid/password to me.

I know when we set things up like this (going down to network land) we have to have user ids that are very long, and contain the context of the userid: userid.groupname.treename.containername.directoryname

Also remember that is has to the userid/password that WORKS ON THE NETWORK!! Not the mainframe userid/password.

Thanks for your help:
The issue is not yet resolved yet. So i have a few more questions.
>>>>is the following command CORRECT?
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
000021 //FTPLOC EXEC PGM=FTP
000022 //OUTPUT DD SYSOUT=*,RECFM=FB,LRECL=0,BLKSIZE=0
000023 //SYSPRINT DD SYSOUT=*
000024 //INPUT DD *
000025 FTP -p 99.999.999.99
000026 USERNAME
000027 PASSWORD
000028 cd /C/TEMP
000029 PUT 'DBKPNMRA.AAAAAA.A.TXT' a.txt
000030 CLOSE
000031 QUIT
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
There is some progress though:
>>>When I try to ping from mainframe to my shared drive i am able to do it.
This is why i doubt my JCL.

>>>Should the userid & password be my computer's username and password or something else?
The shared drive is mapped so i dont have to enter any userid/password when i want to copy it or put anything into it.
I "THINK" i have complete access on the drive.

I hope i have helped you understand my problem more.
Also as I said earlier: we have FTP tools to do it but we want a JCL to do it.

Thanks for all your help.

The other issue is the mainframe FTP program you're using. Some of them want the address in the PARM. I'm not sure what

FTP -p 99.999.999.99

is supposed to do; it seems non-standard. The "standard" would be, I think -

OPEN 99.999.999.99

99.999.999.99 is not the usual IP address, a regular IPV4 address maxes at 255 in any element. Of course you could just be hiding your real address, and that's OK with me.

Most FTP servers set some sort of default path based on the user, so you might not need the CD command. "cd /C/TEMP" does not seem to be valid for a Windows based server, but I don't know your server.