Data queues are an integral part of the operating system of the IBM i. This article shows you how data queues can extend the functionality of system objects you use every day.

In my previous two articles on data queues, I focused more on the technical details of using the data queue APIs in your programs. This article is a little different: it centers on the ways that data queues are used by the IBM i itself. Seeing how IBM uses data queues may give you some ideas as to how they could be applied in your own applications. The three areas I'm going to cover today include display files, output queues, and the alert function.

Data Queues and Display Files

One of the first uses I found for data queues was to add a needed feature to 5250 processing. You can specify a data queue via the DTAQ keyword on the CRTDSPF, CHGDSPF, and OVRDSPF commands. This data queue can be used for a variety of purposes, but the one I think of first is to provide a way to break into display file wait times. It's used most often with self-refreshing screens, where if the user doesn't hit a key, the screen refreshes itself at regular intervals. The way it works is that you create a data queue and then you associate your display file with that data queue (via one of the commands mentioned above). Once that's done, whenever the user hits a data entry key, a message is placed on the data queue. You leverage that by writing your program to wait on the data queue rather than the display file.

Note that if you're used to using EXFMT (like most of us are) you will have to separate that into separate READ and WRITE opcodes. Then, you WRITE to the display file and read the data queue with your desired timeout. If the READ times out without returning a value, you can then refresh the data on the screen and perform another WRITE. If instead you get the specially formatted message that indicates that the user pressed a command entry key (the first 10 characters are "*DSPF") ,then you READ the display file to retrieve the user data.

This is a little bit complex for a simple timeout (which can be accomplished using the WAITRCD parameter on any of those same display file commands), but it allows for a special case: any job can send a message to the queue to interrupt a long read. You can use this for all kinds of things, from logging out stale sessions to getting users out of display files for recompiles. Data queues and display files are a great combination.

Output Queues and Data Queues

I learned about this capability when I was building my CPYSPLFPDF command. I wrote CPYSPLFPDF to convert spooled files into PDFs, way back in the day before our wonderful machine did it for us. Once I created the tool, I realized that it would be really nice to be able to do these conversions automatically. The way I approached the problem was to allow you to set up a set of attributes (a "template") and run that template whenever a new spooled file was created. When I first wrote the program, I was going to have a never-ending program set in a loop in batch and check the target output queue for new spooled files. But then I discovered the DTAQ keyword on the CRTOUTQ and CHGOUTQ commands. Like the similarly named keyword on the display file commands, the DTAQ keyword on the output queue commands associates an output queue with a data queue, and when a new spooled file becomes available on the output queue, a message is written to the data queue. So now, rather than having to poll the output queues repeatedly, I instead just wait on the data queue. If there are no spooled files, the monitor sits quietly and consumes no resources. If a spooled file does become available, all the information I need is in the data queue message and I can process the spooled file. It works wonderfully and is a perfect example of using a data queue as a notification mechanism.

Data Queues and Alerts

Continuing on with the theme of notification, my last example is a less familiar use of data queues in combination with alerts. While the implementation of alerts can be complex, the concept is simple enough: you are able to define which messages in your system are "high priority" messages that require immediate intervention. You do this by creating alert tables and filters and enabling message queues such as QSYSOPR to generate alerts, but the result is that alerts provide a way for you to identify exactly those conditions that you need brought to your attention. You can define a central alert processing machine (also called the focal point) that can coordinate reporting of all the alerts in your network. You can even cause the system to generate Simple Network Management Protocol (SNMP) messages, or traps, that can be recognized by industry-standard network-monitoring tools.

The magic of data queues in this environment is that you can also send alerts that match specific criteria to a data queue. So in the circumstance where you know a certain error message occurs in response to serious system or application faults, you can set up an alert filter for that message and an alert action that sends a message to a data queue. Then you have a program that monitors that data queue, and when a message appears, it signals an external alert by doing something like sending a text message. Setting up the alerts is probably easier than writing a program to monitor message queues or check job logs, and it would allow a smaller shop to create a lightweight messaging infrastructure as opposed to setting up distributed message management or a full-blown SNMP sniffer.

Data Queues Aren't Just for Data

When I say that, I mean that data queues don't need to be used just to send data from one part of a multi-tiered application to another. Used in conjunction with the IBM i operating system, data queues provide a good way for you to monitor and interact with your system in ways you might not have considered.