Issue with a mix of async and sync calls

Author: (Infinity)

Hi There In our application (we are using Uniface 9.6) we are using a service. To use this service, we are invoking operations of this service in ASYNC and SYNC mode. It basically goes like this (In the same sequence as given below)-  In an independent service (Service X)->  Create a new instance of the service (Service Y) (<= This would call Init automatically) Call Operation A of Service Y ASYNC Call Operation B of Service Y SYNC Once in a while (not all the time, this is very sporadic and happens 1 out of 20-30 times) we see that after Init, Operation B runs before Operation A and it is causing production issues for us. We are not able to identify the possible reason why this would be happening and any help in this matter is greatly appreciated. As of now we are thinking that something is messed up in the stack management of URD and we are hopeful that someone has come across this issue before. Thank you J


  1. If the first call needs to finish before the second, why are you calling it async? Using a named instance, it will execute in the same process, as such the first operation is effectively synchronous anyway.  If you do call the first one, and only the first one, async from somewhere else, that is fine, the sync/async decision is made on an activate by activate basis.  Iain

    Author: Iain Sharp (
  2. As "async" say, this call is not in sync :-) What about a component local variable in service Y which hold the current status of the service? Operation A   $LAST_OPER$=""   ...   $LAST_OPER$="A" RETURN Operation B   IF($LAST_OPER$!="A")     ;error handlig or some delay ...     RETURN(-99)   ENDIF   $LAST_OPER$=""   ...   $LAST_OPER$="B" RETURN   

    Author: istiller (
  3. I think the big question is: Why async? Another way to communicate with an async process is  "$DNP", t.i. sending messages between the "clients" which are logged in on the urouter. Once logged in on the urouter you can communicate to all the other registered users or processes. That means: the async process can send an async message to the "calling process": "I've done my job", and the main process can receive this message on the async-Trigger and react. That is quite useful, if you have lots of async processes, and you need some control on who is doing what.   Wolfgang

    Author: gypsilon (