Red mercury: the AS/400 IDE

Don’t get me started on IBM’s mismanagement of the AS/400 development environment, because I’m obsessive-compulsive on this subject.   AS/400 hardware is the best on the planet.  i5/OS is slick, and based upon the functionality it provides, nearly bulletproof.  SQL performance is pretty good; SQL functionality is okay (take a look at SQL Server 2005/8 if you want to see some cool stuff); ILE RPG is okay (when are you going to finish it, IBM?  ASNA’s had a fully free-form RPG for years).  But IDE development management has been gutless and devoid of a creative thought for 20 years: there’s been zero leadership by IBM’s development product managers, who apparently share a systemic inability to demonstrate to IBM’s suits the unique value proposition the AS/400 world offers to customers.  I suspect this group is in charge of e-mail for the Bush administration.

While IBM’s marketing of the AS/400 has been problematic, it’s much better today.  The problem is, the product is an empty suit.  Unless you’re running big batch jobs all day, of course.  If IBM wants to sell new accounts, developers need the tools to create highly-functional and easy-to-use applications in today’s vernacular: the browser.  If you can’t demonstrate an application that “works like every other desktop application” (and in many cases, able to be offered in SaaS mode), you’re screwed without a kiss.

That sucking sound you hear is the AS/400 market going away.  LAMPPP and .NET are cleaning IBM’s clock, and I’m both saddened and pissed off, primarily because IBM has bungled this product.  Meanwhile, I’m moving forward.  Sure, V6R1 is neat…but it doesn’t go nearly as far as it needs to.

Trust me on this one: when you learn how the real world handles development and IT, you’ll see what a great job IBM has done in insulating AS/400 shops from the real world.  And in spite of what you think, the AS/400 runs a pitifully small percentage of mission-critical applications.  While the hardware and O/S are capable, the IDE is so awful that the best features are discounted right out of contention.

Now, none of this means AS/400 shops aren’t providing value for their supporting organizations.  But new business and technology requirements are slowly marginalizing the value of the AS/400, and, without a complete change of direction on IBM’s part, the ability of AS/400 shops to move forward is deteriorating.   A typical shop has to take a completely different approach for developing a customer portal (web) than for developing internal applications (green-screen).  Does a good web designer/developer want to work on green-screen?  ROTFLMAO!  Does a good green-screen develop want to fiddle-faddle with developing a web site with a garage-band look?  Maybe, and it happens too often, and it shows.

IBM’s trying to hang the moon on Eclipse and WDSCi.  But here’s the truth: this is IBM’s red mercury.  Listen, folks-if you want to see an ass-kicking IDE, get on a first-name basis with Visual Studio 2008.  Don’t give me any of your childish geekwad ”evil empire” crap: Microsoft has a huge group (at least 10x larger than the WDSCi group) working on Visual Studio…and it shows.  In addition, Visual Studio Team System provides outstanding development management capabilities.  Is VS or VSTS cheap?  Nope…and as I’ve been telling IBM for a decade, I’ll be happy to pay $5K or more per seat for a great IDE, because even a merely good IDE has a 30-day payback.  Instead, we get a ”free” IDE from IBM that about as valuable and as useful as the crappy bait-and-switch software that comes preloaded on a Gateway entry-level PC.

Just how long has the AS/400 crowd been waiting for a fully-functional WYSIWYG screen designer?  I rest my case…and if you think SDA is full-function, you haven’t been paying attention: try using *DATE, *TIME, or *TIMESTAMP data types, or ENTFLDATR.

Netting it out: activation groups for the rest of us

Why do some overrides not work, like OVRDBF FRP001 SHARE(*YES), when I compile an RPG program?  Because activation groups work like “sub-jobs”; AG’s give you the ability to control overrides for different programs running within the same job.  So, if the calling program (CL or otherwise) is running in *DFTACTGRP and you carelessly compile an ILE RPG program with the QILE activation group, overrides won’t work.

One solution is to set your overrides with OVRSCOPE(*JOB).  If you check the default for that OVRDBF parameter, you’ll find it’s *ACTGRPDFN; this works fine if everything is compiled with the same activation group.  OVRSCOPE(*JOB) means “this override applies at the job and regardless of the activation group.”  *CALLER means “run this program in the same activation group as the program that called it.”  So, OVRSCOPE(*ACTGRPDFN) usually works for *CALLER…but QILE is a different activation group, and the override doesn’t apply.

Here’s the bottom line: IBM made a huge error by setting QILE as the default activation group in the CRTBNDRPG command-it should have been *CALLER.  Using *CALLER preserves existing behavior; using QILE doesn’t.My solution is to use XXM767 (my standard object creation program) for all compiles and object creation.  It’s a poor solution but it’s a standard and therefore far better than hand-compiling. 

There’s another solution: include an “H”-spec copybook with DFTACTGRP(*NO) ACTGRP(*CALLER); these parameters will override the compile defaults.  Of course, CL doesn’t support copy books, and commands don’t support external references (for parameter attributes).

In the real world, with source code control and where you do a build every day and drop everything when the build breaks, problems like this go away.  Unfortunately, most AS/400 shops (I’m trying very hard not to offend anybody!) haven’t recognized the value of a formalized process for managing the journey of source code from the developer to the production environment.  The fact that IBM hasn’t provided this key component of a well-rounded and fully-realized system is a shame.