Re: restoring logical file to link to specific Lib/PF

rick baird wrote:

<<SNIP>>

3rd party software distributors can make their own licensed
program installs? I had no idea.

If so, I don't think I want to go there at this juncture.

"Software Product APIs"; Simon & others have referred to them over the years, here on this list.
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/apis/sw1.htm

<<SNIP>>

I'm only now learning by looking and asking the relationships and
the rules we do now, and will employ for different scenarios of
version upgrades to the package. Like I said, it's a new gig and
I'm just getting my feet wet. <<SNIP>>

Cool... not so as to go under water we hope :-)

FWiW: Since the OS & LPPs support only upgrade from N-2 or newer, its upgrade code checks for [upgrade from] which level are limited to distinguishing from just any two prior file layouts; i.e. given no PTF activity changed the files on any of those two prior releases. I would code one procedure for upgrade from N-2, another for upgrade from N-1, and one for upgrade from N-0. Which one would be invoked was according to if\what was noted to be a missing field; given each release added one or more fields, if the field added in N-1 is missing then the N-2 procedure is invoked, if the field added in N-0 is missing then N-1 procedure is invoked, and if the field added in N-0 is already there [i.e. *not* missing] then N-0 procedure is invoked; i.e. no missing fields means it is a re-install of the same release. Data transformations and handling [both effectively renamed and] deleted fields were done according to the specific release transition. The Record Format Level Identifier can often be used instead to check for what level, if the developer ensured the new version of the file got a new level identifier; but for the OS, its old delivery of files had different definitions between DBCS and SBCS even while the code was the same, so two values were possible for each file.

Regards, Chuck