|
Hi, As I discovered the hard way, ACCPTH(*YES) becomes ACCPTH(*MAYBE) in V5R2. I spoke with a database developer, who asked me why this wasn't better, and I had to admit that it was better, although unexpected. Here's the bottom line. If a member has no records in it, it's faster to rebuild the access path than restore it. Furthermore, it's also faster to not save the empty access path, *AND you save tape. The only disadvantage are: 1. You expect to see the access paths saved to tape, and you don't. 2. You see the access path rebuilt messages, even though rebuilding those access paths was faster than restoring them. Had IBM been smart (ARGH, how many times have I used than expression), they could have: 1. Put a notation into the save information as to how many access paths were suppressed. 2. Not reported that those empty (fast) access path rebuilds occurred. Al Al Barsa, Jr. Barsa Consulting Group, LLC 400>390 914-251-1234 914-251-9406 fax http://www.barsaconsulting.com http://www.taatool.com "Lopez, Andrew" <alopez@xxxxxxxxx m> To Sent by: midrange-l@xxxxxxxxxxxx midrange-l-bounce cc s@xxxxxxxxxxxx Subject SYSSAV & Access Paths 01/22/2004 07:34 AM Please respond to Midrange Systems Technical Discussion <midrange-l@midra nge.com> We upgraded to an 810 this past weekend and ran into a problem with the use of a full system save/restore (GO SAVE, option 21 with GO RESTORE, option 21). We have 55 work libraries that are used to store order entry information as it is being keyed. The data is copied into production files once the order is confirmed. Whenever we do a full system save, these files have no data. I am told by IBM Help Line that access paths for empty files are not saved in a SYSSAV as of V5R2. Indeed, after doing the restore onto the new box, our order entry package would generate an error for each file in each of the work libraries. While we could use EDTRBDAP, that is not acceptable in our view for disaster recovery purposes. We are not interested in creating a CL to open the files and force the rebuild. We want backups that, once restored, cause the system to run as it did when the objects were saved. Saving the objects (via SAVLIB or SAVOBJ) with ACCPATH set to *YES works, and if needed we will add this to our daily saves so that using GO RESTORE option 21 and then overwriting with the latest daily will handle the problem. I can't say I'm thrilled by the prospect of backing up 55 libraries, with 37 files each, on a daily basis when they have no data in them just to get the access paths. My boss is not a fan of *IPL for the RECOVER parameter. So the question is, can I force the default behavior of a SYSSAV to save all access paths? The IBM tech I spoke with couldn't point me to anything. The OS/400 Backup and Recovery Guide V5R1 was no help and there doesn't appear to be a V5R2 revision. _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.