Programming Highs and Tire Lows

Last week we experienced an interesting mix of high and low points.

The big high for us was teaching a class of Java programmers about the joys of RPG. We also spent a little time on RDi, but since they already used Rational Application Developer for their Java work that was mostly just to introduce them to the IBM i specific features.

Three things helped make this an enjoyable class to teach:

1. The students were all young--and we don't mean young in our terms (i.e., anyone less than 50) we mean young young.
2. They were all enthusiastic and asked the right questions, which clearly showed that they were not only understanding the language but also getting a feel for its power and simplicity. We'll be going back to complete their training later this year once the students have had a chance to absorb the initial lessons and we're looking forward to it.
3. This was our first opportunity to teach the new all-free-form RPG flavor of the language. While it was a lot more work to retrofit our teaching materials than we had anticipated (never thought about how many of the examples have F, D and P specs in them!), what a difference it makes when teaching RPG to Java (or C/C++/C# or PHP, etc) developers. Those pesky columns--even when just for data declarations--always caused so much consternation in past classes. This time, the only hitch was the occasional need to remind them that the code must start on or after column 8 and end at column 80.

This class has reaffirmed our belief that all too often, trying to replace your retiring RPG programmers with experienced RPGers is a waste of time. Not that there aren't good RPGers out there looking for work, but most are too expensive for companies are looking for junior to intermediate level staff. Either that or their "30 years of experience" is actually three years repeated 10 times over because they are so reluctant to learn new skills. Case in point--and one of the lows of the week--we had an email concerning a shop where the staff (we won't dignify them by using the terms "programmers", "developers" or "RPGers") are busily stripping out things like embedded SQL and prototyped program calls whenever they have to maintain a modern program because they can't be bothered to learn this "new-fangled stuff." They probably rue the passing of the tabulator and the punched card too. Sad, so sad. No wonder the shop is moving away from the IBM i.

The other high/low mixture of the week concerned our rental car. Very soon after we set off from the airport a low tire pressure warning appeared. We checked but the tire appeared to be fine. Given that rental car companies often do a lousy job of what would be the PDI (pre-delivery inspection) at your local car dealer we have encountered such false warnings many times before. We kept checking but despite the warning light the tire appeared fine. Until it wasn't. Suddenly it lost pressure so we took it to the local tire store to see if they could fix it. Nope. It had a side wall leak, which couldn't be plugged. No problem, they inflated the tire again and we called the rental car company. "Yes sir - we will happily exchange your car. Just drive to your nearest location and they will help you." Fine except only corporate locations would do and the nearest was a 90+ minute round trip away and it was already getting late in the day. It was a slow leak so hopefully it would last until the next evening when we could drive down and swap the car.

The next morning arrived sunny, hot and humid with the tire completely flat. Changing a tire while in work clothes and 95 degree weather had not been high on Jon's wish list for the day but. ...

Luckily that was the end of the lows. We drove the car back to the rental company and, to cut a long story short, the only replacement vehicle they had available was a Mercedes 350. Not a bad swap for a Chevy Impala! Only problem is that Jon is enjoying driving it so much that he wants to keep it. Sadly that is not on the cards but at least we get to use it for a few more days.

  

New Year Predictions

Some may think these are hopes more than predictions for the year ahead and in some cases we would have to agree.

1) Modernization clarified

The new Modernization Redbooks publication, which we have mentioned before, is due to be delivered in the first quarter of the year. It is in the proofreading stage right now. It is perhaps too much to hope that it will have as far reaching an impact as the earlier "Sorcerer's Guide" RPG Redbooks publication. Our hope is that this new publication will help RPGers realize the breadth of modernization options open to them and, perhaps most importantly, that there is no single right answer. Even more importantly, that the _only_ wrong answer is to do nothing!

2) RPG enhancements continue--perhaps more openly

We finally have a completely free-form version of our favorite language and we love it! But what about 2014? We wish we knew. Despite the fact that Rational is now quite open about its future plans for other products, the oganization remains very tight-lipped about future enhancements to RPG and RDi. By the time Barbara Morris was allowed to tell the world about the free-form changes she was just about fit to explode. Hopefully in 2014 Rational management will realize that the community has a lot to offer in assisting them in formulating their plans and will involve RPGers more in their planning.

3) An expanded audience for RPG education

The biggest change here is that free-form RPG will open the door to many younger programmers. We have introduced many Java/C++/PHP/etc. programmers to the joys of RPG and most love it. The one exception is that they find it _really_ frustrating when a whole bunch of errors suddenly appear when they do nothing more than simply delete a spurious character in a name on a D or F spec. Not to mention the myriad errors that occur when they forget to code /Free and /End-Free directives. Then there is the issue of having to remember the right letter and column to use in order to specify that a file is externally described or update capable! For those of us who grew up with columnar RPG it is no big deal, but imagine how frustrating it is if you are new to the language.

PHP, Java, and, now Ruby, open the doors to a new group of developers--and most like what they find. Let's hope that some of the plans being formulated to advance IBM i education around the world start to bare fruit.

4) SEU bites the dust

No, we are _not_ predicting that IBM will stop supporting SEU altogether. We suspect that may not happen in our careers. However, IBM did stop enhancing it for new language features back in V6. That wasn't that big a deal until the new completely free format RPG came onto the scene. Rational Developer for i has the only editor from IBM that understands and supports the free format F, D, H and P specs. If you want to use that new support and you don't like the idea of a completely reverse-image green screen full of errors, you had better not be using SEU.

We expect to see the trend of those moving from SEU to RDi taking another sharp rise in 2014, thanks to the new RPG format (or lack thereof). Of course, we've been telling people for years it's a superior tool for programmer productivity, regardless of IBM's support for other editors or languages. But, hey, if it takes a new RPG to bring people to a more productive toolset, so be it.

5) Ruby makes its presence felt

Only time will tell if the community will embrace Ruby as it has PHP but, with enthusiasts like Aaron Bartell behind it, there's certainly a good possibility. Unlike PHP however, Ruby does require that you completely embrace the OO model, but perhaps the community is ready for that now.

6) SQL growth continues

The last few years have seen a massive growth in SQL usage and we expect to see that continue. While we do not count ourselves in the "The answer is SQL. Now what was the question?" category that some SQL bigots seem to fall into, we do welcome this change.

Database modernization projects also seem to be proceeding apace and we expect this to continue as more and better tooling enters the market.

Summing it up

We could go on and add a whole bunch of other categories. Increased usage of Open Access handlers for tasks other than 5250 modernization for example. Or even more widespread use of free PHP tooling. But we have to stop somewhere and invite you to add your own predictions in the comments section.

Totally Free RPG

As you may have already heard, there was a major Technology Refresh (TR) announcement yesterday - check out fellow blogger Steve Will's You and i blog for a summary of the details.

Of course what we are most interested in, apart from the arrival on IBM i of Ruby on Rails, are the major changes that this TR brings to RPG. In fact they represent the biggest changes in the language since the V5 introduction of /Free form calculations specs. That said, it is likely that they will also be among the most controversial. No, it's not Object Oriented RPG--we're on record as saying we don't think that will ever happen. "It" is completely free form H, F D and P specs. That's right--with TR7 RPG becomes a completely free format language. Well, unless you still have a desire to use I and O specs, that is.

So why do we think it will be controversial? Well first of all there are always those who think that RPG enhancements are a waste of time because:
a) Fixed format was good enough for my grandfather, it is good enough for me or ...
b) If I want to write in a modern language I'll use Java/C++/PHP/whatever ...
c) Hardly anyone uses the "new" features like BIFs anyway so why add more ...

We expect those. It happens every time.

But this time there's an additional factor at play. The syntax. As you'll see from the short sample below it more closely resembles CL than (say) C or Java. But unlike those languages, that use curly braces to delimit blocks, RPG decided to stick with a declaration (dcl) based syntax, starting and terminating definitions with markers such as dcl-ds and end-ds. There were undoubtedly many reasons for doing this, not the least being that the compiler team did not want to add another syntactic construct to the language. Plus of course had they done so they would almost certainly have had to revisit the use of braces within the calc specs.

Yes, it may mean a bit more typing for some things, and RPGers as a general rule are famous (or is that infamous?) for their disdain for typing! But in return for the arduous task of keying dcl-f in place of F, for example, you don't have to concern yourself about what column to put the F or the E in (or else copy an F spec from the quickest program you can put your hands on É--come on, admit it, you've done it, right?)

For that matter, you can make up some of those keystrokes by the fact that you don't need to specify the F or E at all. The F (Full procedural) is the only option in this syntax and the E (Externally described) is the default.

And think of the number of keystrokes you'll save from doing away with all the iterations of /Free and /End-Free around your subprocedure logic!

Of course, the end result is potentially more readable code. And a less "lame-looking" syntax for the newest crop of RPGers coming along.

Here's a very short example of the new "/Free-less" RPG, which also illustrates the new relaxed rules about the relative positions of file and data structure declarations (F and D specs in the "old" language).


 ctl-opt option(*srcstmt) dftactgrp(*No);        
 
 dcl-ds employeeDS;                              
   firstName char(16) Inz('James');              
   lastname  char(30) Inz('Joyce');              
   salary    packed(7:2) Inz(12500);             
 end-ds;                                         
                                               
 // Define printer file and associated DS        
 dcl-f qprint printer(80);                       
 dcl-ds prtDs len(80) end-ds;                    
                                                                                                  
 dsply ('Hello to our new employee');            
 dsply ( %TrimR(firstName) + ' ' + lastName );   
                                                 
 // Also write out details to the printer file   
  prtDs = 'The name of our new employee is ' +       
          %TrimR(firstName) + ' ' + %TrimR(lastName) +
          ' his salary is $' + %Char(salary);        
  write qprint prtds;                                
                                                     
  *InLR = *On;                

We'll be writing more about this new totally free RPG in EXTRA this month. We'll post a link to it in the comments when it's available. Until then, what do you think?

                      

Mentoring and More

We were particularly pleased to see the comments to our blog two weeks ago on training new RPG programmers. It's always gratifying to know that you are not the only people in the world who think that educating our replacements is a good idea. Maybe some of you want to work forever--not us--we have many things we'd like to do.

Among the comments was one from Torbjörn Appehl who mentioned that in Sweden a company named Tieto had recently undertaken a program to train young recruits in the joys of RPG. We mentioned this story last year in our blog, but at the time didn't know the name of the company, etc. Now, thanks to Torbjörn, we have been able to look at the company's website and we highly recommend you to pay a visit too. This is a company to be watched. If you don't live in one of the countries Tieto serves, you're forgiven for going off and weeping quietly in a corner as you bemoan the state of IT companies in North America and probably elsewhere.

So many companies seem content to simply deal with resource shortages by outsourcing, which is not only a short-term solution, but also one that in our opinion is also shortsighted. Do we really want our children to be the hewers of wood and and drawers of water for the rest of the world because we were not willing to invest in them? On the Tieto website pay attention to the mention of mentoring programs and other similar investments the company makes. Do you know of anyone in North America doing that? Or are most, as we suspect, simply bemoaning the skills shortage, which is not just an IBM i and RPG issue, and doing nothing about it.

This issue is fresh in our minds as it came up during the roundtable discussion that opened the annual WMPCA Spring Conference, which we are attending this week. Present at the meeting were a number of present and former students of our friend Jim Buck, who we mentioned in the earlier blog entry. Some of them described the importance of mentoring and internship programs to their success and how hard such opportunities were to come by. Jim is currently working on ways of extending the reach of his programs and we hope to work with him on that. Something needs to happen.

Another comment on the blog came from Christian in France who works for a French training company that runs introductory IBM i and RPG training two or three times a year for clients whose companies have recruited young programmers. We were particularly pleased to see Christian's comments regarding modern programming practices and tooling.

In part he said: "Of course, we use SQL and free RPG, even if we have to talk about DDS and fixed form RPG. Our tools are system i Navigator and RDP, no choice!..."

"As you can see, it is possible to teach 'IBM i', it's a wonderful system with many advantages that can be interesting for young people, but we have to show them the 'sunny side'."

The "sunny side" indeed Christian! No young programmer in their right mind is going to be interested in RPG II style fixed-format coding and SEU. You'll be lucky if you keep them for a month, even if they are an unpaid intern! Show them modern RPG and RDP and you'll find a very different response.

Thanks also to the others who commented on the blog. We really appreciate your feedback.

Another point that came up during this evening's discussion was that most IBM i programmers aren't just programmers. They're really business analysts that implement the results of their analysis in RPG. This in some ways reinforces the point we made about retraining experienced business people and teaching them how to program. It was the way Jon's father broke into programming and we know many other people whose entry into the world of computing took a similar path. Now if only we could work out a way to make that happen on a large enough scale to make a dent in unemployment levels and the RPG programmer shortage that would be progress!

Educating New RPGers

We had a discussion with a client this week that we've had many times before. It usually starts off with a question about what language they should use for future development--the implication (sometimes stated) is that RPG isn't an option.

Why? Not because it's an old language, not that it can't do the things they need it to do, but because it has become too hard to find RPG programmers. More specifically, it has become even harder to find RPGers who are willing and able to do modern things.

We responded with the same suggestion that we normally do (and we have done here in the blog before. If you can't find RPGers, look for a PHPer (or Java or .Net or a ...) who seems to have a business mindset (vs. wanting to write games or the next Facebook application) and teach them RPG and DB2. If you stick to /Free and other modern RPG practices--at least in the beginning--our experience has been that they not only learn RPG easily, they actually quite like the simplicity of the language. After they are hooked on RPG, then you can (if you must) gradually show them the ancient-style code that you almost certainly still have lying around the shop.

This idea has been used with great success in a number of IBM i shops. However, to our knowledge anyway, they have tended to be relatively large shops where there were a number of people who could share the mentorship role. In this specific case, we're talking about a relatively small shop. So the time commitment to not only teach the RPG language to the newbie but also to mentor them in the intricacies of IBM i, DB2 for i, etc. would require a very signifiant proportion of the shop's developer resources. And that's a problem.

Schools in the the IBM Academic Initiative program rarely seem to teach RPG these days. This is mostly because, as we blogged previously, even when they graduate RPG-literate students, too many potential employers still insist on three to five years' experience. But, even if all of the school programs were as successful in turning out RPG literate graduates as our friend Jim Buck at Gateway Technical College, the time it takes for students to graduate from such programs is longer than some of our clients can wait. They need to build their five-year plans today--before their existing programmers hit retirement age--and they can't build a plan simply based on the vague hope that there will be RPG programmers around to replace those staff.

A dilemma to be sure. What's the answer? We wish we knew, but increasingly we think that this is an area where IBM, perhaps in conjunction with their business partners, needs to take a lead. There are a lot of unemployed folks out there who have extensive business experience. Many of them probably did some programming with TRS-80, Commodore 64s, IBM PCs, etc. in their youth. Maybe--just maybe--they are a resource that could be tapped to help fill the programmer gap. But it will need an initiative from someone of the stature of IBM to make it a reality and ensure that "graduates" of such an initiative would be able to break through the insane experience barrier that so many shops erect around their hiring process.

Have you encountered this problem? Come up with and solutions of your own?  We'd love to hear about them through comments to the blog.

/Free at 12

RPG's /Free format has been with us since i5/OS V5R1. That release GA'd in 2001 so this May will mark it's 12th birthday. Doesn't time fly when you are having fun! Despite the fact that /Free will soon enter its teens, some questions about its design still surface on a regular basis. This week one of those perennial questions appeared on the RPG list at midrange.com. The resulting discussion made us think about one of the "features" of traditional RPG op-codes that was not implemented in /Free. Read on and see what you think.

The questioner in this case needed to truncate the result field on an EVAL operation in the same manner that a Z-ADD would do. As is usual in such cases, responders posted many different solutions to the problem--several of the solutions were truly ugly. Certainly the majority would have required substantive commenting in order to avoid confusing the heck out any future maintenance programmers.

When /Free came out we were very much in favor of dropping some of the more arcane RPG op-code such as MOVE and ADD. ADD because EVAL was a much better option and we always thought old-style RPG's numeric truncation was an extremely dangerous "feature" that we were better off without. MOVE because you had no idea what it was doing until you knew the data types and lengths of both fields. We won't get back into the MOVE discussion here, but this latest go-round of postings did make us wonder about solutions for the truncation issue.

One of the few valid uses for numeric truncation that we have encountered involves the rolling-over of counters. For example, to avoid generating duplicate keys, some people use a rolling counter coupled with the time. If you use a four-digit counter, it is useful to have it roll directly from 9999 to 0 when one is added to it. Note that we said "useful" and not "good." It was always poor technique because what it is doing (the roll-over) is not obvious when looking at the code. Regardless, to achieve the same thing in /Free requires that you test the value of the counter before incrementing it and then increment or zero it as appropriate. At least what is happening is more obvious but it does clutter up the mainline logic.

Normally in such circumstances we would recommend that folks use a simple generic subprocedure to implement the function. For the sake of argument let's call it IncrementCounter. This has the advantage that everyone knows its purpose when seeing it in the code and will know that it rolls over on hitting the maximum. It also has the advantage of hiding the complexity of the logic and, as we have said many times before, using subprocedures in this way saves a lot of time in understanding what is going on in the code just so you can ignore it.

But the whole discussion did make us wonder whether there is indeed a place for a new op-code (EVALT) or op-code extender EVAL(T) in RPG. It would handle the scenario posed in the original question on the RPG list and it would also handle the roll-over scenario. We tend to lean toward the use of a T(runcate) extender on numeric EVALs because there is really no need for a new op-code and also because extenders are not frequently used so they tend to jump out at you and make their use obvious. Indeed since EVAL itself is rarely used in /Free an EVAL(T), it really is going to stand out.

What do you think?  Is this the kind of simple RPG extension that is worth developing? Let us know via the blog comments.

P.S. No, we haven't changed our minds about implementing MOVE in /Free. That was one death we were pleased to see.