Re: Hmmmm.....$1 Billion -- MIDRANGE-L

Would we be approaching event based programming in RPG if our mainline was a
select with each "when" being an event  followed by an "exsr"?  If we stay
away from huge monolithic programs this would give us all the logic flow of
event-driven logic.  

My limited experience is with the very under rated VARPG, which is entirely
event driven.   As I worked with VARPG programs on Windows it changed my
regular programming style and logic.  While still cycle driven, my 5250
programs now tend to focus on the events that might takle place rather than
on the cycle.
 
---------------------------------
Booth Martin
http://www.martinvt.com
---------------------------------
-------Original Message-------
 
From: Midrange Systems Technical Discussion
Date: 03/04/05 03:42:56
To: Midrange Systems Technical Discussion
Subject: Re: Hmmmm.....$1 Billion
 
On Thu, 3 Mar 2005, Steve Richter wrote:
 
> On Thu, 03 Mar 2005 20:25:28 -0600, Vernon Hamberg <vhamberg@xxxxxxxxxxx>
wrote:
>> We must be talking different things here - VB for the longest time did
not
>> have thread capability, yet was considered event-driven. So you must mean
>> something different.
>
> for event driven programming you need a message loop. Every windows
> program has, at its heart, a message loop.  The Windows OS feeds
> events like a keystroke, mouse move, a command to close the window to
> the windows message queue.
>
> on the 400 you dont have that default message loop.  If you want to
> use an event model for your interactive job you need threads to
> implement the whole thing.  The main thread would receive from the
> message ( data ) queue, processing the events.   Other threads would
> feed events like "the user has pressed the enter key", a socket
> receive has returned some data,  a physical file trigger has fired
> because a record has been added to a file.
 
You don't need threads to implement event driven programs.  Indeed,
multi-threaded events driven programs are a relatively recent development.
X11 didn't start using threads until R6 IIRC (R6 is the current major
release).  x5250 (an X11 5250 emulator I wrote) is event driven and does
not use threads.  I would guess that the majority of event driven programs
do not use threads.  All is needed is a multiplexing function such as
poll() or select().  There is no technical reason why an event driven
program couldn't be written on the AS/400.  Joe's idea of using data
queues would work.
 
> All of this is just a big example because display data managment and,
> I guess 5250,  does not handle change of direction very well. Once the
> display is waiting for the enter key to be pressed, the device is not
> available to have a new screen written to it.
>
> Whether this is all true, I am not sure.  I am just using the topic as
> an example of what could be done with threads and other improvements
> to the system.
 
The 5250 protocol doesn't lend itself particularly well to event driven
programming.  Having threads wouldn't make it any better.  Threads would
probably make some tasks nicer, but database driven apps probably aren't
among them.  It seems to me that any performance gain by using threads
would be lost in all the locking you would have to do to keep the data
coherent.  Threads work best when you have discreet tasks that can work
independantly.  The database itself might be able to make use of threads
though.
 
James Rich
 
It's not the software that's free; it's you.
   - billyskank on Groklaw