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.
Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at
MC Press books written by Joe Pluta available now on the MC Press Bookstore.
 |
||
 |
|
Developing Web 2.0 Applications with EGL for IBM i Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform. List Price $39.95 Now On Sale
|
|
||
 |
|
WDSC: Step by Step Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction. List Price $74.95
Now On Sale
|
|
||
 |
|
Eclipse: Step by Step Quickly get up to speed and productivity using Eclipse. List Price $59.00
Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online