VMS (OpenVMS):
On VMS, two build methods are provided: a command procedure, and
description files for MMS or MMK. Both methods must be run from
the main directory, not the [.VMS] subdirectory.
A simple build using the command procedure looks like this:
@ [.VMS]BUILD_UNZIP.COM
A simple build using MMS or MMK looks like this:
MMS /DESCRIP = [.VMS]DESCRIP.MMS ! Or, with MMK, ...
MMK /DESCRIP = [.VMS]DESCRIP.MMS
Various options for each build method are explained in comments in
the main builder file, either BUILD_UNZIP.COM or DESCRIP.MMS.
Here are some more complex build examples:
o Build with the large-file option enabled (non-VAX only):
@ [.VMS]BUILD_UNZIP LARGE
or:
MMS /DESC = [.VMS] /MACRO = LARGE=1
o Re-link the executables (small-file and large-file):
@ [.VMS]BUILD_UNZIP LINK
@ [.VMS]BUILD_UNZIP LARGE LINK
or
MMK /DESC = [.VMS] CLEAN_EXE ! Deletes existing executables.
MMK /DESC = [.VMS] ! Builds new executables.
MMK /DESC = [.VMS] /MACRO = LARGE=1 CLEAN_EXE
MMK /DESC = [.VMS] /MACRO = LARGE=1
o Build a large-file product from scratch, for debug, getting
compiler listings and link maps:
MMS /DESC = [.VMS] CLEAN
MMS /DESC = [.VMS] /MACRO = (DBG=1, LARGE=1. LIST=1)
On VAX, the builders attempt to cope with the various available C
compilers, DEC/Compaq/HP C, VAX C, or GNU C. If DEC/Compaq/HP C is
not available or not desired, comments in the relevant builder file
explain the command-line options used to select a different
compiler.
By default, Zip uses (and UnZip supports) the "deflate" compression
method. To add support for the optional "bzip2" compression method,
first obtain and build the bzip2 software (http://www.bzip.org/ or,
for a more VMS-friendly kit, http://antinode.info/dec/sw/bzip2.html).
Then, define the macro IZ_BZIP2 on the BUILD_UNZIP.COM or MMS/MMK
command line to specify the directory where the bzip2 files may be
found. For example:
@ [.VMS]BUILD_UNZIP LARGE -
IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_4B_VMS]
or:
MMS /DESC = [.VMS] /MACRO = (LARGE=1, -
IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_4B_VMS])
Note that historically, UnZip has been built with the default
compiler option, /NAMES = UPPERCASE, while bzip2 is normally built
with /NAMES = AS_IS, to avoid name collisions. With modern
compilers, the "#pragma names" directives in [.VMS]BZLIB.H will
handle these differences without user intervention. An old
compiler (for example, DEC C V4.0-000) will emit complaints
%CC-I-UNKNOWNPRAGMA, and will mishandle the bzip2 library function
names, which will cause the link to fail. To solve this problem,
either build the bzip2 BZ_NO_STDIO object library with /NAMES =
UPPERCASE, or else build UnZip with /NAMES = AS_IS. For example:
@ [.VMS]BUILD_UNZIP LARGE "CCOPTS=/NAMES=AS_IS" -
IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_4B_VMS]
or:
MMS /DESC = [.VMS] /MACRO = (LARGE=1, "CCOPTS=/NAMES=AS_IS", -
IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_4B_VMS])
System-architecture-specific files (like objects and executables)
are placed in separate directories, such as [.ALPHA], [.IA64], or
[.VAX]. Large-file products get their own directories, [.ALPHAL]
or [.IA64L]. On VAX, VAX C products are placed in [.VAXV], GNU C
products in [.VAXG]. Each product builder announces what the
destination directory will be when it is run.
Common files, such as the help libraries (UNZIP.HLP for the default
UNIX-like command-line interface, UNZIP_CLI.HLP for the VMS-like
command-line interface), are placed in the main directory. With a
mixed-architecture VMS cluster, the same main directory on a shared
disk may may be used by all system types. (Using the NOHELP option
with BUILD_UNZIP.COM can keep it from making the same help files
repeatedly.) Building the help files is detailed below.
Completing installation:
To complete the installation, the executables may be left in place,
or moved (or copied) to a convenient place. While other methods
(like DCL$PATH) exist, most users define symbols to make the UnZip
executables available as foreign commands. These symbol definitions
may be placed in a user's SYS$LOGIN:LOGIN.COM, or in a more central
location, like SYS$MANAGER:SYLOGIN.COM. Typical symbol definitions
might look like these:
UNZIP :== $ dev:[dir]UNZIP.EXE ! UNIX-like command line.
or:
UNZIP :== $ dev:[dir]UNZIP_CLI.EXE ! VMS-like command line.
On a non-VAX system, different symbols could be defined for the
small-file and large-file programs. For example:
UNZIPS :== $ dev:[dir.ALPHA]UNZIP.EXE ! UNZIPS = small-file UnZip.
UNZIP*L :== $ dev:[dir.ALPHAL]UNZIP.EXE !UNZIP[L] = large-file UnZip.
The builders create help text files, UNZIP.HLP and UNZIP_CLI.HLP.
These may be incorporated into an existing help library, or a separate
UnZip help library may be created using commands like these, using
either UNZIP.HLP (as shown) or UNZIP_CLI.HLP:
LIBRARY /HELP dev:[dir]existing_library.HLB UNZIP.HLP
LIBRARY /CREATE /HELP UNZIP.HLB UNZIP.HLP
UnZip help may then be accessed from a separate UnZip help library
using a command like:
HELP /LIBRARY = device:[directory]UNZIP.HLB
For greater ease, the user (or system manager) may define a
HLP$LIBRARY logical name to allow the HELP utility to find the UnZip
help library automatically. See HELP HELP /USERLIBRARY for more
details. The command procedure HLP_LIB_NEXT.COM may be used to
determine the next available HLP$LIBRARY logical name, and could be
adapted to define a HLP$LIBRARY logical name for a UnZip help library.
The builders also create VMS message files, UNZIP_MSG.EXE, in the
destination directory with the program executables. A user may
gain DCL access to the UnZip error messages using a command like:
SET MESSAGE device:[directory]UNZIP_MSG.EXE
For system-wide access, the system manager may move or copy this
file to SYS$MESSAGE, although this could cause some confusion if
multiple versions of UnZip are used on the system, and their error
message source files differ.