RPG to .NET Reduces Maintenance Pain, Adds Rich User Interface
February 5, 2008 Dan Burger
|
Like driving with the parking brake on, some business applications put the skids on productivity. Steve Stenglein, the IT director at United States Warranty, could feel the drag that green-screen applications were causing. He’s a big fan of the IBM System i and a skillful RPG programmer, but his staff is small and their time is tightly budgeted. Aging applications required a lot of maintenance and replacing green screens with a graphical user interface was a priority. He knew modernizing apps would not be easy. Most would agree that the most difficult, most time consuming, and most expensive way to reach application modernization is to take on a complete rewrite. “A lot of places get in trouble when they decide to rewrite everything and roll it out in an extended period, maybe two years,” Stenglein says. “Guys loose control of projects that are that large in scope and they go down the drain. I wasn’t looking to do that to the organization or myself.” Stenglein came to that conclusion after spending a little time with Java and WebSphere, which IBM was promoting as the best application roadmap for iSeries shops to follow. IBM’s alternative for companies not interested in Java/WebSphere was WebFacing, but Stenglein discarded that option as a dead-end along with other screen-scrapper options. Eventually he found his way to ASNA. “I chose ASNA because I believed it was a lower learning curve than what IBM was pitching, which was Java/WebSphere,” Stenglein says. “The reusability of the RPG syntax and callable routines that exist in the ‘400, plus all your business rules logic, makes this job (application modernization with ASNA products) easier than trying to reinvent the wheel. In the size of installation we are, you don’t have the option of throwing everything out the window and taking on a project that in three years we will deliver something completely different.” Easier is better, but it didn’t mean there wasn’t going to be some heavy lifting involved when converting RPG green-screen applications This has been an incremental program that Stenglein and one other RPG programmer began eight years ago. ASNA’s Visual RPG product was U.S. Warranty’s bridge from green screens to Windows and Web applications. The approach was to proceed in gradual phases. Green-screen applications that required heavy maintenance were made a priority and moved to the Windows side first. “Doing it in pieces allowed me to see as I went that it was going to scale incrementally and it was going to work. I also found that I could use a bunch of existing AS/400 code along the way,” Stenglein says. Starting with the ASNA Visual RPGtools and converting applications in stages helped Stenglein get a grasp on the modernization process and become comfortable working in a new environment that was close enough to his RPG ILE world to make the transition easier than a leap to the Java side. “I’m not a risk-taker by any stretch of the imagination,” Stenglein says. “But when you ride the ‘if it ain’t broke, don’t fix it’ mentality too long, you end up with software that is so old it puts you in a bind.” About a year ago, Stenglein upgraded from ASNA Visual RPG (also known as AVR Classic) to Visual RPG for .NET. After years of experience on the Windows side, he was feeling confident in that environment and was thankful to be relieved of the heavy maintenance load that had bogged him down during the green-screen days. “Getting out of the monolithic environment that exists in the AS/400 gets you a much more granular set of software in little itty-bitty programs that I reuse during Windows or Web development,” Stenglein says. Compared to the AS/400 development world where duplicate code is a part of so much old software, this seems far more efficient in his mind. Maintenance tasks are much simpler. “You don’t need to be a five- or ten-year systems guru to figure out what’s going on and where it’s going on. It’s all going on in one place, you change it, and it works for Windows or Web.” By now you probably realize that Stenglein is the kind of IT director who works in the trenches and is up to his elbows in programming. He has a couple of programmers working with him and a contract employee, too, but he makes IT decisions based on his experience of actually swimming in the shark-infested waters. “In the past year we have been upgrading the Classic stuff (ASNA Visual RPG) to the .NET environment, which is a different ball game in terms of sophistication and growth,” Stenglein says. “I played with the product (Visual RPG for .NET) on nights and weekends when I first got the compiler and I got somewhat proficient.” The ease with which Stenglein picked up on RPG for .NET had something to do with his previous experience with Visual RPG and some training at the ASNApalooza user conference. He went on to teach Microsoft .NET to the other programmers at U.S. Warranty. “The programmers do maintenance tasks as well as new stuff, and support different aspects of the business, but they all do .NET, and they still do some green screen. We were all green-screen guys at one time and we’ve morphed into .NET guys.” “Morphed” is a good way to describe it. “I was no .NET guru when I was three months into it,” Stenglein says, “and I still am not a guru, but I’m pretty good. You have to become productive quick in a small installation or it doesn’t work.” To go from green screen to Windows, which was the first phase in the project involving Visual RPG required, as Stenglein puts it, “some brute force work to be done.” Anyone who says an application modernization is a walk in the park isn’t being 100 percent honest. But, as Stenglein points out, with experience comes an accumulation of templates that make the continuing development much easier. To port applications from AVR Classic (Visual RPG) to .NET is a comparatively easy operation, Stenglein says. He uses a utility that converts 85 percent to 90 percent of the Classic source code to .NET source code, leaving him with the simple matter of “going in and fiddling with it some.” As a hands-on programmer kind of guy, it sounds as if he actually enjoys the fiddling part. It’s worth noting, but it should come as no surprise, that upgrading from Classic to .NET is an easier step than moving from green screen to .NET. That’s part of the incremental nature of the U.S. Warranty project that Stenglein talks about as being valuable. However, there are many situations that arise in application modernization projects and painting them all with the same broad brush would be inaccurate. Different situations will require varying amounts of effort. Last week when I spoke with Stenglein, he was porting a green-screen application to.NET, but the process did not involve a user interface. “It is really just cut and paste and fiddle with the code and it runs in an hour or two, so it’s not too bad,” he said. According to his estimate, U.S. Warranty, an insurance company based in Pampano Beach, Florida, has moved about 90 percent of its applications that involve a user interface to Windows. That still leaves a hefty portion of U.S. Warranty’s applications running on the company’s iSeries Model 520. “We have kept most of our report-type programs on the iSeries,” Stenglein says. “There is nothing to be gained by updating end-of-the month jobs or night jobs that are batch jobs. Those have all stayed in green screen. It doesn’t buy me anything to swap those. I’m not getting a user interface out of that. If you have a program that reads a million records and updates 50,000 of them, it will do the same thing in green screen as it does in Windows.” Stenglein intends on keeping the iSeries for a long time. Its reliability has made a big impression on him and he says he’s not ready to rely on PC servers as database servers. “Bill Gates will tell you the PCs offer a level of reliability that matches the iSeries, but my experience tells me they don’t. I have a PC server that will just reboot on its own in the middle of the day for no reason. It’s a 2003 server with the latest service pack; the machine is a year and half old. Nobody can tell me why it does that. But I can tell you that you don’t want your business centered around that.” As for the finicky PC server, Stenglein says he doesn’t use it in conjunction with application software. “We deploy our DLL files to a Windows server. Then when the employee requests info on a desktop, it goes to the Windows server and downloads all the DLLs to the local desktop. Then it is all running local on the PC. So even if the Windows server flakes out,” he says, “it has no effect on people working on their desktops until they needed updated software. But if we are not changing anything, it doesn’t come into play. The desktops can continue to work through a server crash.” U.S. Warranty has approximately 65 people on this system and Stenglein believes 100 more could be added without any degradation as long as the iSeries could serve the data fast enough. Returning to the topic of application maintenance, which was a pain point when the applications were all RPG green screens, Stenglein says “we are more productive as programmers because maintenance tasks are simpler. And because of the reusability of code between the Windows and the Web side–where there aren’t different versions of this and that–it becomes faster to change things. “We can deploy software in the middle of the day compared to having to deploy it at night when we were using the ‘400. Now if there’s a code modification that just affects one or two people, we can put it on the server, tell the users to get out of their executable and relaunch it, and they have the new copy. The other people are running locally on their PCs from their prior download (refresh) from the server. This makes it easy for us to deploy or rapidly make changes.” In short, Stenglein sums up his conversion from RPG to .NET by lauding it for its simplification of many programming and maintenance tasks. “Smaller equals better,” he says. “Complex equals nightmare.” This article has been corrected. U.S. Warranty is based in Pompano Beach, Florida, not Cleveland, Ohio, as reported in the original article. IT Jungle regrets the error.
|
