Some Insight Into the iASP and ISV Issue

March 7, 2011 Timothy Prickett Morgan

In last week’s issue of The Four Hundred, I made a logical leap about the problem with supporting independent auxiliary storage pools, or iASPs, that has caused the AS/400 Large User Group to issue a call to arms to compel independent software vendors to support this decades-old feature of the OS/400 and IBM i operating system. While the logical leap I made concerning the root cause of the issue was incorrect, I stand by my assertion that IBM should have made iASP technology transparent to ISV applications and therefore inherently supported.

The AS/400 LUG, in case you don’t know, is a non-profit organization of 110 companies that run IBM i systems that represent an aggregate of over 25 million CPWs of processing capacity. They are among the largest and most influential (with IBM and ISVs alike) IBM i shops in the world, and they tend to keep their identities hidden, like Batman and Superman. But they want ISVs to support iASPs.

I already explained what iASPs are and why you would care in last week’s story, so I am not going to get into it here except to say that iASPs are a necessary technology to support clever server consolidation, offline system maintenance, keeping applications running, and other high availability setups. What I didn’t know, and what the AS/400 LUG didn’t say, and what no documentation I could lay my hands on last week explained, was why ISVs were having trouble supporting iASPs. The reaction of one reader of The Four Hundred was typical of the letters I received last week from IBM i users:

Hey, TPM:

I have a sneaky suspicion that application issues are caused by this scenario. This includes moving volatile data to iASPs and leaving software/compiled code separate. Third-party apps leave data areas/settings/some control files in the program library.

Applications sometimes also have built-in housekeeping functions that would need commands overridden to include your in-house iASP configuration in parameters not set by the app.

It’s an interesting message, though, and I hope you find out what the real reason for this to be brought up is.

Regards,

–John

The leap I made was that somehow support for ISV applications involved a recompilation of code. But some techies I trust were quick to explain this was not the case.–TPM

Timothy:

You say that iASPs require recompiling things. This is not the case, so far as I know. The effort to put our applications on an iASP involved no compilation changes. There was a need to use a slightly different setting in the Apache Web server config file. An update might take a bit of manual work–something we already had to do with certain FTP settings.

So this was a piece of cake to say we can support our applications on iASPs. Other vendors will have different mixes of objects that cannot live in an iASP.

By the way, iASPs are not just for high availability. There can be standalone iASPs, and they are ideal for having test and production environments on one box, or to have separate data libraries for different entities served by a service provider, say.

We are looking at LUG’s letter–there are possible licensing issues for us. But we already have one LUG member running our WebDocs application in a standalone iASP. No sweat!! And that’s good news, right?

Vern Hamberg, software architect
RJS Software Systems

Yo, Timothy:

There are no recompilations required to support iASPs. As with any new function on the IBM i platform, certain changes to existing procedures are required to implement them correctly and efficiently. In most cases, the change is as simple as moving the library to the iASP, and putting the iASP name in the Job Description (*JOBD) so the application can find the library. That’s it. I don’t want to oversimplify it, but, this is nowhere near the extent of a CISC-to-RISC. Over the next few weeks I’ll elaborate on this, giving your readers the basic ins and outs of iASP implementation.

The basic issue with most of the ISVs is the term “support.” Having been through this with a few of them recently, it is question of an unknowledgeable end user calling the ISV for support when there is a problem. In order for an ISV to support iASPs, they have to be familiar with the new technology. In order to do this, it requires an investment of people, time, and in some cases dollars. (Well, it’s all dollars, really). In this economy, it’s really tough coming up with those kinds of bucks.

DLB Associates has implemented many iASP, geo-mirroring, and PowerHA strategies over the last few years, and is currently certified for PowerHA for i implementation. We’ll be following up with a few articles in this regard in the near future.

Douglas Bidwell, systems engineering manager
DLB Associates

If money and support are the problem, then I will reiterate what I said a week ago: Maybe iASPs should be made transparent to the application and managed at a lower level in the virtualized system, like logical partitions already are. (Just to name one example of the many different kinds of virtualization used in the OS/400 and i platform.) If a logical partition can trick an application stack into thinking it is running on a whole physical machine when it obviously is not, then why isn’t there a virtualization layer that can trick an application into thinking it is using ASPs when in fact it is using iASPs under the covers?

The need to support iASPs is just as important for homegrown RPG and COBOL applications as it is for the ISV applications that the AS/400 LUG wants to have iASP support for. And as I said last week, I think iASP support is going to be a key needed component of moving OS/400 and i applications to cloudy computing. So we best get in gear and start making this easier and transparent like all good AS/400 technologies properly are. And that was my point both this week and last week.–TPM