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