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.

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.

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