Using ZIP and UNZIP on VM/CMS
=============================


Installing executables
----------------------

The following CMS MODULEs are available:
   ZIP
   ZIPNOTE
   ZIPCLOAK
   ZIPSPLIT
   UNZIP

In addition to these, each MODULE file also has an EXEC with the same
name.  These EXECs are front-ends to the MODULES that will attempt to
set up the required runtime libraries before running the MODULE.
All the EXECs are identical.  Only their names are different.
They are stored as plain text files.

The CMS MODULE files have been packed using the COPYFILE command to
allow their file format to be properly restored, since variable length
binary files will not currently unzip properly (see below for details).
The MODULEs are shipped with a filetype or extension of CMO (for CMS
MODULE).  Their names may vary on the distribution disk to indicate
their level, etc.

To restore them to executable MODULEs on CMS, do the following:
   1. Upload them to CMS with a Fixed record length with LRECL 1024.
      Example, from a DOS or OS/2 window, type this:
         SEND unzip.cmo A:unzip module a (RECFM F LRECL 1024

      Example, using FTP from CMS, type this:
         BINARY FIXED 1024
         GET unzip.cmo unzip.module.a

      Note:  Replace "unzip.cmo" with the actual name.

   2. Use COPYFILE to unpack the file.
      Example, in CMS type this:
         COPYFILE UNZIP MODULE A (UNPACK REPLACE OLDDATE

   3. Repeat steps 1-2 for each of the programs.

   4. Build the ZIPINFO module by typing this:
         COPYFILE UNZIP MODULE A ZIPINFO MODULE A (OLDDATE

   5. Upload the EXECs to CMS as text files (with ASCII-to-EBCDIC
      translation).
      Example, from a DOS or OS/2 window, type this:
         SEND unzip.exc A:unzip exec a (CRLF

      Example, using FTP from CMS, type this:
         GET unzip.exc unzip.exec.a

   6. Repeat steps 4 for each of the EXECs.


Preparing the environment
-------------------------

The executables provided were compiled with IBM C 3.1.0 and
require the the Language Environment (LE) runtime libraries.

To provide access to the runtime libraries:
   1. Link to the disk containing the Language Environment files,
      if necessary.

   2. Use the command "GLOBAL LOADLIB SCEERUN"

   These commands can be placed in your PROFILE EXEC.

   Note:  EXECs have been provided called ZIP, UNZIP, etc. that
   issue the GLOBAL LOADLIB statement.  This was done to alleviate
   frustration of users that don't have the GLOBAL LOADLIB statement
   in their PROFILE EXEC.  These EXECs may require changing for
   your system.

   Unfortunately, there is no way, using IBM C, to produce a MODULE
   that doesn't require a runtime library.


Testing
-------

To test the MODULEs, just type ZIP or UNZIP.  They should
show help information on using the commands.

If you see something like this:
   DMSLIO201W The following names are undefined:
    CEEEV003
   DMSABE155T User abend 4093 called from 00DCD298 reason code 000003EB

Then you don't have access to the proper runtime libraries, as
described above.

Here is additional information on the ZIP and UNZIP programs that
may assist support personnel:
   - Compiled with IBM C V3R1M0 on VM/ESA 2.2.0 with
     CMS level 13 Service Level 702.

   - Require the SCEERUN LOADLIB runtime library.  This is
     part of the Language Environment (LE).

   - Linked with options RMODE ANY AMODE ANY RLDSAVE.

If you continue to have trouble, report the problem to Zip-Bugs
(see the bottom of this document).



Compiling the source on VM/CMS
------------------------------

The source has been successfully compiled previously using
C/370 2.1 and 2.2.  The source has been recently compiled using
IBM C 3.1.0 on VM/ESA 2.2.0 with CMS level 13.  I don't have
access to an MVS system so the code hasn't been tested there
in a while.

 1. Unzip the source files required for CMS.  The root-level files
    inside the ZIP file and the files in the CMSMVS subdirectory are
    needed.  Example (use both commands):
       unzip -aj zip23.zip -x */*   -dc
       unzip -aj zip23.zip cmsmvs/* -dc

    This example unzips the files to the C-disk, while translating
    character data and ignoring paths.

    If you don't already have a working UNZIP MODULE on CMS you will
    have to unzip the files on another system and transport them
    to CMS.  All the required files are plain text so they can
    be transferred with ASCII-to-EBCDIC translations.

 2. Repeat step 1 with the zip file containing the UNZIP code.
    Unzip the files to a different disk than the disk used for the ZIP
    code.

 3. To compile the ZIP code, run the supplied CCZIP EXEC.
    To compile the UNZIP code, run the supplied CCUNZIP EXEC.

NOTE:
Some of the ZIP and UNZIP source files have the same name.  It is
recommended that you keep the source from each on separate disks and
move the disk you are building from ahead of the other in the search
order.

For example, you may have a 192 disk with the ZIP source code and
a 193 disk with the UNZIP source code.  To compile ZIP, access
the 192 disk as B, then run CCZIP.  This will create the following
modules:  ZIP, ZIPNOTE, ZIPSPLIT, ZIPCLOAK.

To compile UNZIP, access 193 as B, then run CCUNZIP.  This will create
the following modules:  UNZIP, ZIPINFO (a copy of UNZIP).


=========================================================================


Using ZIP/UNZIP
---------------

Documentation for the commands is in MANUAL NONAME (for ZIP) and in
UNZIP DOC UNZIP.  INFOZIP DOC describes the use of the -Z option of
UNZIP.

The rest of this section explains special notes concerning the VM/CMS
version of ZIP and UNZIP.


Filenames and directories
-------------------------

 1. Specifying filenames

    a. When specifying CMS files, use filename.filetype.filemode format
       (separate the three parts of the name with a period and use no
       spaces).  Example:  profile.exec.a

       Unfortunately, this prevents you from using ZIP from
       FILELIST.  To unzip a zip file, however, you can type something
       like this next to it in FILELIST:
          unzip /n -d c

       This will unzip the contents of the current file to a C-disk.

    b. It is possible to use DD names with ZIP and UNZIP on CMS, though
       it can be cumbersome.  Example:
          filedef out disk myzip zip a
          zip dd:out file1.txt file2.txt

       While you can also use a DD name for the input files, ZIP
       currently does not correctly resolve the filename and will
       store something like "dd:in" inside the ZIP file.  A file stored
       in this manor cannot easily be unzipped, as "dd:in" is an invalid
       filename.

    c. In places where a directory name would be used on a PC, such as
       for the ZIP -b (work path) option or the UNZIP -d (destination
       path) options, use a filemode letter for CMS.  For example,
       to unzip files onto a C-disk, you might type something like this:
          unzip myzip.zip -d c

       Currently, ZIP uses the A-disk for work files.  When zipping
       large files, you may want to specify a larger disk for work files.
       This example will use a C-disk for work files.
          zip -b C myzip.zip.c test.dat.a


 2. Filename conversions

    a. Filemode letters are never stored into the zip file or take from
       a zip file.  Only the filename and filetype are used.
       ZIP removes the filemode when storing the filename into the
       zip file.  UNZIP assumes "A" for the filemode unless the -d
       option is used.

    b. When unzipping, any path names are removed from the fileid
       and the last two period-separated words are used as the
       filename and filetype.  These are truncated to a maximum of
       eight characters, if necessary.  If the filetype (extension)
       is missing, then UNZIP uses "NONAME" for the filetype.
       Any '(' or ')' characters are removed from the fileid.

    c. All files are created in upper-case.  Files in mixed-case
       cannot currently be stored into a ZIP file.

    d. Shared File System (SFS) directories are not supported.
       Files are always accessed by fn.ft.fm.  To use an SFS disk,
       Assign it a filemode, then it can be used.


 3. Wildcards in file names

    a. Wildcards are not supported in the zip filename.  The full
       filename of the zip file must be given (but the .zip is not
       necessary).  So, you can't do this:
          unzip -t *.zip

    b. Wildcards CAN be used with UNZIP to select (or exclude) files
       inside a zip file.  Examples:
          unzip myzip *.c          - Unzip all .c files.
          unzip myzip *.c -x z*.c  - Unzip all .c files but those
                                     starting with Z.

    c. Wildcards cannot currently be used to select files with ZIP.
       So, you can't do this:
          zip -a myzip *.exec

       I expect to fix this for CMS in the future.


 4. File timestamps

    a. The dates and times of files being zipped or unzipped are not
       currently read or set.  When a file is zipped, the timestamp
       inside the zip file will always be the current system date and
       time.  Likewise, when unzipping, the date and time of files
       being unzipped will always be the current system date/time.

    b. Existing files are assumed to be newer than files inside a zip
       file when using the -f freshen option of UNZIP.  This will prevent
       overwriting files that may be newer than the files inside the
       zip file, but also effectively prevents the -f option from working.


 5. ASCII, EBCDIC, and binary data

    Background
    ----------
    Most systems create data files as just a stream of bytes.  Record
    breaks happen when certain characters (new line and/or carriage
    return characters) are encountered in the data.  How to interpret
    the data in a file is up to the user.  The system must be told
    to either notice new line characters in the data or to assume
    that the data in the file is binary data and should be read or
    written as-is.

    CMS and MVS are record-based systems.  All files are composed
    of data records.  These can be stored in fixed-length files or
    in variable length files.  With fixed-length files, each record
    is the same length.  The record breaks are implied by the
    LRECL (logical record length) attribute associated with the file.
    With variable-length files, each record contains the length of
    that record.  The separation of records are not part of the
    data, but part of the file structure.

    This means you can store any type of data in either type of file
    structure without having to worry about the data being interpreted
    as a record break.  Fixed-length files may have padding at the
    end of the file to make up a full record.  Variable-length files
    have no padding, but require extra record length data be stored
    with the file data.

    Storing fixed-length files into a zip file is simple, because all
    the data can just be dumped into the zip file and the record
    format (RECFM) and logical record length (LRECL) can be stored
    in the extra data area of the zip file so they can be restored
    when UNZIP is used.

    Storing variable-length data is harder.  There is no place to put
    the record length data needed for each record of the file.  This
    data could be written to the zip file as the first two bytes of
    each record and interpreted that way by UNZIP.  That would make
    the data unusable on systems other than CMS and MVS, though.

    Currently, there isn't a solution to this problem.  Each record is
    written to the zip file and the record length information is
    discarded.  Binary data stored in variable-length files can't be put
    into a zip file then later unzipped back into the proper records.
    This is fine for binary data that will be read as a stream of bytes
    but not OK where the records matter, such as with CMS MODULEs.

    If the data is text (character data), there is a solution.
    This data can be converted into ASCII when it's stored into
    a zip file.  The end of each record is now marked in the file
    by new line characters.  Another advantage of this method is
    that the data is now accessible to non-EBCDIC systems.  When
    the data is unzipped on CMS or MVS, it is converted back into
    EBCDIC and the records are recreated into a variable-length file.


    So, here's what we have...

    a. To store readable text data into a zip file that can be used
       on other platforms, use the -a option with ZIP to convert the
       data to ASCII.  These files will unzip into variable-length
       files on CMS and should not contain binary data or corruption
       may occur.

    b. Files that were zipped on an ASCII-based system will be
       automatically translated to EBCDIC when unzipped.  To prevent
       this (to unzip binary data on CMS that was sent from an
       ASCII-based system), use the -B option with UNZIP to force Binary
       mode.  To zip binary files on CMS, use the -B option with ZIP to
       force Binary mode.  This will prevent any data conversions from
       taking place.

    c. When using the ZIP program without specifying the "-a" or "-B"
       option, ZIP defaults to "native" (EBCDIC) mode and tries to
       preserve the file information (RECFM, LRECL, and BLKSIZE).  So
       when you unzip a file zipped with ZIP under CMS or MVS, UNZIP
       restores the file info.  The output will be fixed-length if the
       original was fixed and variable-length if the original was
       variable.

    If UNZIP gives a "write error (disk full?)"  message, you may be
    trying to unzip a binary file that was zipped as a text file
    (without using the -B option)


    Summary
    -------
    Here's how to ZIP the different types of files.

    RECFM F text
       Use the -a option with ZIP to convert to ASCII for use with other
       platforms or no options for use on EBCDIC systems only.

    RECFM V text
       Use the -a option with ZIP to convert to ASCII for use with other
       platforms or no options for use on EBCDIC systems only.


    RECFM F binary
       Use the -B option with ZIP (upper-case "B").

    RECFM V binary
       Use the -B option with ZIP.  Can be zipped OK but the record
       structure is destroyed when unzipped.  This is OK for data files
       read as binary streams but not OK for files such as CMS MODULEs.


 6. Character Sets

    If you are used to running UNZIP on systems like UNIX, DOS, OS/2 or
    Windows, you will may have some problems with differences in the
    character set.

    There are a number of different EBCDIC code pages, like there are a
    number of different ASCII code pages.  For example, there is a US
    EBCDIC, a German EBCDIC, and a Swedish EBCDIC.  As long as you are
    working with other people who use the same EBCDIC code page, you
    will have no trouble.  If you work with people who use ASCII, or who
    use a different EBCDIC code page, you may need to do some
    translation.

    UNZIP translates ASCII text files to and from Open Systems EBCDIC
    (IBM-1047), which may not be the EBCDIC that you are using.  For
    example, US EBCDIC (IBM-037) uses different character codes for
    square brackets.  In such cases, you can use the ICONV utility
    (supplied with IBM C) to translate between your EBCDIC character set
    and IBM-1047.

    If your installation does not use IBM-1047 EBCDIC, messages from
    UNZIP may look a little odd.  For example, in a US EBCDIC
    installation, an opening square bracket will become an i-acute and a
    closing square bracket will become a u-grave.

    The supplied ZIP and UNZIP EXECs attempt to correct this by setting
    CMS INPUT and OUTPUT translations to adjust the display of left and
    right brackets.  You may need to change this if brackets don't
    display correctly on your system.


 7. You can unzip using VM/CMS PIPELINES so unzip can be used as
    a pipeline filter.  Example:
       'PIPE COMMAND UNZIP -p test.zip george.test | Count Lines | Cons'




Please report all bugs and problems to:
   Zip-Bugs@lists.wku.edu


-----------------------------------------------------------------------
Original CMS/MVS port by George Petrov.
e-mail:  c888090@nlevdpsb.snads.philips.nl
tel:     +31-40-781155

Philips C&P
Eindhoven
The Netherlands

-----------------------------------------------------------------------
Additional fixes and README re-write (4/98) by Greg Hartwig.
e-mail:  ghartwig@ix.netcom.com
         ghartwig@vnet.ibm.com

-----------------------------------------------------------------------
Additional notes from Ian E. Gorman.
e-mail:  ian@iosphere.net

Thank you for trying this first port of ZIP for VM/CMS and MVS!


                        Using under MVS:
                    ---------------------------

1. To use the Info-ZIP's ZIP under MVS you need:

   - C/370 ver 2.1 compiler or another compatible compiler supporting
     long names for function/variable names.

2. To compile the program under MVS do :

   - unzip all the files from zip22.zip file. They are stored as
     ASCII format so you have to unzip them first on PC or other
     system that already have UNZIP, and then upload them to the
     mainframe with ASCII to EBCDIC conversion.

   - Copy all the .C files in the PDS called youruserid.ZIP.C

   - Copy all the .H files in the PDS called youruserid.ZIP.H

   - adjust the job ZIPMVSC.JOB to work on your size. Change my
     userid - C888090 to yours

   - execute the job ZIPMVSC to compile and link all the sources.

   - maybe you have to preallocate PDS datasets named:
     youruserid.ZIP.OBJ and youruserid.ZIP.LOAD

   - execute ZIPVMC to compile and link all the sources.

   - if everything is ok you will get an ZIP MODULE

   - the warnings about the duplicated ASCII and EBCDIC symbols
     are OK :-)

3. Using ZIP

   - Just read MANUAL

   - A few exceptions concerning MVS

     3.1. if you want to make a portable zip file that is to be unzipped
          on ASCII based systems use the -a option

     3.2. If you want to zip the input files as binary ebcdic files
          use the -B (capital letter) option

     3.3. The date/end the time of the input files is set in the zip's
          dir to the current system date/time

     3.4. Without specifying the "-a" or "-B" option, the ZIP program
          defaults to "native" (EBCDIC) mode and tries to preserve the
          file information (LRECL,BLKSIZE..)
          So when you UNZIP a file zipped with ZIP under VM/MVS it
          restores the file info.

          There currently some problems with file with RECFM=V*
          I don't save the length of each record yet :-)

     3.5. No wildcards are supported as input file names:

          So you CAN'T use things like: zip myzip *.c

     3.6. You can use DD names for zipfilename for example:

          under tso/rexx:

           "alloc fi(input) da('myzip.zip')"
           "zip dd:input file1.txt file2.txt ..."

          under Batch:

           //MYZIP    JOB  (account)
           //STEP1    EXEC PGM=ZIP,PARM='dd:input file1.txt file2.txt'
           //STEPLIB  DD DSN=userid.UNZIP.LOAD,DISP=SHR
           //INPUT    DD DSN=userid.MYZIP.ZIP,DISP=NEW,
           //            SPACE=(15000,(15000,10000),RLSE),
           //            DCB=(LRECL=80,RECFM=F)
           //SYSPRINT DD SYSOUT=*


Please report all bugs and problems to :
     zip-bugs@lists.wku.edu

That's all for now.

Have fun!


George Petrov

Notes on Zip under MVS Language Environment (LE).

First see README.MVS.  This note describes just one beta test on OS/390
V2R5 using IBM's C compiler (5647A01), V2R4.  The major difference is
the use of LE on the beta site, together with some MVS native mode
fixes.  Changes have not been tested on CMS.

Some of the notes are to clarify things that were not clear from the
MANUAL or README.MVS.

1.  By default, IBM C generates the same csect name for each input
    source.  The prelink stage does not rename them and the linkage
    editor throws away all but the first occurrence of each duplicate.
    Oops, my code just disappeared :(.

    To get around this "feature", compile with the CSECT option to
    force sensible names on the code and data sections of each csect.
    The name of the static data csect defaults to the source name in
    lower case, the code csect defaults to the source name in upper
    case.  These csect names still have to be unique, they cannot be
    the same as function names.  Of course, several csects have a
    function which is the same name as the source in lower case, not
    exactly an unusual occurrence.  Therefore to make the csect name
    unique, some of the sources have

    #ifdef MVS
    #  pragma csect(STATIC,xxxx_s)
    #endif

    Where xxxx is an abbreviation of the source name.  There has to be
    a better way!

2.  The prelink step always gets cond code 4.  It complains about
    unresolved references, ignore it unless the linker also complains.
    Prelink also complains about duplicate @@PPA2 sections and so does
    the linker, but it seems to do no harm.  Compile and link steps
    should get 0, just prelink gets 4.  See JCL at the bottom.

3.  Under MVS native mode (not Open Edition), tmpnam() returns a quoted
    name of 5 qualifiers.  The first is a HLQ chosen according to the
    MVS LE algorithm (see below), the other qualifiers are time stamps.
    If running on MVS and tmpnam() returns a quoted name with at leat
    one '.', it is only safe to let the user change the high level
    qualifier.  Therefore -b insists on a single qualifier without '.'
    in the MVS native environment.

4.  In Open Edition (OE) mode, the manual says that tmpnam() returns a
    fully qualified name in directory TMPDIR or /tmp if TMPDIR is not
    set.  There is no point in zip trying to override that name so -b
    is ignored in MVS OE mode (untested).  The user should specify
    environment variable TMPDIR instead.

5.  The MVS LE algorithm for choosing the high level qualifier for
    native filenames is interesting, as in "May you live in interesting
    times".  The HLQ varies according to the environment the program is
    running in, sometimes it is userid, sometimes it is TSO prefix.
    See OS/390 C/C++ Programming Guide, Using a Data Set Name,
    somewhere around section 2.9.

    If in doubt, use fully qualified and quoted names.  Instead of
    archive.zip, use 'prefix.archive.zip'.  For input files, instead of
    filename, use 'prefix.filename'.  For PARM= in JCL, double up the
    quotes.  You even have to quote filenames in stdin.

6.  If your PARM includes any '/', make sure the PARM starts with '/'.
    LE assumes anything before the first '/' is LE run time parameters.
    It does no harm to always code a leading '/' for LE parms.

7.  JCL limits a PARM= to 100 characters total with approx. 65 on a
    single line.  Alas the syntax for continuing PARM= always embeds an
    extra ',' somewhere in the parameters that the program finally
    gets.  No workaround, limit your PARM to a single line.  With the
    extra quotes around filenames, that does not leave much room.  In
    most cases, you will have to use '-@' to read the list of filenames
    from SYSIN (stdin), it will not fit on a single PARM line.

8.  Filenames can be dataset names or you can refer to a ddname with
    'DD:name', case insensitive for external files, case sensitive for
    OE files.  You can even specify 'dd:name(mem)'.  No wildcards, to
    zip a complete pds you have to specify each member individually.
    Directory recursion in OE does not appear to work at the moment.

9.  Zip attempts to map MVS filenames to Unix style names.  It did not
    work correctly for quoted names, fixed.  Although you can pick up
    an external (non-OE) file with a name using any case, be aware that
    the mapping to a Unix style name faithfully follows the case you
    supply.

10. The archive file was being created with recfm=V and lrecl=32760.
    32760 is not valid for recfm=V under MVS, I originally changed it
    to lrecl=32756.  Then zip broke trying to fseek() over a record
    boundary, I do not know whether this was a zip or LE bug.  Trial
    and error showed that recfm=U with byteseek seems to work on MVS.
    No BDW or RDW, just a byte stream.  The blocksize is always 6144.

    NOTE: This is an incompatible change from the previous beta,
          archive files used to be recfm=V.  That should not matter
          because we just transfer the data, ignoring BDW and RDW
          anyway.

11. Zip used to complain about preallocated but empty archives, wrong
    length records, no signature etc.  The usual IBM/360 problem of no
    end of file marker in a new, unopened dataset.  Fixed, see routine
    readzipfile in zipfile.c for the gory details.  PARM= works fine.

12. Several source files have records that are more than 80 bytes long.
    It works if you transfer to mainframe datasets with a larger lrecl,
    I used recfm=fb,lrecl=120 for the .C and .H files.  To compile with
    anything longer than 72 bytes, you need MVS C options NOMARGINS and
    NOSEQUENCE (NOMAR,NOSEQ).

13. cmsmvs was still using zname instead of name for open.  Fixed.

14. zip has to jump through a lot of hoops to see if an existing
    zipfile actually contains data.  A side effect of this is that
    creating a zipfile with the RLSE parameter is a waste of time.

Keith Owens <kaos@ocs.com.au>.  Not a maintainer, just a beta tester.
Mon Sep 14 19:31:30 EST 1998


Sample JCL to compile Zip under MVS LE.  You might need a large region,
I used REGION=128M on the job card.  Also watch the output lines,
75,000 with OPT(2), 100,000+ with OPT(2) replaced with DEF(DEBUG).  You
need to allocate prefix.ZIP.C.OBJ (recfm=FB, lrecl=80) and
prefix.ZIP.LOAD (recfm=U, blksize is site defined).

//CBC    JCLLIB ORDER=CBC.SCBCPRC
//ZIP EXEC EDCC,COND=(0,NE),CREGSIZ='4M',
//    INFILE='prefix.ZIP.C(ZIP)',
//    OUTFILE='prefix.ZIP.C.OBJ(ZIP),DISP=SHR',
//    CPARM='LONG,NOTERM,LIST,XREF,SOURCE',
//    CPARM2='OPT(2),DEF(MVS),NOMAR,NOSEQ,CSECT'
//COMPILE.USERLIB DD DSN=prefix.ZIP.H,DISP=SHR
//CRYPT EXEC EDCC,COND=(0,NE),CREGSIZ='4M',
//    INFILE='prefix.ZIP.C(CRYPT)',
//    OUTFILE='prefix.ZIP.C.OBJ(CRYPT),DISP=SHR',
//    CPARM='LONG,NOTERM,LIST,XREF,SOURCE',
//    CPARM2='OPT(2),DEF(MVS),NOMAR,NOSEQ,CSECT'
//COMPILE.USERLIB DD DSN=prefix.ZIP.H,DISP=SHR
//TTYIO EXEC EDCC,COND=(0,NE),CREGSIZ='4M',
//    INFILE='prefix.ZIP.C(TTYIO)',
//    OUTFILE='prefix.ZIP.C.OBJ(TTYIO),DISP=SHR',
//    CPARM='LONG,NOTERM,LIST,XREF,SOURCE',
//    CPARM2='OPT(2),DEF(MVS),NOMAR,NOSEQ,CSECT'
//COMPILE.USERLIB DD DSN=prefix.ZIP.H,DISP=SHR
//TREES EXEC EDCC,COND=(0,NE),CREGSIZ='4M',
//    INFILE='prefix.ZIP.C(TREES)',
//    OUTFILE='prefix.ZIP.C.OBJ(TREES),DISP=SHR',
//    CPARM='LONG,NOTERM,LIST,XREF,SOURCE',
//    CPARM2='OPT(2),DEF(MVS),NOMAR,NOSEQ,CSECT'
//COMPILE.USERLIB DD DSN=prefix.ZIP.H,DISP=SHR
//DEFLATE EXEC EDCC,COND=(0,NE),CREGSIZ='4M',
//    INFILE='prefix.ZIP.C(DEFLATE)',
//    OUTFILE='prefix.ZIP.C.OBJ(DEFLATE),DISP=SHR',
//    CPARM='LONG,NOTERM,LIST,XREF,SOURCE',
//    CPARM2='OPT(2),DEF(MVS),NOMAR,NOSEQ,CSECT'
//COMPILE.USERLIB DD DSN=prefix.ZIP.H,DISP=SHR
//FILEIO EXEC EDCC,COND=(0,NE),CREGSIZ='4M',
//    INFILE='prefix.ZIP.C(FILEIO)',
//    OUTFILE='prefix.ZIP.C.OBJ(FILEIO),DISP=SHR',
//    CPARM='LONG,NOTERM,LIST,XREF,SOURCE',
//    CPARM2='OPT(2),DEF(MVS),NOMAR,NOSEQ,CSECT'
//COMPILE.USERLIB DD DSN=prefix.ZIP.H,DISP=SHR
//GLOBALS EXEC EDCC,COND=(0,NE),CREGSIZ='4M',
//    INFILE='prefix.ZIP.C(GLOBALS)',
//    OUTFILE='prefix.ZIP.C.OBJ(GLOBALS),DISP=SHR',
//    CPARM='LONG,NOTERM,LIST,XREF,SOURCE',
//    CPARM2='OPT(2),DEF(MVS),NOMAR,NOSEQ,CSECT'
//COMPILE.USERLIB DD DSN=prefix.ZIP.H,DISP=SHR
//UTIL EXEC EDCC,COND=(0,NE),CREGSIZ='4M',
//    INFILE='prefix.ZIP.C(UTIL)',
//    OUTFILE='prefix.ZIP.C.OBJ(UTIL),DISP=SHR',
//    CPARM='LONG,NOTERM,LIST,XREF,SOURCE',
//    CPARM2='OPT(2),DEF(MVS),NOMAR,NOSEQ,CSECT'
//COMPILE.USERLIB DD DSN=prefix.ZIP.H,DISP=SHR
//CRC32 EXEC EDCC,COND=(0,NE),CREGSIZ='4M',
//    INFILE='prefix.ZIP.C(CRC32)',
//    OUTFILE='prefix.ZIP.C.OBJ(CRC32),DISP=SHR',
//    CPARM='LONG,NOTERM,LIST,XREF,SOURCE',
//    CPARM2='OPT(2),DEF(MVS),NOMAR,NOSEQ,CSECT'
//COMPILE.USERLIB DD DSN=prefix.ZIP.H,DISP=SHR
//CRCTAB EXEC EDCC,COND=(0,NE),CREGSIZ='4M',
//    INFILE='prefix.ZIP.C(CRCTAB)',
//    OUTFILE='prefix.ZIP.C.OBJ(CRCTAB),DISP=SHR',
//    CPARM='LONG,NOTERM,LIST,XREF,SOURCE',
//    CPARM2='OPT(2),DEF(MVS),NOMAR,NOSEQ,CSECT'
//COMPILE.USERLIB DD DSN=prefix.ZIP.H,DISP=SHR
//ZIPFILE EXEC EDCC,COND=(0,NE),CREGSIZ='4M',
//    INFILE='prefix.ZIP.C(ZIPFILE)',
//    OUTFILE='prefix.ZIP.C.OBJ(ZIPFILE),DISP=SHR',
//    CPARM='LONG,NOTERM,LIST,XREF,SOURCE',
//    CPARM2='OPT(2),DEF(MVS),NOMAR,NOSEQ,CSECT'
//COMPILE.USERLIB DD DSN=prefix.ZIP.H,DISP=SHR
//ZIPUP EXEC EDCC,COND=(0,NE),CREGSIZ='4M',
//    INFILE='prefix.ZIP.C(ZIPUP)',
//    OUTFILE='prefix.ZIP.C.OBJ(ZIPUP),DISP=SHR',
//    CPARM='LONG,NOTERM,LIST,XREF,SOURCE',
//    CPARM2='OPT(2),DEF(MVS),NOMAR,NOSEQ,CSECT'
//COMPILE.USERLIB DD DSN=prefix.ZIP.H,DISP=SHR
//CMSMVS EXEC EDCC,COND=(0,NE),CREGSIZ='4M',
//    INFILE='prefix.ZIP.C(CMSMVS)',
//    OUTFILE='prefix.ZIP.C.OBJ(CMSMVS),DISP=SHR',
//    CPARM='LONG,NOTERM,LIST,XREF,SOURCE',
//    CPARM2='OPT(2),DEF(MVS),NOMAR,NOSEQ,CSECT'
//COMPILE.USERLIB DD DSN=prefix.ZIP.H,DISP=SHR
//MVS EXEC EDCC,COND=(0,NE),CREGSIZ='4M',
//    INFILE='prefix.ZIP.C(MVS)',
//    OUTFILE='prefix.ZIP.C.OBJ(MVS),DISP=SHR',
//    CPARM='LONG,NOTERM,LIST,XREF,SOURCE',
//    CPARM2='OPT(2),DEF(MVS),NOMAR,NOSEQ,CSECT'
//COMPILE.USERLIB DD DSN=prefix.ZIP.H,DISP=SHR
//PLINK   EXEC  PROC=EDCPL,
//    OUTFILE='prefix.ZIP.LOAD(ZIP),DISP=SHR',
//    PREGSIZ=6M,
//    PPARM='NONCAL,MAP,MEMORY',
//    LPARM='LIST,MAP,XREF'
//PLKED.SYSIN   DD  DISP=SHR,DSN=prefix.ZIP.C.OBJ(ZIP)
//              DD  DISP=SHR,DSN=prefix.ZIP.C.OBJ(CRYPT)
//              DD  DISP=SHR,DSN=prefix.ZIP.C.OBJ(TREES)
//              DD  DISP=SHR,DSN=prefix.ZIP.C.OBJ(DEFLATE)
//              DD  DISP=SHR,DSN=prefix.ZIP.C.OBJ(FILEIO)
//              DD  DISP=SHR,DSN=prefix.ZIP.C.OBJ(GLOBALS)
//              DD  DISP=SHR,DSN=prefix.ZIP.C.OBJ(UTIL)
//              DD  DISP=SHR,DSN=prefix.ZIP.C.OBJ(CRC32)
//              DD  DISP=SHR,DSN=prefix.ZIP.C.OBJ(CRCTAB)
//              DD  DISP=SHR,DSN=prefix.ZIP.C.OBJ(ZIPFILE)
//              DD  DISP=SHR,DSN=prefix.ZIP.C.OBJ(ZIPUP)
//              DD  DISP=SHR,DSN=prefix.ZIP.C.OBJ(MVS)
//              DD  DISP=SHR,DSN=prefix.ZIP.C.OBJ(CMSMVS)
//LKED.SYSLIB   DD  DISP=SHR,DSN=CEE.SCEELKED
//SYSUT1   DD  UNIT=SYSDA,SPACE=(CYL,(2,2))
//

Sample JCL to zip the mainframe .C and .H files as ASCII (-a).  Delete
any existing archive first, point the temporary file at a particular
prefix (-b), use 'prefix.ARCHIVE.ZIP' for the archive file, read the
list of files to zip from stdin (SYSIN).

//DELETE  EXEC PGM=IDCAMS
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  *
 DELETE prefix.ARCHIVE.ZIP
 SET MAXCC = 0
//ZIP     EXEC PGM=ZIP,
// PARM='/-a -v -b temppref ''prefix.ARCHIVE.ZIP'' -@'
//STEPLIB  DD  DSN=prefix.ZIP.LOAD,DISP=SHR
//SYSPRINT DD  SYSOUT=*
//SYSOUT   DD  SYSOUT=*
//CEEDUMP  DD  SYSOUT=*
//ZIPC     DD  DISP=SHR,DSN=prefix.ZIP.C
//ZIPH     DD  DISP=SHR,DSN=prefix.ZIP.H
//SYSIN    DD  *
dd:zipc(api)
dd:zipc(cms)
dd:zipc(cmsmvs)
dd:zipc(crctab)
dd:zipc(crc32)
dd:zipc(crypt)
dd:zipc(deflate)
dd:zipc(fileio)
dd:zipc(globals)
dd:zipc(mktime)
dd:zipc(mvs)
dd:zipc(trees)
dd:zipc(ttyio)
dd:zipc(util)
dd:zipc(zip)
dd:zipc(zipcloak)
dd:zipc(zipfile)
dd:zipc(zipnote)
dd:zipc(zipsplit)
dd:zipc(zipup)
dd:ziph(api)
dd:ziph(cmsmvs)
dd:ziph(crypt)
dd:ziph(cstat)
dd:ziph(ebcdic)
dd:ziph(mvs)
dd:ziph(revision)
dd:ziph(stat)
dd:ziph(tailor)
dd:ziph(ttyio)
dd:ziph(zip)
dd:ziph(ziperr)
dd:ziph(zipup)