× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: is operating system always to blame, was: Ready to scrap an A S/400
  • From: Rob Berendt <rob@xxxxxxxxx>
  • Date: Thu, 27 Jul 2000 12:01:24 -0500

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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.