I hope this interest of yours is for your own edification, rather than a job you're working on. Otherwise, you should be relaxing and enjoying a day off ;-)
I'm not aware of any way for 5250 clients to both "listen" for "broadcast" messages and accept data entry at the same time. Web browsers can, by firing off asynchronous requests under the covers so to speak while a data entry form is displayed. And those "hidden" asynchronous requests can "wait" indefinitely for "broadcast" messages that may originate from essentially anywhere; from events originating from other clients, or events originating from other servers.
So inventory counts may be updated on EVERY order entry screen wherever, the moment an order is keyed from any one of them.
While the following example demonstrates a set of chat clients, the same architecture could be as easily applied to a set of order entry / inventory clients:
So yes, using a web browser, inventory could be broadcast to and updated on every client the moment an order is keyed on any other client.
----- Original Message -----
From: Booth Martin <booth@xxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Sunday, September 2, 2012 8:11 PM
Subject: Re: Event-based actions
Therein lies the problem that prompted me to start this thread. The
/field/ has to refresh, not the screen. Plus the cursor has to stay
where it was, and keyed data has to remain unchanged. It has to look
like nothing happened except a couple of fields updated. No flash, no
flicker; just the needed fields change their value.
Here is a description of the GWT Event Bus: "Dispatches GwtEvents to
interested parties. Eases decoupling by allowing objects to interact
without having direct dependencies upon one another, and without
requiring event sources to deal with maintaining handler lists. There
will typically be one EventBus per application, broadcasting events that
may be of general interest. "