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



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. Yes, we thought the DSPJOB
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.

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).
Perhaps something was "reset" that allowed this job to be "visible" to the
system again? Perhaps one of these jobs cleaned something up?



On Fri, Jun 7, 2013 at 11:25 AM, CRPence <CRPbottle@xxxxxxxxx> 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.

--
Regards, Chuck
--
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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.