Re: Terminated Interactive Job Impacts Nightly Processing

I was able to run the WRKJOB command on this job with the *DFNA option (the
joblog is still on the system) and it shows the device recovery action to
be *DSCMSG. The joblog shows a call to the inquiry program at
16:48:31.065915. The next job log entry is the disconnect (CPI1127) at
00:15:36.300062. There are no entries between the two.

It's not clear to me what the user did. He thinks he just clicked on the
"X" rather than end his session as he normally does. But it's fuzzy to him.
We tried to recreate this issue a number of different ways without any
success (in all tests the job was disconnected as it should be with the
appropriate disconnect message in the joblog). I'm not sure he did what he
thinks he did, but then again, I don't know what he did do either.

I don't really have an explanation as to why we didn't just end the
subsystem, which will be doing from now on.



On Fri, Jun 7, 2013 at 2:53 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

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.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.