IBM Mainframe Forum

Hi, I have FTP a unload dataset (Db2 unload) from prod to test LPAR. But the transfered dataset has lost the first character(Ã) from the dataset. I am not sure what else has changed in the file. Why files get corrupted in this manner when FTP ? We don't have shared DASD defined among LPARS. What's the better way to handle this please ?

What parameters did you use for the FTP?

Hi Thanks. I haven't used any parameters.
What I did was from the ISPF main menu select the option 6(commands)
FTP n.n.n.n ( IP address of the LPAR )
logon with the user name and then enter the password
put 'datasetname'

I thought FTP between mainframe is similar to transfer between midrage(AIX). Do I need to use any parameters for mainframe please ?

Depending upon what is in the DB2 unload, you may have to use BINARY instead of TEXT to transfer the data.

The FTP commands themselves are pretty standard on the mainframe, however, since the mainframe uses EBCDIC and not ASCII and has completely different file formats than Unix or PC machines, there can be differences in FTP. For example, you may have to allocate the receiving file on the server side and use put 'file.name' (replace to avoid space allocation problems -- or you can use the SITE command to provide the allocation parameters.

Another thing to consider: a print file routed to disk on the mainframe has format of FBA or VBA where the A means the first byte of each record is reserved for printer carriage control. If the sending file format is FBA or VBA, you may want to unload the data again into an FB or VB file to allow the first byte to be used for data.

Hi , Could you please clarify a little bit ? Yes , data is in EBCDIC format.
The dataset I have transferd has the following charateristics:
Organization . . . : PS
Record format . . . : VB
Record length . . . : 139
Block size . . . . : 8192

The above is the standard output from the DB2 tool. I think, I can't change the above parameters. What you are suggesting is to use special parameter, which help me to transfer as BINARY.
when I issue put 'file.name' (without any parameters) is it transfered in text mode ?

Your file transfer is in text mode. If there are any INTEGER or FLOAT columns in your unloaded data, they will not transfer correctly. In such a case, your FTP would need to be:

Hi Robert , Thanks very much. It worked. I guess in the future I need to use binary format for FTP if transfer between EBCDIC.

Glad to hear it worked.

I think the most important lesson to be learned is to know your data -- sometimes a text FTP makes sense, sometimes it does not. Only by knowing the data can you be sure which is needed.

Hello,

If the unloaded data contains packed-decimal data, this may (probably will) present an additional opportunity on the target system.

While does take a few minutes work, it is usually best to create a delimited text file (x'05' - tab character) to download.

The DCB attributes suggest it is a text file. As others have mentioned, transferring non-text (e.g., binary or packed decimal) data as a text file is very chancy, and transferring data with z/OS variable length records as binary data is also very difficult.

I can remember trying to download a text data set with RECFM=FBM years ago - this was before FTP or the 3270 data transfer function. It seemed the carriage control characters, binary data, changed based on the transfer method I used. I eventually got disgusted and wrote a program to remove the carriage control characters and insert the correct number of empty lines, or an EBCDIC form feed character for a new page, which consistently downloads as an ASCII form feed character. I still use this program! I load the transferred file into a decent word processor; Word Perfect seems to work best, and M$ Word and Open Office both work well if I want to print the file. I use Windoze Notepad just to display the file.