How does RVDQ ESB Work

When Substation ES is using RVDQ, each interface can start two threads. One thread acts as a Scheduler with its own separate event queue and queue dispatcher. The other thread is a Worker. The worker thread uses the Substation ES callback routine to process incoming messages for Recipe subjects. Each Substation ES RVDQ interface sets up listeners for the subjects with at least one Active Scheduler Thread. If the workloads are high it’s best to have the scheduler be defined to it’s own Substation instance.

Though you may define a Scheduler Thread in several RV ESB interfaces, only one (1) Scheduler thread is active. The others are dormant in backup mode until the active scheduler ends or becomes invalid.

The Scheduler thread is the one that listens to RV topics. As messages are delivered from RV daemons, the active scheduler distributes them to worker threads in the RVDQ group based on RVDQ-IDENTITY value using a unique “inbox” topic. The actual RVDQ group identity is

Transport-ID + “-” + RVDQ-IDENTITY + "-DistQ"

For example: RV-SERVER-RVDQ-DistQ

where RV-SERVER represents Transport-ID, RVDQ represents RVDQ-IDENTITY and DistQ represents -DistQ.

So the flow of messages in RVDQ is:

  1. The Scheduler in its message callback gets a RV message from the RV Daemon.
  2. The Schedule re-packages the message into a DQ message.
  3. The Schedule sends the DQ message to a worker thread(s).
  4. The Worker thread gets the DQ message and re-creates the original message.
  5. The Worker thread uses the Substation ES callback to hand the message to a Substation ES. From there is goes to the Back-end system for processing.
Note: The Scheduler is only one (1) thread for the RVDQ-Identity value and so - can only use one cpu (it might bounce around from cpu to cpu - but only uses 1 cpu at a time) - so when a scheduler consumes 100% of a cpu - it is maxed out similar to CICS QR processing).

The RVDQ-WORKERS parameter is the number of DQ messages that can be put on the worker "INBOX". They stay on the "INBOX" until the worker callback calls the user callback and the user callback returns which in Substation ES case is the time to get a UOW and dispatch the UOW to other Substation ES internal queues.

If RVDQ-WORKERS is set to zero, then RVDQ will not send messages to this interface. It can be used as a Scheduler, but not as a Worker.

By setting RVDQ-SCHEDULER to high (value of 5) and RVDQ-WORKERS to zero (0), the RV ESB interface will only be used for Scheduling. This set of options allow you to have a Substation ES that is only a Scheduler controlling its priority and location (LPAR).

By setting RVDQ-SCHEDULER to low (value of 0) and RVDQ-WORKERS to a non-zero, the RV ESB interface will be used as a Worker. (note RVDQ will commandeer any Worker thread as a Scheduler if required. There must always be one valid Scheduler for a RVDQ identity).

To increase concurrent processing RVDQ messages you need to increase the number of RV ESB iInterfaces. Each RVDQ interface will create a worker thread to handle messages from the Scheduler thread. The RVDQ interface can be in the same or different Substation ES address spaces on the same or different LPARs.