FTP File Transfer from PC to Mainframe

George Tillmon · Posted: Wed Feb 02, 2011 8:24 pm

Hi.

I am trying to transfer a file on my pc to the mainframe.
The file is a text file that is downloaded from a website. The record length is 460.
I then ftp it to the mainframe.
However, when I browse the file on the mainframe it only has one line in it. The file shows beinf VB with a record length of 256.
I need the file to have a length of 460 and break correctly so that I can use a program to to generate a report.
I have tried the LOCSITE command with RDW, TRAIL.
I have tried MODE E, A and B.
Nothing works.

HELP!!!!!

Thanks,
George

Robert Sample · Posted: Wed Feb 02, 2011 8:34 pm

Assuming you're starting the transfer on your PC, try this:

George Tillmon · Posted: Wed Feb 02, 2011 9:07 pm

Robert Sample · Posted: Wed Feb 02, 2011 9:21 pm

The SITE and LOCSITE commands are used for the remote system and local system respectively. Which you would use depends upon whether the maifnrame is initiating the connection or not. The QUOTE prefix tells the local machine to pass the rest of the command to the other side without parsing it, which is needed when Windows machines don't know what an LRECL is (for example).

George Tillmon · Posted: Wed Feb 02, 2011 9:25 pm

Robert Sample · Posted: Wed Feb 02, 2011 9:37 pm

Is the data in ASCII or EBCDIC on the PC? I'm assuming the file has fixed length records, but could you confirm that? If the file is ASCII text on the PC, what are the line ending character(s)? Getting the FTP options right can be challenging, depending upon the characteristics of the data in the file.

George Tillmon · Posted: Wed Feb 02, 2011 9:55 pm

Robert Sample · Posted: Wed Feb 02, 2011 10:13 pm

Did this data come from a Unix machine, perchance? If so then the line terminator is probably the line feed character (as opposed to the Windows default of carriage return/line feed) -- hence the 461 bytes per line (50 bytes per record).

Assuming this is the case, add SBSENDEOL=LF to your SITE (or LOCSITE) command to change the line termination sequence.

George Tillmon · Posted: Wed Feb 02, 2011 10:20 pm

Thanks, however, it still does not work.

This is what I get after executing the jcl:
EZA1460I Command:
EZA1736I LOCSITE RECFM=FB LRECL=460 BLKSIZE=23460 SBSENDEOL=LF
EZA1460I Command:
EZA1736I GET APP\GT\CR110129.TXT 'GT.CMS.CLAIM.RESP' (REPLACE
EZA1701I >>> PORT 10,143,14,11,4,233
200 PORT command successful.
EZA1701I >>> RETR APP\GT\CR110129.TXT
150 Opening ASCII mode data connection for APP\GT\CR110129.TXT(23050 bytes).
226 Transfer complete.
EZA1617I 23050 bytes transferred in 0.005 seconds. Transfer rate 4610.00 Kbytes
EZA2802I Data was truncated.
EZA1460I Command:
EZA1736I QUIT generated by unexpected end of file
EZA1701I >>> QUIT
221

Here are the pertinent lines from the mainframe ftp:
000009 //INPUT DD *
000010 LOCSITE RECFM=FB LRECL=460 BLKSIZE=23460 SBSENDEOL=LF
000011 GET APP\GT\CR110129.TXT 'GT.CMS.CLAIM.RESP' (REPLACE

Robert Sample · Posted: Wed Feb 02, 2011 10:32 pm

I think at this point your best bet is to set up an FB file with LRECL 23050 and transfer the file in BINARY to the mainframe, then use ISPF to view the file and see what is at the end of each line. If the data is ASCII, you may have to do some research into the character translation, but the 51st (and 102nd and ...) bytes should be the same and will be the line termination character.

superk · Posted: Wed Feb 02, 2011 10:50 pm

George, before you even attempt to FTP the file, open it up with a hex editor (or use the DOS DEBUG command) and make sure it has the necessary end-of-line and end-of-file characters that are mandatory for z/OS. If not, you'll have to, as Robert suggested, transfer it in BINARY, or have the entity that produces the file fix it.

George Tillmon · Posted: Wed Feb 02, 2011 11:32 pm

Robert, I did as you suggested and here is what I found.

The supposed last character is a "." (period or dot).
When I do a hex display on it it shows as 25.

Like this:
.
2
5

Robert Sample · Posted: Thu Feb 03, 2011 12:46 am

EBCDIC defines hex '25' as LF so it is a line feed character. A couple of things that might work:

1. FTP to a Unix System Services file and use OGET to transfer from USS to z/OS.

2. use an FTP translate table to translate the X'0A' ASCII into an X'15' EBCDIC.

George Tillmon · Posted: Thu Feb 03, 2011 1:03 am

Thank you JESUS!!!!!

I got it guys.
I used PSPad to change it form UNIX to DOS and set the length to 460 and it worked!!!!

Thank you all for your time ans assistance.

George

Robert Sample · Posted: Thu Feb 03, 2011 1:08 am

Very good to hear you got it resolved!

Hank Watson · New User Joined: 25 Nov 2010 Posts: 6 Location: Miami, FL

Regarding Robert Sample's reply:

dick scherrer · Posted: Fri Feb 25, 2011 10:53 pm

Hello,

One thing to try would be to pre-allocate the receiving file (fixed length) on the mainframe so that the lrecl includes the x'0A'.

This worked for us when transferring files created on HP-UX to MVS.

If this doesn't work, post some details and we can see. . .

superk · Posted: Fri Feb 25, 2011 11:24 pm

FTP it in binary (i.e. keep the data in its raw ASCII format). Then, once you have it stored in a dataset, translate it into EBCDIC and strip off the LF characters.

Hank Watson · New User Joined: 25 Nov 2010 Posts: 6 Location: Miami, FL

That's what I finally stumbled across. I was concerned because in one instance of the file on the Unix box, there were newpage (x'0C') characters every 60 lines. With those thrown in the mix, I couldn't retrieve the file. But when Unix file creation was modified to put out only the data records, then this is what works for me: