Re: Skipping lots of releases - Was: Looking at Power 7

On 1/24/11 2:27 PM, rob@xxxxxxxxx wrote:

Good example, Granted, it might be able to be shot down by just
running a RCLSTG and have most of the database cross reference files
rebuilt.

Do not confuse the database x-ref with the SQL catalog TABLEs. Unless something has changed, the RCLSTG is helpless to assist in recovering the data for procedures and functions, having code path only to process all *FILE objects [but ignoring other than DDM device and database]. And no means by any OS feature will recover the definitions for external procedures where the lack of any external object would prevent retrieval of the definition; i.e. any external procedure to which an Access Plan has not been associated to a supported program object type.

But:
1 - I get your example
2 - Then again, SYSPROCS are different because unlike (for example)
doing a DSPFFD or something to recreate it I have a devil of a time
with where does SQL store a CREATE PROCEDURE... So, maybe that is
harder to recreate.

Exactly, not part of the DB X-Ref.

But again that scenario named an object requiring some conversion between releases, only as one other example. There are also the TCP/IP configuration files, which at some point some of the data even moved to stream file(s) instead of a database file in QUSRSYS. There are others that I know of, and there are surely others that I do not know of. So again, there are any number of things that the OS, products, options, and features might do for which some required conversions would not be [available to be] performed in an unsupported upgrade path. So indeed the cliche "If doing that hurts, do not do that" is more applicable than "This is how we recover from stupid". Whatever the example, if the upgrade path is not supported then any user data needs to be exported from the old release and imported at the new release, to avoid the assumption that the data will migrate properly using install and that the features dependent on that data will function properly after performing an install under that poor [without significant experience and knowledge to improve upon that] assumption.

I get your point about where IBM is not going to create an APAR to
document that chopping yourself in the foot with an axe hurts. Just
didn't know if it was created tangentially. Like, "user was getting
MCH.... when trying to run ... It was determined that this was caused
by performing an undocumented N-Many upgrade...". Then again, that
might be a bear to search for.

Thus why anyone would detest even an attempt to predict or even spend any time to document any specific symptoms for any one incident. The situation [from the perspective of IBM as support] is best resolved by having the customer scratch back to the original release and perform the proper install(s); excepting a lucrative support contract above standard OS support, for which someone might have the customer keep coming back for even more paid support as side effect for their past poor decision. So suggesting starting over is not just to avoid documenting some oblique symptoms, but to avoid any number of other problems that have not yet been encountered, which may be lurking about as more side effects from their poor choice in using undocumented install procedures. Consider... While there are only a few correct phone numbers to call for assistance from a specific service provider, there are innumerable wrong phone numbers for the same, just as there are only a few correct install scenarios but a great number of possible variations on incorrect install scenarios; better to document the few good methods, than to waste any time [attempting to] document the innumerable and unpredictable bad methods that might be used.

Regards, Chuck