FAQs - IBM i

The current version of PK Encrypt and PKZIP is V17.  The latest Smartcrypt version is is V16.1.0E and the current version of SecureZIP for IBM i is v14.  For recent Smartcrypt features, take a look at the new PK Protect family of security products.  PK Encrypt for i provides all the same features as Smartcrypt and SecureZIP.

The latest version of PK Protect for i / PKZIP for i5 / OS runs on V7.1 and higher. 

Note

Running PKWARE software on OS V7.4 will require PK Protect or  PKZIP version 16.1.0B or higher.

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.

You can download a fully functional copy of our i5 / OS products from our website: PK Protect for i or PKZIP for z/OS.  Versions of Smartcrypt for i5 / OS and SecureZIP for i5 / OS can still be accessed.  PKWARE products are now available only via digital download.

Please contact PKWARE at 1.937.847.2374 or contact our sales department with any questions pertaining to a machines processor classification and / or if you would like to receive a price quotation.

The current i5 / OS products updates can be found here.

Add SecureZIP to your library list and then enter the following command: CALL WHATOSV

Yes. PKWARE first introduced the support of iASP into PKZIP 8.1.0 in April of 2005.

With the incorporation of ZIP64 technology, PKZIP Enterprise Edition v10 or higher and SecureZIP for i5 / OS v10 or higher offer 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).

PKZIP Enterprise Edition v9 and SecureZIP for i5 / OS v10.x offer an increased ZIP archive capacity, raised from 65,535 to a theoretical limit of over 4 billion files.

Yes, you can rename your library. First, you will need to remove all PKWARE Product libraries from the library list. After doing this, go ahead and rename the object or the library. Please make sure that theres only one PKZIP / SecureZIP library in the library list, which should be the library you want to rename. After adding the new library to the library list, enter the following command: CALL PKZSETLIB newlibrary By entering this command, you associate all PKZIP / SecureZIP objects with the new library name.

Since the archive is created according to the ZIP APPNOTE specifications, the archive is cross-platform compatible. The archive file is a stream file and when transporting the archive it MUST be move in binary mode without any translations. One common method is to utilize the FTP services of the platforms, but if the archive file is in a sharable IFS folder, then the file may directly accessible from a mapped drive on Windows. If the files being compressed on the i / OS are text files and the date is stored on the i / OS in EBCDIC format the data should be compressed using the FILETYPE(*TEXT) so the EBCDIC data will translate to an ASCII format.

Smartcrypt /PKZIP / SecureZIP only reads and writes directly to objects of type FILE, with attributes PF-SRC, PF-DTA, SAVF, SPLF, IFS Streamfiles (*STMF), and IFS directories (*DIR). Other objects such as logical files, *PGM, *MODULE, or *CMD may be compressed via a save file or by utilizing PKZIPs iPSRA (PKZIP Save Restore Application).

The i5 / OS PKWARE Save / Restore Application (iPSRA) feature enables PKZIP / Smartcrypt / SecureZIP to compress / encrypt iSeries save files directly to a file in an archive. The process produces a result similar to creating a save file first and then compressing and / or encrypting it into an archive, but the iPSRA feature economizes on time and disk space by skipping the intermediate step. For additional information regarding iPSRA functionality, please contact PKWARE Technical Support at 1.937.847.2687.

The default for PKZIP MSGTYPE is *BOTH. This means that you will have to hit ENTER to end the terminal session. To change this, insert the parameter MSGTYPE(*SEND), and this will omit the terminal session prompting.

This is not a failure of Smartcrypt / PKZIP / SecureZIP. In this scenario, all of PKWARE products on Windows, z / OS, i5 / OS, and UNIX / Linux (just as an example) will decompress this same file without a problem. There are only two possible resolutions to this issue: Create the archive in the IFS where it is a real stream file. When an archive is built in a QSYS file it may contain unused bytes at the end since it is a file with fixed record length. 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 DB File System if you opt to create the archive within QSYS.

Yes, the PF38 file type is supported in v5.6 and higher.

PKZIP v10 or higher Enterprise Edition and SecureZIP v10 or higher have the ability to create self-extracting archives.Additionally, SecureZIP v10 or higher offers: large archive support on specified releases of AIX, HP / UX, LINUX, Sun Solaris or Windows; a GUI option for Windows desktop; and, self-extraction support for strongly encrypted archives. For licensing and distribution requirements, please contact your PKWARE account representative at 1.937.847.2374 or via email at pkcustomerservice@pkware.com

Either the IFS directory and file may be case sensitive or you might want to specify a forward slash before the QDLS (see the following): Archive Zip File name . . . . . / qdls / pkzfiles / test.zip List Include file or pattern . . / qdls / pkzfiles / testgl The forward slash indicates this is a folder in the IFS, so PKZIP knows it is not in the library.

Yes.

The command below includes the EXDIR and CVTTYPE parameters that you will need to specify to achieve your desired results: PKUNZIP ARCHIVE(PKZ / SSGLTB) TYPE(*EXTRACT) EXDIR(PKZ / TEMP1) CVTTYPE(*DROP) The SSGLTB.TXT file that was within the archive was extracted without the .TXT extension (CVTTYPE parm) and was placed in the library / object that was specified (EXDIR parm).

Use the FILES parameter in the UNZIP command and specify the exact file name that is stored in the archive. Use the TYPE(*VIEW) to display the file names that are stored in the archive.

Use Drop Stored Path *NONE along with the EXDIR library / filename (member too if it applies). This will specify where you want to extract the data to. If you use Drop Stored Path *ALL it says to drop all but the member in EXDIR. PKZIP automatically creates the library and the file and the member. If the library / file / member is specified, the PC cannot use this. If the library / and the member are taken out and just the file name is left, PKZIP automatically creates the library and the file and the member. You can resolve this issue by adding STOREPATH(*NO).

No, the directory and path / folder for the archive must already exist.

We currently do not support the compression and / or decompression of .z and TAR files on the iSeries platform.

If a data base file is being compressed in text mode and has packed data fields, the results are unpredictable for the fields that are packed. Some of the data may also represent internal control characters such as Line Feed, etc. PKZIP / SecureZIP does record processing and does not work in field mode. Also, if the database has signed decimal fields the result may also be unpredictable since the decimal sign byte is not represented correctly when translated to ASCII. But in this case if the data in these fields are not important, at least the bytes can be predictable for use in some application.

Double-byte characters are not currently supported. APW spool files are also not supported because they are double-byte characters that is what makes it an APW spool file and not a regular spool file.

SITE: bigiron.pkware.com USER ID: ftp_support PASSWORD: PKW!PKW (Case Sensitive) After logging on to our FTP site, you will need to change your current directory to USUPPORT (CD USUPPORT). If you are transferring an archive to us, make sure to specify BINARY before performing your Put statement. After you have FTPd all relevant information, please contact PKWARE Technical Support at 1.937.847.2687 or through our support form.

Yes, you will need a new license when upgrading to a later version number (i.e. v9.x to version 10.x) due to the differences in codes. Please keep in mind that you will not be able to apply your 10.0.x license to a previous version.

PKWARE requires a license report to be sent to our Customer Service department when requesting a new or updated license key. To run a license report, first add SecureZIP to your library list and then enter the following command: CALL WHATOSV Once the job has completed successfully, please copy and paste the resulting output into an email addressed to Customer Service at pkcustomerservice@pkware.com

PKWARE has a 24-hour turnaround 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 turnaround times at 1.937.847.2374 (option 3, then option 1, option 1 again) or via email at pkcustomerservice@pkware.com

This message is caused by a change in your serial number, model, and / or processor group. A grace period typically will last seven days. In order to remove the grace period, you will need to obtain a new license code. Please see the following FAQ on how to run a license report and submit a request for a new authorization code.

After you have received an authorization code, you must update the license input member, your library name / PKZLICIN(PKWARELIC). This can be done by doing the following: First, please make sure that you have the program library added to your library list. Next, enter the following commands: CALL QCMD, press enter (if you are not at the command entry screen) EDTF FILE(your library name / PKZLICIN) MBR(PKWARELIC) This will display the license input member, PKWARELIC. Copy and paste the code provided by your vendor into the PKWARELIC member. Make sure there are no blank records and that the entire key has been entered. Press F3 to save your changes and then press F3 again to exit. Now enter the following command to complete the update on the license file: INSTPKLIC INMBR(PKWARELIC) This command will update the license file with the changes you made to the license input file PKZLICIN. If the output displayed states that the file has been updated successfully, then the authorization code has been applied successfully.

This error is caused by having a spacing problem within the authorization code entered, caused by having the code or each line of the code start off in the wrong column and / or having an extra blank record(s). To resolve the problem you will need to make sure that each record starts in column 13, by highlighting and copying the license key you received from pkcustomerservice@pkware.com and pasting directly into the license file.

This error is caused by version differences between the installed software and the license key (i.e., downloading and installing version 10.0 of SecureZIP, and attempting to apply an existing license key for SecureZIP version 9.0). License key and program versions must be identical.

Input File *LIBL / PKWARELIC(*FIRST) cannot be open for input ZAQ I / O Error:A non-recoverable I / O error occurred. Error found in processing input parameters License file NOT Updated After applying the license, you will want to update the license file, by submitting the following command: INSTPKLIC INMBR(PKWARELIC)

A new build has its own standalone library, which does not refer back to any other build. It is best practice to restore the product to a new library name and not to an active library (this could produce unpredictable results). Once you have thoroughly tested the new PKZIP / SecureZIP build, you may remove your old library from the production environment and just add the new library to the library list. Note: Be sure to have only one PKZIP / SecureZIP library in the library list as multiple versions of PKZIP in the library list may result in unpredictable results.

Example: A decryption attempt was made using only a passphrase when the file had been encrypted with both a passphrase and public-keys. ZPGP014I OpenPGP Code=3405. ID=A6E4EF67F22DF11D could Not unwrap key for this packet with private key provided. 1. These are informational messages that you can consider as logging information. As the explanation for ZPGP014I indicates, User Response: No action is required. 2. 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.

Only binary stream copies of a Key ring are supported. (ASCII ARMOR is not supported). When exporting and transferring keys to IBM i OS, ensure that BINARY mode is used for both.

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.

Password-based encryption is activated by specifying a password in the PASSWORD parameter and the same password in the VPASSWORD parameter. Certificate-based encryption is activated by specifying a recipient string in the ENTPREC parameter, which requires the certificate store be properly set up (Please see Chapter 10 of the SecureZip for i5 / OS Users Guide for instructions on how to set up your certificate store). Please note that certificate-based encryption with RECIPIENTs is only supported by SecureZIP. In addition, this mode of encryption requires that one of the Strong ENCRYPTION METHODS, under the ADVCRYPT Parameter, (minimum 128-bit) be selected.

All IBM i products include standard PKZIP encryption (96-bit). In Smartcrypt / SecureZIP, PKWARE has implemented Advanced Encryption Standard (AES 128, AES 192, AES 256), DES, 3DES, and RC4 algorithms for added security and performance. SecureZIP for i5 / OS Enterprise Edition can encrypt data for security control with digital certificates and / or passwords. SecureZIP for i5 / OS Standard Edition provides strong passphrase-based encryption. Additional security features included are: Selectable encryption methods Filename encryption Password masking Manageable password lengths at the enterprise level (1 to 200 characters) Cipher block chaining when any of the AES algorithms are used Contingency key or master recipient On systems running V5R3 or higher, SecureZIP v10.0.x also has the ability to utilize IBMs cryptographic APIs, which, in some cases, may provide better performance.

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 a technique known as digital enveloping with Public Key Encryption. The technique requires that the creating process have the recipients public key, which is used to protect and store the MSK. In addition, the receiving side must have their recipients private key. With these two pieces of information in place, there is no need for users to retain or recall a password for decryption. Recipient-based encryption / decryption requires public and private keys either encoded according to the x.509 or OpenPGP standards.

Yes, when both RECIPIENT and PASSWORD settings are used to encrypt a file, the master session key is derived from the password and is 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 any user who has been added as a recipient when the archive was encrypted who has his or her private key certificate available.

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 where various types of certificates are kept and accessed. The primary store components or directories in the certificate store used by SecureZIP include: PUBLIC: Directory store that contains individual public-key X.509 certificate files on the local system PRIVATE: Directory store that contains individual private-key X.509 certificate files on the local system CA: Certificate store for certificate authority public-key X.509 certificates on the local system ROOT: Certificate store for the trusted root public-key X.509 certificates on the local system CRL: Certificate store for the certificate revocation lists maintained on the local system CWORKAREA: Directory that contains a work area that is used to administer the local stores INLIST: Directory that contains files providing lists of recipients to be used during the encryption process TESTZIPS: Work area for testing the product. Many of our examples throughout our users guide use this directory

Our recommendation is to have your System Administrator set up the local certificate store, which will help maintain the security of the certificate store and its certificates. The information below is intended for your System Administrator to review: For detailed information on setting up the certificate store, please see Chapter 10 of the Users Guide. You can download the users guide by requesting it.

When using digital certificates to encrypt a ZIP file you will need to include the following parameters to your zip job: ADVCRYPT (AES128 | AES192 | AES256 | DES | 3DES | RC4) Next you will need to specify one or more of the ENTPREC parameters: ENTPREC((*DB cn=Firstname Lastname)) ENTPREC((*DB em= \n pkcustomerservice@pkware.com

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).

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 an authorized key or valid 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 i5 / OS encrypts filenames using your current settings for (strong) encryption method and algorithm.

The PKQRYCDB command can be used to view the contents of the P7B file. To view the contents of the P7B file, type PKQRYCDB and press F4. You should now be at PKQRYCDB menu. For the file type, make sure to specify *P7B. Please see Chapter 10 of the SecureZIP for i5 / OS Users Guide for more details about this command.

There is an option under the PKSTORADM command or prompt menu to add the end entity certificated to your local public store. See the Security Administration guide for details on importing root and intermediate CA certificates.

Adding P7B files to your local stores is done through the PKSTORADM command or prompt menu. We recommend using *DETECT as the preferred store. See the Security Administration guide for details on importing root and intermediate CA certificates.

When naming your stores, we recommend that you choose names that are descriptive of what the store is, or choose names that define what the store is. When exporting public or private certificates, or when adding certificates to your stores, we recommend you specify the year when the certificate is set to expire in the name of the certificate.

The Smartcrypt / PKZIP / SecureZIP for i5 / OS can compress files directly to a tape or virtual tape archive via the 1Step2Tape feature. See parameters TYPARCHFL(*TAP) and PKOVRTAPF. For additional information regarding the 1Step2Tape functionality, please contact PKWARE Technical Support at 1.937.847.2687.

Yes utilizing the 1StepfromTape archive can be read directly from tape or virtual tape. See parameters TYPARCHFL(*TAP) and PKOVRTAPI.

Yes. if the correct full path name is used as the archive file name and the file type is IFS or TYPARCHFL(*IFS).

First, make sure that youre licensed for the Spool Feature. If you are not licensed for this feature, please contact PKWARE at 1.937.847.2374 or contact our sales department. PKZIP v5.5.x and higher releases allow all spool files to be compressed, but only spool file type *SCS will compress to PDF. *IPDS are only supported for text document conversion. As for spool file type *AFPDS, it is only valid for spool file compression and not for any conversion to text or PDF (e.g. SFTARGET(*SPLF) SFTGFILE(*GEN1)).

From a command entry line, type PKZSPOOL and hit PF4, then adjust the various parameters to your needs. Once the spool files are chosen, you will then need to define the file format the spool file will be stored as in the archive. At this time the three formats are *SPLF (Spool File native mode), *TEXT (ASCII text document with three variations of how a new page is handled), and *PDF (Adobe Portable Document Format).