1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
VMS (OpenVMS):
Building:
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_ZIP.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_ZIP.COM or DESCRIP.MMS.
Note that on non-VAX systems with VMS V7.2 or later (and with a
sufficiently new C compiler), Zip 3.0 can support files (both data
files and Zip archives) larger than 2GB. For the greatest
compatibility with previous Zip versions, the builders by default
create old-style small-file programs. The user must specify the
appropriate builder command-line option to create
large-file-capable programs.
Here are some more complex build examples:
o Build with the large-file option enabled (non-VAX only):
@ [.VMS]BUILD_ZIP LARGE
or:
MMS /DESC = [.VMS] /MACRO = LARGE=1
o Re-link the executables (small-file and large-file):
@ [.VMS]BUILD_ZIP LINK
@ [.VMS]BUILD_ZIP 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 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_ZIP.COM or MMS/MMK command
line to specify the directory where the bzip2 files may be found.
For example:
@ [.VMS]BUILD_ZIP LARGE -
IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_3C_VMS]
or:
MMS /DESC = [.VMS] /MACRO = (LARGE=1, -
IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_3C_VMS])
Note that historically, Zip 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 Zip with /NAMES = AS_IS. For example:
@ [.VMS]BUILD_ZIP LARGE "CCOPTS=/NAMES=AS_IS" -
IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_3C_VMS]
or:
MMS /DESC = [.VMS] /MACRO = (LARGE=1, "CCOPTS=/NAMES=AS_IS", -
IZ_BZIP2=SYS$SYSDEVICE:[UTILITY.SOURCE.BZIP2.BZIP2-1_0_3C_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 (ZIP.HLP for the default
UNIX-like command-line interface, ZIP_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 be used by all system types. (Using the NOHELP option
with BUILD_ZIP.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 Zip
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:
ZIP :== $ dev:[dir]ZIP.EXE ! UNIX-like command line.
or:
ZIP :== $ dev:[dir]ZIP_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:
ZIPS :== $ dev:[dir.ALPHA]ZIP.EXE ! ZIPS = small-file Zip.
ZIP*L :== $ dev:[dir.ALPHAL]ZIP.EXE ! ZIP[L] = large-file Zip.
The builders create help text files, ZIP.HLP and ZIP_CLI.HLP.
These may be incorporated into an existing help library, or a separate
Zip help library may be created using commands like these, using
either ZIP.HLP (as shown) or ZIP_CLI.HLP:
$ LIBRARY /HELP dev:[dir]existing_library.HLB ZIP.HLP
$ LIBRARY /CREATE /HELP ZIP.HLB ZIP.HLP
Zip help may then be accessed from a separate Zip help library
using a command like:
$ HELP /LIBRARY = device:[directory]ZIP.HLB
For greater ease, the user (or system manager) may define a
HLP$LIBRARY logical name to allow the HELP utility to find the Zip
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 Zip help library.
The builders also create VMS message files, ZIP_MSG.EXE, in the
destination directory with the program executables. A user may
gain DCL access to the Zip error messages using a command like:
$ SET MESSAGE device:[directory]ZIP_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 Zip are used on the system, and their error
message source files differ.
Some further information may be found in the files
[.VMS]00README.TXT and [.VMS]00BINARY.VMS, though much of what's
there is now obsolete.
|