If your training, like mine, is in traditional IBM midrange development techniques, client/server presents some challenges. For example, a graphical user interface (GUI) uses different design techniques than a green-screen, text-based application uses. Not only are client/server's visual elements foreign to most AS/400 programmers, so are the concepts of event-driven programming, and the distribution of program components between the client and the server. Even the language syntax is new-that's one of the reasons I like IBM's new VRPG product.

VRPG, officially VRPG Client/2, is a visual client/server development environment for OS/2 that has some unique benefits for AS/400 programmers. The compiler is based on the AS/400 ILE RPG compiler, which greatly reduces the issue of language syntax. I would say it eliminates the issue of language syntax-except that most AS/400 programmers are still learning ILE RPG. Fortunately, ILE RPG and VRPG are closely related to the previous generations of RPG/400; experienced AS/400 programmers will find that the learning curve is minimal. VRPG can ease you into client/server development, giving you some insight into the issues involved, even if you eventually decide to use a different set of development tools.

Because VRPG was designed specifically for the AS/400 market, it contains support for many critical AS/400 components. For example, VRPG supports a GUI subfile control that goes far beyond the list box functions delivered with a standard GUI design product. VRPG can take advantage of AS/400 file definitions to define files that are accessed in client/server applications. It integrates support for PC-to-AS/400 connectivity, making the communications link fairly transparent.

The current version of VRPG was released for general availability on December 31, 1994. It requires OS/2 (2.1 or Warp) and V3R1 of OS/400. IBM plans to develop a Windows run-time module for VRPG by the third quarter of 1995.

Sneak Preview

IBM announced VRPG on May 3, 1994, as part of the V3R1 announcement, and I was impressed with its potential (see "Visual Development Tools for RPG," MC, May 1994). In December, IBM invited the technical press to Toronto for an in-depth briefing on VRPG. At the briefing, I was able to develop an application using VRPG, to talk to the developers about their plans for the product, and to see some of the sample applications that have been developed using VRPG.

I was especially impressed by the migration examples; VRPG includes an import facility that will convert AS/400 display files to the GUI that VRPG uses. The migration facility is not designed to be a screen scraper that puts a GUI front-end on your AS/400 application. Instead, it converts the screen elements to their GUI counterparts. For example, the function keys that are defined will be converted to push buttons that you can connect to exit routines. (For more information on GUI controls, see "Graphical Controls: An Introduction" elsewhere in this issue.) The conversion is based on the information extracted from the display file definition.

As I discovered during my visit to Toronto, the only way to get a perspective on VRPG is to try it yourself. Client/server applications in general-and VRPG applications in particular-are not designed as a single monolith of code. They are built up by tying the graphical screen components to small sections of code that react to user input. All components are then bundled together during a build routine supplied as part of the development environment. To give you a perspective on how applications are built using VRPG, I'll start with an overview of the components of the development environment.

Magical Mystery Tour

Like most client/server development tools, VRPG is much more than a compiler- it's a complete development environment. Many of the components are borrowed from other IBM products-one reason IBM was able to bring this product to market so quickly. Logically, VRPG has six major elements.

o The GUI builder. o The source code editor. o Support for database connections. o PC-to-AS/400 connectivity. o The VRPG compiler. o The debugger.

All six components are built on the underlying structure of IBM's Workframe/2, which ships with VRPG and is essentially transparent to the programmer. Workframe/2 provides many facilities, such as the build utility that compiles and packages VRPG programs.

The GUI builder is where a VRPG developer spends most of his time. It is a typical OS/2 application that lets you build the user interface element of your application and attach sections of VRPG code to events. An event, in GUI terms, is any action that initiates a section of code. Most events are triggered by user input, such as clicking a mouse button, but events can also be caused by the program itself. For example, when a window is opened or closed, a corresponding event is processed by the program.

Using the GUI builder is a lot more intuitive than it sounds. Since most AS/400 programmers use PC applications, designing a GUI is essentially a matter of translating your experience as an end user into a design that adheres to accepted standards. Most of the difficulties I had with VRPG can be traced to lack of familiarity with OS/2.

1 illustrates the VRPG GUI builder with a partially built data entry window. Several controls have been placed in the window by dragging them from the palette of controls shown at the left of the screen. This component of VRPG is standard fare for client/server development tools. IBM incorporated some built-in components of OS/2 (e.g., color palette selection) into this portion of VRPG.

Figure 1 illustrates the VRPG GUI builder with a partially built data entry window. Several controls have been placed in the window by dragging them from the palette of controls shown at the left of the screen. This component of VRPG is standard fare for client/server development tools. IBM incorporated some built-in components of OS/2 (e.g., color palette selection) into this portion of VRPG.

After the window is designed, the events associated with various controls must be connected to the RPG code. VRPG uses two special opcodes-BEGACT and ENDACT-to isolate the code for an event. BEGACT and ENDACT are similar to the BEGSR and ENDSR operations except that these operations mark the beginning and end of a routine that is executed for an event.

To build the code for an event, click the right mouse button on the control, select EVENTS from the pop-up menu, and select a specific event from the list allowed for that particular control. For example, a push button control allows a "press event," but a text box control does not. As soon as an event is selected, VRPG transfers to the source code editor where the instructions that contain the BEGACT and ENDACT opcodes have already been created. All you have to do is key in the RPG source code necessary to process the event.

This is where VRPG really shines. The source code editor, based on the CODE/400 editor, includes syntax-checking capabilities and formats for RPG specifications. If you are familiar with CODE/400, you'll recognize the editor. Although in many cases the only code you will create for an event is the C- specs, you can add other program components, such as D-specs (see "An Introduction to ILE RPG: Part 2," MC, April 1994). Don't worry about linking the code to your database; that's done in a separate step. The partial code for the press event associated with the Add a Customer push button is illustrated in 2. Instinctively, an RPG programmer understands this code because the basic syntax is so familiar.

This is where VRPG really shines. The source code editor, based on the CODE/400 editor, includes syntax-checking capabilities and formats for RPG specifications. If you are familiar with CODE/400, you'll recognize the editor. Although in many cases the only code you will create for an event is the C- specs, you can add other program components, such as D-specs (see "An Introduction to ILE RPG: Part 2," MC, April 1994). Don't worry about linking the code to your database; that's done in a separate step. The partial code for the press event associated with the Add a Customer push button is illustrated in Figure 2. Instinctively, an RPG programmer understands this code because the basic syntax is so familiar.

The strangest part of developing an event-driven application is that you hardly ever see a program in its entirety. Although VRPG gives you the option to view the source code, a "complete" program is the antithesis of event-driven programming. With VRPG, you see each action (or subroutine) as it is built by joining a specific event, associated with a specific control, to a specific section of code. You can think of that one subroutine as totally self- contained. The way VRPG showed me code helped me understand the event-driven programming concepts.

Linking your program to the AS/400 database is a natural part of the design process. Just as SDA allows you to define fields based on externally defined database files, so does VRPG. Before you can reference a file definition, you must link your VRPG session to the AS/400.

VRPG currently does not require Client Access/400 (PC Support). It uses Communications Manager/2 or Communications Manager/400 to establish an Advanced Peer-to-Peer Networking (APPN) link with one or more AS/400s. Once the link is established, VRPG provides several ways to access a hierarchical list of AS/400 field definitions.

After you select the file and field reference, you can link the field to a particular control (typically a text box or a subfile column). VRPG uses the external file definition stored on the AS/400 to determine field attributes, such as character or decimal data, field length, and decimal positions. VRPG can also take advantage of any validations that are stored in the field definition.

Open for Business

When the design and the coding are complete, it's time to compile (or build) your application. Click on the icon on the toolbar and your program is compiled. The source code editor helps you find and correct any syntax errors.

The VRPG compiler is based on a compiler technology used throughout the Toronto lab-W-code. W-code is an advance on the original concept of high-level language (HLL) compilers. Most compilers have a front-end based on the language standard (e.g., COBOL, FORTRAN, or RPG) and a machine-specific back-end. W-code compilers separate these two elements. Each compiler writes to a common denominator-W-code. For each platform, there is one W-code back-end that translates the W-code into machine-specific instructions. All AS/400 ILE compilers and the newer OS/2 compilers use W-code technology.

To create the VRPG compiler, IBM used the ILE RPG compiler front-end to generate W-code and married it to the W-code back-end compiler developed for OS/2 C Set++. The only modification was the addition of several specific opcodes required for the event-driven design. Notable examples are the BEGACT and ENDACT opcodes discussed earlier.

VRPG provides a toolbar icon to test your application and a source level debugger, borrowed, like the editor, from CODE/400. This comprehensive debugging tool lets you see your code as it's executing, add and remove breakpoints with the click of a mouse button, and modify variables. If you've never used a source level debugger, you're in for a pleasant surprise. Source level debugging tools are a standard feature of many PC-based application development tools-a feature every programmer should demand.

The elements that make VRPG stand out as a choice for AS/400 developers are the familiar RPG syntax supported by the CODE/400 editor, the built-in interface to AS/400 file definitions, and the import facilities that give you a head start on converting your existing applications. Because the import facilities are the easiest way to get started with VRPG, I'll take a more detailed look at what's involved when you migrate an AS/400 application to VRPG. (In future articles, MC will provide additional details about VRPG features. We expect VRPG to become an important part of our development arsenal, and you'll find the results of our experiences in the magazine on an ongoing basis.)

Easy as...

To give you a feeling for VRPG's import function, I've chosen a simple subfile application that was published in MC several years ago (see 3). The display file contains three records-HEADER (the subfile control record containing the column headings for the subfile and the entry field used to position the subfile); DETAIL (the subfile record); and TRAILER (which displays the function key information at the bottom of the screen). I converted the display file for this application to illustrate how the VRPG import function works.

To give you a feeling for VRPG's import function, I've chosen a simple subfile application that was published in MC several years ago (see Figure 3). The display file contains three records-HEADER (the subfile control record containing the column headings for the subfile and the entry field used to position the subfile); DETAIL (the subfile record); and TRAILER (which displays the function key information at the bottom of the screen). I converted the display file for this application to illustrate how the VRPG import function works.

First, I located the display file on the AS/400 using the hierarchical library/file display shown in 4. When I selected the XRD002DF display file, VRPG listed all three records. HEADER is not available for import because VRPG does not use the concept of a subfile control record. In fact, the only record I needed to import was DETAIL. The import facility automatically incorporates the necessary components from the subfile control record. In this case, that includes the input field used to position the subfile, the column headings, and even the function keys because the valid function keys were defined at the file level in this display file.

First, I located the display file on the AS/400 using the hierarchical library/file display shown in Figure 4. When I selected the XRD002DF display file, VRPG listed all three records. HEADER is not available for import because VRPG does not use the concept of a subfile control record. In fact, the only record I needed to import was DETAIL. The import facility automatically incorporates the necessary components from the subfile control record. In this case, that includes the input field used to position the subfile, the column headings, and even the function keys because the valid function keys were defined at the file level in this display file.

The import facility creates a part for each record you import. A part, in VRPG terms, is any component of an application; it can be an entire window with multiple fields or a single pushbutton. By placing the DETAIL part in an empty window using VRPG's GUI builder, I could see the basic subfile design created by the import facility. A portion of the resulting screen is shown in 5. Some components are outside the screen window and cannot be seen in this initial view. Scrolling out to the edges of the window shows that all the subfile components are intact.

The import facility creates a part for each record you import. A part, in VRPG terms, is any component of an application; it can be an entire window with multiple fields or a single pushbutton. By placing the DETAIL part in an empty window using VRPG's GUI builder, I could see the basic subfile design created by the import facility. A portion of the resulting screen is shown in Figure 5. Some components are outside the screen window and cannot be seen in this initial view. Scrolling out to the edges of the window shows that all the subfile components are intact.

Although the basic user interface is converted, some cosmetic cleanup is required. For example, the SELECT column makes no sense in a GUI environment. This field should be deleted from the subfile as illustrated in 6. In 7, the subfile window has undergone some initial cleanup. The next step would be to write the code to display and process the subfile.

Although the basic user interface is converted, some cosmetic cleanup is required. For example, the SELECT column makes no sense in a GUI environment. This field should be deleted from the subfile as illustrated in Figure 6. In Figure 7, the subfile window has undergone some initial cleanup. The next step would be to write the code to display and process the subfile.

This application is hours (not days) from being a complete, working client/server application with logic residing on the PC, particularly if the AS/400 application is written in ILE RPG. In many cases, you can cut and paste sections of code that perform specific functions from the AS/400 application to the PC application.

A Look at the Crystal Ball

As it exists today, VRPG is a useful product for AS/400 programmers. By using a familiar language syntax, RPG programmers can get a faster start on learning the other skills needed in this new environment. If IBM follows through on the plans the developers discussed with the technical press late last year, VRPG has the potential to become an important player in the AS/400 client/server marketplace.

IBM has made a good start at providing transparent function for AS/400 developers by delivering support for field references and subfile parts. The development team intends to make VRPG a full-fledged PC tool. For example, IBM plans to allow third-party vendors to extend VRPG using a technique similar to VBX extensions for Visual Basic.

The biggest stumbling block that VRPG faces is OS/2. VRPG gave me a chance to learn more about OS/2, and I'm impressed-as I expected to be. However, an OS/2-based product in the current PC marketplace faces an uphill battle. The Toronto developers are well aware of the importance of Microsoft Windows in the desktop market, and plans are under way to create a Windows run-time version of VRPG later this year. A Windows development environment is a much larger project because so much of VRPG was created by taking advantage of existing OS/2 components. However, the Toronto developers are actively exploring ways to port VRPG to Windows.

The Final Analysis

Hundreds of client/server development tools are on the market. Choosing among them involves personal chemistry, good research, and a little bit of luck. Most shops will end up with multiple products that work together or separately, depending on the specific problem at hand.

VRPG provides some specific advantages particularly if you're just getting started with client/server. Its built-in AS/400 knowledge makes it easy to access and define your data, the familiar RPG syntax eliminates one new skill you'll have to learn, and the fully integrated package lets you get your first application up and running quickly.

Sharon Hoffman is the editor of Midrange Computing.

IBM's VRPG Hits the Street

Figure 1 VRPG GUI Builder

 UNABLE TO REPRODUCE GRAPHICS 
 
 IBM's VRPG Hits the Street
 
 Figure 2 Partial Push Button Press Event Code
 
 UNABLE TO REPRODUCE GRAPHICS 
 
 IBM's VRPG Hits the Street
 
 Figure 3 The Existing Subfile Application
 
 UNABLE TO REPRODUCE GRAPHICS 
 
 IBM's VRPG Hits the Street
 
 Figure 4 AS/400 Hierarchical Library/File Display
 
 UNABLE TO REPRODUCE GRAPHICS 
 
 IBM's VRPG Hits the Street
 
 Figure 5 The Imported DETAIL Record Format
 
 UNABLE TO REPRODUCE GRAPHICS 
 
 IBM's VRPG Hits the Street
 
 Figure 6 Deleting a Field From the Subfile
 
 UNABLE TO REPRODUCE GRAPHICS 
 
 IBM's VRPG Hits the Street
 
 Figure 7 The Subfile Example After Minor Cleanup
 
 UNABLE TO REPRODUCE GRAPHICS