Re: Ending A "Orphaned" Program

Thanks Chuck. Your response has caused some discussion here. Currently, we
have QDEVRCYACN set at *DSCMSG. We are discussed whether or not we wanted
to change that. We do have some folks who like to hit the little red X in
the corner from time to time and being able to recover back to where you
were is nice. At this point I think we'll start with spinning through
active jobs in QINTER and terminating them.

On Mon, May 7, 2012 at 12:14 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 07 May 2012 08:32, Victor Hunt wrote:

I have a user running Windows 7 Professional 64-bit and the current
version of i Access. Twice last week at the end of the working day
this user's PC locked up and the user just turned it off and went
home. Unfortunately, the user had opened our shipping program which
is a green screen program that opens many files including our order
files. At 9 PM we run our end of day processes.

All users are off the system no later than 5:30 PM. Anyone who
leaves their device at a menu, etc., gets signed off by the system
after 2 hours so the nightly processing is not impacted. Not so with
this issue. It will sit in QINTER until we kill the job manually.
Unfortunately it really screws up the nightly process. Looking at
the job log I see a CPF5140 followed by a CPF5503, both are
diagnostic messages. <<SNIP>>

Given the appropriate "Device Recovery Action" (DEVRCYACN) setting
for a job, the error condition signaled as CPF5140 "Session stopped by a
request from device..." can be monitored; an Escape message as seen in a
quick test. When the DEVRCYACN(*DSCMSG) is established for a job, the
system defers signal of that message as an exception until the job is
"reconnected"; per DSC, the job is "disconnected" with an effective
request to DSCJOB. Note however both that the job ends [instead of just
disconnecting] if the session was not established via a "named-device
session", as a side effect of CPF1358 "DSCJOB not allowed." and
disconnected jobs are ended according to the a "Disconnected Job
Interval" timer system value QDSCJOBITV. When the DEVRCYACN(*MSG) is
established for a job, the system signals that exception when the
condition is detected; monitored by the program, the program can decide
how to react. The other three relevant special values *DSCENDRQS,
*ENDJOB, *ENDJOBNOLIST are also described in the help text of the
DEVRCYACN() parameter of the CHGJOBD and CHGJOB commands, and the help
text for the system value QDEVRCYACN. Those and my above description of
the prior two special values, in conjunction, will hopefully assist to
make sense of how things should work.

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.