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 Fixes for TCP/IP Release 1.5 Service Pack F
Symptoms,
Sorted by Issue Date
Symptoms,
Sorted by Component
Fix Descriptions,
Sorted by Number
Download a file
with all fixes
Download Service Pack F
with fixes pre-appliedCarefully examine each fix for applicability before using it.
Fixes marked with "*" have been pre-applied to the currently available distribution file.
Fixes Sorted By Issue Date (Newest to Oldest):
Fixes Sorted By Component:
All Fixes by Issue Number:
Fix Symptom/Description Issue Date IBM APAR
ZP15F002* Connections fail when datagrams are fragmented When datagram fragments are reassembled to obtain the complete datagram, certain routing fields are not carried to the finished datagram. This causes subsequent improper routing of the return ACK.
Since the ACK is not received by the sender, the fragmented datagram will be retransmitted a number of times until the sending stack times-out the connection.
This fix corrects the problem.
2009/11/12 PM06470 Importance: Medium Risk: Low
ZP15F003* Queued connections time-out earlier than specified A queued connection that is not claimed by an application before the timeout interval has elapsed is terminated as being stale.
An error in the connection manager can falsely trigger the timeout when an extraneous datagram arrives from the remote host. "Extraneous datagrams" include the probes that some Windows-based stacks send after 3 seconds.
This fix corrects the problem.
2009/11/30 PM06470 Importance: Low Risk: Low Pre-Requisite: ZP15F192
ZP15F005* Program check in CTCA link driver during shutdown During shutdown, all executing channel programs for the CTCA must be ended.
In z/VSE 4.3, the PUBX control block was moved to 31-bit storage. Since the code that halts the I/O is running AMODE 24, a program check results.
This fix causes the PUBX to be referenced while in AMODE 31.
2010/02/19 PM13088 Importance: Medium Risk: Medium
ZP15F006* IPN166E Application Program Abend in SOCKPASS The SOCKPASS phase is responsible for returning all socket completions to the requesting external callers. Before accessing storage in the requestor's partition, SOCKPASS performs a variety of tests to ensure that the caller is still executing and that the target area is still valid.
An exceptional condition can occur when the external caller or partition changes status between the instructions that check the validity and the instructions that move the data. Usually, this does not happen unless the TCP/IP partition is executing at a lower priority than the application's partition and SOCKPASS has code to protect it from even this low-probability event.
We now find an uncommon situation that can cause SOCKPASS to program check. This will occur when the requestor's TIB no longer resides in addressable storage.
Applying this fix will cause an interrupt "trap" to be set prior to accessing the external task's TIB. If the TIB address is invalid, an appropriate message will be issued, the socket will be dropped without posting, and normal processing will continue.
Notes:
- It is important that programs do not abandon socket requests until they are posted complete. This is especially true of requests running under CICS, since this can result in CICS storage corruption.
2010/01/13 PM06470 Importance: Medium Risk: Low
ZP15F008* IPL130I Link Level RAW Retransmitting A too-restrictive timer test can cause the IPNET link driver to erroneously believe that a data packet was lost. The attempt to retransmit the packet can then cause the link to fail.
This fix adds redundant checking to ensure that the packet has actually been lost.
2010/02/18 PM13088 Importance: Medium Risk: Low
ZP15F009* Datagrams passed via an IPNET link are not correctly routed Inbound datagrams are not correctly stamped by the IPNET link driver upon entry to the stack. If a connection relies on this value to return its response, the outbound datagram may be misrouted.
This fix adds the appropriate source routing information to the inbound datagrams.
2010/02/18 PM13088 Importance: Medium Risk: Low
ZP15F011* Outbound UDP datagrams with no source IP address Under some circumstances, it is possible for UDP datagrams to be constructed with a null source IP address.
This fix ensures that the source IP address will be set to the home IP address of the sending LINK or ADAPTER.
2010/03/16 PM13088 Importance: Medium Risk: Low Pre-Requisite: ZP15F144
ZP15F012* Stack hangs or malfunctions in a strange manner Although protected by a locking mechanism, an internal message routing routine was coded with a single instruction that falls outside the scope of the lock. Depending on timining, and especially during heavy FTP loads, this error can permit a subtask to have its registers scrambled which can then cause the stack to "hang".
This fix moves the instruction to within the scope of the lock.
2010/04/02 PM13088 Importance: High Risk: Low Co-Requisite: ZP15F013
ZP15F013* Stack hangs or issues "lock not held" message The Connection Block service routine can be called from multiple subtasks. Because of this, it is protected by a locking mechanism. However, after the lock is released, a lock-token pointer is cleared.
Under rare circumstances, this area can already be in use by a previously-waiting task, which can cause additional problems.
This fix moves the token to a register and clears the pointer before the lock is released.
2010/04/02 PM13088 Importance: High Risk: Low Co-Requisite: ZP15F012 Supersedes: ZP15F146
ZP15F014* IPN166E Appl Prog Abend... Phase: IPNTYTCP Under very rare circumstances, a critical storage address is being overlaid. This causes a compare-and-swap instruction to specify an odd address as a target. The result is a specification exception and abend.
The condition that causes the storage overlay requires that an IBBLOK be released and that the high two bytes of its address be equal to the low two bytes of the address of the connection block that owns it. The low two bytes of the IBBLOK's address must also equal a specific, but random, value.
This fix removes the possibility of storage overlay and allows processing to continue normally.
2010/04/23 Importance: High Risk: Low Pre-Requisite: ZP15F257
ZP15F016* SOBLOK dumped and error returned to UDP application The UDP protocol does not negotiate OPEN and CLOSE for a connection. When an application issues a CLOSE, the UDP connection simply ceases to exist.
Previous releases of TCP/IP permitted a SOCKET ABORT request (similar to TCP), but this was not carried through to 1.5F.
This fix restores the ability for an application to issue a SOCKET ABORT request. When issued, all outstanding socket requests will be posted as complete-with-error (SRCODE=8) and then the ABORT request will be posted as successful (SRCODE=0)
Notes:
- Since UDP has no concept of "window", outbound data is always sent as soon as it is queued. Therefore, only RECEIVE sockets will be posted when an ABORT is issued.
- Since UDP has no concept of "reset" or "ACK", there is no way that a remote host can know when a connection has been aborted (or closed). Any inbound data on an "aborted" (or closed) UDP connection is simply discarded. This can result in large amounts of bandwidth and CPU being wasted to receive and discard unwanted data.
2010/05/21 Importance: Low Risk: Low Pre-Requisite: ZP15F144
ZP15F101 DNS look-up fails
UDP connection failsOutbound UDP datagrams (used for DNS look-up) do not properly resolve the ARP (MAC address) of the DNS server or gateway. This causes the DNS look-up to fail.
Once any other access is made to the first "hop" on the path to the DNS, the ARP address is resolved and all future calls function correctly. Unless your DNS resides on the local Ethernet, any traffic that uses your default gateway will prevent the problem.
The problem may be circumvented by including a PING to the DNS in your initialization deck. To do this, add an "INCLUDE member,DELAY" statement to your init deck ("member" is the name of the L-book that contains the "ping").
2008/03/06 PK33472 Superseded by: ZP15F144
ZP15F102 Telnet Daemons attempt restart during shutdown Stage 1 shutdown processing is divided into two parts, A and B. Part A flags all connection to close. Part B flags all Daemons to close.
The problem occurs when a large number of closing connections permits the Telnet Daemons sufficient time to "recover" from the connection-closed condition and attempt to reset to a listen state.
This fix causes the Telnet Daemon to check the system's "quiesce" state, and proceed to shutdown.
2008/03/07 PK33472 Superseded by: ZP15F219, ZP15F202
ZP15F103 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).
2008/05/29 PK67333 Superseded by: ZP15F532
ZP15F104 Abend in IPNACONT phase, possibly others. The IPNFPOWR File I/O driver sets a timer to ensure that OPEN processing completes in a reasonable time.
The timer is not canceled and may post the ECB after its storage has been reused for other purposes.
This fix cancels the timer once the OPEN completes.
2008/04/24 PK67333 Superseded by: ZP15F335, ZP15F355, ZP15F357, ZP15F365, ZP15F395
ZP15F105* BSD Asynchronous I/O Active OPEN requests fail When an asynchronous I/O Active OPEN requests completes normally, TCP/IP is passing the socket number as the return code. This is required for Passive OPENs but not Active ones.
This fix causes successful Active OPENs to return a code of 0.
2008/04/24 PK67333 Importance: Medium Risk: Low
ZP15F106* IPN166E Applic. Prog. Abend Phase: SOCKPASS, Offset:14BE Before returning data to an external application, TCP/IP applies several tests to ensure that the original socket requestor is still executing.
One of these tests is to check the "job start time". If the value has changed since the socket request was issued, the operation is canceled and message IPN855I is issued.
This message shows the expected and found time values.
The abend occurs because an invalid work area address is being passed to the System GETIME routine.
This fix causes a proper work area to be passed to the GETIME routine.
2008/04/29 PK67333 Importance: High Risk: Low
ZP15F107 BSD-based connections fail at initiation Connection-related control blocks are located by means of a unique identifier, set during OPEN processing. Normally, this identifier is assigned when control blocks are allocated. However, this is not possible for "queued connections", since the identifier is not known until the connection block is paired with an OPEN request.
The problem occurs when BSD processing issues a STATUS call for a LISTEN that has just been paired with a queued connection block. If the asynchronous processing involved has not yet updated the hash tables with the new identifier, the STATUS request will fail with a "connection not found" error.
This fix causes the hash tables to be updated at the point of assignment so that subsequent STATUS calls will be able to locate the appropriate anchor block immediately.
2008/05/07 PK67333 Superseded by: ZP15F148
ZP15F108 Incomplete command output
Shutdown not clean/completeAn internal table contains the address of each running pseudo task. Various processes (command and shutdown processing) use this table to iterate through all running tasks. The length of this table is being incorrectly set which means that processes that "run the table" stop too soon and miss some tasks.
This fix corrects the table length constant.
2008/05/14 PK67333 Superseded by: ZP15F114
ZP15F109* "Version mismatch" error message after applying ZP15F202 An internal fix marker was not properly set in the phases provided with ZP15F202. Phase load processing notes that the value contained in the phase is not the expected value, and issues a warning message.
This fix corrects the phases' internal identifiers.
2008/05/14 PK67333 Importance: Low Risk: Low Pre-Requisite: ZP15F202
ZP15F110 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 PK67333 Superseded by: ZP15F136, ZP15F139, ZP15F192
ZP15F112 All stack processing halts during TCP/IP console display operations A piece of debugging code was not removed prior to creating the 1.5F installation job. This code causes the stack's internal dispatcher to serialize console messages at every pass.
Under normal conditions, this causes no delays since there are seldom messages queued for display.
However, if a long display is being produced (eg, QUERY ALL) or if some external process causes a console buffer shortage, TCP/IP processing can be severely impacted. One process known to be involved is the VSE ConnectorServer.
This fix removes the debugging code that causes the serialization.
2008/05/29 PK67333 Superseded by: ZP15F114
ZP15F114* Various timer problems
Failure to pulse connections
Failure to execute in "demo" mode
Fixed-point divide exceptions
Hanging tasks and processes
"ADDIP failure" message and stack failureProblems have been encountered during the conversion of large timer values. Depending upon the point where the problem is encountered, the failure may be trivial or unrecoverable.
This fix corrects the problem.
An additional problem can occur if an internal connection-locator hash table fills. Although this has only been reported once, this fix adds code to periodically validate the hash table contents and remove invalid and obsolete entries.
2008/07/11 PK70370, PK71366 Importance: Medium Risk: Medium Supersedes: ZP15F108, ZP15F112
ZP15F115* Inbound connection requests receive RST instead of connecting Hash tables are used to efficiently locate connection blocks based upon datagrams' IP addresses and ports. The problem occurs when an inbound SYN request causes a hash entry based on the stack's default IP address (SET IPADDR=) instead of the IP address that belongs to the Link being used. Future inbound datagrams on the connection are then "reset" because the appropriate hash table entry cannot be found.
This fix corrects the problem.
2008/07/11 PK70370, PK71366 Importance: Medium Risk: Low Co-Requisite: ZP15F116
ZP15F116* Inbound connection requests receive RST instead of connecting Continuation of fix 115
2008/07/11 PK70370, PK71366 Importance: Medium Risk: Low Co-Requisite: ZP15F115
ZP15F117 Connections "reset" after normal completion TCP connections are completed normally if and when each side has sent a FIN and had it acknowledged.
Two problems exist in this area.
Once a FIN has been received from the remote host and our own FIN sent, the connection manager does not always wait for an acknowledgement. This can cause a problem if a retransmission were to be required. However, this would be very seldom, since the packet length is quite small.
The second problem is that the connections manager terminates immediately following exchange of FINs and the connection control block is destroyed at the same time. If the remote host sends an extraneous ACK following this, it will not be associated with a connection and will be replied to with a RESET.
This fix corrects both problems. The connection manager will not terminate until an ACK has been received for its FIN (standard retransmission logic will apply). Additionally, a two-second "grace period" will be added to each connection to allow for receipt of a tardy ACK.
Notes:
- No perceived delays are introduced by this fix. Responses to both the application and remote host occur as before.
2008/07/11 PK70370, PK71366 Superseded by: ZP15F136, ZP15F139, ZP15F192
ZP15F118* Message IPN283I appears on operator console This message is assigned to class "DIAGNOSE" and is also flagged as "No Console". However, the message does get displayed on the operator's console if it is set to receive the "DIAGNOSE" message class.
The display of this message may be considered a nuisance. If so, this fix will correct the message's behaviour and send it only to SYSLST.
2008/07/11 PK70370, PK71366 Importance: Low Risk: Low
ZP15F119 Program check during execution of QUERY IBBLOK command. During execution of this command, the stack attempts to display the percentage 31-bit storage available for IBBLOKs. This results in division by zero when no 31-bit storage is allocated to the partition.
This fix will cause the display to show the percentage relative to 24-bit storage when no 31-bit storage is allocated.
2008/07/20 PK70370, PK71366 Superseded by: ZP15F257
ZP15F120 "Lost" connections not detected. Connections that do not have data moving across them are normally probed at the interval specified by "pulse time".
A problem occurs when the time of the last inbound data is updated without receipt of data. This prevents generation of a probe and possible detection of a lost connection.
This fix corrects the problem.
2008/07/23 PK70370, PK71366 Superseded by: ZP15F136, ZP15F139, ZP15F192
ZP15F121 FTP351W and FTP352W messages after applying fixes to stack. FTPBATCH checks the versions of loaded phases against the expected versions, as provided by the stack.
When a phase is replaced as part of a fix, it is erroneously reported as an "incorrect version".
This fix corrects the problem.
Notes:
- This problem is cosmetic only. Except for the messages, FTPBATCH processing continues normally.
2008/07/24 PK70370, PK71366 Superseded by: ZP15F239, ZP15F350, ZP15F259, ZP15F285
ZP15F122* Message IPN379I contains misleading text One of the reasons given by message IPN379I is "Partition start address is inconsistent". This text misleads the reader into believing that something is wrong with the partition.
This fix replaces the reason text with "Application buffer address is invalid."
2008/07/28 PK70370, PK71366 Importance: Low Risk: Low
ZP15F123* Excessive GETVIS usage; Orphaned Telnet connections When using the TN3270E protocol, the Telnet Daemons are divided into two functional groups: listeners and effectors. A "listener" initiates a new TN3270E session, negotiates the session parameters, and then passes the connection to the appropriate effector Daemon which then handles the actual session. The listener then issues another passive OPEN and waits for the next user.
A problem can occur when session negotiation fails. For example, when the requested LUName is already in session. Under some circumstances, the TCP connection is not closed before the socket is reused, thus stranding the storage.
This fix causes open sockets to be closed prior to issuing the next OPEN.
2008/07/31 PK70370, PK71366 Importance: Medium Risk: Low Pre-Requisite: ZP15F219
ZP15F124 Application hangs after error If an application attempts to do a RECEIVE and specifies a buffer address of "0", the operation will be suppressed and not posted complete.
This fix causes such a RECEIVE to fail when issued with RC 5, Reason 1.
2008/07/31 PK70370, PK71366 Superseded by: ZP15F172 Co-Requisite: ZP15F127
ZP15F126 SET FCB=*NULL does not set TOF value LPR documentation states that issuing the SET FCB=*NULL command should also result in an automatic SET TOF=0C0D command.
This is because setting an actual FCB causes TOF=NULL to be in effect.
This fix corrects the problem.
2008/08/11 PK70370, PK71366 Superseded by: ZP15F171, ZP15F182, ZP15F183, ZP15F502 Pre-Requisite: ZP15F333
ZP15F127 Program check in Socket interface after applying ZP15F124 An error in ZP15F124 causes a check to be made of a random location rather than the socket parameter list
This fix corrects the problem.
2008/08/11 PK70370, PK71366 Superseded by: ZP15F172 Pre-Requisite: ZP15F124
ZP15F128* IPN166E Application Program Abend ... Phase: IPDRIVER This abend occurs following the issuance of the FLUSH command. An improper use of POST can corrupt an ECB being used by the connection manager.
This fix corrects the problem.
2008/08/12 PK70370, PK71366 Importance: Medium Risk: Low Pre-Requisite: ZP15F114
ZP15F129 Applications that use UDP fail to function Upgrades to UPD processing failed to take into account that socket requests might not include the foreign IP and/or port number.
This fix causes the foreign IP and port to always be assigned their established values.
2008/08/21 PK70370, PK71366 Superseded by: ZP15F130, ZP15F131, ZP15F144
ZP15F130 Failure of UDP-based applications This fix ensures that IP addresses and ports are copied from inbound datagrams to the proper work areas.
Notes:
- Fix ZP15F129 must be backed-out before applying this fix.
2008/08/31 PK74055 Superseded by: ZP15F145 Co-Requisite: ZP15F131 Supersedes: ZP15F129
ZP15F131 Failure of UDP-based applications This fix ensures that IP addresses and ports are appropriately returned to the application. It also causes the values to be shown in Socket Trace entries.
Notes:
- Fix ZP15F129 must be backed-out before applying this fix.
2008/08/31 PK74055 Superseded by: ZP15F144 Co-Requisite: ZP15F130 Supersedes: ZP15F129
ZP15F132 Update of message skeleton file This fix installs a replacement message skeleton phase. It incorporates additional messages and corrections to existing messages.
2008/09/01 PK74055 Superseded by: ZP15F137, ZP15F249, ZP15F364
ZP15F133* Incorrect message. This fix corrects an improper message specification. The message is seldom, if ever, issued. However, this fix should be applied against the possibility of its being required.
2008/09/01 PK74055 Importance: Low Risk: Low Co-Requisite: ZP15F132
ZP15F134* Incorrect statistics reported by message IPT361I. This fix corrects the update of "queued bytes" that is reported by IPT361I.
2008/09/01 PK74055 Importance: Medium Risk: Low Co-Requisite: ZP15F132, ZP15F136
ZP15F135* Excessive CPU usage via PAGESTAT SVC At regular intervals, TCP/IP tests each entry in its connection hashing table. This includes issuing PAGESTAT to determine the validity of each control block.
The PAGESTAT SVC appears to consume more CPU than previously thought. This can be a drain on resources when there are a considerable number of connections active.
Since there are no known issues with the hashing tables, this fix puts the testing under control of DIAGNOSE CLEANUP.
2008/09/01 PK74055 Importance: Low Risk: Low Pre-Requisite: ZP15F114
ZP15F136 Incorrect values in IPT361I message. This fix corrects the IPT361I to indicate the number of IBBLOKs and data bytes that are queued to the connection. The message can occur twice: Once displaying inbound data not yet passed to the application and once displaying outbound data that has not yet been acknowledged.
This fix also adds an "ident" field to both QUERY CONNECTION and DIAGNOSE PERFORM displays. This is a unique identifier for a connection and can be used to associate display information with traced IBBLOKs and sockets.
2008/09/04 PK74055 Superseded by: ZP15F139, ZP15F192 Pre-Requisite: ZP15F132, ZP15F134 Supersedes: ZP15F110, ZP15F117, ZP15F120
ZP15F137 Update for Message Skeleton File This phase replacement provides new, updated, and corrected message skeletons
2008/09/20 PK74055 Superseded by: ZP15F249, ZP15F364 Supersedes: ZP15F132
ZP15F138 STATUS return "normal" after RESET sent This fix causes an RC 8 to be returned for STATUS calls made after a RESET has been sent on the connection.
In addition, several more statistical values updated.
2008/09/08 PK74055 Superseded by: ZP15F148 Co-Requisite: ZP15F137, ZP15F139
ZP15F139 Additional diagnostics and statistics This phase replacement provides new and updated diagnostic messages. It also adds the "Ident" field to most connection-related messages.
Flags are now set to ensure that STATUS requests are notified (RC 8) when a RESET has been sent to a remote host.
2008/09/08 PK74055 Superseded by: ZP15F192 Co-Requisite: ZP15F137, ZP15F138 Supersedes: ZP15F110, ZP15F117, ZP15F120, ZP15F136
ZP15F140 External UDP applications fail Information from the Connection block is being inserted into the Socket block. This is valid and required for TCP connections, but not UDP.
This fix prevents the overlay of non-zero information in the Socket blocks during scheduling.
2008/09/20 PK74055 Superseded by: ZP15F148 Co-Requisite: ZP15F143, ZP15F144, ZP15F145, ZP15F146
ZP15F142 Connection failures As shipped, TCP/IP is configured for a maximum of 5,000 simultaneous connections. If this number is exceeded, it will not be possible to establish and maintain additional connections.
This fix increases the maximum simultaneous connections to 20,000.
2008/09/10 PK74055 Superseded by: ZP15F148
ZP15F143* UDP roll-up fix. This phase replacement consolidates various fixes for the UDP protocol. It should be applied by all installations.
2008/09/20 PK74055 Importance: Medium Risk: Low Co-Requisite: ZP15F140, ZP15F144, ZP15F145, ZP15F146, ZP15F148
ZP15F144* UDP roll-up fix. This phase replacement consolidates various fixes for the UDP protocol. It should be applied by all installations.
2008/09/20 PK74055 Importance: Medium Risk: Medium Co-Requisite: ZP15F143, ZP15F145, ZP15F146, ZP15F148 Supersedes: ZP15F101, ZP15F129, ZP15F131
ZP15F145* UDP roll-up fix. This phase replacement consolidates various fixes for the UDP protocol. It should be applied by all installations.
2008/09/20 PK74055 Importance: Medium Risk: Medium Co-Requisite: ZP15F148, ZP15F143, ZP15F144, ZP15F146 Supersedes: ZP15F129, ZP15F130
ZP15F146 UDP roll-up fix. This phase replacement consolidates various fixes for the UDP protocol. It should be applied by all installations.
2008/09/08 PK74055 Superseded by: ZP15F013 Co-Requisite: ZP15F148, ZP15F143, ZP15F144, ZP15F145
ZP15F147* Extraneous IPN694I message after DEFINE TRACE command An extra debugging message is produced whenever a DEFINE TRACE or DEFINE SOTRACE command is entered.
This fix suppresses the message.
2008/09/20 PK74055 Importance: Low Risk: Low
ZP15F148* UDP roll-up fix. This phase replacement consolidates various fixes for the UDP protocol. It should be applied by all installations.
2008/09/20 PK74055 Importance: Medium Risk: Low Co-Requisite: ZP15F143, ZP15F144, ZP15F145, ZP15F146 Supersedes: ZP15F142, ZP15F140, ZP15F138, ZP15F107
ZP15F149* Excessive CPU consumption This fix will remove a number of diagnostic tests performed for each I/O request. These tests include a PAGESTAT SVC, which consumes an appreciable amount of CPU.
DIAGNOSE FILEIO re-enables the tests.
2008/09/21 PK74055 Importance: Low Risk: Low
ZP15F150* Adds ownership information to FRBLOK This fix adds the requesting program's name, task ID, and requesting address to storage requests made for FRBLOKS. A Q STOR,SPID=FRBLOK will then be able to identify the process that owns the FRBLOK.
2008/09/24 PK74055 Importance: Optional Risk: Low Pre-Requisite: ZP15F114
ZP15F151 24-bit GETVIS depletion When a GPS Daemon is started with the LOG=YES option, an FRBLOK is allocated in 24-bit partition GETVIS. If the Daemon is then shutdown, the FRBLOK is not released.
This fix corrects the problem and ensures that the logging file FRBLOK is released when the Daemon terminates.
Notes:
- This problem can be circumvented by NOT specifying LOG=YES on the DEFINE GPSD command.
2008/09/25 PK74055 Superseded by: ZP15F153
ZP15F152 Excess 24-bit GETVIS in FRBLOK subpool Under some circumstances, the HTTP Daemon is obtaining an "extra" FRBLOK and then not freeing it.
This fix corrects the problem.
2008/09/25 PK74055 Superseded by: ZP15F528
ZP15F153 Alignment errors in GPS reports This phase replacement corrects an error in processing Repeat to Address (RA) orders.
2008/10/01 PK74055 Superseded by: ZP15F190 Supersedes: ZP15F151
ZP15F154* Privileged Operation exception at startup Older releases of VSE do not permit use of Access Register operations without being in supervisor state.
This fix removes an unneeded test for access register mode in the CSOCKET subtask.
2008/10/04 PK74055 Importance: Low Risk: Low Pre-Requisite: ZP15F148
ZP15F155* ILLEGAL SVC error during shutdown This fix eliminates an unneeded DETACH
2008/10/04 PK74055 Importance: Medium Risk: Low Pre-Requisite: ZP15F114
ZP15F156 EWOULDBLOCK(1102) errno not returned on SEND
ECONNREFUSED(1128) errno returned erroneously
Incorrect exception bit set following SELECT callThis fix supplies the updated SOCKOPT macro.
Although this macro was distributed as part of fix ZP15F233, that fix was superseded by ZP15F237.
This fix will allow the IPNRBSDC phase and SOCKOPT macro to be maintained independently in any future fixes.
2008/10/06 PK74055 Superseded by: ZP15F276 Co-Requisite: ZP15F237 Supersedes: ZP15F233
ZP15F157 CLOSE hangs after an ABORT is issued When a socket ABORT is issued on a connection, subsequent socket requests (ie, CLOSE) may fail to complete.
This is a timing issue. Once an ABORT is issued, a RST is transmitted to the foreign host, all queued requests are flagged "complete with error", and the connection is closed. If the ABORT is quickly followed by CLOSE, the request may be lost.
This fix ensures that the CLOSE request will post completion back to the application.
Notes:
- If ABORT or CLOSE is issued with FAST=YES, no pending or subsequent request will be "posted".
- CLOSE must still be issued following ABORT, since it is CLOSE processing that releases the socket's working storage in the application's partition.
2008/10/09 PK74055 Superseded by: ZP15F192 Pre-Requisite: ZP15F139
ZP15F158 Data lost when full-buffered RECEIVE times-out When operating in full-buffer mode, RECEIVE sockets do not complete until either the buffer is filled or a FIN is received.
A problem arises when the RECEIVE also carries a time-out value and the buffer is not filled before the time-out occurs. In this case, the RECEIVE completes as a "time-out" with the returned data length set to zero.
This fix modifies processing so that when a RECEIVE times-out, if there is queued data, it is returned and the SRCODE is set to zero.
2008/10/09 PK77248 Superseded by: ZP15F192 Pre-Requisite: ZP15F139
ZP15F159* Partition SAVE area partially overlaid When the File I/O substask is attached, a parameter is being passed in an incorrect area.
This fix corrects the problem.
2008/10/30 PK77248 Importance: Medium Risk: Low Co-Requisite: ZP15F160 Pre-Requisite: ZP15F114
ZP15F160* Partition SAVE area partially overlaid When the File I/O substask is attached, a parameter is being passed in an incorrect area.
This fix corrects the problem.
2008/10/30 PK77248 Importance: Medium Risk: Low Co-Requisite: ZP15F159
ZP15F161 Socket STATUS returns incorrect data During a passive OPEN (listen), there is a very brief interval where it is possible for a Socket STATUS command to return data that shows the connection is in a "listen" state while certain other fields are not yet finalized. Specifically, this can affect the returned value assigned as "local port".
This fix delays setting the connection status to "listen" until the local port is definitely established.
2008/11/14 PK77248 Superseded by: ZP15F192 Pre-Requisite: ZP15F139
ZP15F162 TCP performance problems This fix corrects several tests involved in closing and opening a connection's SEND window. This will allow the connection manager to take advantage of additional space in the SEND window and will cause transmission to resume more quickly as the window re-opens.
2008/11/24 PK77248 Superseded by: ZP15F192 Pre-Requisite: ZP15F139
ZP15F163* IPN166E Appl Prog Abend Phase: IPDRIVER, Offset: 00001C60 A fixed-point divide exception can occur when converting a large time interval into 300th seconds. This fix adds a test for overflow prior to the conversion.
2008/12/10 PK77248 Importance: Medium Risk: Low Pre-Requisite: ZP15F114
ZP15F164* End-of-connection log records have no timestamp The SeeTCP/IP feature creates an end-of-connection record. The time stamp in this record was not being set. This fix corrects this problem.
Once this fix is installed, you should cycle the SVSESRVR partition.
Notes:
- End-of-connection records created prior to installing this fix will contain an incorrect time.
- The phase included in this fix is the same as supplied by ZP15F210 and will continue to display the "ZP15F210" fix level.
2008/11/25 PK77248 Importance: High Risk: Low Co-Requisite: ZP15F257, ZP15F258 Supersedes: ZP15F210
ZP15F165* IPN166E Appl Prog Abend Phase: IPNATELN When an application using the Telnet Proxy (SOCKET xx,TELNET,...) issues a CLOSE and then terminates before the CLOSE is posted, it is possible for the CLOSE request to be handled twice.
However, validity checks designed to prevent this sort of re-processing come into play and a "preventative" program check is produced.
Processing continues normally, since the validity checks did what they were designed to do.
This fix destroys residual control block pointers to prevent attempted re-processing of requests.
2008/12/10 PK77248 Importance: Low Risk: Low
ZP15F167 Active OPEN fails During the TCP OPEN handshake, the required and permitted sequence is: Outbound SYN; Inbound SYN-ACK; Outbound ACK. Only when this handshake is successfully completed may other packets be sent. [Duplicate datagrams are permitted.]
A problem occurs when the remote host "jumps the gun" and immediately follows its "SYN-ACK" with a bare "ACK". By protocol, it is not permitted to do this, and the offending datagram is responded to with "RST", as required by protocol.
However, the first rule of TCP is that a stack must adhere to the rules itself, but make allowances for those that don't.
This fix modifies the stack's behavior during the SYN exchange to simply discard all datagrams that don't contain "SYN-ACK", without issuing a "RST".
2008/12/10 PK77248 Superseded by: ZP15F192 Pre-Requisite: ZP15F139
ZP15F169 Stack failure following LPR attempt The LPR client fails to recognize when lines are longer than the design maximum for formatted printing, 256 bytes. When "long" lines are encountered, buffer length may be exceeded and unpredictable results can follow.
This fix truncates oversized lines to the design limit of 256 characters.
Notes:
- This does not affect InfoPrint files, which support a line length of 32k and are not formatted by the LPR process.
2008/12/22 PK82194 Superseded by: ZP15F171, ZP15F182, ZP15F183, ZP15F502 Pre-Requisite: ZP15F333
ZP15F170 Application unaware of connection closing A TCP connection assumes a variety of "states", as defined by RFC 793. A problem may occur because TCP/IP is not changing this indicator from "Established" to any of the intermediate states leading up to "Closed".
Although the "state" is maintained for informational purposes only, a problem may arise if an application queries the state and then proceeds based on an inaccurate response.
Once this fix is applied, the "state" will change to "CLOSE-WAIT" when a FIN has been received from the remote host and until a CLOSE has been queued by the application. If a CLOSE has been queued by the application and FIN has not yet been received, then the "state" will be set to "FIN-WAIT-2".
Once a CLOSE has been queued by the application and a FIN has been received from the remote host, the "state" will be set to "TIME-WAIT". This value covers the residual period until the connection is considered to be "closed".
2009/01/05 PK82194 Superseded by: ZP15F192 Pre-Requisite: ZP15F139
ZP15F171 Long line support for LPR This replacement phase adds support for input lines of up to 32,767 bytes.
FCB support has also been corrected to properly position the form following the report. If a value has been specified for "SET EOD=" (0C0D, for example) then that string is used for the final form positioning. If "SET EOD=" is null, then a string of single-line skips is issued until the FCB wraps to top-of-form.
Notes:
- If problems occur, use "SET LONGLINE=OFF" to bypass the modifications.
2009/02/04 PK82194 Superseded by: ZP15F182, ZP15F183, ZP15F502 Supersedes: ZP15F126, ZP15F169, ZP15F306, ZP15F313, ZP15F315, ZP15F318, ZP15F323, ZP15F333
ZP15F172* Random diagnostic messages This replacement phase prevents the issuing of unrequested IPT301D messages. There is also a remote possibility that this problem may also cause a program check.
2009/01/11 PK82194 Importance: Medium Risk: Low Supersedes: ZP15F124, ZP15F127
ZP15F174* ">Undefined<" message after applying ZP15F364 This fix reinstates PDF debugging messages that were removed by an earlier fix and corrects problems introduced by ZP15F364.
2009/01/26 PK82194 Importance: Medium Risk: Low Supersedes: ZP15F132, ZP15F137, ZP15F249, ZP15F309, ZP15F364
ZP15F175 Unable to maintain connections with some hosts During connection negotiation, each host provides a value for the maximum bytes that may be contained in any single datagram. This is the Maximum Segment Size (MSS)
A problem arises when a host specifies a very small MSS that is less than the protocol-specified default of 536. In this case, the lower value is ignored and 536 is used instead.
Sending datagrams larger than the requested maximum will have unpredictable results.
This fix removes the minimum value for MSS, leaving 536 as the default.
Notes:
- Very few hosts (only one seen so far) request MSS sizes below the default.
- For efficiency, MSS should be set to the largest value that does not cause fragmentation (general rule). This is usually 40 bytes less than the MTU size.
- As MSS decreases, network efficiency decreases as well, since smaller MSS values require more datagrams to transmit the same volume of data.
2009/02/04 PK82194 Superseded by: ZP15F192 Pre-Requisite: ZP15F139
ZP15F177* Console messages break instead of wrap To support multiple logging devices, TCP/IP adjusts message lengths based upon values established by DEFINE LOG. When a message is too long, it is divided into multiple lines and a continuation character (>) ends each incomplete line.
When a message is routed to SYSLOG (console), a hard-coded value is being used rather than the DEFINE LOG value. This may cause problems if the message is being trapped by an automation product.
This fix causes TCP/IP to honor the line length established by DEFINE LOG. Since this DEFINE is done automatically, you must override it by using MODIFY LOG, as follows:
MODIFY LOG,ID=CONSOLE,LINELEN=nn
Care MUST be taken that the value specified does not exceed the allowable maximum for WTO, as supported by your version of VSE.
2009/02/05 PK82194 Importance: Low Risk: Medium
ZP15F178* Repeatedly invoking FTP from REXX depletes batch partition storage The FTP batch program relies on the operating system to release storage at program termination. Unfortunately, when called from another process (eg, REXX), this does not occur until the calling process also goes to EOJ.
Each invocation of FTP causes an additional set of storage to be obtained until there is insufficient memory left for it to execute.
This fix adds code to release all storage obtained by FTP prior to returning to the calling program.
2009/02/24 PK82194 Importance: Low Risk: Low
ZP15F179* UDP connections fail when source and target are same stack When a UDP server and client are both running under the same stack, the datagrams will not be correctly matched to the connection. This is due to a problem with multi-homing support.
This fix corrects the problem.
2009/02/24 PK82194 Importance: Low Risk: Medium Pre-Requisite: ZP15F145
ZP15F180* Batch FTP client retains storage in IPSTOR subpool When the Batch FTP Client is called from another routine, is does not release working storage in the IPSTOR subpool. This can cause storage shortages if the FTP phase is repeatedly invoked before the caller goes to EOJ.
This fix causes the IPSTOR subpool to be released and the IPSTORX phase be deleted before FTP returns to the calling program.
2009/03/05 PK82194 Importance: Low Risk: Low Pre-Requisite: ZP15F178
ZP15F181 Reports over 32,760 bytes are truncated "Long line" support added by ZP15F171 introduced a problem that causes file I/O operations to return a premature end-of-file.
This fix corrects the problem.
2009/03/05 PK82194 Superseded by: ZP15F182, ZP15F183, ZP15F502 Pre-Requisite: ZP15F171
ZP15F182 Stack abends when using an FCB with LPR This replacement phase corrects several LPR-related issues including a serious one in FCB support.
Since the problem addressed by this fix has the potential to cause failure of the entire stack, it is HIGHLY recommended that this fix be applied as soon as possible, even if you are not experiencing any problems.
2009/03/24 PK82194 Superseded by: ZP15F183, ZP15F502 Supersedes: ZP15F126, ZP15F169, ZP15F306, ZP15F313, ZP15F315, ZP15F318, ZP15F323, ZP15F333, ZP15F181, ZP15F171
ZP15F183 Improvements to LPR client This replacement phase improves the overall performance of the LPR client, reducing the amount of network traffic.
Additional support is added to allow retrieval of carriage control in MCC format for both InfoPrint and FORTRAN formats.
To retrieve carriage control in MCC format, code "SET CC=MCC" after setting INFOPRINT=ON or ASA=ON.
Notes:
- The CC=MCC setting should NOT be used for actual InfoPrint servers. This feature is intended for use by other processes.
- The corequisite fix, ZP15F358, is required only for use with SET CC=MCC. It need not be applied otherwise.
2009/03/29 PK85862 Superseded by: ZP15F502 Co-Requisite: ZP15F358 Supersedes: ZP15F126, ZP15F169, ZP15F306, ZP15F313, ZP15F315, ZP15F318, ZP15F323, ZP15F333, ZP15F181, ZP15F171, ZP15F182
ZP15F184 Excessive allocation of IBBLOKs When the VSE stack closes its RECEIVE window, some stacks will attempt periodic probes of the connection to ensure that they have not missed its re-opening. If their probe takes the form of an additional byte, sent beyond the current window, then a problem can occur.
Although the VSE stack responds to the datagram with a restatement of the window and the current ACK value (as required by RFC), the errant datagram is then queued for processing behind the data already waiting for a RECEIVE.
If the window remains closed for some time, and if the remote stack probes excessively, then the buildup of incorrectly queued IBBLOKs can seriously deplete 31-bit partition GETVIS and spill into 24-bit GETVIS. This can eventually crash the VSE stack.
This fix will cause the "probe" datagram to be discarded immediately and ensure adherence to RFC 793, as follows:
"...any unacceptable segment (out of window sequence number or unacceptible acknowledgment number) must elicit only an empty acknowledgment segment containing the current