RE: RE: CPI2417 Job message queue for xxxxxx/xxxxxx/xxxx has been wrapped. *** Additional Information ***

Thanks Tom. Yes, now that you mention that I seem to recall other instances
of this behavior at another job but that was a long time ago and it happens
so seldomly (thankfully !). 

So should I just end QINTER *IMMMED instead of *CNTRLD 300 ?

Thanks !

Chuck

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of qsrvbas@xxxxxxxxxxxx
Sent: Wednesday, October 12, 2005 8:31 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: RE: CPI2417 Job message queue for xxxxxx/xxxxxx/xxxx has
beenwrapped. *** Additional Information ***

midrange-l-request@xxxxxxxxxxxx wrote:

>  10. RE: CPI2417 Job message queue for xxxxxx/xxxxxx/xxxx has been
>      wrapped. *** Additional Information *** (Chuck Lewis)
>
>Here is what is in that CL:
>
>ENDSBS SBS(QINTER)    OPTION(*CNTRLD) DELAY(300)
>MONMSG     MSGID(CPF1054)  
>
>So should I just change that to *IMMED and would that do the trick ?
>
>What I had to do this morning was issues an ENDJOBABN against the job that
>was "stuck"

Chuck:

AFAIK, a subsystem will _not_ end until all of the jobs within it end. It's
always been that way (AFAIK).

Perhaps what you wanted was something like:

 ==>  endjob xxxxxx/xxxxxx/xxxx option(*immed) loglmt( &n )

where &n is some rational limit, perhaps even zero. If you knew what the
messages were that were being written and didn't want to see them, zero
might be fine.

>-----Original Message-----
>
>Cut to the chase here, what the heck is going on when one stinking job can
>keep QINTER from ending ? This is an iSeries 810 at V5V2.

...and like I said, this has always been true and I believe it's true for
every subsystem not just QINTER. The reason it isn't more widely
known/realized is simply that we rarely see jobs that "won't" end. I'm as
close to certain as I can get that none of us have seen any subsystem end
before the jobs within it ended. (Note that this is not the same as a
subsystem going to END status.)

In some ways, this is one item where Windows Task Manager and its <End
Process> followed by its "Program is not responding. End now?" message can
seem to have an advantage. OTOH, how often do we wish we could look into the
joblog of a Windows task?

If anyone else can add to/correct any of this, please do so.

Tom