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 C
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
ZP15C001 Link Driver does not respond to a close-down notification from a 3172 control unit. When link driver closes, the LUB(s) is not freed. When a 3172 controller encounters unrecoverable difficulties, it may transmit a STOPLAN or SHUTDOWN notification to the host. The TCP/IP link driver was ignoring the notification, making the inactive link difficult to notice. Another problem is that the dynamically-allocated LUBs are not freed, causing eventual depletion after cycling the link driver several times.
This fix causes the driver to look for and process any STOPLAN or SHUTDOWN requests. It also releases the dynamically-acquired LUBs during shutdown. Additional diagnostics are provided, and are controlled via the DIAGNOSE CLAW option.
2004/02/16 Importance: Low Risk: Low
ZP15C002 CICS PL/1 program using EXEC TCPIP does not properly serialize buffer and ECB user. This fix addresses a problem with the code invoked by the EXEC TCPIP calls when executing a PL/1 program under CICS.
This fix consists of two parts. The first part is a new object deck, IPNETYP, which contains CICS-specific code. The second part is a modification to IPNETCPL.L, which will cause use of the IPNETXPC phase.
For this fix to take effect, you must recompile your PL/1 programs after running them through the TCP/IP preprocessor (IPNETRAN).
2004/02/19 Importance: Medium Risk: Low
ZP15C101 Messages IPI504W and IPI508W repeat endlessly. When an external application (phase) terminates without closing a socket connection, TCP/IP detects this, issues a message, and closes the connection.
Under some circumstances, the connection is flagged for closure, but the associated connection manager task is not dispatched. This leaves the connection in an open status and causes internal monitoring to repeatedly detect and attempt to close the connection.
This fix causes the connection manager to be posted following the connection's status update.
2003/11/17 Importance: Medium Risk: Low
ZP15C102 Connections stall Datagrams that have been fragmented during transmission may not be reassembled in a timely fashion. This can cause connections to be dropped
This fix ensures that datagrams are made available for processing as soon as they are complete.
2003/11/18 Importance: High Risk: Low
ZP15C103 Messages IPI504W and IPI508W repeat endlessly after applying fix 101. After applying ZP15C101, TCP/IP continues to "loop" while issuing messages.
Although the connection manager is notified of a "dead" connection and dispatched, termination processing may not complete in a timely manner. Thus, the connection still "exists" and cleanup processing repeatedly sees the dead connection, issues another set of messages, and re-attempts to close the socket.
This fix causes cleanup processing to check if it has already scheduled a close and, if so, bypasses the messages and unnecessary processing.
2003/11/20 Importance: Medium Risk: Low Pre-Requisite: ZP15C101
ZP15C104 "Response timeout, resetting connection" message. Also dropped connections and "hangs" The IP header and TCP and ICMP datagrams all have their integrity protected by a 2-byte checksum. The methods for computing checksums are specified in RFC791 (IP), RFC793 (TCP) and RFC792 (ICMP). In each standard, the checksum is computed as the 16-bit one's complement of the one's complement sum of all 16-bit fields (with the checksum field set to zero). In practice, one simply adds the unsigned halfwords. Anything "carried" out of the 16-bit result is added to the low-order part of the sum. At the conclusion, the sum's bits are "flipped" to get the final one's complement checksum.
Before data is accepted, the checksum is re-computed and compared with the value stored in the data.
Two other RFC's address interesting aspects of one's complement checksums (RFC1071 and RFC1141), observing that, since 0 (X'0000') and -0 (X'FFFF') are mathematically identical, checksums that evaluate to X'0000' are correct even if the transmitted value is X'FFFF'. Based on this, they go on to provide "shortcut" methods for validating checksums and methods for updating them when some of the data is modified.
These RFC's are interesting to read and would be quite useful except for a single problem: They both violate the published standards. X'0000' is NOT equal to X'FFFF'. The standards state the method of checksum calculation precisely and succinctly and they do not provide for the "shortcut" methods.
If you read RFC1071 or RFC1141 carefully, you will note each carries a header that EXPLICITLY states that it is NOT part of the standard.
Unfortunately, some technicians have erroneously assumed that "if it is published as an RFC, it is part of the standards," and are now causing data with invalid checksums to be transmitted.
Because VSE is a very small portion of the TCP/IP "universe", because we can respond to the problem more quickly than hardware vendors, and because accepting the incorrect checksum (in this very specific instance) reduces the integrity by a very trivial amount, we are providing this fix to bring us into agreement with the non-standard stacks.
2003/11/27 Importance: Medium Risk: Medium
ZP15C105 Dropped connections, hangs If a datagram must pass over a network segment with an MTU size that is too small to accomodate it, the datagram must be fragmented for transmission and then reassembled at its destination.
While this fragmentation is carried-out at the IP level, but is generally done because the TCP payload is too long.
Each fragment's IP header information is protected by a checksum that is verified prior to using the included data. Corrupted fragments are discarded and the normal retransmission process assures that correct replacements will be forthcoming.
Once the datagram has been reassembled, the completed data packet is passed to TCP (or other) processing. This processing includes validating the TCP checksum over the entire data packet.
Included in the TCP checksum calculation is the "pseudo header" that contains, among other values, the computed length of the data.
Under some circumstances, the reassembled datagram is being padded to an even-byte boundary. This extra byte increases the length value and thus invalidates the checksum. When this happens, TCP processing simply discards the datagram and waits for retransmission. However, since retransmitted data (generally) will also be fragmented in the same manner, its checksum will also fail.
This fix eliminates the invalid rounding and padding.
2003/12/02 Importance: High Risk: Low
ZP15C106 TCP Checksum errors after applying ZP15C104 Fix ZP15C104 altered the manner in which TCP checksums are validated. The zapped code does not properly handle a "carry" during pseudo-header summation. This situation does not occur frequently, but terminates the connection when encountered.
2003/12/03 Importance: High Risk: Low Pre-Requisite: ZP15C104
ZP15C107 Script-based commands are all translated to upper-case. While processing LPR requests, commands may be placed in a script. When this script is read, each record is translated to upper-case prior to processing. This is a problem if a value requires mixed-case.
This fix eliminates the automatic up-casing of script input. Note that this may have some unintended consequences if you are relying on this translation for other processing.
2003/12/08 Importance: Low Risk: Low
ZP15C109 "TCP910I Error: No storage available for this request" returned during an LPR function. This message is erroneously issued for a wide variety of conditions involving the LPR "SET VARIABLE" command.
Applying this fix will cause more appropriate messages to be issued.
Unfortunately, the patch area available is insufficient to allow truly descriptive messages to be issued. Each cryptic message, along with an explanation, follows:
"VarNam" - The variable name was not specified.
"NoVal" - The value to be assigned is missing.
"Inv+" - A plus sign was encountered before a value.
"VarNFnd" - A variable was specified as a value, but it is not defined.
"SubVNFnd" - A SUBSTR() variable is not defined.
"NotNum" - The offset or length specification for SUBSTR() is not numeric.
"InvFrm" - The format of a SUBSTR() specification is invalid.
"Miss+" - A plus sign, required to append variables, is missing
"Trunc" - The final data string is too long and would be truncated.
2004/01/13 Importance: Low Risk: Low
ZP15C110 User cannot exit from CICS client panel (PING, email, LPR, etc.) The CLIENT01 phase is executed under CICS control to provide terminal operators with access to TCP/IP-provided clients. Among these are ping, tracert, discover, LPR, REXEC, RSH, and finger (FTP and Telnet services are provided by other phases and will NOT be affected by this fix).
Once users enter the interactive client interface, they may become trapped, with no method to terminate the client interface.
Application of this fix ensures that the command: "QUIT" will be recognized by the client interface itself, and it will immediately return control to CICS.
Notes:
The patched CLIENT01.PHASE must be loaded into your CICS partition before the change can take effect.
This fix updates "VERCHECK.PHASE" to indicate that it has been applied, and the "QUERY VERSIONS" command can be used to verify this fact. HOWEVER, since CLIENT01 executes in a CICS partition and NOT in the TCP/IP partition, its status is NOT verified at execution time. Please be sure that CICS has access to the patched phase.
2004/01/14 Importance: Medium Risk: Low
ZP15C111 "IPN166E Application Program Abend, Phase: IPNATELN Offset+BA4" The Telnet client (NOT the Telnet Daemon) can release control to the dispatcher without releasing certain internal locks. However, when control to returned, the locks are still held and processing resumes normally.
If a second instance of IPNATELN is running simultaneously, it will believe that its own requested locks are in the proper state. This will be true except under the rare condition that it also releases to the dispatcher simultaneously with the first instance, and the first instance explicitly releases the locks. On the next dispatch of instance two, it will be running without the locks. A lock condition test will then fail and a program check is forced.
This fix replaces the IPNATELN phase with one that now properly releases and reacquires its locks when it interfaces with the dispatcher
2004/01/22 Importance: Medium Risk: Low
ZP15C112 Error: Variable substitution caused truncation This problem occurs when a variable occurs as the final characters in an LPR command. The variable substitution routine continues scanning beyond the end of the line, causing an erroneous overflow condition.
This fix eliminates the problem
2004/02/05 Importance: Low Risk: Low
ZP15C113 PRINT command leaves translate table in invalid state. When issuing multiple PRINT commands within a single session, the translate table is not in a usable state following the first PRINT operation. Including a SET TRANSLATE following the PRINT command circumvents this problem.
This fix causes the translate table to be preserved during the PRINT operation.
2004/02/04 Importance: Low Risk: Low
ZP15C114 IPN166E ... Abend, Phase: IPNIGARB ... Offset: 165A TCP/IP periodically tests inflight socket requests to ensure that the requesting program has not terminated without canceling the socket operation. One test requires access to the external program's COMMREG. The ABEND occurs when a a program running in a dynamic partition ends and the former COMMREG area is released and then reallocated as fetch-protected storage.
This fix puts IPNIGARB into key 0 prior to checking the expected COMMREG area, eliminating the protection check abend.
2004/02/02 Importance: Low Risk: Medium
ZP15C115 IPN694I Datagram dropped due to TTL Each IP datagram carries a 1-byte "time to live" (TTL) field. Although this value is designated in seconds, in practice it is decremented each time the datagram is routed to another host. Thus, the field is actually a "hop counter".
In either case, whenever the field reaches zero, the datagram must be discarded. The original reason for this was to get rid of "old" data. It's practical purpose is to prevent routing table "loops". It is also what makes "trace route" work.
The message addressed in this fix is issued each time TCP/IP for VSE discards a datagram due to its TTL reaching zero.
Normal, non-looping, behavior will still cause this message to be issued from time to time, causing unnecessary operator excitement.
This fix will suppress the message, which will be placed under control of a DIAGNOSE flag in a later release.
2004/02/05 Importance: Low Risk: Low
ZP15C116 Program check abend during shutdown (This is a correction to version 1 of this fix, which failed to apply due to an incorrect offset.)
To maximize the multi-tasking ability of the Turbo Dispatcher and to ensure the integrity of non-user key storage, TCP/IP uses STXIT processing to intercept, validate, and perform updates to non-user key storage.
During shutdown processing this facility terminates. Depending upon timing, some processing that depends on this facility may occur after its termination, resulting in a program check abend.
This fix allows normal processing to continue until much later in the shutdown process and prevents unnecessary abends.
2004/02/08 Importance: Low Risk: Low
ZP15C117 Message "IPN903E FREE LENGTH (..) IS WRONG" followed by "IPN907E xxx, IBBK0x". Under some circumstances, an IBBLOK (which contains a datagram and supporting information) must be copied. IBBLOKs are pre-allocated in several fixed lengths and are selected by size needed.
The problem occurs when the physical length of the IBBLOK being copied differs from that of the target IBBLOK. When normal cleanup attempts to release the IBBLOK, the size is found to be incorrect.
This fix preserved the physical length field in the IBBLOK.
2004/02/08 Importance: Medium Risk: Medium
ZP15C118 The two CICS transactions, FTPC and FTPW "lock-up" and cannot be stopped. When the CICS 'DF' temporary storage queue has been defined as recoverable, use of the FTP client will cause a "hang" situation. This is because the FTPC and FTPW transactions share a common, default resource name.
This problem can be circumvented by defining the default CICS "DF" temp storage queue as non-recoverable.
This fix provides each transaction a unique TS resources name, outside the DF queue.
2004/02/19 Importance: Medium Risk: Low
ZP15C119 Program check in IPNACMLP when input includes either "SET LRECL=" or "SET BLKSIZE=". A CVB instruction specifies the wrong register.
This fix corrects the problem.
2004/02/09 Importance: Low Risk: Low
ZP15C120 "IPN222E System Loop detected" during TCP/IP shutdown. If a call is made to the internal DNS client while TCP/IP is shutting down, a system-status test can cause the client to loop.
This fix causes the client to return a "not found" condition when invoked during system shutdown processing.
2004/02/10 Importance: Low Risk: Low
ZP15C121 Unwanted "PWD" command after "CD" and "LCD" The FTP client automatically generates a "PWD" (Print Working Directory) command following each "CD" and "LCD" command.
Normally, this simply provides feedback as to the current directory. However, some security implementations restrict the use of "PWD". Also, not all FTP Daemons support "PWD". In either of these cases, the failure of the "PWD" command causes a non-zero return code in FTPBATCH and EXEC FTP.
This fix removes the unnecessary "PWD" command. It can still be explicitly issued by the user.
2004/02/16 Importance: Optional Risk: Low
ZP15C122 The CICS transactions, TELC, TELR, and TELW, "lock-up" and cannot be stopped. When the CICS 'DF' temporary storage queue has been defined as recoverable, use of the Telnet client will cause a "hang" situation. This is because the transactions share a common, default resource name.
This problem can be circumvented by defining the default CICS "DF" temp storage queue as non-recoverable.
This fix provides each transaction a unique TS resources name, outside the DF queue.
2004/02/19 Importance: Medium Risk: Low
ZP15C123 Using the PASSWORD= parameter on DEFINE EVENT causes the DEFINE command to be ignored. Specifying PASSWORD= caused an improper branch. This fix corrects the problem
2004/03/09 Importance: Low Risk: Low
ZP15C124 FLUSH command causes program check Issuing a flush command against a connect that is "owned" by a program not running in the TCP/IP partition, can result in a protection exception.
This fix ensure that TCP/IP is in the correct key prior to modifying an SOBLOK residing in the SVA.
2004/03/02 Importance: Medium Risk: Low
ZP15C126 Storage subpool NFPOWO increases in size until the TCP/IP partition fails. When an attempt is made to access a non-existant POWER LST queue entry, a temporary work area is left allocated.
This fix ensures that the work area is always released.
2004/04/02 Importance: Medium Risk: Medium
ZP15C127 Idle connection is closed with "IPT317I Response time-out resetting connection" Idle connections are probed at intervals to ensure that the remote host is still active and available. This is done by retransmitting a byte of data, requiring the remote stack to resend an ACK.
When setting up the probe, the IP headers fields are not always being cleared. Since most fields are explicitly set, this is seldom a problem. However, if any residual data appears in the "fragmentation" flags or offset, this may inhibit the remote host from sending the required ACK.
This fix ensures that all IP header fields are cleared at the start of processing.
2004/08/18 Importance: Medium Risk: Low
ZP15C201 FTP fails due to improper translation of control information. FTP data and control connections use translation independently. Translation between EBCDIC and ASCII over the (telnet) control connection uses the translation table specified by the SET TELNET_TRANSLATE= command. If this command is omitted, the default translation table is used.
It is particularly important that the forward and backward "slash" characters be accurately translated, since the various EBCDIC code pages assign different values to these symbols, among others.
This fix corrects a problem that causes the wrong translation table to be used when SET TELNET_TRANSLATE= is specified. Observed errors include the inability to login and the failure of commands that specify a file path. All FTP operations, including batch, are affected.
2003/10/28 Importance: Medium Risk: Medium
ZP15C202 GET of a empty file fails with non-zero return code A GET of a empty file from a foreign ftp server by default will fail with a non-zero return code. The ZEROERR=NO parmdata must be specified when using the // exec ftpbatch program to allow a GET of a empty file to complete with a return code of zero. The ZEROERR=NO must be specified on the DEFINE FTPD command when using the // exec ftp program to allow a GET of a empty file to complete with a return code of zero.
2003/11/10 Importance: Medium Risk: Medium
ZP15C203 Sockets not reused, CLOSE fails after GIVESOCKET, ABEND in IPCICSRQ. This fix corrects 3 different problems for applications using the BSD/C API.
1) The BSD/C interface retains socket control blocks for one minute following CLOSE. This is to allow any residual processing time to complete. This delay is not always necessary and can adversely impact the performance of applications that do not require it. This fix allows the system administrator to to specify the delay time to be used. This is accomplished via the "CSRT=" keyword of the SOCKOPT MACRO instruction. The default value remains at 60 seconds.
2) A BSD/C CLOSE following a GIVESOCKET may fail with a ERRNO 1117. A CLOSE following aa successful GIVESOCKET will now be successful.
3) An ABEND may occur in a BSD/C application running under CICS. This has been corrected.
This fix consists of replacements for the SOCKOPT MACRO, two phases, and the following object decks:
IPNRTAKE,IPNRSOCK,IPNRAIO2,IPNRACCP.
If your application includes any of these object decks, you will need to relink it for this fix to take effect.
2003/11/25 Importance: Medium Risk: Medium
ZP15C204 GiveSocket() or TakeSocket() fails A GiveSocket() may fail with errno=17 (x'11') or errno=118 (x'76'). This may happen when using IBM's CICS Web Services or any other application program that uses the GiveSocket function.
A TakeSocket() may fail with errno=17 (x'11') or errno=118 (x'76'). This may happen when using IBM's CICS Listener or any other application program that uses the TakeSocket function.
2004/01/15 Importance: Medium Risk: Medium
ZP15C205 AutoFTP fails when more than 12 variables are defined. AutoFTP uses a fixed table that can only contain a maximum of 40 variables. Of these, POWER and other pre-defined variables occupy 27 slots, leaving only 13 dynamic variables for a customer to define. This table will be increased in future releases.
If additional user-defined variables are required, this fix will remove the following POWER variables: &PWROFCB,&PWROUCB,&PWRPRTY,&PWRSID,&PWRNODE &PWRPRGN,&PWRROOM,&PWRDEPT,&PWRBLDG,&PWRPCNT, and &PWRLCNT.
Once this fix is applied, the number of entries available for user-defined variables is increased to 24.
2003/12/18 Importance: Optional Risk: Medium
ZP15C206 Records missing after using FTP to write into a VSAM KSDS when the source file contains out-of-sequence records. If the records in the source file are in EBCDIC key-sequence, the store works successfully. However, attempting to store records that are out-of-sequence (which includes records sorted in ASCII), would cause some records to be lost.
After applying this fix, when a sequential insert fails, the message: "IPF307I VSAM KSDS File switching from Skip Sequential to Direct" will be issued. At the same time, processing will switch to direct mode, and all records will be correctly stored.
This fix consists of a replacement for IPNFKSDS.PHASE.
2004/01/13 Importance: High Risk: Medium
ZP15C207 Parm SYSLOG=ON does not work The SYSLOG=ON parameter of the PARM= data passed on the execute ftpbatch card or PARMDATA of the ftpbatch.L book should cause all messages to be written onto the console. This was not working, and is now corrected with this zap.
2004/01/14 Importance: Medium Risk: Medium
ZP15C208 CIALCERT fails with reason code GCRSBOIL The subject of a certificate contains information defined by the ASN.1 Object Identifiers (OID) specification. If a certificate containing an "undefined" 10-byte OID is encountered, the CIALCERT job will fail.
This fix causes CIALCERT to accept any value as the OID and it will accept and store the certificate.
2004/01/22 Importance: Medium Risk: Medium
ZP15C214 Protection exception abend when invoked from REXX A protection exception may occur when invoking ftpbatch from a IBM REXX program because of access register 2 not being cleared.
2004/06/04 Importance: Medium Risk: Medium
ZP15C215 AUTOFTP SET &ERROR = "IGNORE" does not work. The autoftp should be able to ignore a error and execute the next ftp command, but the error occurred flag was not being reset.
2004/06/04 Importance: Medium Risk: Medium
ZP15C301 Erroneous "hacker attack" messages are produced and IP addresses are locked-out of the system. When a web browser sends several null requests in a row, the HTTP Daemon may incorrectly interpret this as as a "port scanning" activity and bar the IP address from further access.
Scan detection is controlled by the DEFINE HTTPD "SCANBLOCKER=YES/NO" parameter. This fix restores the Daemon's default behavior to that of previous releases. You may still enable "scan blocking" via the parameter.
2003/10/20 Importance: Medium Risk: Low
ZP15C302 Client takes 15 seconds to terminate. Note that the patch offset has been corrected since this fix was originally published.
When an EVENT initiates (eg, autoLPR), the batch client (EXEC CLIENT) runs, or a program issues a socket call for CLIENT, the session takes 15 seconds to terminate. This is due to the failure of the underlying process to indicate its completion to the interface.
This fix drops the wait to 1 second. If, after applying this patch, you notice poor behaviour of LPR or email processes (failures, unexplained retries, etc.), back-off the patch. Note that this problem has been corrected for service level D, but is too extensive for a patch.
2004/01/06 Importance: Optional Risk: High
ZP15C500 FTP BIM-EDIT interface does not work. When attempting to FTP to the BIM-EDIT library, abends or message:
IPF708W Unable to load BIMEOPTN.L config file. Using defaults
followed by message:
IPF706W Cannot process BIM-EDIT request. BIM-EDIT is down
This fix will correct the problem
2003/12/16 Importance: Medium Risk: Medium
ZP15C501 DNS resolution fails to resolve names that are not fully-qualified. If more than one DNS server is being used, the "DEFAULT_DOMAIN" is not being appended to requests that are sent to any but the first server entry.
This fix corrects the problem.
2004/02/17 Importance: Medium Risk: Low
This page and all materials residing on this site Copyright© 1996, 2008 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© 2008 CSI International