|
I believe that it is still possible to fill the disk on an AS/400 if you leave database monitor running for many hours. This catastrophe can happen on an AS/400 - the machine that prevents SNADS transfers when they exceed the disk threshold. You may presume that I am speaking from experience. I was VERY cross with my friends in the IBM Rochester database group for allowing this to happen. If I do it to myself, I have no excuse. In my opinion, Rochester should never create a generally-available tool that can kill a system. By the way, I have learned several ways to prevent this from happening. That particular zealous pursuit of knowledge probably wouldn't have happened without experience. The OS should protect itself from malice and stupidity. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Richard Jackson mailto:richardjackson@richardjackson.net http://www.richardjacksonltd.com Voice: 1 303 808 8058 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -----Original Message----- > From: owner-midrange-l@midrange.com > [mailto:owner-midrange-l@midrange.com]On Behalf Of Mark Walter > 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 +---
As an Amazon Associate we earn from qualifying purchases.
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.