we have tested ZIP31C and compared it with the results of ZIP232, which we used before (see attached file test_zipv31c_en.doc),
Josef

The results look more or less promising.

The character conversion changes were provided by other EBCDIC users, so that was all as expected.

If the recfmV check is needed in Zip 3.1, please post it here rather than in the attachment.

The -fz warning generally comes up when a file that is slightly less than 4 GB compresses to slightly more than 4 GB.  The -fz flag forces Zip to handle the entry as larger than 4 GB rather than guess it will still be under 4 GB when compressed.

> (see attached file test_zipv31c_en.doc),

   Some of us don't have Microsoft Word handy.  Plain (ASCII) text is
easier to handle (and more compact).

Quoted from sms

> (see attached file test_zipv31c_en.doc),

   Some of us don't have Microsoft Word handy.  Plain (ASCII) text is
easier to handle (and more compact).

Steven,
I install OpenOffice.org (OO.o) on systems without Word to be able to read and update .doc files. It's big, but free and available for many platforms.

Sometimes it does a better job of handling old Word releases than Word.
Al

> I install OpenOffice.org (OO.o) on systems without Word [...]

   Ever try that on a VMS system?  That's my full-time computer.  I
could probably fire up a Mac and read it there, but my point is that
plain text should be left as plain text, for the benefit of all.

Quoted from fits

we have tested ZIP31C and compared it with the results of ZIP232, which we used before (see attached file test_zipv31c_en.doc),
Josef

have also attached the compare file in html format,
josef

>>If the recfmV check is needed in Zip 3.1, please post it here rather than in the attachment.
the recfmV check is also posted on reply 4 in link: http://www.info-zip.org/board/board.pl?m-1272445230/  ,
Josef

Sorry, I guess my question is if you want me to make this change.  It sounds that you do.

Below is the change I'm referring to.

RECFM=VB/V and Option -B not supported

In the origin CMSMVS.C source code we have put after line 321 following check  
  command: 
  
if (fdata.__recfmV & bflag) {
  printf("FLDATA: RECFM=VB/V and Option -B not supported");
  printf("file : %s not processed!",z->name);                
  z->name = " ";                                               
  return
  ZE_NONE;
}    

If there's more changes, please point me to them.

Ed,
If the zip file is being encoded with an EBCDIC->ASCII translation or you don't care about the record boundaries because the user has bytestream data being mapped to a non-POSIX file, the check prevents legitimate zip processing.   There is no way to tell the latter case.

This is why the real longer-term fix that has been discussed is to finish the work to preserve the lengths of each text record is so they can be used to recreate those record boundaries when decoding into a non-POSIX MVS or VM/CMS file.  

Whether or not you put in this check now, it would need to be reverted once that new support is in place.
Al

Understand.  The question is if it provides benefit now.  If your changes are done before Zip 3.1 goes out, then you can revert this in your changes.  If your changes are not done in time, for example because of pressure to get some other changes released, then you would have to work the backward compatibility issues if there are any.  I was going to add this change, unless there is definite objection to it.