Re: Just Upgraded from 5r2 to 5r4

Some conversions were noted in the V5R4 Memo to Users, as well there were probably some mentioned in the V5R3 MTU. The QPFRADJ system value should allow adjust to account for the conversion or other work which may be specific to post-upgrade. The 'seems slower' may remain a valid fuzzy description until many objects have been decompressed or converted on the new release. Some installations will choose to move conversion activity to post-install, specifically to avoid encounter of conversion requirements in run-time; the MTU needs to describe not only that such a conversion will transpire, but /how/ conversions can be forced, in order to effect the conversions outside of run-time.

Note that some conversions [dtaq, msgq, menu, & msgf objects?] could be manifest as waits due to inability to convert them, which of course fits in with 'seems slow'. In some cases, if a requested lock [e.g. alcobj in one job] is obtained without forcing conversion, then [a coded loop on retry] to get the lock to enable conversion will typically be a wait for naught. For performance impact of such cases [not waits], that would be due mostly to lack of /alignment/ activity completion; see the field ODALGN for DSPOBJD], whereby access of a non-aligned object will be slow until it is aligned [plus any waits due to locks]. I expect the V5R3 MTU is where some such [alignment] conversions are described.

Regards, Chuck