• Subject: Re: Sockets vs MQSeries
  • From: Chris Bipes <chris.bipes@xxxxxxxxxxxxxxx>
  • Date: Sat, 20 Jan 2001 12:04:07 -0800
  • Organization: CrossCheck, Inc

We use Data Queues for real time processing.  Our applications send to a local 
queue Named after the destination system.  We define a remote DQ on the 
destination box that reads the entries and posts them.  Some of our queues are 
keyed to prioritize the entries.  If the remote system is down, the entries 
just pile up.  A monitor job can pull the queue entries off and store them in a 
file if the queue starts to grow too large do to the remote system not pulling 
the data off.  This is very fast and little overhead for the applications.  We 
are switching to TCP/IP data queues whitish use sockets for the Comm part.  You 
must be running the host data queue server which is part of the OS and free.  
Very little programming time needed and no communication programming necessary. 
 It is all built into the OS for you.  Under 4.5 the data queue limit seems to 
be expanded greatly and now that DQs will automatically shrink back, well the 
DQ maintenance practically goes away.

Chris Bipes
Sr. P/A
CrossCheck, Inc.

----- Original Message ----- 
From: "Stephane Leon" <sleon@dplanet.ch>
To: <MIDRANGE-L@midrange.com>
Sent: Saturday, January 20, 2001 7:17 AM
Subject: Re: Sockets vs MQSeries


Thanks for that.
It s more clear to me now.
Mq Series use sockets.


--
Stephane


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

This thread ...

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].