This incident raises a larger issue ... namely, how to do "impact analysis" of Db2i applications, especially when embedded SQL is in use.
Does IBM provide any tools, processes or procedures to recommend how applications developers should "query" the application inventory, before making the kinds of changes that Greg described, that allowed him to just make what appeared to be a small change, only to find out later on, that it in fact had a larger scope and impact?
Are there any particular queries over the Db2i catalog that might help?
Example: if customers keep all SQL scripts in source physical files, they could use PDM's FNDSTRPDM to search all application source code, to find everywhere a particular SQL table, function, procedure, UDTF, etc., is used; (a "poor man's" impact analysis tool, ... better than nothing?)
Do any vendor "impact analysis" and/or "change management" tools provide processes or procedures to assist with identifying this particular situation, to help avoid such a scenario?
Mark S. Waterbury
On Thursday, June 9, 2022, 09:12:11 AM EDT, Greg Wilburn <gwilburn@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
While working with ACS Run SQL Scripts and the Schemas applications, something very strange occurred.
I used Schemas to locate an SQL View called V_BOX_TYPES and generate SQL in Run SQL Scripts - I wanted to add a column.
This morning, one of our reports was failing because another view in that same library was completely missing - the object was just gone. I went into Schemas to find two objects I didn't recognize.
"Box Types" was the description of the view I was changing.
"Closing Log" was the description of the view that was deleted.
"GWILBURN" is me.
The timestamp is right is virtually the same time I modified V_BOX_TYPES.
Q_AT000003
Q_AT000003
QDFTOWN
GWILBURN
06/08/2022 04:49:48 PM
Box Types
Q_AT000004
Q_AT000004
GWILBURN
GWILBURN
06/08/2022 04:49:48 PM
Closing Log
Any ideas how I would have mucked this up?
TIA
Greg Wilburn
midrange.com
