How to FTP GET a file

karthickrrajamani · New User Joined: 19 Aug 2008 Posts: 4 Location: Chennai

I'm using a GET command to retrieve a file from my remote location and i see that the output file has spaces between each character as shown below. Also multiple records are getting concatenated as 1 long string. Any confirgurations I am missing ? Please enlighten

=COLS> ----+----1----+----2----+----3----+----4----+----5----+----6---
****** ***************************** Top of Data *********************
000001 ~1 1 0 6 0 2 ; 0 9 1 6 2 ; G 9 5 1 0 4 7 0 3 1 ; 0 0 0 0 0 0 1

Bill Woodger · Posted: Fri Jun 10, 2011 2:19 am

Can you copy & paste the messages from the transfer with "code tags" (button above the input form, says Code)?

Can you also do a hex display for the data above, and where you think your data should be a 2nd record, and the end of the file?

karthickrrajamani · New User Joined: 19 Aug 2008 Posts: 4 Location: Chennai

dick scherrer · Posted: Fri Jun 10, 2011 2:45 am

Hello,

The info you posted has been "Code'd".

A mentioned, it will probably help if you show the data using "HEX ON". Posting the same thing from the remote may also help.

How are the files defined (i.e. mainframe file info from 3.4 - anything that is available from the remote) ?

superk · Posted: Fri Jun 10, 2011 2:48 am

karthickrrajamani, as far as we know, that's what the data is supposed to look like. I'm not going to let this topic drag on and on just to find out that the data, not created on a mainframe, is the source of the problem, which of course it is. Bill asked for the data content IN HEX, and I concur. You need to post a hex dump of the ASCII data, as it appears on the Microsoft FTP server.

karthickrrajamani · New User Joined: 19 Aug 2008 Posts: 4 Location: Chennai

I do have the file sent to us from the server as it comes from a different app team. All i know is that cognos tool creates this csv file and when we receive it, we receive it with spaces in between.

The file in mainframe is defined as Fixed Block with an LRECL of 800.

My doubt would be whether a "csv" file could be the source of the issue ?

Bill Woodger · Posted: Fri Jun 10, 2011 3:06 am

H-E-X

What do you, personally, make of the tilde? That's this thing: ~

Are you expecting that? Your second record doesn't have anything like it, but has something that "looks like space".

Try to do this, then you get the next bit.

Robert Sample · Posted: Fri Jun 10, 2011 3:08 am

karthickrrajamani, what are you expecting the data to look like? Are the other three semicolons in the record that you did not mention also end of record markers? If not, what distinguishes an end of record semicolon from any other semicolon (hopefully the HEX display will shed some light on that)? There's a great deal of information you did not provide -- information that is required to identify and resolve your issue (and answering the questions so far posted will probably only lead to other questions before answers).

dick scherrer · Posted: Fri Jun 10, 2011 3:08 am

Hello,

As Kevin mentioned - you need to see the hex of the remote file. Once you know exactly what you are working with, some progress can be made.

One thing i do when uploading data to the mainframe is to pre-allocate the receiving file on the mainframe with the attributes i want (i.e. fb, lrecl=800).

Bill Woodger · Posted: Fri Jun 10, 2011 3:55 am

He seems to have just wandered off (again, see his only other topic).

FB, LRECL 800. 530 bytes of data all as one record instead of individual records. No big surprise.

What about the ASCII mode for the transfer? I'd expect EBCDIC or BINARY. Yet we can read, at least some of, the data. Are we seeing the file after the transfer, or after it has been de-ASCII'd by something?

Robert Sample · Posted: Fri Jun 10, 2011 6:07 am

Bill, I'm thinking UTF-8, which is backward compatible with ASCII but can use 1 to 4 8-bit bytes per character.