× 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 there a answer for this?
  • From: "Neil Palmer" <neilp@xxxxxxxxxxx>
  • Date: Mon, 26 Feb 2001 23:53:40 -0500

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