Hi Scott,
Not sure you can trap this via PSSR and MONITOR. However, check out the
SHTDN opcode. I believe this requires that the job be ended with
OPTION(*CNTRLD) DELAY(nn), where 'nn' is the number of seconds sufficient
enough for the program to do whatever it is you need it to do. I've never
used this in an interactive program, so I'm uncertain whether SHTDN will
work in a scenario where the program is waiting for input from the
workstation file. I'm thinking that, instead of EXFMT, you might need to
do WRITE, SHTDN, READ opcodes. The more I think about it though, I think
the program would stop at the READ opcode, so if the job is ended while the
program is sitting on the READ opcode waiting for the user, the SHTDN might
never trap the job ending.
My memory is foggy on this, but I think there is (was?) a way to write to
a workstation file, wait 'x' seconds, read the record, and loop through
this until the user presses Enter or some command key. It might have
required an API, maybe even a call to an IBM-supplied SUBRxx program (S/36
only???).
I think the better option is to disconnect the job (DSCJOB) instead of
ending it. If the job is disconnected, the user sees a signon screen with
a CPI1131 message at the bottom, however, the program and the data input on
the screen is retained in memory until the job is ended. If the user signs
back on before the job is ended, all of the data entered is retained. You
would need to talk to the security officer about changing the inactive
timeout to use DSCJOB instead of ENDJOB. There is a way to do this so the
job disconnects, say, at 20 minutes of inactivity, but the job doesn't
actually get ended until 'n' hours later. If your security officer doesn't
know how to do this, you might want to pose the question on the midrange-l
list.
- Dan
On Wed, Dec 28, 2016 at 8:53 AM, Scott Williams <scottwill0707@xxxxxxxxx>
wrote:
I'm still kinda new to the RPG space, and I guess it's time I actually post
a question as my research has not led me to a working result yet.
My shop has a strict 20 minute timeout setting for the workstations. This
cannot be changed. Workstations (which have static, unique names) are being
kicked (the job is ended, not disconnected) and users are losing input
data. The system kicks out a CPI1127 when this happens. They are typing
lengthy entries and/or get distracted by phone calls, co-workers, etc.
Since they do not press any function keys, rollup/down, or Enter during the
time limit, their entries are lost when the system kicks them. (Note: they
are being given ten 70 length fields to enter data in the program affected
by this timeout setting.)
<snip>
midrange.com
