On Wednesday 24 June 2009, Vikesh Bhoola wrote:
> Kirk, thanks for info on Co:Z.
>
> Its not that I hate OMVS...
I should hope not!
> Apart from the single "-" file name within zip this is great. I
> assume there is no way getting around this one ?
This is a limitation of zip - no external tool can get around it.
That's the way zip handles input from stdin.
Using stdin is a hack solution at best. It's just that zip doesn't
like the idea of having a filename that starts with "//". You'd have to
request a change to zip/unzip from the developers, along the lines of
the "dots" vs "slashes" stuff that's been done. I think that this would
be a good idea, actually.
That said, your technique of using zip isn't much different from
using gzip or bzip2 - you typically depend on the filename of the
compressed file to identify what you're extracting. (Yes, I know that
gzip actually carries the name of the compressed file internally, but
most people don't care because they're piping to and from tar.)
> We are hoping to get gzip2 installed soon (still waiting on the
> order) than perhaps can get past this.
Do you mean bzip2? I think the latest gzip is 1.3.12 or something.
(I think that once we have zip/unzip for z/OS up to the current
release, we should try building bzip2 1.0.5 and gzip 1.3.12 - both of
which support large files! Has anybody tried that?)
Neither gzip nor bzip2 gets around the one file per archive issue;
they are both just compressors, not archivers. And bzip2 doesn't even
carry the name of the original file in the archive (just like the
ancient Unix compress program - no meta data, just the file data).
I know that they allow you to concatenate a series of files into one
compressed file - but I really don't think you'll like the result.
In other news, however...
I think I have the cmsmvs version of zip pretty well done as of last
night, but I need to do some more testing, etc. Then I have to make a
comprehensive patch combining that plus the stuff for the Unix
version, , undo a couple of changes that I've rethought, do a bunch of
code cleanup, and convince the Info_ZIP guys of the impeccable
correctness of my changes so they'll accept it into the next release.
So you might want to start reviewing the zip documentation on
setting up the JCL to run zip and unzip - or have you already got that
set up? I've never tried doing that from the MVS side of the house, but
I've got a loadlib with what I *think* are workable copies of zip
3.1b++ unzip 6.0 in it.
That "++" means that I've gotten my patches all tangled up with
Lutz' recent patches, and I have to back up to the 3.1b base and create
a clean set of just my stuff. :-(
As far as I can tell, the quick and dirty little unzip 6.0 patch I
submitted a couple of weeks ago was all that was needed for unzip -
I've been using it for the last couple of weeks on all kinds of zip
files - large and small, new and old, good and corrupted - with no
problems; Lutz reported that it worked fine for him, too.
Cheers,
Bob
--------
Bob Woodside
[email protected]
http://www.woodsway.com
> > http://www.zjournal.com/index.cfm?section=article&aid=1075
>
> Thanks for this link, a solution we may consider.
>
> Regards,
> Vikesh
> Please Note: This email and its contents are subject to our email
> legal notice which can be viewed at
> http://www.sars.gov.za/Email_Disclaimer.pdf
>
> ---------------------------------------------------------------------
>- For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
