RE: Time limits in RPG

Prompt the CRTPF command, F9, scroll down to:

Maximum file wait time . . . . . WAITFILE       30     
Maximum record wait time . . . . WAITRCD        60     

Francis Lapeyre
IS Dept. Programmer/Analyst
Stewart Enterprises, Inc.
E-mail: flapeyre@xxxxxxxx 

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Douglas Palme
Sent: Monday, November 13, 2006 4:32 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Time limits in RPG

Speaking of timeouts, what is the default timeout period for a file ?
And
can it be changed on a file by file basis?


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Scott Klement
Sent: Monday, November 13, 2006 4:28 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Time limits in RPG

Hi Phil,

As well, we have a situation where the users sometimes hold a session

w/

a particular program. However, in the past, they have not been able to
use the system values that pertain to ending sessions after a certain
time has passed and a key was not hit.

Hmmm... there's no way to tell whether a key was hit. The system sends 
data to a terminal a full screen at a time.  It then lets the terminal 
take care of all the editing of the data on the screen.  The system 
doesn't receive control again until an AID-generating key is pressed,
such 
as ENTER or a F-key, etc.

I'm sure you've encountered this behavior already.

If you want, you can perform a timeout when no AID-generating key has
been 
pressed for 30 minutes.  Or whatever time limit you prefer.  But there's

no way to do it based on whether any key has been pressed (that is,
short 
of writing your own emulator, and adding that functionality to the 
emulator itself.)

I know of 3 different ways to wait until a timeout has occurred on a 
screen, and have the program resume control:

a) The WAITRCD keyword for the CRTDSPF command.

b) Attach a data queue to the display file, write the display with the 
INVITE keyword, and wait for a data queue entry before reading the 
display.  Since data queues can time-out, this lets you check for a 
timeout.

c) Schedule the system to send an alarm signal (with the alarm() API)
and 
set up a subprocedure that's called automatically when a signal is 
received.  Then display the screen as normal.  If a signal is received,
a 
timeout has occurred, so use an *ESCAPE message to cancel the screen.


There are pros and cons to each method.  Here are my experiences:


Method A works okay, but has some drawbacks:

     -- You have to code MAXDEV(*FILE) on the F-spec, and always read
           the file with the READ op-code by FILE (not record format)
           name.

     -- You have to code an OVRDSPF to override WAITRCD before opening
           the display file (or before the program starts) -or- you
           to remember to type the WAITRCD parameter every time you
           rebuild the display file (I prefer the OVRDSPF method so
           I can't forget to specify the keyword.)

     -- Each time a timeout occurs, the user will see it. Input
inhibited
           will go on until the screen is read again.  For what you're
           doing, this won't matter. But, if you wanted to (for example)
           check %SHTDN every 5 seconds, this would be very annoying.


Method B works very nicely as well, however:

     -- You still have to OVRDSPF before displaying the screen, but now
you
           specify a data queue to attach to instead of WAITRCD

     -- The data queue has to be built first.

     -- You still have to use READ/WRITE instead of EXFMT, but you can
use
            the record format name if you prefer.

     -- You have to call the data queue APIS, which might add
complexity.

     -- Since the program is waiting on the data queue and not the
display
           file, you have problems if the user turns the terminal off or
           loses communications before exiting the screen.  The program
           doesn't know that the user has disconnected, since it's not
           waiting for the screen, it's waiting for the data queue.

     -- Unlike method A, this method is invisuble to the user until you
           display another screen or close the display file and cause
the
           screen to change.

Method C is much more unconventional, but it's the one I prefer.

     -- No special display file coding. You can use EXFMT as always.

     -- It doesn't interrupt the screen until you display something
           different. This makes it suitable for checking %SHTDN in
           a loop.  (Using an interval timer, for example.)

     -- Since the program is still waiting on the EXFMT, it still
receives
           errors if the user disconnects.

     -- You have to use the Unix-type APIs alarm(), setitimer() and
           sigaction() which can add complexity, though I generally
           find the Unix-type APIs to be much easier to read than the
           i5/OS APIs.

     -- Have to call the QMHSNDPM API to send the *ESCAPE message, and
           have to have some knowledge of how escape messages work.