/ / FTPSTEP EXEC PGM=FTP,PARM='bigiron.pkware.com (EXIT'
/ / SYSPRINT DD SYSOUT=*
/ / INPUT DD *
PUT YOUR.FULLY.QUALIFID.DSN CLOSE QUIT
With the incorporation of ZIP64 technology, Smartcrypt / SecureZIP for z / OS offers an increased ZIP Archive size, raised from 4 gigabytes (32 bit binary counter) to a theoretical limit of over 17 billion gigabytes (64 bit binary counter). Large file support functionality is also available in PKZIP for z / OS v9.0 Enterprise Edition.
Smartcrypt / SecureZIP for z / OS offers an increased ZIP Archive capacity, raised from 65,535 to a theoretical limit of over 4 billion files. This increased capacity is also available in PKZIP for z / OS.
Smartcrypt / SecureZIP password-based encryption uses a symmetric implementation of keys, meaning that the same key is required for both encryption and decryption.
SecureZIP requires that the password be specified at both ends so that the internal encryption / decryption key can be derived algorithmically. No form of the password or key is carried in the ZIP Archive.
Two levels of key are derived from the password for processing:
Master Session Key
File Session Key
The process for deriving the keys are as follows:
If running on an EBCDIC-based platform, the password is converted to ASCII (so as to match the same password being entered on an ASCII-based system such as Windows).
The ASCII password is passed to a hashing function to generate a master session key. This key is used to encrypt / decrypt random data that is in turn used to generate a key for the file itself. (The password is not used to directly derive the File Session key for decrypting the data). In addition, a random initial vector (IV) is created for each file for cipher-block chaining, thereby ensuring that two encryption runs for the same data / password combination will result in different cipher streams.
A pseudo-code representation of the encryption process is as follows:
Password = GetUserPassword()
RD = Random()
ERD = Encrypt(RD,DeriveKey(SHA1(Password)))
For Each File
IV = Random()
VData = Random()
FileSessionKey = DeriveKey(SHA1(RD, IV))
Encrypt(VData + VCRC32 + FileData,FileSessionKey)
First, we recommend consulting the Service Support Schedule on the Announcements page to ensure your version of product is supported on the new version of z / OS. If possible, it is recommended going to the most recent versions of Smartcrypt, PKZIP or SecureZIP.
These are actually informational messages designed to assist SecureZip users with identifying if their Hardware Cryptography utility / hardware is active or installed.
For a PKZIP user, this is displayed for you so if you wish to contact Customer Service to upgrade to Smartcrypt / SecureZip from PKZIP, we have all of the information needed to better assist you.
If these messages are showing up as ending in an E (Error) and not an I (Informational), a code change is in place. Version 9 levelset 3 has this correction and is available at our website in our product updates section.
PKZIP for z / OS Enterprise Edition and all editions of Smartcrypt / SecureZIP offer the ability to create self-extracting archives on z System for the Windows and UNIX platforms only. For licensing and distribution requirements please contact your PKWARE account representative at 937.847.2374 or via email at email@example.com .
PKZIP for z / OS includes the Assembler User API which provides a powerful tool for the user to dynamically take control of the format of data to be archived and the target data set names of files to be extracted.
The Two User APIs currently available are Data Record Transformation API for ZIP processing and File Name Manipulation API for UNZIP processing.
Data Record Transformation API for ZIP processing provides a means to restructure a data record before compression takes place. A common use is to transform binary and packed decimal fields into display-format numerics. This is useful when the system intended to receive the ZIP Archive does not easily handle these field formats.
File Name Manipulation API for UNZIP processing provides a means to transform filenames into manageable IBM MVS-compatible data set names. This is useful when specialized re-direction of files is required that surpasses the capabilities of the PKZIP for MVS command set.
Smartcrypt / PKZIP / SecureZIP for z / OS has several uses for temporary files. They are engaged at various times depending on the processing involved and the virtual storage resources available at execution time. Key uses of work files are:
A staged copy of a targeted ZIP archive (this is a permanent file with a temporary name)
Spill data sets to hold compressed data until it is ready for writing to the ZIP Archive.
Temporary files to manage ZIP file selection requests and Archive directory information.
ISPF user-files to hold generated JCL, utility message output and Browse extraction data. The allocation controls for these files are located on the PKZIP for z / OS Configuration screen. Note that large amounts of disk space may be required to Browse or Extract a file under ISPF.
! Note that installations running DFSMS / MVS or an equivalent product may find that file allocation requests made through PKZIP for z / OS result in different file characteristics than those requested. This is because Systems Managed Storage routines active in the system intercept allocation requests and have the ability to alter the location and / or attributes of a data set. Use of PKZIP for z / OS file allocation request parameters must be coordinated with the operating environment's Automatic Class Selection (ACS) routines that are in control at the installation. Check with your Storage Administration or Systems Programming staff for appropriate values (e.g. UNIT, DCB attributes) to be used for temporary files.
According to RFC1952 "GZIP file format specification version 4.3", data within a GZIP file structure may be held in either TEXT or BINARY format:
"If FTEXT is set, the file is probably ASCII text. This is an optional indication, which the compressor may set by checking a small amount of the input data to see whether any non-ASCII characters are present. In case of doubt, FTEXT is cleared, indicating binary data. For systems which have different file formats for ASCII text and binary data, the decompressor can use FTEXT to choose the appropriate format."
PKZIP for z / OS uses the DATA_TYPE command (with options of BINARY, TEXT or DETECT) to govern how input data is to be handled during the compression process. The FTEXT flag is then set accordingly.
Once the GZIP file has been created on z System, FTP transfer the file in BINARY mode to the PC. Once the file resides on the PC, add the .GZ extension so the UNZIP utility will recognize the GZIP format.
The biggest issue to overcome when moving PKZIP images from Test to Production is the high level qualifiers you installed PKZIP with to the Test system. With this in mind, please make sure you perform the necessary steps below to ensure a smooth transition from Test to Prod.
Rename all DSN's to Prod naming scheme. i.e. (DEV.PKZIP.ZOS.HELP to PKZIP.ZOS.HELP)
Re-Assemble the ACZDFLT via the ASMDFLT to reflect the new PROD HLQ. You may need to make some changes to ACZDFLT to reflect the appropriate HLQ's.
Modify the PKZSTART of the INSTLIB to reflect the new Prod. HLQ.
That is it.
You may either provide the command -ARCHIVE_COMMENT( ) in the PKZIP job, or change the ACZDFLT default value for that command (See INSTLIB(ASMDFLT)).
How do I get rid of the need for the INSTLIB? Some installations desire to eliminate any allocation of a PARMLIB or CONFIG dataset through PARMLIB_DSNAME_ZIP and PARMLIB_DSNAME_UNZIP. If no installation-supplied dataset commands are desired, then ACZDFLT parameters may be set to bypass the allocation attempt. Only / / SYSIN DD and EXEC PARM='...' parameters will be processed. Both parameters should be set to avoid dataset allocations in the generation of ACZDFLT.
One of the features of PKZIP for z / OS is to allow a common input file for commands. This is controlled either by a / / PARMLIB DD statement in the job step, or via the ACZDFLT module. As distributed, the ACZDFLT module contains default parameters of PARMLIB_DSNAME_ZIP='PKKZIP.MVS.INSTLIB(CMDZIP)' and PARMLIB_DSNAME_UNZIP='PKZIP.MVS.INSTLIB(CMDUNZIP)'. These members are dynamically allocated for PKZIP and PKUNZIP processing respectively, and contain the commented commands shown above.
You may either edit the members shown above to remove the commented commands, or create a modified ACZDFLT module that points to another dataset member. (See INSTLIB(ASMDFLT))
During EXTRACT processing, PKUNZIP uses MVS Dynamic Allocation Services (SVC99) to look for the target dataset as "old" initially. If MVS dynamic allocation detects that the data set does not exist, then this informational message is issued by the system. PKZIP for z / OS handles this condition and continues by creating the target dataset before continuing.
The command -SUPPRESS_DYNALLOC_MSGS may be used to instruct MVS Dynamic Allocation Services to suppress messages such as these. However, be aware that other dynamic allocation messages may be suppressed as well.
Use the following to suppress these messages.
-SUPPRESS_DYNALLOC_MSGS will suppress the warning message
An Abend S80A is usually caused by insufficient 24-bit ("below the 16-megabyte line") storage in the Region for the job. System I / O functions such as QSAM use this storage area for buffering. If too many buffers are requested (e.g. DCB=BUFNO=nnnn) for a file, and the REGION parameter for the Job Step is too small, then system services may fail. Some adjustments that can be made in an attempt to alleviate the problem are: Try increasing the REGION for the JOB STEP.
If DCB=BUFNO was specified for one or more of the files for performance reasons, consider reducing the BUFNO value. If multi-tasking was requested for the job, consider reducing the number of tasks with the MULTI_THREAD_LIMIT command.
Try modifying the -DATA_TYPE command on the UNZIP side of the equation. If you are using BINARY, try changing this to TEXT.
The -DATA_TYPE(BINARY) command is used to direct PKZIP for z / OS to bypass EBCDIC to ASCII character translation. This feature is useful when the file contains non-text data (such as graphics or internal numeric representations), or if text-based data is to be extracted only to other EBCDIC-based platforms.
All data within a file is treated the same during ZIP processing in accordance with the -DATA_TYPE(TEXT) and -DATA_TYPE(BINARY) commands. Care should be taken when zipping files that may contain both text and binary data. Use of the -DATA_TYPE(TEXT) command when binary data exists within the file will produce unpredictable results for fields containing binary data. -DATA_TYPE(BINARY) should be used to preserve data integrity; however, this means that text data will not be translated to the ASCII format by UNZIP processing in a cross-platform environment.
In a case where neither -DATA_TYPE(TEXT) nor -DATA_TYPE(BINARY) is specified in either the command or installation default module, PKZIP for z / OS will read a portion of data from the input file (in accordance with the -DATATYPE_DETECT_DEPTH value) and scan it for non-translatable text characters using the active text translation table. If the number of translatable text characters (as specified by the -DATATYPE_DETECT_TABLE) meets or exceeds the percentage specified by -DATATYPE_TEXT_PERCENT, the file will be treated as -DATA_TYPE(TEXT). Otherwise, it will be treated as if DATA_TYPE(BINARY) has been used. Note: One exception to this is X'00', or the NULL terminator character, which is commonly used in C language. The NULL character will be allowed within the files. If it is unknown whether a file in the ZIP Archive is text or binary, the user may use the -ACTION(VIEWDETAIL) command to examine the file attributes.
Note: It is possible for members of the same PDS or PDSE to be treated differently when -DATA_TYPE(DETECT) is used because of a varying mix of data. Each member is treated as an independent file during ZIP processing.
SAVE_LRECL(Y) must be specified when compressing BINARY data of variable length. This includes NONVSAM RECFM=U / V files and VSAM ESDS, KSDS and Variable-RRDS files. The record length information of each record is required for PKUNZIP to properly restore each record.
Unpredictable results may occur during EXTRACT processing if SAVE_LRECL(N) is specified (e.g. data records streamed across output record boundaries, VSAM PUT failures, scrambled data with unexpected keys in VSAM KSDS files).
VSAM note: The RECORDSIZE parameter is commonly misunderstood. RECORDSIZE(80 80) in a Cluster definition does not accurately reflect whether all records in a Cluster are fixed in length.
The first RECORDSIZE parameter is used during an Access Method Services Define Cluster or Import to compute the amount of space to be used (when RECORDS is used in the DEFINE). The second RECORDSIZE parameter is used during Record I / O and limits the size of an output record. Any record size between 1 and 80 may be put to the file (with the exception of a fixed RRDS).
This is not a failure of PKZIP for z / OS. In this scenario, PKZIP for DOS, WinZip, PKZIP for i5 / OS, and PKZIP for Unix (just as an example) will decompress the same file without a problem. There are only two possible resolutions to this issue:
Create the archive with a RECFM of Variable or Undefined file type.
Ask the makers of the Java ZIP utility to add some tolerance to their ZIP utility like other ZIP developers have done.
With both resolutions, the resulting output ZIP file will not have trailing characters. We are at the mercy of other file types within the 390 environment, where padding the last record out will always occur.
When using ARCHIVE_RECFM=FB for Archives intended for off-system transport (via FTP or other electronic means), ARCHIVE_LRECL should also be tuned. The default for ARCHIVE_RECFM=U, which writes exactly the number of bytes required for the Archive. By changing to ARCHIVE_RECFM=FB, the defaults for ARCHIVE_LRECL ARCHIVE_BLKSIZE will still be half-track blocking (27998 on 3390 DASD). By leaving the defaults for these parameters alone, the operating system will write a complete record / block combination (rounded to 27998), resulting in dead space at the end of the archive; increasing transmission time and storage space on the target system. It is recommended that ARCHIVE_LRECL be set to a smaller size (ARCHIVE_BLKSIZE will automatically be set by PKZIP for MVS to match half-track blocking for a given LRECL). This allows the last block of the Archive to be a short block (as governed by QSAM in the operating system) thereby reducing wasted space.
The shortening of the ARCHIVE_LRECL must be balanced with the overhead associated with QSAM managing multiple records per block. A good start would be as follows:
When using ARCHIVE_RECFM=FB for Archives intended for off-system transport (via FTP or other electronic means), ARCHIVE_LRECL should also be tuned.
The default is ARCHIVE_RECFM=U, which writes exactly the number of bytes required for the Archive. By changing to ARCHIVE_RECFM=FB, the defaults for ARCHIVE_LRECL ARCHIVE_BLKSIZE will still be half-track blocking (27998 on 3390 DASD). By leaving the defaults for these parameters alone, the operating system will write a complete record / block combination (rounded to 27998), resulting in dead space at the end of the archive; increasing transmission time and storage space on the target system.
It is recommended that ARCHIVE_LRECL be set to a smaller size (ARCHIVE_BLKSIZE will automatically be set by PKZIP for z / OS to match half-track blocking for a given LRECL). This allows the last block of the Archive to be a short block (as governed by QSAM in the operating system) thereby reducing wasted space. The shortening of the ARCHIVE_LRECL must be balanced with the overhead associated with QSAM managing multiple records per block. A good start would be as follows:
The DST change will not affect our z / OS products.
The following file formats may be used to house an OpenPGP Key Ring:
RECFM=FB (Sequential or PDS)
RECFM=VB (Sequential or PDS)
RECFM=U (Sequential only)
Unix File System (Sequential binary stream without FileFmt=NL)
Only binary stream copies of a Key ring are supported. (ASCII ARMOR is not supported).
When exporting and transferring keys to z / OS, ensure that BINARY mode is used for both.
Example: A decryption attempt was made using only a passphrase when the file had been encrypted with both a passphrase and public-keys.
ZPGP017I encrypted with Key
ZPGP014I PGP ERRCode=3390. unwrapKey ID=A6E4EF67F22DF11D No Store Provided for
unwrapPublic-Key Encrypted Session Key
ZPGP018I File was encrypted using AES128 Algorithm for Packet Type 18
ZPAM031I ZIPFORMAT=OpenPGP UNIT=3390 BLKSIZE= 27998
ZPEX001I tested okay SEG / BASE82 / ALLOC
These are informational messages that you can consider as logging information. As the explanation for ZPGP014I indicates, "User Response: No action is required.
The ZPGP014I explanation says that they are to be used by PKWARE Tech Support to assist in diagnostics for unresolved issues. Since there is not an unresolved issue (the archive opened with the password), the information may be ignored.
Tip! - The OpenPGP file format has multiple key definitions that precede the encrypted file data. These are vetted as they are encountered in the file stream. In this case, the ZPGP014I is issued to let us know that the public-key packet could not be used in the decryption process should it be required later in the work flow.
In general, any media or file format supported for a ZIP archive is also supported for an input OpenPGP file.
Some processing restrictions apply based on the OpenPGP file architecture. For example:
The directory information is not independently accessible from the data portion of the OpenPGP file.
If encrypted, a decryption key is required to perform a View of the filename and related metadata stored in the OpenPGP Literal Tag
ARCHIVE_FASTSEEK processing used to locate the ZIP Central Directory does not apply. Decryption and Inflation are required to access the filename and other metadata.
Inasmuch as the OpenPGP file format does not retain file data sizes (compressed or uncompressed), in order for a VIEW request to report on file size information, the entire data file must be decrypted and decompressed for byte counts to be accumulated.
The OpenPGP file format does not support the retention of file attributes as ZIP archives do. So, allocation amounts and DCB attributes cannot be retained for use during extraction.
When creating an OpenPGP file with either Passphrase or Public-key encryption, contingency keys may be configured to be included for decipherment by a set of installation-defined keys that are supplemental to those directly requested by the user.
Define a read-accessible OpenPGP Key Ring file (keyring-file) containing the public keys to be used as contingency keys.
Configure PARMLIB_DSNAME_ZIP with a definition that references the key ring:
Configure the defaults module setting MASTER_RECIPIENT to reference the keys to be used as contingency keys. A form of the setting may be chosen such that multiple, or specific keys be included from the key ring.
Yes, the installation and maintenance procedures have been simplified. View the README in the installation package for information on this change.
V 15.0.1 includes a new command SELECT_LIBRARY_NONPDS to designate whether a requested data set mask should include non-partitioned data sets in the selection process.
INSTLIB(LPACOPY) contains a module identification list for modules which are marked as RENT and are appropriate for LPA use. This list should be referenced for the specific release and maintenance level as this list may change over time. Most applicable modules are 31-bit residency mode and impact Extended LPA rather than 24-bit LPA. Review the residency mode attributes if 24-bit LPA is constrained in your operating environment.
This is a result of the new command in v15 for utilizing zEDC or zIIP hardware. There are three options, suppress the return code, turn off use of the ZEDC / ZIIP option, or authorize the services. The first two options are coded in the ACZDFLT member to cover all jobs, or can be included in specific jobs only.
To suppress the return code (message will still display in the sysprint)
Add the -PKSUPPR=ZPCM123W statement
To turn off the message return code entirely (disables the use of ZEDC / ZIIP hardware)
Add the -FACILITY_COMPRESS=PKZIP statement
Either will address the RC=04 that may cause an issue.
However, if you wish to use either zIIP or zEDC hardware that would entail the following configuration tasks to be completed / verified for zIIP / zEDC workload redirection to be attempted:
Provide APF authorization to PKZIP / SecureZIP in one of two ways:
The System Administrator#rsquo;s guide covers APF Authorization, reference the section on Enabling zIIP Processing or Enabling zEDC Processing.
APF authorize the execution library (or libraries) from which Smartcrypt / PKZIP / SecureZIP will execute.
Install and activate the PKWSVC authorizing the services.
Smartcrypt / SecureZIP Enterprise Edition customers can use the KeyMaker program to convert an OpenPGP key to the X.509 Digital Certificate format before importing into RACF. Some OpenPGP keys may not have expiration dates. When the key is converted to X.509 format, an expiration date is required. KeyMaker will default to setting an expiration date value to one year past the date the OpenPGP key was created. This may result in a converted key having an expiration date in the past. To avoid this issue, use the -expire option to KeyMaker to set an alternate expiration date when converting to X.509 format.
Smartcrypt / SecureZIP Enterprise Edition customers can use the KeyMaker program to convert an OpenPGP key to the X.509 Digital Certificate format before importing into RACF. OpenPGP keys use a different trust model than X.509 keys. When the key is converted to X.509 format, a trusted ROOT is not provided with a trust period of longer than 1 day and the converted key will not be trusted when imported to RACF. To address this issue the key should be explicitly marked as trusted within RACF.
Using the XML_VIEW command available in V15.0.6 produces XML formatted output.
When performing high volume operations such as may occur when using Field Level Encryption, you can remove some overhead that exists due to SAF calls performed for each cryptographic operation. You can disable SAF checks using an available patch from IBM for ICSF version HCR77A1. Information on this patch is available at https: / / www-03.ibm.com / support / techdocs / atsmastr.nsf / WebIndex / FLASH10818. Refer to the section labeled OWH / RNG Authorization Access.
OpenPGP technology includes both a file format and an encryption specification. PKZIP will open "unencrypted" OpenPGP files and OpenPGP files that are signed but not encrypted. PKZIP SE will not allow creating or opening OpenPGP files that use encryption.