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



Our only web "programs" are done in PHP. The PHP is used to provide the
front end, and the data is then sent back to the RPG programs that actually
do work thorough data queues. So, yes, though I am not sure what you may
have been implying.

Doing this, each page is a PHP thread. So since all of the activity is
transactional, there is always a request and a response. The two jobs
communicate using a fixed Data Structure with many fields. The submitted
RPG worker job that handles the txns must have a unique return address for
the response to the particular thread the made the request.

To do this, the RPG processing job always has ONE, known, "incoming" data
queue. Inside of the Data Structure of the record it receives is a "return
address" - which is actually a data queue name that is unique to that
instance of the PHP thread. So when the RPG is done, it return the response
through the provided DQ name it received.

Creating and deleting queues in a high volume, high speed environment is not
ideal.

So that we are not constantly churning to create and delete them, we use an
RPG-based "Queue Broker" (QB). This job, at startup, creates X
(configurable) number of queues with sequential number names (CCQ#######),
and keeps a list of them. The QB has one "known" queue for requests, and
another known queue for responses. When the PHP wants a unique queue name,
it sends the blank Data Structure to the Queue Broker (QB) request queue,
which populates the field in the DS with the first queue name that was not
already checked out. The QB then flags it as checked out in the list, puts
it on the "response" queue, and waits for another request.

The PHP then uses that DS by adding the rest of the fields and sending it to
the RPG dedicated "incoming" queue. The RPG uses the embedded name for the
response.

When the PHP is done with the queue, having received its response, it sends
the "completed" DS to the QB, which recognizes that it is fully populated,
therefore finished. It CLEARs the queue (QCLRDTAQ) and flags it as checked
IN, ready for re-use. This way, the creation and deletion of the queues is
eliminated and things work faster!

We also have a configuration setting for how many MORE queues to build when
the supply gets low, as well as a calculation that adjusts the startup count
up or down (for next time) so it starts with a more appropriate amount.

100% of our inter-program communication is done with Data Queues, between
any RPGs, Java-RPG, or PHP-RPG code.

Ira Chandler
Curbstone Corporation
Technical Services - 888-844-8533
https://curbstone.com/email_disclaimer

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Booth
Martin
Sent: Sunday, December 25, 2016 2:12 PM
To: Midrange Systems Technical Discussion
Subject: Re: Are data queues reliable?

Question: do you send to or receive from web pages using data queues?


On 12/25/2016 12:12 PM, Ira Chandler wrote:
I have used data queues as an integral part of my server designs since
1991. All of the submitted jobs (20 or more) in our payment server are
using them to send transactions around to be processed using a centralized
"routing table". Each program has a dedicated "incoming" queue, and uses
the routing table to know where to send the transaction next based on its
origin, status, and transaction type.
...


As an Amazon Associate we earn from qualifying purchases.

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