Thanks for the response.
On Wednesday 29 July 2009, Bob Woodside wrote:
I'm also trying to figure out which problem to attack first with my
limited resources - this one, or the problem with filename handling
between zip and unzip.
No rush Bob, either issue is no urgency as work around
On Monday 27 July 2009, Vikesh Bhoola wrote:
Thanks for your reply.
On Friday 24 July 2009, Bob Woodside wrote:
Does the cmsmvs version fail like this if you execute it under
z/Unix?
Tried that and it does not fail with an error :
Or does it just fail when you run it via the MVS JCL?
Thanks for your reply.
On Friday 24 July 2009, Bob Woodside wrote:
Does the cmsmvs version fail like this if you execute it under
z/Unix?
Tried that and it does not fail with an error :
/zip31b/mvs: zip -avl -MV=dots /tmp/TEST.zip /tmp/HLQ.FOURGIG.txt
Translating to ASCII...
zip
On Friday 24 July 2009, Bob Woodside wrote:
I don't see how zip can be failing now. Everything seems to be
defined correctly.
This is an odd one.
Has anyone else verified the zip patches (cmsmvs version) applied
results in the same message when zipping files over 4GB :
zip error: Entry
On Friday 24 July 2009, Vikesh Bhoola wrote:
On Friday 24 July 2009, Bob Woodside wrote:
I don't see how zip can be failing now. Everything seems to be
defined correctly.
This is an odd one.
Has anyone else verified the zip patches (cmsmvs version) applied
results in the same message
On Wednesday 22 July 2009, Vikesh Bhoola wrote:
On Wednesday 22 July 2009, Bob Woodside wrote:
Try this. Edit the file zip.c.
[snip]
Thanks for your assistance, done the above I get the following :
[snip]
Zip special compilation options:
* size of int: 4
* size
Bob, thanks for the info on the patches. I have re-done this and did not
get any prompts or rejects this time round. Uploaded the file to z/OS
it compiled successfully. I verified the patches are in, but still get
the error for zipping a file over 4GB :
zip warning: Entry too
On Wednesday 22 July 2009, Vikesh Bhoola wrote:
Bob, thanks for the info on the patches. I have re-done this and did
not get any prompts or rejects this time round. Uploaded the file to
z/OS it compiled successfully. I verified the patches are in, but
still get the error for zipping a file
On Wednesday 22 July 2009, Bob Woodside wrote:
Try this. Edit the file zip.c. At line 1219 you'll see
# if 0
Change that to
# if 1
and rebuild zip. Then run zip -v and let me know what zip reports.
Thanks for your assistance, done the above I get the following :
Copyright (c) 1990-2009
On the topic of bzip2 (as alternative to UNZIP MVS/cmsmvs version):
==
On Friday 17 July 2009, Bob Woodside wrote:
Vikesh --
Would a version of bzip2 help you out for the time being? I had just
done a z/OS USS port of the latest
On Tuesday 21 July 2009, Vikesh Bhoola wrote:
On the topic of bzip2 (as alternative to UNZIP MVS/cmsmvs version):
==
On Friday 17 July 2009, Bob Woodside wrote:
Vikesh --
Would a version of bzip2 help you out for the time
On Tuesday 21 July 2009, Vikesh Bhoola wrote:
I don't require the MVS unzip (cmsmvs version) as urgently as I
required the zip function.
Good, because I haven't had much time to look at this lately. :-(
For now your USS unzip patch works well ( fast as well) with Kirk's
CoZBATCH
On Monday 20 July 2009, Vikesh Bhoola wrote:
Bob,
ZIP was run this weekend against some large files, using the cmsmvs
version ZIP module.
For zipping files over 7GB, I got the following error:
See my other reply - 7GB makes no sense to me.
zip warning: Entry too
On Tuesday 21 July 2009, Bob Woodside wrote:
compression:about 2.5 times slower than zip
decompression:about the same as unzip
That could explain things as I used both -1 (fast compression) for
Infozip for bzip2 which gave me a 4 to 1 difference which is very
notable. Also bzip2
On Tuesday 21 July 2009, Bob Woodside wrote:
I don't understand why there would be a boundary condition at 7GB.
4GB, yes, but not 7GB. Have you tried zipping a file that is just a
little larger than 4 GB?
Sorry about that - Yes, you are right, problem is the 4GB boundary. I
had to create
On Monday 20 July 2009, Vikesh Bhoola wrote:
Bob,
ZIP was run this weekend against some large files, using the cmsmvs
version ZIP module.
[snip]
Now, I'm not sure if the apply of the patches in the diff file was
correct as you mentioned this issue was resolved. Also I had made the
On Tuesday 21 July 2009, Vikesh Bhoola wrote:
On Tuesday 21 July 2009, Bob Woodside wrote:
I don't understand why there would be a boundary condition at
7GB. 4GB, yes, but not 7GB. Have you tried zipping a file that is
just a little larger than 4 GB?
Sorry about that - Yes, you are
On Tuesday 21 July 2009, Bob Woodside wrote:
and extracted zip31-try04.zip...
s/zip31-try04.zip/zip31-try04.diff/g
...but you knew that. :-)
Cheers,
Bob
--
Bob Woodside
Woodsway Consulting, Inc.
http://www.woodsway.com
Bob,
ZIP was run this weekend against some large files, using the cmsmvs
version ZIP module.
For zipping files over 7GB, I got the following error:
zip warning: Entry too big:HLQ.Q2.Q125.DN2008Q5
zip error: Entry too big to split, read, or write (Poor compression
On Friday 17 July 2009, Chase, John wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Bob Woodside
[ snip ]
The old version of bzip2 that used to be available from IBM has
been withdrawn; I don't know what version it was or whether it
supported
Bob, thanks for confirmation regarding the MVS (cmsmvs) build of unzip.
I did see the same error when executing the MVS version in USS, but was
wondering if it perhaps was the syntax.
I managed to compiled the unix version which works well
Just a change in the README.zOS:
gmake -f unix/Makefile
The error you are getting would indicate that there is no output on
stdout pipe from unzip. As you suggest, it looks like unzip from
stdin (using -) doesn't work. You might try this as an equivalent
alternative for reading from stdin:
fromdsn -b //DD:IN |
unzip -p /dev/fd0 |
todsn -s
Kirk, thanks for your response.
I tried
fromdsn -b //DD:IN |
unzip -p /dev/fd0 |
todsn -s ISO8859-1 -t IBM-1047 //DD:OUT
and get the following :
CoZBatchÝN¨: Copyright (C) 2005-2009 Dovetailed Technologies LLC. All rights res
CoZBatchÝN¨: version 1.3.0 2009-06-11
Looks like unzip doesn't like your input data. I'll bet that if you
copy it to HFS it will also fail.
What RECFM is the dataset? If it is RECFM=F*, maybe it has extra
bytes in the last record, in which case unzip probably won't like it.
On Fri, Jul 17, 2009 at 10:18 AM, Vikesh
File is
Record format . . . : U
Record length . . . : 0
Block size . . . . : 27920
Copied the file to HFS and unzipped it :
userid:/tmp: unzip -l Report8.ZIP
Archive: Report8.ZIP
Length DateTimeName
-
On Friday 17 July 2009, Kirk Wolf wrote:
Looks like unzip doesn't like your input data. I'll bet that if you
copy it to HFS it will also fail.
Kirk --
Yes, it will. The problem is that my current patch is very badly
borken [sic]. :-(.
What RECFM is the dataset? If it is RECFM=F*,
Why not use the jar command in z/UNIX? It is basically a zip/unzip type
program. That is, it will unzip a .zip file and will create a .zip file as well
as a .jar file. Actually, a .jar file __is__ a .zip file. Just with special
files inside it such as the manifest et al.
And I am fairly sure
On Fri, 17 Jul 2009 12:01:53 -0500, McKown, John jmck...@healthmarkets.com
wrote:
Why not use the jar command in z/UNIX? It is basically a zip/unzip type
program. That is, it will unzip a .zip file and will create a .zip file as
well as a .jar file. Actually, a .jar file __is__ a .zip file. Just
On Friday 17 July 2009, McKown, John wrote:
Why not use the jar command in z/UNIX? It is basically a zip/unzip
type program. That is, it will unzip a .zip file and will create a
.zip file as well as a .jar file. Actually, a .jar file __is__ a .zip
file. Just with special files inside it such
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Bob Woodside
Sent: Friday, July 17, 2009 1:08 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: INFOZIP 2Gb
On Friday 17 July 2009, McKown, John wrote:
Why not use the jar command in z/UNIX
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Bob Woodside
[ snip ]
The old version of bzip2 that used to be available from IBM has
been
withdrawn; I don't know what version it was or whether it supported
large files. There is now a supported version
On Friday 17 July 2009, McKown, John wrote:
-Original Message-
The question is whether jar can support the Zip64 file
format, and
hence can support archives that can 1) be larger than 4 GB, and 2)
contain individual files that are larger than 4 GB.
As far as I know,
I agree. bzip2 or gzip seem like much better choices than zip.
AFAIK, zip files have a directory at the end of the archive with a
pointer to the end at the very beginning. This might explain why
unzip is failing with pipes or special files.
On Fri, Jul 17, 2009 at 1:52 PM, Chase,
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Kirk Wolf
Sent: Friday, July 17, 2009 2:03 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: INFOZIP 2Gb
I agree. bzip2 or gzip seem like much better choices than zip.
AFAIK, zip files have
On Friday 17 July 2009, Kirk Wolf wrote:
I agree. bzip2 or gzip seem like much better choices than zip.
AFAIK, zip files have a directory at the end of the archive with a
pointer to the end at the very beginning. This might explain why
unzip is failing with pipes or special files.
Bob,
Thanks, I've successfully managed to install UNZIP (cmsmvs version) made
all the changes according to the provided diff file using gmake.
However, cannot test this as I don't seem to have the correct UNZIP JCL
syntax.
Does anyone perhaps have a working UNZIP JCL or even one that writes to
On Wednesday 15 July 2009, Vikesh Bhoola wrote:
Bob,
Thanks, I've successfully managed to install UNZIP (cmsmvs version)
made all the changes according to the provided diff file using gmake.
However, cannot test this as I don't seem to have the correct UNZIP
JCL syntax.
It's not the JCL
Thank you Bob for this.
I will test this out today let you know if it works for me.
Thanks again,
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
Bob,
I've made all the changes and the compiles goes through with no issues
using gmake.
The compile loops for some reason using make -f mvs.mki (but than its
documented to use gmake) ;)
Ran some tests on files 2GB and it worked wonderfully. Even got good
performance for the zip - for me, equal
On Monday 13 July 2009, Vikesh Bhoola wrote:
Bob,
I've made all the changes and the compiles goes through with no
issues using gmake.
The compile loops for some reason using make -f mvs.mki (but than
its documented to use gmake) ;)
Yes, I think the part of Lutz' patch that I left out was
Bob, just replied to your update on the Info-ZIP forum.
If you would like, I can send you the diff for my working version,
which has Lutz' code mixed in with mine. You should be able to use it to
run the MVS version of zip. Let me know if you would like me to do this.
Yes, I would be most
On Friday 10 July 2009, Vikesh Bhoola wrote:
Bob, just replied to your update on the Info-ZIP forum.
If you would like, I can send you the diff for my working version,
which has Lutz' code mixed in with mine. You should be able to use it
to run the MVS version of zip. Let me know if you
On Friday 10 July 2009, Vikesh Bhoola wrote:
Bob, just replied to your update on the Info-ZIP forum.
If you would like, I can send you the diff for my working version,
which has Lutz' code mixed in with mine. You should be able to use it
to run the MVS version of zip. Let me know if you
On Monday 29 June 2009, Vikesh Bhoola wrote:
On Friday 26 June 2009, Bob Woodside wrote:
By the way, Vikesh, did you have to apply the patches against
zip 3.1b that Lutz posted to the Info-ZIP forum to get the dots
stuff to work?
Yes, I did. Lutz's solution works 100% to get the dots
On Friday 26 June 2009, Bob Woodside wrote:
By the way, Vikesh, did you have to apply the patches against zip
3.1b that Lutz posted to the Info-ZIP forum to get the dots stuff to
work?
Yes, I did. Lutz's solution works 100% to get the dots to work - Bob,
thanks for the pointer on that
On Thursday 25 June 2009, Bob Woodside wrote:
Nope, not quite ready. When I tried to add a large file to an archive,
I got this error message:
It appears getting the cmsmvs version LARGE_FILES is proving to be more
challenging than I've anticipated.
This is a limitation of zip - no
On Friday 26 June 2009, Vikesh Bhoola wrote:
It appears getting the cmsmvs version LARGE_FILES is proving to be
more challenging than I've anticipated.
Or I. I managed to run several tests of both versions last night,
and I found that the cmsmvs version would run successfully if I added
On Friday 26 June 2009, Vikesh Bhoola wrote:
Yes, I do have a batch JCL for the cmsmvs zip set up :
//INFOZIP EXEC PGM=ZIP,
// PARM='/-avl -1 -MV=dots DD:OUT ''INPUT.DATASET.NAME'''
By the way, Vikesh, did you have to apply the patches against zip
3.1b that Lutz posted to the Info-ZIP
On Wednesday 24 June 2009, Bob Woodside wrote:
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.
Nope, not quite ready. When I tried to add a large file to an
archive, I got this error message:
zip error: Entry too
Bob,
We could really use you as a contributor in http://oss4zos.org
Let me know if you would like an id so you can post (We don't have an
open registration process since wiki-spammers nailed us).
Here's a page that should be updated with your very nice Info-Zip work:
Kirk, thanks for info on Co:Z.
Its not that I hate OMVS, it was just additional space was required as
USS Info-zip couldn't read from MVS datasets.
This solution works for me
- can be used to read MVS datasets
- can be used to write to MVS datasets as well
- retains trailing spaces
- uses
Vikesh,
I don't see a way to avoid the - file created by zip: this is what it
uses as a file name when it uses stdin as input. Better to use gzip or
bzip2 for single files anyway.
I didn't mean to imply that you hated OMVS - this was a little joke
referring to recent threads on IBM-MAIN :-)
On Wednesday 24 June 2009, Kirk Wolf wrote:
Bob,
We could really use you as a contributor in http://oss4zos.org
Let me know if you would like an id so you can post (We don't
have an open registration process since wiki-spammers nailed us).
Yes, please send me whatever info I need,
I'm not an nedit user, but why don't you port the nedit server part to
z/OS, which should be much simpler and sounds pretty cool to me:
http://www.nedit.org/help/server.php#Client/Server_Mode
Then you could run the client on your workstation, which makes more sense to
me than running an X-based
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
On Wed, 2009-06-24 at 15:11 -0400, Bob Woodside wrote:
(When I can edit my source files directly on
z/OS with Nedit, I'll be a happy camper!)
I thought Nedit had quietly died a few years back. Nice editor.
Shane ...
--
For
On Wednesday 24 June 2009, Kirk Wolf wrote:
I'm not an nedit user, but why don't you port the nedit server part
to z/OS, which should be much simpler and sounds pretty cool to me:
Actually, I always use it in client-server mode, with the client
(nc) and server (nedit -server) running on
On Wednesday 24 June 2009, Shane wrote:
On Wed, 2009-06-24 at 15:11 -0400, Bob Woodside wrote:
(When I can edit my source files directly on
z/OS with Nedit, I'll be a happy camper!)
I thought Nedit had quietly died a few years back. Nice editor.
It's still alive on my machines, but
/u/userid/zip31b: zip -av -1 /tmp/BIG_FILE.zip //'userid.BIG.FILE'
Sadly, it's all a dead end, because it looks like zip can't handle
this kind of filename:
It looks like all that dots stuff in the filename handling code
needs another wrinkle added for full MVS + USS support.
Bob, thanks
There are commands (todsn and fromdsn) in our free Co:Z Toolkit for
converting MVS datasets to/from Unix pipes, which you can redirect into
infozip / gzip / bzip2. They offer all sorts of options like line
termination rules, codepage conversion, padding/truncation rules, etc.
See:
On Tuesday 23 June 2009, Vikesh Bhoola wrote:
See comments on the Info-ZIP forum where I offer some SWAG
theorizing about how I must have broken the name display -- and
somebody (EG, I
think) explains the use of the 3 name fields.
Thanks, I seen the comments made on the forum and
On Tuesday 23 June 2009, Bob Woodside wrote:
Ah, but that I was just playing around with the code to see what
would happen. Based on EG's comments, I've modified the function
local_to_display_string in fileio.c to play nicer with EBCDIC - at
least it seems nicer to me. That's the function
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Bob Woodside
Sent: Friday, June 19, 2009 7:09 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: INFOZIP 2Gb
On Friday 19 June 2009, Vikesh Bhoola wrote:
You might try double quotes around
On Saturday 20 June 2009, McKown, John wrote:
You could also enclose in marks.
/u/userid/zip31b: zip -av -1 /tmp/BIG_FILE.zip //'userid.BIG.FILE'
or
//'userid.BIG.PDS(MEMBER)'
Sadly, it's all a dead end, because it looks like zip can't handle
this kind of filename:
On Sat, 20 Jun 2009, McKown, John wrote:
You could also enclose in marks.
/u/userid/zip31b: zip -av -1 /tmp/BIG_FILE.zip //'userid.BIG.FILE'
or
//'userid.BIG.PDS(MEMBER)'
I forgot to mention that the above will have problems if the DSN or member
has a $ in it as the shell will
I finally managed to get enough space for a ZFS to test the zip of a file 2Gb
:
I successfully zipped a 4.7GB file (in USS).
Fri Jun 19 13:40:22 GMT 2009
/u/userid/zip31b: zip -av -1 /tmp/BIG_FILE.zip /tmp/big_file.txt
Translating to
Vikesh Bhoola wrote:
I finally managed to get enough space for a ZFS to test the zip of a file 2Gb
:
I successfully zipped a 4.7GB file (in USS).
Fri Jun 19 13:40:22 GMT 2009
/u/userid/zip31b: zip -av -1 /tmp/BIG_FILE.zip /tmp/big_file.txt
You might try double quotes around the file name construct,
with single quotes embedded to prevent prefixing; so:
/u/userid/zip31b: zip -av -1 /tmp/BIG_FILE.zip //'userid.BIG.FILE'
Thanks, I tried that, still get :
/u/userid/zip31b: zip -av -1 /tmp/BIG_FILE.zip //'userid.BIG.FILE'
On Friday 19 June 2009, Vikesh Bhoola wrote:
You might try double quotes around the file name construct,
with single quotes embedded to prevent prefixing; so:
/u/userid/zip31b: zip -av -1 /tmp/BIG_FILE.zip
//'userid.BIG.FILE'
This should do the trick:
/u/userid/zip31b: zip -av -1
On Tuesday 16 June 2009, Kirk Wolf wrote:
Try it - it seems to give you an archive with no files in it. After
all, what would the file name in the zip directory be?
Well, yes and no. Let's just say no named files. Unzip shows
something like this:
unzip -l ../backup.zip
Archive:
On Friday 19 June 2009, Vikesh Bhoola wrote:
I finally managed to get enough space for a ZFS to test the zip of a
file 2Gb : I successfully zipped a 4.7GB file (in USS).
Great! It looks like you're getting the same results I did.
Translating to ASCII...
adding: È_ø¬¿ñèë¡ÈÌÈ
See
Try it - it seems to give you an archive with no files in it. After
all, what would the file name in the zip directory be?
On Mon, Jun 15, 2009 at 6:30 PM, Bob Woodsideibm...@woodsway.com wrote:
On Monday 15 June 2009, Kirk Wolf wrote:
I could be wrong, but I don't believe that zip allows
Bob, thanks for the gmake link and the update - it sounds promising.
I've just downloaded gmake and going to install it.
Just want to confirm if gmake is required for the cmsmvs/mvs.mki ?
I've managed to piece together clues from you, Lutz, and sms,
Yes, I too found the info all scattered
On Monday 15 June 2009, Vikesh Bhoola wrote:
Bob, thanks for the gmake link and the update - it sounds promising.
I've just downloaded gmake and going to install it.
Just want to confirm if gmake is required for the cmsmvs/mvs.mki ?
I don't know if it is required for you.
Our make
Subject: Re: INFOZIP 2Gb
Vikesh --
Like I said, keep following the discussions on the Info-ZIP forums.
I've managed to piece together clues from you, Lutz, and sms, and got a
clean build from the cmsmvs/mvs.mki makefile that looks like it actually
works.
I just posted some initial info
I could be wrong, but I don't believe that zip allows input from stdin.
If info-zip uses fopen() to open files, then it might be possible to
read mvs datasets directly as input files.
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Sun, Jun 14, 2009 at 8:55 PM, Timothy
Bob, thanks for confirming.
I managed to compile zip under unix with LARGE_FILE_SUPPORT using gmake only:
Compiled with IBM C version 410.9.0 for Unix (Unknown) on Jun 15 2009.
Zip special compilation
On Monday 15 June 2009, Kirk Wolf wrote:
I could be wrong, but I don't believe that zip allows input from
stdin. If info-zip uses fopen() to open files, then it might be
possible to read mvs datasets directly as input files.
I've never tried it, but here's a quote from the zip man page:
That's a good point, though: zip and unzip could read/write MVS-style
datasets directly (using that // syntax), just like cp and mv do, if they
use the appropriate interfaces.
- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Based in Tokyo, Serving IBM Japan / Asia-Pacific
Vikesh Bhoola writes:
This is a issue, as we really don't have the
additional space to copy the 14GB MVS file to
USS just to zip it.
Is it possible to string together a couple z/OS UNIX commands and use UNIX
pipes?
I don't think this works exactly, but something roughly like this:
cp
Vikesh --
Like I said, keep following the discussions on the Info-ZIP forums.
I've managed to piece together clues from you, Lutz, and sms, and got a
clean build from the cmsmvs/mvs.mki makefile that looks like it
actually works.
I just posted some initial info on the Info-ZIP
What I have working is the version in the unix directory, built under
USS as a Unix executable.
Thanks Bob, it is disappointing, but at least that explains the
differences I was seeing.
We don't have gmake installed, and so with make -f /unix/Makefile
Configure does not compile successfully
On Friday 12 June 2009, Vikesh Bhoola wrote:
What I have working is the version in the unix directory, built
under USS as a Unix executable.
Thanks Bob, it is disappointing, but at least that explains the
differences I was seeing.
We don't have gmake installed, and so with make -f
Thank you Bob.
[snip -- this thread was getting too long for my little mind]
I agree, but as long as progress is being made.
Just to keep others informed, I've made the changes to the code as
Info-Zip forum. This allowed me to compile the zip with
-DLARGE_FILE_SUPPORT with no errors.
On Thursday 11 June 2009, Vikesh Bhoola wrote:
Thank you Bob.
[ snip ]
So, I'd be interested in the code once you manage to get this
working. Comparing the difference between your CFLAGS mine, I see
mine : -D_OPEN_SYS -DMVS -DREENTRANT -DLARGE_FILE_SUPPORT
Yours :
-DOS390 -DEBCDIC
On Wednesday 10 June 2009, Edward Jaffe wrote:
Bob Woodside wrote:
I'll look at the configure script later to see what needs to be
done there. Then I'll do the same with unzip 6.0. And the code
should probably be patched to recognize a ZOS define as well as
OS390 -- time to move the
have also posted this to Info-Zip forum.
Your assistance is appreciated.
Kind Regards,
Vikesh Bhoola
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Bob Woodside
Sent: 09 June 2009 07:21 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: INFOZIP
Regards,
Vikesh Bhoola
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Bob Woodside Sent: 09 June 2009 07:21 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: INFOZIP 2Gb
On Tuesday 09 June 2009, Vikesh Bhoola wrote:
Thanks for the links
On Wednesday 10 June 2009, Vikesh Bhoola wrote:
Bob, thanks for the detailed information, it is very much
appreciated.
[snip -- this thread was getting too long for my little mind]
OK, I did a quick 'n dirty test with a hacked Makefile and a
hand-patched flags file, and built zip
Bob Woodside wrote:
I'll look at the configure script later to see what needs to be done
there. Then I'll do the same with unzip 6.0. And the code should
probably be patched to recognize a ZOS define as well as OS390 --
time to move the mainframe support into the 21st century.
I'll
As zip and unzip develop, when ready I can update http://www.oss4zos.org
with the new version information.
Also, it would be nice to have a downloadable binary distribution when
everything settles. It may be possible to host the binaries at oss4zos.org
if there's not a better option forthcoming.
On Tuesday 09 June 2009, Vikesh Bhoola wrote:
Thanks for the links.
While waiting for our order on bzip2,
I tried downloading INFO-Zip
3.1b (Beta version) - as Zip 3.0 does not compile. I finally managed
to compile INFO-ZIP Zip 3.1b to create a ZIP module.
[snip]
How do I
You'll probably also want to use the best hardware optimization compile
options (ARCH and TUNE) for your particular machine.
ARCH(5) with TUNE(7) or TUNE(8) is very safe if you're not sure what to do.
Binaries generated using those options will run all the way back on
z900/z800 machines, but they
Sent: 03 June 2009 06:26 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: INFOZIP 2Gb
You can use the jar command -- provided with the no charge IBM SDK for
z/OS, Java Technology Edition -- to create Zip files. For example:?
jar cf myarchive.zip file1.seq file2.seq file3.seq
I think this works:
jar
On Wednesday 03 June 2009, Vikesh Bhoola wrote:
We would have liked INFOZIP to work for files 2Gb as it appears to
be quicker than the jar method.
I guess the best free working solution is the jar function. It takes
a bit longer, but it does the job.
Our windows zip product successfully
Or you could head down the path of using a vendor zip. I did a quick
check.. PKZIP supports compression of files over 9 exebytes in size. I am
sure that there are others as well.
Rob Schramm
Sirius Computer Solutions
--
For
: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Vikesh Bhoola
Sent: Wednesday, June 03, 2009 6:55 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: INFOZIP 2Gb
Thanks to all that responded.
It appears that no one has experienced the same or had tried zipping
data larger than 2Gb
PKZIP supports compression of files over 9 exebytes in size.
We went from PKZIP to ZIP/390, because of cost and support issues.
ZIP/390 comes from DATA21 (www.data21.com).
Both companies support lines are only open 9-5, M-F (local time).
DATA21 is in California, and PKZIP is in Phili (I
) Ted MacNEIL
To: supp...@data21.com
Sent: Jun 3, 2009 13:17
Subject: RE: INFOZIP 2Gb
FYI We now support adding a file to an existing archive.
David L. Kennedy
Data21, Inc.
Phone: (310) 792-1771 x217
Fax: (310) 792-1778
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm
About jar's CPU, is there any zAAP eligibility when running jar?
There's also gzip and bzip2. bzip2 is also supported by IBM as part of the
IBM Ported Tools (no charge). Here's some more information:
http://www.ibm.com/servers/eserver/zseries/zos/unix/ported/suptlk/index.html
I also found this
1 - 100 of 104 matches
Mail list logo
