Archives for posts with tag: Windows

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?