The IPACT Queuer and Router Services (IQR) provides a
standard Application Programming Interface (API) for sending messages.
By using IQR, application programmers are relieved from trying to develop
messaging methods between applications on the same node or multiple nodes.
IQR provides delivery, recovery, and connectivity between
multiple nodes using a router installed over DECnet or TCP/IP. IQR
services are provided that allow for the addition of user supplied routers to
alternate networks. IPACT has a library of other routers written for
process control devices, SNA, and other networks.
A link library is provided that interfaces the Manufacturing
Automation Queuing and Routing Software (available from DECUS).
The need to deliver transactions and events reliably between
different computer systems have been identified for most process control
computer systems. DECnet does not guarantee the delivery of messages at
the application layer. The IQR router and IQR services provide this end
to end delivery guarantee. The use of these two mechanisms provides the
ability to deliver information from one computer system to another in
applications where such guarantees are required (e.g. the MES environment).
Messages are not deleted or lost until the receiving process acknowledges the
message. This can be thought of in a similar manner as a database
"commit".
The IQR software is designed to provide guaranteed message
delivery between two different locations. This is done by creating a
messaging hub which contains message queues. Each message
queue contains actual messages to be read. Also, the IQR software
provides a router which will move a message from one hub to
another (even across different nodes).
You are welcome to download the IQR documentation.
It is in a .PDF format.
The IPACT Queuer and Router Services currently supports the
AXP/Open VMS v6.1 and higher operating system.
A hub is an individual "container" that holds
all the information required for a group of message queues and their
respective messages.
Each hub is created by using the IQU utility. When
created, the hub occupies both system memory and a disk container file.
System memory is used to store general hub information, as well as non-journaled
message queues. The container file holds a backup of hub information and journaled
message queues.
All hubs can contain a pre-defined number of message
queues, either journaled or non-journaled. The hub is created
in protected memory, so as to not allow someone to accidentally
"damage" its information.
Within any hub are usually many message queues. A message
queue has a number of properties that all can be defined by the process
creating a message queue. Message queues are created by using the IQU
utility or by using the IQR System Service.
Messages are written to a message queue using utilities
(like QIT), system service routines, or from another hub via the router.
Messages are then read from a message queue using utilities (like DQIT),
system service routines, or sent to another hub via the router.
All message queues are remembered between system startups.
There is no need to create the queues after each startup as they will exist
when the hub is re-installed using the IQU utility (see Utility Chapter).
The characteristics of each message queue is also maintained over a system
startup for all message queues.
The following is a list of properties that can be defined
for any message queue:
| Properties |
Description |
| Name |
All message queues have a
name that consists of up to 16 characters. No two message queues in a
hub can have the same name. |
| Size |
Messages written to a
message queue can be of many varying sizes. Each message queue can
specify the size (in bytes) of the largest message that can be written
to it. |
| Location |
A message queue can be
either journaled or non-journaled. Journaled message queues are saved
in a disk file and are recoverable after abnormal events like a system
crash. Non-journaled message queues are stored in memory and offer a
speed advantage over journaled message queues, but are not recoverable
in the event of a system shutdown. |
| Volatility |
Message queues can be
created so that messages written to it are volatile. A volatile
message always has the possibility of being lost in the event that the
message queue has run out of room and requires more space to write a
new message. In this case, the oldest message is deleted from the
message queue. |
| Number of Messages |
A message queue can be
specified to hold only a certain number of messages at any one time,
regardless of the size of the actual message. An example would be a
volatile message queue that can hold only two messages at a time. Any
time a message is written to it that would exceed the two message
limit, the oldest message is deleted. |
| Acknowledgment |
All messages must be
acknowledged from a message queue after being read. Acknowledging a
message indicates to the queue that the receiver has properly received
the message, and the message queue is now clear to delete the message
from the queue. Acknowledgment is usually done by the user; however,
it can be set up to be done automatically after a message is first
read. |
| Number of Readers |
To read a message from a
message queue, you must first connect to it and declare yourself as a
reader. A message queue can only have one or two readers connected to
it at a time. The number of readers allowed is defined at the time the
message queue is created. If more readers try to connect than are
allowed, an error is returned. The first reader to connect is the
Primary Reader and the second reader to connect is the Secondary
Reader. |
| Stale Messages |
Message queues can be set
up to have stale messages. A message becomes stale when it exists on a
queue for longer than a preset amount of time. After a message becomes
stale, it is deleted from the queue (without a chance to be read). |
| Replication |
Some message queues can
be created to replicate any message written to it to other message
queues within its hub. This can aid in the ability to perform just one
write to a message queue that in turn will automatically write the
message to up to four other message queues. This process is called
replicating. Messages are never actually written to a replicating
message queue; therefore readers are not allowed to connect to this
kind of queue. |
Within each message queue are its contained messages. Each
message is stored in FIFO (first in, first out) order. All messages
will remain in the queue until one of the following conditions is met:
 | A reader acknowledges a message |
| A process requests to delete a message |
| A message becomes stale |
| A volatile message queue runs out of space. |
Messages are not stored in any particular format. It
is up to the writer/reader of the messages to interpret the actual message
being passed. It is important to remember that all messages that are
read must be acknowledged. If a read message is never acknowledged, the
reading process will not be able to read another message until it
acknowledges the current one. If, however, the process would
abnormally exit and never acknowledge the message, the read message is again
placed at the front of the queue. This will insure that a process will
properly read each message.
The IQR Router is responsible for routing messages from
message queues in a particular hub to other hubs or remote nodes.
Currently, only the DECnettransport is supported. DECnet and TCP/IP
Transporter are fully supported. The remote nodes may be any DECnet
compatible node that supports the IQR Router protocol (to include routers of
the MAQ/MQD and IMS type).
The interface to the IQR software is through an Application
Programming Interface (API). This API is written as an user
written system service and is installed with protected privileges. The
system service allows the ability of the IQR software to protect the files,
shared regions, and access methods from errant user programs. All of the
data structures are protected in either executive or kernel mode. The
following is a list of the common services provided. The IQR
System Service Library Descriptions chapter gives a more complete
description of the system service calls including those typically only used by
the IQR router and the IQR utilities.
| IQR_ACK_READ - Acknowledge a message read from a
message queue |
| IQR_ATTACH_H - Attach to a hub |
| IQR_BACKUP_RNA - Negative acknowledgment of a
message from a message queue |
| IQR_CONNECT_READ - Connect to a message queue with
intent to read |
| IQR_CONNECT_WRITE - Connect to a message queue
with intent to write |
| IQR_READ_Q - Read a message from a message queue |
| IQR_READ_QW - Read or wait for a message from a
message queue |
| IQR_WRITE_Q - Write a message to a message queue |
When a VMS process writes a message to a message queue, the
IQR services determine if and where the message can be queued. This
determination depends on how the message queue was defined. If
successful, the message will be placed in region or hub container file
depending if the message queue is journaled or not. The reader process
reads the message, processes the message, and then acknowledges the message
from the message queue. Until the message is acknowledged the message is
not deleted.
For more information regarding this or other IPACT products,
please see our Information Request Form.
BACK TO TOP
|
