× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




 
We have been using data queues as you describe and find them very
efficient and flexible.

A few suggestions...

        Create one data queue. Years ago I was told by an IBM'er that
the data queue processing is optimized when only one is accessed within
a program. This may not be case anymore but I still recommend it.

        Create a keyed data queue. Even if the same key value is posted
to every entry, doing so allows for expansion and flexibility. For
example, a key value may control application flow and/or processing
priority.

        Two problems occur when using data queues. They get full and
they get damaged.

1. Obviously, damaged means that your application fails to send or
receive data. Deleting and recreating the data queue is the recovery. In
RPG, using call(e) or the dreaded indicator when QRCVDTAQ is run can
make your application recover on it's own.

2. Getting full is a bit tougher to deal with. Especially since you
likely want to process the data and don't wish to lose it. This
condition occurs during the QSNDDTAQ process. A automated recover may
simply be a matter of launching additional QRCVDTAQ jobs to keep up with
the traffic.

        Use the Data Queue timeout value. Using the QRCVDTAQ time out of
10 seconds allows you application sense hit count and controlled
shutdown requests. Simply code a loop with an imbedded QRCVDTAQ and test
for length of data to process. Also code the shutdown request signal
within this loop and you can be assured to terminate your application
gracefully.

        If you have the need for some java or RPG code to process the
data queue. I may be able to come up with some.

HTH,

Ken Slaugh 

----- Original Message ----
From: David Gibbs <david@xxxxxxxxxxxx>
To: java400-l@xxxxxxxxxxxx
Sent: Wednesday, October 4, 2006 10:18:59 AM
Subject: Data queue performance question

*** Cross-posted to java400-l and midrange-l.

Folks:

I'm writing a application that is going to be using data queues to
communicate bulk data.

The application has two parts ... a java server and a number of host
(RPG, but it really doesn't mater) programs.

My thought is to use a single keyed data queue to transfer data back and
forth between both applications.

In some cases the host programs will write to the data queue and hand
the java server the data queue key.

In other cases, the java server will write data to the data queue and
hand the host program the data queue key.

Is there anything inherently inefficient using a data queue in this
manner?  Would it be better to use multiple data queue's (one for host
to java another for java to host)?

Thanks!

david
--
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/java400-l.







--
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/java400-l.


________________________________________________________________________
_____
Scanned by IBM Email Security Management Services powered by
MessageLabs. For more information please contact
mailto:smtpalerts@xxxxxxxxxx
________________________________________________________________________
_____


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.