Q: I've been using your IFSDIR tool to read IFS directories from SQL. It works nicely, letting me query different attributes and so forth. However, your UDTF doesn't seem to contain the file's create date? Is there some way I can find out the create date?
Q: We had an IFS file that someone checked out with the CHKOUT command. It stayed that way for a long time before we figured out what was going on! I'd like to write a program that looks up who has IFS objects checked out in some of our more critical IFS directories. I was thinking about using your IFSDIR UDTF for this. But it doesn't list who has an object checked out! How can I adapt it?
A: This article contains an updated copy of IFSDIR that includes these two additional columns in the UDTF.
The main reason my IFSDIR UDTF didn't have these features to begin with is the fact that it was written using the stat() API. The stat() API is a simple way to get information about an IFS object. You pass it two parameters: the first one is the name of the IFS object you'd like information about, and the second parameter is a data structure. The API will then populate the data structure subfields with information about the file you provided.
However, the stat() API is a Unix-type API. IBM has deliberately made this API work exactly like the one available on Unix systems. Unfortunately, the "create date" is not consistently available in Unix circles. Unix tools always have the access date, modification date, and the attribute change date—but not usually the create date!
There's another API called Qp0lGetAttr() that can get lots of information about an IFS file. Qp0lGetAttr() has no trouble getting the date when a file was created. It can also get other attributes that are specific to IBM i.
Unfortunately, qp0lGetAttr() is much more difficult to code than stat(). When I wrote the IFSDIR UDTF, I was doing it as a programming example, and therefore I wanted it to be as simple as possible, since that would make it easier for you to grasp the idea behind a UDTF without getting bogged down.
Despite my reluctance, I decided the best way to solve this problem is to rewrite my UDTF routines to use Qp0lGetAttr(). So I bit the bullet and did that.