Home ▪ Products ▪ IQR    

   

IPACT Queue and Routing Software (IQR)

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

 

Documentation

You are welcome to download the IQR documentation.  It is in a .PDF format.

 

Supported Systems

The IPACT Queuer and Router Services currently supports the Alpha and Itanium platforms running Open VMS v6.1 and higher operating system.  Currently validated to OpenVMS 8.2.

 

IQR Components

Hub

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.

Message Queue

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.

IQR Router

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

 

IQR System Service

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_QN - Read a message or request notification if none.
  • IQR_READ_QW - Read or wait for a message from a message queue
  • IQR_WRITE_Q - Write a message to a message queue
  • IQR_TIME - Return current system time modified by Hub delta time
  • IQR_SET_DTIME - Set Hub delta time

 

Message Flow

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.

Licensing

Public domain with credit given to IPACT, Inc. similar to GNU General Public License.  Complete source code backup savesets along with developer's manuals are available upon request and typically available on IPACT's FTP site.

 

    
     Home ▪ Products ▪ IQR    
 

Integrated Process Automation & Control Technologies