Retain input buffer from fields when QINACTITV kicks user from session. CPI1127

[pizzaguy]

I'm still kinda new to the RPG space, and have frequented this forum many times for information. I guess it's time I actually post a question as my research has not led me to a working result yet.

My new shop has a strict 20 minute inactivity timeout setting for the workstations. 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.

I was hoping the PSSR can trap the error was have the input field written out to a work file. A CL program will be needed to check in there is any data out in the workfile when the resume the program. This workfile could be cleared each night after hours to avoid left over data. The problem I'm running into is that even after coding a PSSR routine in the program, it isn't executed when the system ends the job. The CPI1127 message can be found in the QSYSOPR queue, but the PSSR doesn't seem to catch this.

Here is a sample program I wrote to test that theory. The program should write to the XT90 file unless an error occured, then it should write to XT91 instead.

H OPTION(*NODEBUGIO: *SRCSTMT)
H DFTACTGRP(*NO)
H*================================================ ======================*
H* DATA LOSS INACTIVITY TEST PROGRAM *
H*================================================ ======================*
F* FILE SPECS
F*================================================ ======================*
FXT90 UF A E DISK INFSR(*PSSR)
FXT91 UF A E DISK
FXT90DF CF E WORKSTN INFSR(*PSSR)
D*================================================ ======================*
D* DEFINITION SPECS
D*================================================ ======================*
** Program Status Data Structure
D SDS
D PGMMSGID 40 46a
D pgmruntime 6s 0
D PSSRDone S N
C*================================================ ======================*
C* CALC SPECS
C*================================================ ======================*
C*
/FREE
//FREE FORMAT CODE BELOW
DOU *IN03;
INPUT = *BLANKS;
IF *IN03;
LEAVE;
ENDIF;
MONITOR;
WRITE RECORD1;
//DO STUFF WITH RECORD
READ RECORD1;
INTXT = INPUT;
WRITE XT90R;
ON-ERROR;
//IF PGMMSGID = 'CPI1127';
INTX2 = INPUT;
WRITE XT91R;
//ENDIF;
ENDMON;
ENDDO;
*INLR = *ON;

BEGSR *PSSR;
IF PSSRDONE;
*INH1 = *ON;
RETURN;
ELSE;
//IF PGMMSGID = 'CPI1127';
INTX2 = INPUT;
WRITE XT91R;
//ENDIF;
ENDIF;
ENDSR;

/END-FREE


C*
O*================================================ ======================*
O* OUTPUT SPECS
O*================================================ ======================*
**
***END OF PROGRAM***

Display Source:

A R RECORD1 CF03(03)
A 1 2SYSNAME
A 2 71TIME
A 1 71DATE
A 2 2'XT90DF'
A 1 35'TEST DISPLAY'
A DSPATR(RI)
A COLOR(TRQ)
A INPUT 50 B 6 16


Am I barking up the wrong tree with PSSR and MONITOR? Thanks in advance.

[tomliotta]

Since nothing is moved into the "buffer" until /Enter/ or similar function key is pressed, a *PSSR (nor any) routine won't be able to capture anything. If the job is ended, whatever is still in the client stays there. And an ended job won't do anything anyway unless the end-condition is trapped and the end-job signal allows a delay.

Better in your case might be not to do ENDJOB but to build a kind of "screen saver" function that requires password entry to unlock. One obstacle to that is that you might not be able to change existing application code. It is possible to control it externally though. If you can change the application(s), you might find it easy to code in a handler to react to a signal from a program that monitors QINACTMSGQ. Even if apps can't be directly changed, facilities such as routing programs in interactive subsystems can enable handlers for jobs.

I've also seen commercial solutions, but I haven't checked any out for years. A truly reactive and customizable solution can be more than trivial.