In a variety of cases, it just makes sense to consider using Zend's 5250 Bridge. For developers, it offers a way to get a GUI without having to rewrite existing 5250 applications. The 5250 Bridge also lets you see multiple green-screen applications in a single view, and it allows for reuse of green-screen application logic. For solution providers, the 5250 Bridge provides a methodology for incorporating a graphical interface into their products to make them more appealing to today's decision makers. Additionally, it gives you a platform where you can build new functional options via Internet deployment without having to master a number of complex technologies. Because Zend's 5250 Bridge does not incur an interactive cost, it lets you compete in the low end. And finally, it provides a means for implementing a modernization solution in PHP similar to IBM WebSphere HATS.

To help you determine whether this tool may be useful in your shop, I introduce Zend's 5250 Bridge, provide an overview of its architecture, and walk you through the installation procedure.

5250 Bridge Defined

So what exactly is 5250 Bridge? It's a PHP library consisting of a set of PHP functions and classes for accessing 5250 data streams to enable 5250 interfaces and applications within a PHP program. Both PHP functions and classes are provided to give developers the option of using procedural functions or object-oriented programming. Implementing the 5250 Bridge utilizes the IBM WebFace server, which is part of TCP/IP on IBM i.

Features of 5250 Bridge include availability of all screen information (input and output fields and attributes, format name), a maintainable 5250 session, and no requirement for Java.

High-level Architecture

To understand how 5250 works, we must first look at the program model of a typical 5250 application (Figure 1). In this model, the 5250 application presents a screen and waits for input. Once the input has been entered, the application processes the input in the business logic of the application and then decides which screen to display next via the Workstation Function Manager. All screen data entered, including function selections, is communicated to the application through the Workstation Function Manager as well. Now consider the architecture of the 5250 Bridge (Figure 2).

The PHP application acquires screen data (e.g., field formats, field contents, function key mappings) from the Workstation Function Manager in an XML file. The XML file is populated via calls to the APIs residing in the 5250 Bridge. Likewise, APIs are provided for the PHP application to communicate 5250 requests through the 5250 Bridge to the Workstation Function Manager.

One way to view this is that the PHP application and 5250 Bridge API replace the 5250 screen representation in the Classic Program model in Figure 1. This architecture allows for the 5250 Bridge API to be used in such a way that the application logic of the 5250 program doesn't change. The 5250 application still provides the business logic and database access, as in the Classic Program model, as well as screen manipulation — the difference is that the screen manipulation is communicated via the 5250 Bridge to the PHP application rather then being rendered on a 5250 screen.

The following steps enable a PHP program to interact with an IBM i 5250 application:

1. The PHP program sends a "start session" request to the 5250 program by using the 5250 Bridge API.
2. The 5250 Bridge API returns a confirmation to the PHP program indicating that the interactive program session has started.
3. The 5250 Bridge API sends current screen information (e.g., input and output fields, field attributes, cursor position) in XML format to the PHP program.
4. The PHP program sends input values and function key actions to the 5250 Bridge API.

Installation

The 5250 Bridge is part of the larger Zend Platform product available from Zend (zend.com). You can download a 30-day evaluation of Zend Platform that provides a fully functional version of 5250 Bridge for an unlimited number of concurrent 5250 sessions. When the 30-day trial expires, the number of concurrent connections will be limited to one, which still affords developers the opportunity to create web applications that use the 5250 Bridge API. Prerequisites for the 5250 Bridge include

• Zend Core for IBM i5/OS: 1ZCORE5, *BASE
• Developer Kit for Java: 5722JV1, *BASE
• Java Developer Kit 1.4: 5722JV1, 6

To install Zend Platform, follow these steps:

1. Download the product from the Zend website (zend.com).
2. Unpack the resulting zip file.
3. Create a save file on IBM i using command CRTSAVF ZPLATSAV.
4. Transfer the save file from the zip file to IBM i (put zplatsavf /qsys.lib/qgpl.lib/zplatsavf.file).
5. In IBM i, execute the installer using command RSTLICPGM LICPGM(1ZCORE5) DEV(*SAVF) OPTION(1) SAVF(QGPL/ZPLATSAVF).

The Zend Platform files will be restored to the IFS. Several screens will appear, indicating the action the installer will be taking. After several minutes, the installation is complete, and the 5250 Bridge is available for use.

Part of the Zend Platform installation is an updated index page that includes links to the three 5250 Bridge demo programs:

• The 5250 emulation program allows access to IBM i resources using the 5250 emulation client with the Zend 5250 Bridge API.
• Subfile runs an interactive program supplied with 5250 Bridge that uses a Z5250DEMO user created by the installation of Zend Platform.
• Subfile extended also runs an interactive program supplied with 5250 Bridge that uses the Z5250DEMO user created by the installation of Zend Platform. This demonstration, however, extends the IBM i program by adding images and using Ajax technology.

The Zend Platform installer adds the following directory structure to the IFS:

• /usr/local/Zend/5250/API — contains the PHP interface functions
• /usr/local/Zend/5250/demos — contains three demonstration programs
• /usr/local/Zend/5250/etc — contains configuration files
• /user/local/Zend/5250/logs — logs file directories

Let's examine the first demo — 5250 emulation program — to see, from a user perspective, how the program works.

When a user provides a valid IBM i user name and password and clicks the Login button (Figure 3), a 5250 emulation session is started within the browser window (Figure 4). Discussing all the code that comprises this demo is beyond the scope of this article; however, we can briefly look at some of the basic building blocks of the 5250 Bridge. Keep in mind that when you install Zend Platform, the demo code is available for your review at /usr/local/Zend/5250/demos.

The first thing to notice in the PHP program is how to specify the 5250 Bridge API directory location as the include path:

<?php
set_include_path('usr/local/Zend/5250/API');
require_once ('Zend/ProceduralApi.php');

The set_include_path() function defines the include_path configuration option for the duration of the running of the PHP script. The require_once() call includes and evaluates (executes) the specified file (in this case, 'Zend/ProceduralApi.php'). Note that use of the require_once() function causes the script to be evaluated only once, even if the code's logic causes the require_once() statement to be encountered a second time. Recall from earlier that 5250 Bridge supports both procedural and object-oriented calls. If you want to develop code using objects, then the require_once call() would be

require_once ('Zend/5250.php');

Next, we open a connection:

$Bridge = Zend_5250_open ( 'simple' );
$response = @zend_5250_connect($Bridge);

The call to Zend_5250_open() causes a session to be started. The call to zend_5250_connect() creates the actual connection between the PHP program and the 5250 Bridge using the connection established by the Zend_5250_open() call.

The next step is to make calls to the bridge that will enter the IBM i user name and password in the correct fields — that is, the fields expected by the 5250 application:

zend_5250_set_input_field ( $Bridge, 0, 'USER');
zend_5250_set_input_field ( $Bridge, 1, 'password');
$response = zend_5250_submit ( $Bridge );

The zend_5250_set_input_field() function populates data into an input field as specified by the field ID. The first parameter to the call is the resource for the 5250 Bridge connection as established by the earlier call to Zend_5250_open. The second parameter is the field ID number on the 5250 screen. Consider a 5250 emulation sign-on screen — the first field (i.e., user name) is assigned field ID 0, and the second field (i.e., password) is assigned field ID 1. Finally, the third parameter is the data that will populate the field. The zend_5250_submit() function call causes the data on the 5250 screen to be submitted to the specified bridge connection. These four function calls provide the foundation for the use of the 5250 Bridge.

The 5250 emulator presented as a result of running the demo can display the input field numbers when you hover the cursor over a particular field. This capability can help you greatly when you develop your own 5250 Bridge applications, as it lets you run the 5250 application in the emulator window and determine the field numbers. For example, hovering the cursor in the "Selection or command" field of the emulator window in Figure 4 displays the result in Figure 5, which indicates that the field ID for the input field is 0.

A Bridge to the Future

Now that you have some ideas of how to use 5250 Bridge to web-enable existing 5250 applications, I encourage you to explore further by visiting the 5250 Bridge web page (zend.com/5250). Also, be sure to examine the demonstration programs that installation of the Bridge provides.

Erwin Earley is a staff software engineer at IBM and has worked with the Rochester, Minnesota, development lab since 1996. He has worked in the IT industry since 1980 and has experience with several Unix variants as well as Linux and OS/400.