RE: multi-threading

Well the communication jobs were tied to physical interfaces and 5250
terminals once a pone a time. We did not want every job to be calling
the 7 programs and opening all the necessary files which is why we used
the queues. (When it was just a S36 5250 terminal job with 10 operators
it was fine.) but when we got to IVR, POS terminals, Web interfaces,
XML interfaces, remote IP modems, etc we had to change. Since we can
have many interfaces dumping into a single queue, we need to process
multiple transaction at a time. Since the processing servers are
running the transactions sub-second, we only need 3 to 5 to handle the
hundreds of communication paths to the queues.

If I used a multi-threading job, how would this help or be more
efficient than what I have?

Chris Bipes
Director of Information Services
CrossCheck, Inc.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Neill Harper
Sent: Friday, September 04, 2009 1:35 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: multi-threading

Any example where you have used multiple jobs to accomplish your needs
may
also a valid case for using threads.

The advantage of the threads is it allows a lighter footprint than
creating
a new job, it also allows you to access job specific resources such as
qtemp.

Disadvantage is badly programmed threads can cause mayhem ;-)