Download Fix File

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.

Download Fix File

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.

Download Fix File

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.

Download Fix File

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.

Download Fix File

Data is being dropped and/or inserted in DBCS strings.

This fix corrects the problem.

Download Fix File

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.

Download Fix File

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.

Download Fix File

This fix causes the "reset" datagram to always have a header length of 20 bytes.

Download Fix File

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.

Download Fix File

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.

Download Fix File

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

Download Fix File

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.

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

Download Fix File

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.

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

Download Fix File

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.

• This fix should be applied IMMEDIATELY if ZP15E115 has already been applied.

Download Fix File

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.

• 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

Download Fix File

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.

Download Fix File

This fix corrects an error that prevents execution of the code responsible for printing File I/O diagnostics and re-attaching the task.

Download Fix File

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.

Download Fix File

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.

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

Download Fix File

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.

Download Fix File

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.

• Under some conditions, FTPBATCH will automatically initiate a "QUERY CONNECTION" command.

Download Fix File

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.

• This routine is only called during the production of other diagnostics.

Download Fix File

Under some circumstances, TCP/IP transmits a reset (RST) request with an invalid checksum.

This fix corrects the problem.

Download Fix File

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.

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

Download Fix File

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

Download Fix File

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.

Download Fix File

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.

Download Fix File

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

Download Fix File

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.

Download Fix File

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.

Download Fix File

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.

Download Fix File

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.

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

Download Fix File

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.

Download Fix 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.

Download Fix File

An incorrect test is being performed on DBCS translation buffers. This fix eliminates the erroneous check.

Download Fix File

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.

Download Fix File

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.

Download Fix File

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.

Download Fix File

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.

Download Fix File

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.