iSpeak

Hear from our iSeries experts. Put in your two cents.

RPG

September 16, 2005

The Perception

There's a major schism evident in this blog between those that believe that RPG is a language for traditional programming and those that see it as a capable language for the future. The former perceives RPG as a language for 5250 applications, text-only reports, and batch jobs. It's not hard to understand where they get this perception, since that's 99% of what you see when you look at RPG programs. The other side thinks it's capable of much more, and I fall into that category.

If you read the comments posted to this blog, both in response to Paul Conte's Free Format D-specs are LONG Overdue! and my own It's Time to Improve Our Image, you'll see that the vast majority of arguments boil down to this difference of perception.

From my perspective, RPG and Java are direct alternatives to one another. The things that you can do in Java or .NET or Visual languages can also be done in RPG.

Many people, such as myself, have written web applications in RPG, and have found it to be an elegant language for doing so. I use RPG to generate not only plain text printed reports, but fancy, colorful reports with pictures and lines and different fonts on them. I use RPG to generate Word and Excel documents that can be built off-hours and e-mailed automatically to our sales force, our customers, our vendors, etc. I use RPG programs to consume web services, to provide security for network applications, and much more.

From the perspective of many others, that's not the case. RPG to them is for writing green screen accounting software and drab reports that all use a common fixed-width font and are often printed on green bar or blue bar paper.

It's important to understand that this perception is absolutely central to the problems facing the iSeries today. If you believe that RPG is only for old-style programming, then RPG is doomed. If RPG is doomed, I have no doubt that the iSeries is also doomed. Like it or not, the two are inextricably linked. You can run Java or .NET anywhere. Without RPG, the iSeries is just a really expensive database server.

It's RPG that makes it all make sense! It's an elegant language for writing not only business rules, but also for web programming. I've written web applications in PHP, Perl, C, and even Java. CGIDEV2 -- an RPG method -- is the most elegant way that I've found! Most of these other methods either involve embedding the HTML/XML code in the program or embedding the program in the HTML/XML code. In either case, it's awkward. Separating the markup language from the code, the way CGIDEV2 does it, is much more elegant in my opinion.

The problem isn't that RPG isn't capable of these things. The problem is that the programmers who make up the majority of RPG people are not aware of the capabilities that it has. Or, perhaps they haven't upgraded their skills to the point where they're able to understand modern techniques.

That's not usually a problem with a Java or .NET programmer.

What this all boils down to in the end is how someone perceives of the iSeries and of RPG. A management team that's out looking for a software solution looks at the alternatives, and sees demos of the available software packages. Or, if they're looking at custom software, they look at what consultants have done for other companies. Or, for in-house development, they look at what other companies have done to provide a starting point for their in-house staff.

About 70% of the solutions that they see are Windows solutions, because it dominates the marketplace. If they keep looking, they'll eventually find the iSeries solutions.

And when they see iSeries solutions, they occasionally see a really unbelivably convoluted WebSphere solution that costs big bucks and requires big iron. The rest of the time, they see an ancient 5250 system that looks pathetic when compared to the friendliness and flexibility of a Windows system.

When 70% of what they see is Windows, and those solutions are friendlier and more flexible, will they bother to look at iSeries solutions the next time? Especially when they're much more familiar with Windows?

It's true that it'll take a long, long time for all of the existing iSeries shops to migrate away. So the system won't be dead soon, but it will fade away very slowly!

If we want to change this, folks, tt's the programmers who need to step up to this challenge. We need to upgrade our skills so that we can compete!

Now, this is the point where you choose RPG or Java. Do you re-use the skills you already have, and expand upon them, to write efficient, modern RPG code? It'll run faster than the Java code, use much less memory, and RPG's syntax is the best in the world for writing business rules. Or do you bite the bullet and do your work in Java? There are many more Java programmers in the world, since it's not an iSeries-only technology, and your code will run on any system, which is a big advantage to some people.

Believe me, remaining with the 5250 technology, or drab reports, or nightly batch type coding isn't an option! Not if you want to have a future.

Fortunately, no matter how you approach it, the iSeries is capable of doing it. And it'll be stable. And it'll be easy to troubleshoot problems on. But it may not be around forever if we don't upgrade our skills and improve our image. Because whether it's technically better or not, it's all about perception!

Posted by on September 16, 2005 at 3:04 PM | Comments (116)

May 4, 2005

Free-format D-specs are LONG overdue!

IBM needs to deliver free-format D-specs (and P-specs) for ILE RPG, and SOON!

If we're worried about i5 image and productivity, a top priority should be the application "lingua franca" of the system.

Can you imagine Windows Server and .NET offering a language that still requires fixed-format, positional entries?

As a practical matter, free-format D-specs don't need to include all the esoteric options that have been added since the days of the "cycle."

Instead, a free-format D-apec should allow declarations of normal scalar and structure types. For example:

Dcl TRUE         Lgl  Const( '1' );
Dcl CurItemPrice Dec( 9 : 3 );

Dcl Structure ItemInfo  Qualified;
  Dcl ItemNbr    Integer;
  Dcl ItemPrice  Like( CurItemPrice );
  ...
  Dcl ItemDesc   String(100);
End Structure;

Positional declarations are a stone-age idea anyway, but this syntax is especially cumbersome with:

-- Long identifiers (requiring "..."). This really torques me on procedure interfaces, prototypes, and P-specs!

-- Within subprocedures, where you have to repeatedly bracket code with /Free /End-Free

Hopefully, it won't take IBM another decade to fix this critical deficiency in RPG.

-- Paul

Posted by on May 4, 2005 at 9:14 AM | Comments (91)

August 2008
Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            

Blog Policy

Our blogs are editorial content of System iNetwork. We welcome your comments and opinions and encourage lively debate on the issues, and we reserve the right to edit all postings for clarity, length, civility of tone, and appropriateness to the topic under discussion. Comments consisting of product or job solicitations and other spam, profanity, and extreme rudeness will be deleted. We also reserve the right to publish excerpts from the blogs in our e-mail newsletters and print magazine.

ProVIP Sponsors