Troubleshooting
Problem
This document describes why an iASP could be available, but missing files in the IFS.
Resolving The Problem
If a directory using the name of the iASP exists in the root prior to the iASP being varied on,
the vary on will complete and allow the iASP to reach an 'Available' state, but it will not
be mounted properly during the vary on process.
In the following example, the iASP is named iASP001:
In the job log, only message CPCA08C shows a successful creation of /DEV/IASP001. What needs to be seen is a successful creation and mount of /IASP001. Message CPCA1B0 would indicate the mount.
The common scenario that causes the problem is as follows:
1. IASP001 is issued a varied OFF.
2. /IASP001 gets unmounted and unlinked (deleted).
3. /DEV/IASP001 gets unmounted and unlinked as well.
An application runs which expects the IASP to be available. It performs a write to /IASP001/MYFILE. /IASP001 does not exist at this time (because the IASP was varied off), so the application auto-creates the /IASP001 and writes MYFILE into it. This means /IASP001 now exists in *SYSBAS.
1. IASP001 is issued a varied ON.
2. /DEV/IASP001 gets created.
3. /IASP001 fails the create and mount (because it already exists in *SYSBAS).
The typical message indicating the problem will be :
CPDB414 with RC1
File system failure. Independent ASP may not be usable.
RC 1 = The directory to be mounted over is not empty.
The user may, or may not, notice the mount failure in the vary on joblog. If the failure is not noticed, the user will attempt to access /IASP001 and notice "none of my files are there!"
The recovery is to vary off, save and delete or rename the existing version of /IASP001 out of *SYSBAS, and then attempt the vary on again. The proper method for this is as follows:
In the following example, the iASP is named iASP001:
In the job log, only message CPCA08C shows a successful creation of /DEV/IASP001. What needs to be seen is a successful creation and mount of /IASP001. Message CPCA1B0 would indicate the mount.
The common scenario that causes the problem is as follows:
1. IASP001 is issued a varied OFF.
2. /IASP001 gets unmounted and unlinked (deleted).
3. /DEV/IASP001 gets unmounted and unlinked as well.
An application runs which expects the IASP to be available. It performs a write to /IASP001/MYFILE. /IASP001 does not exist at this time (because the IASP was varied off), so the application auto-creates the /IASP001 and writes MYFILE into it. This means /IASP001 now exists in *SYSBAS.
1. IASP001 is issued a varied ON.
2. /DEV/IASP001 gets created.
3. /IASP001 fails the create and mount (because it already exists in *SYSBAS).
The typical message indicating the problem will be :
CPDB414 with RC1
File system failure. Independent ASP may not be usable.
RC 1 = The directory to be mounted over is not empty.
The user may, or may not, notice the mount failure in the vary on joblog. If the failure is not noticed, the user will attempt to access /IASP001 and notice "none of my files are there!"
The recovery is to vary off, save and delete or rename the existing version of /IASP001 out of *SYSBAS, and then attempt the vary on again. The proper method for this is as follows:
| 1. | Vary off the IASP. This should automatically un-link /IASP001 out of *SYSBAS (because the un-link code does not differentiate whether it exists in *SYSBAS or the IASP). |
| 2. | Verify that /IASP001 is truly deleted out of *SYSBAS using the WRKLNK command. |
| 3. | Vary on the IASP again. This should appropriately create and mount /IASP001 successfully. |
*NOTICE - Another reason why an IASP could be Available, but missing IFS data could be caused by a backup activity performing an unmount of the file system and not remounting when complete.
When a user or application tries to unmount the QDEFAULT.UDFS for an IASP, IFS code will automatically attempt to unmount the IASP QSYS.LIB file system that it is mounted over '/"IASPNAME"/QSYS.LIB'. The unmount of IASP QSYS.LIB is often successful, but then the unmount of QDEFAULT.UDFS itself can fail (typically with 'object in use'). That leaves things in a confused state until there is either a successful unmount QDEFAULT.UDFS and remount of it, or the IASP is varied off and varied back on. This kind of issue is often encountered with BRMS.
Refer to the following document for more information: Unmount User-Defined File Systems in BRMS
Using DSPASPSTS against the IASP and then pressing F7 to display STATFS, OR using the command STATFS OBJ('/<iaspname>'), the normal state of the IASP should show the File system type as "User-defined file system." If the File system type shows something like - "root" (/), then that is an indicator that either the directory was created while the iasp was varied off or got unmounted some how.
To attempt to locate the job which may have unmounted the file system, look in QHST for message CPCA1B1 (File system or directory unmounted).
To know if the file system was mounted, look in QHST for message CPCA1B0 (File system mounted).
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000000CHAAA2","label":"Operating System"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Version(s)","Line of Business":{"code":"LOB57","label":"Power"}}]
Historical Number
545070924
Was this topic helpful?
Document Information
Modified date:
15 September 2020
UID
nas8N1012598