Fixes are also available for the following older TCP/IP service levels:
TCP/IP 1.5 A
TCP/IP 1.5 C
TCP/IP 1.5 D
TCP/IP 1.5 E
TCP/IP 1.5 F Fixes for TCP/IP Release 1.5 Service Pack E
Symptoms,
Sorted by Issue Date
Symptoms,
Sorted by Component
Fix Descriptions,
Sorted by Number
Download a file
with all fixesCarefully examine each fix for applicability before using it.
Fixes Sorted By Issue Date (Newest to Oldest):
Fixes Sorted By Component:
All Fixes by Issue Number:
Fix Symptom/Description Issue Date IBM APAR
ZP15E101 Storage depleted by excessive queued SEND requests The BSD/C API with SOCKOPT BSDCFG1=$OPTSNWT permits multiple SEND requests to be queued without waiting for an acknowledgement from the remote host. Once a predetermined amount of data has been queued, the sender is notified that the queue is "full" and a WAIT is issued to allow buffers to be reclaimed.
The test to determine that a maximum queued data condition has been reached is never satisfied. This can permit a very active application to queue SEND data far in excess of the intended limit, eventually depleting all partition GETVIS.
This fix corrects the test and allows the BSD/C API to properly pace SEND requests.
2006/11/21 Importance: Medium Risk: Medium
ZP15E102 Abend in IPNL3172 driver phase during initialization If you include a DEFINE LINK for TYPE=3172 (or any TYPE that equates to "3172") but do NOT include any DEFINE ADAPTER commands, then the driver attempts to locate and start any/all adapters on the device.
The problem occurs when a register containing a control block pointer is incorrectly modified.
This fix restores the register to its correct value.
Adding appropriate DEFINE ADAPTER commands will also prevent this abend.
2006/11/17 Importance: Low Risk: Low
ZP15E103 Not specific. An error causes invalid results for double-word ADD operations. This causes invalid statistics to be generated and can also cause erratic behavior of TCP connections and other unspecified problems.
In general, errors will not be seen until one of the added terms exceed 2**32. However, as many TCP-related values have initial values >> 0, connections may become unstable long before 2**32 bytes are transferred.
This fix corrects the problem and should be applied by all customers as soon as possible.
2006/11/21 Importance: Critical Risk: Medium
ZP15E104 TCP connection fails to complete. When a FIN is initiated from the remote host, a corresponding FIN is generated and transmitted. If a SOCKET CLOSE is then queued, the FIN's sequence number is incremented and assigned to the CLOSE. Since this sequence can never be ACKed, the CLOSE is not posted complete.
This fix prevents the sequence number from being increased beyond the actual FIN value.
2006/12/03 Superseded by: ZP15E122
ZP15E106 Error in DBCS translation. Data is being dropped and/or inserted in DBCS strings.
This fix corrects the problem.
2006/12/13 Importance: High Risk: Low
ZP15E107 Lost or dropped connections over a 3172, OSA, or OSA2 adapter following the timed-clear of the ARP table. Usually accompanied by an IPT317I message. If a retransmission occurs due to the failure of ARP processing, additional ARP processing on the connection may fail. This will cause the connection to terminate with an IPT317I message.
This fix reinitializes the ARP counter prior to each retransmission attempt.
Issuing the ARPDELETE OFF command will also prevent this failure.
2006/12/19 Superseded by: ZP15E122
ZP15E109 Connections that are "lost" prior to the first outbound transmittal are not detected. The faulty connection "hangs". The probing mechanism ("pulse") used by the stack involves retransmitting the last acknowledged byte. The protocol requires the remote host to discard the byte and restate the high ACK value. If an ACK is not forthcoming, standard retransmission logic comes into play and a "dead" connection is detected and closed.
When there is no data byte to retransmit (ie, we are at the start of the connection), the probe packet (pulse) is inhibitted since some other stacks object to a retransmitted byte that occupies the SYN's position.
This fix eliminates the retransmitted data byte and sends a null packet instead (which still requires an ACK restatement). It also permits a probe to be sent prior to any data transmission. If the retransmitted byte matches the sequence number of the initial SYN, then the SYN flag is set in the datagram.
2007/01/17 Superseded by: ZP15E122
ZP15E110 Resets issued against incoming TCP datagrams to non-existent connections sometimes have an incorrect TCP header length. This may also cause an incorrect checksum to be generated. This fix causes the "reset" datagram to always have a header length of 20 bytes.
2007/01/19 Importance: Low Risk: Low
ZP15E111 Automation software doesn't see complete console message Console messages are processed to multiple destinations by a common routine. Since each destination can have a different length line, a parser attempts to permit breaks only to occur at a blank.
This behavior currently limits the console line length to 65 characters. Since automation products frequently rely on reading and interpretting console messages, splitting a message into two segments may cause difficulties.
This optional fix increases the console line length to 125, its maximum permitted value.
This fix must NOT be applied if you are running under a VSE release earlier than VSE/ESA 2.3.
2007/01/26 Importance: Optional Risk: Medium
ZP15E112 User ID information not passed to Security Exit The DEFINE USER command permits specification of a data string, file system root, UID, and GID values. If the password specified for the User ID is not matched, these values are not passed to the security exit.
This fix causes the User ID-related fields to be passed to the security exit regardless of password validity. The exit --which is the final authority on password validation-- will then always have access to the User ID fields.
Additionally, a new field, SXVALID1, will now indicate the functions that are valid for the user ID.
2007/02/09 Importance: Medium Risk: Low Co-Requisite: ZP15E113
ZP15E113 Additional fields mapped by SXBLOK macro Application of fix ZP15E112 provides the Security Exit with two additional bytes of information. These bytes indicate the type of requests that are permitted for a specific user.
Mapping for these additional fields, along with the values contained in the fields, are included in this replacement for the SXBLOK macro.
The new mapping overlays a previously-reserved area. Therefore, unless the new fields are to be used by your Security Exit, there is no need to update the SXBLOK macro nor reassemble your Security Exit
2007/02/09 Importance: Optional Risk: Low Co-Requisite: ZP15E112
ZP15E114 OSA 2 link driver does not recover after displaying IPL463I (STOPLAN) Upgrades to the OSA2 hardware have resulted in better recovery from some overrun and network problems. Unfortunately updated documentation was not available when the OSA 2 link driver was produced.
This fix is a replacement phase for the OSA2 driver (IPNLOSA2). This new phase correctly deals with a STOPLAN that is generated by the device when its input buffer is overrun.
In most cases, the recovery will now be automatic and nearly instantaneous.
Notes:
- When the device is overrun, an unknown number of datagrams will be lost. This is the correct procedure according to the IP RFC. Protocols that require reliability (eg, TCP) automatically provide for retransmission of "lost" datagrams.
2007/03/01 Importance: Medium Risk: Medium
ZP15E115 OSA 2 link driver does not recover after displaying IPL463I (STOPLAN) Upgrades to the OSA2 hardware have resulted in better recovery from some overrun and network problems. Unfortunately updated documentation was not available when the OSA 2 link driver was produced.
This fix is a replacement phase for the OSA2 driver (IPNLOSA2). This new phase correctly deals with a STOPLAN that is generated by the device when its input buffer is overrun.
In most cases, the recovery will now be automatic and nearly instantaneous.
Notes:
- When the device is overrun, an unknown number of datagrams will be lost. This is the correct procedure according to the IP RFC. Protocols that require reliability (eg, TCP) automatically provide for retransmission of "lost" datagrams.
- Be sure also to apply ZP15E116.
2007/03/01 Importance: Medium Risk: Medium Co-Requisite: ZP15E116
ZP15E116 IPN166E ...Program Abend, Phase: IPNET ... Offset: 0225AC after applying ZP15E115 Following replacement of IPNLOSA2 by fix ZP15E115, the first two bytes of an IBBLOK may be overlaid while the adapter is in STOPLAN mode. When the the adapter enters STARTLAN mode, a previously overlaid IBBLOK fails a validity check, causing the program check abend.
This fix changes register usage to prevent the overlay.
Notes:
- This fix should be applied IMMEDIATELY if ZP15E115 has already been applied.
2007/03/05 Importance: High Risk: Low Pre-Requisite: ZP15E115
ZP15E117 Can't link TN3270 LUname to IP address A Control call, GETHOSTBYLUNAME has been added to enable the mapping of a TN3270 session back to the IP address of the client.
The added call works similarly to GETHOSTBYNAME. A Control Socket is opened and the command:
GETHOSTBYLUNAME xxxxxxxx
is sent. "xxxxxxxx" is the 1- to 8-byte LUname of an existing TN3270 session. The returned value is a 16-byte (128-bit) binary representation of the connection's IPv6 address.
Note that the IPv4 address is contained in the final 4 bytes of the IPv6 address.
A returned value of all zeros indicates that the specified LUname is not currently assigned to an active session.
Notes:
- You must allow for the return of information beyond the meaningful 16 bytes, since additional fields may be added at a later time.
- This fix includes ZP15E228
2007/03/14 Importance: Optional Risk: Low Supersedes: ZP15E228
ZP15E118 Datagram traces do not contain all blocks The trace is designed to include only datagrams blocks with a "trace elegible" flag set. This was intended to limit trace complexity by omitting unnecessary blocks. However, some useful blocks are occassionally omitted.
This fix causes tracing of all datagram blocks.
2007/04/03 Importance: Low Risk: Low
ZP15E120 File I/O subtask does not produce diagnostics or re-attach after failure. This fix corrects an error that prevents execution of the code responsible for printing File I/O diagnostics and re-attaching the task.
2007/04/03 Importance: High Risk: Low
ZP15E121 Loop occurs during FTP processing after applying ZP15E122 FTP processing continues to issue RECEIVES after being notified that the connection has been closed.
This problem has come to light following corrections to FIN and RST processing introduced in ZP15E122.
This fix prevents re-issuing a RECEIVE following FIN notification (EOF).
This fix may be applied without ZP15E122 being present.
2007/04/02 Superseded by: ZP15E314
ZP15E122 Various problems involving closing of a TCP connection. This fix ensures that no datagrams are sent following the receipt of a valid RST (reset) from the remote host.
In addition, the connection manager will NOT send a FIN until all queued data has been transmitted and a CLOSE socket request has been queued.
The Connection Control Block will not be destroyed until both sides of the connection have issued and acknowledged FIN.
This behavioral change means that STATUS calls can continue to be made until a CLOSE is issued and posted complete. It also means that CLOSE requests that do NOT complete with an SRCODE of 0 should be considered to be in error.
Please note that when a RECEIVE ends with SRCODE of 4, it indicates "End-Of_File" and does NOT indicate an error.
Notes:
- You ABSOLUTELY MUST apply ZP15E121 to prevent the FTP Daemon from "looping" when it encounters EOF.
- ZP15E101 and ZP15E103 are included as COREQ's because both involve updates to other phases and, once ZP15E122 has been applied, those fixes cannot be applied without modification.
2007/04/11 Importance: Medium Risk: Medium Co-Requisite: ZP15E101, ZP15E103, ZP15E121 Supersedes: ZP15E104, ZP15E107, ZP15E109, ZP15E124
ZP15E123 Performance problems caused by small MTU and MSS sizes. Some connections are assigned an MTU size that is much smaller that intended or required. This causes file transfers to run slowly.
This fix corrects the problem and allows each connection to be established with the "best" MTU, as determined by the link driver and route table.
2007/04/06 Importance: Medium Risk: Low
ZP15E124 Message IPT344I loops on console. If a "QUERY CONNECTIONS" command is issued against a connection that has received in excess of 4,294,967,295 bytes, the display logic loops back to the "SEND" message, creating an unending number of IPT344I messages.
This fix corrects the problem.
Notes:
- Under some conditions, FTPBATCH will automatically initiate a "QUERY CONNECTION" command.
2007/04/03 Superseded by: ZP15E122
ZP15E125 IPN694E Loop in non-Rent queue IPN694E Loop in Rent queue This message indicates that a TCP/IP internal phase management routine detected a loop in its control block chain during look-up.
The "loop" condition is determined by examining a predetermined number of control blocks before assuming that the chain is circular. Howver, this may simply indicate a larger than expected number of phases.
This fix increases the limit to a more reasonable level.
Notes:
- This routine is only called during the production of other diagnostics.
2007/04/04 Importance: Low Risk: Low
ZP15E126 Invalid checksum on outbound RST packet. Under some circumstances, TCP/IP transmits a reset (RST) request with an invalid checksum.
This fix corrects the problem.
2007/04/06 Importance: Medium Risk: Low
ZP15E129 LPD assigns a "default" name instead of the requested name. Because LPR streams may originate from a wide variety of non-VSE hosts, the LP Daemon attempts to ensure that a meaningful 8-character POWER name is assigned to the file. If the LPR client does not provide a suitable name, then the LPD generates a unique value and assigns it.
The problem occurs because the LPD does not have enough latitude in its name edit routine. POWER permits a wide range of characters --including non-printable characters-- in file names.
This fix removes the file name edit check.
Notes:
- The POWER manual cautions against using non-displayable characters in file names. It may prove difficult to enter commands for specific files if the name is not permissible in an operator command.
2007/05/23 Importance: Low Risk: Medium
ZP15E132 Slow outbound data transfer
Invalid Max Segment Size (MSS) value being usedAn error has been found that occurs during a PASSIVE OPEN (listen), when the SEND MSS requested by the remote host exceeds the MTU size - 40. In this instance, instead of reducing MSS to MTU-40, an extremely large SEND MSS is set.
This can be seen observed in the output from a QUERY CONNECTIONS or DIAGNOSE PERFORM display, which will show a SEND MSS value that is larger that the requested value (shown in parentheses).
This does not occur during an ACTIVE OPEN or in any case when the requested MSS is small enough to prevent datagram fragmentation.
Although the faulty connections should have failed completely, the examined instances were able to complete normally, but at greatly reduced speed. The speed reduction is caused by long, fixed-length pauses between outbound transmissions.
This fix corrects the condition that causes an invalid MSS to be used.
2007/06/30 Importance: High Risk: Low Pre-Requisite: ZP15E122
ZP15E133 MTU from Route Table entry does not override LINK value The MTU value used for a connection is normally specified based on the link being used. However for some routes, it is necessary to use a reduced value.
This fix ensures that the Route Table MTU size overrides the DEFINE LINK value, if smaller.
2007/07/31 Importance: Medium Risk: Low Pre-Requisite: ZP15E122
ZP15E134 Delays in performing file-based I/O All I/O to files is performed in a separate subtask. At the completion of each I/O, the requestor is notified by posting an ECB.
A delay may occur because the engine subtask is not waiting on the ECB being posted, although the ECB is checked each time the engine task is dispatched. The delay time is unpredictable, but generally small, except on systems with little or no TCP/IP activity.
This fix causes the engine task to be awakened each time an I/O request is completed.
2007/09/27 Importance: Medium Risk: Low
ZP15E136 n/a This patch provides the queued inbound byte count via the SOCKET STATUS call.
The count is returned in the "STDATQI" field of the STATBLK macro. This field replaces a full-word that was previously marked "reserved".
2007/10/15 Importance: Optional Risk: Low
ZP15E137 Support for new OSA Express feature IBM has announced extensions to the OSA Express adapter for the z10 EC server. This fix adds the "OSAPORT=" parameter to the "DEFINE LINK" command.
This fix provides a method for using Port 1 of an OSA Express adapter adapter that has 2 ports per CHPID.
After applying this fix, you can add the "OSAport=n" parameter to the DEFINE LINK command for a TYPE=OSAX link driver. "n" should be 0 or 1 (default is 0).
2007/10/09 Importance: Optional Risk: Low
ZP15E144 Occasional connection failure after connection.
Connection fails with SRCODE 36 (X'24'), "Send after CLOSE"When an incoming connection request is matched to a listen connection, but the connection does not proceed to the "established" state for any reason, the connection should return to "listen" state without notifying the application.
During the process of resetting the connection state values, the intial FIN sequences are being set to zeros instead all X'FF'. The result is that as soon as the connection is finally established, the first "send" request generates an "after close" condition.
This fix correctly resets the FIN values.
2008/03/05 Importance: Low Risk: Low Pre-Requisite: ZP15E122
ZP15E145 Long connection delay before data begins to transmit This problem occurs when a remote host establishes an initial window size that is smaller than its requested Maximum Segment Size (MSS) and the first outbound data transmission is larger than the available window.
When this condition occurs, the logic that detects "Silly Window Syndrome" (SWS) prevents transmission of a partial, short datagram and waits for the window to be increased. If the remote host does not increase the window to the smaller of MSS or the queued data size, transmission does not occur until a timer has expired (nominally, 60 seconds).
This fix allows immediate transmission of data if the window is at its maximum advertised value.
2008/05/21 Importance: Medium Risk: Low Pre-Requisite: ZP15E122
ZP15E146 Corrupted datastream If an application program specifies a RECEIVE buffer at location 0, data transfer is suppressed but the operation is flagged as complete. If the application then relies on the contents of location 0, results can be erratic.
This fix causes the stack to reject the invalid request when it is made.
2008/08/01 Importance: High Risk: Low Co-Requisite: ZP15E148 Pre-Requisite: ZP15E103
ZP15E147 Message "BSD103W IPNRAIOC failed R15=00000014 errno=+113" Asyncronous I/O processing is attempting to inspect and modify an SOBLOK assigned to an in-flight operation. However, the SOBLOK's eyecatcher is not correct.
The probable reason for this is that the I/O has already completed and the SOBLOK has been modified to indicate this status.
This fix causes an erroneous eyecatcher to be interpretted as a completed operation, rather than a "corrupt SOBLOK" error.
Notes:
- This fix is not optimal. Although it may be a reasonable interim workaround, the architectural problem that caused the error has been fully corrected at Service Level F.
2008/08/07 Importance: Low Risk: Medium
ZP15E148 Program check in Socket interface after applying ZP15E146 An error in ZP15E146 causes a check to be made of a random location rather than the socket parameter list
This fix corrects the problem.
2008/08/11 Importance: High Risk: Low Pre-Requisite: ZP15E146
ZP15E201 FTPBATCH hangs when transferring a TYPE=VSAMCAT file When using TYPE=VSAMCAT, a problem with the DEFINE CLUSTER process of IPNFVCAT might cause one of the following conditions: (1) FTPBATCH abend, (2) FILE NOT FOUND after a DEFINE, (3) DEFINE ERROR.
This fix corrects the problem.
2006/10/19 Importance: Medium Risk: Medium
ZP15E202 DBCS translation fails with IPN944E message An incorrect test is being performed on DBCS translation buffers. This fix eliminates the erroneous check.
2006/10/19 Importance: Medium Risk: Medium
ZP15E203 DEFINE LOG with NOIMPORT does not suppress messages with the "IMPORTANT" attribute. When defining additional log files, all messages are logged by default. This can be suppressed by using NOCRIT, NOVITAL, NOWARN, NOIMPORT, NOINFO, NORESP, NODIAG, or NOSEC. The NOIMPORT option specifies an incorrect bit value in the command parser that makes it impossible to suppress "IMPORTANT" messages from a log file. This fix corrects the problem.
2006/10/23 Importance: Medium Risk: Low
ZP15E204 BSD103W message R15=value is incorrect If a SEND fails and DEBUG mode is active, the R15 value displayed contains an address rather than the reason code.
This fix causes the SRCODE to be displayed.
2006/10/26 Importance: Medium Risk: Low
ZP15E205 Output from a "DIR" command is missing one byte. When a directory list from a remote host requires multiple buffers and an individual line exceeds 100 characters, the 101st character can be lost.
This fix resolves the problem and restores the missing character.
2006/11/01 Importance: High Risk: Medium
ZP15E206 Usage of dynamic Dataspaces with FTPBATCH fails FTPBATCH used as an external FTP server fails to store or retrieve files using a dynamically-defined Dataspace.
This is due to an internal conflict with file type indicators.
This fix corrects the type specification, allowing FTPBATCH to use dynamically-define dataspaces for both storing and retrieving files.
2006/11/02 Superseded by: ZP15E314
ZP15E208 SecureFTP fails and storage is depleted by excessive queued SEND requests. SecureFTP fails with a:
FTP945W Data connection failed RC=8 error message
Cleanup problem error after a failed transfer with error message:
IPN694I Internal SOECB content error called from 0000943A in FTPDAEMN
DEFINE FTPD with SENDFAST=YES
FTPBATCH with SET SENDFAST ON permits multiple SEND requests to be queued without waiting for an acknowledgement from the remote host. Due to an error, the test for maximum queued data is never satisfied. This results in data being queued until partition GETVIS is exhausted.
This fix corrects the test so that once a predetermined amount of data has been queued, additional SEND requests are delayed until acknowledgements are received and buffers are reclaimed.
2006/11/21 Superseded by: ZP15E314 Pre-Requisite: ZP15E101
ZP15E210 IPN694I INTERNAL SOECB CONTENT ERROR. CALLED FROM 000029C8 IN IPNAFTPC During normal FTP data transmission, one Daemon is instructed to open a "listen" connection and the other Daemon then issues an "active" open to the now-available address and port.
During some conditions, the "active" open is not issued, leaving the "listen" connection behind. The "listen" times-out after two minutes and attempts to post the request as failed. The message is issued because the control blocks used to request the "listen" have been reused for other purposes.
This fix prevents the re-use of the control areas before the operation is posted complete.
2007/01/08 Importance: Medium Risk: Medium
ZP15E211 IPF402I POWER CLOSE XPCC SENDR has failed. RC 2 Codes: 0 0 This message indicates a communications failure between TCP/IP and POWER.
A change in processing with Service Pack E causes this message to be displayed when an attempt is made to FTP data into the RDR queue following an "* $$ EOJ".
This includes blank lines and most other lines except for a "* $$ JOB" record.
CSI's approach to FTP is that the process is "File Transfer" and NOT "File Editing". Although some accomodations are required when transferring files between dissimilar systems, we generally assume that "if you sent it, you meant it."
This fix will suppress the IPF402I message when it is caused by invalid records following "* $$ EOF".
CSI highly recommends that files to be sent to the RDR queue be inspected for validity and corrected as required.
2007/03/27 Importance: Optional Risk: Low
ZP15E212 FTP PUTs to the POWER LST queue fail with "wrong length record" The default record format length for LST queue files is incorrectly being set to FB 80/80.
This fix sets the default format to "V" (variable) and LRECL to "256". This will restore functional compatability with 1.5D and earlier releases.
2006/12/15 Superseded by: ZP15E314
ZP15E213 FTP941I message not being issued
Invalid password aborts session
LOPEN failure retried excessivelyThe SITE STRIP ON command can be used to strip trailing blanks during an ASCII transfer of data from VSE to a foreign FTP server. This can significantly improve the performance of file transfer but can adversely affect applications that depend upon the presense of trailing blanks of fixed-length records.
The TCP/IP 1.5E User Guide states that an FTP941I message will be issued, indicating the total number of bytes stripped. However, the message was given an attribute of "diagnose", which limits its display.
This fix changes the FTP941I message to "informational".
This fix also addresses a problem where an incorrect password causes an immedidate abort of a session. This condition will now result in the message: "530 Not logged in" to be sent to the client.
This fix also prevents excessive retries following the failure of an LOPEN. When the local FTP Daemon fails to respond positively to an OPEN request, the operation will be terminated and the message: "Error: during LOPEN, command failed" will be displayed.
2007/01/18 Superseded by: ZP15E314
ZP15E214 Upgrade of SSL to include AES ciphers The Advanced Encryption Standard (AES), as documented by the U.S. National Institute of Standards (NIST) in FIPS-197, has been added to the cryptographic routines included with the SSL feature of TCP/IP for VSE.
The FIPS-197 publication containing the details of this new cipher can be downloaded from:
http://csrc.nist.gov/CryptoToolkit/tkencryption.html
With this update, SSL for VSE includes support for AES with key lengths of 128, 192, and 256 bits. Operation modes include both Electronic Feedback (ECB) and Cipher Block Chaining (CBC). AES is the U.S. government-approved replacement for the 30+ year old DES encryption standard and is cryptographically superior and more efficient than the algorithm it replaces.
The AES-128, AES-192, and AES-256 ciphers are available on all z-architecture and System/390 platforms, running VSE 2.3 and higher. When installed and operated under z/VSE 4.1 and higher, SSL will automatically use the "CP assist for Cryptographic Functions" (CPACF). This hardware-implemented assist greatly reduces the resources required for encryption.
This SSL implementation has been reviewed by the U.S. Dept. of Commerce and the U.S. National Security Agency, and has been granted a classification of "ENC-unrestricted". It can therefore be exported to any country not on the U.S. embargoed list. [See http://www.bis.doc.gov/Entities/Default.htm for more complete details on U.S. export regulations.] Currently, the U.S. Department of Commerce prohibits the download and/or sale of this encryption product if you are in, will ship to, or plan to sell to the following countries: Cuba, Iraq, Iran, North Korea, Rwanda, or Syria.
To upgrade SSL to the new algorithm, you must download and install the new IPDSCIAL.PHASE. You can obtain a copy from the CSI website (http://www.e-vse.com/csi/download.htm) by clicking on the "Click here to download SSL components" link. This will download a file (SSL4VSE.ZIP) containing the IPDSCIAL installation jobstream (IPDSCIAL.BJB). To complete the installation, copy this file (binary mode) into the POWER RDR queue and execute it. When prompted, respond with the library.sublibrary that contains the existing IPDSCIAL.PHASE.
For additional information on SSL and how it can be used with customer applications, please consult the "CryptoVSE API" section of the "TCP/IP 1.5E Optional Features Guide".
2007/01/23 Importance: Optional Risk: Medium
ZP15E215 HARDWAIT caused by fix ZP15E215
Was: Address exception Abend (VSE 2.4 and below)This fix has been found to cause a VSE HARDWAIT condition.
If you have applied this fix to your system, you are STRONGLY urged to remove it immediately.
A corrected fix, ZP15E221, has been posted.
2007/02/13 Importance: Critical Risk: High
ZP15E216 Abend when using the CPACF hardware assist The CP Assist for Cryptographic Function (CPACF) provides extremely high performance for various cryptographic functions. The crytographic routines of TLS/SSL automatically use CPACF when it's presence is detected on z/VSE 3.1 and above, or if it has been configured to be used via the $SOCKOPT options phase.
An abend can occur when SSL presents a request for an unsupported cipher to the CPACF hardware.
This fix ensures that SSL properly tests for hardware support for each cipher. If CPACF does not support the needed cipher, then the software implementation is used.
At the time this fix was issued, CPACF only supports the AES 128-bit cipher and the software is making requests for unsupported ciphers.
This fix ensures that the software tests the correct flags and only passes supported cipher requests to CPACF.
Notes:
- The software supports AES-128 and AES-256 ciphers while CPACF only suports AES-128. Since the CPU costs of the software implementation of AES-256 is an order of magnitude greater than the hardware implementation of AES-128, it is highly recommended that your applications be configured to use the slightly less-secure AES-128 cipher unless AES-256 is required.
- Microcode updates to CPACF that will implement the AES-256 cipher are expected to be available shortly and should be requested from IBM. When available, the software will automatically detect and use the additional hardware assist(s).
- At this time, the intermediate AES-192 cipher is not supported by hardware or software.
2007/01/29 Importance: Medium Risk: Medium Pre-Requisite: ZP15E214
ZP15E217 FTPBATCH loops or fails when invoked from an IBM REXX routine. When FTPBATCH completes execution, several CDLOADed phases are not deleted. This has no effect on batch execution since VSE automatically deletes them and releases storage.
However, when called by a REXX routine, the second and all subsequent times may fail due to "left-over" phases, storage, and values within FTPBATCH.
This fix clears/uninitializes the problem values.
2007/01/30 Importance: Medium Risk: Medium
ZP15E218 Catalog of a certificate fails The CIALROOT or CIALCERT jobs may fail when attempting to catalog a certificate due to an unrecognized construct in the certificate being cataloged. This fix allows the contruct to be used and the certificate to be cataloged.
2007/01/30 Importance: Medium Risk: Medium
ZP15E219 Wrong Length Record error on POWER LST queue This error occurs when attempting to FTP a text file into the LST queue while operating in Unix mode and the file's extension is not in the external types (EXTTYPES) table.
The table supplies a default RECFM, LRECL, and BLKSIZE for unknown files of FB/80/80. This causes problems whenever a record exceeds 80 characters.
This fix will change the default values to V/256/256. This is valid for all possible POWER LST files.
The FTP 150 message that describes the file's attributes will also change from:
150-Type:ASCII Recfm:FB Lrecl:80 Blksize:80
to:
150-Type:ASCII Recfm:V Lrecl:256 Blksize:256
An additional benefit from applying this fix is that it eliminates the artificial maximum LRECL of 132 for LST queue files. POWER's full 256 byte line length will now be supported.
2007/01/31 Superseded by: ZP15E314 Pre-Requisite: ZP15E212
ZP15E220 SSL103C CRYGCRIN failed R15=FFFFFFFB reason=GCRSBOI3 Internal SSL Certificate processing does not recognize the ASN.1 object identifiers assigned to "address" and "zip code".
This fix ensures proper handling of the "address" and "zip code" objects.
2007/03/27 Importance: Medium Risk: Low
ZP15E221 Address exception ABEND (VSE 2.4 and below) An ABEND may occur in the BSD/C interface when running on VSE/ESA releases below 2.5. This can happen when the SUBSID interface is entered while executing in AMODE 31.
This fix corrects the problem by detecting the VSE release, and then setting the appropriate AMODE prior to accessing the SUBSID interface.
This fix supercedes ZP15E215, which was found to cause a potential VSE hardwait condition.
Fix ZP15E215 must be removed before you apply ZP15E221.
2007/02/13 Importance: Medium Risk: Medium Supersedes: ZP15E215
ZP15E222 FTP PUT to POWER RDR queue fails after applying ZP15E219 Fix ZP15E219 changed the default RECFM/LRECL values for POWER files (with unknown extensions) to V/256. Due to the manner in which POWER files are accessed, this causes no problems for standard text files.
Because binary file transfers cannot use record delimiters, all such files being sent to POWER must be fixed-length records of known length. In general, this is always F/80.
This fix sets the default for inbound binary-mode POWER file transfers (of unrecognized type) to RECFM F, LRECL 80.
Notes:
- Fix ZP15E219 must be applied before ZP15E222.
2007/02/12 Superseded by: ZP15E314 Pre-Requisite: ZP15E219
ZP15E223 FTP PUT of an EPIC tape file fails This fix permits use of EPIC-controlled tape files (with FTPBATCH) by allowing the syntax:
PUT %FILEIN,TAPE,EPIC FTEPTST1.TXT
This fix also causes tape files to be detected automatically. For example, if you code:
PUT %FILEIN,SAM,EPIC FTEPTST2.TXT
then "TAPE" will automatically be substituted for "SAM", if the file is found to reside on a tape volume.
Notes:
- Use of the "EPIC" option applies ONLY to files being opened for input that are known to (and cataloged by) EPIC.
- Because EPIC records RECFM, LRECL, and BLKSIZE information in its own catalog, these values are optional on the PUT statement. If omitted, they are automatically retrieved from the EPIC catalog.
2007/02/18 Superseded by: ZP15E314
ZP15E224 Invalid block size causes abend If the block size is not specified on a PUT or GET it may default to a value less than the record size. This may result in an abend. When the block size is not specified for a dynamically allocated autonomous file(%), this fix sets the block size equal to the record size.
2007/02/27 Superseded by: ZP15E314
ZP15E225 PDF conversion does not use the intended translate table By default, the PDF conversion routine uses the same translate table being used by the FTP Control Connection.
This fix causes the PDF routines to use the translate table assigned to the Data Connection.
2007/03/01 Superseded by: ZP15E314
ZP15E226 SSL request fails with reason GCRIBC02 or GCRIBPKM Information passed to SSL as a Certificate is in a format known as ASN.1, and must conform to the standards defined in ITU x509. As with most Internet-related standards, there is some ambiguity as to allowed ranges, settings, etc.
This fix allows a Certificate with a tag number of zero to appear in the initial constructs and also permits an RSA public key structure without a leading zero.
2007/03/12 Importance: Medium Risk: Medium
ZP15E227 "SITE SOSI" is ignored during DBCS translation Although FTP accepts the SITE SOSI command and indicates that the value is being used, all DBCS translation is performed with the setting if "SITE SOSI CONVERT"
This fix ensures that the desired SOSI setting is passed from FTP to the translation routines.
2007/03/06 Superseded by: ZP15E314
ZP15E228 IPA702W Product code check for 107 failed 00 This message is incorrectly classed as a "warning". It was intended to be a minor diagnostic message, providing useful data for resolving "unforeseen" problems.
This fix reclassifies the message to "diagnostic" and prevents its display on the operator console.
2007/03/12 Importance: Low Risk: Low
ZP15E229 "FTP343I data received without end of record" and FTPBATCH terminates with RC = 0 The FTP343I message is issued when a text-mode data transfer ends without a record-delimiter; in other words, the file is cut-off in the middle of a record.
This condition can be caused by many things. The list of causes includes transmitting a file that was already corrupt (truncated), aborting a running data transfer, an I/O error on the remote host, and many others.
Most well-designed FTP Daemons will reset (RST) the data connection rather than close it (FIN). More importantly, they will inform the client of the failure by returning a 500-level message at the conclusion of the transfer.
For a variety of reasons, some Daemons either do not detect the file corruption, or simply fail to report it. Regardless of the reason the Daemon closes the connection normally and issues a standard "successful transmission" message.
Because Mainframe users are concerned with data integrity, the VSE Daemon incorporates this additional check and error message for incoming files. Unfortunately the message is classed as "informational", which prevents the FTPBATCH return code from reflecting the detected problem.
This fix will cause FTPBATCH to end with a non-zero (warning) return code when this condition is detected.
Notes:
- You can use the FTPBATCH "SET IGNORERR" command to force a zero return code in those cases where corrupted files are to be received without detection.
- Non-text (IMAGE/BINARY) files contain no record structure and do not have this validity test performed
2007/03/12 Superseded by: ZP15E314
ZP15E230 550 Action not taken: Local definition failure When using a script with the batch FTP client (// EXEC FTP) to provide logon information, a GET or PUT that appears within the first four input records may fail.
This is because the first four records are assumed to contain the local and remote userids and passwords and the program allows a wide range of values to be coded.
This fix causes // EXEC FTP to check for EXEC statements appearing in the first four records and to adjust its processing accordingly.
2007/04/03 Importance: Optional Risk: Medium
ZP15E232 The control connection to the foreign FTP server fails to open. When the foreign FTP server sends a 220 "welcome" message that contains a single line greater than 512 bytes, the connection will fail.
This fix increases the maximum line length to 1024 characters.
Notes:
- If the "welcome" message spans multiple lines, the 512/1024-byte limit applies to each line, not the total for the message.
- This limit also pertains to all other messages returned by the the foreign server.
2007/04/10 Importance: Medium Risk: Medium
ZP15E233 AutoFTP fails to honor an "ignore error" override AutoFTP normally aborts script processing following an error. Since this may be inconvenient when the error occurs on a DELETE or RENAME, the special "&ERROR" variable can be set to the string "IGNORE".
SETVAR &ERROR = "IGNORE"
When the &ERROR variable is set in this manner, AutoFTP continues to execute the script.
This fix causes AutoFTP to honor the &ERROR setting.
2007/04/10 Importance: Medium Risk: Medium
ZP15E234 Pulse disabled on control connection When the VSE FTP client opens the control connection, it immediately disables pulsing. This prevents the stack from sensing and resetting "dead" control connections.
This fix allows the standard "pulse" to be issued on idle control connections.
2007/05/14 Importance: Medium Risk: Medium
ZP15E235 FTP928E wrong length record The BLKSIZE=, LRECL=, CC=, and CRLF= values of the DEFINE FILE command are no longer overriding the values specified via the FTP SITE command.
This causes a problem when invalid values are specified with the SITE command -OR- if SITE command values in effect for a previous GET/PUT are not nullified or respecified.
This fix restores the behavior to its 1.5D level.
2007/05/08 Superseded by: ZP15E314
ZP15E236 Abend in application after gsk_uninitialize() call When an application progam issues an uninitialize call, any following initialize calls will abend. This is caused the the clearing of a phase address.
This fix corrects the problem.
2007/05/23 Importance: Medium Risk: Medium
ZP15E237 CICS/TS Abend when using SIT option RENTPGM=PROTECT and SSL This fix prevent modification of a static constant area from within IPCRYPTS. This module is distributed as an object deck and applications using the SSL and cryptographic subroutines must be re-linkedited to include this corrected object deck.
2007/06/04 Importance: Medium Risk: Medium
ZP15E238 FTP 226 message omitts record count for binary transfers During a binary transfer the 226 completion message should contain the number of records sent or received. This fix adds the number of records sent or received to the 226 message returned to the FTP client.
Notes:
- A single line 226 message can be forced by using the "site terse on" command.
- Since binary transfers have no record structure (unless MODE BLOCK or STRUCTURE RECORD are in effect), the record count is the number of records used to contain the data on the VSE file system.
2007/06/04 Superseded by: ZP15E314
ZP15E239 FTP DIR listing is truncated by one byte per line. When receiving directory entries from a foreign FTP server, each line should be terminated with CR/LF. However, some Unix FTP servers only provide a single LF as a line-ending character.
Although the VSE FTP client allows for this aberrant behavior, the byte immediately preceding the the LF is being dropped.
This fix corrects the problem.
2007/06/05 Importance: Medium Risk: Medium
ZP15E240 SITE RECLF ON ignored on outbound files During ASCII file transfers each record is normally delimited by the addition of a CR/LF pair. To accomodate file systems that use only a single LF character to delimit records, the SITE RECLF ON command instructs FTP to parse incoming data using only an LF.
This fix causes FTP to handle outbound files in the same manner as inbound, appending a single LF to each outbound record.
2007/06/13 Superseded by: ZP15E314
ZP15E241 QUERY SECURITY output is not displayed on the console. This fix corrects the problem.
2007/06/14 Importance: Low Risk: Low
ZP15E242 // EXEC FTP terminates after RENAME failure. In previous releases, failure of a RENAME command (550 File not found) did not cause termination of additional processing.
In 1.5E all 5xx-level errors generate an "Error:" response and the // EXEC FTP client terminates, flushing the remaining SYSIPT commands.
Although this is technically correct behavior and the 1.5D behavior could be considered incorrect, this optional fix will allow a RNFR 550 response from the foreign Daemon to be ignored.
This problem can also be circumvented by applying fix ZP15E233 and then using the SYSIPT commands:
SETVAR &ERROR = "IGNORE"
RENAME fn.ft newfn.newft
SETVAR &ERROR = "EXIT"
This will tell FTP to ignore any rename error and then continue with normal treatment of any additional errors.
2007/06/15 Importance: Optional Risk: Low Pre-Requisite: ZP15E233
ZP15E243 Wrong length record when storing into an HFS file. This fix changes the default maximum record size for file types of "textc" from 1024 to 4096.
This will permit FTP to transfer "textc" files of up to 4096 bytes in each record.
2007/06/15 Superseded by: ZP15E314
ZP15E246 Abend during DES encryption while using CPACF assist. A abend may occur when attempting DES encryption via the CPACF hardware assist, when the hardware does not support the triple-DES cipher algorithm.
This correction causes a check for CPACF support of triple-DES prior to executing the CPACF instruction. This will avoid specification-exception program-check abends.
2007/09/27 Importance: Medium Risk: Medium Pre-Requisite: ZP15E216
ZP15E247 FTP session abends when CWD is entered with a single quote (CWD '). A program check abend can occur whenever FTP attempts to process a CWD or LCD command that is followed by a single quote.
This fix corrects the problem.
2007/07/17 Superseded by: ZP15E314
ZP15E248 SecureFTP data connection for DIR fails The data connection used to receive directory information when using SSL may fail because of a retry of the SSL handshake.
This fix removes the redundant attempt for an already-established secure data connection.
2007/07/18 Importance: Medium Risk: Medium
ZP15E249 IPF204E VSAM ESDS File read error, Return:8 Feedback:88 After applying IBM VSAM PTFs UD53207/UD53208, an IPF402E error message may occur when reading a VSAM ESDS dataset. This occurs when a GET is issued following an EOF. Previous behavior resulted in the EOF simply being re-issued.
This fix prevents the erroneous read after EOF.
2007/10/15 Importance: Medium Risk: Medium
ZP15E250 SSL fails to initialize or encounters a program check. The use of strong crypto algorithms is prevented when an RSA key size of 512 is used. If $SOCKDBG is in effect, debugging message "SSL103I IPCRSINI failed R15=FFFFFF97 reason=SINISZCI" is issued.
This fix will allow the strong ciphers to be used with an RSA 512-bit key.
This fix also corrects a program check that can occur when the CPACF hardware assist facility is presented with an AES-256 cipher operation that it does not support.
You should also check with IBM for microcode updates that will add support of the AES-256 algorithm to the CPACF crypto hardware assist feature.
2007/08/08 Importance: Medium Risk: Medium
ZP15E251 FTPBATCH control connection not using the "SET TELNET_TRANSLATE=" table. This fix causes FTPBATCH to honor the translate table specified by the SET TELNET_TRANSLATE= command.
2007/08/13 Importance: Medium Risk: Medium
ZP15E252 FTPBATCH job stalls while receiving foreign reply When using SecureFTP, the FTP client may stall due to an incorrect diagnostic check.
This fix removes the incorrect diagnostic check.
2007/08/23 Importance: Medium Risk: Medium
ZP15E253 FTPBATCH with SecureFTP abends When using SecureFTP, FTPBATCH may abend during the SSL handshake. This fix prevents this abend from occurring.
2007/08/24 Superseded by: ZP15E314
ZP15E254 FTP session terminates after SITE command fails If a SITE command fails due to a secuity violation, the FTP session abruptly terminates. The security failure should not cause session termination. This fix corrects this problem.
2007/08/26 Superseded by: ZP15E314
ZP15E255 Abend in BSD/C application with unresolved errno variable. When an application fails to provide an errno variable, a protection exception may occur. Although the application should supply an errno variable, this fix will test for the variable's presence before attempting to initialize it to zero.
2007/08/27 Importance: Medium Risk: Medium
ZP15E256 FTP session terminates after security violation. When an FTP command fails due to a security violation, the FTP session abruptly terminates. The security failure should not cause session termination, only suppression of the command.
This fix corrects the problem.
2007/09/27 Superseded by: ZP15E314
ZP15E257 Abend in CICS/TS when using Crypto Express2 hardware. A call to Crypto Express2 to perform RSA operations may cause an abend under CICS/TS. This is caused by a failure to reset to the correct storage protection key.
This fix corrects the problem.
2007/09/27 Importance: Medium Risk: Medium
ZP15E259 AMODE 24 BSD/C applications fail. Data areas returned from some BSD/C functions may be allocated in 31-bit storage. This causes problems for applications running in 24-bit mode.
This fix forces all returned values to reside in 24-bit storage.
2007/09/27 Importance: Medium Risk: Medium
ZP15E260 BSD/C ACCEPT fails with wrong errno when TCP/IP is not available The ACCEPT function may return errno=ECONNRESET(1121) when the TCP/IP partition has been shut-down. This fix will cause a return of errno=ENETDOWN(1117) when TCP/IP has been shut-down.
2007/11/02 Importance: Medium Risk: Medium
ZP15E261 IPF204E VSAM ESDS File read error, Return:8 Feedback:88 After applying IBM VSAM PTFs UD53207/UD53208, an IPF402E error message may occur when reading a VSAM ESDS dataset. This is caused by issuing a GET after EOF has been set in the RPL.
Prior to applying the above-noted IBM PTF's, the RPL EOF condition would be re-returned to the calling application.
This fix prevents the erroneous attempt to read following EOF. from occurring.
This fix supercedes ZP15E249. ZP15E249 MUST be removed before applying this fix.
2007/10/15 Importance: Medium Risk: Medium Supersedes: ZP15E249
ZP15E262 IPF204E VSAM KSDS File read error, Return:8 Feedback:88 After applying IBM VSAM PTFs UD53207/UD53208 an IPF402E error message may occur when reading a VSAM KSDS dataset. This is caused by the FTP Daemon sometimes issuing an additional READ after EOF has been returned by VSAM.
Prior to applying the above-noted IBM PTF's, VSAM restated the EOF condition without error.
This fix prevents any further reads after EOF notification.
2007/11/02 Importance: Medium Risk: Medium
ZP15E263 SSL handshake fails with GCRICHLZ error During the SSL handshake a certificate was received containing an ASN.1 primitive with a length of zero.
This fix causes an asterisk(*) to display for a zero-length ASN.1 primitive structure and circumvents the error condition.
2008/04/11 Importance: Medium Risk: Medium
ZP15E264 Excessive IPT301I diagnostic messages This message should only be issued when DIAGNOSE RETRANS is in effect.
This fix corrects the problem.
2007/11/02 Importance: Medium Risk: Medium
ZP15E265 System GETVIS leak when using Crypto Express2 hardware A call to Crypto Express2 for RSA operations requests system GETVIS storage in subpool SSLSGV and does not release it. This zap also requires a replacement IPDSCIAL.PHASE. This zap corrects this problem.
2007/11/08 Importance: Medium Risk: Medium
ZP15E266 Connector Server abends during TCP/IP shutdown When TCP/IP is shutdown the Connector Server SELECT is posted with one and then zero sockets ready for processing. This fix adds a check for TCP/IP shutdown, causing the SELECT to be posted with errno ENETDOWN. In addition to applying this fix, you should create a $SOCKOPT phase with the $OPTNBSD option set. This option forces a CDLOAD of the IPNRBSDC phase into 31-bit partition GETVIS, rather than relying on the SVA-based copy. This eliminates a possible abend that occurs when an application is actively executing within the phase as TCP/IP shutdown processing releases the SVA storage.
2007/11/12 Importance: Medium Risk: Medium
ZP15E269 System GETVIS leak when using Crypto Express2 hardware A call to Crypto Express2 for RSA operations requests system GETVIS storage in subpool SSLSGV and does not release it. This zap also requires a replacement IPDSCIAL.PHASE. This zap corrects this problem.
Notes:
- Fix ZP15E265 (if installed) MUST be backed-out prior to installing ZP15E269.
2008/01/23 Importance: Medium Risk: Medium Supersedes: ZP15E265
ZP15E270 Certificate from godaddy.com fails The issuer information for godaddy.com issued certificates contain extraneous serial number fields that were not expected. This fix cause the extra fields to be ignored. They will be displayed as "unknown" in the CIALCERT job's SYSLST. This may also apply to other certificate authorities that include extra information in the issuer section of the certificate.
2008/08/15 Importance: Medium Risk: Medium
ZP15E301 Reading VSAM-managed SAM files results in a "0-record" condition. A bit setting in the catalog can be overriden by OEM software or the use of a MODEL, hiding the "implicit" identity. The VSAM-managed SAM file is then seen as an empty ESDS file and the result is no transfer of records.
This fix will disable the checking for VSAM-managed SAM and will read the file even if the catalog indicates that it is "empty". If the file is truly empty, then the standard IBM VSAM warning message will appear on SYSLOG.
2006/11/21 Importance: High Risk: Low
ZP15E302 FTP not accepting valid SITE xDEST= command. Certain operand forms that are acceptable to POWER are rejected by the FTP Daemon. This fix extends the range of operand formats recognized as valid.
2006/12/24 Superseded by: ZP15E314
ZP15E303 EMAIL REPLYTO command returns "invalid character" warning. The problem occurs when an unexpected hexadecimal value is assigned to the "@" symbol.
This fix removes the general syntax check for the field. The actual edit will later be performed by code that understands "@"-character substitution.
2007/01/05 Importance: Low Risk: Low
ZP15E304 "Wrong length record" errors cause excessive diagnostics to appear in the TCP/IP SYSLST. This fix will disable the diagnostic dump but does not address the problem that is triggering it.
Please see fix ZP15E212 for a potential fix to the underlying problem.
2007/01/17 Superseded by: ZP15E314
ZP15E305 PDF conversion fails for listings that exceed 13,000 pages. A print queue entry exceeding 13,000 pages will have all of the data sent to the recipient, but much of the indexing at the end of the PDF will be missing, and the PDF is unusable. FTP will display "Unable to translate to PDF". Other clients will display similar messages.
This fix corrects the poblem.
2007/08/02 Importance: Low Risk: Low
ZP15E306 LPR "SENDLENGTH=NO" option does not work Normal LPR/LPD processing requires that the command issued to the remote LPD contain an exact byte count of the data file being transmitted. This means that transmitting a POWER listing by LPR requires the file to be read and formatted twice; Once to obtain the length and again to actually transmit the data.
An addition to the RFC permits specification of a file length of zero. This is intended to cause the remote LPD to read the data file until the connection is closed.
When the SENDLENGTH=NO option was introduced, we could not find an LPD that supported the feature and, consequently, a bug in the code prevents the option from working with newer LPD implementations that now support it.
This fix corrects the format of the commands issued when SENDLENGTH=NO is in effect.
Notes:
- Not all LPD's and LPD-based printers support this option. Before specifying SENDLENGTH=NO, you will need to verify that the resulting datastream is acceptable to the printer or LPD. However the CPU, I/O, and elapsed-time savings can be significant.
2008/05/30 Importance: Low Risk: Low
ZP15E307 SENDLENGTH=NO would not send a proper format. CPU usage is high. There are SOME LPR printers that support the use of receiving data without a length value within the header. Without this, LPR will read a file 2 times. With this feature it will only read it one time, and in the case of POWER, this will reduce the CPU during that first pass.
If your LPR printer supports this feature then apply this zap.
2008/05/20 Importance: Low Risk: Low
ZP15E309 "TCP150E Security exit unable to initialize" while running EXEC EMAIL batch client If the stack has SECURITY set to "ON" but no security exit defined, then security initialization will fail, and any attempt to use local file I/O ("%ddname") will also fail.
This fix permits the email client to execute without a security exit defined.
2008/06/26 Importance: Medium Risk: Low
ZP15E310 FTPBATCH doesn't generate PDFs correctly. When generating a PDF, all of the text is nulls because the translation table is being treated as though it were nulls.
This fix corrects the problem. PDFs
2008/07/16 Superseded by: ZP15E314
ZP15E313 DBCS translation of In-Body text is incorrect. The recipient of an EMAIL that uses DBCS translation for the in-body text will see garbage characters at the end of the text.
This phase replacement will correct the problem.
2008/11/10 Importance: Low Risk: Low
ZP15E501 FTP from/to HFS files fails in VSE mode When FTPing an HFS file in VSE mode, the backslash gets replaced with a period, so the file is placed in the root directory with periods in its name.
2006/11/13 Superseded by: ZP15E314
ZP15E502 IPF904E HFS RENAME ERROR
IPF905I 214 - PATH NAME NOT DIRECTORYA problem with the FTP RENAME command prevents renaming files that reside in the 6th level directory of an HFS file.
This fix corrects the problem.
2007/01/30 Importance: Low Risk: Low
ZP15E503 Rename of HFS file in root directory fails A rename of an HFS file in the root directory will receive the following error: HFS RENASETD ERROR RC=C2 and IPNFHFS1: Internal error.
This fix will correct the error.
2007/08/23 Importance: Medium Risk: Low Pre-Requisite: ZP15E502
This page and all materials residing on this site Copyright© 1996, 2009 by CSI International. You may read, download, and copy these materials only for the purpose of evaluating or publicizing CSI International, its services and products or in accordance with a license agreement with CSI International.
Copyright© 2009 CSI International