Re: Terminated Interactive Job Impacts Nightly Processing -- MIDRANGE-L

On 07 Jun 2013 11:22, Victor Hunt wrote:

The kill program looks at all jobs in QINTER and kills all the jobs
that it finds. It does not check for the type of job.

That indicates a likely defect, either with the /kill program/ or with the API [or non-API interface] that is utilized to implement that kill-program. If *all jobs* are supposed to get ended, then why not just ENDSBS QINTER to be thorough, eliminating need for any logic to obtain and process a list of jobs within the program.?

Yes, we thought the DSPLOG would have also shown the disconnect
activity (in fact when we tried it this morning, it did). But for the
Wednesday job, none was displayed. QDEVRCYACN is set to *DSCMSG, we
are considering a change to *ENDJOB.

The QDEVRCYACN is a system value, which may or may not reflect what was established for the job. As I had noted in my prior reply, the actual DEVRCYACN for the job may have been different than the system value. If the job still exists [even if *OUTQ status], then the request to WRKJOB OPTION(*DFNA) will show the "Device recovery action". If the job had defined DEVRCYACN(*MSG), then the onus is on the application to handle the condition; it could choose to effect the DSCJOB, but could do something else instead.

The *DSCMSG depends on the active application to deal properly with the message, upon reconnect. Similarly upon reconnect, the application must deal with the EndRqs, if *DSCENDRQS is utilized. In either case, the job should disconnect, and the history log should log that effect.

We notice, at midnight every night, several jobs ending/starting or
starting/ending (QHTTP, CRTPFRDTA, QPMHDWRC, etc.) over a period of
a few seconds.
The user job in question ends 15 minutes after this activity, which
corresponds to the setting of the QDSCJOBITV sysval (15 minutes).

The job should have ended within 30 minutes of the job having been disconnected. However as noted earlier, this particular job was apparently not diagnosed as /disconnected/ according to the DSPLOG results. So perhaps the job was never disconnected; never was in status DSC, but still for some reason was not ended by the kill program.? What does the spooled joblog for that job show transpired?

Perhaps something was "reset" that allowed this job to be "visible"
to the system again? Perhaps one of these jobs cleaned something up?

Doubtful. But there is something not understood yet about the scenario, which could include defect(s) which could confound a logical interpretation of what happened, with only what is currently known.

Regards, Chuck

On Fri, Jun 7, 2013 at 11:25 AM, CRPence wrote:

On 07 Jun 2013 09:11, Victor Hunt wrote:

<<SNIP>>

On Wednesday at 16:45, a user went into this program using his
client (iAccess for Windows), did some work, and then hit the
"red X" and closed the session (he normally doesn't do this).
There were no messages of any kind in QSYSOPR or in DSPLOG for
this session.

Our nightly process runs at 21:00, that night a number of
processes did not complete due to locked files (mostly file
reorgs). At 00:15 on Thursday we see an entry in DSPLOG where the
users session is finally ended due to the QINACTITV time-out,
which is set to 150 minutes. QINACTMSGQ is set to *ENDJOB.

The job was likely in DSC status per the "Device Recovery Action"
(DEVRCYACN) for the job; that *may* resolve from the QDEVRCYACN
system value, but could come from elsewhere or changed within a job
with CHGJOB. I would have expected however, that the DSPLOG
JOB(the_job) would have revealed the disconnect activity. Perhaps
that effect was not recorded, and thus confuses the [understanding
of the] issue. The subsystem monitor job however, I believe would
have a message about the job being disconnected, IIRC.

In addition, we have a job that runs 15 minutes before our
nightly job that kills all the jobs in QINTER. This job reported
no running jobs in QINTER Wednesday night.<<SNIP>>

Verify that the program does not overlook jobs in the Disconnected
status.