[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 15261
  • Last Modified:

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).



0
bodger
Asked:
bodger
  • 3
  • 2
  • 2
  • +1
1 Solution
 
daveslaterCommented:
Hi
2 Solutions
A) Use QCMDEXC to issue the dlyjob cl statement
b) use the QC2LE sleep procedure
there is also Usleep that works down to a millisecond
H DFTACTGRP(*NO)

D sleep           PR            10I 0 extproc('sleep')
D   seconds                     10U 0 value

D usleep          PR            10I 0 extproc('usleep')
D   Miliseconds                 10U 0 value


c                   callp     sleep(10)
c                   callp     usleep(1000)


Dave
0
 
daveslaterCommented:
ps
what are you waiting for?
0
 
odumbruceCommented:
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                                                          
0
Nothing ever in the clear!

This technical paper will help you implement VMware’s VM encryption as well as implement Veeam encryption which together will achieve the nothing ever in the clear goal. If a bad guy steals VMs, backups or traffic they get nothing.

 
bodgerAuthor Commented:
Dave

Regarding your question. I have an output-only status display, at a keyboardless terminal, which must be periodically updated.
0
 
bodgerAuthor Commented:
Dave

I'm using QCMDEXC.

Thanks

0
 
daveslaterCommented:
Ahh
why don't you use a dataq. The dataq can autiomaticaly update the display when an entry is received. No waiting.

Dave
0
 
odumbruceCommented:
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.
0
 
tliottaCommented:
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
0

Featured Post

Vote for the Most Valuable Expert

It’s time to recognize experts that go above and beyond with helpful solutions and engagement on site. Choose from the top experts in the Hall of Fame or on the right rail of your favorite topic page. Look for the blue “Nominate” button on their profile to vote.

  • 3
  • 2
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now