RPG In Isolation
I was going to discourse on another topic, but a response to Buck (to whom I apologize, along with Bill, for being derelict in checking my site’s e-mail), who commented on my previous post, demands a reply. He feels that lack of formal education, while being a contributing factor, is only a contributing factor; rather, it is the midrange habit of being exposed to one programming language.
Actually, I am inclined to agree. The isolation in RPG is real. But we also do well to consider the background of the situation. The earliest IBM minicomputers, the System/3, had as its programming language RPG II. That was it. Small businesses who wanted that computer worked in that language- at least, I’m not aware of others used on the machine, besides assembler.
When the System/34 came out in 1977, the choice of compilers widened. BASIC, COBOL, and Fortran became available. But still, RPG dominated. I’m not surprised that Fortran and BASIC popularity did not rise. But COBOL was big at the time. However, RPG was already a business-oriented language, so COBOL was not really needed from that standpoint, and RPG was perhaps felt to be more terse and easier to learn. Then too, COBOL programmers were already being kept busy keeping the IBM mainframes humming, so there were probably not an excess of them floating around. COBOL has never been much more than a peripheral language on the IBM midrange; useful probably only to those whose business already depended in some way on COBOL, perhaps having COBOL talent already available.
In addition, and perhaps most important of all, The System/34 had no need to talk to the outside world unless it were to another IBM minicomputer or mainframe. There was no need to handle HTML; there was no HTML, because there was no Internet.
This is not to say that RPG was a perfect language. String manipulation beyond the realm of MOVE and MOVEL was very difficult. The two things the designers never got right until RPGIV came along were string manipulation and date arithmetic- being able to get the date 30 days after today, for instance. (One thing I will never comprehend is why they have never been able to enable multiple dimension arrays. In earlier days in a different environment, trying to emulate multiple dimension arrays was a real pain.)
But since the programmers had no other languages to work with, they bent RPG to their will. They created these plug-ugly array- manipulation routines to piece together strings. And they created complex routines to do date addition and date format conversion. We must not forget the famous “magic numbers” - to convert a date in month-day-year for mat to year-month-day, for instance:
MMDDYY MULT 10000.01 YYMMDD. I am still reminded of the RPG programmer of my acquaintance who, with the help of engineers, created sines and cosines and other functions in RPGII.
Now, there may have been elegant functions created in C for such purposes as string manipulation and mathematical functions. But once RPG routines were developed, the C functions were not needed. It really didn’t matter. They couldn’t use C anyway. If you knew what you were doing, you could write assembler subroutines – but that was it. I don’t think RPG couldn’t even call COBOL programs; at least the techniques were not well known for doing so.
So when ILE came around, much of the motivation for calling the now-available C routines was missing. We didn’t need them. RPG routines were already doing the work. Unless there were some performance considerations, programming managers would probably take a dim view of programmers who ripped out the ugly-but-tried-and-true RPG routines just for their own amusement. One could make a valid argument that those routines were a maintenance nightmare. But unless management had a good deal of foresight, this might be a difficult thing to prove to management’s satisfaction.
And yes, programmer inertia was also a factor. My shop has had IBM midrange machines since the 1970’s, and AS/400s since the 90’s. But the first RPGIV program was written on this system in 2007, by me after I arrived.
But now, the IBM midrange does have to deal with the outside world. My company already has an Internet presence, and we quite frankly don’t have to know PHP or Java or the other languages in vogue in order to make the business work. All we have to do is make sure our Internet provider gets the necessary data. And RPGIV provides the necessary tools to alleviate some of the issues that plagued us with earlier versions of RPG. If we need outside routines like APIs or C or Java or Rexx, they are easy enough to call. I have expressed myself in earlier posts about my ambivalent feelings about freeform RPG.
But mentioning freeform brings us to the topic of: How do our employers find replacements for us fixed-format loving old codgers when we retire? That is a topic for another time.
November 10th, 2009 at 1:54 pm
No doubt the success of RPG in the S/3 days left us with a glut of pre-existing home grown tool kits written in RPG. Tool kits that got converted again and again and are still in use today. How many RPG programmers just this year will learn to program in RPG by looking at that essentially 30 year old code?
As for replacing us geezers, I fear the answer is going to be a canned package on commodity hardware.
January 13th, 2011 at 3:38 pm
So (anybody!) if you were currently (Jan.2011) on a 10-year-old AS/400 and almost all your applications were written decades ago in RPGII and OCL, and you were probably going to move to a new box in the near future, what language would you pick to gradually migrate the legacy apps to? What is the “best” technology to be on? What has the strongest pool of available programmers?
RPG IV?
RPG ILE?
SQL & PHP?
.NET ?
There are few folks available now with RPGII skills, and my client really *must* get more up-to-date before I get hit by a bus! With their options wide open, I’m not really sure what to advise them.
January 18th, 2011 at 1:08 pm
We’re moving (however slowly) to RPG IV / ILE. I write stored procedures that the webby people can call to reach out and touch our database without them having to become intimate with it. Being able to do it in RPG is very helpful, as the debugging is easy to work with.
June 18th, 2012 at 10:46 am
I had a good five years of BAL (Basic Assembler) and a couple years of SabreTalk (PL1 + airline macros) before jumping over to IBM Sys 3, 32, 34, 36. From the start, BAL was re-entrant code, had enter-return and enter-no-return. I spent 20 years in RPGII before such options began to appear in RPGx. No real problem going mentally from BAL to RPGII. I always felt SabreTalk was clumsy and had poor diagnostics. The noticeable mental jump was going to the.AS400 (skipping Sys38). That took a little mental reallignment but soon became my favorite. I’m still seeing
ads for RPGII so I assume peeps are running it in emulation mode. I do convert.RPGII