diff options
Diffstat (limited to 'vms/install_vms.txt')
| -rw-r--r-- | vms/install_vms.txt | 158 |
1 files changed, 158 insertions, 0 deletions
diff --git a/vms/install_vms.txt b/vms/install_vms.txt new file mode 100644 index 0000000..47dfebb --- /dev/null +++ b/vms/install_vms.txt @@ -0,0 +1,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. |