OS2 World.Com Forum

Subject  :  System Crashes
Author  :  Russ D russd@phoenix-com.net
Date  :  09 Aug, 2006 on 21:39
I have a client that is running 4 Compaq ProLiant 1600-R's with OS/2 Warp 4 FixPak 15 on each of these servers. The units function as voicemail platforms. The software he is running on these systems is a product developed by my competitor. All systems are remotely located so he is using DTOC v.2.54 to manage each of the units.

What is happening is this; whenever one of his employee's remotes into the machine a SYS3171 or SYS3175 error is generated and the system locks up. It than has to be rebooted remotely. I have the popuplog.os2 for two of the systems. After looking at them I noticed that they are identical with the exception of the PID. To be honest, I don't really know what these logs really are saying but I do need to get this problem resolved. I have attached the files for review, if any one can assist in resolving this issue I would greatly appreciate it.


Subject  :  Re:System Crashes
Author  :  Fahrvenugen
Date  :  09 Aug, 2006 on 22:37
A few things to check.

Have a look for any files which are opened but have never been properly closed. Also, check and see if you're running low on disk space and / or if the swapper file is taking up the remaining available disk space. It is possible that this could result in an sys3171 error.

Also, since you're having the difficulty when someone tries to remote access the machine(s), it could be a problem with the TCP/IP stack. According to IBM APAR's, the sys3171 error can occur in the tcp/ip stack if no hostname is defined. Check your config.sys for a line such as:

SET HOSTNAME=machine_name

For more information, have a look at:

http://www-1.ibm.com/support/docview.wss?uid=swg1IC30157

Also, I'm wondering if maybe you're running on an older TCP/IP stack, one of the ones that was buggy. From a command prompt, check your TCP/IP stack level. Type:

inetver

and put the results here. there might be a stack update which could help solve the issue.

I don't know if any of this will help, but it is a start.


Subject  :  Re:System Crashes
Author  :  Russ D russd@phoenix-com.net
Date  :  09 Aug, 2006 on 23:25
I checked the suggested files and the Config.sys file does have the hostname set.

As for the TCP/IP information -- on the machines we are having the problems with the came back with

Inet version 4.00e

I checked several other machines exactly like the ones have the problem and found the following:

Version numbers of TCP/IP protocol drivers
Socket.sys: 6.3000
AFOS2.sys: 6.3000
AFINST.sys: 6.3001

I double checked my records and the machines having the problem were installed several years ago and have not had much updating done primarily because they are so busy it is impossible to take them down for any time to do the upgrades.

I hope this helps provide more insight to the problem. I should note that all my clients use remote access to administer them machines. I also have access to those machines but I do not have access to the machines having the problems.


Subject  :  Re:System Crashes
Author  :  Fahrvenugen
Date  :  10 Aug, 2006 on 06:12
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.


Subject  :  Re:System Crashes
Author  :  Russ D russd@phoenix-com.net
Date  :  10 Aug, 2006 on 15:54
I was going over my installation notes for these machines and found that we had upgraded the software configurations to the newest revisions, but because of problems with crashes we downgraded it.

My question is this, these machines are located in a data center where internet connection speeds are not regulated. The machines that are located in other data centers where the internet speeds are throttled don't have this problem. The largest portion of our clients have speeds of 256Kbps whereas these crashing machines are running connection speeds in excess of 1Mbps.

I also spoke with one of my clients employees and she told me that yesterday she started to wait for the pages to completely load in her browser before attempting to do any modifications to the page and she had no problems. she was able to remotely make changes within the program running and disconnect successfully.

What you appear to be discribing is a TCP/IP stack overflow and what I don't want to do is upgrade these machines and continue to have problems. I find that if people know they have a very high speed connection they believe that they can get work done faster and that illusion cause me problems.

Your help and thoughts have been extremely helpful.


Subject  :  Re:System Crashes
Author  :  magog
Date  :  11 Aug, 2006 on 01:45
Maybe you could also move to VNC and drop DTOC.
I've changed it here myself, as DTOC had problems with some keys at the WPS.

The OS/2 VNC Server is available here:
http://eros2.by.ru/pmvnc_en.shtml

---
Regards,
Juergen Ulbts (Germany)

*** Java Movie Database - http://www.jmdb.de/ ***
*** New version available (2006-08-10) ***
*** Website has been updated ***


Subject  :  Re:System Crashes
Author  :  Russ D russd@phoenix-com.net
Date  :  25 Aug, 2006 on 21:12
After all the information I thought it would be appropriate to update the forum on the status of this problem. It is fixed.

Thanks to all for your suggestions; however, believe it or not, none of them worked. A factor that was not revealed to me and I could not pass on to everyone else was the fact that there was another system in between these Warp 4 platforms and the remote desktops doing the administration. Of all things a virus program installed on that gateway was reeking havoc on everyones connections. It wasn't until my clients network technician was kick out of these systems that this problem was discovered. It appears he was the only one that knew of the programs existence and he installed it one day before all the problems arose. Up until he installed it the systems were really stable. I told my clients network man not to install anything without first testing its impact on these systems.

Again thanks to all for your input. It was greatly appreciated even though it really didn't help resolve the issue.


Powered by UltraBoard 2000 <www.ub2k.com>