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.
 |
 |
 |
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online