|
Jim, My suggestion (not frying the user with a few thousand volts, the one to set QJOBMSGQFL to *NOWRAP) has an advantage over your suggestion in that it will allow device errors to be recovered. Did you ever have a remove PC5250 session drop due to a line problem, and want to dial back in and get reconnected to that job ? Well QDEVRCYACN seto to *ENDJOB or *ENDJOBNOLIST will prevent you from doing that. On the other hand, if you have a system with a slower processor, you might not be able to put up with the performance hit while the job loops until it fills the job message queue, and then produces the joblog. It's not that noticeable on a system with a reasonably high CPW rating, or multiple processors. So as with many things, I guess the answer is "it depends". Do you have a fast or slow system ? Do you have multiple processors ? Is the ability to reconnect to a job disconnected due to a communications error more important than the slowdown encountered while letting the job loop for a while ? Of course John Carr had an excellent point - assuming you have control of the source code for the application you are running (or complain loudly to the vendor). The programs should be written to allow for a lost connection in the first place and handle the error gracefully instead of going into a tight loop - then you would probably leave QDEVRCYACN at *DSCMSG knowing your programs would handle the situation. PS - John, how about posting a code excerpt for both a CL and RPG program showing how to handle a device disconnect gracefully ? Neil Palmer DPS Data Processing Services Canada Ltd. 50 Acadia Avenue, Ste.102 AS/400~~~~~ Markham, Ontario, Canada. ____________ ___ ~ Phone:(905) 474-4890 x303 |OOOOOOOOOO| ________ o|__||= Cell.:(416) 565-1682 x303 |__________|_|______|_|______) Fax: (905) 474-4898 oo oo oo oo OOOo=o\ mailto:NeilP@DPSlink.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.DPSlink.com iSeries 400 The Ultimate Business Server "Jim Franz" <franz400@triad.rr.com> Sent by: owner-midrange-l@midrange.com 2001/02/26 20:48 Please respond to MIDRANGE-L To: <MIDRANGE-L@midrange.com> cc: Subject: Re: Is there a answer for this? > Someone in the Telesales department shuts down there AS/400 session without > properly signing off the system, when this occurs that session > will consume more than 65% of the CPU unless the job is manually ended. > It sounds like the pgm is trying to recover the session. I would look at the system value qdevrvyacn (device i/o error action) and set it to *endjob. Another possibility is that the job has generated a huge job log, in which you may want *endjobnolist. These options are global to the system. The change only applies to new jobs started after the chgsysval. There is also some error options in the RPG for a device error, to have the pgm end more normally, but thats a longer discussion. hth jim +--- | 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.