ZIP & UNZIP [1.9 (Aug 26th 1992)]

[Niall76]

Hi,

I have bunch of files I ZIP every day, but I always have an issue with this one file. I believe it is a fixed length, sequential file. For some reason the file allocation changes on it with ZIP (FROM 280/280 blocks TO 128/140 blocks), even when the -0 Store only option is used. This causes problem with the program that reads this file.

Does anyone know a way around this? Below is how I use ZIP and UNZIP commands

PROMPT> DIR FILEA.FIL /FULL

Directory GXPROJ:[TSK]

FILEA.FIL;1 File ID: (5607,24,0)
Size: 280/280 Owner: [GOLS,CONSOLE]
Created: 28-MAR-2011 06:39:31.31
Revised: 28-MAR-2011 06:39:31.34 (1)
Expires:
Backup:
Effective:
Recording:
File organization: Indexed, Prolog: 3, Using 1 key
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 280, Extend: 0, Maximum bucket size: 5, Global buffer count: 0, No version limit
Record format: Variable length, maximum 2044 bytes, longest 0 bytes
Record attributes: None
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Client attributes: None

Total of 1 file, 280/280 blocks.
PROMPT>
PROMPT> ZIP "-V0" FILEA.ZIP FILEA.FIL
adding filea.fil (stored 0%)
PROMPT>
PROMPT> REN/LO FILEA.FIL *.GOOD
%RENAME-I-RENAMED, GXPROJ:[TSK]FILEA.FIL;1 renamed to GXPROJ:[TSK]FILEA.GOOD;1
PROMPT> UNZIP "-V" FILEA.ZIP FILEA.FIL
Extracting: filea.fil
PROMPT> DIR FILEA.FIL; /FULL

Directory GXPROJ:[TSK]

FILEA.FIL;1 File ID: (5610,24,0)
Size: 128/140 Owner: [GOLS,CONSOLE]
Created: 28-MAR-2011 06:39:31.31
Revised: 28-MAR-2011 06:39:31.34 (1)
Expires:
Backup:
Effective:
Recording:
File organization: Indexed, Prolog: 3, Using 1 key
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 140, Extend: 0, Maximum bucket size: 5, Global buffer count: 0, No version limit
Record format: Variable length, maximum 2044 bytes, longest 0 bytes
Record attributes: None
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Client attributes: None

Total of 1 file, 128/140 blocks.

Thanks,
Niall

[Hein van den Heuvel]

Well, the file itself is an indexed file and the main attributes are correctly saved and restored. That's all we can see from here.
You may want to ANALYZE/RMS/FDL the old and new file. Maybe anylyze hints to the root cause or post the results here in a .TXT attachement.

You want and need to upgrade ZIP to a slightly less antiquated version, why use not the most recent version availalable for your platform.

Standard, but always important, questions:

1) Did it ever work
2) What is the exact error message
3) Which Platform/OS version

hth,
Hein

[Niall76]

Hi Hein,

Thanks for your quick response.

FDL of before and after are attached (windows Zip). There is certainly an issue there in the output of the two files.

Answers to your questions:
1. Did it ever work: probably not. This is a new file added to daily backup. Other files are not of this format type.
2. What is the exact error message: no error message at all. Appears to UNZIPâ s fine and programs runs on this file, just it takes approx 50 times longer to run on the unzipped file!
3. Which Platform/OS version: OpenVMS 7.3

I don't mind installing a newer version of ZIP, is it free and where can you download it?

Many Thanks,
Niall

[Hoff]

Those are even older than the fossil versions of zip and unzip HP tends to use.

Time to upgrade your tools.

Zip and unzip that far back were bug farms.

Newer versions are here:

http://vms.process.com/fileserv-software.html

The versions at this site are classically built against V5.5-ish VMS releases, so they should run most everywhere.

You'll want at least zip V3.0 and unzip V6.0 here.

[Steven Schweda]

> ZIP & UNZIP [1.9 (Aug 26th 1992)]

1992? Seriously? Yikes. I didn't get
involved in Info-ZIP development until
September 2004 (complaining about related
problems with "Zip 2.3 (November 29th
1999)"), so 1992 is a little before my time,
but ...

Note that Zip and UnZip don't use the same
version numbering scheme, so, as usual,
actual output from, say:
zip -v
unzip -v
would be more helpful than your vague
description or interpretation of what you
have.

> File attributes: Allocation: 280, [...]

> File attributes: Allocation: 140, [...]

Note that, like many programs, Zip and UnZip
(in recent years, at least) tend to believe
the End-of-File info (efblk, ffbyte), and
ignore the allocated storage beyond the EOF.

Does BACKUP do any better?

Beginning around Zip version 2.32 ("(June
19th 2006)"), Zip has offered a "-VV" option,
which causes it to store every allocated
block (hiblk), which may include data beyond
EOF (efblk, ffbyte). So, if someone's lying
about EOF, you can probably still get what
you want.

Interestingly, most, if not all, of the
EOF-related changes were on the Zip side.
UnZip tended to do what it was told, so it
needed only to be told the right things (by
Zip). But there was a change to the way
VMS-specific file attributes were stored at
some long-ago time, so a very old UnZip might
have some trouble dealing with an archive
created by a (normally-built) modern Zip
program. (Here, "modern" means that "zip -v"
mentions "VMS_PK_EXTRA" in its "Zip special
compilation options" report section. I don't
know when that became the default scheme.
The older scheme was "VMS_IM_EXTRA", which
UnZip should still handle properly, and which
Zip can still be built to use, but it's not
well tested these days, and I wouldn't advise
using it.)

> You want and need to upgrade ZIP to a
> slightly less antiquated version, why use
> not the most recent version availalable for
> your platform.

I'm with him.

> 3) Which Platform/OS version

Again, actual "-v" reports should have shown
the interesting info.

The latest released versions, Zip 3.0 and
UnZip 6.0) have been built on systems so old
as VMS V5.4 (with VAX C V3.1-051), so I can
think of no really good reason to stick with
(known-buggy, reduced-feature) antiques. But
I'm always open to a good counter-argument.


1992. The fun never ends around here.

[Steven Schweda]

> Newer versions are here:
> [...]

They're even available direct from the home
world:

http://www.info-zip.org/
ftp://ftp.info-zip.org/pub/infozip/vms/

where there should be enough stuff to get
anyone started.

Also on sourceforge.net. (Also not invisible
to the major Web search engines.)

And, if you have a C compiler (and DCL), then
it should be possible (and practical) to
build everything from a source kit, which is
always fun and educational.

[Hein van den Heuvel]

>>> FDL of before and after are attached (windows Zip). There is certainly an issue there in the output of the two files.

The 'after' file is seriously mangled. No hope.

First choice... upgrade ZIP.

Second choice:
This is a tiny indexed file.
Instead of transferring the indexed file, convert it to sequential:
$ CONVER/FDL=NL:/stat before.idx before.seq
Provide an FDL file :
$ ANAL/RMS/FDL=before
Zip up both sequential file and FDL file
After un-zip re-create the indexed file:
$ CONV/STAT/FAST/FDL=before before.seq after.idx

Third choice:
Stick the Indexed file into backup saveset. Zip that up, unzip and restore.

Hein

[Niall76]

Hi guys,

I know it is a shameful version of Zip, So I'll go with the upgrade option as you all point towards.

My issue is now, how do i get the new Zip file to unzip on VMS with my old version. I have unzipped in windows, and tried to ftp accross, but the build_zip.com file has lost all of its formatting, god only knows what the other files are like.

I gues the PRODUCT INSTALL option is not available for Zip?

Thanks,
Niall

[Steven Schweda]

> I gues the PRODUCT INSTALL option is not
> available for Zip?

It is, if you produce the kit.

> My issue is now,

Is that anything like a _problem_?

> how do i get the new Zip file to unzip on
> VMS with my old version.

Did you try it? What did you try? What
happened?

ftp://ftp.info-zip.org/pub/infozip/vms/
ftp://ftp.info-zip.org/pub/infozip/vms/readme

Did your old UnZip program (whose version is
still a secret?) have trouble unpacking a kit
on the VMS system?

> [...]
> actual output from, say:
> zip -v
> unzip -v
> would be more helpful than your vague
> description or interpretation of what you
> have.

I could be talking to a wall and get just as
much useful info back.

> I have unzipped in windows,

Probably not the best idea. Unpacking the
kits on a/the VMS system should cause fewer
problems than trying to do that elsewhere.

> and tried to ftp accross,

That vague description is a few details short
of useful, too.

> but the build_zip.com file has lost all of
> its formatting, god only knows what the
> other files are like.

If you can use _binary_ FTP at all times
(preferably avoiding Windows involvement, but
that may not be crucial), then you should be
able to try your old UnZip program on the new
Zip and UnZip kits. If that causes trouble,
then you could try to use one of those loose
"unzip552*.exe" programs instead of your old
(secret-version) UnZip program.

[Niall76]

Hi,
Surprise surprise, UNZIP is from the same time as the ZIP exe.

UnZip: Zipfile Extract v5.0 of 21 August 1992; (c) 1989 S.H.Smith and others
Versions 3.0 and later by Info-ZIP. Bug reports ONLY to zip-bugs@cs.ucla.edu

I ftp zip.zip from Windows (no other choice) to my aplha. UNZIP did run, but the com files are all garabge inside.

@LINK
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\ \
%RMS-W-RTB, 943 byte record too large for user's buffer

I have found a more up to date version of Zip on a VMS 8.3 system (zip 2.32 & unzip 5.52). I have tested Zipping and Unzipping the file with the issue and it works fine on this version. I can't find any install directorys on this machine only the executables. I guess copying these across is not an option.
Thanks,
Niall