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

Yeah, this is kind of fun. I once wrote a VBX in Visual C++, as I recall. This was basically a big loop that tested messages that came from Windows, as you describe. But that sounds a lot like a job on the 400 waiting on a MSGQ or DTAQ. Not exactly the same, but similar. Of course that was 10 years ago and I have senile moments these days.

As a VB developer, this matter of the Windows message processing was not at the forefront. And for developing user apps, there was no such idea as threads that I had to think about. Yes, they've been added in later versions - I was working in VB3 at the time.

The matter of threads on iSeries is not necessarily a bug - you know,"It's not a bug, it's a feature". It's a matter of thread safety - shared memory vs. process-specific. One can get thread-like behavior using batch jobs that send status info to some common location. So-called threads on iSeries - I'm out on a small limb here but have seen some of this at the SLIC level - are a subclass of what are called tasks - everything is handled by a task dispatcher. There is more to initialize for a new job than for a new thread but it is still similar. On the iSeries, e.g., WRKSYSSTS actually is reporting processes, not jobs, when counting active "jobs".

Again, threads were not supported in VB for the longest time, yet VB was called event-driven. Now there are event handlers in VB, which are called by some Windows message processor that comprises the VB runtime, I guess. But there is a similarity, in my mind, to subroutines or procedures in RPG that are called from a loop that tests function key presses and other states or "events".

But I ramble. Time for sleep.

Vern

At 11:11 PM 3/3/2005, you wrote:

On Thu, 3 Mar 2005 23:14:17 -0600, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote: > > From: Steve Richter > > > > for event driven programming you need a message loop. > > You can implement this using a data queue. Here's an example: > > http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/index.htm?i > nfo/apis/apiexusque.htm > > No threads needed.
I dont mind arguing the topic of how best to do event driven
programming, it's a pretty interesting subject. but it is just an
example.
threads are one of the fundamental building blocks of software
applications.  as I understand it, the reason interactive jobs dont
allow threads is because the underlying OS400 code is too buggy to be
made threadsafe.   IBM has to fix that.
-Steve
--
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,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.