Keep trailing spaces using FTP 1

[shieh]

I want to ftp a file created on main frame that is fix length record of file. There are trailing spaces at each record. How can I keep all tailing spaces when GET it from Unix machine? I put CR at the end of each record to result the problem but I am looking for better solution that doesn't require altering the original file.

Thanks

Shieh

 

[Annihilannic]

Have you tried transferring it in binary mode? i.e. type bin before you type get filename.

Annihilannic.

 

[shieh]

Yes, I did try with binary mode. The original file is a text file and it turned into garbage unreadable file.

Shieh

 

[Annihilannic]

What kind of mainframe?

I would guess this behaviour is dependent on the FTP server on the mainframe. If you get a file like that from a UNIX system in ASCII mode it preserves the trailing spaces.

On some mainframes (Tandem, for example) you can write datafiles in a binary format (spaces, line feeds and all) which you could then download to your UNIX system using binary mode.

Annihilannic.

 

[shieh]

It is IBM MF. I initiate ftp session from Unix so it is up to unix to handle ftp function. Problem is that there is no option of reserving trailing spaces from ftp of unix(Solaris). Under MF, I can specify this option if I initiate ftp from MF.
I can put \n(new line or CR) at the end of text file on MF and it works. In order to do that I have to create a program to put this special character to all the files I want to transfer but the user doesn't allow me to alter the size of the file. It sounds funny, isn't it.
Another solution is putting trailing spaces back when it move over to Unix.

Neil

 

[Annihilannic]

It takes two to tango. The FTP client has little control over how the FTP server sends the information.

I've tested UNIX to UNIX and it also preserves the spaces.

Annihilannic.

 

[shieh]

Unix to unix is no problem because it has \n at end of each line. However there is no CR or NL at end of line on MF. When it transfers to unix all spaces got trimed.

Shieh

 

[vgersh99]

for Solaris's 'man ftp':

cr Toggle <RETURN> stripping during &quot;network ASCII&quot;
type file retrieval. Records are denoted by a
RETURN/LINEFEED sequence during &quot;network ASCII&quot;
type file transfer. When cr is on (the default),
<RETURN> characters are stripped from this
sequence to conform with the UNIX system single
LINEFEED record delimiter. Records on non-UNIX-
system remote hosts may contain single LINEFEED
characters; when an &quot;network ASCII&quot; type transfer
is made, these LINEFEED characters may be dis-
tinguished from a record delimiter only when cr is
off.


vlad
+----------------------------+
| #include<disclaimer.h> |
+----------------------------+

 

[shieh]

CR option on FTP at unix machine is for whether stripe CR or not when there is CR on the original file. The file I try to download is on MF and there is no CR on each line of the file. Basically all trailing spaces got trimed when it download to Unix machine.

Shieh

 

[SamBones]

A unix FTP has no concept of a record like on the mainframe side. To unix it's just a stream of characters. With the exception that for an ASCII transfer, it does do on the fly conversion to valid unix ASCII text based on the sending system (i.e. stripping CR's from MS Windows, and EBCDIC to ASCII conversion from IBM mainframes).

The FTP client on unix CAN change some properties of the FTP server, IF the FTP server supports it and allows it. The command to pass these commands to the FTP server from the client is &quot;[tt]QUOTE SITE[/tt]&quot;.

The following is some code that I'm using to send a file to an IBM mainframe from a unix machine (names have been changed to protect the innocent). There's no login commands because I'm using a [tt].netrc[/tt] file for the username and password.

ftp mvs123.mycompany.com <<-FTPCMDS
	quote site vol=abc123
	quote site recfm=fb lrecl=196 blksize=9800
	quote site primary=100 secondary=10
	put filename.YYYYMMDD.DAT <destination file name>
	bye
FTPCMDS

I don't quite remember what all of the values are for. They were given to me by the mainframe guy when I was setting this up. When I was just doing a [tt]put[/tt] without the [tt]quote site[/tt] commands, it was chopping the file into 80 byte fixed length records (the size of an IBM punched card, heh heh).

Anyway, you can probably find some parameters that will get you what you need. I found all of what I needed with a Google search. Maybe try Googling for &quot;quote site&quot; and see what you get.

You could also probably use the &quot;garbage unreadable file&quot; you got when doing the binary transfer. This file should be all correct, it's just that it's in EBCDIC, not ASCII. You can use a [tt]dd[/tt] command to convert it to ASCII. See the [tt]man[/tt] page for help on using it. There are a number of options depending on the format of the file on the mainframe side.

Hope this helps.

 

[shieh]

Great, it worked.

Thanks so much for all of your help

Shieh