02
Sat, Nov
2 New Articles

Practical RPG: Using Data Queues, Part Two

RPG
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Data queues may be small, but this article shows you how keyed data queues allow you to send big things in little packages.

 

The previous article on the practical application of data queues showed how you can use a single keyed data queue to allow an arbitrary number of clients to access an arbitrary number of servers. The only constraint was that the message size was limited to the maximum size of a single data queue entry, which is just shy of 64K. That's a pretty significant constraint, but in this article I'll show you how adding just one more data queue completely removes that constraint.

 

One Queue to Bind Them All

The primary object of any arbitrary-length messaging system is to make sure that the entire message is processed at the same time. As it turns out, it's relatively easy to do that; it just takes a little careful planning and a little timing. Let's start by reviewing my diagram of the single-queue solution:

 

080614PlutaImage1

Figure 1: A single keyed data queue can connect as many clients and servers as you need.

 

The idea is that we put a request on the queue that is then read by the appropriate server. The request looks like this:

 

Key Value

Server ID

Client Job Number

Request ID

Data

Application-specific Request

 

The server ID says who will process the request, the client job number is who made the request, and the request ID is an optional identifier in case you have multiple requests (more on that in a moment). The client adds the request to the data queue with the Server ID as the key, and the appropriate server pops the request off. It then responds with a request that looks exactly the same, except the data portion is replaced with the response:

 

Key Value

Server ID

Client Job Number

Request ID

Data

Application-specific Response

 

This message is placed on the queue with the Client Job Number as the key. The client is waiting for an entry with that key, and no two clients have the same key. Simple, clean and elegant. As noted, though, the problem is that the message is limited to only 64K. That's enough for simple requests but not nearly enough for many types of services, especially those that return lists of information. So how do we get around that? Well, it's simple: we add another queue for the data!

Keeping Your Bits Together

So the issue is how to handle a request that returns more data than a data queue entry can handle. To do that, I need to revise our diagram a little bit. I'll simplify it down to a single client and server, but I'll add in the request and response. We end up with this:

 

080614PlutaImage2

Figure 2: Drilling down into a single communication request shows a simple structure.

 

The concept is a model of simplicity; the queue has a simple six-character key. The request is placed on the queue with the server ID, and the response is placed on the queue with the client ID (the client job number). No client/server transactions will ever collide. But the request is constrained to that 64K limit; how do we get from that to more than a single piece of data? Enter the second queue!

 

080614PlutaImage3

Figure 3: We then add a second queue to handle the variable-length data.

 

This is the final architecture for an unlimited-length messaging system. The header queue contains one entry each for the request and the response in a transaction. The detail queue can have as many entries per transaction as necessary, which provides an arbitrarily long limit for both request and response. But why a second queue? Why not just send everything on one queue? That's because whoever is reading the queue has no way of knowing whether the transaction data is complete. The sender may have been delayed for processing or some other reason, and the receiver may have gotten ahead of the sender. No data on the queue doesn't mean there is no more data coming, just that it's not there yet; it's very dangerous to use a lack of data as a positive end of message. You could theoretically have an "end of message" transaction, but I prefer not having to look at the data in order to determine the completeness of the message. So basically you want to send all the detail and then the header.

 

And here's where the timing piece comes in. There are 10 distinct steps in the conversation:

  1. The client writes all the request data to the detail queue using the data key (which we'll define shortly).
  2. The client writes the request header to the header queue using the server ID.
  3. The server reads the request header, which includes the data key.
  4. The server reads all the request detail data using the data key.
  5. The server processes the request.
  6. The server writes all the response detail back to the queue using the data key.
  7. The server writes the response header to the header queue using the client job number.
  8. The client reads the response header from the header queue (using the client job number).
  9. The client reads the response detail using the data key.
  10. The client processes the response.

 

It's really important to see how the data is front-loaded. You send all the detail first, and then you send the header. The very act of sending the header indicates to the receiver that the transaction is completely enqueued. It can then read the data until no more data exists; that's the end of the data! There are other techniques, but they all rely on something programmatic: a count in the header, or a special EOF message. A simple programming mistake can easily send those awry. But in this case, the physical act of sending the header after sending the detail ensures the integrity of the message.

 

I used the term "data key" several times in the list. This data key is what allows this architecture to support multiple clients and multiple servers all running through the same two queues. It prevents interleaving of data on the otherwise FIFO data queue.

 

The data key is a unique key that defines the message, and it consists of all the key values of the message as defined at the beginning of the article. I used a minimal combination of server ID, client job number, and request ID. In a completely barebones architecture, you could get away with just server ID and client job number, but throwing in the request ID makes it theoretically possible to make several simultaneous requests from the same client to the same server and keep the requests separate. This is important in parallel processing environments, especially if you have multiple instances of the same server. Note: This architecture could also allow you to execute processes on another machine. The server could easily be something that reaches out to a web service or an MQ series queue.

 

But that's another discussion for another day! For now, just review this architecture and see how it can be used in your environment to allow you to interface your RPG programs with as many servers as you need.


 

Joe Pluta

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 This email address is being protected from spambots. You need JavaScript enabled to view it..


MC Press books written by Joe Pluta available now on the MC Press Bookstore.

Developing Web 2.0 Applications with EGL for IBM i 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 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 Eclipse: Step by Step
Quickly get up to speed and productivity using Eclipse.
List Price $59.00

Now On Sale

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More 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.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY 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.

  • SB HelpSystems ROBOT GenericForms 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.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA 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:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA 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.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra 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: