The Display File Description command is a great tool, but perhaps it does its job too well. It shows everything you ever wanted to know about a file and then some. Sometimes, it seems as if getting to the relevant piece of information quickly is next to impossible. The screens are difficult to read, and you usually have to scroll through several of them. Here’s a simplified version, built for speed and ease of use.

As an AS/400 programmer, you are already familiar with the Display File Description (DSPFD) command. A useful tool provided by IBM, the DSPFD command tells you almost everything there is to know about a particular file. Whether you want to know the auxiliary storage ID, the preferred storage unit, or the coded character set ID (CCSID), the needed information can be displayed all at the push of a button and a couple of strokes of the roll keys. Do you want to know if the file allows read, write, update, or delete operations? The access path size or file level identifier? All this information is displayed every time you run the command. And that’s just the problem: information overload. You get screen after screen of information about the file, whether you want this information or not.

Now, don’t get us wrong. Sometimes you do need all that information. We once ran across a “one-million-plus” record file that was having its access path rebuilt an inordinate number of times during the day, causing major response-time difficulties with that system. The DSPFD command helped to identify the source of the problem.

Still, 90 percent of the time when we use the DSPFD command, we are looking for only a couple of pieces of information. If we are writing records to a file, it’s the number of records in the file and maybe the file size that interests us. Other times (like when a file gets a level check error), it’s the record size and the file creation information that’s most useful. Occasionally when tracking down problems, we need to know if the file has the journaling function turned on and, if so, the name of the journal. But that’s about it. It is unusual that we need to see any more information than that.

For these reasons, we created our own slimmed-down version of DSPFD, which we call Display File Description (DSPFILDSC). See Figure 1 for a sampling of the output from our command.

What DSPFILDSC Won’t Do

For the purposes of our DSPFILDSC command, we chose to ignore display files. When we need to look at a display file, we use IBM’s DSPFD command. Usually with display files, we’re looking only for the restore display, defer write, keep, and assume display file attributes. If you try to run DSPFILDSC on a display file, you get an error message instead.

Another limitation of our tool is its handling of multiple-member files. Because we have no such files in our systems, we didn’t find it necessary to handle them. You can display any individual member in a multiple-member file (by specifying the member name), but we don’t provide you with a member list.

The same is true with multiple-format logical files. Although our systems do employ these files, we chose not to address multiple-format members with our command. You can look at any individual format in a multiple-format logical, but you must specify the member name. Ideally, the tool would have a second screen, accessed via a command key, which would display a subfile record for each format in the file. However, that’s a function for another day.

What DSPFILDSC Will Do

Our DSPFILDSC command provides a single screen of accurate, pertinent information about any physical or logical file. In addition, the command shows you a couple of things that DSPFD does not. The owner of the file is displayed (along with the creation information), which can be useful when dealing with object authority issues. To find the owner of a file without our command, you would need to run IBM’s Display Object Description (DSPOBJD) command and then navigate through the appropriate screens.

The DSPFILDSC command also shows the size and description of each of the key fields for your files when these fields are displayed. Depending on what you are looking for, this feature alone gives our tool a substantial advantage over IBM’s DSPFD command.

How It Works

Three source components make up our DSPFILDSC command: the RPG IV driver program, which uses five main APIs to gather the necessary information about the specified file; the associated display file, which the RPG IV program uses to present the information; and the DSPFILDSC command source. All this code can be found on the Web at www.midrangecomputing.com/mc/99/05.

The command is self-explanatory and prompts the user for the file and library name, file member name, and record format name, if applicable (see Figure 2).

First, the RPG IV program uses the Retrieve Object Description (QUSROBJD) API to verify that the file specified does exist. If the file does not exist in the library named, the program uses the Send Program Message (QMHSNDPM) API to issue an error message back to the command requester.

The program also uses the QUSROBJD API to return information on the owner of the file, who created the file and when, the date and time the object was last saved, and the name of the source file used to create the file. You can find these fields in the OBJDS data structure used to define the variable returned by the QUSROBJD API.

The Retrieve Database File Description (QDBRTVFD) API provides the additional critical information about the file. Just as it was with the QUSROBJD API, the QDBRTVFD API information is returned to a program variable. This return variable has different data structures containing different pieces of information about the file. Some data structures also contain fields that “point” to other data structures. Because we load the variable into an array, we can use these pointer fields as array indexes to access the file information. The fields DbPhyOff, DbFileOff, and DbJrnOff are some of these pointer fields. One of the key structures we access with this API gives us the names of the key fields for the file. We load these names into an array for later processing.

Next, the Retrieve Member Description (QUSRMBRD) API finds the size of the database file.

Finally, we need the description of the key fields for the file. We already have the names of the key fields loaded into array AKEY. To get the description and sizes of all the fields in the file, we use yet another API, List Fields (QUSLFLD). This API works differently than the others. Instead of giving us the returned information in a variable, it dumps the returned data into a user space. So, we first create the user space by using the Create User Space (QUSCRTUS) API; we then establish the pointer for the newly created user space. The pointer is required to “address” information in the user space. We use the Retrieve Pointer to User Space (QUSPRTUS) API to establish our pointer.

We load our newly established pointer into GenDsPoint, a pointer field on which we have based the data structure GenDs. When we load the pointer field GenDsPoint with an address, the data structure GenDs is loaded with the data located at that address. We use this technique of data structures based on pointer fields to retrieve the data in the user space. As we continually overlay the ListDs data structure over the user space, we receive the field information for every field in the file. If the field name we are processing happens to be found in our AKEY array, we write the record to the workstation subfile that contains the list of key fields.

After all the information on the file has been gathered, we present the display file to the requesting workstation session.

The Final Word

We think the tool in this article is more concise and to the point than IBM’s DSPFD. Although our DSPFILDSC command doesn’t display as much information, sometimes less really is more.

Figure 1: This display panel represents the output from the DSPFILDSC.

<>
<>
<>

<>
<>
<>

Figure 2: The DSPFILDSC command prompts the user for the file and library, file member, and record format names.

<>
<>
<>

Figure 1: The Item Selection program allows the user to enter an item number and select the action to perform.

Figure 2: In View mode, all entry fields are protected.

<>
<>
<>

<>
<>
<>

Figure 3: While in Modify mode, only the key fields are protected.

Figure 4: If errors are encountered, the invalid fields are highlighted and the messages are displayed in a message subfile.

<>
<>
<>