MPTS Fixpak (WR_8504) - Norway

IBM MPTS LAN Adapter and Protocol Support FixPak WRN8504 : Norwegian This FixPak is a refresh of the MPTS LAN Adapter and Protocol Support program and is intended to replace (upgrade) only LICENSED instances of MPTS. This FixPak supersedes WRx8503. 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. Please refer to the MPTS Configuration Guide on Diskette 6 for complete Installation and Configuration details. ************************************************************************ Diskettes can be created using the LOADDSKF utility. There are 6 files/images included in this package. ************************************************************************ WN8504B1 DSK MPTS DISKETTE #1 LAPS 3.50 1.44MB WN8504B2 DSK MPTS DISKETTE #2 MPTS Socket-TCP/IP Support Files 3.50 1.44MB WN8504B3 DSK MPTS DISKETTE #3 Transport Protocol Drivers 3.50 1.44MB WN8504B4 DSK MPTS DISKETTE #4 MAC Adapter Drivers 3.50 1.44MB WN8504B5 DSK MPTS DISKETTE #5 Utilities 3.50 1.44MB WN8504B6 DSK MPTS DISKETTE #6 PUBS and Symbol Tables for Debug 3.50 1.44MB Note: The following APARs are contained in FixPak WR08504. FixPak WR08504 also contains all APARs contained in FixPaks WR08502 and WR08503. * - APAR = IC18158 TRAP00D IN LANDD.OS2 IN FUNCTION PURGE_TIMERS_386 Customer is doing a shutdown and during this time is pulling the plug on the adapter cable. LANDD.OS2 is trapping in Purge_timers_386. * - APAR = IC18159 TRAP IN ODI2NDI WHEN CABLE IS PULLED FROM ADAPTER Trap occurs when running ODI2NDI and you pull the lobe cable from the PC. This happens when running PCI t/r adapters but could (from review of code) happen with any type of adapter. Problem is due to the fact that the bx register is not being properly saved before the call to indication on in the MAC. * - APAR = IC19310 TRAP IN NETBIOS (NCBDONE) DUE TO INVALID POST RETURN ADDRESS Trap in Netbios (ncbdone) when a ncbstatus command was issued and rc=0b (ncb cancelled) while the LAN server/requester is shutting down. Problem is that we are passed the ncbpost address from the netwksta.sys driver and at this point ths address is invalid. So we get a trap due to the fact that we cannot access si anymore. * - APAR = IC19311 DCAF DOES NOT TERMINATE AFTER PUTTING WR08210 OR LATER CODE ON THE MANAGING MACHINE AND USING NETBIOS After applying WR08210 or later code on a DCAF managing machine, the application does not terminate correctly. The DCAF icon remains on the desktop with the hash background. With the kernel debugger it shows the thread eqntqui blocked and waiting. * - APAR = IC19312 USING TCPBEUI, CONNECTION BEING DROPPED DURING FILE TRANSFER (NET MOVE FAILS) TCP is dropping the connection in the middle of a file transfer when using NETBIOS over TCP/IP (tcpbeui). The setup has a server and 2 requesters. After hours of execution, one of the clients fails at NET MOVE. * - APAR = IC19313 TRAP00D WHEN USING H-NODE IN TCPBEUI WITHOUT A NAME SERVER AT LAN SERVER LOGON If tcpbeui is configured and you select h-node without specifying a name server or local domain scope in the MPTS configuration, it will give a trap000d when you attempt to logon. * - APAR = IC19314 TRAP000D IN NETBEUI.OS2 GETSESSION_386 + 40 Trap000d in netbeui.os2 in sessctrl.3st at GetSession_386 + 40. The code is attempting to return an error code to the redirector and has a bad address. * - APAR = IC19315 ODI2NDI IS NOT GETTING THE ADDRESS WHEN IT IS BINDING TO THE MAC The ODI2NDI statement is getting moved in the CONFIG.SYS causing the protocol not to bind. This occurs when changing something using MPTS install. * - APAR = IC19316 SRVIFS FAILS TO RETURN PROCESSING TO SETBOOT DURING CID INSTALL During CID installation, from time to time a setboot command is issued to have the system rebooted. This is done to help rely on CID as the instrument of installation and therefore not require any user input (such as shutdown and reboot). Intermittently, setboot does not function. What is happening is that srvifsc is looping and causing the actual setboot function to not be called by the system. Results are that the customer will need to ctrl-alt-del to have the system reboot. * - APAR = IC19317 NBTCP DOESN'T HANDLE AN IP ADDRESS OF 0.0.0.0 CORRECTLY When NBTCP gets bound to 0.0.0.0 (which can happen on DHCP clients), it doesn't correctly refresh itself when it gets the valid IP address. I have turned on the debug flag for NBTCP, and from the debug log I see that we don't re-init the interface when the IP address changes from 0.0.0.0 to anything. However, when we change from xxx.xxx.xxx.xxx to yyy.yyy.yyy.yyy, where x and y != 0, then we re-init the interface. * - APAR = IC19318 SYSTEM DOES NOT COMPLETE SHUTDOWN. TCPBEUI CODE IS GOING INTO A LOOP AND NEVER COMPLETING. Customer has TCPBEUI installed on a system and has LAN Req./LAN Server running on the system. The customer attempts to shutdown, and the shutdown never completes. Mouse is able to be moved, but the cursor is a clock and it never finishes shutdown. What is happening is that LAN Server/Requester issued a NCB.RESET command to TCPBEUI to remove all of the sessions/ commands/names (to include his name) from the adapter. TCPBEUI is in the Netbios_reset code and never completes. * - APAR = IC19319 AN MPTS DEFECT BROKE AUTO-SENSING ON BOOT UP, WHICH CAUSED MPTS TO GO INTO WRONG MODE (NOT BALANCE) WHEN BRIDGES ARE PRESENT There is a section of code that determines whether to come up in balance=1 or balance=0 mode (balance on or off). Due to a previous fix, this test was removed. So, in essence, if you have a server that has two adapters, each in a different ring but bridged together, then the system will come up automatically in balance=0 mode when it should come up in balance=1 (on) mode.