Run VisualAge RPG Applications On 64-bit Windows 7, 8, And 10 Over The LAN

With assurance of continued support from IBM, we used VisualAge RPG (VARPG) to develop modern business applications. Then IBM pulled the plug on VARPG. Nevertheless, we’ve kept our applications working, and have even managed to find a way to run them under 64-bit Windows from our LAN. Here’s how we did it.

A Little Background

Around a decade ago, we were looking for a way to put a modern interface on our 5250-based applications. We really liked what VisualAge RPG (VARPG) had to offer. We found many reasons to lean toward this solution, but the most enticing ones were that we were able to utilize RPG and native file I/O. Much as we suspected, we found VARPG very easy to use. After all, it is essentially the same language (with GUI enhancements) that we’d been writing business application in for years.

We were concerned about IBM’s commitment to VisualAge RPG, but IBM representatives assured us that IBM planned to support and enhance VARPG for many years. Based on this, we continued developing brand new mission-critical applications.

Within a year, IBM officially ended support for VARPG. When I questioned two IBM’ers who spoke at a local conference, the subject was taboo. When I asked them about a migration path, they told me there wasn’t one. (A year or two later, EGL was proposed as a possible solution, but look where that is now.)

So here we are with brand new “mission-critical” core business applications, utilizing an easy-to-use interface that the users like and that IBM now considers “legacy”. How can a development tool that supports the syntax of the 6.1 RPG compiler–including free-form–be considered legacy?

A few years pass, and now a new wrinkle – these once “modern” applications would not run on Windows 7 (64-bit). Sure, Windows 7 Professional has an XP mode, but deployment to clients in this manner is messy. IBM was no help because VARPG is no longer supported and was never supported on Vista or higher.

Years have gone by, and there are now many more options for modernizing. Unfortunately, none of the solutions provide a direct migration or conversion utility from VisualAge RPG, and we simply don’t have the time, manpower, or cash flow to rewrite these applications utilizing another “new” modern user interface. For better or worse, we have VARPG applications, and we need them to run on 64-bit Windows systems.

After much experimentation, I was able to make VARPG applications run “natively” utilizing 64-bit Windows 7 over our network, bypassing any need to install the programs on each machine. I am happy to say that this solution also works under Windows 8.1 and Windows 10. Maintenance and development of applications must still be performed through XP mode, but that is a small price to pay to be able to maintain these now-legacy (although still newer than our ERP solution) applications.

The following instructions assume that you have utilized VisualAge RPG at one point or another; installation of the VisualAge RPG program itself is beyond the scope of this article.

Packaging an Application

On a system that is running Windows XP or lower, map a network drive in which to install all your VisualAge RPG applications. Install the applications to this machine only. To avoid object locks and installation problems that can occur when updating the application, do not map to the same location that your end users will use.

In my shop, we use the V: drive, with directory VRPG as the base. That is, V: is mapped to 10.10.x.yvrpg. For that reason, I use V: as the example drive in the following instructions.

Package your application to the V: drive

Under most circumstances, you want to package the entire application.

Your target directory must be on the V: drive, and the version ID must be unique. I usually use the current date appended by a, b, etc., as the version. Failure to change the version ID to make it unique will result in more complexity when running the Setup program. In this example, V:CCC is the target directory.

You will receive a confirmation box. Press OK.

Once packaging is complete, you should receive the following:

Installing an Application

Open the location where you packaged your application and launch Setup.

Upon initial install, you’ll receive a series of screens, starting with this one:

Choose the custom installation option and ensure that the destination directory has the name of the package directory with _LAN appended. In this example, the directory is V:CCC_LAN.

You will be prompted to select a program folder. Take the default and click Next.

The program will be installed.

When prompted, answer No when asked to create a shortcut. Installation is complete.

Updating an Application

When you make modifications to the program, follow the application packaging instructions above and remember to change the version number. When you run Setup, you’ll be presented with a slightly different set of prompts.

Be sure to choose Migrate as the default is to delete the application. If you see a different selection box than this one, you likely packaged with the same version number. Re-package and launch Setup again.

The program will be updated. As before, answer No when asked whether the system should create a shortcut. Update is complete.

Running the Application

Now comes the fun part. We will be allowing this application to run over the network, utilizing any version of Windows (including 64-bit versions of 7, 8.1, 10) and bypassing installing it on each machine.

Outside of your XP Mode/environment, map the V: drive to a publicly-accessible directory. (This means a directory with read and execute rights only for most users.) This will prevent the users from deleting the directories and files. We utilize the IFS under IBM’s NetServer (at 7.1).

As I mentioned earlier, this should not be the same directory to which you installed the program in XP mode. If you use the same location and the program is in use during update, Setup won’t delete the old copy and you’ll have to manually rename objects once everyone is out of the program.

Open the destination directory and delete the copies of the directories that have the same names as the package target directory and the actual program if they exist. (In this case, those directories are CCC and CCC_LAN.) The package target directory is being copied for backup purposes only.

Destination (delete):

Source (copy and paste directories into destination):

Compile the run time programs and any shared components that you may have using the same process described above. Theoretically the run time support should never change, so this step only needs to be performed when packaging your first application.

On our system, run time support is stored in directory V:VRPGVRPGRT_LANSYSTEM, and shared components are in V:VRPGVRPGRT_LANSHARED.

VisualAge RPG isn’t the most efficient at utilizing TCP. Through trial and error, I’ve discovered that the programs can be sped up significantly, especially when working off-site over VPN is necessary.

The first time a user launches a VisualAge RPG application in this fashion, it may take a few minutes to copy over the required resources. Subsequent launches will be significantly faster.

I’ve created a .BAT file for each VisualAge application. The .BAT file launches copy_rt.bat, which copies the run time support if necessary. In this case, I create a .BAT file called ccc.bat.

After initial launching, each user should have directory C:vrpgrt_lan on their hard drive.

One thing you will notice when you launch the program is that you will be always be prompted for your IBM i username and password. If your data resides on multiple systems, you will be prompted for each one.

To bypass this prompt, open your c:vrpgrt_lansystem directory. Find FVDEPW.EXE:

Right-click and send to desktop as a shortcut.

When you launch the program, you’ll have the opportunity to input your system IP address(es) that require sign-on, with the username/password. From that point, your programs will launch without being prompted each time.

The Final Chapter–Or Is It?

I have petitioned IBM (thru IBM’s Request for Enhancement) to revitalize VisualAge RPG. Unfortunately, IBM has declined this request. Perhaps you can help to put VisualAge RPG back on IBM’s radar by also requesting a Request for Enhancement.

Despite IBM’s unwillingness to enhance (or even support) VisualAge RPG, we are continuing to develop new applications that utilize it as we see fit. End-users and upper management want to see results. VisualAge RPG delivers an intuitive user interface with a fairly modern RPG IV syntax and it allows our users to get their jobs done more effectively.

While we are considering other modernization strategies, VisualAge RPG still plays a key role in our shop for developing and maintaining mission-critical applications. IBM has continued to support and enhance RPG IV. Unfortunately, VisualAge RPG got left behind. Maybe IBM will surprise us and introduce a “Technology Refresh” in their next release of RDi, which will include a revamped VisualAge RPG. Am I dreaming? Perhaps, but if enough Request for Enhancements are submitted, maybe IBM will re-evaluate their decision and revitalize VisualAge RPG.

Dan Devoe has been developing applications on IBM Power Systems (formerly AS/400) for over 20 years. He has worked in the transportation, software development, manufacturing, and wholesale distribution industries. Presently, he is Senior Systems Analyst /IT Manager at Boston Warehouse Trading Corporation in Norwood, Mass. Visit Dan’s LinkedIn page at dandevoe.com