RE: RE: CPI2417 Job message queue for xxxxxx/xxxxxx/xxxx has been wrapped. *** 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 Liotta