|< Day Day Up >|| |
At first, we thought that this would be a great topic for discussion. We would be able to provide you with some information that would really be useful. During our residency we discovered otherwise.
Historically, WSAA was designed to simply take a snap-shot of an enterprise’s production assets. There was no requirement to update or to delete the components that were loaded.
Over time, the code surrounding the database has been modified to support the ability to update and delete some (although not all) of the components. You have seen pages with update and delete links previously in this chapter.
We have looked carefully and have found that even if you save the batch JCL from an inventory collection, there is nothing in it that will provide you with the means to load another file at a later time.
There is no functionality in the current design of WSAA that lets you perform an incremental (or on-going) database load.
What this means for your site is rather extraordinary. If you want to update the information in the WSAA database, you must reload the contents of your site’s production data sets and the online (CICS or IMS) information. Therefore, when you clean up any database errors during your initial load, you must do so with the knowledge that you are likely to encounter some of these same errors again.
One of the key decisions you must make — and we cannot help you with this — is how often to rescan your production source code libraries in order to update the information stored in the database inventory. Irrespective of the change management methodology you use, you must take the time to load the components one data set at a time.
Depending on the size of your production components, your database load batch jobs may require considerable system resources. In 3.10.4, “Run your inventory collection during off-hours” on page 112 we describe how best to deal with this circumstance.
One method that we can suggest for tracking your changes follows:
Before you load your production source data sets, save the member list, including the ISPF statistics.
Update your production libraries using your change management system on your normally scheduled basis.
Regenerate the member list with the ISPF statistics.
Compare the two lists and identify all new and any modified components, along with any members that have been deleted.
Reload the database.
Review the results of the member list comparison to ensure that all of your changes have been scanned into the database.
Clean up any resultant database errors.
The applications and analysis concatenation sets you built will remain intact when you re-run your inventory collection.
However, you must reanalyze all impact analysis projects to ensure that the contents are current and accurate.
|< Day Day Up >|| |