view release on metacpan or  search on metacpan

unzip-6.0/vms/NOTES.TXT  view on Meta::CPAN

   ---------------------------------

   The intent of the "-V" (/VMS) option was to store VMS file attributes
in a Zip archive, allowing UnZip to extract an exact copy of a file on a
VMS system, including all its VMS attributes.

   In Zip before version 2.31, using the "-V" (/VMS) option created an
archive which usually contained data from beyond the EOF (End-of-File)
marker in a data file, but generally not all the disk blocks allocated
for the file.  When extracted on a VMS system, the result was usually
acceptable (because the data from beyond the EOF marker were usually
ignored).  However, when extracted on a non-VMS system, the resulting
file was usually corrupted by being NUL-padded to the next larger 16KB
multiple in size.

   Now (Zip 2.31 and later), with "-V" (/VMS), Zip truncates a data file
at EOF, and portable-format files (Stream_LF, fixed-512) should be
extracted properly on a non-VMS system.  On a VMS system, well-formed
files (that is, those with no valid data beyond EOF) should also be
restored correctly.

   With the new "-VV" (/VMS = ALL) option, the archive includes all
allocated blocks for the file (including those beyond EOF).  When
extracted on a VMS system, the original file should be reproduced with
as much fidelity as possible, but on a non-VMS system, most files will
be seen as corrupt because of the data from beyond EOF.


   Changes to Program Exit Status Values
   -------------------------------------

   Zip and UnZip exit with 32-bit VMS status values which are formed
from their internal OS-independent status values.  In previous program
versions, this was done by converting the internal success code (0) into
%x00000001 (SS$_NORMAL), and converting the other internal warning and
error codes using an artificial control/facility code, 0x7FFF (which
includes some reserved bits), and a severity value which was determined
according to rules specified in the VMS-specific exit function.
Curiously, the internal status codes were left-shifted by 4 bits instead
of 3, so all the resulting VMS message codes (bits 13:3) were even.

   Zip and UnZip now have facility names and codes assigned by HP
(UnZip: IZ_UNZIP, 1954; Zip: IZ_ZIP, 1955).  Now, by default, the
programs exit with standard 32-bit VMS status values which differ from
the old ones in several ways: The official facility code is used, and
the facility-specific bit is set.  (For compatibility with older
versions, the internal status codes are still left-shifted by 4 bits.
This also makes it easier to extract the internal status code from a
hexadecimal representation of the VMS status code.)  The builders also
create non-executable message files (UNZIP_MSG.EXE and ZIP_MSG.EXE) so
that, after a suitable SET MESSAGE command, the program messages will be
available from DCL.  For example:

      $ SET MESSAGE dev:[dir]ZIP_MSG.EXE
      $ ZIP FRED.ZIP no_such_file
        zip warning: name not matched: no_such_file

      zip error: Nothing to do!
      (dev:[dir]FRED.ZIP;)

      ALP $ WRITE SYS$OUTPUT F$MESSAGE( $STATUS)
      %IZ_ZIP-W-NONE, Nothing to do

The message files may be copied into SYS$MESSAGE to make them generally
available, although this could cause some confusion if multiple versions
of the programs are used on the system, and their error message source
files differ.  Each different destination directory will get its own
UNZIP_MSG.EXE or ZIP_MSG.EXE ([.ALPHA], [.ALPHAL], [.VAX], and so on),
but all of the same-architecture files are equivalent to each other.
That is, on an Alpha system, any of the [.ALPHA*]ZIP_MSG.EXE files could
be used; on an IA64 system, any of the [.IA64*]ZIP_MSG.EXE files could
be used; and on a VAX system, any of the [.VAX*]ZIP_MSG.EXE files could
be used.  (Similar for UNZIP_MSG.EXE, of course.)

   If desired, the programs may be built to use the old exit status values
by defining a C macro with the old facility value:
"CTL_FAC_IZ_UNZIP=0x7FFF" (UnZip) or "CTL_FAC_IZ_ZIP=0x7FFF" (Zip).
(See comments in the builder regarding LOCAL_UNZIP or LOCAL_ZIP, as
appropriate.)  This will maintain compatibility with older program
versions, but will make the programs incompatible with the new error
message files.


   VMS File Attribute Schemes
   --------------------------

   Zip's "-V" (/VMS) option causes VMS file attributes to be stored in
an archive.  Since Zip version 2.2 (released in 1996), Zip has, by
default, stored VMS file attributes using a scheme ("PK") which is
compatible with the one used by PKWARE in their PKZIP product.  Before
that, a different scheme ("IM") was used.  UnZip versions before 5.2
support only the older IM scheme, but since UnZip version 5.2, both
schemes have been supported by UnZip.

   The IM scheme has not been well tested recently, but it is still
available.  Some problems were seen when the IM scheme was used with
symbolic links on VMS V8.3.  Details on how build Zip to use the IM
scheme instead of the PK scheme are included in comments in the main
builder files.  Look for VMS_IM_EXTRA in [.VMS]BUILD_ZIP.COM or IM in
[.VMS]DESCRIP.MMS.

   The "special compilation options" section of a "zip -v" ("zip
/verbose") report should show either VMS_PK_EXTRA or VMS_IM_EXTRA,
according to how Zip was built.


   UTC Date-Times
   --------------

   Zip archives traditionally include local (MS-DOS compatible)
date-time information for files.  Since Zip version 2.1, it has also
been possible to store UTC date-time information in the archive, and
since UnZip version 5.2, UnZip has been able to use this UTC date-time
information when extracting files.

   On VMS, support in the C run-time environment for UTC became
available with VMS V7.0.  UTC support in Zip and UnZip is automatically
enabled at compile time, if it is available on the system where the code
is compiled (__CRTL_VER >= 70000000).  It may be disabled at compile
time by defining the C macro NO_EF_UT_TIME.  Details on how build Zip
and UnZip with additional C macros defined are included in comments in