The independent auxiliary storage pool (IASP) is the strategic building block for availability on IBM i. There is a lot of mythology around migrating to an IASP environment, and some extremely wild estimates about the complexity of migrating. The reality is usually considerably easier than most people would imagine!
IASPs can be used as a standalone method to isolate applications and their data from the operating system (which is pretty much standard practice on most platforms) or as part of a High Availability solution. The options for High Availability range from operating system based replication using PowerHA, through to high end three site solutions using PowerHA, the lab services IASP Copy Services Manager and hardware based replication provided by IBM storage solutions. In addition you can take advantage of the hardware FlashCopy technology to make near instantaneous copies with minimal impact on production operations that can then be used for backups, reporting, testing, data warehousing extracts and so on.
Actual customer experience today is that by migrating your application to an IASP and making some simple work management changes you can be up and running with the IASP in very little time at all. The largest time spent in migrating is the time you spend on testing your application in the new environment. With this in mind, you may wish to consider using the same testing to validate your application on a new OS level at the same time.Pointy Headed IBM Blokes
And its true.
Turning on the iASP is very simple. As simple as adding the iASP name to job descriptions, or runtime environments. If you dont have the iASP name, you simply cant see those iASP libraries.
One thing to remember is that by default the IFS (Integrated File System) and of course things within the IFS like the QDLS (IBM Document Library System) live in the system base area.
But we can move the IFS into an iASP storage area #huzzah
The Integrated File System typically divides into two categories
This is where an IFS document is prepared for transmission to an external system or for a dodgy old FAX solution. Effectively TEMP storage, this type of use does not normally need to be migrated because the files are expendable and only stored while they are being processed.
Remember – we have a network share name which points at a phsyical IFS or DLS location.
Moving the IFS location just means we need to make sure the share is updated with the new IFS location. So, its transparent with no changes to your users who use those shares.
Why does anyone use the DLS any more?
If you are still using the DLS then shame on you.
DLS uses the old DOS based file naming stadnard (8 character with 3 character), has no security and is a throwback to the 1980’s
So, obviously you want to move your DLS files into a secure IFS folder and then create new shares to point at the new location.
But, you will also want to sniff out any old programs that are loading files into the old DLS locations and update them as well.
Update old DLS CLP programs to use the IFS instead
Luckily, IBM i makes it easy to find the programs which use the QDLS.
For example, if the QDLS commands you are looking for include CPYTOPCD and CPYFRMPCD, we can use the “Print Command Usage” command to list them all out:
PRTCMDUSG CMD(CPYTOPCD CPYFRMPCD) PGM(ALLUSR/ALL)
You might also want to look for modern “Import File” commands and make sure they are not using the DLS:
PRTCMDUSG CMD(CPYTOIMPF CPYFRMIMPF) PGM(ALLUSR/ALL)
You will now have two big spool files, with all the programs using these commands. Check the last used dates to see if they are still relevant.
Now consider your options for converting the CPYTOPCD to a CPYTOIMPF, and the CPYFRMPCD to a CPYFRMIMPF, using a prefix ahead of the directory name to point to your new path in the iASP.
You could also write your own version of the command, where you control the iASP name using your own business specific logic.
That’s a step in the right direction
:thumbsup and good luck!