PKZIP MVS 2.61
Downloading patches
Alternatively, you can download all level 1 patches (this is a self extracting file, which must be run before use) in a single job. To confirm that all the available patches have been installed on your system download the verify job (this is a self extracting file, which must be run before use).
Patch 001
Error Description
The Short-Term License utility (ZIPPSTL) generates a
license update that is not applicable to this level of PKZIP for MVS.
With this patch
applied, the utility will generate a correct license update.
Corrective Action
For users with level 1, the following patches should be applied to ZIPPSTL and ZIPPATCH modules.
//PKZAP EXECPGM=AMASPZAP,PARM=IGNIDRFULL
//SYSLIB DDDISP=SHR,DSN=<PKZIP
2.6 level 1 load library>
//SYSPRINT DD
SYSOUT=*
//SYSIN DD *
NAME ZIPPSTL
XXXPSTL
VERIFY 0966 F4F0
REP 0966
F2F6
NAME ZIPPATCH PATCHTAB
VERIFY 0001
40
REP 0001 E8
CHECKSUM
14B727E6
/*
Issued
January
2001
Patch 002
Error Description
This patch note corrects three problems and adds support for suppressing the return code from message 796:
UNZIP090W Potential Storage overwrite detected at:…,
Header:STOR0046RGZPCONV, …
This patch note documents the messages relating to ARCHTEMPSUFFIX. It corrects the Storage problem by correctly setting the “extra field length” when the attributes in the archive are not useful to PKZIP for MVS. It corrects the NIA problem by correctly setting the length for the compare used when finding matching parts of the NIA name – this length can be set incorrectly when the processing tries to match wild cards in the output name. It also allows the message 796 to be suppressed.
Corrective Action
The messages documented below should be added to the
Messages and Codes Manual.
The following patch should be applied to the
PKZIP, PKUNZIP, ZFSZDF00, ZIPATASK, ZIPBTASK and ZIPPATCH modules.
//PKZAP EXECPGM=AMASPZAP,PARM=IGNIDRFULL
//SYSLIB DDDISP=SHR,DSN=<PKZIP
2.6 level 1 load library>
//SYSPRINT DD
SYSOUT=*
//SYSIN DD *
NAME ZFSZDF00
NIAS000
VERIFY 0276 41E0,000E
REP 0276
58E0,D1A8
NAME PKZIP ZIPSERV
VERIFY 01DC
5010,D07C
VERIFY 02B4 0000,0000
VERIFY 02B8
0000,0000
VERIFY 02BC 0000
VERIFY 02BE
0000,0000
VERIFY 02C2 0000,0000
VERIFY 02C6
0000,0000
VERIFY 02CA 0000,0000
REP 01DC
47F0,C2B4
REP 02B4
5010,D07C
REP 02B8
58E1,0000
REP 02BC
18FE
REP 02BE
54F0,C338
REP 02C2
BAEF,1000
REP 02C6
4740,C2B8
REP 02CA 47F0,C1E0
NAME PKUNZIP
ZIPSERV
VERIFY 01DC 5010,D07C
VERIFY 02B4
0000,0000
VERIFY 02B8 0000,0000
VERIFY 02BC
0000
VERIFY 02BE 0000,0000
VERIFY 02C2
0000,0000
VERIFY 02C6 0000,0000
VERIFY 02CA
0000,0000
REP 01DC
47F0,C2B4
REP 02B4
5010,D07C
REP 02B8
58E1,0000
REP 02BC
18FE
REP 02BE
54F0,C338
REP 02C2
BAEF,1000
REP 02C6
4740,C2B8
REP 02CA 47F0,C1E0
NAME ZIPATASK
RGZPCONV
VERIFY 033C 4780,C3D4
VERIFY 0368
47F0,C3D4
VERIFY 039E 4780,C3D4
REP 033C
4780,C3D8
REP 0368
47F0,C3D8
REP 039E 4780,C3D8
NAME ZIPBTASK
RGZPCONV
VERIFY 033C 4780,C3D4
VERIFY 0368
47F0,C3D4
VERIFY 039E 4780,C3D4
REP 033C
4780,C3D8
REP 0368
47F0,C3D8
REP 039E 4780,C3D8
NAME ZIPMS
ZIPMS
VERIFY 38BC 0000,0026,0004
REP 38BC
0001,0026,0004
NAME ZIPPATCH PATCHTAB
VERIFY 0002
40
REP 0002 E8
CHECKSUM E8DBAD5F
Messages
New Messages
These messages should be added to the Messages and Codes Manual.
373 Severity: Warning
Message Text: "APPEND"
specified for ARCHTEMPSUFFIX is not valid for PDS/PDSE archive datasets,
"REPLACE" used.
Explanation: The ARCHTEMPSUFFIX
command has been used with the APPEND option, which is not valid when creating a
member. REPLACE has been substituted.
Action: Change the input command to specify
REPLACE (or let it default). Alternatively use a different type of file
(such as a sequential file) for the archive.
374 Severity: Error
Message Text: Final Archive
name and temporary Archive name must be different, both are:<file
name>.
Explanation: The values used or defaulted
for the ARCHTEMPSUFFIX command mean that the temporary Archive dataset has the
same name (<file name>) as the final archive. In this situation, the
temporary Archive could overwrite the real one, so processing is
terminated.
Action: Correct the input
ARCHTEMPSUFFIX command to ensure that the temporary name is different to the
final name.
875 Severity: Warning (Suppressible)
Message Text: Archive name
has been truncated for use with "new" archive, to: <archive file name
'prefix'>.
Explanation: The values used or
defaulted for the ARCHTEMPSUFFIX command mean that the temporary Archive dataset
name is too long (greater than 44 characters). The name used is
constructed by shortening the dataset name to give <archive file name
'prefix'>, then adding the appropriate suffix.
Action: In most cases, processing will continue
with the shortened name and this dataset will be renamed to the final name on
completion of the processing. Correct the input ARCHTEMPSUFFIX command to ensure
that the temporary name is not too long in the future.
Note however that in some situations, the generated file name may cause a number of problems with installation specified facilities, for example, with SMS and Security processing where these expect specific dataset names. In these cases, a shorter suffix, the use of the REPLACE option or a change to the Archive file name may be required to meet the installation requirements.
Updated Message
The following message should be updated in the Messages and Codes Manual - note that the only change is the addition of the word 'Suppressible' on the Severity line.
796 Severity: Warning (Suppressible)
Message Text: Record(s) in
file have been truncated.
Explanation: The record
length of the output file is shorter than the length of one or more records in
the archive. The records that exceeded the output record length have been
truncated.
Action: Ensure that the record length of
the output file is the desired length. Note that this length could be specified
in a variety of places including the file itself (if it already existed) and the
OUTLRL command.
Issued
February 2001.
Patch 003
Error Description
This patch resolves the following issues with PKZIP for MVS:
The documentation updates are described later in this patch note.
The problem only occurs when processing the last record in a block for a variable length file (which is the only record for a variable length file that is not blocked – and note that the last record in the file is also at the end of a block). The processing assumes that this last record will contain at least 1 byte of user data (in addition to the RDW associated with the record). If this record is a null record (i.e. has a length of 0), ZIP processing will ignore the record.
With this patch applied, ZIP will not ignore the null record at the end of the block.
Corrective Action
The following patches should be applied to ZFHRGEN and ZIPPATCH modules.
//PKZAP EXECPGM=AMASPZAP,PARM=IGNIDRFULL
//SYSLIB DDDISP=SHR,DSN=<PKZIP
2.6 level 1 load library>
//SYSPRINT DD
SYSOUT=*
//SYSIN DD *
NAME ZFHRGEN
CRED000
VERIFY 0266 47B0,C28A
REP 0266
4720,C28A
NAME ZFHRGEN TRNS000
VERIFY 01B2
18F4,06F0
VERIFY 0352 0000
VERIFY 0354
0000,0000
VERIFY 0358 0000
VERIFY 035A
0000,0000
REP 01B2
47F0,C352
REP 0352
12F4
REP 0354
47D0,C1D0
REP 0358
06F0
REP 035A 47F0,C1B6
NAME ZIPPATCH
PATCHTAB
VERIFY 0003 40
REP 0003
E8
CHECKSUM 7E98546A
/*
Manual Updates
Chapters in the following manuals are added or updated as a result of this patch:
In Chapter
7 Processing PDS Members of Using PKZIP for MVS, the following note should
be added to both the Supported PDS files and Selection using a DD
sections.
Note:
Note:
Note:
Note:
Issued
March 2001
Patch 004
Error Description
This patch resolves a problem when compressing a Variable length file, which contains null (0 length) records using Delimiters (i.e. –TEXT has been specified or PKZIP has detected that the file requires EBCDIC to ASCII conversion and a –DELIM value has been specified or defaulted). When doing this, PKZIP may do one or both of the following:
The problem only occurs when processing a null record
coincides with the end of an internal storage block. The null record is
moved into the internal block with an incorrect length, which overwrites
following storage. If this storage is not in use by PKZIP, an S0C4 will
occur immediately. If the storage is used by PKZIP, then the ZIP090W
message will be output later in the processing, when PKZIP checks its internal
storage chains.
With this patch applied, PKZIP will use the correct length when moving a
delimited null record.
Corrective Action
The following patches should be applied to ZFHRGEN and ZIPPATCH modules.
//PKZAP EXECPGM=AMASPZAP,PARM=IGNIDRFULL
//SYSLIB DDDISP=SHR,DSN=<PKZIP 2.6 level 1 load library>
//SYSPRINT DD
SYSOUT=*
//SYSIN DD *
NAME ZFHRGEN
READ000
VERIFY 0760 18F9,18E5
VERIFY 078E 1869
VERIFY
089E 0000
VERIFY 08A0 0000
VERIFY 08A2
0000,0000
VERIFY 08A6 0000,0000
REP 0760
47F0,C89E
REP 089E
18F9
REP 08A0 12E5
REP
08A2 4720,C764
REP 08A6 47F0,C78E
NAME
ZIPPATCH PATCHTAB
VERIFY 0004 40
REP 0004
E8
CHECKSUM B7668D97
/*
Issued
March
2001
Patch 005
Error
Description
This patch resolves the following issues with
PKZIP and PKUNZIP processing:
Non PKZIP related Storage
Leaks
As noted in the User Manual, PKZIP for MVS attempts
to recover the storage associated with its processing to ensure that it can be
called repeatedly via the API without ‘leaking’ storage. In most cases,
especially when it completes with a Return Code of 0, this is achieved for
storage that is specifically acquired by PKZIP.
However there is some
storage that appears to be acquired for PKZIP processing by the Operating
System, using Subpools and Storage Protect Keys that are not directly used by
PKZIP. This storage is not freed at PKZIP termination. There does
not seem to be a large amount of storage involved - typically less 512 bytes
below the 16 MB line and 4 kilobytes above the 16 MB line for each file
processed. However this ‘leakage’ might be enough to restrict the number
of calls that can be made to PKZIP within one Job Step if there are other
constraints on Storage, or the process using the API is also a significant user
of Storage.
Users planning to invoke PKZIP or PKUNZIP processing via
the API a significant number of times (more than 100 times) should verify that
there is sufficient virtual storage available to complete the required
processing.
HLQ Upper Case
Conversion
In PKZIP versions prior to PKZIP V2.5, the HLQ
command was processed in a slightly different way (see Documented Changes for
PKZIP 2.5/1). As a result of this, HLQ commands specified in lower case
may no longer work in the same way, especially if the lower case content is used
as the <ZIP file hlq> (see Reference Manual).
To ensure
compatibility with these levels, this patch converts the HLQ command to upper
case.
However this will also mean that HLQ commands used for current
PKZIP 2.6/1 users that are in lower case will be converted to upper case, and
may now be used. Users with HLQ commands that have lower case content
should check that these are specified correctly.
Manual Update
Chapter
in the following manual is updated as a result of this patch:
Patch 006
Error Description
In some previous releases, it was possible to specify the Archive name in any
case (upper, lower or mixed) and this would be accepted by PKUNZIP. In
this release, without this patch, a lower or mixed case name would cause
DYNALLOC messages similar to the following:
UNZIP901E Unable to allocate file
<file name>, DYNALLOC error code 035C0002
UNZIP945E Unable to select
file <file name>, DYNALLOC error code 035C0002.
With this patch,
the processing will use an upper case version of the archive name rather than
the name as input. This upper case conversion will also be done for PKZIP
processing.
Corrective Action
The following patches should be applied to the ZIPPTASK and ZIPPATCH modules.
//PKZAP
EXECPGM=AMASPZAP,PARM=IGNIDRFULL
//SYSLIB DDDISP=SHR,DSN=<PKZIP
2.6 level 1 load library>
//SYSPRINT DD
SYSOUT=*
//SYSIN DD *
NAME ZIPPTASK
PC011200
VERIFY 00E8 4163,5000
REP 00E8
416B,5000
NAME ZIPPATCH PATCHTAB
VERIFY 0006
40
REP 0006 E8
CHECKSUM
9941D24B
/*
Issued
August 2001.
Patch 007
Error Description
When a truncated GZIP archive is processed by PKUNZIP, it is possible for the
processing to go into a loop, repeatedly adding the same character at the end of
the output file.
This loop is a result of the incorrect setting of the
End of File flag.
This patch corrects the setting and outputs a
message when this condition is detected. The message number 408 is reused
for this message, so that its explanation is updated to reflect the possibility
that it can also mean a truncated GZIP file.
Corrective Action
The message documented below should be updated in the Messages and Codes
Manual.
The following patch should be applied to the ZIPDTSKG and ZIPPATCH
modules.
//PKZAP
EXECPGM=AMASPZAP,PARM=IGNIDRFULL
//SYSLIB DDDISP=SHR,DSN=<PKZIP
2.6 level 1 load library>
//SYSPRINT DD
SYSOUT=*
//SYSIN DD *
NAME ZIPDTSKG
WASTEBIT
VERIFY 00C8 D203,D07C,C214
VERIFY 00CE
47F0,C180
VERIFY 01A6 0000,0000
VERIFY 01AA
0000,0000
VERIFY 01AE 0000,0000
VERIFY 01B2
0000,0000
VERIFY 01B6 0000
VERIFY 01B8
0000,0000
REP 00C8
D203,D078,C214
REP 00CE
47F0,C1A6
REP 01A6
4110,D050
REP 01AA
41F0,0198
REP 01AE
50F0,1000
REP 01B2
58F0,2138
REP 01B6
05EF
REP 01B8 47F0,C180
NAME ZIPPATCH
PATCHTAB
VERIFY 0007 40
REP 0007
E8
CHECKSUM 38A24242
/*
Messages
Updated Message: The following message should be updated in the Messages and Codes Manual.
408 Severity: Error
Message Text: GZIP archive file has an invalid
format for a GZIP file.
Explanation: PKZIP has determined that the GZIP
archive is not correctly formatted. Typically this will be caused by one
of the following:
a) corruption within a GZIP header for the GZIP archive
specified, or
b) truncation of the GZIP archive.
Action: Ensure that the
correct archive has been specified and that PKZIP has access to it. If the file
has been transferred from another platform please check that it was transferred
as binary. A valid GZIP archive starts with the hex value x’1F8B’ therefore
browsing the archive in hex can provide a quick visual check that the transfer
was successful. Also ensure that the whole archive has been transferred,
by comparing file sizes.
Issued
September 2001.
Patch 008
Error Description
This problem can cause Excessive Storage usage when using CACHEMEMORY, potentially resulting in Abend U0008.
This problem will typically only be seen when compressing many small ‘files’ (e.g. PDS or PDSE with many members).
An incorrect setting (and testing) of the CACHEMEMORY limit within PKZIP and PKUNZIP processing causes the problem. As a result, more storage than was specified may be used, meaning the cache could eventually use all the storage in the region.
This patch corrects the setting and testing of the CACHEMEMORY limit. See later for some additional information on the setting of CACHEMEMORY.
Corrective Action
The following patch should be applied to the PKZIP, ZFHRGEN, ZIPTTASK and ZIPPATCH modules.
//PKZAP EXEC PGM=AMASPZAP,PARM=IGNIDRFULL
//SYSLIB DD DISP=SHR,DSN=<PKZIP 2.6 level 1 load library>
//SYSPRINT DD SYSOUT=*
//SYSIN DD
*
NAME PKZIP COMPRESS
VERIFY 010C 5850,921C
VERIFY
09E0 5850,921C
REP 010C
5850,9224
REP 09E0 5850,9224
NAME ZFHRGEN
SIZE000
VERIFY 02D6 D203,1008,521C
REP 02D6
D203,1008,5224
NAME ZFHRGEN SZVS000
VERIFY 0304
D203,1008,521C
REP 0304 D203,1008,5224
NAME
ZIPTTASK CACHCRTE
VERIFY 04AA 5040,B008
VERIFY 05E0
0000
VERIFY 05E2 0000,0000
VERIFY 05E6
0000,0000
VERIFY 05EA 0000
VERIFY 05EC
0000,0000
VERIFY 05F0 0000,0000
VERIFY 05F4
0000,0000
VERIFY 05F8 0000,0000
REP 04AA
47F0,C5E0
REP 05E0
18F4
REP 05E2
5BF0,B008
REP 05E6
5800,2328
REP 05EA
1AF0
REP 05EC
BA0F,2328
REP 05F0
4740,C5E0
REP 05F4
5040,B008
REP 05F8 47F0,C4AE
NAME ZIPTTASK
CACHCNST
VERIFY 018C D703,B020,B020
VERIFY 019E
5850,C330
VERIFY 02AC 0000,0000
VERIFY 02B0
0000,0000
VERIFY 02B4 0000
VERIFY 02B6
0000,0000
VERIFY 02BA 0000,0000
VERIFY 02BE
0000,0000
VERIFY 02C2 0000,0000
VERIFY 02C6
0000,0000,0000
VERIFY 02CC 0000,0000
VERIFY 02D0
0000,0000
VERIFY 02D4 0000
VERIFY 02D6
0000,0000
VERIFY 02DA 0000,0000
VERIFY 02DE
0000
VERIFY 02E0 0000,0000
VERIFY 02E4
0000,0000
VERIFY 02E8 0000,0000
VERIFY 02EC
0000,0000
VERIFY 02F0 0000,0000
VERIFY 02F4
0000,0000
VERIFY 02F8 0000,0000
VERIFY 02FC
0000
VERIFY 02FE 0000,0000
VERIFY 0302
0000,0000
REP 018C
D70B,B020,B020
REP 019E
47F0,C2B0
REP 02AC
0000,00C8
REP 02B0
5850,B004
REP 02B4
1255
REP 02B6
4770,C2C2
REP 02BA
5850,C330
REP 02BE
47F0,C1A2
REP 02C2
58F0,2004
REP 02C6
D503,2328,F21C
REP 02CC
47D0,C2BA
REP 02D0
4110,C2AC
REP 02D4
1BFF
REP 02D6
4100,0091
REP 02DA
8900,0018
REP 02DE
0A2F
REP 02E0
5810,232C
REP 02E4
4110,1001
REP 02E8
5010,232C
REP 02EC
5810,B028
REP 02F0
4110,1001
REP 02F4
5010,B028
REP 02F8
8810,0004
REP 02FC
1211
REP 02FE
4780,C2C2
REP 0302 47F0,C2BA
NAME ZIPTTASK
CACHDSTR
VERIFY 01C2 5890,B024
VERIFY 029C
0000,0000
VERIFY 02A0 0000
VERIFY 02A2
0000,0000
VERIFY 02A6 0000,0000
VERIFY 02AA
0000,0000
VERIFY 02AE 0000,0000
VERIFY 02B2
0000,0000
REP 01C2
47F0,C29C
REP 029C
58F0,2328
REP 02A0
180F
REP 02A2
5B00,B008
REP 02A6
BAF0,2328
REP 02AA
4740,C29C
REP 02AE
5890,B024
REP 02B2 47F0,C1C6
NAME ZIPPATCH
PATCHTAB
VERIFY 0008 40
REP 0008
E8
/*
Notes for setting CACHEMEMORY
With this change, PKZIP processing will respect the
CACHEMEMORY limits. Prior to this change, it was possible that more
CACHEMEMORY than specified was allocated and this might have benefited
performance. If CACHEMEMORY has been allocated according to the rules
given in the Using manual, and summarised below, this patch should not affect
performance. If however less storage than recommended has been allocated,
then implementing this fix may slow down the ZIP compression. In light of
this, all CAHCEMEMORY settings should be reviewed.
The following
paragraphs are from Chapter 13. Performance, of the Using Manual.
PKZIP divides the CACHEMEMORY equally between the compression tasks and the
archive. If the amount of memory allocated to one of these processes (e.g.
one compression task) is not sufficient to hold the data, then the excess data
is spilled to a temporary file, on a Least Recently Used basis. When
allocating cache memory, it is important to ensure that the CACHEMEMORY amount
divided by (the TASKS value + 2) is large enough to hold the compressed data,
otherwise much of the value of cache memory is lost. For example, if the
compressed file was 1,000,000 bytes, then the appropriate command is
?CACHEMEMORY(3000000).
Assuming that CACHEMEMORY is big enough to hold
the data, then the use of CACHEMEMORY can result in a 50% plus reduction in the
number of I/Os (EXCPs) and a small reduction in the CPU used to write/reread
these. BUT, instead of writing this data to disk, the processing keeps it
in memory, which means that memory usage will increase. Whether this is an
issue for an installation will depend on the availability of memory on the
executing system. If memory is short then this could increase paging and
the gain in the I/O reduction could be lost in the additional paging.
Assuming there is sufficient storage, then elapsed time should decrease because
of the reduction in I/Os.
Issued
October 2001.