Midrange Stuff, OS/400 Edition

RPG programmers, welcome to .NET. Come on in and get comfortable. Those are pretty much the sentiments ASNA would like to pass along to application developers troubled by what many consider a dead end for their RPG skills and perhaps their jobs. On August 24, ASNA begins rolling out AVR for .NET, an avenue of opportunity, the company says, for RPG programmers and companies with big investments in that language and in their employees who are proficient in it.

Maintaining the familiarity of the RPG language and its data access methods is one of the keys to an easy transition to .NET, says Eduardo Ross, vice president of ASNA research and development. By side-stepping the need to learn new languages and data access methods, programmer productivity doesn't flatline like it could when new language skills are mandatory. Another key is the capability to reuse RPG code in the .NET environment. Exactly how much code will be automatically ported to .NET is difficult to pin down, as it will vary with each circumstance. But suffice it to say that it's enough code to make it a legitimate consideration in even the worst-case scenario. (ASNA is readying a new tool, with a planned release in September, that the company says will "translate nearly all user interface independent business logic without issue." ASNA calls the tool Importa, and it will be sold separately from AVR for .NET. You can find out more about it by viewing the July/August issue of the ASNA Visions newsletter.)

ASNA Visual RPG, more commonly referred to as AVR, has gained acceptance in large part because of its similarity to RPG. It has continually gained ground as AS/400 and iSeries shops look for ways to build Web and Windows applications while avoiding Java and WebSphere. AVR 4.0, before the introduction of AVR for .NET, was the latest version of that strategy. The development environment in AVR 4.0 was always above average, but not on a level with the major development languages. That changes with the integration of Visual Studio .NET. AVR development now enjoys a leap forward. Although lacking some of the polish of Microsoft's proprietary languages Visual Basic and C# as it comes out of the gate, AVR is on nearly equal footing across the board.

As an example, Ross says, "You're much better off using C# to render fractals or perform scientific calculations, but RPG makes it easy to deal with database files and tables, so if you want to build a library operating on such files, it's much easier and more efficient to write it in RPG. Visual Basic doesn't have a construct saying, 'get me the next row.' You have to use a database access library like ADO, and the compiler can't help you. RPG and COBOL, on the other hand, have database access built directly into the language." Fast record-level access to the AS/400 database, a compatible stand-alone database, or SQL Server is built in with ASNA's own DataGate Component Suite for .NET.

Brian Bunney is director of the .NET division at Packaged Business Solutions, a consulting company with AVR development experience. His OS/400 experience dates back to the System/38 and the introduction of the AS/400. From his viewpoint, the syntax for AVR 4.0 and AVR for .NET is very close to RPG. "As far the language goes," Bunney says, "it is a pretty easy transition from one to the other." The differences RPG programmers will face, however, is in the underlying aspects of the .NET platform. "In .NET," he points out, "you have a total object-oriented environment. AVR 4.0 is close, but is not 100 percent object-oriented, like it is in .NET."

Programmers familiar with AVR will have a better understanding of object-oriented programming, which helps a great deal when going to .NET. It puts them on the same learning curve that a Visual Basic or C# developer goes through while learning the integrated development environment and the underlying .NET framework.

"If the person is coming from the AVR model," Bunney notes, "the learning curve is shorter because it skips over the initial culture shock of moving to a PC platform. Your whole train of thought changes when developing on the PC as opposed to the '400." For RPG programmers, that means learning the nuances between OS/400 development and PC development.

"Part of the learning curve is taken care of for those who have gone from OS/400 to AVR. Handling event-driven and object-oriented programming, dealing with controls on forms . . . they already know all that. Transitioning that knowledge into .NET is easier for those programmers than for those who make the move from OS/400 to .NET, Bunney says."

"The .NET framework is very easy to pick up," says Bunney, "but I have a PC background as well as an OS/400 background."

One thing RPG programmers will face is that subfiles are implemented with a data grid in .NET, and the grid is populated differently than a subfile is populated in RPG. The logic in the subfile has to be manipulated to fit into the new environment. Despite this unfamiliarity in handling subfiles, Bunney notes there are strong ties between the .NET environment and the OS/400 environment. For instance, you can still call OS/400 programs and CL programs, and the operations code used for access to the database is going to be familiar.

The basic foundation when programming in .NET is called a class. It is necessary to understand how classes work, how they are set up, and how to access other classes. RPG code resides in a class. It could be ported from an iSeries; however, because of the class structure, it will limit the amount of code that comes across. Still, the coding of the logic is not going to be foreign to an RPG programmer.

"Rather than one program on the '400 with a display file that contains the business logic, you now have two or three parts that are separate," Bunney says. "They may not even run on the same PC, but they have to talk to each other. OS/400 programmers have to wrestle with these concepts."

Jeff Cubinski has been building applications in AVR 4.0 for a little more than a year. He is president of JTS Technology, a consulting group based in Germantown, Wisconsin, a suburb of Milwaukee. Cubinski comes from a System/36 and AS/400 background, which serves him well while working on a contract basis with the Milwaukee area YMCA, where OS/400 applications are being converted to Web applications and database changes are part of the long-term plan.

Cubinski has worked with a beta copy of AVR for .NET and is already close to implementing his first application that will integrate information from PC and AS/400 applications. The goal of this application is eliminating manual steps and duplicate procedures in processing member access cards. Previously, information was input on a PC and the steps were repeated on the AS/400. All data and pictures will now be stored on the AS/400, instead of on two different systems. This application went live on August 15.

Eventually, Cubinski says, he will build an intranet Web site, so YMCA staff will have access to all AS/400 legacy data for data extractions and reporting.

While both Bunney and Cubinski have made the transition from RPG to AVR, some programmers are going to wonder if it is any different from making the transition to Java, a move that has never gained a great deal of traction among the RPG clan.

"Java is a completely new and unrelated language for the RPG programmer, Bunney says. "With AVR for .NET, the RPG guy already knows the language, the syntax, and the operations code. It's RPG. AVR for .NET is a language-familiar environment, and once you learn the environment you can be very effective and create apps very quickly.

"Plus, you can develop applications five to 10 times faster in .NET than you can in Java." He says this is true because the language environment is so accommodating. "It does so many things for you that otherwise would require coding in Java."

Using subfiles as an example, Bunney points out that, before .NET, it used to require coding all the fields, defining them in the DDS, and moving the database fields into the fields in the DDS. "With .NET, you don't worry about all that. With the database grid, you can attach the file to it and it's done."