PLXX480D - IR36929 V350 Superpatch for ICP Dec 01, 1998 --------------------------------------------------------------- Note - PLXX480 neglected to pick up CSP3DBL0.MTX from plxx454B. PLXX480B does pick that fix up. PLXX480B replaces PLXX480. --------------------------------------------------------------- Included in this V350 superpatch are - 1. PLXX449B - IR34332 2. PLXX450 - IR34434 3. PLXX453 - DD00453 4. PLXX454B - IR34578 5. PLXX458B - DD00458 6. PLXX460B - DD00460 (this is in plxx470B) 7. PLXX463 - IR35172 (this is in plxx470B) 7. PLX465B - IR35379 8. PLXX471B - IR36157 9. PLXX473 - DD00473 10. PLXX475 - IR36511 11. PLXX476 - IR36602 12. PLXX477 - IR36675 13. PLXX478 - IR36718 14. PLXX484 - IR36863 15. PLXX490 - IR37207 16. PLXX495 - IR37592 17. PLXX497 - IR37619 ----------------------------------------------------------------------- PLXX497 is a V3.5.00 patch which reapplies the following task CSP2CHD0.MTX - Escon single slot driver Problem - With a large configuration, the 'get statistics' buffer is too large and overwrites the next buffer, causing an 1101. The Fix - The code was changed to allow the 'get statistics' message to use a larger buffer. March 30, 1998 ----------------------------------------------------------------------- PLXX495 - V350 ICP for the 1000 APAR = IR37592 EtherStreamer Task (CSP2ETC0.MTX) Problem occurs when wrapping a frame back to the host software. Only on Etherstreamer. Module is 2.c-WrapFrame(). We saw this problem with 2 parallel channel adapters, both going to one etherstreamer. Host A could not ping Host B. Since an ethernet adapter cannot transmit and receive the simultaneous frame, the etherstreamer driver will "wrap" the same frame back to the mainframe. This wrap was failing, and the ping times out. March 24, 1998 ----------------------------------------------------------------------- PLXX490 V3500 Fddi Driver. (CSP2SFA0.MTX) Includes PLXX450 (described below) Includes PLXX465B (described below) PLXX490 Corrects a problem when the 1000 fddi is attached dual-home, and the hub goes down, and the 1000 was staying stuck in isolated state, 1E19 is in the leds. Mike Young. 01.23.98 ------------------------------------------------------------------- PLXX484 - V350 patch for ICP IR36863 The problem - The Performance Monitor, with ICP V35, calculates an incorrect "buffer utilization" value. You may see a near-constant value of 65% in the trace.dat file (via C3) during periods of quiet operation when the buffer utilization should be low. The fix - The incorrect calculation has nothing to do with actual buffer utilization. The calculation was being done on a hard coded buffer pool number that was changed in V35. The Router code was fixed so that the buffer calculation is done correctly. Mike Young. 1000 ICP Software Support. Nov 20, 1997 ------------------------------------------------------------------- ------------------------------------------------------------------- PLXX449B - IR34332 Modules = CSP2CHC0.EXE (serial engine code) Correct problem where 1000 ESCON adapter was timing out host connections with 11A2 error. 1000 ESCON ADPATER CONNECTED TO MULTIPLE IMAGES MAY FAIL WITH 1111 AND 11A2 ERRORS AFTER ONE IMAGE IS IPLED. ERROR DESCRIPTION: 1000 ESCON adpater was connected to 2 systems through an ESCD. When one system was IPLed the TCP/IP connections on the other system were lost. The 1000 system.log showed 1111 and eventually an 11A2 error. The 11A2 error indicates that the 1000 system has "timed out" the channel because of no response. During the IPL of the other system a Connect Request for the failing system "collided" with a with a device frame which caused a DLE from the other system. The ESCON adapter was not redriving the connect request on the failing system. As a result an Async DE which was need to end a Deferred Command Retry was never presented on the channel. The READ issued by TCP/IP never completed, and eventually the 1000 system timed out the connection. ------------------------------------------------------------------- PLXX450 is a V3.500 patch - APAR = IR34434 March 10, 1997 Modules = CSP2SFA0.MTX When a 1000 FDDI adpater is configured for multiple TCP/IP connections recycling one TCP/IP host can bring down the others. ------------------------------------------------------------------- PLXX453 March 25, 1997 Modules = CSP1LLC0.MTX Reapplies the Logical Link Control task. PLXX453 fixes a 1200 by csp1llc0 when pool1 is empty. The 1200 log would show an EIP of 1A. From now on, the log 1103 will appear in the leds if we hit this. You can use 1103 to set up a stop-trace-on-error. ------------------------------------------------------------------- PLXX454B is a V3.500 patch - APAR = IR34578 March 15, 1997 Modules = CSP3DBL0.MTX = CSP3BLK0.MTX This patch corrects problem causing 1302/1204 errors during IPL of ICP 3.5. ------------------------------------------------------------------- PLX458B is a V3.5.00 patch which reapplies the following task - Module = CSP1LLC0.MTX Provides additional 1202 bullet-proofing. ------------------------------------------------------------------- PLX460B - Modules = CSP1LSA0.MTX This patch is for V3402 ICP. Reapplies the $LSA task, and adds a 1420 log when a FRMR happens. The 1420 log contains the DLC Status Message that explains the reason for the FRMR (Frame Reject). ------------------------------------------------------------------- PLXX463 is a V3500 patch for 1000 ICP. May 08, 1997 V350 - IR35172 Modules = CSP1LSA0.MTX It corrects a problem that resulted in a 1202 logged by $LLC. When Vtam had sent a close station down to LSA, but we still had I-frames outstanding (unacked), that close-station was put on hold in pending state. If during this pending window, a FRMR (frame reject) happened that event would generate another close-station, and that FRMR would cause a 2nd close-station to be generated, the duplicity of these commands caused a 1202 condition. This condition has been corrected. ------------------------------------------------------------------- PLX465B is a V3.500 patch - APAR = IR35379 The following task is re-applied. 1.Model 3 FDDI task (CSP2SFA0.MTX) When a 1E16 (Illegal Transmit Frame) is encountered, the 1000 previously logged the 1E16 and stayed operational. Now, the 1E16 causes the FDDI to go offline and intervention required. Mike Young Nov 18, 1997 ------------------------------------------------------------------- PLXX471B is a V3500 patch for ICP. August 4, 1997 APAR = IR36157 Modules = CSP2CHC0.EXE Correct problem where 1000 ESCON adapter was hanging with NMI condition. The problem seems to manifest itself when attached to an Amdohl mainframe. The fix is in the Serial Engine code. The fix delays setting the data transfer latch until reception of the accept command response from the channel. ------------------------------------------------------------------- ------------------------------------------------------------------- PLXX473 - V350 patch for ICP August 27, 1997 Modules = csp3rou0.mtx csp3blk0.mtx This patch adds some function to the blocking algorithm in the 1000 when the V35 function of "multi-host connectivity" is used. PLXX473 is to be used along with PLXX472, an Operator Facility patch that restores the configurability of the "Maximum response Length" on the Lan Gateway Definition Parameters dialog box when configuring Lan Gateway Function. The "maximum response length" parameter was removed with the initial release of V35 ICP. The value was hard-coded to 10. But under some operational conditions the "maximum response length" is important. For example, in a single session FTP; doing a PUT from the MVS TCP/IP out thru a 1000 to a workstation on a LAN; the ACKS that come back from the LAN workstation towards the MVS TCP/IP may get "hung up" in an empty channel block and have to wait for the duration of the "block delay time" to be sent up in the channel block to the MVS mainframe. The blocking algorithm collects frames coming in from the LAN and "blocks" them into a channel block to be sent to the mainframe. The blocking algorithm sends the block when - 1. It becomes full 2. The "block delay timer" pops (configurable from a time of 10milliseconds (default) to 100 milliseconds. 3. A lan frame coming in has a length less-than the maximum-response-length (aka resp_len). So, in our FTP example the singular ACK of length 60 arrives at the blocker and has to wait for either the block to fill, (it won't in this example) or the timer to pop. So, the resp_len parm must be able to be configured to a value of, say, 100. That would allow that ACK frame to satisfy the condition of being less than the value of resp_len and therefore trigger the release of the block. You can see how a FTP of a huge file would have it's thru-put reduced by the accumulation of these delays. The resp_len was hard-coded to 10 in an attempt to prohibit the smaller 60 byte ARP broadcast frames from causing excessive, inefficient host I/O on the channel. PLXX473 contain a solution that enhances our blocking algorithm to require that any broadcast frame be blocked. PLXX472 contains a new OF/2 that restores the maximum-response-length configurability. Mike Young. 1000 ICP Software Support. ------------------------------------------------------------------- PLXX475 - V350 patch for ICP September 28, 1997 IR36511 Modules = csp3rou0.mtx csp1cif0.mtx The problem occurs when V35 "multi-host IP connectivity" is configured for a lan adapter that is going up through escon to 2 different lpars and each lpar has it's own tcpip stack. So data is running up through the 1000 lan adapter to each of the tcpip stacks. When one of these lpars "crashes" or is ipl'ed, the normal sequence of shutdown messages is NOT sent to the 1000 from that lpar's tcpip. So, incoming lan frames continue to be sent up that escon path. However, the escon path is gone; so those incoming frames back up on the blocker task; eventually the blocker logs an 1111. When a blocker logs an 1111, cif was sending the suspend-route message to the LAN adapter that was using the blocker route. While in SuspendRoute state, the LAN adapter would throw away all incoming frames of DSAP = AA (tcpip). V35 enhanced 1000 IP connectivity by allowing one lan adapter to have route up to multiple IP hosts. The LAN adapter only has knowledge of two possible routes, the AA tcpip route or the vtam-type route (some other sap). If the LAN adapter is the one that goes into suspendroute state, all tcpip frames are tossed. So any other hosts that were using that LAN adapter for TCPIP on other still-functional routes would experience traffic suspension. The correction to this problem is to have CIF send the SuspendRoute message to the Router task (if configured for TCPIP on that route that logs 1111). Changes to the SUSPENDROUTEMSG and RESUMEROUTEMSG in sudsdpi.h were made to accomodate this change. Mike Young. 1000 ICP Software Support. ------------------------------------------------------------------- ------------------------------------------------------------------- PLXX476 is a V3.5.00 patch which reapplies the following tasks IR36602 Modules = csp2etc0.mtx (etherstreamer driver) Problem is when a "set adapter" command comes down from mainframe software called "OSI". The Etherstreamer adapter was handling the command ok, but the status flag was not being restored to the original "ON" condition. This caused the etherstreamer to be NOT ready to receive frames. The fix - The Set Adapter command processing code was fixed to restore the original status value after processing. October 13, 1997 ------------------------------------------------------------------- PLXX477 is a V3.5.00 patch which reapplies the following tasks IR36675 Modules = CSP2CHD0.MTX - Escon single slot driver CSP2CHC0.MTX - Escon double slot driver The Problem - If you configure more than 59 subchannels for an escon adapter you will hit a 1009 at IPL time. The fix - The driver code was corrected to allow for the larger configs. October 23, 1997 ------------------------------------------------------------------- PLXX478 V3500 APAR = IR36718 Modules = CSP2TRB0.MTX (Busmaster Token Ring device driver) This patch fixes a problem with the BusMaster Token Ring that has been configured for multi-host connectivity. When multiple tcpip paths are active, and then one of the tcpips on the mainframe is taken down, we were seeing a 000D log in the 1000. This is an error, we should only have posted the 000D when the last active tcpip host was taken down. Situation Example - 1. One BusMaster Token Ring adapter configured for 3 mainframe tcpip stacks, with a separate subchannel pair going up to each stack. 2. All three tcpip stacks are active, and we have telnet users coming up thru each path. 3. Take one of the three tcpip stacks down. 4. All other telnet users on the other paths will hang, be unable to pass data thru the 1000. Evidence of failure - 1. See a 000D log in the 1000 system.log logged by csp2trb0.c 2. All users resume connectivity when that one tcpip stack is brought back active. Note - 1. This failure was confined to the "busmaster" token ring the other line drivers are okay. Mike Young. 10.29.97 ------------------------------------------------------------------- End of PLXX480.TXT file of the V35 superpatch. -------------------------------------------------------------------