Archives for category: IBM i
IBM i

IBM i (Photo credit: Wikipedia)

I have been to just one of Trevor’s presentations, and he is an entertaining speaker. Users and developers that use the IBM i generally know who he is.

Some in the audience actually did have a real “AS/400“, at that time, and had not yet moved to the current offering from IBM, the “IBM i on Power”, from before, and he said, “Well, yeah, you do have an AS/400″.

I can understand how he might be considered “caustic” in his conversations, and call it my opinion if you want, but he is right.

It’s not the same machine it used to be. People have the green screen idea when they think of our succession of machines. Maybe they’ll be calling it “IBM Next” after 7.0 but we’ll see.

They called it “Mac”, “Windows“, but when they do, the brand is not held back by those names. People regard it as a general brand. None of us has any problem at all calling an automobile by the name the manufacturer gives it. But the Rambler is dead. The Edsel is not coming back.

One well-known creator of a very much-used language, whose name slips my mind, gave a talk about branding at a conference, and gave a few examples.

Once upon a time, there was a phone company that accumulated one of the worst reputations for quality, overhauled it to get one of the best, but the consumer brand was irreparably damaged. So, they changed their name to Verizon.

Has anybody here ever used IBM Visual Age for Java? Or ever hear of it? How about Eclipse?

That’s branding.

The other day I went to a Java Users Group. Despite the fact that the IBM i can run all the java you ever want, PHP, Python, web servers, XML, and almost anything you can run on Unix, about half a dozen good GUI‘s, you can run just about any popular file system, including the one for Unix, the one for Windows, for the i.

I’ve heard there are knockout applications running web sites, few viruses can do it damage, there’s nothing ancient about the latest offerings for IBM i on Power.

They had never heard of the IBM i. So I explained that it was the modern replacement for the old AS/400. They immediately stopped listening and did the same thing when they heard “RPG“, and didn’t even seem to hear that RPG can do all this great stuff and is getting updated faster than any other standard language.

From now on I’m not even going to mention the AS/400, I’ll just talk about the IBM i.

RPG needs a re-branding too. IPG or i2100, or something.

 

In big companies and big outsourcers it often happens that projects are always broken down into small pieces, measurable, how quick. Training in new technologies, new languages, takes bites out of budgets. How quick can you get this done, and forget about modernizing your code, it’s not budgeted.

I sympathize, why fix it if it ain’t broke, and you’ve been taking the bugs out for thirty years, and you don’t want to do that again, but think about that. Like you have a hundred programs that access several files, each file in almost all of them say, and when you have to expand the amount file you have to change 50 programs and recompile the other 50.

Brace yourselves, your dollar amount fields have a high probability of a need for expansion soon.

And what is your company going to do in twenty more years with a change to your OCL you run with STRS36PRC, after all the guys are gone that used to know what to do with a matching record indicator and all that?

On a recent iPro or MC-online article somebody mentioned a study that showed 60-something percent of developers’ time is now spent on maintenance. Tools that make maintenance easier are great, and there are some tool sellers that address that (like Databorough and Hawkeye). But I think that many companies would be well served by a well-planned, minimally disruptive, stepwise move toward modernizing their code base. Things like breaking up the monolithic order entry programs into small pieces, replacing the in-line routines in fifty programs that access the same customer information by external routines, and so on.

ROI? Sometimes real hard to calculate, but if you can cut down maintenance on the other end by even half, then what would you say?

 

IBM i

IBM i (Photo credit: Wikipedia)

I work every day on a mixed code bag, including code written in the 1980s in one of the oldest known programming languages. Really out-dated stuff, what’s known as RPG-II. It was designed for the IBM System/34 and was the main coding language used on the IBM System/36 as well.

HP and Wang made their own RPG compilers to offer a way to pull customers away from IBM, but they apparently mostly quit trying after IBM brought out the System/38 and then the AS/400, the business system that blew DEC’s rival system and HP’s special ‘midrange’ into history. We who have worked on these IBM midrange systems -IBM now calls it “midmarket”– never could understand why everybody didn’t want to go out immediately and move their business to the most stable and secure-able system available so we always blamed IBM for hiding it and hiding their advertising budget from it, presumably to protect their lucrative mainframe business.

I”ve been through major upgrades and conversions of software from one base to another.

But at a lower level than that, I’ve considered different factors relating to program changes. The code base that’s so old for example, could benefit from a major overhaul and conversion to a more modern code base that could cut down drastically on both code change costs (in hours) and reduce the program halts that haunt ancient code bases that have gone through patches, fixes, more patches, enhancements and modifications over longer than the lifetime of the younger developers among us.

Programmers are generally attracted to “refactoring” old code, but it’s a bad word to CIO’s and managers who imagine all the kinks that occur with implementing changes and new code.

But we can minimize the pain of damages. I’ve thought of some things that make life easier to code changers and projects in general.

(1) Gosh, guys, get a good code analyzer! They’re around, and yes, the IBM i world has them too. Maybe especially. On the IBM i, for example, there are some that drill down into your code and claim to come close to extracting your business rules, identifying unused “orphan” code, and even maybe suggesting possible improvements. They exist even for COBOL code, but believe that these are not quite as thorough or detailed as the ones for RPG, understandable, but they’re more than nothing.

(2) We can minimize the disruption of changes.

We can make changes by steps, unless it’s a major difference in business rules, no way around that. But for changes that fall short of that, you don’t have to change all the menus and programs at once, change them a bit at a time. That saves money and nerves for the users and provides a proving ground for the changes, and helps dampen user complaints, which usually come from users who get comfortable, often with good reason, doing their jobs a certain way and have a hard time with the new stuff.

Y2K is an example. The best change-overs were either completely invisible, or moved smoothly into four-digit years. That project was so good the world scratched their heads and wondered what the fuss was about, and they thought maybe we had pulled a big scam on them. There was even a line on one of the Star Trek shows (or was it a movie) where an predecessor to Captain Jane wondered aloud whether there was really a problem.

Of course we coders know we saved their behinds!

English: Python logo Deutsch: Python Logo

English: Python logo (Photo credit: Wikipedia)

Mel Beckman has written an article that repeats a theme I’ve seen since the days when I first started writing code in the first widely used version of RPG in the 1970’s. There’s always a variant of RPG is dead, RPG is dying, RPG is fading away, and all that. But I always pay attention, because all things change in this world below on here on Earth. It seems like the main reason he says this is that, according to him, not much new code is being written in the newest version of RPG-IV and that most of the time spent doing RPG is on maintaining existing RPG code, as in fixes, enhancements, and the like.

Find it here: http://www.iprodeveloper.com/article/opinion/is-rpg-dead-699217?cpage=6#commentsAnchor

I’m glad iprodeveloper opens it articles up for comments. For web sites that open up for comments so readers can offer their reactions, I’m finding these days that the comment section gets at least as interesting as the article itself. Actually, the article plus the comments generally make good reading.

For example, Mel Beckman listed a lot of other languages as newer and more promising for writing new code. He gives examples he calls “more-modern” languages: “More-modern languages such as C (including C++ and C#), Java, JavaScript, Perl, PHP, Python, and Ruby (all of which run natively on IBM i)”.

Aaron Bartell pointed out that for a some of these you have to have multi-layered implementations to make them work, with the extra load of maintaining and configuring each layer. Someone else pointed out that training current staff (the ones that know your business) in new languages is not cheap either.

I’ll add my own observation that each layer of technology -hardware, third-party software, external servers and applications, and so on– comes a multiplier in maintenance load.

Jon Paris added his observation that for one of his recent classes he was teaching the newest RPG, RPG-IV, to programmers that code in C, C++, Java, and others. He also added that the Java programmers are delighted with the ease of performing some functions in RPG.

Well, one more thing. The current generation and latest versions of RPG, RPGLE or RPGIV, have incorporated great advances that utilize, or enable the use of new techniques and possibilities. And while it does not have object-oriented syntax, with the intelligent use of subprocedures and service programs, it does enable advantages that are generally associated with OO programming.

Here’s an alert to utility software providers: there just might be a market for a precompiler that does OO things, that for example expands an embedded OO syntax into RPG code for compiling, similar to how the 4GL’s are said to work.

There are some programmers where I work who do new coding in COBOL, too.. Nothing wrong with that for the purpose, depending. But more on that later, and on refactoring code in a future article.

 

Related articles