|
Hi, I think that there's an acceptable reason why, because performance is better, but not telling us sucks. Rochester deems that the rebuild of the access path is faster in a zero records environment than the time to save and then restore it. Also you use less tape (not much). 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 "Jim Franz" <franz400@xxxxxxx r.com> To Sent by: "Midrange Systems Technical midrange-l-bounce Discussion" s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx> cc 12/05/2003 04:47 Subject PM Re: ACCPTH(*YES) becomes ACCPTH(*MAYBE) in V5R2 Please respond to Midrange Systems Technical Discussion <midrange-l@midra nge.com> is there an acceptable reason why? "maybe" is never supposed to happen in OS 400. jim > Hi, > We were migrating a partition from an older box to a newer box using > SAVSTG, which failed. I have never got SAVSTG to work successfully on > V5R2. I heard later today that a PTF will be available by January 10. > > So we went back and did GO SAVE Option 21, and restored that media. We > were checking our job logs on the restore, and we discovered that many > access paths were rebuild, which is not what we had predicted. So we > called this into service. > > We went back and displayed the tape, and saw that many of the access paths > were never saved, which mystifies us. > > I retrieved the CL code for GO SAVE option 21 (QMNSAVE, but I'm sure you > knew that off the top of your head ;-))))) and saw that ACCPTH(*YES) is > definitely specified. > > This afternoon, I got a call from service saying that ACCPTH(*YES) was > really changed to ACCPTH(*MAYBE) in V5R2, and this feature was never > documented. IMHO, this should have both been documented in the Memo to > Users and the help text. > > The bottom line is that it's much faster to rebuild an access path with > zero records than to save and restore it, So ACCPTH(*MAYBE) is the > performance you would like, but SUPRISES(*YES) is what you got, and it > should always be SUPRISES(*NO). > > 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 > > _______________________________________________ > 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. > > _______________________________________________ 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.