I64 8.2 Zip

[Lucinda_1]

Can you zip a .bck? I need to compress this file as much as possible.
I get the following:


VMSI64> copy unzip.exe sys$system:
VMSI64> copy zip.exe sys$system:
VMSI64> set def vmsi64$dka0:[cortex]
VMSI64> mcr zip systembackup.bck
zip warning: multiple disk information ignored
VMSI64$DKA0:[CORTEX]SYSTEMBACKUP.BCK;1: found a preamble of 2710322306 bytes

zip error: Nothing to do! (VMSI64$DKA0:[CORTEX]SYSTEMBACKUP.BCK;1)
VMSI64> dir *.zip
%DIRECT-W-NOFILES, no files found
VMSI64> dir system*

Directory VMSI64$DKA0:[CORTEX]

SYSTEMBACKUP.BCK;1 *******/******* 12-OCT-2005 15:11:07.89

Total of 1 file, 22071105/22071112 blocks.

[John Gillings]

Lucinda,

VMSI64> run zip

RUNning an image doesn't pass any paramters. You need to execute it as a "foreign command". There are several ways to do this. Here are the common ones:

1) Foreign command symbol

$ zip="$device:[directory]ZIP.EXE"
$ zip file

Note the leading dollar sign is required, as is the full filespec.

2) MCR command

$ MCR device:[directory]ZIP file

3) DCL$PATH

Define the logical name DCL$PATH to include the directory containing your foreign command image:

$ DEFINE DCL$PATH device:[directory1], dev:[dir], ...
$ ZIP file

[Lucinda_1]

Can you zip a .bck? I need to compress this file as much as possible.
I get the following:


VMSI64> copy unzip.exe sys$system:
VMSI64> copy zip.exe sys$system:
VMSI64> set def vmsi64$dka0:[cortex]
VMSI64> mcr zip systembackup.bck
zip warning: multiple disk information ignored
VMSI64$DKA0:[CORTEX]SYSTEMBACKUP.BCK;1
: found a preamble of 2710322306 bytes

zip error: Nothing to do! (VMSI64$DKA0:[CORTEX]SYSTEMBACKUP.BCK;1)
VMSI64>
; dir *.zip
%DIRECT-W-NOFILES, no files found
VMSI64> dir system*

Directory VMSI64$DKA0:[CORTEX]

SYSTEMBACKUP.BCK;
1 *******/******* 12-OCT-2005 15:11:07.89

Total of 1 file, 22071105/22071112 blocks.

[John Gillings]

Lucinda,

The syntax for ZIP is to give it the name of the ZIP file, then a list of file to add to the zip file. For VMS files, you should also specify "-V" (quotes essential) to make ZIP save the VMS file attributes

Try:

$ mcr zip "-V" myzip.zip systembackup.bck


This will zip systembackup.bck into a new ZIP file called myzip.zip

-V never works for me, but others claim it does. When you UNZIP the saveset, you may have to repair the attributes. I've attached the command procedure FIXSAVESET.COM as a text file.

[Arch_Muthiah]

hi,

We can zip .bck files using
$ zip "-V" systembackup.bck
while unzip, you should add -l option.

This "-V" option automatically saves VMS file attributes.

But as per Mr.John info, when you UNZIP, you may have to repair the attributes using his com procedures.

Note: But I remembered VMS zip file size limit is 2GB only, but your .bck file size is 2710322306 bytes.

Also if there are any DECNet
(node::"un pwd"disk:fn) files in your saveset, the zip may not work. The error "zip error: Nothing to do!" is for this only, the $status code may be 1 or 12.

If you really want to compress your valuable data, my suggesion would be, not follow this way. Because there will be recovery issues while restore. So better restore the save set now itself and zip it, then do the backup.

If your are going to store this in a magnetic tape, there also you can use "/density" to increase your data compression.

Archunan

[Steven Schweda]

The first place to look is normally:

http://www.info-zip.org/

Folow the links to the source kits, which
are normally available at:

http://ftp.info-zip.org/pub/infozip/src/
ftp://ftp.info-zip.org/pub/infozip/src/

Now that you have one working UnZip
executable, if you also have a C compiler, I
suggest fetching the kits for the current
versions, Zip 2.31 and UnZip 5.52. On VMS,
they can do I/O considerably faster than
older versions. There are some other fixes,
too, and with SET PROCESS /PARSE_STYLE =
EXTENDED, you can forget about quoting
upper-case options on the command line.
(Zip 2.3? Yuck-ptui!)

If you _don't_ have a C compiler, I suggest
the same things, but you might need to visit
one of the TestDrive systems to get the
stuff built. (Of course, while you're there
you could just steal mine, if you can find
the stuff.)

> Total of 1 file, 22071105/22071112 blocks.

Yikes. Too big. You need [Un]Zip with
large-file capability. Sadly, no released
versions have that. Luckily, some
unreleased (BETA) versions do. The normal
place to look for those is:

http://ftp.info-zip.org/pub/infozip/OLD/beta/

but the stuff you'll find there now is a bit
stale. I have some newer source (+ some
non-IA64 binary) kits on my server. If you
send some e-mail to sms antinode.org, I
can tell you what's there and where to find
it. (Or where to look on the IA64 TestDrive
system.)

As for any problems with "-V", I believe
that everything is delightful in the latest
released versions (and the latest betas),
but I'd be happy to look into any problems
which can be reproduced. (Of course, a
prompt fix for the TCPIP V5.4 e-mail
problem reported elsewhere might speed any
required [Un]Zip repairs for Mr. Gillings.)

[Steven Schweda]

> while unzip, you should add -l option.

Why "-l"? Around here (UnZip 5.52 of 28
February 2005):
-l list files (short format)

> But as per Mr.John info, when you UNZIP,
> you may have to repair the attributes
> using his com procedures.

Show me a situation where using Zip -V and
UnZip changes any file attributes.

> Also if there are any DECNet
> (node::"un pwd"disk:fn) files in your
> saveset, the zip may not work.

Show me how to get a name like that through
BACKUP. Then explain why it would matter
here.

Zip does have trouble accessing DECnet-remote
files, however. (Of course, so does BACKUP.)

By the way, (unreleased, BETA) Zip 3 and
UnZip 6 also do a better job with ODS5 file
systems (extended file names, case
preservation, and so on).

[Steven Schweda]

And, by the way, 22071105 blocks is about
11GB, not 2.7GB. (The old, small-file
program can't count that high.)

Even if you could use Zip 2.3 on a file that
size, I think that you'd find 2.31 would save
a _lot_ of time. Similarly, UnZip 5.52 for
expansion.

Of course, because of the size > 2GB problem,
you're pretty much forced to use Zip 3 and
UnZip 6, which also have the faster I/O,
which saves you from having to decide among
the older versions. (See? All the
complications actually made things simpler.)

As I recall, I didn't actually test things
past about 5GB, but what could go wrong?

[Arch_Muthiah]

Hi Steven,

Why are you so angry with me?. I saw your angry-answer to my other posting also. If any chance my posting, hurted you, I am extreamly sorry friend, and forgive this VMS fan.

I have faced lots of difficulties contacting and getting help from COMPAQ or HP support engineers (VMS), even after getting them in line, they will say I am not VMS guy, I will catch someone who knows VMS to help you. After few days they will call and reply and sometime they won't.

Now I am so much happy seeing and parting with my favourite OpenVMS friends group through this great ITRC forum. When I come to know this group in May 2004, I thought, "Oh! My GOD!, people are there in this world to clear our day to day doubts".

I have gathered lots of valuable info from our forum members for my day to day work. In the same way I am trying to contribute to this forum with my small knowledge along the our seniors.

Whenever I am free, I used to visit our forum, and try gather knowledge from the latest posting or if anyone in need of answer for their urgent work (I have usually posted questions for my urgent work only), I will try my best and quickly to answer with my minimum knowledge focusing to solve the questions. I won't see any thing else.

You have mentioned the "this guys always has bad answers".

If you read again my posting....

< We can zip .bck files using
$ zip "-V" systembackup.bck
while unzip, you should add -l option.

This "-V" option automatically saves VMS file attributes.

But as per Mr.John info, when you UNZIP, you may have to repair the attributes using his com procedures.>

I have clearly mentioned "-V" option will save RMS file attributes. As I want to give respect to Mr.John's previous posting, I just mentioned about his COM procedures.

Also I have asked to use -l option with unzip, because using this option, we can list the files names, file modification date-time, each file sizes and all files totals. This is what I got as my immediate answer to Mr/Mrs.Lucinda Perry.

We are all just trying our best to address the issue of one our group member, the answers from all our group members may not be same. If my answer delayed Mr/Mrs.Lucinda Perry's work or it hurted you, I am sorry again Steve.

Archunan

[Colin Butcher]

Here's a summary, along with a few observations.

Once-off stuff:

Executables are here:
http://h71000.www7.hp.com/freeware/freeware70/000tools/ia64_images/

Download via PC or directly to a VMS system.

Copy them to SYS$COMMON:[SYSEXE] as ZIP.EXE and UNZIP.EXE

SET FILE/PROT=(S:RWED,O:RWED,G:RWED,W:RE) so that everyone can run them (them protect them with ACLs or whatever works in the context of your system security policy).

Login stuff:

Add $ ZIP :== $ZIP and $ UNZIP :== $UNZIP to your LOGIN.COM (or maybe SYLOGIN.COM if that's appropriate). This sets up the foreign commands you need to be able to use them at the command line and pass parameters in.

Usage:

$ ZIP "-V"

$ UNZIP "-V"

Warnings:

ZIP runs a compression algorithm on a file. If you ZIP it again, or run another compression algorithm again (such as with a tapre drive in compression mode) them you will probably end up with a BIGGER file than you started with. That's an effect of the maths behind the compression algorithms.

So, ZIP is great for compressing files (e.g. savesets) before copying them over a fairly low bandwidth network link (e.g. a VPN between sites using the Internet as a carrier). ZIP is great for fitting large savesets onto DVDs or CDs for storage or software distribution, provided that you have spare writable disc space to expand the files on before you do the rstore - no good shipping a ZIPped saveset of a system image to a system with only one disc drive when the CD is read-only.

ZIP is not great to compress data before writing it to tape where the tape drive has compression enabled.

Hope that helps.

Cheers, Colin.