Progress 9.1D Crashing

J

jumstead

New Member
We are experiencing repeated crashing of a Linux Server ( IBM x225 w/ 2.5Gb ram, 40Gb + free disk space running Suse Open Server 8) running a Progress 9.1D Encompix ERP app. The client app (writting in ProVision) running on a Windows XP Pro ( we have tried other Window OS's with the same results ) is doing an upgrade of the data, migrating from an old version to a new version which is a lengthy process taking 4 to 5 hours (per the ERP vendor).

What happens is part way through the upgrade the server crashes. A hard crash keyboard and mouse will not responde, can not ping or telnet to the server. The only way to restart is power it off and on.

It always crashes at approximately the same place on a given table approx 1/4 of the way through 1,200,000 plus records. Total database size is approximately 1.3Gb.

We were able to get the upgrade to work on a smaller database.

Does anybody have any suggestions or starting points for debug.
 
Is the client freezing or is the server crashing. Are there any error messages in the database log file? More info
 
cecsno said:
Is the client freezing or is the server crashing. Are there any error messages in the database log file? More info
Click to expand...
The server is crashing and neither the server OS or the database log files have any error messages in them. The work station doesn't crash but the app does display error dialogs stating the server is not available. We know this has something to do with the total number of records, less records and it will not crash. The ERP vendor ran the upgrade on their Windows server and it runs OK. We do not use Windows Servers.
 
So your running the update in client/server mode. Do you set the -T parameter to a directory where you can monitor the growth of the .srt file. Also are you using the -TM and -TB parameters. You might also want to use the -y parameter on the client to gather session statistics in the client.mon file.

It kind of sounds like the .srt file may be getting larger than 2GB.

You've probably run this on different clients too.
 
cecsno said:
So your running the update in client/server mode. Do you set the -T parameter to a directory where you can monitor the growth of the .srt file. Also are you using the -TM and -TB parameters. You might also want to use the -y parameter on the client to gather session statistics in the client.mon file.

It kind of sounds like the .srt file may be getting larger than 2GB.

You've probably run this on different clients too.
Click to expand...
I don't believe we are using a .srt file. The command line for starting the Progress server on the Linux server is

/usr/dlc/bin/proserve /data/prog/mtmtest/mtmtest -L 70000 -B 30000 -S 50006 -N TCP -classpath /usr/lib/java

Could you enlighten me about the -T parameter? I can't find any mention of it in the Progress documentation. But if it is using a default .srt file then this could very well be the problem.

I'll try the -y parameter on the client the next time we try an upgrade. Which won't be for a few days.
 
The -T parameter defines the directory where Progress temporary files (.srt .lbi .pge) are kept, normally in the startup directory. These temporary files are created every time a client is started and are erased when the session terminates normally. In an abnormal termination they should stay in place.


When you said the vendor performed the update on Windows Server, was that with your data?
 
cecsno said:
The -T parameter defines the directory where Progress temporary files (.srt .lbi .pge) are kept, normally in the startup directory. These temporary files are created every time a client is started and are erased when the session terminates normally. In an abnormal termination they should stay in place.


When you said the vendor performed the update on Windows Server, was that with your data?
Click to expand...
The Progress temp files are created on the client machine then? They are actually named srtnnnnn, lbinnnnn, pgennnnn at least on our Windows clients, I was confused looking for something.srt. Looking at the files that have been left behind from crashes I don't see any that are over 37Mb.

How would these make the server crash / lock-up? More importantly how to stop it from doing so.

Yes the vendor performed the update with our data.
 
jumstead said:
The Progress temp files are created on the client machine then? They are actually named srtnnnnn, lbinnnnn, pgennnnn at least on our Windows clients, I was confused looking for something.srt. Looking at the files that have been left behind from crashes I don't see any that are over 37Mb.

How would these make the server crash / lock-up? More importantly how to stop it from doing so.

Yes the vendor performed the update with our data.
Click to expand...
It is very odd that a sever crash will occur with out some sort of message being sent to the database.lg file, so I was thinking that some clue might be gained by looking at the client side. No core files on the server either? When you run with the -y at least you'll no what program is running when it crashes.

In the mean time I would scour the server looking for protrace files, core files and system log files (especially network) that might point to a cause.
 
You must log in or register to reply here.
Back
Top