RE: is operating system always to blame, was: Ready to scrap an A S/400

Then start using the operating system.  As I said earlier, 
use group profiles and change the group profile:
chgusrprf usrprf(yourgroup) maxstg(yourvalue)
Stopped this problem for us.





mwalter@netrax.net on 07/27/2000 09:33:02 AM
Please respond to MIDRANGE-L@midrange.com@Internet
To:     MIDRANGE-L@midrange.com@Internet
cc:      
Fax to: 
Subject:        RE: is operating system always to blame, was: Ready to scrap an 
A       S/400

I've also encountered this scenario personally, which, by the way is the 
reason we removed the query option from users. The system was a 9406 E50 
with 9332 disk drives. The disk filled up to 100% and the system crashed 
with disk errors. When we IPL'd and tried to recover, there were damaged 
objects all over the place. It required a complete restore. Still, I 
believe that the OS was doing it's job. It warned the sysop that the disk 
has reached it's threshold, he ignored the message. We had very little 
warning until the big BOOM. IMHO, the OS has no way of knowing how much is 
too much.

-----Original Message-----
From:   Cox, Joe [SMTP:joecox@montana.edu]
Sent:   Wednesday, July 26, 2000 5:18 PM
To:     'MIDRANGE-L@midrange.com'
Subject:        RE: is operating system always to blame, was: Ready to scrap an 
A       S/400

Ran into this situation about 9 months ago.  When running at 95% of 
capacity
while waiting to install a new 400 an errant query with improper joins
filled the disk.  The system appeared to everybody to be locked up.  I had
always heard horror stories about disk crashes when they reached 100%.  So 
I
was very pleasantly surprised when I found the controlling subsystem still
active.  The console was the only thing that would work and it was very
slow, but it did allow me to shut down the job and free up the disk space
before a required IPL.  I'd say the OS did an admirable job even though 
some
would say it did lock up.


        -----Original Message-----
        From:   Mark Walter [SMTP:mwalter@netrax.net]
        Sent:   Wednesday, July 26, 2000 1:19 PM
        To:     'MIDRANGE-L@midrange.com'
        Subject:        RE: is operating system always to blame, was: Ready
to scrap an AS/400

        Say the program loops and writes records into a data file of some
sort,
         the procedure fills up the disk. This can happen by the way. An
AS/400
        query with improper joins specified will also fill up disk. The
cannot know
        what is filling up the disk, it can only warn someone that the disk
is
        reached its threshold. Eventually, the machine will fail. I'd say
that this
        is not the fault of the OS.

        -----Original Message-----
        From:   Leif Svalgaard [SMTP:leif@leif.org]
        Sent:   Tuesday, July 25, 2000 2:16 PM
        To:     MIDRANGE-L@midrange.com
        Subject:        Re: is operating system always to blame, was: Ready
to scrap an
        AS/400

        ----- Original Message -----
        From: Mark Walter <mwalter@netrax.net>
        To: <MIDRANGE-L@midrange.com>
        Sent: Tuesday, July 25, 2000 12:43 PM
        Subject: RE: is operating system always to blame, was: Ready to
scrap an
        AS/400


        > I'm sorry but a program that goes into a infinite loop and brings
a
        system
        to it's knees is not  the fault of the operating system.
        >

        If a an application program goes into an infinite loop and the WHOLE
system
        is on its knees, it IS the fault of the operating system.


        +---
        | This is the Midrange System Mailing List!
        | To submit a new message, send your mail to
MIDRANGE-L@midrange.com.
        | To subscribe to this list send email to
MIDRANGE-L-SUB@midrange.com.
        | To unsubscribe from this list send email to
        MIDRANGE-L-UNSUB@midrange.com.
        | Questions should be directed to the list owner/operator:
        david@midrange.com
        +---

        +---
        | This is the Midrange System Mailing List!
        | To submit a new message, send your mail to
MIDRANGE-L@midrange.com.
        | To subscribe to this list send email to
MIDRANGE-L-SUB@midrange.com.
        | To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
        | Questions should be directed to the list owner/operator:
david@midrange.com
        +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to 
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: 
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---