Midrange Programmer--Control Access Path Rebuilding

Most of you probably let the system take care of itself after an initial program load, right? We normally do, too. But a couple of times in the past we waited while access paths that we really didn’t care about at that particular time got rebuilt while the access paths we were really waiting for sat idle in the queue. If only there was a method, or methods, to control how and when access paths get rebuilt. Aha! But there are. Read on to find out more.

Access path rebuilding may not be an issue when you perform regularly scheduled initial program loads, or IPLs. These are usually done during off-hours, when all programmers and users are safely tucked into bed. But what about those times when the system ends abnormally or when you are forced to manually IPL during the business day? It is during these times that access path rebuilding can cripple your staff and user community for the rest of the day. Faced with these types of dilemmas, our group learned some ways to better manage access path rebuilding.

Before I explain how to manage access path recovery, I should point out a little information on access path maintenance, because the way that you set that up will determine your options with access path recovery. Controlling access path maintenance is accomplished when you create a physical or logical file, using the create physical or create logical file commands (CRTPF or CRTLF respectively) or by changing a physical or logical file using the change physical file or change logical file commands (CHGPF or CHGLF respectively). The access path maintenance parameter (keyword MAINT) allows you to define how an access path is maintained. There are three options:

There are advantages and disadvantages to each option and specific applications for each, but my goal here is for you to have a basic comprehension of the available options so you will better understand what can be done, should you ever have to recover access paths either during or after an IPL.

Now that you know what your access path maintenance options are, let’s get into access path recovery. When your OS/400 operating system decides to end abnormally for some strange reason, what can you do to control when, how, and if access paths are recovered to a useful state? The first method is to define access path recovery the same way that you define access path maintenance. I don’t mean by using the same parameter, but at creation or file maintenance time. There is a parameter in the CRTPF, CRTLF, CHGPF, and CHGLF commands called access path recovery (keyword RECOVER), which lets you define how the access path will be recovered after an abnormal system end for files with *IMMED or *DLY access path maintenance and for those files with a keyed access path.

Pretty cool, isn’t it? Now you can control when and how an access path is recovered, either at file creation or on the fly, by changing the file. But it leaves you wanting more, doesn’t it? What if you’ve defined all your files to be recovered once an IPL is completed? Or what if, for one time only, you want a specific file to be recovered only when it is next opened, and you don’t realize it until the system goes down? There are many scenarios that may arise when OS/400 ends abnormally that might make you rethink how you want access paths to be recovered. For those times, there is the edit rebuild of access paths (EDTRBDAP) command.

After an unplanned or manual shutdown of the system, and during the ensuing IPL, if there are any invalid access paths--access paths that were in use when the system went down--the EDTRBDAP screen will be displayed. The edit rebuild of access paths display shows the names of the file members that have immediate or delayed maintenance access paths that were not valid when the system went down. It allows you to override the recover value of the file and to rebuild the access path using a different strategy.

The display allows you to enter a sequence number and shows the access path’s file, library and member. It also shows the estimated recovery time, and if the file is currently being rebuilt, it will show the elapsed time of the recovery.

The sequence number that you enter is used for more than to simply sequence the order of the access path recovery; it's also used to determine if you want to recover the file during the IPL, after the IPL, when the file is opened, or at a later time. I’ll explain.

The recovery values mentioned above have related numerical values. The default value for *IPL (recover during IPL) is 25, while the default for *AFTIPL (recover after IPL) is 75. These numeric values correspond to the sequence numbers listed with each access path entry on the display. So for those files that were defined with *IPL, you will see a 25 as the sequence value; a 75 would signify *AFTIPL and a sequence of 100 would represent *NO.

The threshold value is a system value that determines which sequence numbers represent *IPL and which represent *AFTIPL. The default value is 50. So any sequence number from 1 to 50 is used to schedule recovery during the IPL, 1 being the highest priority and 50 being the lowest. Sequence numbers from 51 to 99 will be used to schedule access path recovery after the IPL has completed; with 51 being the highest priority and 99 being the lowest. So by using the sequence number, you can determine if an access path should be recovered during or after the IPL and in what order. There are also two other values you can place in the sequence parameter:

*OPN says to rebuild the access path the next time it is open. It equates to a sequence number of 100.

*HLD says to hold the recovery of that access path until a later time. That later time is when someone comes back to the EDTRBDAP screen and changes the sequence number to 1-99 or *OPN. *HLD has a numeric representation of 200.

The display also allows you to sort the entries by status, file, library, or estimated time. I should mention here that the estimated time is calculated assuming a dedicated CPU to rebuild that one access path. So while the time might not necessarily reflect a real-world estimation, it can still be used to determine rebuild time with relation to the other access paths.

There you have it. It's probably more than you ever wanted to know about access path recovery. I know it was for me. Still, by understanding the flexibility of access path recovery, you are now equipped during your most critical time of need. With the track record of OS/400, this need shouldn’t be the norm. But, hey, you know what they say about an ounce of prevention.