Question

Housekeeping Stream Files

CLLE, iSeries, DSPLNK

I am working on a utility program to housekeep stream files based upon how many days ago the file was created.

I checked the DSPLNK command, but, this command does not provide the creation date.

Does anyone haappen to know if there is such a command that would provide this information, and furthermore, if there is an example of a CLLE program that already does this ?

Please advise

-Nick

The Get Attributes API Qp0lGetAttr provides the creation information (along with a whole lot more) of an Integrated File System file. And as you are writing a utility program, you may also be interested in the Read Directory Entry API readdir which allows you to sequentially read the files found in a directory and/or the Process a Path Name API Qp0lProcessSubtree which allows an exit program of yours to be called when certain file types are found in a directory.

At my web site you can find the first two of four articles related to processing stream files from an ILE CL program. The other two articles however will not be available at my web site until they are published by System i News. The articles can be found under the heading 'Industry Standard API Basics for the CL Programmer'.

One item to watch out for -- the IFS APIs return creation date in what is known as the C epoch. This basically means what you get back is an integer value representing the number of seconds since Jan 1 1970 that equate to when the file was created. In the C/C++ Run-Time Library Functions Manual you will find many APIs that work with time values based on the C epoch. This epoch consideration is one that is covered in the third article of my series -- though in the article I simply show how to convert the epoch to a meaningful character string, not how to use it as an aging argument.

For your utility program you will NOT want to use commands such as DSPLNK as DSPLNK only provides output to either display or print. While a program can process printed output, this is NOT considered a formal programming interface. Not being a formal programming interface means IBM does not worry about compatibility issues such as changing the report layout. Also report layouts can change significantly when i5/OS is installed with various languages -- English, German, Russian, Arabic, Chinese, etc. Processing a report as input to a utility program can mean a different version of the program per National Language Version. Using APIs, such as those referenced above, provides your utility program a level of stability that DSP command interfaces (in general) do not.

Probably more information than you really wanted...

Bruce Vining
http://www.brucevining.com/
Integrated solutions for the System i user community