Great Minds Agree: It’s Good to Save Access Paths
September 14, 2005 Hey, Ted
In your article entitled “Avoid Changed Default Values,” I believe that you are providing a disservice to your readers with your answer. Your answer to the question centers around hard-coding a default IBM value in a CL command when it should have been to remind everyone to read the IBM Memo to Users before upgrading to a new release of the operating system.
I have just finished reviewing said document and on page 38, a change is documented. Furthermore, the information provided in the article is WRONG. IBM did not change the default value of the access path (ACCPTH) parameter on the save commands from a value of *NO to *YES. They changed it to *SYSVAL and created a new system value called QSAVACCPTH, which controls whether or not the access paths are saved.
I believe that a correction is in order.
–Jonathan
Jonathon is absolutely correct. I’ll try to set everything right today. I got many responses to that article. I’ll publish a few of the best ones here, then end with a few comments of my own.
I can add a little more to this. They “sort of” changed the command default. Actually they created a new system value to store your default value and changed the command default to use this instead. So you can set your default via the new system value QSAVACCPTH. By the way, the change is WELL documented in their “Read me first” for the V5R3 upgrade. As always, do your homework before a release upgrade.
Now, even if set to ACCPTH(*NO), the save command still saves the access paths descriptions. Not the actual access path data. There is a HUGE difference at restore time. Changing the value to *YES saves the access path data as well. This does increase the size of your backup and it’s usually a significant amount as this reader found out. But when you restore libraries from a save with *NO specified, the system recreates the logicals based on their saved descriptions and then rebuilds ALL of them from scratch. This can be a very long running process and can be watched via the QDBSRVnn jobs on the system. With access path *YES, the system will restore the access paths rather than needing to rebuild them. That’s a much quicker recovery of a library.
Now to the change they wanted. I have worked with hundreds of iSeries and can attest that the vast majority use ACCPTH(*YES) in their save commands. I would venture to guess that virtually ALL large shops use it. Because of the resource issues with recovery, I know they’ve (IBM) wanted to enforce *YES for a long time. By the way – the system will still take the time to rebuild some logicals. There are exceptions to the rule like any rule and you can study these yourself. But the bottom line is that using *YES on your save commands will greatly reduce restore time on the restore commmands. On really large files with logicals it could save as much as a day. Or more. Yes you read that right. And that rebuild activity associated with your logicals is very resource intensive in both processor and disk. You’ll notice it.
My rule and recommendation to the world is to use ACCPTH(*YES).
Best wishes, and thanks for the great tips, Ted.
–Bill
I guess the person who doesn’t want to save his access paths has never had to use any of these backups. I’d recommend a bigger and faster tape drive before I would recommend not saving access paths. If they are already on the biggest and fastest tape drive out there, then look at high availability options. If you’ve ever had to watch an AS/400 rebuild its access paths for a day or two during a full restore, you’d probably agree with me.
–Dan
This change and a few others are nicely documented in the “Memo to Users” (MUST reading before/after a release update); see “Backup and recovery changes.”
In this particular case, I agree with IBM’s change. At the cost of some more time and media, it can save you hours of time when restoring a library. Without saved access paths, all logical files (and their access paths) must be rebuilt. This process will get your CPU up to 100 also. With the command “EDTRBDAP” the rebuild process can be viewed and modified if desired.
–Bruce
Instead of changing the programs, changing the system value would be more efficient.
–Ben
According to the SF98086 iSeries Memorandum to Users, section 3.38.1 (Save command and API changes), system value QSAVACCPTH applies to the following commands and APIs:
- SAVLIB command
- SAVOBJ command
- SAVCHGOBJ command
- SAVRSTLIB command
- SAVRSTOBJ command
- SAVRSTCHG command
- QSRSAVO API
–Ted
Another possible V5R3 surprise:
If the new QUTCOFFSET system value is set, the AS/400 will change the time if they are in daylight savings time zone. This will be a delayed surprise for the previous contributor. (And while it may be a good surprise for many people, if they run Domino, it could be a bad thing – Domino does not like to have the time changed by a whole lot while it is running!) Again, this is in the Memo to Users (except for the Domino part).
One final note: IBM used to include the Memo to Users with an OS upgrade, but now you must find it for yourself. The most that was included in my box was a “Start here for OS/400” that says before you start to complete the required planning tasks by going to the Information Center.
–TK
OK, my turn again. First of all, I published David’s tip because I wanted readers to be aware that their backups might increase in size and duration after moving to V5R3.
Second, I dropped the ball by not verifying the changed parameter value. I’m still working at V5R2, but I could have visited the Infocenter.
|
Third, had I done my homework and found out about the new system value, I would have advised David to change the system value rather than the CL program.
Fourth, it did occur to me that some readers might not know how to hard-code a default value with the CL prompter. After all, I have had to tell several seasoned veterans recently that keying a single ampersand and pressing Enter extends the size of an entry field.
Fifth, it occurs to me that IBM would not change a default value, or anything else, without a good reason. The cynic in me says that the good reason might be for IBM’s benefit, but it would be hard to make a case for IBM’s self-interest in the area of backups.
Sixth, I wish that all the tips I ran were error-free and supremely useful, but I can’t avoid making mistakes. I assume readers are intelligent people and can and will evaluate the suitability and reliability of anything they use. The only disservice I can see is to quit publishing the newsletter. Better to goof up sometimes than to do nothing. If Jonathon (or anybody else) is dissatisfied with Four Hundred Guru, I’ll cheerfully refund his subscription money. (We don’t charge for subscriptions, so the refund will be kinda small.)
Last, thanks to everybody who wrote. I apologize to any one whose email I didn’t answer with at least an acknowledgement. I wish I could answer all my email, but I just don’t have the time.
–Ted
RELATED STORY
