29
Fri, Nov
0 New Articles

Opening Up Your Options

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

Kevin Vandever’s article, “The First Degree of Separation,” on the mechanics of messaging details the various ways to provide a connection between two programs, typically a client and a server. You can think of it as the physical connection between the client and the server. In reality, the techniques provide the lowest three layers of the Open Systems Interconnection (OSI) model. Figure 1 shows an overview of the OSI model, and much more in-depth information can be found at either whatis.com/osifig.htm or www.lexcon.com/osimodel.htm. Business application messaging deals specifically with the messages required to provide support for a typical business application. In so doing, it covers the upper four layers of the OSI model from the transport layer up to the application layer. This article presents a specific architecture you can use to implement real business applications.

I detail the simplest form of distributed programming, often called the server/client model, which is fundamentally different from the client/server model, as I show you later in the article. The server/client technique directly corresponds to the monolithic programming model of the AS/400 block mode interface where the application program displays a screen and waits for user input. Server/client extends this model to the graphical environment, providing a user-friendly interface with only minor changes to your application programs. This is the first stage of application revitalization.

Server/Client Model

What is the server/client model? It is called server/client rather than client/server because the user actually sees the server, not the client. I know this can be a little confusing at first, but the distinction is crucial. In a client/server application, the client runs on the workstation and makes requests to a server program on the host. Each request is usually a single, specific transaction (such as adding an item master record). This requires a completely different architecture for the host programs than you may be used to when you write typical AS/400 applications. There is no screen to interact with, no way to let the user select values, no help text, and no subfiles. While the word paradigm is often overused, the difference between traditional programming and client/server programming is indeed a paradigm shift. On the other hand, with server/client programming, the client is the original application program, which is typically running in batch on the host. That program makes a


request to the workstation, which then displays the appropriate panel and waits for user input. In effect, the workstation becomes a user interface server and acts as a display file. All the conventional techniques of writing records to a screen or a subfile, even an error message subfile, can be emulated.

The application program stays essentially unchanged, and a version of the user interface client can also be running on the host as a green-screen program. This allows both green-screens and graphical workstations to share the same program logic, which is another key to the revitalization process.

Three Screen Types

To convert the old green-screen program to a graphical environment, we need to identify the three basic screen types. On the AS/400, nearly all programs use one or more of the following types:

• Full-screen panel. A full-screen panel displays a set of information on the screen within a single window. The user interacts with the screen through the Enter key, function keys, and entry fields. The typical interaction between an RPG program and a full-screen panel is through the WRITE and EXFMT op codes and less often through the READ op code. Full- screen panels correspond directly to the data panel of the previous section.

• Subfile. The subfile is a list of records. A single line is defined and then repeated on the screen. The list may be too large to display on the screen at once, so you can use the roll keys or function keys to navigate through the list. Interaction with a subfile is more complex and, in the case of the AS/400, requires two separate objects: the subfile record and the subfile control record. There are clear and initialization options requiring a WRITE op code to the subfile control record. Data operations you can perform to the subfile include WRITE, READ, READC, CHAIN, and UPDAT.

• Message subfile. The message subfile is a highly specialized version of the subfile. This is usually a single line on the screen reserved for error messages. Multiple errors can be sent to this subfile, and the user can scroll through them and eliminate more than one error at a time. This reduces the number of times the screen needs to be edited.

• Pop-up window. A pop-up window is simply a smaller version of either the full-screen panel or the subfile. It “pops up” over the existing information, leaving part of the screen uncovered. It is usually used for contextual information such as help text or select lists.

The Basic Messages

To support the basic screen types in the graphical environment, you need only a few output messages:

• Add a list entry. This message adds entries to a list before the list displays.

• Update a list entry. This message updates the last entry read.

• Add an error. This message allows the user interface client to handle errors, which are simply specialized list entries, with a special display type.

• Display a full-screen panel. This message shows a panel and waits for user input. To preserve the “feel” of the AS/400 interface, the client should destroy any other panels currently displayed.


• Display a pop-up. This message shows a pop-up, but unlike the full-screen panel, currently displayed windows will not be destroyed. The user interface should disable these windows, however.

• Display with overlay. Anytime two or more panels appear simultaneously, the user interface must treat them as a unit. For example, when showing a subfile, I often use a WRITE to a record format that displays the available command keys on the bottom of the screen, followed by an EXFMT to the subfile control record. These two record formats (three, actually, counting the subfile record) would be treated as a single panel in the user interface.

There are also a few input messages you can use:

• Read a list entry. This message allows access to a specific list entry.

• Read the next changed list entry. This operation borders on being platform-specific, but because it is so prevalent in the AS/400 world, it is probably a good idea to support it.

• Read a panel. This message reads the input fields from a panel.

Message Protocol

Now I will define the message protocol. This article uses a simple protocol based on the assumption that the application will exactly mimic the green-screen logic. That is, each display file operation will be converted to only one message. This allows me to define an upper boundary to the message size, which I will do when defining the message body. Because of this assumption, some of the complexities of message management are removed, particularly that of managing multiple-segment messages, which are messages that span more than one physical data unit. This is another benefit of the server/client architecture.

All messages consist of two parts: a header and a body. The header contains specific fields that do not change from application to application. These application- independent fields allow you to use a standard mechanism to process the messages. In fact, if you use an object-oriented language to develop the user interface, you’ll find that you can write a generic class to handle most of the interface details, changing only the actual screen layout for different applications. This is exactly how the AS/400 handles display files: Common routines in RPG are used to communicate with a display file, which defines only the actual position and layout of the fields.

Message Header

As shown in Figure 2, the message header for our example has five fields. The fields contain the following information:

• Session ID defines which user interface program you are communicating with. Whenever a user requests an application while using a workstation, the host assigns the workstation a session ID. This ID routes messages to the correct workstation.

• Screen ID corresponds to the display file name. In our simple architecture, this will actually contain the 10-character display file ID that the original monolithic RPG program used.

• Panel ID identifies which panel within the screen to access and is equivalent to the format ID within the display file.


• Operation code should have a one-to-one relationship with the actual op code used in the RPG program. The only difference is for error message subfiles. Note that error message subfiles require extra processing. Programs that originally sent a message to the program message queue now have to send “add an error” messages to the error message subfile panel.

• If the operation is successful, the return code contains a value indicating which function key was pressed. (This value can be used to set the appropriate command key indicator in the application program.) This field can also contain error codes such as session, screen, or panel not found.

Message Body

The message body is specific to the application. It may be specific to the high-level language (HLL) used to develop the application. For example, a strict emulation of an RPG application may require that all 99 indicators be sent to the user interface client, which is probably necessary if your application makes heavy use of indicators to hide fields. In that case, your message body will have the format shown in Figure 3. The indicator buffer contains the 99 indicators from the application program. Your user interface will be written to understand the meaning of those indicators. You may implement only some of the functions; for example, you might not recognize the color keywords. The data buffer contains the actual fields. No single operation for a standard 24 x 80 inch 5250 screen can have more than 1,920 bytes of data, and most operations have considerably less. You can set an upper limit of 2,019 bytes of data in the message body and about 40 bytes of data in the message header to safely contain any message in 2,100 bytes of data. This is a negligible amount, especially with modern compression techniques.

User Interface Client Gets a Lift

The message protocol outlined here allows any existing AS/400 block mode application to be split into user interface and application logic. The layout of the message body is specific to RPG, but the overall architecture supports any block mode HLL. This first step of revitalization allows you to redesign the user interface client, which I cover in the article
“Revitalization—Put on a GUI Face.”


Application Presentation Session Transport

Network Data Link Physical Header Body

Session ID Screen ID Header Body

Indicator Buffer

(99 bytes) Field Buffer (1,920 bytes)

Browser, FTP clients, Email HTTP, FTP, POP
NetBIOS Novell SPX, the TCP portion of TCP/IP Novell IPX, the IP portion of TCP/IP Ethernet, Token-Ring Twisted Pair, Coax

Figure 1: The OSI Reference Model has seven distinct layers that delineate responsibilities in a distributed programming architecture.

Opening_Up_Your_Options05-00.png 322x109

Panel ID Oper Code Return Code

Figure 2: The message header contains the basic data fields required for communication between the application client and the user interface server.

Opening_Up_Your_Options05-01.png 311x109

Figure 3: The message body contains an indicator buffer and a field buffer.


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: