Re: v5r4 upgrade first touch object conversions and logical files

STROBJCVN for database *FILE objects for a conversion that does not require the full amount of work performed by that function, will be work that was performed for naught [plus side effect of last-used]. Unless there are unconverted database file members [i.e. neither opened nor target of STROBJCVN of those members existing-before and remaining-since V5R1 was slip-installed on the system], the STROBJCVN is the poorest choice to effect any of the various conversions required for database *FILE objects since then. A recent Memo To Users [MTU] should have called out the DSPOBJD for database *FILE objects, but made no mention of any requirement for STROBJCVN; i.e. no database file member conversions in any recent release.

Regards, Chuck

Evan Harris wrote:

Agreed - I was just interested in the preference for DSPOBJD rather
than STROBJCVN - although I see you use this for SQL Objects.

I normally run a STROBJCVN after the upgrade (if I can't do a full
system save) for the same reasons and was wondering if there was an
advantage to altering my approach.

Pete Massiello wrote:

After an upgrade to V5R4, I always do a DSPOBJD *ALLUSR/*ALL *FILE,
DSPOBJD *ALLUSR/*ALL *USRQ, DSPOBJD *ALLUSR/*ALL *DTAQ, and then a
STROBJCVN *SQLPGMS on all User libraries. The only drawback to
this is that all these objects get a last changed date update, but
that is better than doing it at first touch on Monday morning when
the users get on the system (typically a weekend upgrade). I had
one customer who didn't want the last changed (could have been used
date, don't remember which) date to be updated, and they said they
didn't want me to run these. Monday morning, the system was as
slow as molasses as all their regular production objects were
touched for the first time and converted. By noon the system was
back to normal, but to me that isn't the right way to do it.