RPG Everywhere!
RPG isn’t just for the AS/400 anymore as Cross/400 puts RPG on multiple platforms using a Java-like virtual machine| | Cross400 Summary Product: Cross/400
Company: CrossWorks
Phone: (612) 938-8130
URL: http://www.cross-works.com/ (new window)
Price: Varies based on complexity of migrated application
Summary: Cross/400 is a complete environment for porting RPG applications to non-AS/400 platforms | |
|
|
Since the beginning, RPG has been almost exclusively an AS/400 language using AS/400 specific constructs for creating menus and screens. So imagine our surprise when we saw an AS/400 RPG application running on a Windows NT system—just as if it were meant to run there in the first place. By borrowing a page from Java and creating a virtual machine that runs RPG, CrossWorks Inc.’s (Hopkins, Minn.) Cross/400 allows any AS/400 RPG application to be ported to any platform that the virtual machine supports.
Although there are other development environments that allow you to compile RPG code to run on non-AS/400 platforms, Cross/400 is the first we have seen that requires little or no rewriting of code. For example, ASNA’s Visual RPG ("A Different View of RPG”) will let you move RPG applications from the AS/400 to Windows, but not without additional programming.
Today, Cross/400 is sold as a combination of software and services, with CrossWorks doing the migration of the first application and delivering the Cross/400 toolkit plus a working RPG application to the customer. After the first application has been migrated customers can do later migrations on their own. CrossWorks does intend to release a shrink-wrapped version of Cross/400 once the virtual machine supports a high percentage of CL commands.
More Than a Cup of Coffee
The Cross/400 RPG Virtual Machine (VM) is very similar to the Java VM with one important exception: The RPG VM is able to process the RPG language commands as well as many CL commands. In addition to its RPG and CL language processing capabilities, the VM understands DDS files and encapsulates a fully functional version of the OS/400 database, DB2/400.
This full DDS and DB2/400 database support is what allows RPG applications to be ported to other platforms with no rewriting of code. If it works on the 400, it should work on Cross/400. If an application can’t be ported directly, which would happen most frequently when it uses CL commands that are not supported, CrossWorks will add the missing support to Cross/400. This additional support is not free and will increase the initial cost of Cross/400, which is based on how much work the first migration requires.
| To an ISV this $25,000 price tag may not seem like a lot when weighed against the increased revenues the additional platform support might bring. Unfortunately, to an IS manager, this price tag is high enough to make them think twice. |
The first step in the migration process is to send your complete RPG application to CrossWorks for analysis. CrossWorks has developed a set of tools that examines RPG code and reports on problems that Cross/400 will have with the code. CrossWorks then decides on the cost of the migration and how long it will take to complete.
Typically, an RPG application that needs additional support for only a few CL commands takes roughly four weeks to migrate and costs approximately $25,000. The caveat here is that each application is looked at separately and the cost and migration time varies widely. Don’t let the $25,000 price tag scare you. Remember that this price includes the Cross/400 software and migration services for your first application. It also includes two days of face-to-face training for your staff in the operation of the Cross/400 tools.
The typical user of Cross/400 will be an ISV with an AS/400-based RPG application that wants to expand its market by adding support for additional platforms. Another use for Cross/400 is moving applications developed internally within your company to Windows NT so they can be run on less expensive PC hardware. This would typically not be done to replace an AS/400, but to supplement a central AS/400 with a Windows NT server at a remote location.
Monetary Migrations
To an ISV this $25,000 price tag may not seem like a lot when weighed against the increased revenues the additional platform support might bring. Unfortunately, to an IS manager, this price tag is high enough to make them think twice. IS managers should consider the cost of putting an AS/400 in every remote location where the application needs to run and then add in the cost of supporting these remote AS/400s. When looked at in this context, the $25,000 price tag may not seem too high.
After you decide to go ahead with the migration and agree to the timetable and price, CrossWorks will complete the migration.
When CrossWorks was first developed, the steps to migrate an entire application were performed manually. Over time CrossWorks has used the lessons learned while migrating its customers’ applications to create a step-by-step automated process that is run from within the Cross/400 environment.
Because we didn’t have a complete RPG application of our own, CrossWorks was kind enough to let us use a customer’s recently migrated application for our evaluation. To simulate the customer experience, a CrossWorks technician paid us a visit and we walked through the migration process in a manner similar to what would happen in the two-day training course.
We won’t bore you with the specifics, but the migration process mostly involves moving the RPG application from the AS/400 to the target system, creating libraries on the target system, compiling the RPG, CL and DDS programs into objects, as well as a whole host of other tasks.
Because Windows doesn’t understand the concept of libraries and members, Cross/400 simulates them with directories and files. On a Windows system the AS/400 libraries are folders, the source files are sub-folders of the library folders, and the members are Windows files within the sub-folders. The translation between EDCDIC and ASCII is done during the migration process automatically.
We think that with the two-day training course under your belts, and sufficient knowledge of the target platform, you should have no trouble migrating the second and later applications.
The End of the Road
What you get after the migration is complete is a working version of your application that runs on the target platform. At this point Cross/400 is available on Windows 95 and 98, Windows NT, Sun Solaris, IBM AIX, HP-UX, and SCO Unix. You should contact CrossWorks for an up-to-date list of supported platforms.
Typically this application is stored on a server and the clients access the application on the server, but run the VM locally. Another possibility is for the VM to run on the server and distribute the GUI to the client through something like X Windows or Windows NT Terminal Server Edition. In this situation, CrossWorks analysts say that a 100 MHz Pentium server running Windows NT should be able to handle 10 clients. They also suggest that it is more important to have fast disks than a fast processor, as the VM is very disk intensive.
There is some configuration required on the client systems, but configuring our Windows 98 PC to run the migrated application only took a couple of minutes. You have to add the CrossWorks program directory to your Autoexec.bat file and customize the x400.ini file to fit the environment. The x400.ini file contains parameters that control components such as printing, GUI presentation, error logging and the default user name.
Using the WINMODE parameter you can control how the application will be presented to the user. The WINMODE=GUI setting enables “Quick & easy GUI” which is an on-the-fly screen scraper built into Cross/400. The “Quick & easy GUI” interprets the DDS files at runtime and substitutes an appropriate GUI element for each DDS element. For example, a DDS entry field will be rendered as a text box, a DDS entry field with multiple choices will be rendered as a drop-down box, and function keys will be rendered as buttons. If you use WINMODE=TEXT you will get the look and feel you expect from an AS/400 application green-screen application.
One recent enhancement to the software is the addition of 5250 data stream support. In the version we reviewed the application screens were displayed in a CrossWorks window. By the time you read this article, CrossWorks will have added support for 5250 terminal emulators. With this support you can use any 5250 terminal emulator to display a Cross/400 application. More importantly you can use any software that uses a 5250 data stream to enhance the presentation of the application. Cross/400’s “Quick & easy GUI” will be alright for most purposes, but the added 5250 support will allow you to do more complex transformations with third-party tools.
Once you have configured Cross/400 you must change your directory to the application directory before you run the application. From a DOS window (on Windows 9X/NT), enter x400 and a logon screen similar to that of an AS/400 is displayed. Type in a user name and password and the application’s main screen is displayed.
Cross Profiling
The VM recreates the security environment on an AS/400 complete with user profiles and object security. The VM also recreates AS/400 print spooling and job queues. We navigated the application extensively and were amazed by how faithfully Cross/400 recreated the AS/400 environment. You can even pop out of an application to a command line and run CL commands, just like you would be able to do on an AS/400. The only difference is that there is less help and prompting available from the Cross/400 command line than from a real AS/400.
As we mentioned before, the Cross/400 VM recreates most of the functionality of an AS/400, including the database. This database support includes support for compiling DDS into physical and logical files. Cross/400 even provides support for ODBC access to its internal database so you can use any ODBC-compliant tool to manipulate the data created by your applications.
This internal database support will work for most applications, but some organizations may want to access existing RDBMS from within Cross/400 applications. In the coming year, CrossWorks plans to add native support for Oracle and IBM DB2 databases.
Although we did not migrate our own application we feel that we experienced much of what a CrossWorks customer would go through during this process. That said, we could recommend, without hesitation, Cross/400 to any ISV that wants to quickly get up and running on an additional platform. The additional revenues the new platform will bring should offset the cost of the initial migration fairly quickly. In addition to the initial cost of the first migration there is a license fee for each copy of an application that is sold to a customer of the ISV.
For corporate IS departments, the decision to use Cross/400 is less clear-cut. If you have an existing application that you need to run on another platform, and you don’t want to rewrite the application, then Cross/400 will work great if you can afford the price tag.
In any case we found Cross/400 to be a useful tool for extending the usefulness of RPG applications. Although Cross/400 will not fit everyone’s needs, when it does, it could be a lifesaver and prevent many months of new development.
Related Editorial:
The Future of RPG"Virtual RPG Machine" Will Aid PortingRelated Information:
CrossWorks Inc. (new window)Cross/400 Overview (new window)