Adventures in WordPress

I’m an old school programmer. I remember a time when internet access was slow and we could see images slowly appear on web pages. At the time, understanding the technical aspects of HTTP and HTML were important to properly balance out design considerations and performance.

But times change. And I’m getting too old to worry too much about the nitty-gritty details. In my professional life, I dealt with one content management system, Zope. We were trying to develop a system based on Zope and Plone, but for various reasons, the effort wasn’t successful. I’m a big fan of Python. But sometimes it seems that, because the language is so easy to use, systems built using Python can get bloated very easily.

About five years ago, I learned PHP. It’s an ugly language with a less than stellar reputation. But it is ubiquitous and widely supported. Likewise, there are aspects of WordPress that grate with my old-school programmer creds. But it is widely used and supported. Sometimes you just have to be pragmatic.

For about 6 years, I was the webmaster for our church, the Kingston Unitarian Fellowship. Up until recently, the site was hard-coded HTML using SSI and Javascript. And it took some effort to make the site mobile-friendly. But back in January, the board directed me to use WordPress for the church website. It was not entirely surprising since we talked a bit about it before. And it made sense since other people in the congregation would then be able to update content. That was an important consideration for me since I knew it was only a matter of time before we would end up resigning our membership.

Starting from zero knowledge, I had most of the site converted within a matter of hours. Over the next week, I gained the knowledge to move over the dynamic content, and fix a few other glitches. And after a few months, I learned the “right” ways to do certain things, such as where to load the custom CSS and Javascript files.

With that new knowledge and experience, I decided my own web site needed a revamping. It most definitely was not mobile-friendly, and I hadn’t done much with the site for years other than occasionally update the genealogy section. But there was some content that sometimes prompted visitors to drop a few bucks in my “tip jar”. So I set out to bring my web site solidly into the 21st Century.

My site had literally hundreds of static pages. How to approach such a task? First, photo albums took up a large number of pages. I decided to implement the photo albums using a custom WordPress plugin with Ajax loading of the photos. Conversion of the content was made easier with a custom script.

The next biggest group was a set of about 200 pages, each one for a specific area in the city of Toronto. Again, I wrote a custom plugin with Ajax loading of the individual pages, and converted the pages using a custom script.

The rest had to be handled manually. That put a lot of pages in the main menu. So many in fact, that I reached a hard limit, making it difficult to update the menu. I ended up adding smaller sub-menus included at the top of some pages. Over time, I’ll do more of that to make the main menu more manageable.

Finally, I copied over blog postings from my blogs hosted on Blogger.

There are always trade-offs with any project, such as a web site. I like the freedom you get with a hard-coded site. But that takes much more of an effort. I’m not a big fan of the choices of theme you get with a content management system, but I can live with the options provided by the default scheme that comes with the current version of WordPress.

Cheers! Hans

Three Disruptive Technologies

This is the column I wrote intended for the May 2017 edition of our church newsletter. Given recent events, that issue will be my last. With that in mind, I decided not to include this column. Instead, I offer it up here, on my own personal blog:

For almost two years, I’ve had the privilege of acting as editor for KUFLinks. In that role, I’ve taken the liberty of writing a monthly column under the banner “Communications”, most of which have been on one particular topic, technological change. In this missive, I look at three pivotal changes, that have been quite disruptive on society.

First, when editing KUFLinks, I use a piece of software called “LibreOffice Writer”, which is well-suited to desktop publishing. This program is a member of a large class of software known as “free software”. Although much of this software is available at no cost, the word “free” primarily refers to freedom. That is, you have the freedom, granted by the software license, to do what you want with it. Either without restriction, or with one specific limitation that in practice doesn’t affect the users of the software. (There is fierce debate between these two camps, but the details are not relevant to this discussion.)

Most of you aren’t aware of this, but free software underlays much of what we do today. The most popular web browsers, Chrome and Firefox, are based on free software. Most of the software running the internet is too, from the operating systems, to the web servers, databases, and content management systems. If you use a smart phone or tablet, you’re using products based on free software. Even the WordPress software running the KUF web site is free software.

Second, let’s go back a few centuries to the invention of the printing press in Europe. This of course led to immense change in European society. Of interest to Unitarians is the story of one man, Michael Servetus, who used the printing press to publicize his views. In doing so, he got a lot of people mad at him, especially the Catholic church. Servetus expected a safe haven from the Calvinists in Geneva, but unfortunately, they too were not happy with him. Later, Servetus came to be considered the first Unitarian.

Third, we come back to the present. Many of us still remember a time without the internet. Looking back, it now seems strange that we had to look up information in books, often having to wait until the chance to visit the local library or book store. In many cases, we had to travel some distance to find the right repository of information. When doing research, patience was definitely a virtue.

But of course today, everything is on-line, often just a simple search away from the convenience of our home, either on a desktop computer, or on a mobile device. And if we want to connect with other people with the same interests or values, that too is a simple matter of pressing few buttons.

I can say a whole lot more on each of these three disruptive technologies, but I’ll leave it at this. For now.

Cheers! Hans

Is It Now Time To Leave Facebook?

What do we do about Facebook? Many of us use Facebook every day. For many of us, it’s a great way to connect with friends and acquaintances, and to see what’s going on in our communities. I organize a monthly ukulele jam, and Facebook is one of the ways I use to publicize the jams, both on the Kingston Ukulele Society page, as well as other pages.

Unfortunately, Facebook continues to tinker with the filtering algorithms used in deciding what we should see. And this tinkering means that there’s less likelihood that we’ll see what we really want to see.

Facebook does offer a way for us to tailor what we see in our newsfeed. For me, I have my settings configured to see “All Updates” from the vast majority of my Facebook friends, but only the “Status Updates”, “Photos”, and “Music and Videos” from them. The photo at right shows how to change the settings. However, some people have reported that this option is no longer available to them. Since it normally takes a while for updates to roll out to users, it’s inevitable that the rest of us will lose this capability too.

In a Youtube video, Derek Muller explains Facebook’s algorithm that decides what we should see. But here’s my concern: Facebook can never truly understand what’s really important to me. For example, I have some Facebook friends that I have little day to day interaction with, but still I’m interested in everything they post. No algorithm can figure that out.

Of course, Facebook can do whatever it wants. In fact, as a public company, they have a duty to ensure that their stock-holders get the best possible return on their investment. Even if it means reducing the level of usefulness to its users. We all need to realize this fact of business.

But Facebook is also treading a fine line. While doing what they can to maximize share value, they also can’t risk alienating its users. If Facebook becomes less useful to us, what’s the point? Already, there are reports of teenagers leaving Faceook in droves, moving to mobile messaging apps. If Facebook can’t guarantee that I’ll see exactly the things I’ve asked for in my settings, what postings will I miss out on? And also, what assurance can I have that people will see my notifications of upcoming ukulele jams? Big companies can afford to pay Facebook the big bucks needed to ensure that everyone sees their posts. I can’t.

Can I afford to leave Facebook in favor of an alternative social networking site? I’m on Google+, as are many of my friends and acquaintances. But most of them aren’t active on that site. Today, I signed up to Pinterest, but it’s not clear if that’s an acceptable alternative. And I’ve never quite seen the point of Twitter. Today, Facebook still offers me the ability to tailor my newsfeed, but what happens when they take that feature away from all of us?

We’re all left with a dilemma. We all visit Facebook to stay connected and see what’s happening in our communities (geographic or interest). But unless there’s a mass migration, we can’t simply jump to an alternative social networking site. So we’re all stuck with Facebook. As for me, I’ll do my bit to post more on Google+, and less on Facebook. If enough of us do that, perhaps we can tip the balance in favor of the alternative. Or convince Facebook to put more emphasis on the needs and wants of its users.

Cheers! Hans

A Short History of Free-Form RPG

Free-form RPG is back in the news with the announcement of free-form D, F, P, and H-specs. In this short essay, I look back at the history of free-form syntax in RPG.

It all started more than twenty years ago, back when RPG IV was being designed. At the time, there were two distinct schools of thought. On one side, there were people who insisted RPG should have a fully free-form syntax. On the other, were those who strongly believed that RPG should remain in its traditional fixed-form layout. The result was a compromise that leaned heavily towards a traditional fixed-form syntax, but with some free-form elements, such as keywords on the new definition specification and expressions in an extended factor two entry.

My first task in the implementation of the RPG IV compiler was coding the new D-spec, along with its keywords. Later, we were able to convince our planner that keywords should also be allowed on the F-spec. Later still, keywords on the H-spec became an obvious design change.

The extended factor two opcodes, such as EVAL, IF, DOW, etc., were a riskier proposition. At first one developer was assigned the task, and later another to help out the first. But as time went on, it was clear that they weren’t making any progress. Late in the development cycle, I w
as assigned that piece of the language. Scrapping the work already done and starting from scratch, I finished the feature well in time for the initial release of RPG IV.

With the release of RPG IV, the development team was scaled back, leaving two developers working on new features. Because the extended factor two calcs were such a hit, one proposed enhancement was a fully free-form syntax for C-specs. However, we believed that it would require 100% of all development and testing resources for one release. When considering potential enhancements, this item would always get pushed well down the priority list.

This changed during the planning cycle for V5R1. I realized that common coding standards had changed somewhat during the past few years. I realized that a new free-form C-spec did not need to include all traditional C-spec features. Conditioning indicators weren’t needed now that we had the IF opcode. Resulting indicators were largely deprecated in favor of built-in functions. And some opcodes were no longer needed, such as IFxxand the MOVE opcodes. We just needed a few additional built-in functions to fill in some gaps. With this strategy, free-form calcs could be implemented relatively easily, along with other useful functional enhancements.

But of course, this proposal was not without controversy. In order to get the proper design, we had approval from management to discuss the proposal publicly, on a popular RPG related mailing list. Many people loved the idea, but some were vehemently against the proposal. Personally, although I knew we had something good, I was so disheartened with the criticism that I gave the feature a 50/50 chance of making it to release. However, in 2001 it was released, and over time, most critics came around to accept the syntax.

With V5R1 and /FREE released, we started thinking about moving towards a free-form syntax for other spec types. However, while free-form syntax made a lot of sense for calc specs, we could see little benefit for the rest of the language. Other enhancements of a more functional nature were always considered more important.

In the summer of 2003, the iSeries group in the Toronto Lab could not escape the “staffing actions” rampant throughout the Software Group, and the RPG compiler development team was reduced to one person. I was moved to a new team responsible for PL/X, a compiler used internally within IBM for the development of mainframe software.

So now we come to the Fall of 2013, 12 years after the release of  free-form calcs, 18 years after the release of RPG IV. A few weeks ago came the announcement of free-form D, F, P, and H-specs in RPG. Although I’m happy to see this come about, I’m also puzzled. It seems all too anti-climactic, too little too late to save an anachronism of a programming language. In a previous missive entitled Is RPG Dead? The Autopsy, I list half a dozen features common to modern programming languages but missing from RPG. Note that free-form syntax is not included in that list. At the time I wrote that, significant parts of the language were still fixed-form, but I didn’t consider the lack of a fully free syntax significant.

So what’s the big deal about the additional free-form syntax? More than ten years ago when I was part of the RPG development team, we always looked for useful functional features to add to the language. That is, features that would help improve programmer productivity, or allow programmers to do things they couldn’t do easily before. But that seemed to change about ten years ago. In the last release that I had any involvement with, one feature added was XML operations within the language. It wasn’t as if programmers couldn’t handle XML before since there were already XML API’s in use. But as far as I could tell, the only reason the XML opcodes were added was because COBOL was getting XML operations, and someone within the management team decided that RPG needed them too. I considered it a goofy feature, but I was too tired and jaded to argue. (Now that JSON is commonly used in places where XML was previously used, should RPG now include JSON opcodes?)

Lately, the major enhancements to RPG seem to be accompanied by major coverage in the iSeries press. Consider that silly Open Access feature, which seems primarily designed for ISV’s helping to modernize old monolithic applications, which in most cases probably should be rewritten from scratch instead. And now with the new free-form specs, a lot of pundits are writing about how the feature will make the language more acceptable to other programmers, while ignoring the functional deficits previously mentioned. That is, these days, it seems like planning RPG content is more of a public relations exercise geared towards managers of client RPG shops rather than providing real improvements making the job of RPG programmers easier. As RPG falls further and further behind the modern programming languages, I suspect the PR show will become more and more prominent.

In my opinion, although I think the new free-form specs are a nice improvement to RPG, they will not make RPG more palatable to the programmers of Java, Python, PHP, etc. A dozen years ago, we saw little justification for the feature, and I don’t see what has changed in the meantime. If anything, RPG has become less and less relevant as applications programmers continue to discover the productivity gains to be had by using modern interpreted languages like Python and PHP.

Operation Red-Nose Project

About 13 months ago, I started working on a project to replace the software used by the local Operation Red-Nose (ORN) organization. Up until then, they had been using an old DOS-based system that was long past its best-before date. In fact, they were only using part of the system, and even that had major usability issues. The project was suggested by my supervisor at the MCF Practice Firm, a volunteer at ORN. The purpose of the project was for me to pick up some specific programming skills. At the time, I couldn’t complete the project since I got a job offer five weeks into the program. But that job didn’t last, and I was able to return to the ORN project. (During the summer, federal funding for the practice firms was withdrawn, and so MCF was forced to close.)

For the ORN project, I decided on CakePHP and MySQL. I chose PHP and MySQL since they are pretty much ubiquitous in the I.T. realm. For the framework, I quickly narrowed down the choices to CodeIgniter and CakePHP. I chose the latter since it strongly encouraged the use of an MVC design. The ORM also impressed me, with its ability to get all the data associated with a transaction in one operation (typically). That is, all the SQL joins were taken care of automatically.

In a nutshell, the ORN application manages many aspects of the operation, in particular, the event nights during the annual campaign. The system keeps track of volunteers. During an event night, volunteers are checked in to the system and assigned to teams. Operators take calls from clients and enter their ride requests into the system. The dispatcher assigns the requests to the available teams, and tracks the progress of the requests. And at the end of the evening, the treasurer tracks the donations.

An essential part of the development process was demonstrating the system to the ORN volunteers and getting feedback. After each weekly meeting, I’d normally have several pages of suggested improvements. The main issue was understanding how the volunteers would learn the capabilities of the system, which wasn’t always easy for a programmer geek like me. As the programmer, I knew how to get things done. But for others, especially those with little computer experience, it wasn’t always clear.

Add to that some language issues. ORN Kingston is managed through La Route du Savoir, an organization that provides training and services to French speaking people in the Kingston area. Although everyone at ORN speaks English, one person had a bit of trouble with some of the more technical language I used. Often, someone had to translate my technical language into a form that that person could understand, and her requirements into language I could understand. But we managed, and the result was a system that everyone was happy with, even if it took a few weeks after the start of the 2012 campaign to get all the required features in place and the defects fixed.

Is there more work to do on the new Kingston ORN system? Sure. The data entry form for the telephone operators can be improved. I took a few phone calls myself, and readily saw one problem with the layout of the entry fields. For the 2013 campaign, I’ll rearrange the entry fields to reflect the order that questions are asked of the callers. That is, if the first question is “Where are you?”, the pickup location should be the first item on the form. In general, that form should have a list of questions for the operators to ask to ensure that nothing is missed.

How did CakePHP work out? In retrospect, I think it was a perfectly reasonable choice. At no time was there anything that CakePHP couldn’t handle. There was one annoying issue with session timeout. However, upgrading to version 2.2 addressed that problem. The upgrade didn’t go without some effort, though. When I started the project, I didn’t always follow the preferred naming convention. For version 2.2, I had to rename my controller classes.

What about MySQL? The application currently uses 16 tables, which is puny compared to other production systems. Although I prefer more robust DBMS’s, I could clearly see how MySQL has matured over the past few decades. The InnoDB engine (now the default) is sufficiently robust for this type of application, supporting foreign keys and transactions, vital features in even the smallest of databases. In contrast, today in the year 2013, there are still production MySQL databases that use the old MyISAM engine. In my opinion, any database administrator who entrusts vital company data to a MyISAM database should be fired immediately.

If I were to start the project today from scratch, would I do things differently? Styles of programming for web applications are always changing. For the ORN project, I designed it as a fairly traditional server-based web application, with just a bit of client-side programming. But the trend is to move more processing to the client, with the view and controller components on the client and the model on the server. But for this type of application, I don’t think I’d do things any differently.

PHP – What Really Sucks About It?

PHP sucks. That’s something I think a lot of programmers will agree on, even PHP programmers. For example, Jeff Atwood offers an interesting viewpoint in his blog entry The PHP Singularity. But heck, a lot of programming languages suck. And even though they suck, there are many millions of KLOC written in languages like COBOL, PL/I, and RPG.

Programming languages, like human languages, evolve. PHP started life as a web templating system, and evolved into a general-purpose programming language. During subsequent releases, new features have been added and some cruft deprecated. Other languages, like Perl and RPG have over the decades undergone similar transformations away from their original purposes.

Why is PHP so maligned? Perhaps because many of us have had to deal with PHP code written 10-15 years ago when the language lacked many of the nice features added in recent releases. Or PHP code written by programmers who knew better than the previous programmers on the project.  Or PHP code written by programmers without extensive programming experience. 10-15 years ago, programmers who knew the risks associated with web programming typically chose other languages if they could.

When I started doing PHP programming, I started with PHP 5 and CakePHP. With Cake, you can’t help but structure your application using a more or less proper MVC design. It’s probably too much trouble not to. And so I know from personal experience that it is indeed possible to write relatively clean code using PHP. Unfortunately, we don’t all have the luxury of working with clean PHP code.

What kind of programming shop typically uses PHP? I would guess the typical PHP shop evolved as follows: The shop started out small, perhaps as a one-person company. As the business grew, the demands on the custom PHP application grew as well. Other programmers were brought in, each with their own programming styles. Perhaps one of them was assigned the task of managing the others. But without any significant management experience, eventually the programming staff gets to the point of running from crisis to crisis as the code base gets harder and harder to maintain. Does that sound like your PHP experience? It’s a sure-fire recipe for job stress and significant staff turnover.

Based on my own experience, the next time I’m interviewed for a programming position, PHP or otherwise, I would come armed with a bunch of questions, including:

  1. Can I see your documents describing your development process?
  2. Can I see proof that the documented development process is followed?
  3. Would I be reporting to a manager with specific management experience?

To be fair, it’s possible to write bad code in any language. But if a programming shop wants to grow beyond a small business, it needs to adopt a different mindset. It needs professional management experience. It needs proper coding standards and processes. It needs programmers who know what it means to work as a team. It needs a staff that understands the importance of egoless programming. Can those things be found in the typical PHP shop?

Cheers! Hans

Is RPG Dead? The Wake

In a previous post called Is RPG Dead? The Autopsy, I suggested I’d probably have more to say on the subject. This offering is in response to Scott Klement’s editorial, RPG is Dead? Are You Serious?! I’d like to respond to a couple of points he makes.

First, he brings up the fact that people have been debating RPG’s death for the past 20 years, and yet RPG is still around. But why bring up the question at all if there was any doubt as to RPG’s future? Does anyone ask if Python is dead? Or PHP? Of course not! No one has to.

Next, he raises the point that most application development on IBM i is done in RPG. No one is denying that. However, no one can deny that IBM i is a platform in decline. The numbers just don’t lie. The fortunes of RPG are intimately tied to the fortunes of the platform. As IBM i slowly dies, so does RPG. (I said more on this theme in my blog posting Is RPG Dead? Do We Still Have To Ask?.)

Skipping past some history, Scott talks about what’s important to programming business logic. Let’s look at each in turn:

Business logic uses numbers heavily. Well, this is not unique to business applications. However, most arithmetic in any business application, like in any other domain, is integer arithmetic. Business logic does make use of decimal numbers, but even there, most operations involving decimal numbers are simply the movement of data. Actual decimal arithmetic is a small part of the logic, and in most business apps, could be implemented fully in SQL code. That said, other languages do have support for decimal arithmetic. Scott mentions Java for one. Python is another. Even PHP has support for decimals.

Business logic uses databases heavily. Business applications don’t have a monopoly on using databases. Many different domains, from gaming to on-line social networking to statistical analysis make at least moderate use of databases. And so you can find support for databases in practically every programming language out there. RPG gives you two choices: built-in I/O operations and pre-processed SQL. Other languages often provide higher-level access to databases. For example, in CakePHP, you define your high-level relationships (1-1, n-1, 1-n, n-n) between your tables, and one find() operation can bring in all related data for a transaction. That is, the framework figures out the SQL for you, including joins. Among the available RPG frameworks, which one can provide that level of power?

Business logic uses dates frequently. And so do many other types of programs. And so you can find date support in practically all modern programming languages. RPG is certainly not unique. Python has the datetime class. PHP has an extensive list of date/time functions and classes.

Business logic uses a lot of string manipulation. I disagree with that assertion since strings are most commonly needed in the presentation layer of an application. But let’s assume it’s true for business logic. Again, what modern programming language lacks support for strings? Languages like Python, Perl, and PHP (to name a few) all have very powerful string support. Much more powerful than RPG’s support. In those other languages, strings are all objects, with a rich set of methods. RPG, in comparison, has a rather limited choice of string operations. Consider the ease of doing regular expression matching in Perl, Python, and PHP. And compare that to what you need to do in RPG.

If these four categories define what’s important in programming business logic, there are clearly languages other than RPG that have a definite advantage. Whenever I see someone claim that RPG is the best language for business logic, I always interpret that to mean that the author simply knows RPG best. And Scott certainly is an expert on RPG.

Finally, Scott makes the point that RPG is still being enhanced and supported. True. However, other languages have long ago surpassed RPG in terms of features and capabilities. In my previous missive, I listed half a dozen features common to other programming languages that are still lacking in RPG. And I could have listed more. And other languages continue to grow and gain in popularity.

RPG will not disappear overnight. To say that RPG is dead is an exaggeration. However, it is becoming increasingly irrelevant in the I.T. world. I’m reminded of a job interview I had back in 2008 where the interviewer looked at my resume and asked: “What’s an iSeries?”. (RPG wasn’t discussed at all in that interview.)

Cheers! Hans

Is RPG Dead? The Autopsy

In a previous post, I promised to say more on the subject of RPG’s death. But I’m finding it tougher than I expected. Don’t misunderstand me, it’s not for lack of content. It’s just that I worked with RPG for a long time. I don’t want to see RPG go away. Writing this blog posting feels like I’m kicking an old friend while he’s down on the ground. On the other hand, it’s just a programming language. And the facts need to be understood.

When I first learned RPG III, 31 years ago, I was impressed by a couple of things. First, I was impressed with the externally-described file. As far as I knew, no other language had such a powerful feature. Second, I was impressed with the syntax-checking source editor. At my university, some professors were just beginning to think about something like that.

But other aspects of RPG III were definitely goofy, such as the fixed-form syntax and the indicators. Fortunately, the language has grown since then. Indicators can be largely avoided, and calculations can be coded in a free-form syntax. However, although RPG has progressed, other languages have progressed faster, and new languages have cropped up with even more powerful features. More and more, RPG looks like an anachronism, rather than a modern programming language.

I’ll list some features that are commonplace in other, modern programming languages that RPG still lacks:

1) Namespaces. That is, what happens when you want to import two libraries with the same name? In languages like Java and Python, imports can be put into a directory hierarchy. And if there are conflicts, things can be renamed.

2) User-defined data types. Sorry, data structures and LIKEREC just don’t cut it.

3) Object-oriented programming. What language doesn’t have OO support these days? It’s something we now take for granted elsewhere.

4) Extensive list of built-in functions or classes. Just compare what RPG has to the Python Standard Library or PHP’s Function Reference. No comparison.

5) Frameworks. Most modern programming languages have a goodly selection of frameworks that simplify programming web applications. These frameworks have various levels of functionality, however, typically they take care of a lot of nitty-gritty details. Using a framework, you should never see a query string, or XML, or JSON, or SQL.

6) Operating system independence. Programs written in languages like Java, Python, and PHP can easily be ported across different operating systems.

Some would argue that RPG could be further enhanced to address these short-comings. But why bother when there are already other languages that have these features? The planners at IBM certainly know what’s lacking in RPG, and they still seem to have the resources to make the occasional enhancement. But over the past decade, there seems to have been little effort to address these specific short-comings. Looking at the situation from that perspective, one could argue that IBM itself also sees no future for RPG.

So far, I’ve written about 500 words, and yet there’s still more to be said. Stay tuned.

(Update: Next installment: Is RPG Dead? The Wake)

Cheers! Hans

Is RPG Dead? Do We Still Have To Ask?

Guess what, folks? It’s that time of year again when people debate the future of RPG. Is RPG dead? Think about it: Does anyone ever ask that question about any other programming language? Why do some people still insist that RPG does have a future?

To start with, let me make one assertion: Of all participants in this debate, I’m one of the very few who is both knowledgeable about RPG and who does not have a financial stake either way. Some commentators make their living by moving people off of IBM i. Others make a living doing RPG programming or training others. If anything, I don’t relish the idea of RPG disappearing because of my long involvement with RPG development.

RPG is very much unlike practically all other programming languages in use for application development. It is one of the few programming languages that is available on only one operating system. That’s right! If you want to do RPG programming, you need a system with the IBM i operating system. And IBM i is one of the last of the traditional proprietary operating systems.

What do I mean by that? Look back at the history of computers: In the 1950’s and 1960’s, there were a lot of computer companies, colloquially called “IBM and the Seven Dwarfs”. After a couple of mergers, they became “IBM and the BUNCH” (Burroughs, Univac, NCR, Control Data Corporation, and Honeywell). Each one had their own mainframe computer products. And each computer ran its own proprietary operating system, each incompatible with all the others. Over time, almost all of these proprietary operating systems have disappeared. Today, there are just two left: z/OS and IBM i.

Today, most computers run either Windows, or some variant of Unix or Linux. Even the machines that run the O/S relics z/OS and IBM i now also run Linux, with significant cost savings over the dinosaurs.

So here’s the current situation: The fact is that the main reason for running IBM i is to run RPG applications. And to be fair, a lot of them are still running. Without RPG, there’s no reason to choose IBM i. And without IBM i, there’s no way to run RPG apps.

Is there a future for IBM i? When I was looking for work back in 2007, one headhunter specifically told me that the bottom had fallen out of the i job market. Indeed, over the course of about 8 months, I saw only three listings for iSeries jobs in the greater Toronto area. If there are so few IBM i job openings in the 8th largest metropolitan area in North America, what hope is there for IBM i programmers elsewhere?

Frankly, in this day and age, if you want to develop a new application, it just doesn’t make any sense at all to limit yourself to one particular operating system. Especially one that is clearly in decline. Other languages like C, C++, PHP, and Python can run on practically any operating system. If you want to protect the value of your software development investment, clearly, any of these other languages is the way to go.

I have more to say about RPG, but I’ll save that for another blog post. Stay tuned!

Cheers! Hans

OS/2 – 25 Years Later

I almost missed an anniversary. Last month was the 25th anniversary of OS/2. I suppose that’s understandable. After all, who cares about OS/2 anymore?

Well, I still remember OS/2. I used it on my home computer up until June 1998. By then, the writing had been on the wall for years. But rather than turn to Windows, I put Linux on my home computer. My first reaction after booting up Red Hat 5.2 for the first time was: What the heck am I getting myself into? However, KDE version 1 was released just three weeks later, and that made Linux much easier to use. Not as easy as OS/2, but still acceptable. And unlike OS/2, interest in Linux was increasing.

At IBM, I worked with someone who was at the meeting where Microsoft effectively told IBM that their OS/2 partnership was over. And I still remember his description of the meeting. Both sides presented their status. After Microsoft presented their status, the IBM’ers present slowly began to understand the implications of Microsoft’s position. Meanwhile, on the other side of the room, the Microsoft employees were smiling giddily, knowing full well that they were shafting their loyal partner.

After the “divorce”, Microsoft did everything in their power to stop OS/2 from gaining any traction. But OS/2’s failure in the market wasn’t entirely Microsoft’s fault. IBM’s sales division didn’t know how to sell it. And later on, Windows was adopted as the standard workstation for all IBM employees. Clearly, the OS/2 supporters within IBM were a small, albeit dedicated, minority.

There were broader implications. At the time, I was working on the AS/400. Penetration of OS/2 within AS/400 shops was practically zero. Microsoft had pretty much 100% of the desktops within that market. And yet, few people listened to the warnings that the desktop was a beachhead for Microsoft’s incursion into the SMB market. And over time, as many of us predicted, Windows became more and more prevalent in that market, displacing AS/400 installations (and later, iSeries). And now, interest in IBM i is way down. Perhaps the only thing keeping IBM i alive now is the fanatical devotion of it’s remaining users.

What would have happened if Microsoft didn’t go their own way? Would we all be using some form of OS/2 today?

Cheers! Hans