LUG Issues Call to iASP Arms for ISVs

February 28, 2011 Timothy Prickett Morgan

The computer business is cryptic, and you have to be playing inside baseball to understand that headline. The LUG is, of course, the Large AS/400 User Group, a non-profit comprised of the largest IBM i shops in the world. ISVs are, of course, independent software vendors who peddle products for the OS/400 and i platform. And iASP is not the International Association for the Study of Pain or the Indiana Association of School Principals, but rather the independent auxiliary storage pool feature of the OS/400, i5/OS, and IBM i operating system family.

I have seen a lot of bad definitions of what iASPs are, but what the heck, let me give it a shot, too. Not only does the AS/400 and its progeny have single-level storage, which means the operating system creates a single address space comprised of main memory and disk capacity that applications and their databases can reside in, but the physical disk storage in the machine has a layer of virtualization abstraction that sits behind this single-level storage framework and in front of disk controllers and the drives that hang off them. Back in the days of V5R1, the system itself took ASP 1 and that left system administrators with ASPs 2 through 16 to create as pools. The pools segmented the virtualized storage capacity behind the single-level storage of the AS/400 system so you could tie specific data sets to specific disks and controllers. In other words, ASPs kind of defeated the some of the purpose of having single-level storage in the first place. But, ASPs allowed you to put data that your applications needed in a jiffy on the fastest disks and controllers in the system and plunk less-frequently used data on other devices in the system on their own ASPs. Your RPG and COBOL applications still saw a big address space and you didn’t need to have applications messing around with moving data from disk to memory and back again as it was changed.

With V5R1 back in 2001, the concept of independent ASPs was introduced, and as we reported when V5R2 was launched the following year, the technology moved from interesting to usable. The ASP count went way up, with ASP 1 dedicated to OS/400 itself, ASPs 2 through 32 being dependent ASPs that functioned just like ASPs of old, and ASPs 33 through 255 being independent.

With iASPs, you can consolidate multiple physical servers and their databases and files onto a partition, keeping the ASPs (and thus their files and databases) for each server logically separate from each other so you don’t have to change anything, and you don’t end up having to consolidate languages and databases, but you still get the benefits of single-level storage. iASPs also let AS/400 administrators set up ASPs that could be shared by multiple systems–that’s one interpretation of what the word independent means. This is something of a technical feat when you realize that swapping a batch of disks from AS/400 machine to another is akin to me allowing you to use my frontal lobe for a while. Disk is main memory in an AS/400, so taking a chunk out while a machine is running is very tricky stuff if you don’t want the machine to go offline. But it is also very useful, particularly if you are clustering whole systems or logical partitions within them for high availability failover, or if you want to be able to move workloads from machine to machine as you do planned downtime for system maintenance. So IBM made the investments and gave OS/400 something akin to a lobotomy that you can turn on and off.

Maybe International Association for the Study of Pain is not so far off, after all.

Anyway, iASPs are meant to be used in conjunction with high availability software clustering, not as a replacement for it. (Something has to do the thinking at the application level, after all, and manage the failover.) The technology has been evolving from V5R2 through V5R3, i5/OS V5R4, i 6.1 and now i 7.1.

That brings us to the LUG. As The Four Hundred divulged in its exclusive report on the LUG two years ago, the super-secret organization has bugs in all of the data centers of the world, and when a CFO overrides the CIO and forces a marched “upgrade” from an AS/400 system to a Windows or Unix box running SQL Server or Oracle, ninjas from the AS/400 LUG, wearing the black of the iSeries systems with red and gold stripes on their temples, sneak into the data center and make the “upgrade” to Windows and Unix fail, protecting the long-term business from its own short-term folly.

OK, so the LUG members don’t actually do that. But wouldn’t it be nice?

What the 110 shops that make up the LUG actually do is band together and use their collective buying power–they have an aggregate of over 25 million CPWs of OS/400 and i capacity–to influence the technology roadmap, pricing, and other aspects of the AS/400, iSeries, System i, and converged Power Systems product line. In fact, it is a safe bet that the convergence of the AS/400 and RS/6000 was driven by these large shops as well as the complaining of thousands of other customers who were frustrated by the higher prices all components on an AS/400 had compared to an RS/6000. My guess is the LUG had more influence than the complainers like you and me.

Back in mid-January, the LUG issued an open letter to the IBM i software development community telling them, in essence, to get with the iASP program.

“The reason we are contacting you is that we have been hearing from our members that their companies are eager and ready to implement the Independent Auxiliary Storage Pools (iASP) technology to improve system availability,” the LUG open letter states. “However, our members find that they must delay IASP implementation because many of their existing applications provided by different ISVs do not support iASPs.”

The newsflash for me is that ISV applications need to be tweaked to support iASPs. But apparently this is the case and I have a thought about that. But let’s see how the big i shops apply pressure first:

“The LUG members feel that iASP adoption by the IBM i ISV community is critical to ensuring that companies all over the world can continue to rely on IBM i to run their businesses. In some instances LUG companies are making iASP support a requirement before selecting any ISV software. Thus, we are challenging the entire IBM i developer community to add iASP support into their short-term product plans,” the letter goes on. “We believe that all of us (LUG, ISVs, and IBM) are all working for the same end goal–successful business on the world’s most reliable integrated platform.”

The iASP technology is obviously a good thing. But it violates one of the cardinal rules of the AS/400 philosophy, and that was to not require customers to do a recompile when new technologies are introduced on the system.

IBM has violated that rule three times in the history of the System/38-AS/400-i family: once in 1988 with the jump from the System/38 to the AS/400, once again in 1995 with the jump from CISC to PowerPC chips, and again in 2008 with IBM i 6.1. And each time it has caused pain. The price/performance advantages moving from System/38s to AS/400s were so compelling that it didn’t matter, and the PowerPC-based AS/400s offered more than twice the bang for the buck as the CISC machines that came before them. Small wonder that the late 1990s were the last boom years for the AS/400. The price/performance improvements moving from older iSeries and System i machines to Power6, Power6+, or Power7 machines is much less impressive and companies are wrestling with so many issues that migration gets back-burnered. And sometimes, ISV applications have not been converted to run on i 6.1 or i 7.1 or ISVs want big bags of money just because the Power7 machines customers can move to are in higher software tiers than the machines they are moving from. All of this provides a disincentive for customers to move ahead and for ISVs to do business.

I don’t know why iASPs are not or cannot be made transparent to the application, but if this is such a big deal, then maybe that is the answer. 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 I fail to see why another virtualization layer or shim can’t be made to have an application think it is using ASPs when in fact it is using iASPs under the covers.

But what do I know. I am not a member of the LUG or IBM. I am just a hack that likes to write about systems and try to help. If such a thing cannot be accomplished, then LUG is right. IBM and ISVs have to get in gear and get their apps working in conjunction with iASPs. And you know why? Because iASPs are going to be necessary to fluff OS/400 and i applications into the clouds.

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search