JapanPlease read through the following Frequently Asked Questions (FAQs) for answers to common questions. FAQs are updated on a regular basis so return often if needed.
Don’t see what you’re looking for? Contact PKWARE® Tech Support
online or call +1.937.847.2687 (8am - 5pm CT)
What is the most current version of SecureZIP® for z/OS®?
SecureZIP® for z/OS® version 10
2. What is the most current version of PKZIP® for z/OS?
PKZIP® for z/OS version 9
3. Does SecureZIP perform data compression and/or decompression like PKZIP?
SecureZIP for z/OS offers all of the same features and functionality found in our PKZIP product lines. SecureZIP simply adds the ability to secure the data being stored or compressed within the ZIP file. PKZIP Enterprise Edition users can decrypt and decompress any passphrase-encrypted archive created by SecureZIP, even if a strong encryption algorithm (AES128, AES256, etc.) was used to encrypt the data.
4. On what OS versions does PKZIP/SecureZIP for z/OS run?
PKZIP and SecureZIP for z/OS run on all releases of z/OS supported by IBM.
5. Our license expired, but we never received the 5-day grace period. Instead, we received RACF or ACF2 errors and an update error message. Why?
The first PKZIP/PKUNZIP® job that is run on an unlicensed system (typically due to a CPU upgrade/downgrade or expired license) must be submitted by a user with write authority to the PKWARE license dataset to invoke the grace period.
This authority is only required the first time PKZIP/PKUNZIP is run on the unlicensed system; it is not required after the grace period has been successfully invoked (this is one time per CPU, not one time per IPL).
During the grace period, error messages will be displayed on the console (and the printout) for each execution of PKZIP/SecureZIP for z/OS. At the end of the period, if the license is not updated, the product will no longer function except to VIEW an archive. The five-day grace period is designed so that the program will not cease to function on a weekend or the Monday following the five-day grace period. You must contact PKWARE at
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
during the grace period to obtain licensing to allow extended use.
6. Is PKZIP/SecureZIP for z/OS cross platform compatible?
A ZIP archive can be transferred from one platform to another, and can be decompressed or modified by a copy of PKZIP or PKUNZIP which is running on that platform. The internal format of a ZIP archive is identical no matter which platform compressed the files that it contains. To ensure compatibility, ZIP archives must be created by PKZIP 2.50 running on MS-DOS or PKZIP version 5 or higher on other platforms.
If you wish to transfer data across platforms using any other version of PKZIP or SecureZIP you should check with your supplier first to confirm that your versions of PKZIP/SecureZIP are compatible. Please also note that the PKZIP DCL products are not compatible with the PKZIP 2.50 for MS-DOS or PKZIP/SecureZIP version 8 products.
7. Where can I find patches, PTF's, or fixes for PKZIP/SecureZIP® for z/OS?
The best place to obtain patches for SecureZIP® for z/OS is in our updates section.
8. How can I tell which version of PKZIP/SecureZIP® for z/OS I am running?
Simply run a ZIP or UNZIP job and the version and level (LVL) will appear in a ZPLI001I message. Such as:
ZPLI001I SecureZIP(R) for z/OS, Version 10.0.0 - 09/27/07 11.21 LVL(0)
ZPLI001I PKZIP(R) for z/OS, Version 9.0.0b - 05/04/07 14.31 LVL(7)
9. Do I need a new license to use PKZIP® for z/OS v9.x or SecureZIP® for z/OS 10.x?
Yes, you will need a new license when upgrading from one version to another (i.e. version 5.6.0b to version 9.0.0) due to the differences in codes. Please keep in mind that you will not be able to apply your 9.x license to a 5.x or 8.x product.
Additionally, if you are going from PKZIP to SecureZIP v10, or vice versa, a new key is required, even if the version number remains the same.
To request a key please contact
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
.
10. What do I need to do to get an Authorization Code?
PKWARE requires a license report be sent to our Customer Service Department when requesting a new or updated license key.
To run a license report you must edit and submit the LICSHSYS member located under the *.INSTLIB dataset.
Once the job has completed successfully please copy and paste the resulting output into an email addressed to Customer Service at
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
11. How long does it take to receive an Authorization Code?
PKWARE has a 24 hour turn-around policy for returning authorization codes. There are exceptions to this policy (i.e. production is down, no jobs can run, etc.).
Contact Customer Service for appropriate turn around times at 937.847.2374, option 3, or via email at
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
12. When I apply my authorization code, I am getting an "Invalid Input Control Record" message. PKZIP for z/OS v9.0 and SecureZIP for z/OS v10.0 license keys use a different logic than the previous PKZIP/SecureZIP v5.x and v8.x license keys. You will want to verify that the version of the key matches the version of the product the key it is being applied to.
If you do see that the versions do not match, then please contact Customer Service to receive a new license key for the appropriate version of the product you are using. You can contact Customer Service via Email, or by phone at 937-847-2374 and selecting option 3.
If the version does not seem to be the problem, another thing to verify is to begin all lines of the Zap in column two. Be sure all letters, spaces, commas, periods, etc… are aligned exactly how the email shows them to be. If you continue to experience problems, please call PKWARE Technical Support at 937.847.2687 or submit your request online.
Additionally, if the LICUPDAT is being run on a 2086, 2094, or 2096 the problem could be due to the type. Changes were made to these types that affected our license logic. These changes were addressed in a fix.
To see if you have this fix, please browse the .SPKZCLIB and look at the ‘CHANGED’ date of the RUMULIC.
If you have any questions regarding the steps needed to apply the latest levelset, please feel free to contact Technical Support at 937.847.2687.
13. We need to extract data from an application and secure it before distributing to customers. Is there a way to complete this task without having to write the unencrypted, sensitive data to disk prior to compressing and encrypting?
PKWARE offers Application Integration and z/OS UNIX File System Support integration features in SecureZIP® for z/OS v10. With this new functionality, SecureZIP essentially takes a multi-step job and reduces the numbers of steps from 3 or more down to 1. This new functionality takes advantage of the Application Integration feature to create compressed and encrypted .zip files before they are staged to disk; and with the new support for z/OS UNIX File System Support, the encrypted data can be written directly on a remote UNIX mount or partition without having to be staged on the mainframe disk first. For additional information regarding PKWARE’s Application Integration solution, please contact the PKWARE Support team at 937-847-2687.
14. Is it possible to compress and/or encrypt HFS, or zFS files using SecureZIP for z/OS?
SecureZIP for z/OS v10 has a new feature called z/OS UNIX File System Support that allows direct access with HFS and zFS files on z/OS.
Prior to SecureZIP for z/OS v10:
Data from outside the organization is FTP'ed to a UNIX server in the DMZ. The data needs to be processed by an application on the mainframe, and the mainframe has a NFS mount point through HFS to the FTP server in the DMZ. An IEBGENER job runs to copy the data from HFS to z/OS. Once the encrypted ZIP archive is on z/OS, SecureZIP decrypts the archive and the mainframe application can now process the data.
Using SecureZIP for z/OS v10:
Data from outside the organization is FTP'ed to a UNIX server in the DMZ. SecureZIP decrypts the archive, reading it in directly from the UNIX FTP Server, allowing the mainframe application to now process the data. Once the application is done, the processed file needs to be sent back to the partner, so SecureZIP encrypts the data directly to the FTP server through HFS, where it can be FTP'ed back to the partner.
15. I forgot the password for my .zip file(s). What do I do?
PKWARE solutions utilize strong encryption so there is nothing that can be done if you lose or forget your password. It is important to remember your password as PKWARE has no special means for "getting around" the encryption and may not be able to assist in the recovery of an encrypted file.
16. How do I activate encryption?
Encryption is activated through the use of the -PASSWORD and/or -RECIPIENT commands. If a value is present for either setting, whether through commands or default settings, then encryption will be attempted in accordance with other settings (such as -ENCRYPTION_METHOD).
However, if ENCRYPTION_METHOD=NONE is specified, then encryption will be bypassed.
Please note that certificate-based encryption with RECIPIENTs requires that one of the Strong ENCRYPTION_METHODs (minimum 128-bit) be selected.
BSAFE_AES128 - A SecureZIP implementation of the AES 128-bit key algorithm, including cipher-block-chaining and block padding. When recipient-based encryption is requested, this is the default encryption method unless the installation defaults module has been tailored differently.
17. What types of encryption are available in SecureZIP for z/OS?
SecureZIP for z/OS can encrypt data for security control with digital certificates and/or passwords. In addition to standard PKZIP encryption (96-bit), PKWARE has implemented RSA's BSAFE Advanced Encryption Standard (AES), DES, 3DES and RC4 algorithms for added security and performance. Additional security features included are:
• Selectable encryption methods
• Filename Encryption
• Password masking
• Increased maximum password length (up to 200 characters)
• ISPF dialog password field blanking
• Cipher Block Chaining when any of the AES algorithms are used
• An enhanced key protection option
18. How do I password encrypt a ZIP file using SecureZIP for z/OS?
When creating ZIP file you will need to include the following in the JCL:
-PASSWORD(password)
-ENCRYPTION_METHOD (Standard | AES128 | AES192 | AES256 | DES | 3DES | RC4).
• STANDARD supports standard encryption and is the default value.
• AES128 uses the Crypto-C AES 128-bit key algorithm.
• AES192 uses the Crypto-C AES 192-bit key algorithm.
• AES256 uses the Crypto-C AES 256-bit key algorithm.
• DES uses the Crypto-C DES key algorithm.
• 3DES uses the Crypto-C 3DES key algorithm.
• RC4 uses the Crypto-C RC4 key algorithm.
19. How does recipient-based encryption differ from password?
Password-based encryption depends on both the sender and receiver knowing, and providing intellectual input (the password) in clear text. The password is used to derive a binary Master Session Key for each decryption run. No key information is kept within the ZIP Archive, therefore both parties must retain the password in an external location.
Recipient-based encryption provides a means by which the Master Session Key (MSK) information can be hidden, protected, and carried within the ZIP Archive. This is done by using technique known as Digital Enveloping with Public Key Encryption. The technique requires that the creating process have a copy of the recipient's Public Key Digital Certificate, which is used to protect and store the MSK. In addition, the receiving side must have a copy of the recipient's Private Key Digital Certificate. With these two pieces of information in place, there is no need for users to retain or recall a password for decryption.
20. What types of digital certificates are required for encryption/decryption?
Recipient-based encryption/decryption requires Public and Private key certificates kept in file streams encoded according to the x.509 standard.
21. What is a Digital Certificate Store?
Recipient-based encryption requires that public and private key certificates be used by SecureZIP. These are kept in file streams encoded according to the X.509 standard. A certificate store is the location of where various types of certificates are kept and accessed. The primary store components used by SecureZIP include:
• CSPUB: Certificate store for individual public-key X.509 certificates on the local system.
• CSPRVT: Certificate store for individual private-key X.509 certificates on the local system.
• CSPUB_DBX: VSAM index structure for the public-key X.509 certificates on the local system
• CSPUB_DBX_PATH_CN: VSAM index structure allowing the common name search and selection of public/private-key X.509 certificates on the local system.
• CSPUB_DBX_PATH_EM: VSAM index structure allowing the email search and selection of public/private-key X.509 certificates on the local system.
• CSPUB_DBX_PATH_PUBKEY: VSAM index structure allowing the identification of public/private-key X.509 certificates on the local system.
• CSCA: Certificate store for Certificate Authority public-key X.509 certificates on the local system.
• CSROOT: Certificate store for the Trusted Root public-key X.509 certificates on the local system.
• CSCRL: Certificate store for the certificate revocation lists maintained on the local system.
• LDAP: Certificate store for individual public-key X.509 certificates accessible via a TCPIP network.
22. How do I create a Local Certificate Store on the mainframe?
You must first create and prime a local certificate store on the mainframe. You do so by properly configuring the PKISPF and PKZSTART members of the INSTLIB dataset, then following these steps ...
1. Execute PKZSTART
2. Type A at the option line for the Administration Panel,
3. Type CS at the option line for the Certificate Store Panel,
4. Select option 1 for "Local Certificate Store Administration."
5. Type CREATE at the option line and complete the required files for HLQ, the New Database
Profile and page down to add any specific SMS/non-SMS allocation parameters that may be
needed.
6. When prompted, select to enable/disable the various security policy settings
7. Review and submit the JCL that is created.
8. Check for a Return Code of zero
9. A new database profile should have been created and set as your "Active DB Profile"
10. To verify proper setup choose option 8, then option 2 to run the Certificate Store IVP.
11. Distribute the DB Profile location to all appropriate users with the proper syntax (e.g. -
INCLUDE_CMD(YOUR.ACTIVE.DB(PROFILE))
Please note that SecureZIP™ for z/OS ships with four x.509 test key pairs (PKWARE Test1, PKWARE Test2, PKWARE Test3 and PKWARE Test4).
Only PKWARE Test3 and PKWARE Test4 have the trusted chain included (ROOT and INTERMEDIATE CA).
23. How do I add a digital certificate to my Local Certificate Store?
Upon a successful export of the digital certificate from the Certificate Authority Tool (e.g. Windows Internet Explorer | Tools | Options | Content | Certificates) you must perform a BINARY transfer of the certificate to the mainframe, storing the cert in a sequential file or as a member of a PDS.
From the SecureZIP Local Certificate Store Administration Menu perform the following steps...
0. Select option 3 "Add new Certificates to the Local Store"
1. Enter the certificate PDS/file location (e.g. 'PKZIP.PUBLIC.CERT')
2. Assign a custom member name if desired (e.g. PKT2005)
3. Confirmation will appear in the top right corner of the screen saying the key was either added
of failed (e.g. PKT2005 ADDED)
Please note when entering a PRIVATE key you must enter the password in order to add the PRIVATE key to the Local Store.
24. How do I use a digital certificate to encrypt a ZIP file using SecureZIP for z/OS?
When using a digital certificate to encrypt a ZIP file you will need to include the following three parameters in the SecureZIP command stream:
-INCLUDE_CMD(YOUR.SECZIP.DATABASE(PROFILE)
-ENCRYPTION_METHOD (AES128 | AES192 | AES256 | DES | 3DES | RC4)
-RECIPIENT (DB:CN=Common Name,R)
Please note that additional RECIPIENT options include searching for digital certificates stored on a LDAP server or in specific datasets on System z.
For additional details on implementing digital certificate encryption into the job stream please refer to Chapter 6 of the SecureZIP for zOS User's Guide.
25. When extracting an encrypted ZIP file how do I know what algorithm was used?
SecureZIP will automatically detect which encryption method was specified during the ZIP process and operate accordingly. A -VIEWDETAIL run can be performed to see which algorithms were used for various files.
26. Can both recipient-based and password encryption be used together?
Yes, when both RECIPIENT and PASSWORD settings are used, to encrypt a file, the Master Session Key is derived from the Password and also protected by using Public Key Encryption.
This means that a ZIP file may be decrypted either by a user who knows the password, or who has their private key certificate available.
27. How many recipients can be specified?
The ZIP File format specification allows for a maximum recipient list size of 3,275. This can be restricted further by other file attributes associated with the data, and by run-time capacity limitations (such as virtual storage). (Note: Approximately 20 bytes is required for each recipient within the ZIP archive central directory record for each file. This area is limited to 64K in size).
28. What are the virtual storage (REGION size) requirements to run certificate-based encryption?
When using recipient-based encryption, plan on an initial increase of 4MB of 31-bit storage for up to 15 recipients. LDAP will require an additional 1MB for every 27 recipients above 15. File-based and local certificate store will require an additional 1MB for every 41 recipients above 15.
Some SecureZIP operations require additional virtual storage to operate successfully. In particular, activation of certificate-based operations (for example, recipient-based encryption and digital signature operations) may necessitate increasing the 31-bit region size. It is recommended that the user evaluate the virtual storage used by a SecureZIP step in relation to the number of digital certificates used for a particular process and establish an appropriate REGION size.
29. What other ways can SecureZIP for z/OS locate public keys needed to encrypt data for recipients?
SecureZIP for z/OS can locate a recipients' public-key certificates stored on your company's LDAP-compliant directories through the Directory Integration Module. This approach allows for recipient selection based on common name, email address, or other installation-configured LDAP fields. One or more LDAP-compliant servers may be configured for searching.
Your company's technical support staff responsible for configuring the LDAP compliant directory that stores certificates can provide you with the necessary information for the LDAP profile. For proper LDAP configuration please refer to Chapter 4 of the "SecureZIP™ for zOS System Administrators Guide."
To inquire about the Directory Integration Module, please contact your PKWARE account representative, or email sales at
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
30. How do we activate a MASTER_RECIPIENT or "contingency recipient"?
To meet corporate security policies, SecureZIP provides the ability to include a "contingency-key" or master recipient certificate in a SecureZIP job when strong encryption is activated through the MASTER_RECIPIENT setting.
The MASTER_RECIPIENT may be set directly in the defaults module, or indirectly by specifying MASTER_RECIPIENT in a command stream referenced by SECUREZIP_CONFIG. This default-module-only setting specifies a PDS[E] member that contains SecureZIP certificate store configuration commands to be automatically included in the processing stream. The configuration command values from this member will be included at the start of command input processing prior to //SYSIN statements being read. The data set(member) will be converted into an "INCLUDE_CMD=(pds[e](member)" command internally and will be echoed to the message log in accordance with the ECHO setting.
SecureZIP certificate store configuration commands entered from other sources such as //SYSIN will override the values read in from this source. This ensures the organization will always be able to extract and/or decrypt the secured archive/data using the "global" private key certificate.
31. How does MASTER_RECIPIENT affect activation?
When SecureZIP is being used to encrypt data, either with RECIPIENT or PASSWORD, a recipient specified by MASTER_RECIPIENT is automatically included. However, -MASTER_RECIPIENT alone does not trigger encryption to take place.
32. What is Filename Encryption?
Someone who cannot decrypt the contents of an archive may still be able to infer sensitive information just from the unencrypted names of files. To prevent this, you can encrypt the names of files in addition to their contents.
Encrypted file names can be viewed in the clear-that is, unencrypted-only when the archive is opened by a recipient holding the authorizing keys or password, if the archive was encrypted using a recipient list, or by someone who has the password, if the archive was encrypted using a password.
SecureZIP for z/OS encrypts filenames using your current settings for (strong) encryption method and algorithm.
33. How do I FTP dumps to your site?
//
//FTPSTEP EXEC PGM=FTP,PARM='bigiron.pkware.com (EXIT'
//SYSPRINT DD SYSOUT=*
//INPUT DD *
FTP_SUPPORT
PKW!PKW
CWD USUPPORT
BINARY
PUT YOUR.FULLY.QUALIFID.DSN CLOSE QUIT
//
34. Does SecureZIP for z/OS support archives greater than 4GB?
With the incorporation of ZIP64 technology, 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.
35. What is the archive capacity with SecureZIP for z/OS?
SecureZIP for z/OS v10.x 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 v9.0 Enterpriese Edition.
36. How is the encryption/decryption key built when using password-based encryption?
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:
0. Master Session Key
1. File Session Key
The process for deriving the keys are as follows:
2. 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).
3. 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)
37. I am upgrading to a z/OS 1.7 or 1.8. Are there any special considerations that need to be made?
When running PKZIP on z/OS v1.7/1.8, it is always recommend going to the most recent versions of either PKZIP or SecureZIP.
The reason for the the recommendation to be at these levels is because there has been one issue reported to us regarding z/OS v1.7 and v1.8 in an earlier levelset of version 5.6. The latest levelset of PKZIP 5.6 incorporates this fix. All levelsets of version PKZIP/SecureZIP 9.0 and 8.2 have this fix.
Here is the information on this issue reported to us:
********************************* Top of Data ***********************
Subject: TT2273 0C4 in zOS 1.7 UCB Lookup
Reference: 30179
Releases: 560+
Symptoms: zOS 1.7 UCB lookup changed, causing 0C4 ABEND
Comments: Replaced SHOWMVS code with MVS SCANUCB macro ******************************** Bottom of Data ********************************
This was fixed in refresh 22.
If you would like to know whether or not you have this fix, you could run a simple zip or unzip job and do a find for ZPLI. In our PKZIP splash screen you should find a date of Sept 05 or more recent:
ZPLI001I PKZIP for zSeries, Data Compression, Version 5.6.0b - 09/08/05 15.
If you do not have this fix and you are running 5.6 and you want to upgrade you can find the most recent levelset in our product updates section.
If you would by chance like to install version 9.0, this can be obtained from our downloads section.
38. Is PKZIP for MVS version 5.0.x or 5.5.x compatible with the z990 (machine type 2084) hardware?
PKZIP for MVS v5.0.x and 5.5.x are not supported on the z990 2084 system, z890 2086 system, or the z9 BC/EC systems. If you are upgrading your hardware to one of these systems then you must upgrade to PKZIP for z/OS v9.0. PKZIP for z/OS v9.0 includes the logic capable of handling the additional three digits associated with the 'make and model' of the z990, z860 and z9 systems.
39. New item: I am getting ICSF messages in my job. These appear to be error messages, but the job completes successfully. Is this something I need to be concerned about?
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 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.
40. Using PKZIP for zSeries 5.6, I get the following error when extracting a PDS file. ZPEX011E Error opening Archive for PDS extraction.
Set -ARCHIVE_FASTSEEK=N or -TASK=1 in your ACZDFLT and then submitting the ASMDLF to re-assemble the defaults will correct this issue.
41. Using PKZIP for z/OS 9.0, I am receiving this ZPLI902W ZIP64 LARGE FILE SUPPORT FEATURE WARNING -CPU NOT LICENSED GRACE USED 01 DAY(S) message.
Customers with a Standard Edition License will receive this message because the default for -ARCHIVE_FASTSEEK is Y. This will cause a request for ZIP64 which is not part of the Standard License. In order to avoid this, the customer should change the ACZDFLT module to specify ARCHIVE_FASTSEEK=N prior to running any PKZIP/PKUNZIP jobs.
Once the change to the INSTLIB(ACZDFLT) is done, please edit and submit the INSTLIB(ASMDFLT) to assemble the change.
Any Standard Edition license customer interested in upgrading to the Enterprise Edition to be licensed for large file support should contact their account rep. or call PKWARE Sales at 937.847.2374 and select option 1.
42. We upgraded from PKZIP for MVS v5.0.x to v9.x, and our compression percentage is lower with the newer release. Why?
The 5.0 product used COMPRESSION_LEVEL(NORMAL) as a default.
The 9.x product uses a COMPRESSION_LEVEL(SUPERFAST) as a default, which does not compress as much as the NORMAL level, but runs faster.
To increase the compression percentage you can test the change by adding -COMPRESSION_LEVEL(NORMAL) to your JCL (Please refer to the "PKZIP for zOS User's Guide" for compression level options).
When you have found a level you are satisfied with, you can change the defaults in your hlq.INSTLIB(ACZDFLT) member as COMPRESSION_LEVEL=NORMAL and then re-assemble the ACZDFLT by submitting the ASMDFLT job.
43. Does PKZIP have the ability to create self-extracting EXE/SFX archives on System z?
PKZIP for z/OS Enterprise Edition and all editions of SecureZIP offer the ability to create self-extracting archives on System z 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
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
.
44. What is the Assembler User API in PKZIP/SecureZIP for z/OS?
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.
45. How are work files used?
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.
46. How is GZIP TEXT and BINARY data selection done?
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.
47. What do I need to do to make a GZIP file created on System z extractable on a PC?
Once the GZIP file has been created on System z, 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.
48. What changes do I need to make when I move PKZIP from my test environment over to
Production?
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.
49. How do I prevent the ARCHIVE_COMMENT "PKZIP/SecureZIP for z/OS by PKWARE" from being created.
You may either provide the command -ARCHIVE_COMMENT( ) in the PKZIP job, or change the ACZDFLT default value for that command (See INSTLIB(ASMDFLT)).
50. I do not want to put the INSTLIB into my production environment, however, the CMDZIP and the CMDUNZIP PARMLIB statements prevent me from doing this.
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. MCZDFLTS TYPE=CSECT,
LICENSE_HLQ=pkzip.mvs,
PARMLIB_DSNAME_ZIP=NULLFILE,
PARMLIB_DSNAME_UNZIP=NULLFILE,
51. How do I remove "* COMMON PKUNZIP COMMANDS CAN BE PULLED IN THROUGH THE PARMLIB_DSNAME_UNZIP SPECIFICATION IN THE DEFAULTS MODULE." from the SYSPRINT output of the job?
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))
52. Why does EXTRACT processing issue message: "IKJ56228I DATA SET data_set_name NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED"?
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
53. What causes S80A Abends?
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.
54. I am transferring a file from UNIX to System z and the file is not converting correctly. The
data looks the same as it did on UNIX and does not appear to be doing the ASCII-->EBCDIC conversion. Is there a special command I should be using?
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.
55. When compressing or ZIP'ing VSAM files and specifying -BINARY or DATA_TYPE (BINARY), please read the following:
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).
56. When I try to decompress a ZIP file created by PKZIP/SecureZIP for z/OS using JAVA Class ZIP utility, I get a Stack-Trace, and the program ends.
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.
57. If I set the archive record format to fixed block, and the archive is intended for off-system transport, what else is required?
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:
-ARCHIVE_RECFM=FB -ARCHIVE_LRECL=1024
58. What's the proper way to create Fixed-Block Archives with PKZIP/SecureZIP for z/OS?
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:
-ARCHIVE_RECFM=FB
-ARCHIVE_LRECL=1024
59. How will the change in Daylight Savings Time (DST) impact PKWARE software for z/OS?
The DST change will not affect our z/OS products.