Do you ever kind of get sick of the way RPG is kicked around? I do too, but I guess in this article I'll do some of the kicking because, in some ways, it's our own fault.
Maybe it's the weather. It's really hot today, hot and muggy, and last week it was so cold I was back to wearing sweatshirts. So I'm not prepared for this hot weather, and it always takes me a bit of time to adjust. And what do I do when I'm in the slow process of adjusting? I get cranky.
Today I'm sitting here, looking out at my backyard that once again needs a good weed killer applied (I know I'm not supposed to do that because of water runoff, but I'm going to anyway because I'm not going to pull every stinkin' weed out by hand, and that's making me even crankier), and thinking "Man, didn't I just do that three years ago?" Needless to say, I am not in a good mood. Plus, it looks like rain, and that rarely improves how I feel. Oh, did I mention it's allergy season?
So, I'm just looking for someone or something to give a hard time to, and I guess it's RPG's turn. These are just some random thoughts I've had over the last few months, but I will try to string them together and make it appear there's a common thought here.
We Need to Get Code Markings Under Control
I honestly don't like code markings, especially when there are too many of them. Now don't yell at me and tell me how important they can be, I know what their advantages are. And I know how good flossing is for me, but I still hate to do it. Seems to take soooooo long.
That said, however, I think there comes a time, probably when there's more marked code in your programs than unmarked, that you should really think about completely redoing the whole mess. Or at least deleting some of the commented-out lines. I know the purpose of code markings, but I think most shops have carried the practice to almost unhealthy proportions.
The original intent for code markings was twofold. First, to make it easy to back out a change if something went horribly wrong, and I can dig that. I also, however, feel that the most effective way to back something out is not to carve up the program again and recompile it, but to move a saved object and source back into position. If you're doing that, the need for code markings drops.
The second reason for them was if you have packaged software and made changes. You wanted your changes to the source code to be obvious, and I am foursquare on that one. It makes good, good sense, although you want to couple that with creating a user mod library where these changed programs should go, leaving your original package module out in the main library.
For homegrown code, however, is it really unrealistic to set a statute of limitations on code markings? I don't need to have to see deleted code from seven years ago. That kind of stuff makes it harder to see what's going on, and I'm not going to go back to that way of doing things. Code should be scrubbed every few years with a mind for making it more readable and removing things that happened before some of the infrastructure people were born.
We're Always Doing Maintenance
I also hate doing program maintenance. Nonstop.
Now first and foremost, I realize that this is not a failure in the RPG language, and maybe I should have been more explicit above and indicated that most of my problems deal with the RPG environment, not the commands per se.
The one thing that seems truest about the RPG environment is the fact that we're always doing maintenance. It's been years since I was doing a real new development or enhancement project in RPG. Some of that is because a lot of the clients I deal with have very mature ERP systems and there's not that much to develop, but that's not the whole story.
If maintenance is really where it's going to be at for the RPG world, then wouldn't it make some sense to invest in the applications that we're saying are indispensible for our businesses? And a good way to make that investment would be to fully adopt ILE practices in our RPG coding. We should be making the investment to break up our big ol' programs into smaller, ILE-friendly procedures, including service programs. But we don't see that happening as often as it should.
Of course, there are reasons why this is not happening. One of them is that we're just hesitant, although perhaps the word we really want to use is "scared," to make major changes to some of these old programs. And the fear is understandable. If your shop is like most, there are programs out there that probably no one really understands. And something bad could happen if you miss something when you're redoing those programs. True, true, but the simple fact is that things happen every day in trying to modify those big ol' programs. So simple fear is not a full explanation.
Management Doesn't Want to Invest in RPG
No one will actually admit to this (or will they?). And I'm sure some shops are investing in RPG. But most of the time, with most of the shops I deal with, I'm not seeing it.
What are we saying when the people who have the most to gain from RPG treat it as if it's a dead end that's no longer worth putting any effort into? The effort that's going into the language right now, as seen on the forums, is using the language to solve problems, but often those problems could better be handled by other languages via APIs.
The real point is that investing in RPG is not something that takes money. Nor does it require extensive education to use esoteric aspects of the language. The investment in RPG that I'm talking about is an investment of will, of belief. Do we believe that we can write modular, efficient apps in RPG that will take us into the next 20 years? Or do we believe that RPG has done all it can and all we can hope for over the next few years is to keep the heart beating while we slowly replace all of that code with PHP or some other web language that's not nearly as good at doing what we need done as RPG is?
I Feel Better Now
Well, I have to admit that I feel a little better now, not so grumpy. Maybe it was the complaining. That's what I want to believe. Or maybe it's just evening and cooler outside. I guess it could go either way. I have no idea what I will do when summer finally comes and it gets really hot.
Nothing has been decided, of course. I still get sick of too many code markers, but they aren't going away any time soon. I still would rather develop new apps than fix 25-year-old ones, but I do what they pay me to do. And the future of RPG? Not sure what will happen there. In many ways, RPG is where COBOL was a couple of decades ago. It's a mature language that's used in lots of places. And because the apps that use it are not being updated, it's being viewed as a dinosaur.
Seriously, what happens next is up to us. It's our move.
David Shirey is president of Shirey Consulting Services, providing technical and business consulting services for the IBM i world. Among the services provided are IBM i technical support, including application design and programming services, ERP installation and support, and EDI setup and maintenance. With experience in a wide range of industries (food and beverage to electronics to hard manufacturing to drugs--the legal kind--to medical devices to fulfillment houses) and a wide range of business sizes served (from very large, like Fresh Express, to much smaller, like Labconco), SCS has the knowledge and experience to assist with your technical or business issues. You may contact Dave by email at
MC Press books written by David Shirey available now on the MC Press Bookstore.
 |
||
 |
|
21st Century RPG: /Free, ILE, and MVC Boost your productivity, modernize your applications, and upgrade your skills with these powerful coding methods. List Price $69.95 Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online