Green screens are great for quick and dirty command-line tools used by programmers. But beyond the entrenched legacy systems or command-line utility, green screens are the No. 1 cause of all loss of market share for IBM i. No, it is not the green-screen applications you wrote or that your company purchased 20 years ago that are the issue; the problem is the green-screen app that you may be creating today. That green-screen application that was just approved for development is the cause of the loss of RPG—and indirectly i on Power—programming jobs.

Does this sound counterintuitive? If so, you've identified the problem: you think green screens are okay for certain applications, and they are. But they are not good for any new end-user application development of any kind. The only thing a green-screen application does is contribute to the time when your VP of IT is replaced with a Microsoft-weenie and then he or she decides to "replace the AS/400 because it's old." You know the type: "We need to implement agile software." Which, by the way, is the first clue that should indicate their only IT training has been watching Microsoft TV commercials.

Don't get me wrong, Microsoft makes some really interesting stuff, and deserves most of its success. Other operating systems, such as those various Unix-clones, make very usable servers and most are reliable. But "the AS/400" isn't old technology, and it certainly is no older than the Microsoft operating systems running on Intel hardware or the flavor of Unix on most servers. Okay, maybe System/38 was shipped one or two years before Microsoft shipped DOS, but so what? Certainly the IBM "i" operating system of today is no more the CPF of 1980 than Windows 7 is the MS DOS of 1983—a lot has changed. The only real advantage Windows and now Linux have over our operating system is a name that doesn't change every 15 minutes. Ironically, our operating system name is so bad today, that it would actually need to be changed before it could remain the same. I know, this is a sort of "I voted for the war, right before I voted against it" statement, but it is true. The i name is to ambiguous for IBM. Apparently only Apple knows how to market this identifier, as they just renamed their iPhone OS to "iOS," licensing the trademark from Cisco, who owns it. But I digress.

Where IBM Failed AS/400

Bill Gates & Co. were right: graphical user interfaces (GUIs) are "better." Today we know that in the mid-1990s IBM Rochester had the opportunity to move the operating system to a graphical-based user interface. This was happening around the same time as the move of OS/400 to the PowerPC chipset. This move gave OS/400 the platform the performance boost it so badly needed. But for some reason, IBM decided against a GUI for the i platform. This wasn't a simple "thumbs up/down" vote, however. I have heard it was a heated debate that came down to this: "our customers have so much invested in green screens it will be difficult to get them to change."

Of course this was nothing more than the classic: "we've always done it this way so why change now?" I have also heard there was concern about performance. It would have taken a lot to put a native GUI on the platform, but would it perform? If they created dumb-head terminals, (which they did) and allowed a GUI to run on those (which they did) and then allow them to be attached to the i platform (which they did), then the GUI engine could be outboard (off the main system) and therefore not impact performance (which they didn't do). Two retired IBMer's (the same ones who built the original 5250 data stream in the 1970s) independently leveraged all that technology IBM created and didn't use and enable support for a native GUI on the i platform. This happened at least 12 years ago—perhaps more—and it worked great. But on the i platform, unless IBM gets behind a technology (they did not) rarely does it have long-term success. So the two former IBMers stopped selling their GUI just a few years ago.

If IBM had created a GUI and advocated the platform as an end-user product with a server option (like everyone else seems to be doing), then it could have been i from the end-user desktop to the server farm and everything in between. The IBM POWER-based Cell chips used in Nintendo and other video gaming consoles make graphics scream—more than enough power for OS i GUI support. Imagine the graphical performance boost we would have had when Cell came out and was added to the i platform.

It was Lou Gerstner, one of the most respected IBM CEO's of all time, who, in my opinion, made one of the worst decisions any IT industry CEO of all time. What is it? Gerstner said "When something becomes a commodity we won't be in that business." Well, Lou, today all IT hardware is "a commodity," so now what?

Graphical Is Available

Regardless of IBM's decisions some 15 years ago, today the world has made a decision, and there are only two kinds of applications:

1. Inside the browser or "browser-based" applications
2. Outside the browser or simply "applications"

The first choice has been available for the i platform for more than a decade; longer than the lifecycle of the original "i" platform, the System/38. The web server and browser have been used to build end-user interfaces for applications on i for so long that only in your shop is it not happening. Yes, you are the only shop not using this technology; and subsequently, you are on a path to Windows, or worse—".NET".

The second application class is an interesting phenomenon. Browser-based application advocates, like Apple and Google, are now suggesting that "outside the browser" applications, or simply "applications" as Microsoft calls them, are the future. Seems to me we've been using out-of-the-browser applications for half a century. Everything runs in circles. But there is a new twist: the GUI technology for these out-of-the-browser applications is web browser-based, not native Windows or native KDE or native X or native OS X GUI controls. In other words, the GUI technology programmers will write to is HTML with an HTML scripting language such as JavaScript, and the operating system will map them to any native interface controls. This could solve one of the handful of platform-porting obstacles that have plagued programmers for decades. If I write for Windows, it doesn't run on Mac OS X or on i. Sure the program logic and code itself could be compiled on other operating systems, but the I/O logic (database and graphical user interface, API calls) don't port at all. By writing to a common user interface (HTML), one of the biggest obstacles to application portability is removed.

Today, HTML and JavaScript are available to RPG, C, C++, Cobol, and even CL programmers on the i platform. Tools like the original CGIDEV2, my own CGILIB service program, and others have been making this capability easy for more than a decade. Third-party tools like those from BCD, Profound Logic, CNX, ATGI, and others have been enabling this technology in their own products for just as long. The iGUI is here and it is HTML.

With these tools and the recent Zend PHP available to i users, you may be able to get by without in-depth knowledge of HTML and JavaScript, but you do need to learn the fundamental HTML concepts, and in the case of PHP, you'll need to learn PHP. Consider HTML knowledge as valuable, in fact, more valuable than your display file DDS knowledge. 

IBM includes the Apache web server "free" with your paid software license. This is the only technology you need on your system to write browser-based and therefore GUI-based applications for i. 

Is there any reason you are not using browser-based user interfaces for your applications? If the answer is "yes," then I think the reason for this may be: Fear

• Fear of learning HTML
• Fear of learning JavaScript
• Fear of asking the boss if he or she will let you use the web browser for that new application.

For me, using HTML and JavaScript is so common place that I find it difficult to use DDS for display files at all. I want to use display file DDS about as much as I want to use RPG II and the RPG Logic Cycle to build new applications—it ain't gonna happen.

Moving to a web browser-based user interface is moving to iGUI. If I can create an end-user application that uses a web browser user interface in less time than the average programmer can clone a subfile program, then so can you. If the whole CGI thing has you confused, there is another, albeit pricier, option in the 7.1 Rational Open Access:RPG Edition API licensed program product. 

Rational Open Access:RPG Edition ("ROARE") provides a way to connect to any type of user interface: browser, green screen, remote database, XML, web services, whatever you want. It doesn't provide you with any of these connections itself, however. Instead, it is merely an API that, like user space APIs, simply lets you or a third party write code that allows RPG to access modern user interfaces or I/O devices using traditional RPG input/output operation codes. In other words, if you've licensed or written the necessary "device driver" you can access, for example, the web browser or other things using the READ/WRITE operation codes and classic RPG processing, no cryptic API calls necessary.

Today, Profound Logic and its Profound UI seem to be ahead of everyone else in the ROARE space—the solution provides a device driver as I'm calling them, for browser-based applications written in RPG. You simply write class RPG operations such as OPEN, READ, WRITE, UPDATE, etc. The Profound UI device driver takes care of talking to the web browser for you. Profound UI offers a turnkey development environment that provides a GUI-based PDM/SEU/SDA toolset that makes user interface and application design as painless as possible.

But not all iGUI applications need ROARE; most simply need a web browser user interface and one of the CGI libraries that I mentioned earlier.

Don't Lose Your Job

Today, GUI means browser-based user interfaces. You can build GUI applications for i (iGUI as I call them) using RPG, HTML, JavaScript, and PHP, so there is no excuse to allow those Microsoft weenies into your shop to take away your job.

The i is so reliable and trusted over other platforms that it's now being installed all over the world in countries such as Russia, where industries like banking or gas and oil are  fast-growing industries. Those systems and applications need to be not only reliable, but secure—secure not just from outside attacks/hacks but from untrustworthy in-house employees. Recently I visited several banks in Russia and I saw i running in these banks. When this kind of security is required, nobody screws around with Windows, and Linux is just too labor intensive to be used efficiently.

Remember, when you have tens of millions, or hundreds of millions, or in some cases, billions of records in the database, those other platforms that a Microsoft-weenie boss might be using at home on his 12-record checkbook application just don't scale up for use in a real-world environment. If he or she is impressed with a sexy WYSIWYG GUI application they use at home, it is your job to let them know the i platform and RPG IV also support GUI applications.

When your company wants a new application, strongly suggest that it be written with a browser-based user interface.

When your company refuses based on "all the other applications are green screen", you must refuse their "we've always done it this way" argument and push for an iGUI solution.

If your company still refuses, suggest that they allow you to write the new application in both green screen and iGUI versions—this will let them see what the i is capable of doing and give you the much needed GUI experience. Remember, you're first five to 10 web-based iGUI applications may not be very user-friendly; you are a programmer, after all.

When your company still refuses, then write the green-screen application and, covertly (perhaps on your own time) write the same application using an iGUI interface. Then when you roll out the app, suggest that they take a look at the browser-based version as well.

If they still refuse, then accept it and continue this practice for the next four or five applications. Then when the new VP of IT is hired and says "green screens are old, we're going to Microsoft" you can say "we've got GUI versions of these applications already". So the "i" suddenly doesn't look so old.

If they still refuse, at least you'll have some web browser-based, iGUI application experience to add to your resume.

Bob Cozzi's RPG World Conference and ShowCase is September 20 to 22, 2010 in St. Charles, IL. Visit www.RPGWorld.com for details.

• Bob's website: RPGWorld.com is where you find all things RPG IV including our annual Conference and ShowCase.
• Bob on Facebook: Join the RPG World group on Facebook.com
• Bob on Twitter: Twitter.com/bobcozzi
• Bob's Software: RPGLIB is Bob Cozzi's sought after RPG IV add-on library of over 200 pre-written subprocedures. Everything from date conversion to API wrappers to conversion to CSV format. Download a free 30-day trial today at www.RPGLIB.com
• Bob's free software: RPG Open is Bob's free, open source service program that includes several core features missing from the RPG IV language. Check it out, its free: www.RPGOpen.com