Lol, it sounds to me a little like trying to cram the glass slipper onto granny's gnarled, bunion-riddled feet... Not a good fit for the desired solution.

Where's the disconnect? It's the 5250 protocol itself that stops "event driven" in its tracks... I'm sure one could get really sneaky (maybe using UDDS, data-queues, and break-message-handler program to force a refresh action... dunno...)

Do you really need this in 5250? Sounds like a lot of work for minimal benefit... I'd probably recommend handling this as an exception window popup for cases where an action is selected for a subfile row, the details for the selected item can be re-retrieved, compared to the values stored in the subfile, and determine if the transaction is ok to proceed (i.e. There's still enough on-hand to allocate your transaction).

-Eric DeLong

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike Wills
Sent: Sunday, September 02, 2012 10:33 PM
To: Midrange Systems Technical Discussion
Subject: Re: Event-based actions

This is a great example of making old technology work with new thinking.
This is dead simple in a web application. A client side JavaScript could be
set to listen for changes from a server side script. I believe this is
where Node.js is best sending events to the client.

Mike Wills

Sent from my mobile.
On Sep 2, 2012 9:37 PM, "John McKee" <jmmckee@xxxxxxxxxxxxxx> wrote:

This probably won't work. I don't know that for a fact though.

Could a separate record format be used that had fields that overlaid the
first screen? Grab cursor position, display only updated fields, and
restore the cursor? Actions performed by a WRITE?

John McKee

On Sun, Sep 2, 2012 at 9:11 PM, Booth Martin <booth@xxxxxxxxxxxx> wrote:

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

On 9/2/2012 8:59 PM, Dennis wrote:
You could do this with threads. In your example, a trigger on the
or inventory items file could, well, trigger a message to a data queue on
which one thread of Sally's job is waiting. Another thread may be waiting
for screen interaction, while yet another may be awaiting an Alarm to
(say, a timer Alarm). Any/all of these actions might causevSally's screen
to refresh with new stats.

But Sally is going to be rightly perturbed if she spent the last couple
of minutes filling in fields on that screen, and just when she's ready to
press <ENTER> or some function key, the screen refreshes.
"Nature gave man two ends - one to sit on and one to think with. Ever
since then man's success or failure has been dependent on the one he used
-- George R. Kirkpatrick

Bravely sent from my Galaxy tablet phone.

Booth Martin <booth@xxxxxxxxxxxx> wrote:

The dataque with trigger is pretty straight forward and provides the
event and needed information. Thats the first half of the problem.

Now, I need the other half, the listening part. Lets say Sally has an
inventory item on her screen and is talking with a customer and the
screen shows:

On Hand - 12
Inbound - 12
Allocated - 22
Available - 2

In the call center there are 28 other folks taking orders and some one
of those people sells 4 pieces, leaving as Available a minus 2.

At this point, I would like Sally's screen to refresh and reflect that
there are none left to sell. All without Sally doing anything and
without a timer constantly refreshing her screen every nn seconds.

This is fairly common in the new world, but it isn't clear to me how we
do this on our platform.

Here is a simplistic example:

This clock refreshes every n.nn minutes, based on a timer. I would
rather that when another program sent a change in the time, a
would hear the message and poke the clock program with the new time to
be displayed.

An Executive Dashboard is another example of the problem. How does one
refresh that screen by other than a cycle started with a timer?

On 9/2/2012 8:00 PM, Mark S Waterbury wrote:
Hi, Booth:

I think it would help if you could attempt to describe what problem
are trying to solve, or what you are trying to accomplish. In other
words, what are your goals or objectives.


Mark S. Waterbury

On 9/2/2012 8:38 PM, Booth Martin wrote:
This seems simple enough yet I am stumbling all over the school yard
with it.

This has to do with event-based actions versus waiting for the Enter
to be pressed or for a timer to run out..

This is a fairly simplistic case, but it should serve to demonstrate
problem I am trying to solve.

Lets say a desktop gadget displays the local temperature. When the
temperature changes, the gadget changes the display. As I understand
it, this is accomplished by a "listener" that "listens" for a
temperature change event from the mother ship. It is not a timer that
periodically checks to see what the temperature is. When the listener
hears that the temperature has changed, it alerts the desktop gadget
my desktop display shows the new temperature. As I said, this is a
simplistic case.

So, in midrange world, how do I mimic the behavior of a listener and

This may not be well presented. For that I apologize. Of course, if I
understood the issue better I probably would also know the answer,
right? ;) If you have questions, please ask. That may help me
explain my issue better.

Booth Martin
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page