SUMMARY OF REVISION A.09 CHANGES

COMPUTER NETWORK INTERFACE (CNI/32)

The following updates were introduced at the A.09 revision level:

  1. The TCP/IP stream handler (CP$STR) has been modified to validate acknowledgement sequence numbers within the range of unacknowledged operations. If an OPB is received containing an invalid acknowledgement sequence number, an error message will be printed on CO and the CNI link will be restarted and resynchronized. This error message has the following format:
  2. LINK lnk ACK OVERRANGE ERROR ASQ= aaa OSQ= ooo TSQ= ttt

    Where lnk = name of the CNI link

    aaa = oldest operation waiting acknowledgement

    ooo = sequence number received in error from the OPB

    ttt = newest operation transmitted

    This change required a change to the CNI equates and configuration macros to provide an additional link table variable to count ACK sequence errors.

     

    BACKGROUND INFORMATION:

    The CP$STR (TCP/IP stream handler) can send a limited number of operations before requiring any acknowledgement. The operation header (OPB) of each operation is stamped with a sequential transmit number and the time when transmitted. The reception of the operation must be acknowledged within a specific time interval.

    CNI in the receiving CPU acknowledges an operation by placing the operation=s transmit sequence number in the acknowledgement sequence field of the header of any OPB ready to be transmitted back across the link. Multiple operations in a contiguous sequence may be acknowledged with a single OPB by returning the transmit sequence number of the last (most recent) operation in the sequence. If CNI is ready to acknowledge an operation and no operation is available to send, a CNI link sequence function OPB will be used. Transmit sequence numbers increment sequentially, starting at 0 and then wrapping back to 1 after the maximum value of 255 is used. 0 is always valid and reserved to force the receiver to begin a new set of sequence numbers, such as when a CPU or CNI is restarted.

    OPBs transmitted but never acknowledged are automatically acknowledged and removed from the link queue if matching status return operations are received within the link acknowledgement timeout period.

  3. To save memory, error text and associated routines have been eliminated for the resident version of CP$STR.
  4. An instruction error in CP$STR that cleared OPBIND rather than LNKCUR after transmission of an OPB has been fixed. This could prevent the removing of an operation from a link queue and blocking further transmissions. OPBs may accumulate and possibly cause CNI to run out of OPBs, which is fatal.
  5. Assembly option $SE and code was added to simulate errors using the CPU switch register for debugging versions. This code is not released in production versions.
  6. CN$FUN was changed to eliminate queueing of multiple probe responses to be returned to the same CPU. Only the most recent probe is valid, so old probe responses waiting to be sent back to the originating CPU are deleted when a newer probe request is received. This prevents the CNI fatal error of running out of OPBs when probes are being received but the link is not able to return them.
  7. An error was corrected in the RCVOPB routine in CN$LCP where code is used to match a received status return OPB with a previously transmitted OPB waiting in the pending queue (where a match should always be found). The coding error could have caused an application to hang forever with an outstanding CNI operation.

 

SUMMARY OF REVISION A.08 CHANGES

COMPUTER NETWORK INTERFACE (CNI/32)

The following updates were introduced at the A.08 revision level:

  1. The Ethernet TCP/IP Stream Handler in CNI has been enhanced to provide more robust recovery when a remote node has been disconnected or restarted. Sometimes the local CNI would not detect and recover from this condition. This was corrected by adding timing to acknowledgements of outbound packets. When a remote node stops acknowledging packets, even though the IPCs may still have the communications link established, the local CNI will begin a reconnection and resynchronization process to reestablish the link. If the remote CPU or CNI is not operating, the local CNI will report a Link Synchronization Timeout Error, if link message reporting is enabled, and continue trying to reestablish the connection. This module, CP$STR, was actually released as a patch at A.07A on 05/24/96.
  2. CNI would not correctly process data chain writes. This was corrected in MX$FUN. Additional corrections were added to MX$ROP to detect invalid data chains and data chains exceeding 32,768 bytes. An error of #8100 will be reported in the UFT Status word and the reason code @DC will be returned in UFT Byte Count for locally recovered operations. If system recovery I/O is used, the task attempting illegal data chain I/O through CNI will be aborted by CNI with reason codes OTH DC.
  3. CNI/32 suffered from a generic MAX/32 problem. This occurred when a task with a map level 2 queued I/O and then was reduced to a 1 level map due to deallocation of memory before the 2 map level I/O was completed. The I/O would appear to hang since the handler would try to update the UFTSTA using the second level map pointer in the node rather than the current 1 level map. This has been corrected in CNI/32 by forcing it to allocate at least enough memory to always remain in a level 2 map. This extra memory will be available for dynamic buffer allocation, but CNI/32 will never deallocate the pool below the minimum to remain in a 2 level map. This problem only affected small CNI/32 configurations and was eliminated by making TOC32 allocate extra memory. Now CNI/32 ensures that adequate memory is always allocated.
  4. Link error messages were added or made more consistent in the half and full duplex link handlers, CP$HDX and CP$FDX.
  5. The JM overlay $REM,,PAS command has been corrected to perform multiple sets of pathfile assignments. This change occurred in the overlay module R0AREM.
  6. The OC overlay /REM,,FIL usually omitted information in the "TO" columns. You could tell where the assignment originated but not where the destination was. This was fixed in the overlay module R$EM:A.