PROGRESS APPLICATIONS on SCO UNIX Crashes UNIX

PROGRESS APPLICATIONS on SCO UNIX Crashes UNIX

Post by CK » Tue, 05 Mar 1996 04:00:00



Hello all,

we have a couple of SCO Unix System V boxexs around running PROGRESS 6.4F.
Recently, we have installed a turned-key financial application on one and there are 16 users who can access 150 database tables at one time.
Therefore 16 users x 150 tables each gives 2,400 possible opened tables. The system keep halting whenever we try doing period close or any types of month-end analysis or reporting.
The machine is 64 MB RAM with 4 GB HDD. The user filesystem in which PROGRESS and the application is residing is about 90% free.
The root filesystem has 300 MB and only 150 MB is used.

We have been changing kernal parameters (increasing them) but it does not seem to help.

Can anyone out there suggest what is wrong ? we have similar machines in Hungary and China running SCO Unix and HP-UX but they seem to be OK.
Except that the Hungarian system is using a sub-set of the said application.


would increasing the following parameters help or am i looking at the wrong place ? :

further down, i've also an extract of the sar report from the same system.

Thank YOU in advance.
charles

******* extract of kernel parameters *******

1. nfile      445
2. ns5inode   445
2. maxup      100
3.    
4. nrgeion    3000
5. ninode     1200
6. ctbufsize  128
7. nhinode    128
8. SEMMAP          50
9. SEMMNI          40
10. SEMMNS          500
11. SEMMNU          500
12. SEMMSL          400
13. SEMOPM          10
14. SEMUME          10
15. SEMVMX          32767
16. SEMAEM          16384
17. SHMMAX          524288
18. SHMMIN          1
19. SHMMNI          100

****Extract of sar report ***********

00:00:01 proc-sz ov inod-sz ov file-sz ov lock-sz

01:00:01  56/800  0 198/450  0 201/445  0   3/100

02:00:00  56/800  0 198/450  0 200/445  0   3/100

03:00:01  56/800  0 198/450  0 201/445  0   3/100

04:00:01  56/800  0 198/450  0 201/445  0   3/100

05:00:00  56/800  0 198/450  0 201/445  0   3/100

06:00:01  56/800  0 199/450  0 200/445  0   3/100

07:00:01  56/800  0 198/450  0 201/445  0   3/100

08:00:01  56/800  0 197/450  0 200/445  0   3/100

08:20:00  56/800  0 198/450  0 201/445  0   3/100

08:40:01  56/800  0 198/450  0 200/445  0   3/100

09:00:01  56/800  0 198/450  0 201/445  0   3/100

09:20:01  64/800  0 210/450  0 250/445  0   3/100

09:40:01  68/800  0 218/450  0 285/445  0   3/100

10:00:02  80/800  0 233/450  0 349/445  0   3/100

10:20:01  80/800  0 230/450  0 330/445  0   3/100

10:40:01  80/800  0 233/450  0 341/445  0   3/100

11:00:01  80/800  0 236/450  0 313/445  0   3/100

11:20:01  80/800  0 236/450  0 317/445  0   3/100

11:40:01  78/800  0 232/450  0 313/445  0   3/100

12:00:01  78/800  0 228/450  0 301/445  0   3/100

12:20:01  78/800  0 232/450  0 321/445  0   3/100

12:40:01  75/800  0 221/450  0 295/445  0   3/100

13:00:01  76/800  0 225/450  0 305/445  0   3/100

13:20:01  76/800  0 225/450  0 305/445  0   3/100

13:40:01  76/800  0 224/450  0 304/445  0   3/100

14:00:01  76/800  0 225/450  0 305/445  0   3/100

14:20:01  76/800  0 228/450  0 317/445  0   3/100

14:40:01  78/800  0 234/450  0 323/445  0   3/100

15:00:01  76/800  0 228/450  0 317/445  0   3/100

15:20:01  72/800  0 223/450  0 293/445  0   3/100

15:40:01  77/800  0 232/450  0 313/445  0   3/100

16:00:01  82/800  0 236/450  0 336/445  0   3/100

 
 
 

PROGRESS APPLICATIONS on SCO UNIX Crashes UNIX

Post by Geoff Crawfo » Wed, 06 Mar 1996 04:00:00



says...

Quote:

>we have a couple of SCO Unix System V boxexs around running PROGRESS

6.4F.

6.4??  6.3 I understand, didn't know they had a 6.4 yet.

Quote:>Recently, we have installed a turned-key financial application on one

and there are 16 users who can access 150 database tables at one time.
Quote:>Therefore 16 users x 150 tables each gives 2,400 possible opened

tables.

Progress does not work this way *at all*.  There is only one operating
system file for the database, plus the .bi and .lg for open files.  
From the Unix perspective there are more files open when you are
running the application because of the .r's than the database.

Quote:>The system keep halting whenever we try doing period close or any
types of month-
>The machine is 64 MB RAM with 4 GB HDD. The user filesystem in which

PROGRESS and the application is residing is about 90% free.

Quote:>The root filesystem has 300 MB and only 150 MB is used.

All of that sounds just fine as far as Progress V6 is concerned.

Quote:>We have been changing kernal parameters (increasing them) but it does
not seem to help.

That's probably not your problem.

Quote:>would increasing the following parameters help or am i looking at the
wrong place ? :

>further down, i've also an extract of the sar report from the same
system.

[stune and sar snipped]

Check the error log in /usr/adm.  Are there messages there??  If not,
and you're not getting a system Panic, then don't change any more
kernel parameters.  Some are already too high.

You don't say exactly what the behavior is, other than the system
crashes.  What *exactly* crashes.  The Progress session, the database
server, or all of Unix.  I have *never* in 10 years of Progress work
seen Progress itself bring down Unix.  If you are having kernel panics
or other messages, they are probably not related to Progress.

I suspect your "crash" may be more related to the database server.  By
your description it sounds like the large process is overflowing the
lock table.  Either shorten the scope of your transaction, or use a
large -L parameter.

HTH.

======================================================================
Geoff Crawford                              Phone:    (201) 627 - 0307
Innovative Client Servers                   FAX:      (201) 627 - 0634

Denville NJ 07834

 
 
 

PROGRESS APPLICATIONS on SCO UNIX Crashes UNIX

Post by Geoff Crawfo » Thu, 07 Mar 1996 04:00:00




Quote:

>My guess is that you could be exceeding NLOCKS (or the one that
restricts
>the number of locks).

No, no, no.  Again, Progress does *not* use Unix parameters for this.  
There is nothing in the kernel that needs to be changed.

Quote:

>Look at the Progress parameters like -L. Can you tell us the server
>parameters ?

As I mentioned previously, that's the place to look.

======================================================================
Geoff Crawford                              Phone:    (201) 627 - 0307
Innovative Client Servers                   FAX:      (201) 627 - 0634

Denville NJ 07834

 
 
 

PROGRESS APPLICATIONS on SCO UNIX Crashes UNIX

Post by Nigel All » Sun, 10 Mar 1996 04:00:00



>Hello all,
>we have a couple of SCO Unix System V boxexs around running PROGRESS 6.4F.
>Recently, we have installed a turned-key financial application on one and there are 16 users who can access 150 database tables at one time.
>Therefore 16 users x 150 tables each gives 2,400 possible opened tables. The system keep halting whenever we try doing period close or any types of month-end analysis or reporting.

                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I don't think that his is your problem - the Progress databvase is
only one file (maybe more if you use muti-volume) - anyway - Progress
does not use one file descriptot per table.

Nigel.

----------------------------------------------------------------------
Nigel Allen                          phone: +61 (0)2  498 7555
Senior Consultant                    fax:   +61 (0)2  498 7498
Progress Software Pty Ltd            mob:   +61 (0)41 112 1092

Pymble, N.S.W. Australia 2073        web:   http://www.progress.com
                "Flat out - like a lizard drinking"
----------------------------------------------------------------------

 
 
 

1. Get variable from Unix script (SCO Unix/ Progress V8.3C11)

Hello,

running Progress V8.3C11 under SCO Unix OSR5.06.
Is it possible to get from a L4G Progress code a Unix shell script
variable.
In my Unix script I load a flag with true or false, after testing result
of some operations, and would like to use this the value of the flag in
my progress program.

Thank's.
F. STOCK

2. Problem using OLEDB provider for Jet 3.51

3. PC with Progress to SCO UNIX with Progress 7.3

4. Concurrent UpdateBatch calls

5. JOB: US-MN Sr Progress Programmer/Analyst - PROGRESS/UNIX/Application Development

6. Testers with C++ or Java, Permanent

7. Recovering from Oracle 7.1(SCO Unix) database crash

8. ORA-12224

9. PROGRESS 8 & SCO UNIX Compatibility

10. Question - SQL on PROGRESS/SCO Unix

11. Problem with Progress 7.3E on Sco Unix 3.2v4.2

12. Progress 9.0A (or B) on SCO Unix

13. Progress V7.3E and SCO Unix 5.0.5