Four Reasons RPG Geezers Should Care About The New Free-Form RPG
February 12, 2014 Jon Paris
|
By now you have probably heard that with the latest V7 changes to RPG IV, we can code completely free-form programs. But why should you care? Maybe you saw the benefit of free-form calcs and have been using them for some time, but you still can’t see why you should bother with learning this new way of coding D, F, and P specs. What’s the point? Well, I’m going to share my thoughts on that subject. On my last birthday, I officially became a geezer (i.e., senior citizen if we want to be polite), so with some 45-plus years of RPG behind me I think I’m qualified to talk on the topic. So, here are my top four reasons why we should all embrace this latest change. 1) I hate F-specs. I can never remember which letter goes in which column, and of course the more I use embedded SQL, the less frequently I have to code them. I almost always end up either cloning or using the prompter in RDI (about the only time I ever use it) and even then I’ll get at least one thing wrong. I also find it frustrating to have to specify every little detail. For example, if I say it is a printer file, then of course the thing is output. How many input-capable printers have you ever encountered? Forget that the new F-specs are free-format. For me the most liberating thing about them is that they assume sensible defaults! For example, suppose I code this:
Dcl-F MyPrinter Printer;
That is all RPG needs. There is no need to specify the “E” for externally described, since that is the default for all files. Similarly there is now a sensible default usage for each file type, and that takes care of having to tell the compiler that my printer is an output file. Isn’t that a pleasant change? Even I can remember how to code that! How about disk files? Well those are the simplest of all. Want an input disk file? No problem:
Dcl-F ProdData;
That’s all I need to code, as the default device type is disk, and it has a default usage of input. I love it! But what if it were a keyed file, and records were to be both added and updated? Equally simple and, perhaps more importantly, a lot more obvious than a “U” and an “A” in some obscure column. Here’s what it would look like:
Dcl-F ProdData Usage(*Update: *Output);
2) Requiring that all F-specs come before any D-specs is annoying. This is particularly true in programs with large numbers of files. I use a lot of data structure I/O and it is annoying to have to separate the two sets of definitions. Same thing applies to control variables used with a specific file. Ideally I’d like to define the file and then follow with all the associated DS, field, and constant definitions. Well with the new support I can do just that. // Definition and variables for Product file Dcl-F Product; Dcl-DS ProductRec LikeRec(ProductR); Dcl-C obsoleteProduct 'O'; Dcl-S prodRecCount Int(5); // Definition and variables for report file Dcl-F ProdRptF Printer OflInd(fullPage); Dcl-S fullPage Ind Inz(*On); If fullPage; PrintHeaders(); EndIf; Admittedly an overly simplistic example, but hopefully it gives you the idea. 3) Flipping in and out of free-form for subprocedures is ugly. This has bugged me ever since the V5R1 introduction of /Free. There I am happily coding away in my little /Free world and I have to switch back to fixed form to start a subprocedure, and then back to free to code the logic before going back to fixed to end the subprocedure. It just makes the code look plain ugly. (Note I also hate those big ugly blobs of asterisks that some people use for comment blocks.) Admittedly part of this problem is alleviated by the simple removal of the requirement to use /Free and /End-Free, which is also part of the new support. Here’s a really simple example of what I mean. Here’s the pre-liberation version of a super simple subprocedure:
/End-Free
P PrintHeaders B
/Free
Write Heading;
pageFull = *Off;
Return;
/End-Free
P E
/Free
As I noted, I can now remove the /Free and /End-Free directives, which gives me this:
P PrintHeaders B
Write Heading;
pageFull = *Off;
Return;
P E
Less typing, but it still looks a little funky. This is the new version:
Dcl-Proc PrintHeaders;
Write Heading;
pageFull = *Off;
Return;
End-Proc;
Now I can code a subprocedure, complete with local variables, every bit as easily as a subroutine. That’s one less excuse for the “subroutines were good enough for my grandfather” brigade. 4) I want my legacy to live on. As I said earlier, I have been working in the midrange arena for more than 45 years. Many of the applications that I wrote way back when are still in use today. I would love to be able to go back and retrofit them with these latest RPG enhancements. Why? Because I take pride in my work and don’t want programmers who work with them in the future to discount them simply because they look ugly (fixed form) and therefore do not match their expectation of what a program should look like. Over the last few years, my partner Susan and I have trained a lot of Java, C++, C#, PHP and other programmers in the joys of RPG and the IBM i. We always start with modern editors (RDi) and free-form RPG. Always. We have seen so many potential RPG lovers turned off by being introduced first to the old fixed-format version of the language. Even worse to RPG/400, not even RPG IV. It might surprise you to know that the vast majority of those who we have trained love RPG and the simplicity with which it handles situations that would require much more coding in other languages. As long as they were writing logic (i.e., the free-form calcs), our students had no problems. What drove them crazy was when something as simple as changing a variable name resulted in a multitude of errors because they had inadvertently disrupted the column sensitive portion of the definition. The resulting errors made no sense–after all the line looked pretty much the same as it did before. The same thing happens with subprocedure definitions. And we’re talking about people who have been trained to build all of their applications around subprocedures. I have seen situations where these folk started off really buzzed by what RPG offers only to become frustrated and disappointed as they progress into subprocedures. No more. Now we can introduce them to a version of RPG that removes these barriers. And that can only be a good thing. Summing It Up IBM’s motivation for these changes in RPG may have been primarily to make it easier to attract new programmers, and that’s a good thing. Hopefully, though, I’ve given you a few ideas as to why you might want to embrace these new features in your own coding. In a future tip, we’ll go into the details of this new style of coding and give you a few head-to-head comparisons between the old and new way of doing things. Author’s Note: For more on this topic, check out this page on the IBM website. Jon Paris is one of the world’s most knowledgeable experts on programming on the System i platform. Paris cut his teeth on the System/38 way back when, and in 1987 he joined IBM’s Toronto software lab to work on the COBOL compilers for the System/38 and System/36. He also worked on the creation of the COBOL/400 compilers for the original AS/400s back in 1988, and was one of the key developers behind RPG IV and the CODE/400 development tool. In 1998, he left IBM to start his own education and training firm, a job he does to this day with his wife, Susan Gantner–also an expert in System i programming. Paris and Gantner, along with Paul Tuohy and Skip Marchesani, are co-founders of System i Developer, which hosts the new RPG & DB2 Summit conference. Send your questions or comments for Jon to Ted Holt via the IT Jungle Contact page.
|
