Treehouse Remote Access (TRA) Connects
tRelationalPC to Your Mainframe

by Dan Acheff

This article describes how we added a Graphical User Interface to one of our NATURAL-based mainframe products, tRelational, and the middleware that we created in the process, Treehouse Remote Access (TRA).

tRelational Needs a GUI

The tRelational product from TSI is an ADABAS C data analysis tool which also assists in ADABAS to RDBMS mapping and data modeling. In releases prior to V3.0, tRelational was a typical NATURAL application with a 3270 user interface.

Since the data modeling component of tRelational was in need of a Windows-based Graphical User Interface (GUI), we began investigating a port through which tRelational could be brought to the PC platform. Our evaluation of Windows GUI building tools confirmed that C++ would give us the most flexibility. We decided that rewriting all of the tRelational code in C++ would be prohibitive, and we would still have to access the tRelational Dictionary (TRE-DICT), which is an ADABAS C file on the mainframe.

NATURAL RPC Fits Best

The best solution was to use a Remote Procedure Call (RPC) mechanism that would allow our Windows-based C++ GUI programs to call mainframe resident NATURAL programs. We decided that this approach was viable and planned the release of tRelational V3.0, the first TSI mainframe product to have a GUI front-end. The first task was to reorganize the tRelational NATURAL code in order to separate the 3270 user interface from the application logic and data access routines. The idea was to share the application logic and data access routines between both user interfaces (i.e., 3270 on the mainframe and the Windows GUI). This would also allow PC and mainframe users to share TRE-DICT.

We identified the NATURAL subprograms needed by the Windows-based C++ programs, and began coding the GUI accordingly. The only missing piece was the NATURAL subprogram RPC mechanism. Commercial products were available that provide the ability to call NATURAL subprograms, but the problem we had was cost. The NATURAL RPC solution we incorporated into tRelational had to be available at a fraction of the total cost of tRelational. Since we were unable to find any products to bundle with tRelational that did not severely impact the cost, we decided to write our own NATURAL subprogram RPC, which we call Treehouse Remote Access (TRA).

The only remaining application-specific tasks were the creation of program stubs. In a typical RPC environment, the RPC facility will automatically create the program stubs for both the client and server, by analyzing the target programs. The program stubs are very small, simple modules so we decided to code them manually. The NATURAL program stubs simply convert a parameter list of character strings to/from a parameter list acceptable to the target NATURAL subprogram. The C++ stubs on the Windows platform perform a similar function, converting a parameter list of various C++ data types to/from a parameter list of character strings.

TRA Architecture

The TRA Server is a stand-alone MVS address space written entirely in Assembler, except for the TRA NATURAL Server which is written in NATURAL. The TRA Server loads and calls the NATURAL batch nucleus and starts the TRA NATURAL Server running. The TRA NATURAL Server has a very simple processing loop:

• Receive an RPC request from a calling client through the TRA Communication Routines
• CALLNAT the indicated NATURAL subprogram stub
• Send the RPC response to the calling client through the TRA Communication Routines

This processing loop is executed until the TRA Server is shut down by an operator command. The TRA Communication Routines are responsible for the reliable delivery of the RPC request to the TRA Server and the response to the TRA Client using TCP/IP. These routines are also responsible for ASCII to EBCDIC conversion. There are several other subtasks in the TRA address space for functions such as operator communication, remote monitoring, and batch program submission. The batch program submission capability has not been utilized by tRelational yet, but may be used in a future release to run batch reports.

TRA Future Plans

Future plans for TRA include the addition of multiple TRA NATURAL Server subtasks and a dispatching facility to allow multiple concurrent RPC requests. A program stub generator that would allow quicker integration of NATURAL 3270 based applications into the TRA environment is also being considered. With these enhancements in place, TRA will be a fully functional NATURAL RPC facility with many possibilities.

One possibility that we are investigating is the integration of TRA and the ForeSite™ Application Server, a product distributed by TSI and developed by InfoSpinner, Inc. The ForeSite Application Server allows the developers to create Web pages from many data sources, including mainframe 3270 applications.

The System Integration Modules (SIMs) of the ForeSite Application Server are the building blocks that are used to add data sources to its Web library. A TRA SIM would allow a Web page author to easily define data produced by NATURAL subprograms to a Web page with the ForeSite Integrator. Then, the dynamic data generated by the NATURAL subprogram could be retrieved by the TRA SIM and added to the Web page by a ForeSite PageServer®. Thus, the proposed TRA SIM would give Web page developers a flexible and easily configurable mechanism for Web-enabling NATURAL applications.