IBM i > Storage > Disk

Enabling Applications for IASPs

Implementing your application in an IASP is easier than you think.

In this article, I'll define an independent auxiliary storage pool (IASP), also called an independent disk pool. I'll address some application considerations for moving to IASPs, including instructions specifically for JD Edwards applications.

When you finish reading this, I hope you remember three things: First, it's easier than you may have been led to believe to implement your application in an IASP. Second, now is a good time to ask your application provider to describe the changes needed to allow your version of the application to run in an IASP. Third, IASPs are critical to any availability plan, whether it's single-system, multipartition or multisystem.

Overview of IASPs

As the IBM* System i* family hardware grew from 5.5 CPW and 56 GB of disk in 1988 to 184,000 CPW and 380-plus TB of disk in 2007, the need for new constructs became apparent to OS/400* architects. These included:

• Eliminating single points of failure
• Allowing faster normal and abnormal IPL times
• Allowing users to consolidate multiple smaller servers onto more powerful hardware
• Enabling greater maintenance flexibility
• Allowing more granular cost-effective storage-archive capabilities
• Enabling i5/OS* to reach greater availability

All of this had to be done in a way that would be a natural extension of i5/OS and require minimal application modification.

The architects' answer was to extend auxiliary storage pools (ASPs) to IASPs in OS/400 V5R1.

Tweet