IBM MPTS LAN Adapter and Protocol Support Fix Pack WRx8610 This package is a refresh of the MPTS LAN Adapter and Protocol Support (MPTS) program and is intended to replace (upgrade) only LICENSED instances of MPTS. As such, its use is limited to the license agreement under which you obtained the original licensed copy. This version of MPTS is installed using the MPTS Program Product Installation Aid, MPTS.EXE. There is NO selective install of MPTS sub-components. All components of MPTS are installed, including all of the MAC drivers. Use the following procedure for manual (diskette-based) installation: 1. Ensure that adequate disk space is available for MPTS install. MPTS versions require 11.5 mb of disk space for both new installations and re-installations of MPTS. 2. With the MPTS refresh diskette (Fix Pack Diskette 1) in drive A:, run MPTS by entering "A:\MPTS", and follow the prompts. 3. Shut Down and Reboot the system. NOTE : SEE THE FILE WRx8610.TXT FOR ADDITIONAL INFORMATION The following APARs are fixed with WRx8610: APAR = IC14877 NETBEUI TRAPS IN TIMERINDICATE. An intermittent trap occurs in netbeui.os2, timerindicate procedure. This has been reported on both WR08150 (MPTS for LS 4.0) and WR08152 (MPTS for Warp Connect). The trap in both cases is caused by an invalid pointer to dgroup. APAR = IC17233 USING SRVIFS TO INSTALL LAN SERVER ENDS WITH LSI0073 ERROR. SRVIFS drive is Z:, which is a redirected drive to a CDROM. When issuing the following command, the program ends with an LSI0073 error and then traps: Z:\CID\SERVER\IBMLS\LANINSTR /REQ APAR = IC18814 A CUSTOMER APPLICATION DOES NOT TERMINATE. DEBUG SHOWS 1 THREAD STILL ACTIVE. Customer has workbench application called REUCCS.EXE. When terminating the application, one thread from the app still remains active. This is due to an NCB.LISTEN that is not getting cleaned up when the application ends. This is somewhat different from IC17205 because the fix that resolves DCAF has no bearing on this problem. APAR = IC19116 TRAP000D IN NETBIOS.OS2 IN FUNCTION IDC_ENTRY +1AA. TRAP MOST PREVALENT DURING SHUTDOWN. Trap000d happens during shutdown. Function is IDC_Entry +1aa. We are attempting to do a compare of biosinfotable seg number to 0. The problem is that we are using the wrong offset--si instead of di--and thus we are going past the boundary of selector ds. APAR = IC19338 USING FIX PACK WR_8415 AND THE LAPSDUMP THAT WENT OUT WITH IT CREATED INCORRECT OUTPUT FOR NETBEUI SUMMARY User installed CSD WRS8415 and the LAPSDUMP on the same CSD disk (diskette_5). User specified USER configured NCB of 254. However, the NETBEUI summary section came out with: CONFIGURED NCBs ==> 36864 We recreated this problem using U.S version (WR08415) and the CONFIGURED NCBs showed 24576. These values are too high and need to be corrected in the code. The date and file size of the LAPSDUMP is lapsdump.exe 17/03/97 17:50 112606 APAR = IC19569 TRAP000D IN TCPBEUI FUNCTION SOCKET_DATAGRAM_386, LABEL SOCKET_DG_NEXTDS DUE TO INVALID REGISTER LOADING INTO ES. Customer is getting a trap000d in TCPBEUI.OS2. This trap is happening during receipt of datagrams. Trap is in Socket_datagram_386 function. If you look at the ERRCD value, you can see the selector that is trying to be placed into es. The problem is that this value is currently an invalid selector. Therefore, it traps. APAR = IC19807 LISTEN NOT POSTED FOR NT CLIENT WHEN THE SERVER IS USING MULTIPLE ADAPTERS. NT client sends a find name, then sends a directed call to the specific adapter that answered the find name. If that adapter happens to be answering another find name, there will be no listen posted. Another adapter on the server will not be able to answer it because the call was directed to the specific adapter. APAR = IC19947 LOOP IN ACSNETB.DLL (AT WR08415 OR LATER) OCCURS WHEN SHUTTING DOWN CICS APPLICATION IF SESSIONS ARE STILL CONNECTED. There is a loop in acsnetb.dll during a shutdown of CICS. This loop only happens if CICS has current sessions established when shutdown of CICS is initiated. Basically, the system hangs and must be rebooted to clear it out. At this time, it appears that acsnetb.dll is getting an incorrect value from netbios at the time of the loop. When this happens, the post_dispatcher thread never exits, therefore, the app is also never allowed to exit. APAR = IC19994 WHEN INSTALLING WR08421, LAPSPM.DLL IS NOT CALLING IN18INST.EXE, AND THEREFORE THE IBMI18N SUBDIRECTORY IS NOT CREATED. This problem causes errors when you attempt to install TCP/IP from diskettes that are created from the Merlin CD. To recreate: 1. Install Merlin (base OS/2 without any networking support) 2. Install MPTS WR08421 (do not install GA MPTS that is shipped with Merlin). 3. Using proddsks, create and install TCP/IP. 4. You will get an xpg/4 error after diskette 13. APAR = IC20180 MAPNAME.EXE CREATES RFC NAMES WITH "AAAAAAAAAAA...." IF COMBINATIONS OF MJ OR MZ ARE USED FOR THE NETBIOS NAME. When using MAPNAME to create RFC names, the output is incorrect when the letter combinations of MJ or MZ are used within the NETBIOS name. Some examples are below: > mapname 1MZXSRV01 /rb RFC name: DBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > MAPNAME MMZXSRV01 /rb RFC name: ENAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA These are failing letter combinations: MJ and MZ (MAPNAME is case sensitive so mj, Mj, mJ, mz, Mz, and mZ also fail). - "M" and "m" converted both end in "N" (ie. EN, and GN) - "J", "j", "Z", and "z" converted all end in "K" (ie. EK, GK, FK, and HK). Note: Replacing "M" or "m" with "-", which when converted also ends in "N" (CN), will cause the RFC name to be incorrect. APAR = IC20181 MPTS PLACES THE IBMLANLK DRIVERS IN A BAD POSITION IN THE CONFIG.SYS UNDER CERTAIN CONDITIONS. When reinstalling MPTS, the install code places the IBMLANLK drivers in a bad position in the CONFIG.SYS. This is only known to happen, under normal conditions, when you are reinstalling the MPTS code. It should not happen on a first-time install. It happens when there is a DEVICE statement before the HPFS IFS statement in the CONFIG.SYS. APAR = IC20282 NCB.FIND.NAME COMMAND IS RETURNING IMMEDIATELY INSTEAD OF WAITING 5 SECONDS. THIS CAUSES PROBLEMS WITH GROUP RESPONSES. When doing an NCB.FIND.NAME before WR08415 is applied, the findname would wait 5 seconds before completion--even if it got a name_recognized response. This would allow applications to get more than one response in the event that the netbios name in question is a group name. After applying WR08415, the findname is completing immediately after it receives a name_recognized response, thus causing invalid information to be passed back to the customer. APAR = IC20452 THE IBMTRP.NIF IS NAMED IBMTRPO2.NIF IN MPTS WR08421 AND WR08600. THE CORRECT NIF FILE NAME IS IBMTRP.NIF. Customer was using the IBMTRP.OS2 and IBMTRP.NIF files for the IBM PCI 16/4 Token Ring adapter under an OS/2 Warp 3.0 system. The customer then migrated from WR08415 (with IBMTRP drivers shipped with the adapter) to an OS/2 Warp 4.0 system with WR08600 MPTS. We found that MPTS WR08421 or later (i.e. WR08600) includes the correct NIF file with the wrong name. APAR = IC20887 GETTING HANG CONDITION ON CLIENTS WHEN ATTEMPTING TO DO MULTIPLE LOGONS FROM SEVERAL DIFFERENT SYSTEMS AT THE SAME TIME. Customer is attempting to logon to the server from several different systems at the same time. Customer is using a script that does the logon and has clients configured for Netbeui and TCPBEUI. The session that is doing the logon hangs. Logon does not complete. The problem is that the client is awaiting completion of a send datagram. This wait is causing the logon to hang. APAR = IC20959 UNABLE TO ACTIVATE AN LU IN A CERTAIN ADDRESS RANGE IN LANDD.OS2. When CS is attempting to have a client activate an LU with it (at start of CS on client), the activate fails if the LAA has a 31 in its 56 positions (e.g., 40:00:31:04:05:55). If the address is changed to 40:00:32:04:05:55, then all is ok.