FTP From mainframw

[Hamdy Al-Sebaey]

we've HP server I try to send & get files to & from mainframe, to send the files, there is no probleem at, but to get the files every time I get it with different records.
Is there something to changed on my side or on the side of mainframe?

Thanks in advance,
Hamdy

[Alexander M. Ermes]

Hi there.
You may run into problems with the recform from the mainframe. If the recform is variable,
you have a problem. Try it with a fixed recordlength. Be careful about the characters for EOF or LF-CR. Check the files as soon as you have them for these.
Rgds
Alexander M. Ermes

[Roger Baptiste]

Hi,

<>

what do you mean by diff records?? Do you mean the filesizes are different every time you get them?? Does the ftp get process hang each time this happens?? Are you running this through a automated script?? What format(ascii/bin? are you using? Was this ever working fine??

<>

Make sure whether the file you are getting is a static one (i.e no mainframe process is writing to it- that way you would not get the same size)
Try the ftp process Manually from the command line and see whether you get it consistently.
See whether the problem (if it is) is for all file sizes or for only huge file size?

I ran into FTP issues wrt Mainframe sometime back and did all these. Ultimately, it turned out the mainframe guys had some patch issue and sorted it out at their end. It is important that you zoom in to the exact problem clearly.


-raj

[harry d brown jr]

What kind of mainframe? Are the files you are getting from the "mainframe" containing extra carriage returns or is the data you are getting being truncated? You will probably need to foll around with the "type" command - binary.

live free or die
harry

[Hamdy Al-Sebaey]

Hi Raiman,
The record varaible is not coming to our server(HP) as it is on the mainframe, I mean it coming with another record length.

Haary, I'm sorry but the main frame is for another company,I do'nt know which kind of mainframe.

[Roger Baptiste]

<>

Give bin type transfer a try, to see whether it works.

HTH
raj

[Hamdy Al-Sebaey]

Hi Raiman,
I tried but it does'nt work, as you mainframe supports record variable length.I think that there must be something to be changed on the side of mainframe.

[Roger Baptiste]

Hamdy,

If the file size is not correct even after trying with bin format and through a regular command option of ftp, then i think it is time to call (or grab) the mainframe admin folks.

From your end , if FTP is working fine for all other files(and sizes), there is nothing much to do.

HTH
raj

[Hamdy Al-Sebaey]

Raijman,
Thanks alot,that is what I thought about to contact the mainframe admin.

Regards,
Hamdy

[Bill Hassell]

As a general rule, transferring data files between unlike computers is full of peril. Those of you that transferred ASCII files between HP-UX and a PC have seen the ^M characters and similarly, PC users see ASCII files from HP-UX with black squares when viewed in Notepad.

The problem is that ftp can perform only one translation: ASCII. When using ASCII as the transfer mechanism, the source bundles each record (as defined by the source computer) into an FTP-defined package. When the destination sees this record, it writes the record according to the rules of the destination machine, whether it is a PC, a MAC, an MPE (HP 3000) mainframe or some other computer.

So ASCII is the ONLY compatible file transfer method. When transferring BINARY data files, the records are read according to the rules of the source machine, but in the case of Unix, there are no defined record separators kept inside the file...it is up to the creating program to define what is written and how to access the data.

That is very different from mainframes systems where there are dozens of filetypes (fixed reclen, blocked records, variable length, ISAM, KSAM, and the list goes on). The mainframe knows how to decode the file records into something the program understands, but on the Unix side, nothing but a compatible program will be able to understand or create binary compatible records. So sending the file in BINARY mode is a WYSIWYG task while ASCII mode will insert (possibly inappropriate) characters into a binary data stream.

This is also why sharing data using CIFS/9000 (SAMBA) with PCs has so many problems. The filesystems can communicate about the location and size of the files, but the content is 100% defined in the operating system, and in the world of PCs vs. Unix, very little compatibility was designed into PC operating systems.

"After all, the only difference between PCs and Unix is that the slashes go the other way." spoken by a former sales rep who is now serving coffee mocha at Starbucks. ;-)

[Dave La Mar]

We do this daily from an IBM VM/VSE system to HP 11.0.
Transfers of VSAM (all types except KSDS), as well as sequential.
TCPIP for VSE, sending a VB vsam file, states -
"Input VSAM datasets have no restrictions on record length.
Actual record length is determined when the record is read."
The transfer type we use is ascii.
Going from HP-UX to vsam we do delcare a recz, but not from VSE to UNIX.
If the file is ksds I can see where you might get odd records, as the key is not translated correctly from EBCDIC to ascii in many cases.

I assume you are doing a get from UNIX.
Please post your ftp get parms and i will try it here.
d