                     VMS Notes for UnZip 4.0
                        27 November 1990


The various VMS tweaks to UnZip 4.0 were tested on a VAX 11/785 and a
VAX 8600, both running VMS 5.2 and VAX C 3.0.

Among other things, this system has built into its C run-time library
most of the standard Unix functions; the notable exception is utime().
It also predefines the token "VMS", so it is not necessary to specify
this on the compiler command line.

Despite the lack of utime(), UnZip does manage to set the date/time of
each extracted file--with one exception.  Because of the difference in
the way VMS and Unix/MS-DOS specify directories, UnZip cannot presently
set the dates of files extracted using the -d option (aside from those
in the "root" directory, i.e., without any pathname).  As with directory
dots (more on that below), this is something which will be fixed sooner
or later.  Be patient.

To build UnZip, just run the included command file VMS_MAKE.COM (i.e.,
"@vms_make").  By default, this creates a shareable-image executable,
which is smaller and (supposedly) loads faster than the normal type.  
It also will be better able to take advantage of any bug fixes or new 
capabilities that DEC might introduce, since the library code isn't 
built into the executable.  If you don't want or can't use a shared-
image executable, though, edit the command file to remove everything 
after "unshrink" on the link line (and you can delete the options file 
vmsshare.opt as well).  The shared executable is 54 blocks long, vs. 
approximately 200 for the normal one (i.e., about 27 and 100 KB, re-
spectively).

[Btw, the VMS make utility "MMS" looks to be roughly compatible with the
ordinary Unix variety.  My site doesn't run MMS, but someone whose site
does have it might try adding a "vms" target to the real Makefile.  The 
"msc_dos" target should provide a good template (e.g., file extensions
of .obj and .exe).  If anyone gets it to work, please send your changes
either to me or to David Kirschbaum (kirsch@usasoc.soc.mil).]

UnZip is written to return the standard PK-type return codes (or error
codes, or exit codes, or whatever you want to call them).  Unfortunately,
VMS insists on interpreting the codes in its own lovable way, and this
results in endearing commentary such as "access violation, error mask =
0005, PC = 00003afc" (or something like that) when you run UnZip with no
arguments.  To avoid this I've added a special VMS_return() function which
interprets the error codes and prints a semi-informative message (enclosed
in square [] brackets), then exits with a normal error status.  Tastes
vary, however, and some people may not like the semi-informative messages
(I don't, for one).  If you happen to be one of those people, you may
disable the messages by recompiling misc.c with NO_RETURN_CODES defined.
(This knocks down the executable size by 4 blocks, too.)  The syntax is 
as follows:
	cc /def=(NO_RETURN_CODES) misc

To use UnZip in the normal way, define a symbol "unzip" as follows:
	unzip :== $diskname:[directory]unzip.exe
(substitute for "diskname" and "directory" as appropriate).  In general
it's wise to stick such assignments in your LOGIN.COM file and then for-
get about them.

Because of the gory details of VMS Record Management Services and of the
way UnZip performs seeks, any zipfiles you play with must have a record 
type of "stream-LF".  FTP does not create files with this record type, al-
though Zmodem does; hence it may be necessary to change this appropriately.
On my system this is easy:  we have an ATTRIBUTE command which allows one
to change the record type (for example, "attr /rtype=streamlf zipfile.zip").
Unfortunately, it was recently brought to my attention by Joe Doupnik (aka
"Mr. Kermit") that ATTRIBUTE is not a native VMS command.  As it happens,
there is another utility out there by Joe Meadows ("FILE") which seems to
do the same thing; but again, this is not a native VMS command.  If you 
have one of these utilities, you're set.  If not, you have three choices:
(1) get one of the utilities from a VMS anonftp site; (2) wait for version
4.1 of UnZip, which eliminates the problem, to be released; or (3) send me 
e-mail and I'll send you back the appropriate version 4.1 fixes (still
"beta" versions, but they seem to work all right).  If you choose the latter
course, please specify if you have the capability of reading a compressed
file of some sort (zoo, arc, lharc, zip or tar.Z, uuencoded or xxencoded)--
tends to ease the load on the ol' network, dontcha know.  See the end of
this file for some brief notes about VMSSERV sites.

Having done all this you are ready to roll.  Use the unzip command in
the usual way; as with the MS-DOS and Unix versions, this one uses '-'
as a switch character.  If nothing much happens when you do a directory
listing, for example (aside from a message about "return-code 51," if
you have those messages enabled), you probably forgot to change the file
mode to stream-LF (I mention this because I used to do this on a regular 
basis).  Either that, or else you're trying to specify a filename which 
has uppercase letters in it...VMS thoughtfully converts everything on the 
command line to lowercase, so even if you type Makefile, what you get is 
makefile--which (in my example here) doesn't match.  This is relatively 
easy to circumvent by enclosing the filespec(s) in quotes:
	unzip -tq nunzip99 "Makefile" "VMS*" *.c *.h
[This example also demonstrates the use of wildcards, which act like Unix
wildcards, not VMS ones.   In other words, "VMS*" matches files VMSNOTES,
VMS_MAKE.COM, and VMSSHARE.OPT, whereas the normal VMS behavior would be
to match only the first file (since the others have extensions--ordinarily,
you would be required to specify "VMS*.*").]

Be forewarned about one potential trouble-spot with the directory-creation
facility:  both Unix and DOS allow dots in directory names, but VMS does
not.  As a result, the program will fail horribly with all sorts of un-
pleasant error messages like "routines.for: file exists" (it doesn't) and
"Can't process file:  routines.for/el2.for" (how true).  This will be
fixed in a future release, but since I'm the only person I know who uses
dots in DOS directory names, I don't think it's a serious problem (but
feel free to correct me if your opinion differs).  Note also that created
files get whatever default permissions you've set, but created directories
additionally inherit the (possibly more restrictive) permissions of the
parent directory.  And, of course, things probably won't work too well
if you don't have permission to write to whatever directory into which
you're trying to extract things.  (That made sense; read it again if you
don't believe me.)

Greg Roelofs
roelofs@amelia.nas.nasa.gov
GAL::ROELOFS


Addendum:  VMS mail-based file servers (VMSSERV)
------------------------------------------------

Joe Meadows' FILE utility and many other VMS software packages can be
requested from VMSSERV%FHCRCVAX.BITNET@OLY.ACS.WASHINGTON.EDU (or just
VMSSERV@FHCRCVAX.BITNET) using listserv-type commands; send a message 
whose BODY contains the command "HELP", and you should be on your way 
(I've never tried it, of course :-) ).  There's also a FILESERV thing 
on FileServ@vms.ecs.rpi.edu; get help in the same way.  All this infor-
mation and more comes to you courtesy of the most excellent dude, John 
Lundin, Jr.  Send me e-mail if you want the entire help file (but try
sending a HELP message to VMSSERV *first*, since that's where the file
originally came from, I think).  Or check out the monthly info postings 
in comp.os.vms, if you get netnews.

There are also a number of VMS ftp sites, including Simtel, but you're
on your own there.
