Use a message subfile to return error information to the user.

Written by Bruce Vining

Anyone who has been following this column for a while probably knows that I believe in using messages whenever possible. Messages are a wonderful way of keeping textual information out of my code, thereby allowing me to reword some text without having to change an application program, a command definition, and so on. One place where I find that many developers (CL and otherwise) are underutilizing messages is in the area of display file error-reporting.

Extracting a bit can be done a number of ways, but the code in this article uses only the basic arithmetic capabilities of CL.

Written by Joe Pluta

This article is sort of the antithesis of what we normally do in RPG Developer. Sometimes, you need to do things in CL without calling an RPG program. The situation is rare, but it happens. One case may be where you have to provide the source to the program in question but you can't count on the RPG compiler being there. And no matter how much IBM has improved the language (and it's been quite a bit), some things really can't be done in CL. But in this article, I want to show you how to do something in CL you may have thought was not possible: extract the value of a single bit.

Let's look at some additional stat APIs.

Written by Bruce Vining

In last month's column, "Dependency and Validity-Checking of Command Parameters," we looked at how a validity-checking program could be used to detect the use of conflicting parameter values when running the USEDIRPGM command. It had been my intent for this month's column to continue that discussion of validity-checking programs. However, some readers of this column have encountered a problem with the USEDIRPGM command processing program (CPP), so I'm moving up a topic that I had not planned on discussing for a while yet.

Today, we extend the USEDIRPGM command.

Written by Bruce Vining

In last month's column, "Clearing, Rather than Deleting, an IFS File," we implemented a CLRSTMF command. Today, we will start to incorporate this command into the USEDIRPGM command that we created earlier in the year.

Here's the command IBM should have given you but didn't.

Written by Bruce Vining

In recent articles, starting with "Trying to Get a Handle on Your IFS?," we've seen how to automate the deletion of an IFS stream file when a file has not been used within a user-determined number of days. Rather than deleting a stream file, though, some companies would prefer to clear a stream file—similar to how the Clear Physical File Member (CLRPFM) command can be used to clear a database file member. Unfortunately, if you were to prompt generically for all commands that start with the letters CLR (that is, prompt for CLR*), you would find that there is not a Clear File (CLRF) or Clear Stream File (CLRSTMF) command on your system—or at least not one provided by the i operating system. For this reason, today's article will look at how to implement a CLRSTMF CL command.

More functionality extends the USEDIRPGM command.

Written by Bruce Vining

In last month's article, "Isn't Recursion Great?," we saw how a CL command can recursively invoke itself in order to provide nested processing—in the case of USEDIRPGM, nested processing of imbedded IFS directories. Today, we will expand on last month's program with more-specific handling of the stream files (*STMF) and directories (*DIR) that are processed by the DIR3 program, which is the command processing program (CPP) for the USEDIRPGM command.

Find out how to easily check the contents of IFS subdirectories.

Written by Bruce Vining

In last month's article, "What IFS Files Have Not Been Used For Three or More Days?," we saw how a CL program can easily determine how many days it's been since a file has been used. We also looked briefly at how we could automate the removal of files that have not been accessed within a user-determined number of days. Today, we will expand on last month's program with more specific handling of the stream files (*STMF) and directories (*DIR) that are processed by the DIR3 program.

Access and manipulate various forms of time to automatically remove files from the IFS or save them.

Written by Bruce Vining

In last month's article, "When Was an IFS File Last Used or Changed?", we saw how a CL program could determine the date and time an IFS file was last opened or modified. Today, we'll take that one step further: finding out which files have not been opened in the last X number of days, where X is a user-specified value. This is the type of information that may help you decide what files are ready to be archived and/or deleted on your system. An example of how to automate the removal of such files is provided at the end of this article.