Re: Any ZLIB experts out there?

On Mon, 2006-02-13 at 15:51 -0800, James H H Lampert wrote:
> Anybody out there who's familiar with the OS/400 port of 
> ZLIB?
> 
Yes.  I ported it quite some time ago (1998?, 0.15) to an iSeries native
C implementation.  I'm not sure if you are using something similar, or
perhaps a PASE version?

In any case,  I had to make a few changes to get it to work on the
AS/400.  I've got source copies, but no longer have the objects as I
(not three days ago!) wiped out a bunch of objects and libraries in
order to 'clean things up'.

I should have known that since I haven't used it in about eight years,
if I erase it, I'll want it back in three days time.  Sigh.

> We're developing a tool that is essentially a front-end 
> for the MINIZIP utility supplied with the OS/400 port of 
> ZLIB. Our tool basically either takes a single IFS 
> directory and creates a ZIP archive with the contents of 
> that directory, or steps through an entire IFS directory, 
> performing the aforementioned conversion with every 
> subdirectory in that directory. (There are a few added 
> wrinkles, but they're not relevant to the problem at 
> hand.)
> 
> At any rate, a customer tried this (with a test copy of 
> the directory tree in question), and got a bunch of weird 
> joblog messages.
> 
> They started with (some names changed)

I ran into a number of issues with this.  I suppose the original
developers would by default expect that the zip catalog as well as the
contained files would always be in ASCII.

In the case of iSeries, if you run the ported version of minizip to
create a new zipfile, it will be in (of course) EBCDIC.  Including the
zip catalog.

Trying to open such a file on a PC would result in pure garbage.  The
zip catalog is EBCDIC, and of course all the contained files are EBCDIC.

Now, in the case of opening a minizip file that you find on your
iSeries, should one 
A) automatically assume that the catalog is in EBCDIC  
B) automatically assume that the catalog is in ASCII  
C) Try to guess

I didn't like option C, and I know that A and B are both wrong.  I
suppose the problem is that the zip header doesn't (as far as I know)
keep a code page entry for the catalog or the contained files.

I sort of gave up on it at that point.  An iseries version could be good
at doing iSeries files, but not work at all with PC files, and vice
versa.  Or one might be able to make a nonstandard implementation on
iSeries that specially marks EBCDIC files.

Perhaps this has been fixed since 1998, I don't know.


> 
> error in opening /foo/bar/baz/EAL 806 - SCU 2004 Rev 2.xls 
> for reading
> After some completion messages, this was followed by
> 
> error opening /foo/bar/qux.zip
> 
> and
> 
> error in closing /foo/bar/qux.zip.
> 
> and
> 
> Program minizip completed with return code -102
> 
> and then over a thousand PAGES of
> 
> *NONE Information 02/13/06 14:57:04.239656 QP0ZCPA QSYS 
> *STMT QP0ZCPA QSYS *STMT
>   From module . . . . . . . . :   QP0ZUDBG
>   From procedure  . . . . . . :   Qp0zVLprintf
>   Statement . . . . . . . . . :   699
>   To module . . . . . . . . . :   QP0ZUDBG
>   To procedure  . . . . . . . :   Qp0zVLprintf
>   Statement . . . . . . . . . :   699
>   Message . . . . :   ERROR 3025 FOUND OPENING MESSAGE 
> CATALOG
> /QIBM/PRODDATA/OS400/SHELL/MRI2924/SHELL.CAT.
I checked on one AS/400 we have here.  after the OS400 directory, there
is no 'SHELL' subdirectory.  Curious.

> 
> Can anybody explain what's going on here? This isn't 
> making a whole lot of sense.
> 
> --
> JHHL