midrange.com - In My Humble Opinion

I was sitting here at my desk after replacing the window motor in my van pondering this thought:

"Man, I think JSF is trying to emulate the RPG cycle with it's 'Life Cycle' (click here), the exact thing that so many RPGers are trying to get away from."

Or maybe it is better stated to say I hear many wanting IBM to rid RPG of it "legacy" features. I must admit that I have held my hand high with the same chant, though now I must recant. Yeah, I know I am making a stretch to say the JSF and RPG cycles are the same, but none-the-less the Java community is trying to adopt cycles which RPG has had for how many years now?

Makes my head spin to see all the excitement in the browser framework world. Seems like we are always trying to get back to what 5250 screens have had for such a long time - ease of user interface development. No, I am not ignorant to the fact that green screens aren't very appealing, but the reality of it remains that if RPG had a new GUI face (and maybe a syntax facelift), it could arguably take the application development industry by storm. Just look at all of the efforts by Sun, Microsoft and Adobe to make yet another, "thicker" browser with their JavaFX, Silverlight, and Flex3 respectively.

Makes me wonder how "legacy" RPG and it's infrastructure really is. I have been with the language for about 10 years now and I left RPG for awhile to have some fun with Java. I loved Java at first because there were some really nice and flashy things that made my heart twitter (twitter would be like the first time you sit next to your future wife, but before you give the first kiss). But even when I factor in how fast you can write Java code, it still comes down to long-term support of the applications built. The Java frameworks out there are very nice, but I can't count the hours I have spent trying to make something work in Hibernate or MyFaces that just wasn't meant to be because the writers didn't have forethought of how others might need to use it.

That's what keeps bringing me back to RPG, DB2 and i5OS - the trio that just doesn't die. It has the best framework out there, mostly because you don't even know you are in one! I can't help but think what would happen if the cycle was modified to work with a new GUI interface that was native on the i5. Platform independance (i.e. EGL/Java)? Phooey, that is what vendors (of which I am) say to make people think they need their product. I would much rather have "The Trio" to keep my business running efficiently and reliably at a reasonable cost. When will IBM catch on to the potential gold mine they have already built - it just needs "tweaking". We can dream can't we?

Well, it is time to go back to work.

Oh, and on last note, if you haven't already, please add the following to your list of blogs to visit: iDevelop

How did we do? Well, it has been a mixed bag. Our interest in keeping the solution cross platform quickly ran aground as we faced the difficulty in getting the more entrenched RPG programmers to embrace Java as well as finding Java programmers who were comfortable in the System i world. We also got some push back from customers who also did not have the Java programming resources to grow and enhance the solution. We also began to use, through the hiring of an individual, an ILE RPG CGI framework that would be more "comfortable" for the RPG programmers to use and be more productive. This two pronged approach was completely wrong for a host of reasons and has hampered, IMHO, the overall solution. The business model we used, using support revenue to fund the development of an Open Source solution is actually a good one and has been successful overall. Had those resources been more carefully managed, matching development costs more closely to the revenue model, it would have been an excellent way to grow the overall effort.

Focusing on the development approach: We completely underestimated the effort required to build a web application. I don't care whether it is written in Java or ILE RPG, the skill set needed to develop a UI using HTML, CSS and Javascript plus backend business logic and framework components completely overwhelmed our programming staff. It was recommended very early on that we hire at least two "HTML Monkeys" (as one programmer called them) to offload the UI to folks with the proper orientation to UI. That recommendation was never followed but would have saved countless hours of programmer time. I honestly don't think a programmer should be designing a UI in a web solution. Period. I also don't see any more productivity in either ILE RPG or Java (the only two programming languages we used). If the programmers could have focused on writing business logic and enhancing the framework, rather than designing UI, we would have been much better off.

If I was starting out today with the same code base and the same goals, I would do the following:

1. Use HATS to get a web interface in front of the customer NOW. I would do this because the lengthy wait for a completed solution led to some attrition in the customer base. Better to have a transitional technology in front of the customer now to hold their attention rather than to try to hold them with promises. HATS was not mature enough in 2002 and the System i not yet powerful enough to make HATS a viable solution at the time. It is ready for prime time now.
2. Decide on a single programming language and go with it. Personally, I like the idea of Java on System i because it makes a solution potentially portable to other platforms while leading with the strengths of System i. However, ILE RPG is a "natural" for the System i and many folks who are already on i are more comfortable writing RPG code. Naturally, RPG will be more productive for RPG programmers and Java more productive for Java programmers (duh!). But there is nothing inherently more productive about either language (although the OO nature of Java might lead to more productivity over time, IMHO).
3. Find a framework that is productive. Tough call here and this is where the "missing link" comes in, particularly for RPG programmers. IBM provides no tools or frameworks in RPG that made the move to the web easier. CGIDEV2 was a community response to that deficit,and a good one, but this deficit in in IBM supplied RPG web frameworks still remains. When I look at other tool providers, the successful ones who had proprietary languages that did text based applications migrated their tools to the Windows UI and then on to the web. Microsoft in particular did a great job with this, moving Basic to Visual Basic to VB.NET. Yes, very different languages but MS at least developed the solution (or bought it) and got it in front of their developers. IBM got with the Windows GUI program with Visual Age RPG but then when the web appears they did ... ? I am mystified that IBM who fully "owns" RPG and clearly saw the web as the next UI wave simply froze and did nothing to enhance the language to easily get applications to the web. What were they thinking?

We have an awesome platform, loyal customers, and a cadre of programmers just dying to cut their teeth on an IBM supplied, leading edge, ILE RPG based web framework. Where is that web framework, now 12 years after the popular advent of the Internet? That is the missing link. A "link" sorely needed as the platform struggles to maintain market share.

There are many, many other lessons learned from this experience and I am certainly ready and will to share them. Feel free to chime in.

We initially began our iSeries modernization process with writing custom web apps using WDSC utilizing the Webfacing feature. I first learned about WebFacing at COMMON in San Antonio in 2004. At the time it seemed like the answer we were looking for. So, I purchased Claus Weiss' book "Understanding the IBM WebFacing Tool." This is a great read and walks you through step-by-step on initially getting your custom iSeries apps to the web and also helps you customize the WebFaced app to suit the users needs.

However, from the time I deployed our first WebFaced app on our WAS Express 5.0, we began seeing lots of performance issues. The performance hit was only on the web side of things and was having trouble processing multiple requests. For example, one of the main issues we had with any WebFaced app was every 9 to 15 clicks of the mouse where the iSeries had to do something, the app would hang for around 5 to 8 solid minutes. Seeing this, I submitted a PMR to IBM and I got the dreaded response, "We've never seen anything like this before." So, we tried putting on some PTFs to hopefully fix the problem to no avail.

After a year or so of doing this, and a managerial change in my department, we decided to investigate CGIDEV2. I put together a few test programs just to see if the performance was the same as a WebFaced app. There was no comparison in performance. The difference was like night and day. My new manager was highly impressed and was wondering what language it was running behind the scenes. When I told her it was RPG, she didn't believe me. So, I had to show her what was really going on and she was floored. All we needed to do was convert the DDS screens to html, rework some of the RPG programs to utilize the CGIDEV2 APIs and add a few lines into our Apache configuration file and Viola!

Since that time, all of our WebFaced apps are now on CGIDEV2 and we're not looking back. This has truly been the answer to our iSeries modernization prayers. In a world where a sexy look and high performance is what users desire, I don't see how anyone can drink the WebFacing kool-aid.

Don't get me wrong. I think WebFacing is great for getting custom iSeries apps to the web fast. However, I truly believe that it's a short term solution. We have had an overwhelming number of positive responses to the new apps in CGIDEV2.

[tags]webfacing, cgidev, ibm, common[/tags]

Five years ago I started a company with a few other folks who were trying to "save" a school administration system that was written in RPG that we did not own. In this particular case, the company that owned the software and the source code was really just using the customer base as a revenue source while they pushed the customers into other school administration solutions that were not System i centric. You may have heard of PowerSchool, once owned by Apple, which is now owned by this same company. How a company that initially acquired the premier IBM Midrange (S34/S36/S38/AS/400) school administration system (once sold through IBM!) could end up selling a solution that runs on an Apple platform is a long, ugly tale that involves hundreds of folks and millions of dollars. But, the bottom line here is that IBM failed to capitalize on and captivate the mind share of system administrators that really needed a stable, reliable and easy to administer system. That failure was demonstrated in the reality that the company that acquired this software back in the 80's missed the fact that the true asset was the system the software ran on, as well as the software itself. The hardware was the key to the solution, not just an interchangeable component of it. As the software solution was bought and sold a few more times, the beauty of the platform was lost to the need to look more "modern".

But, that was also a bit before systems started to become commoditized. Commoditization has hurt the System i platform prospects because the system can run so many application that people miss out on the fact that running applications is only part of the solution. Running applications in a stable, reliable and easy to manage environment is the key. It is the holy grail. The System i has that. It is a slam dunk reality that no other platform, IMHO, can match.

So, now the issue for us System i die-hards is, the RPG applications of yesteryear, like the school administration solution I originally mentioned, are essentially unchanged in their 1980's look and feel. That is precisely because of the stability of the System i. I have customers who I trained on the System 36 version of the software in 1987 that are still running the follow on version of the software on the System i today. In some cases they are using data that was keyed in on a System 36 and migrated to the System i with minimal disruption. They love this platform and, in smaller school districts, they have managed to keep their IT staff to one or two people when it comes to running the school administration solution. In one case, I consulted at a district that had NO IT staff for the System i school administration system, just a janitor who swapped the tape out of the drive while he cleaned at night. Compare this to the instructional solution arena where there might be many, many IT people needed to keep the network, application, database, web and email servers running. From a management standpoint, it is a nightmare.

So back to the "missing link". Here is the reality of the marketplace we were facing when we started up the company:

1. Loyal Midrange customers. Some had been using versions of the software for 20 years.
2. Green screen stability was losing to GUI "glitz and glamor". PowerSchool looks great! Our solution looked like "DOS".
3. The "AS/400", although stable, was seen as a dinosaur.

Our decision, for better or for worse, was to lead with the System i. We didn't have source code so we had to rewrite from scratch. We used the database on the System i and released the code as Open Source. We were going to focus on a web based solution rather than a plump or fat client. We initially chose Java as the programming language because we could write code that would run (theoretically) on any platform. That would alleviate the need to fight the hardware battle during the sale of a system (although we would lead with the System i in all cases). We could continue to support customers running the RPG version of the code while we delivered a web version. They could use both simultaneously since both solutions used the same database.

Five years later, how did we do?

Continued in part two...

I have started to read more of Timothy Pricket Morgan's (from here on out written as Tim) articles and am liking how he approaches the usefulness of the iSeries. What I mean by that is he realizes that some significant ground could be made in the RPG programming realm if the higher up stiff necks at IBM would come to realize the goldmine of potential they have with the RPG programming language. Read the following post of mine on the web400 archives to see where I am coming from.

I am going to take a little risk here and state NONE of the higher ups making final decisions for not giving RPG due recognition for viable future development have written much RPG code at all (or maybe better stated, they haven't done so in the last 10 years which seems to be the period of RPG's evolution), so it is hard to say that they have the right perception of RPG to make the decisions they are making - to say it bluntly they have second hand information that is mixed with much hype of other promising languages. I am surprised that they take the stance they do based on what I hear coming from George Farr who is making some great (and fairly vague) statements about possible new framework level changes coming in RPG.

For the record I will say that about 50% of my development is done in Java (mostly J2EE, but also a lot of J2ME and J2SE) and I feel I can make appropriate high level opinions to state that if IBM spent 1/10th the time on RPG enhancements and tooling as they do with Java that RPG could be the next big thing that bring people to IBM iSeries hardware. Note that I specifically said iSeries hardware. I don't believe that making a language like RPG platform independent brings a lot of glory other than from geeks like myself. Want proof in the pudding? Take a look at C#.NET. It is grown to the same industry acceptance as Java in about 3 or 4 years, and it took Java 10+ years. By keeping the C#.NET focus directed towards Windows machines Microsoft is afforded the same niceties we have by keeping RPG only on the iSeries. (Note: I am talking mainstays. Yes I know about the .NET Mono project, and yes I know about RPG being able to run on select IBM mainframes).

Here is Tim's comments that invigorated me to write on the topic. Keep up the good work Tim and let us know if your voice is heard.

Every saga needs a hero, of course, and IBM could, in fact, be that hero if it thought a little outside of the box. (To be fair, by backing down on this compiler issue, IBM is being the hero.) For years, IBM has been trying to use positive reinforcement (RPG IV has great new features), and negative reinforcement (we are killing the old compilers), to get people to try to get companies to move ahead. There might be a better way to get people to move. For instance, what if IBM actually offered really good porting tools and services at a reasonable price to help customers make the jump? It could work with third parties to do this, of course. And what if IBM gave customers goodies if they made the jump. Say, a free six months on a lease of a new System i5? Free Web-enablement for the first 25 or 50 screens? If IBM wants customers to all be on RPG IV, it has to give them a compelling reason to do it. What if someone with some clout--someone like Bill Zeitler, who runs the Systems and Technology Group, or Sam Palmisano, chairman and CEO at IBM--actually said in a Webcast or a presentation that RPG and COBOL have a future, that these are perfectly reasonable alternatives to Java and C#, and made the case why companies should continue to code in RPG or COBOL instead of other languages?

- Timothy Pricket Morgan IT Jungle June 26, 2006
[tags]iSeries, RPG, Mono, IBM, Java[/tags]

By now most everybody has heard of the term SOA which stands for Service Oriented Architecture and if you are like others, including myself, you have been inundated with high-level zero-informative type explanations that abstract the definition out to the point of no return. In this blog entry I would like give my take on SOA as it relates to a programmers mind and what I feel the moniker should really be.

Way back in the day when you wrote your first program there was most likely the "Hello World" application that gave you enough gumption to keep on trucking with your IT intentions. Through your first couple months of programming you most likely found places where code was repeated and thus created a maintenance nightmare in trying to keep all instances up to date. If you were fortunate enough to have a modular programming language (i.e. RPG ILE, Java, .NET, PHP, etc) at your disposal you could then take the chunks of code that were repeated in each program and make a separate callable "function" that could be used time and time again.

Wanna know what modularizing your code accomplished and what title you can now add to your next review/resume? That's right, you are now a bonafide SOA programmer. How is that possible being that SOA is just now surfacing being preached by the masses as the "next great thing". Well, someone, while walking from the couch to the fridge, manufactured this great concept called "web services" as a means to allow two different languages on two different machines/OS's to "call" each other. While reaching for the brick of cheese in the fridge they came up with the idea to use HTTP as the transport protocol and XML as the data carrier. Walla! We now have web services. But wait, we need to give this a solid name that will cause IT managers to give us programmers something to research during our lunch hours. So on they way back to the couch, and three mouthfuls of cheese later they came up with the name Service Oriented Architecture. By the time it reached ears the could have named it more effectively SOA had been made into a formidable house-hold name by the forum junkies - so here we are with "SOA".

Wow! A trip to the fridge can revolutionize the IT industry!

To summarize: If you have written RPGPGM1 that calls RPGPGM2 you have effectively written a Service Oriented Architecture. This latest round of hype is based on the fact that instead of relying on RPG prototypes for passing parameters (or *PLISTs) and OS/400 for making the communication from one program to the next we are using WSDL's, XML, XSD's, SOAP and HTTP to accomplish the same task - essentially recreating the program call interface with technologies that are 100% text based. I think a more appropriate name would have been WOA (Web Oriented Architecture) because that denotes more of what is actually occurring and what has changed from our legacy SOA. Not only does it describe it better, but it is much more fun to say in meetings: "Who wants to work on the WOoooaAA project? [all hands go up]"

Just remember, you heard of WOA here first on imho.midrange.com! Comments anyone?

[tags]iSeries, SOA, Web Services, Service Oriented Architecture, XML[/tags]