|
View previous topic :: View next topic
|
| Author |
Message |
kkxlnc
New User
Joined: 12 Jun 2005
Posts: 44
Location: Boston
|
|
|
|
We have an issue with a ftp process. We are zipping a file on mainframes (.zip using pkzip, the EBCDIC to ASCII conversion is being handled). This file is being sent to a windows based server using SFTP process. Another SFTP process send this file over to the vendor. The vendor is unzipping the file at his end.
eg:
say the record length on originating mainframes is FIXED 1000 bytes.
the vendor after unzipping the file is getting a variable blocked file and hence unable to process it as expected
The data itself is perfectly readable, but the record length is distorted.
Please suggest how to handle this data transmission? |
|
| Back to top |
|
 |
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1306
Location: Vilnius, Lithuania
|
|
|
|
z/OS XMIT+AMATERSE (or ADRDSSU) -> binary ftp -> PC -> binary ftp -> z/OS AMATERSE+RECEIVE (or ADRDSSU)
ZIP on z/OS when you have real tools? Gimme a break! |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
If you zip the file on the mainframe, transfer it to somewhere in the middle, from there to the destination, then unzip it, then it should arrive as you sent it (it has gone all the way as "binary", otherwise it would be a garbled mess at the other end).
Most likely the "vendor" is doing something, wittingly or otherwise.
I'm guessing you can't visit the vendor? Ask them to send the zip file back to you without doing anything to it, along with a zipped file that the vendor "received". So, you get two zips back. One should be identical to what you have sent out. The other should give you some clues about what the vendor has done.
Is the "vendor" on a mainframe (you mention they are getting "variable blocked"? |
|
| Back to top |
|
|
kkxlnc
New User
Joined: 12 Jun 2005
Posts: 44
Location: Boston
|
|
|
|
Yes, the vendor is on a mainframe. We just suggested him to give a LRECL (not sure what he put on his unzip JCL) similar to ours on the output file. Waiting for his response to see if that works for him. Else, your suggestion is good. We will ask him to send that zip file (that he received) back to us and we will check if there is an issue.
Thank you for the help. |
|
| Back to top |
|
|
Ed Goodman
Active Member
Joined: 08 Jun 2011
Posts: 556
Location: USA
|
|
|
|
If they need a file with an LRECL, why are you translating to ASCII? The PKZIP program is probably assuming you will be using the file on a system that uses cr/lf to show end of record. It will truncate the lines for you on purpose.
Since you say they are getting RECFM=V, then they are probably opening it on some form of mainframe file system (maybe a real mainframe, maybe an emulator like Microfocus)
Please tell us the type of system on which they are using your file. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Good point from Ed.
I was assuming you'd tried "unzipping" your own file as part of the testing?
Also, if mainframe-mainframe, as Prino has pointed out, why use pkzip? It is just a lump of data passing through the Windows box, so no need for pkzip if data content not needed on PC? |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| Bill Woodger wrote: |
| Also, if mainframe-mainframe, as Prino has pointed out, why use pkzip? It is just a lump of data passing through the Windows box, so no need for pkzip if data content not needed on PC? |
If the data set has a lot of whitespace in it, there may be non-trivial savings in time and cost in transmitting the compressed data, even given the need to compress it and then decompress it. There are better choices than PKZIP for data compression on the mainframe, but the fact that there's a Wintel box in the midst of the process suggests that the design involved a toy computer analyst who'd never heard of another way to do things. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Akatsukami wrote: |
suggests that the design involved a toy computer analyst who'd never heard of another way to do things.
|
Straight to the heart of the matter! |
|
| Back to top |
|
|
|
|
