|
View previous topic :: View next topic
|
| Author |
Message |
Michelle1993
New User
Joined: 18 Mar 2009
Posts: 5
Location: Canada
|
|
|
|
I am attempting a Mainframe (MF) to MF transmission using FTP. However, for a few months, this must point to itself, i.e., the FTP is done from one MF to the same MF. This means the mainframe address in the following JCL is the mainframe address of the sending mainframe.
Is this at all possible?
If so, how do I get rid of the "450 Data set..." error?
Here is my JCL:
//*
//STEP030 EXEC PGM=FTP,REGION=0M
//SYSTCPD DD DSN=TCPIP.PARMS(TCPDATA),DISP=SHR
//SYSPRINT DD SYSOUT=*
//OUTPUT DD SYSOUT=*
//SYSIN DD *
(mf address)
(userid)
(pw)
PUT 'sending-filename' 'receiving-filename'
QUIT
The resulting execution report shows:
| Code: |
EZA1736I FTP
EZY2640I Using /etc/ftp.data for local site configuration parameters.
EZA1450I IBM FTP CS V1R9
EZA1456I Connect to ?
EZA1736I (mf address)
EZA1554I Connecting to: (destination address) port: 21.
220-FTPD1 IBM FTP CS V1R9 at (site info), 18:50:31 on 2009-03-17.
220 Connection will close if idle for more than 5 minutes.
EZA1459I NAME (destination address:userid):
EZA1701I >>> USER (userid)
331 Send password please.
EZA1789I PASSWORD:
EZA1701I >>> PASS
230 (userid) is logged on. Working directory is "(userid).".
EZA1460I Command:
EZA1736I PUT 'sending-filename' 'receiving-filename'
EZA1701I >>> SITE FIXrecfm 80 LRECL=80 RECFM=FB BLKSIZE=27920
200 SITE command was accepted
EZA1701I >>> PORT (ports)
200 Port request OK.
EZA1701I >>> STOR 'receiving-filename'
450 Data set (receiving-filename) is allocated to another job and is unavailable for STOR command.
EZA1460I Command:
EZA1736I QUIT
EZA1701I >>> QUIT
221 Quit command received. Goodbye. |
Much obliged! |
|
| Back to top |
|
 |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello Michelle and welcome to the forum,
Looks like your "client" job successfully connected to your manframe server and "sent" the file  |
|
| Back to top |
|
|
Michelle1993
New User
Joined: 18 Mar 2009
Posts: 5
Location: Canada
|
|
|
|
Hello Dick Scherrer,
The file has not been "sent": I have put ICEGENER steps before and after the FTP step to dump the contents of the receiving file, and the contents has not changed.
It is indicated that the STOR command did not execute successfully.
Thanks again! |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Code: |
| 450 Data set (receiving-filename) is allocated to another job and is unavailable for STOR command. |
I misread this first time thru 
Suggest you delete the current output file and allocate another that is empty. Also make sure that you don't have the file in use in tso or somewhere else. |
|
| Back to top |
|
|
Michelle1993
New User
Joined: 18 Mar 2009
Posts: 5
Location: Canada
|
|
|
|
Hello,
I have tried a couple of things:
- deleting the current output file AND letting the FTP step run: got the same "450 Data set..." error, and the dataset was not created
- deleting the current output file and recreating it prior to running the FTP job: got the same "450 Data set..." error, and the dataset was empty
- I have tried with the "receiving file" attached to my own userid, to someone else's userid, to the application high level qualifier: always the same "450 Data set..." error.
The file is not is use at the time the FTP job is running UNLESS the FTP step itself puts an exclusive hold on that filename (as the receiver) and cannot write to it (as the sender).
By the way, all of this works just perfectly IF the destination address is NOT the same as the sending mainframe.
Any idea? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Well, i've never tried to send something from a mainframe to the same mainframe. . . In that back of my head, i thought it might work as the jobstream would be a client and the ftp server might interract as with some other client. You might talk with your network support people to see if this is something familiar.
| Quote: |
| By the way, all of this works just perfectly IF the destination address is NOT the same as the sending mainframe. |
This may be the way to go until the true destination server can be brought into the loop.
Good luck |
|
| Back to top |
|
|
Michelle1993
New User
Joined: 18 Mar 2009
Posts: 5
Location: Canada
|
|
|
|
Hello again,
Well, we wanted to avoid any code change at project cutover (host migration) but we may not have a choice...
I will talk with the network team... and will let you know if a solution is found.
Thanks for all your support!
Michelle |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
If the ftp jcl is put in a PROC and the ftp control info put into a member referenced by a symbolic variable, the switchover would need very little last minute modification.
| Quote: |
| Thanks for all your support! |
You're welcome - someone will be here if there are questions |
|
| Back to top |
|
|
Michelle1993
New User
Joined: 18 Mar 2009
Posts: 5
Location: Canada
|
|
|
|
Good morning (at least for me)  ,
The usage of PROC and symbolic variables is the current method used at our site, and it is exactly the way we manage different environments as well as minimize our last minute changes.
In this particular case, Application A currently produces a file used by Application B, both on same host. At end state however, Application A has migrated to new MF host, but must continue producing file for Application B on old host.
I wanted to immediately implement App A --> FTP --> App B while on the same host. At cutover, from application viewpoint, absolutely no impact... As we know, when on different hosts, the FTP works like a charm.
But I will pick my network people's brain, and will advise of the outcome.
Thanks again for the support and words of wisdom!!!
Michelle |
|
| Back to top |
|
|
|
|
