I believe it was around v4r4. It was before the advent of AUTORCL which corrected things somewhat allowing the queue to return to original size without having to delete and recreate the queue manually. But even after AUTORCL was added, things still slowed significantly when the queue got too deep. Good to hear it is no longer an issue.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
-----CRPence <crpbottle@xxxxxxxxx> wrote: -----
To: rpg400-l@xxxxxxxxxxxx
From: CRPence <crpbottle@xxxxxxxxx>
Date: 12/14/2015 03:18PM
Subject: Re: Need ideas to reduce open/close in RPG program
On 14-Dec-2015 13:02 -0600, Mark Murphy/STAR BASE Consulting Inc. wrote:
<<SNIP>> Years ago I made a broker using a data queues to send data
to multiple systems. It was extremely fast, but if the data queue got
more than say 100 messages deep, it was 10 times slower. I think you
can regulate that by setting the initial size of the data queue, but
I never did any testing to verify my hypothesis.
If "years" goes back to pre-v3r1 or perhaps early v3r1, then since
then, the horribly slowed queue issue was addressed and rectified. The
/old/ implementation was *horrible*, whereby all of the enqueued data
was getting _moved_ elsewhere whenever a new message was added and\or a
message was removed\dequeued [I do not recall the specifics], then all
of that moved data was getting _moved back_ /onto/ the queue.
I knew about the issue and the resolution, because the DBXREF is
implemented using the same underlying LIC methods as user queues. The
negative impact was so noticeable, that either the LIC queue feature
needed to /correct/ the design to allow the [since changed from a
single-queue to a dual-queue feature] to operate with sufficient
throughput, or the DBXREF would have had to implement an alternative
queue [and that probably would have been using a list of spaces,
implemented entirely above the LIC except for ensuring atomicity].
midrange.com
