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 ;-)

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].