last updated at 10 Aug, 2006 06:18 (2 times)
So if I undersand correctly, the machines with:TCP/IP:Socket.sys: 6.3000
AFOS2.sys: 6.3000
AFINST.sys: 6.3001
*don't* crash, but the ones with:
Inet version 4.00e
*do* crash.
If this is the case, then the network stack and MPTS has just surfaced to the top of the list of suspects. With a response of 4.00e, it is likely that there have been no updates to MPTS installed, and no updates to the TCP/IP stack either. (4.00e was what the original 1996 release of Warp 4.0 replied when it got the inetver command)
The machines with the inetver reporting "6.300x" are running the newer MPTS (Multiple Protocol Transport Services - IBM speak for a network stack and network card setup) with the full 32 bit TCP/IP stack. The ones with the 4.00e are still on the older MPTS, with a 16 bit TCP/IP stack.
I know it is possible to do remote updates with OS/2, but to be honest, I've never done this myself (I've always had physical access to a machine I've updated), so it is an area I don't have much experience with. Also, I'd be very cautious trying to update the *network stack* from remote. If something goes wrong and the update doesn't work as it should, your network connection on that machine may not work any more, which means bye-bye remote access. So my advice would be if you're going to update those machines then do it either at a time when you can be there, or (less preferable, but still possible) have someone else there who is competent with computers on the phone to be ready to help if a problem should occur. Chances are there would be no problems (the last time I did a stack update that didn't work correctly was about 8 years ago), but its still a computer, so you never know until it is up and running again.
If I recall correctly, the older 16 bit stack, especially without any updates, did have a few issues. It can be updated by applying MPTS fixpak wr08423 followed by wr08425 and then you can install the latest 4.0 level stack (Version 4.02w) from:
ftp://service.boulder.ibm.com/ps/products/tcpip/fixes/v4.0os2/latest/stack/latest40.exe
and it *might* solve the problem, but you'll still be running on the older 16 bit stack.
My own recommendation (based on the fact that you have some machines running the 32 bit stack without a problem) would be to upgrade to those 2 machines to the 32 bit stack. It seems to be compatible with every application I've thrown at it (whether originally designed for the old 16 bit stack or the new 32 bit stack), it seems to solve quite a few problems, it can allocate more resources to TCP/IP, and is generally a lot quicker on a network.
To upgrade to the 32 bit stack, you'll first need to install wr08610_conv from IBM. You can get it here:
ftp://service.boulder.ibm.com/ps/products/mpts/fixes/english-us/wr08610_conv
And then you'll want to install the wr08621 update, available here:
ftp://service.boulder.ibm.com/ps/products/mpts/fixes/english-us/wr08621
And then finally, grab the newstack.zip package off Hobbes and install it to bring the TCP/IP portion up to a level that fixes a few problems in wr08621:
http://hobbes.nmsu.edu/cgi-bin/h-search?key=newstack&pushbutton=Search
If you have access to the machine (or if you have someone there you can walk through the process), the OS2MT package is probably the easiest to use to install this stuff:
http://xenia.sote.hu/~kadzsol/os2mt/index.htm
If you pick off Language as "EN", and under "Category", chosing "Update" you can find the listing for MPTS_8610_32bit
And under the category "Fixpak" you can find "mpts_8621_32bit".
However if you want to do the update from remote, you'll probably be best to use the IBM RSU (Remote Service Utility) to do the update. This is a method that IBM developed to allow for "unattended" installations of updates, fixpaks, etc. While I've never had a need to use it, from what I understand it will work to let you update the MPTS and TCP/IP stuff from remote.
As I write this, I don't have the information on RSU handy. But I do have the information somewhere. I'll have a look and see if I can find it for you and post a follow up.
I hope this helps. Again, I don't know for sure if it is the stack or not, but if some machines running that same package on the newer stack aren't having the problem, but with the older stack the problem exists, that is my best guess.