I am looking to build a CA-OPS Toolkit of sorts here in my shop. I was wondering if there was anything that you have been asked repeatedly. I am thinking along the lines of information gathering to make sure CA-OPS is running smoothly and no one has made a mess of things. For example, we had some trouble with users forgetting to auto-enable rules after they edit them. They would enable them but not auto-enable them so they worked fine until IPL. Now we have a TOD rule which will run through the rule sets and pull out any rule in mismatched enabled states. I also have a REXX which will log our IPL information into a file in our DR documentation just in case we need it for reference. I know there are some reporting tools as well, I just have not got into them yet. Just wondering if there was anything that the community could suggest that would be good to add to my tool kit.
One thing we do is to take a daily snapshot of our SSM tables on all systems. Just before writing it out, we compare the table with the previous day's snapshot for all SSM tasks - CURRENT, DESIRED, MODE etc. Then we email the differences to the AO team mailbox. That way, we can tell what's changed and investigate why.
Excellent idea. I had already started looking at the backup piece but comparing them seems like a pretty good idea too, just like we are doing with the rule sets. One question, For the previous day's tables, how are you reading them in? I assume you would have written them the day before and thus would have to restore them to read them again. This implies a table name is needed. Do you just use something like TEMP_STCTBL or do you do something different?
Actually the backup and compare are quite separate. We use the supplied READTBL for backup (and we have WRITETBL set up for any restore we might need), but for the compare we use another table (STCTBL_BK) that we copied the day before. I like your idea though, as it verifies the backup worked and avoids the problem of someone corrupting the backup table in storage.
So I have a version of this up and running now. The trickiest part may have been the restore of the table. I did not realize that READTBL used a SQL CREATE statement AND that the CREATE statement does not overwrite a current table. Once I had that figured out it was just a matter of making sure variables got passed and assigned correctly, that the report/e-mail looked pretty and of course that the logic worked.