Re: Is there a answer for this?

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