bodger
asked on
RPG Timed Wait or Delay Function
Can anyone suggest a better way than that shown below to implement a Timed Wait in RPG?
C TIME TIMEA 60
C Z-ADDTIMEA TIMEB 60
C TIMEA DOWEQTIMEB
C TIME TIMEB
C ENDDO
My concern with a delay as implemented above is that it is very processor intensive. Unless the job as a whole were assigned a very low priority it could all but freeze the system and were the delay to be larger than 1 second, say 1 minute, then the freeze could become a nuisance to other users.
In the particular assignment which needs this delay function, it cannot be achieved outside the RPG program, so a CL wait is of no use unless it is part of a separately threaded CLP which sends timed messages to the RPG program (in which case the question becomes one of how to wait for a message within an RPG program).
C TIME TIMEA 60
C Z-ADDTIMEA TIMEB 60
C TIMEA DOWEQTIMEB
C TIME TIMEB
C ENDDO
My concern with a delay as implemented above is that it is very processor intensive. Unless the job as a whole were assigned a very low priority it could all but freeze the system and were the delay to be larger than 1 second, say 1 minute, then the freeze could become a nuisance to other users.
In the particular assignment which needs this delay function, it cannot be achieved outside the RPG program, so a CL wait is of no use unless it is part of a separately threaded CLP which sends timed messages to the RPG program (in which case the question becomes one of how to wait for a message within an RPG program).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You can also add error reporting to this api
H Option(*SrcStmt : *NoDebugIO)
H Dftactgrp( *No )
H Actgrp( *Caller )
H Bnddir( 'QC2LE')
D sleep PR 5u 0 EXTPROC(*cnowiden:'sleep')
D p_sec 5u 0 Value
D Sec s 5u 0
D Rtn s 5u 0
/free
Rtn = sleep( 60 );
*inlr = *on;
/end-free
H Option(*SrcStmt : *NoDebugIO)
H Dftactgrp( *No )
H Actgrp( *Caller )
H Bnddir( 'QC2LE')
D sleep PR 5u 0 EXTPROC(*cnowiden:'sleep')
D p_sec 5u 0 Value
D Sec s 5u 0
D Rtn s 5u 0
/free
Rtn = sleep( 60 );
*inlr = *on;
/end-free
ASKER
Dave
Regarding your question. I have an output-only status display, at a keyboardless terminal, which must be periodically updated.
Regarding your question. I have an output-only status display, at a keyboardless terminal, which must be periodically updated.
ASKER
Dave
I'm using QCMDEXC.
Thanks
I'm using QCMDEXC.
Thanks
Ahh
why don't you use a dataq. The dataq can autiomaticaly update the display when an entry is received. No waiting.
Dave
why don't you use a dataq. The dataq can autiomaticaly update the display when an entry is received. No waiting.
Dave
I agree with dave on that one. That is how the displays work at airports that use a as400. Flight information hits a dataq that then triggers a display which will update and wait for the next event.
AFAIK, the dtaq is attached to the display file and the program then waits for an entry to appear on the data queue. (See CRTDSPF DTAQ().) When a user presses <Enter> or some other AID-generating key, that's when the data queue entry is created.
This way, the program logic is driven by the data queue rather than by the display file. Instead of the program delaying during an EXFMT statement, the program simply does a WRITE and the calls the data queue API. Essentially all other logic is the same.
When the API is called, a wait-time is specified. If no entry appears within the wait-time, the API returns an indication that there was no entry available; and the program then continues on to output the next refresh and wait again.
Note that one side effect is that entries can be written to the data queue by external programs in order to cause a refresh-on-demand. Also note that there is no user required -- if no keys are pressed for the display file, then the API stills returns once the time limit passes.
Tom
This way, the program logic is driven by the data queue rather than by the display file. Instead of the program delaying during an EXFMT statement, the program simply does a WRITE and the calls the data queue API. Essentially all other logic is the same.
When the API is called, a wait-time is specified. If no entry appears within the wait-time, the API returns an indication that there was no entry available; and the program then continues on to output the next refresh and wait again.
Note that one side effect is that entries can be written to the data queue by external programs in order to cause a refresh-on-demand. Also note that there is no user required -- if no keys are pressed for the display file, then the API stills returns once the time limit passes.
Tom
what are you waiting for?