Re: Time limits in RPG -- RPG400-L

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 sendsdata to a terminal a full screen at a time. It then lets the terminaltake care of all the editing of the data on the screen. The systemdoesn't receive control again until an AID-generating key is pressed, suchas 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 beenpressed for 30 minutes. Or whatever time limit you prefer. But there'sno way to do it based on whether any key has been pressed (that is, shortof writing your own emulator, and adding that functionality to theemulator itself.)

I know of 3 different ways to wait until a timeout has occurred on ascreen, 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 theINVITE keyword, and wait for a data queue entry before reading thedisplay. Since data queues can time-out, this lets you check for atimeout.

c) Schedule the system to send an alarm signal (with the alarm() API) andset up a subprocedure that's called automatically when a signal isreceived. Then display the screen as normal. If a signal is received, atimeout 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.