The Lowdown on S/36 and S/38 Compilers in i5/OS V5R5
April 10, 2006 Timothy Prickett Morgan
|
Since the end of January, I have been trying to get the official details on exactly what IBM was planning with regard to the System/36 and System/38 compilers in the WebSphere Development Studio application development tool. I hooked up with George Farr, technical development manager for System i development tools at IBM’s Toronto software labs, late last week and he explained the situation to me. As I have previously reported, with the January refresh of the i5/OS platform and the Power5+ System i5 machines, IBM put a statement of direction at the end of the i5/OS V5R4 announcements that has caused some anxiety among many OS/400 shops. Specifically, IBM said that support for certain compilers that were created for the System/36 and System/38 predecessors to the AS/400-iSeries-System i line were on the way out. WebSphere Development Studio for iSeries V5R4, in fact, will be the last release to ship with the RPG II and COBOL compilers that are compatible with the System/36 and the RPG III and COBOL compilers that are compatible with the System/38. Back in January, IBM said that customers who have deployed System/36 and System/38 applications in the S36EE or S38EE emulation environments should switch to ILE RPG. IBM did say that these old compilers would be available as a non-warranted PRPQ in the next release of i5/OS. This, as you might imagine, made some AS/400 and iSeries shops pretty nervous. This announcement begged this question: if the compilers don’t support these S/36 and S/38 environments, will the operating system itself? Jim Herring, director of product management and business operations for the System i line at IBM, said at COMMON two weeks ago that IBM had no plans to discontinue the S36EE emulation environment; Herring said nothing about the S38EE environment. Farr last week explained what IBM was doing and why. “The S/36 and S/38 compilers will be pulled out of the next release, but the execution will remain the same.” At first blush, that seems sufficient, until you realize that even companies running RPG II and RPG III applications in the emulation environments that have been available in the AS/400 line since Day One have to make changes to their applications as their businesses evolve. It is hard to assess how much RPG II and RPG III code is out there in the OS/400 and i5/OS installed bases, and I would even venture to guess that companies themselves probably do not have a very good idea if they have a mixed RPG II, RPG III, and ILE RPG environment. Old applications persist, which is one of the reasons why the System i5 is here. “We want people to move to RPG IV,” explained Farr. “The fact that IBM is still shipping these old compilers is giving people the wrong signal. The bottom line is that we need people to move forward.” I find it ironic that last June, I heard two rumors, one that said IBM was going to pull the plug on RPG II and RPG III compilers in a patch to OS/400 V5R3 and another one that said IBM would do it with i5/OS V5R4. Farr assured me that this would not happen last June, and that is what I told you. But he did not say anything about future releases at that time. Whether the rumors from last year just garbled what would happen with i5/OS V5R5–if that is what the next release of the operating system will be called–or were just a coincidence is unclear, but my guess is that what IBM has planned for i5/OS V5R5 was originally planned for V5R4, but someone changed the plan between June 2005 and January 2006. I can’t prove that; it is just a hunch. RPG has a long history at IBM, starting out on mainframes in the 1960s and moving to the System/3 product in 1969 with the creation of RPG II. When the AS/400 was launched in June 1988, IBM grabbed the RPG III compiler and made three copies of it, and then it tweaked them to create the System/36 Extended Environment, the System/38 Extended Environment, and the RPG III native compiler for the AS/400, which was eventually called RPG/400 by the installed base. As the AS/400 evolved, this RPG III-RPG/400 compiler kept evolving, but with OS/400 V2R2 in February 1992, IBM loosened up RPG with ILE RPG, which was called that to fit with the naming conventions of the Integrated Language Environment marketing/technical initiative that IBM was talking about at the time, and this eventually evolved into the free-formatted, C-friendly RPG IV environment that debuted with OS/400 V3R1 in May 1994. Since that time, IBM has been trying to get customers to move out of the emulation environments and the S/36 and S/38 compilers to native RPG IV on the iSeries. Last summer, when I was chasing this story, Farr estimated that somewhere between 10 to 15 percent of the RPG applications running out there in OS/400 were running it the System/36 or System/38 emulation environments, with another 30 to 35 percent being written in RPG/400. The remaining 50 to 60 percent of applications are written in RPG IV. Last week, Farr did not want to give an update on how much old code he thinks is still out there, but he did say that there was a lot less S/38-RPG III code than there was S/36-RPG II code. Farr wanted to be clear that IBM was not removing the S36EE and S38EE runtimes from i5/OS, and he did not even want to think about when IBM might do this. But he did make it clear that if he had his way, companies would have all long-since moved to RPG IV and this would be a non-issue. But the fact remains that the viability of this older RPG II and RPG III code on any future releases is now called into question. But IBM understands that some companies, for whatever reasons, cannot make a move. And that is why the RPG II and RPG III compilers will be available in an unwarranted PRPQ. What I learned last week is that this PRPG will not only not have official support from IBM in the future release, but that it will also have a price tag. Farr did not want to be specific, but he said that it would have a tiered price, as a lot of i5/OS systems software does, and he also said that there was “a 100 percent chance” that the price would be north of $1,000. He also suggested that IBM might increase this price over time as a means of encouraging companies to move to RPG IV. Those companies who do need to develop and support RPG II and RPG III applications do, of course, have an option besides paying IBM for a PRPQ version of these compilers. They can buy an older box that still supports an older version of WebSphere Development Studio and give that box to their programmers. In fact, they can buy two of these cheap, and have a backup for the inevitable failure that old iron eventually has. (Yes, even AS/400 and iSeries disk drives eventually fail.) That way, developers can continue to tweak and change code on one box and then run applications in the S36EE and S38EE runtime environments on production machines–even those running i5/OS V5R5 and higher. Another alternative will be to keep an i5/OS V5R4 partition on the production box with an older version of WebSphere Development Studio on that partition, which would be used explicitly for RPG II and RPG III applications. Both of these approaches have the same problem, however: by staying back, you end up with a machine or a partition that is running software that is not supported by Big Blue. As I said last week, just because IBM doesn’t support RPG II and RPG III code inside WebSphere Development Studio, that doesn’t mean someone else can’t. I can imagine an open source RPG II compiler that snaps into the open source Eclipse integrated development environment. There are a number of companies who have the skills to create such a compiler. But, again, it is hard to imagine that it would be worth the effort unless the resistance to RPG IV is very great. Moving gradually but assuredly to RPG IV seems like the least disruptive course of action at this point. But, then again, I don’t have to port all that code, so it is easy for me–and IBM–to say that. One last thing. If IBM is willing to charge a premium in the near term for the S/36 RPG II and S/38 RPG III compilers, it most certainly is willing to someday charge a premium for the S36EE and S38EE runtime environments. In fact, I am a bit surprised that IBM didn’t announce that it will do this in the future i5/OS V5R5 release (again, if it is indeed called that). IBM has been willing to charge a huge premium for 5250 green screen processing capacity, and if IBM is serious about getting people onto RPG IV, then it stands to reason that eventually the company will put the S36EE and S38EE runtimes in a PRPQ and ask for money for it. RELATED STORIES IBM Sort Of Clarifies Plans for S/36 and S/38 Environments |
