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 shop has a strict 20 minute 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. (Note: they are being given ten 70 length fields to type data in.)
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 will 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.
Hi,
I'm not sure of the best way to handle this and I understand the problem. What I would look into doing is some sort of information saving during the screen entry. Every few seconds save the info from it. Either that or change the timeout to something over 20 minutes. I don't think you're going to be able to trap the timeout message for the workstation.
If you want to expand your question to many more eyes, I would post it at Midrange.com in the Midrange-L mailing list. I'm sure you'll get quite a few other ideas from there.
Sorry I couldn't be of more help. This one just isn't my forte these days. :)
The problem lies with one particular program that gives the user a large field for entry. They typically type long, verbose entries into this field (or set of 10 fields I should say) on a screen. The user doesn't do anything to reset the inactivity timer during this period of time and then the system ends their session for inactivity. all the data typed in the fields on that screen is lost.
Changing the timeout length is not an option unfortunately.
I shall also post this on Midrange, and have been trying to post to Code400 as well.
Hope that helps clear up any ambiguity about the issue at hand. Thanks.
Here's the link to the Midrange.com discussion in case anyone needs this info: