RPG: A Rose by Any Other Name ...

Today’s IBM i 25 chapter begins by musing about the meaning of RPG’s name. In one of our earliest blog posts back in July 2007, we blogged about the name of the RPG language and whether it should have a new one to match its new personality. We had suggested “Borg” since RPG seems so good at assimilating the best features from other languages. Many of you offered alternative suggestions.

In reading today’s anniversary chapter, Susan learned something new—although Jon claims he knew it long ago. When RPG IV was introduced, the name “RPG” was officially declared to be no longer an acronym—or, more correctly as Scott Klement pointed out recently, an initialism. For those who didn’t realize this, to be an acronym, apparently it must be pronounceable as a word, such as NATO. If it is simply spelt out, as RPG is, it’s technically an initialism.

While the letters RPG may not officially stand for anything any more, RPG, the language, means a great deal to many thousands of programmers around the world and the users of their rock-solid, efficient, modern business applications.

In many ways it’s a good thing that RPG no longer stands for “Report Program Generator” because it has been many, many years since RPG’s primary function was reporting. It has evolved radically over the years.

If the picture that comes to your mind when you think of RPG is of columnar logic with multiple conditioning indicators and nary a hint of SQL, it’s time to wake up, Sleeping Beauty—you’ve missed a lot in the last 25 years. IBM i’s modern RPG IV is barely recognizable as a relative of the AS/400’s original RPG/400.

Today’s RPG logic is written in free format. It also utilizes libraries of homegrown, open-source and third-party functions in addition to RPG’s own library of more than 70 BIFs (built-in-functions). As a result, what would have been dozens of lines of indicator-laden, columnar “old-style” RPG are replaced by simple, powerful expressions.  And RPG’s data access has “grown up” too. Support for a huge variety of native data types and a deeper level of integration with SQL than is seen in almost any other language makes RPG a natural partner for IBM i’s integrated DB2 database.

Still think that RPG = Green Screen? Think again. Many shops are running interactive Web and mobile applications with logic powered by RPG. Or if you prefer, RPG code can easily provide the business logic underpinnings of Web services, stored procedures and other services to applications written in PHP, Java, Python, Ruby, .NET, etc.

Inevitably there are things that RPG doesn’t understand natively and that IBM cannot add to the language in a meaningful timeframe. The pace of change in today’s IT world is just too fast. That’s why Open Access was recently added to the language. It allows for the development of drivers to add new functionality while maintaining RPG’s powerful data marshaling capabilities. For example, you can write a driver to call a currency conversion Web service from RPG, allowing any RPG program to treat access to real-time currency conversion data as if it were a huge database in the sky. Simply set the key values for the currencies involved and issue a CHAIN operation. The conversion rate is returned as if it were being retrieved from a database column.

In our next EXTRA article, due out in the next couple of weeks, we’ll take a look back at 25 years of RPG. We’ll post the link in the comments section here when it’s available, so check back if we’ve piqued your interest. Or follow us on Twitter @JonParis or @SusanGantner.

And don’t forget to join in the celebration with all 25 chapters leading up to IBM i’s 25^th  birthday at  http://bit.ly/ibmi25.

In the meantime, it seems a shame to waste a perfectly good initialism as RPG. Maybe we could unofficially assign one—or a few. How about Renegade Programming Gurus? Robust Programming Genus? Real Problems Gutted?

 

 

How Old Is Your OS?

If your shop is at V5R4, then hopefully it comes as no surprise to you that regular software maintenance (SWMA) for V5R4 ends September 30 of this year. Lest you find yourself thinking, “But we need more time - why doesn’t IBM extend that deadline?” please note that this IS the extended deadline. V5R4 has been supported years longer than earlier releases for various reasons.

If you really can’t move to 6.1 (or 7.1) by September and must still have support, IBM announced last week the ability to purchase service extension for up to three years. Your support cost will be increased and over regular software maintenance. Hopefully this will help to serve as an incentive to move to a currently supported release (at last!). If you want more details about the extended support, take a look at the IBM announcement. Another document with some additional details is here, along with details for the service extension support for V5R3.

“V5R3?!?” we hear some of you saying. There are many reasons/excuses for not moving beyond V5R4 as we have explored before but surely anyone could have moved to at least V5R4 by now, right? Apparently not.

As a matter of fact, we recently talked with an ISV who has customers whose systems are still at V3R7! Not many fortunately, and the ISV’s software is not supported at that release. But they do know of a much larger number of customers who are at various release levels between V4R2 and V5R3.

Now, as surprised as we were to find evidence of V3R7, we’re sure this isn’t a record. We’re confident that some of our followers probably know of (perhaps even work at) shops earlier than V3R7. So there’s your challenge: In the comments below, let us know of the earliest active version of OS/400 (it was stilled called that in those earlier releases) that you know about.

 

 

 

Looking Back on 25 Years

 

 

 

 

 

 

This week we return to the subject of the IBM i 25th birthday bash with some more personal reminiscences.

One shared memory is of the first time we met Malcolm Haines in the U.K. before he moved to a marketing role in the U.S. We had heard about Malcolm's incredibly successful Graffiti campaign in the U.K. and while doing a one-day event in London had asked our hosts if they could introduce us.

Long story short--we had a fascinating meeting with Malcolm (the first of many) and arranged to get some copies of the advertising collateral sent to us to help inspire the troops back home. It is amazing to us looking back to realize how powerfully these messages still resonate.

One example: "Shouldn't the system run without an army?" is every bit as relevant today as when it was first used. In fact you might ask why IBM isn't still using it, but we digress. You can see images of three of the posters used in the campaign on the IBMi25 Facebook page but since you have to dig through the "Recent posts by others" to find them, Trevor Perry also posted them here.

Jon's Memory Dump--Breaking Things

It never occurred to me that quite a lot of my work on the compiler would be spent "breaking" it! Why? Because the new S/36 compatible compilers had to mimic the behaviour of the originals. But the original compilers were written in assembler and, due to memory limitations, took quite a lot of shortcuts en-route to the executable program. Often memory patching techniques were used to ensure that a particular path was followed if certain conditions existed. The problem was that the compiler writers often made the assumption that one of a finite number of alternative paths would have been set up and therefore (assumedly to save a few bytes) had not coded for the possibility that the programmer might have managed to code something that fell through gaps in syntax validation and resulted in a "none of the above" condition. Some of the time this would cause an error to be signalled later in the process, but it was not uncommon for it to produce an executable program. Just not one that the compiler writers had even intended.

So why does this cause problems? Well one of the first lessons I learnt when working with compilers was that by the time we discovered that we had a compiler bug, at least a dozen programmers had decided it was a new "feature" and were using it in production code. Sometimes the bug had the potential for causing significant problems and so we fixed it and dealt with the fallout. More often we had to retain the aberrant behaviour and sometimes allowed the programmer to specify that they wanted the correct behavior via a compiler option. In the case of the S/36 compilers there was a lot of aberrant behavior--some of which was even documented. So we had to do our best to "break" the correctly working compiler code (which was based on the S/38 compiler) and modify it to make the same mistakes that the real S/36 compiler had made. This wasn't always possible but we tried.

Susan's Memories of Rochester, Minn.

I mentioned in an earlier post that I became fascinated with the AS/400 before it was AS/400--back when it was code-named Silverlake in the Rochester lab. After spending a few weeks on residency in Rochester and then several months traveling around the world teaching IBMers about the system-yet-to-be-named, my fascination turned into an obsession. I was more convinced than ever that the developers in Rochester were the smartest people I'd ever hope to spend time with.

But I grew up in the South--in South Carolina and Georgia --I had rarely even visited parts of the country where snow covers the ground for months at a time. Was I obsessed enough to actually move to Minnesota to be around the home of AS/400? Apparently so.

Some of my friends enjoyed laughing at my attempts to buy a snow shovel after moving to Rochester (saying to the sales person when asked what kind of snow shovel I needed, "there are different kinds?"). But I did manage to live there, snow shovel(s) and all and I loved it--not the weather, but the place and the people. By the way, it's May 1 today and I see that Rochester is expecting around 4 inches of snow tomorrow. You definitely don't move to Rochester for the weather!

I worked in the AS/400 Technical Support Center in Rochester, the home of one of my heroes in the community at the time, John Sears. I found that John was indeed inspiring but there were many others in Rochester--in the support center as well as in the lab--who were equally inspiring, the many unsung heroes toiling away in the background creating amazing software. I found it impossible to be there and not be impressed at the brilliance housed in all those blue buildings (and the white buildings across the road).

My office happened to be just a few doors down from the ITSO--the group responsible for the famous Redbooks publications. As interesting as the Redbooks they wrote were, they didn't hold a candle to the experience of working with the people who wrote them. Technical field staff (aka SEs) from IBM offices all around the world came to the ITSO for extended residencies or multi-year assignments to dig into the new technologies being implemented by the developers nearby and make them practical for use by mere mortals. It was like working next door to the United Nations. I met and worked with people from places I barely knew existed and found kindred spirits from around the globe--all united by a similar obsession with (in the immortal words of Malcolm Haines) "the best computer a business can buy."

Some of the international assignees from the ITSO found a way to stay around after their assignments and have gone on to play important roles in the life of the system and the community. Perhaps the most recognizable name today from among those is Ian Jarman. Now, where have we heard that name before?

 

Back to the Future with RSE

If there's one thing that folks in the IBM i community love, it's a name change, right?

Well, here's one that we never thought we'd see - one that puts us back to where we were a few years ago. Nope, IBM i is not changing its name to iSeries or AS/400 (but that would have been a good April Fool's joke a few weeks ago, wouldn't it? Wish we had thought of that.)

We're sure you have all followed carefully the progression of packages and names for the Eclipse-based development toolset from WDSC (WebSphere Development Studio Client) to RDi (Rational Developer for i) and then to RDP, or RD Power as some prefer (Rational Developer for Power Systems). 

We're kidding of course. From the number of questions we get personally and see on forums, Internet lists, LinkedIn groups, etc., the litany of names has been a big source of confusion for many.

Guess what--we're going back to RDi again. Rational Developer for i. They've added "RPG and COBOL Tools" to the end of it, but still, it would seem that V9.0 (for those who have lost count, the current version is V8.5.1) will be called Rational Developer for i - or, we presume, RDi for short, as before.

We haven't seen any information yet on pricing, but we're hopeful that there won't be a significant increase beyond perhaps the (sadly) all-too-predictable 15% that seems inevitable with each turn of the crank.

As far as enhancements to function for IBM i RPG and COBOL developers, we haven't seen a lot. It appears that IBM Data Studio is now packaged with the new version vs being a free download that you could install yourself at 8.5.1.

Also listed are "Significant improvements to Remote Systems Explorer qualities of service." This sounds like lawyer-speak for bug fixes. We hope we're wrong but don't hold your breath. Then again, bug fixes would also be welcome.

There are two new packages, in addition to the basic RDi package:

1) Rational Developer for i RPG and COBOL + Modernization Tools, Java Edition - this would appear to replace the Rational Developer for Power Systems Software Power Tools for i.

2) RPG and COBOL + Modernization Tools, EGL Edition - this would appear to replace the oddly named RDi SOA toolset, which never changed to RDP when all the similar products did, for some reason.

From what we understand, if you have Rational Developer for Power Systems (what we've referred to as RDP) and have an active SW maintenance agreement, you will be entitled to a no charge license to the V9.0 RDi package. Someone reported on the WDSC-L list on Midrange.com that it will require a new Activation Kit to be used to install it, however.

Likewise, if you have a license to the RDP Power Tools, you're entitled to V9.0 RDi  + Modernization Tools, Java Edition, and if you have a license to RDi SOA, you're entitled to V9.0 RDi  + Modernization Tools, EGL Edition - both assuming active SW maintenance, of course.

So is all this good news, bad news or no news?

Until pricing is clear and, of course, we see how well the actual V9.0 code performs, it's hard to say. The new packages do seem to more accurately reflect what people really need. AIX/Linux developers have their own product and IBM i folks have RDi - as we did before. If you want/need more significant Java and/or EGL support, there are additional features for that.

Anything that simplifies the ordering process is a step in the right direction of course. But will the Rational reps stop trying to write up orders for RAD when IBM i shops call to get "Rational" to develop their RPG code? We can but hope! 

Back to the Future with RSE

If there’s one thing that folks in the IBM i community love, it’s a name change, right?

Well, here’s one that we never thought we’d see - one that puts us back to where we were a few years ago. Nope, IBM i is not changing its name to iSeries or AS/400 (but that would have been a good April Fool’s joke a few weeks ago, wouldn’t it? Wish we had thought of that.)

We’re sure you have all followed carefully the progression of packages and names for the Eclipse-based development toolset from WDSC (WebSphere Development Studio Client) to RDi (Rational Developer for i) and then to RDP, or RD Power as some prefer (Rational Developer for Power Systems Software).

We’re kidding of course. From the number of questions we get personally and see on forums, Internet lists, LinkedIn groups, etc., the litany of names has been a big source of confusion for many.

Guess what - we’re going back to RDi again - Rational Developer for i. They’ve added “RPG and COBOL Tools” to the end of it, but still, it would seem that V9.0 (for those who have lost count, the current version is V8.5.1) will be called Rational Developer for i - or, we presume, RDi for short, as before.

We haven’t seen any information yet on pricing - we’re hopeful that there won’t be a significant increase beyond perhaps the (sadly) all-too-predictable 15% or so that seems inevitable with each turn of the crank.

As far as enhancements to function for IBM i RPG and COBOL developers, we haven’t seen a lot. It appears that IBM Data Studio is now packaged with the new version versus being a free download that you could install yourself at 8.5.1.

Also listed are “Significant improvements to Remote Systems Explorer qualities of service.” This sounds like lawyer-speak for bug fixes. We hope we’re wrong but don’t hold your breath. Then again, bug fixes would also be welcome.

There are 2 new packages, in addition to the basic RDi package:

1) Rational Developer for i RPG and COBOL + Modernization Tools, Java Edition - this would appear to replace the Rational Developer for Power Systems Software Power Tools for i

2) RPG and COBOL + Modernization Tools, EGL Edition - this would appear to replace the oddly named RDi SOA toolset, which never changed to RDP when all the similar products did, for some reason.

From what we understand, if you have Rational Developer for Power Systems (what we’ve referred to as RDP) and have an active SW maintenance agreement, you will be entitled to a no charge license to the V9.0 RDi package. Someone reported on the WDSC-L list on Midrange.com that it will require a new Activation Kit to be used to install it, however.

Likewise, if you have a license to the RDP Power Tools, you’re entitled to V9.0 RDi + Modernization Tools, Java Edition, and if you have a license to RDi SOA, you’re entitled to V9.0 RDi + Modernization Tools, EGL Edition - both assuming active SW maintenance, of course.

So is all this good news, bad news or no news?

Until pricing is clear and, of course, we see how well the actual V9.0 code performs, it’s hard to say. The new packages do seem to more accurately reflect what people really need. AIX/Linux developers have their own product and IBM i folks have RDi - as we did before. If you want/need more significant Java and/or EGL support, there are additional features for that.

Anything that simplifies the ordering process is a step in the right direction of course. But will the Rational reps stop trying to write up orders for RAD when IBM i shops call to get “Rational” to develop their RPG code? We can but hope!