PMS Information Systems
Welcome to PMS Information Systems - IBM i (AS/400) Forum !!!

Get Answers for all your queries on IBM i (AS/400).

Join the forum, it's quick and easy

PMS Information Systems
Welcome to PMS Information Systems - IBM i (AS/400) Forum !!!

Get Answers for all your queries on IBM i (AS/400).
PMS Information Systems
Would you like to react to this message? Create an account in a few clicks or log in to continue.

DATA QUEUE MYTHS

Go down

DATA QUEUE MYTHS Empty DATA QUEUE MYTHS

Post  maran Fri Dec 30, 2011 1:29 pm

What Are Data Queues?

Data queues are a type of system object (type *DTAQ) that you can create and maintain using OS/400 commands and APIs. They provide a means of fast asynchronous communication between two jobs, or within the same job, because they use less system resources than database files, message queues, or data areas. You can attach a sender ID to each message being placed on a data queue. The sender ID, an attribute of the data queue that is established when the queue is created, contains the qualified job name and current user profile. Also built into data queues is the ability to set the length of time a job will wait for an entry before continuing its processing. A negative wait parameter will tell the job to wait indefinitely for an entry before processing. A wait parameter of 0 to 99999 will tell the job to wait that number of seconds before processing. When reading messages from a data queue, you have the option to peek at the entry, meaning that your application receives the message but leaves it on the queue; or, you can destroy the entry, meaning that your application receives the entry and removes it from the queue. And, as of V5R1, you can now journal data queue entries.


SEND AND RECEIVE THE ENTRIES


High-level language programs can send data to a data queue using the QSNDDTAQ (send to a data queue) API and receive data using the QRCVDTAQ (receive from a data queue) API, as well as others. Data queues can be read in a first in, first out (FIFO) sequence, or in a last in, first out (LIFO) sequence, or in keyed sequence. Keyed data queues allow the programmer to specify a specific order in which to receive messages on the data queue or to retrieve only data queue messages that meet a criterion. That is, the programmer can receive a data queue message that is equal to (EQ), greater than (GT), greater than or equal to (GE), less than (LT), or less than or equal to (LE) a search key.

Why Use Them?

For one, they are great for passing data between programs. I realize that you can pass data between programs using call parameters, but if you're interested in decoupling--that is, decreasing the dependency that programs have on each other--data queues allow you to accomplish that. Also, if you want to pass data between programs on different machines, even if one of those programs resides on a machine other than the iSeries, the data queue is a great option. Another twist on the passing-data objective is the client/server application. In the client/server scenario, you have many programs (or clients) writing different types of data to the same data queue. These clients can reside locally or remotely and can be written in many different languages. The server receives the various data queue messages and processes them accordingly, which may mean calling other programs or triggering other events.

Another place where data queues come in handy is in subfile applications. I know, it sounds a little odd, but using data queues with subfiles allows you to create very flexible applications with relative ease.


Commands and APIs


There are three commands and five APIs that you can use with data queues. I am going to list all of them but focus only on the few that you will use most of the time. Also, if you use TAA tools, there are a couple of helpful commands included that I like to use. The following is a list of the commands and APIs:

CRTDTAQ—The create data queue command is used to create data queues.

DLTDTAQ—The delete data queue is used to delete data queues. Following so far?

WRKDTAQ—The work with data queues allows you to list one to many queues. From this screen, you can delete data queues, change the descriptions of data queues, and add new data queues.

CLRDTAQ—This is not a standard OS/400 command. It is part of the TAA tools and is used to clear a data queue's messages.

DSPDTAQ—This is also part of the TAA tools and not a standard OS/400 command. It is used to display the contents of a data queue.

DSPDTAQD—Are you starting to see that the best data queue commands are not standard OS/400 commands? This command is also part of the TAA tools and allows you the view the details of a data queue, including how many entries currently exist.

QCLRDTAQ—This API allows you to clear a data queue's messages. If you don't have TAA tools, you could create your own CLRDTAQ command using this API.

QRCVDTAQ—This API allows you to receive data queue entries.

QMHQRDQD—This API allows you to retrieve data queue information. You could use this API to create your own DSPDTAQD command if you don't have TAA tools.

QMHRDQM—This API allows you to receive an entry from the data queue without removing that message from the data queue. Use this API to create your own DSPDTAQ command.

QSNDDTAQ—This API allows you to write messages to a data queue.

Now I will further discuss the CRTDTAQ command and the QSNDDTAQ and QRCVDTAQ APIs. The CRTDTAQ command is not complicated, but there are a few options from which you can choose, so I would like to discuss those with you. Check out the figure below. After typing in the data queue name and library, the next entry is data queue type.

You have two choices: *STD or *DDM. A standard (*STD) data queue is one that is created on the local machine.

A DDM data queue is the same as a DDM file. It is a logical view of a data queue on another machine.

A *STD data queue is created on one iSeries machine and you create a DDM data queue on another.

A DDM data queue points to the *STD data queue on the other machine. After the type parameter comes the maximum entry length. It is here that you define the maximum length of your data queue message.

The maximum length you can use is 64512 bytes, or 64K.

The next parameter I want to talk about is the sequence parameter. You have three choices: *FIFO, *LIFO, or *KEYED. If you select *KEYED, you are then prompted for the key length. Just as with a database file, the key length is the length of the data you are going to use as the key to the data queue. Next, you determine whether or not you want to include the sender ID, which is the job name and user's profile, with each message written to the queue.

The next parameter is broken up into two parts and is used to determine the maximum size of the data queue and the initial number of entries. The maximum size can go to 2 gig. The initial number of entries tells OS/400 how much space to reserve when the queue is created. You can extend the queue up to the maximum size, but, depending on your application, you may want to reserve a specific amount of space to start off. The default is 16. A new parameter and feature of data queues introduced in V5R1 is the automatic reclaim feature. This allows OS/400 to reclaim unused space in a data queue when that queue is empty. The need for this feature comes from the fact that the data queue size extends as you add messages beyond what you set in the initial number of entries parameter. Answering *YES to this parameter causes OS/400 to automatically reclaim the storage whenever the data queue is empty. The size of the data queue will then go back to the initial size at creation, which is determined by the maximum message size and number of initial entries parameters. One note of caution if you use this feature is that the data queue is locked while this reclaim takes place.
maran
maran
Admin

Posts : 442
Join date : 2009-07-24

https://pmsinformationsystem.forumotion.net

Back to top Go down

Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum