FTP transfer



Post anything related to mainframes (IBM & UNISYS) if not fit in any of the above categories

FTP transfer

Postby p19689 » Thu Oct 28, 2010 8:49 pm

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 ?
p19689
 
Posts: 65
Joined: Fri Oct 01, 2010 1:13 pm
Has thanked: 0 time
Been thanked: 0 time

Re: FTP transfer

Postby Robert Sample » Thu Oct 28, 2010 8:56 pm

What parameters did you use for the FTP?
Robert Sample
Global moderator
 
Posts: 3719
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 279 times

Re: FTP transfer

Postby p19689 » Fri Oct 29, 2010 1:59 pm

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 ?
p19689
 
Posts: 65
Joined: Fri Oct 01, 2010 1:13 pm
Has thanked: 0 time
Been thanked: 0 time

Re: FTP transfer

Postby Robert Sample » Fri Oct 29, 2010 2:56 pm

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.
Robert Sample
Global moderator
 
Posts: 3719
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 279 times

Re: FTP transfer

Postby p19689 » Fri Oct 29, 2010 3:52 pm

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 ?
p19689
 
Posts: 65
Joined: Fri Oct 01, 2010 1:13 pm
Has thanked: 0 time
Been thanked: 0 time

Re: FTP transfer

Postby Robert Sample » Fri Oct 29, 2010 4:22 pm

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:
FTP n.n.n.n ( IP address of the LPAR )
logon with the user name and then enter the password
binary
put 'datasetname'
Robert Sample
Global moderator
 
Posts: 3719
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 279 times

Re: FTP transfer

Postby p19689 » Fri Oct 29, 2010 4:43 pm

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

:)
p19689
 
Posts: 65
Joined: Fri Oct 01, 2010 1:13 pm
Has thanked: 0 time
Been thanked: 0 time

Re: FTP transfer

Postby Robert Sample » Fri Oct 29, 2010 5:02 pm

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.
Robert Sample
Global moderator
 
Posts: 3719
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 279 times

Re: FTP transfer

Postby dick scherrer » Fri Oct 29, 2010 11:33 pm

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.
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6268
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 93 times

Re: FTP transfer

Postby steve-myers » Sat Oct 30, 2010 1:14 am

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.
steve-myers
Global moderator
 
Posts: 2105
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 243 times

Next

Return to All other Mainframe Topics

 


  • Related topics
    Replies
    Views
    Last post