Re: ACCPTH(*YES) becomes ACCPTH(*MAYBE) in V5R2

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.
>
>