RE: allow multiple threads in interactive job

>My understanding is that threads were originally developed 
>on other systems to work around those systems limitations 
>of process switching and sharing between processes.  The 
>AS/400 never had such limitations so multi-threading wasn't 
>a requirement originally. 

Threads are invaluable in interactive programs as a way to increase
perceived performance or allow blocking operations while not locking out
the user. 

Take a simple subfile example: Imagine a program where you displayed the
first page of a subfile on the screen, and while the user was deciding
what to do you loaded the second page on a background thread. Depending
on the IO needed to load a page in a subfile, that could be a marked
improvement in performance. 

Or take an example of waiting for an object, for example a lock on a
data area that serialized access to a program. W/o a thread you show a
page to the user saying "Please wait" and then you try the ALCOBJ.
Assuming default wait times, that screen is hung up for 30 seconds. Now,
with a thread you could run the screen on the primary thread and do the
ALCOBJ on the background thread. This way the screen could be responsive
to the user and allow the user to hit F3 to say, never mind, I'll try
later.

-Walden

------------
Walden H Leverich III
President & CEO
Tech Software
(516) 627-3800 x11
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)