[adrotate group=”3,5,7″]
I was having a discussion with a business partner today about the new IFS auditing process when we started to look at what options to offer for each of the errors it found. Originally I was going to simply save and restore the object to the target system, but what about a directory? The problem is we have no idea what sits below a sub directory so we would have no idea what size the actual save of that directory would be (we would have to save all sub directories because nothing could exist on the target system!) or how many objects it consisted of. One option would be to simply create just the top directory because each of the objects reported in the audit that did not exist would have their own individual record in the error listing with a command we could build from the data from the source system.
Eventually we looked at the API’s IBM provides for the IFS to see if there was anything which would allow us to find out the number of objects involved in a directory as well as the total size. There is nothing, but we then thought about the Qp0lProcessSubtree() API, we are already using it to do the audit and it seemed very capable of providing what we needed.
The program we wrote is available for download on the download page if your interested in giving it a spin. Here is some sample data we pulled back when we ran it against our IFS structure.
This is for the /QIBM directory.
Directory Entered = /QIBM
Successfully collected data
Size = 3.5GB Objects = 39997 Directories = 4601
Took 7 seconds to run
This is for the /home directory
Directory Entered = /home
Successfully collected data
Size = 187.4MB Objects = 984 Directories = 373
Took 0 seconds to run
So based on the above we can see it took 7 seconds to collect the data about the /QIBM directory and all of its sub directories. The total space taken up by those objects is 3.5GB (this is actual space, it does not take into account any header data or padding). The interesting thing for me was the number of sub directories (*DIR) 4,601 plus 39,997 objects (*STMF). Another interesting point is the data in the /home directory, you can see it reported 373 (*DIR) objects and 984 (*STMF) objects, a quick look at the structure using the WRKLNK command showed these numbers to be vastly incorrect! We could not find that many objects so we decided to do a save of the objects to see how many actually got saved. It saved 1357 objects! Which is exactly what our API reported so where are the missing objects!
If you look in the /home directory you will find a sub-directory called QIBMHELP, if you look in that directory you will see it is empty. But when we run the test against that directory we find the following.
Directory Entered = /home/QIBMHELP
Successfully collected data
Size = 17.3MB Objects = 263 Directories = 332
Took 1 seconds to run
So where are these objects? Doing a save automatically saves all the objects and if you start journalling against the directory you will see all of the objects listed! IBM must have set some hidden attributes for the objects because you cannot see them when you use WRKLNK but they definitely exist and do get actioned by the various API’s. One thought is the objects all sit in a directory .eclipse so maybe the fact that it starts with a ‘.’ is keeping them hidden? If you look at the directory using OpsNavigator or a mapped drive they show up….
If you would like to give the tools a test run just download the save file from the downloads page, restore the objects into your favorite library and give them a run.. There is a command RTVDIRSZ and a program of the same name. We have saved the objects back to V5R4 and they were saved from CHLIB..
If you have any questions let us know.
Chris…