MPTS Fixpak (WR_8620) - Japan

IBM MPTS LAN Adapter and Protocol Support FixPak WRx8620 (IBM PTF WR08620) This package requires that you have the refresh of the MPTS LAN Adapter and Protocol Support (MPTS) that was included with either WRx8600 or WRx8610. WRx8600 is the MPTS portion of TCP/IP 4.1 for OS/2 that is available from IBM's Software Choice. The following versions of LAPS are suitable for applying this FixPak. Note that for IBM WorkSpace On-Demand Release 2, you do not need to apply any FixPaks before applying WRx8620 because it already contains WRx8610. Version Product in which MPTS was included V5.00.0 Warp Server V5.10.0 Warp 4.0 V5.11.1 IBM Directory and Security Server V5.12.1 IBM WorkSpace On-Demand Release 1 V5.20.0 Warp Server SMP V5.30.0 TCP/IP 4.1 for OS/2* V5.40.0 IBM WorkSpace On-Demand Release 2* *These products already contain the prerequisites needed. Note: 1 - WRx8620 should not be installed on a non-SMP Warp Server without installing TCP/IP v4.1 prior to it. There have been various problems reported when using WRx8610 (or above) without TCP/IP v4.1. This FixPak also supports Warp Server SMP machines with WRx8610 applied. Note: 2 - This FixPak must be installed using Corrective Service Facility (CSF) 2-B Version 1.41, which is distributed with this FixPak. (CSF is also called the FixTool.) To use CSF, run SERVICE.EXE or FSERVICE.EXE--not MPTS.EXE. Note: 3 - If you try to install this FixPak with a version of the FixTool prior to 1.41, you may notice various errors or pop-up warning panels. Please use the version of CSF that comes on the tool diskette of this FixPak. Once you use FixTool Version 1.41, you will not be able to use previous versions of the FixTool to service other products on this system. Note: 4 - This FixPak is language dependent. Be sure you are installing the proper language version. The third character in the FixPak name indicates which language the FixPak is for. Installing this MPTS FixPak on other language versions of OS/2 is not supported. Note: 5 - MPTS is Year 2000 ready with or without this FixPak. It does not require any changes to be able to handle year 2000 dates. Note: 6 - After application of this FixPak, the TCP/IP stack will be upgraded to the 4.2 level. Note: 7 - This FixPak replaces existing syslevel files. Because of this, the previous CSD level will always be WR08610, even if you are installing the FixPak on WR08600. This FixPak is intended to upgrade only LICENSED instances of MPTS. As such, its use is limited to the license agreement under which you obtained the original licensed copy. Title to the contents herein and any copies made is retained by the International Business Machines Corporation, Armonk, New York, 10504. ************************************************************************ Diskettes can be created using the LOADDSKF utility. There are 5 files/images included in this package. ************************************************************************ FIXT141 DSK FixPak Tool Diskette 3.50" WJ8620B1 DSK MPTS DISKETTE #1 3.50 1.44MB WJ8620B2 DSK MPTS DISKETTE #2 3.50 1.44MB WJ8620B3 DSK MPTS DISKETTE #3 3.50 1.44MB WJ8620B4 DSK MPTS DISKETTE #4 3.50 1.44MB Note: The following APARs are contained in FixPak WR08620. FixPak WR08620 also contains all APARs contained in FixPaks WR08610. * - APAR = IC12446 GETHOSTBYNAME SOCKET CALL DOES NOT FUNCTION AS NSLOOKUP DOES. Customer is looking for the same function of nslookup <hostname.this> from another domain (that.domain.com) in telnet or ping. 1."nslookup <hostname.this>" from another domain produces the correct IP address. 2.But "ping <hostname.this>" or "telnet <hostname.this>" from another domain (that.domain.com) gets unknown host error. The gethostbyname socket call does not function as it should. It should produce the same results as the "nslookup" command. * - APAR = IC18036 WARP 4 FINNISH VERSION INSTALLS INCORRECT VALUE FOR NBDDBACKADDR LINE IN TCPBEUI SECTION DURING MAIN INSTALLATION. On installation of Warp 4 Finnish version from CD-ROM, if you install File and Print Services and MPTS and only select TCPBEUI, the installation adds NBDDBACKADDR=0x0. The NBDDBACKADDR is a valid keyword, but 0x0 is an invalid parameter for this keyword. If you remove TCPBEUI and then reinstall it once the system is up, this problem goes away. Something in the main installation is causing this to happen. * - APAR = IC20415 IF A CALL COMMAND IS CANCELLED OR TIMES OUT BEFORE A "NAME RECOGNIZED" IS RECEIVED, THE "USE COUNT" FOR LOCAL NAME ISN'T DECREMENTED. If a CALL command is cancelled before a Name Recognized frame is received or if the CALL times out, then the "use count" for the local name is not decremented. * - APAR = IC20489 THE CUSTOMER GETS A TRAP E WHEN PINGING THE BROADCAST ADDRESS AFTER UPGRADING TO TCP/IP 4.1. Receive a trap E when pinging the broadcast address or subnet after upgrading to TCP/IP 4.1. * - APAR = IC20587 TCP/IP 4.1 WINDOWSIZE CHANGED FROM 8K TO 32K. Performance degradation was found in TCP/IP windowsize when comparing TCPIP 4.0 to TCPIP 4.1. It was suggested to use INETCFG -s tcpswinsize 26000 on the client and server, but this showed no improvement. Therefore, the default tcpwinsize was changed in AFINET.SYS for a default of 32k, rather than the original 8k. * - APAR = IC20646 APAR TO ALLOW NODE STATUS REQUESTS WITH A NAME OF '*'. FOR NT FP3. When NT clients with Fixpak 3 attempt to logon to a server knowing only the server's TCP/IP address (and not its NetBIOS name), one step in the algorithm that builds the session is to send a Node Status Request (as defined in RFC 1001,1002) to the server and parse the returned table to find the server's NetBIOS name. When doing so, these clients use a NetBIOS name of '*', which is currently illegal. If that table is not returned, the clients cannot logon. So, we need to allow Node Status Requests with NetBIOS names of '*'. * - APAR = IC21555 MAC DRIVER NOT PLACED IN CORRECT POSITION IN CONFIG.SYS FILE. If MPTS is installed after the Netware installation, the mac driver comes below all the protocol drivers. This causes problems in the odi2ndi.os2 driver. * - APAR = IC21666 TRAP D OR E IN IFNET$ IN OUTPUT +96 WITH CS:EIP=3068:0000147E Customer is getting a TrapD or E in IFNET$. The stack is not checking if the arplookup() call fails. This leads to an incorrect rtenrty pointer value being passed to the output() function where it traps. * - APAR = IC21825 NETBIOS (ACSNETB.DLL) RETURNS AN INVALID RETURN CODE (XB4) TO THE APPLICATION. ACSNETB.DLL returned an invalid return code (xb4) to the application even though the Netbios trace shows the correct return code. The ddid field was not getting updated with the correct return code. Thus, ACSNETB was getting the wrong return code. * - APAR = IC21956 / IC22223 10022 RETURN CODE ISSUED FOR SOCKETS APPLICATION. When a DB2STOP command is run, the error listed below is logged in the DB2DIAG.LOG file. The DB2STOP command processes completely - the only problem is that the log shows an error. DIA3208E Error encountered in TCP/IP protocol support. TCP/IP function "accept". Socket was "8". Errno was "10022". According to the TCP/IP Programming Reference manual, a 10022 error is SOCEINVAL (Invalid argument). In the section for the ACCEPT call, SOCEINVAL is defined as "Listen() was not called for socket s." Sockets is returning the wrong error code. * - APAR = IC21958 IBM DIRECT TALK/2 V2.1 CAN'T START MORE THAN 21 LINES. Environment: Machine configured as Direct Talk/2 server and client. Problem: Server starts properly, but client process gets an error when starting more than 21 lines. DT/2 application reports errors EXH0321 and EXH3248, which indicate a Netbios connection problem. A review of Netbios trace shows return code 0E (Name Table Full) error on an Add Name command. DT/2 reports this as error 14 (0E in decimal). A review of the available Netbios resources shows that there are enough available names, so the error should not occur. * - APAR = IC22209 / IC22731 TCP/IP FAILS TO RECOVER IF THE LAN HAS A TEMPORARY OUTAGE. TCP/IP no longer works if there is a temporary network outage. This problem is occurring on a token-ring network. If a network error occurs, such as a beaconing condition, the token-ring adapter will drop from the network. When the network comes back up, the adapter inserts back into the ring. TCP/IP, however, no longer works. If they attempt a Ping command, it reports "Network Down" and the ping fails. Netbios is also configured on the same adapter, and it is able to function. The network has intelligent hubs that sense the network problem and can recover in seconds. After the network is back, the token-ring adapter's light shows green, meaning it is back on the network. Netbios traffic begins flowing through the adapter. TCP/IP, however, does not recover. To get TCP/IP to work, you must run SETUP.CMD (or just the IFCONFIG LAN0 line) to reinitialize TCP/IP. TCP/IP should recover without any intervention from the user. This problem does not occur with all token-ring cards, but does occur with the IBM PCI Auto LANStreamer and the IBM PCI 16/4 adapter.