Sean Gleann wrote: >I'm coming under pressure from 'upstairs' regarding the idea of implementing >change control or versioning on parmlib members and other 'control'-type files >(WLM policy, SMS rules, RACF, etc)
>Currently, I manually maintain 'change history' comments in each member, and a >previous version 'backout' member, but that is a highly manual task, subject >to a high level of self-discipline (and on occasion I have either bypassed or >screwed up that procedure. >I've looked at the idea of using SCLM for this, but it all seems like using a >sledgehammer to crack a hazelnut. Git has also been suggested, and I'm still >looking at that. We're NOT using Change Control or Versioning. I am very glad about this. ;-) These suggestions below are NOT Change Control or Versioning, but could make your work really really easier if you do not want to use change control software like Librarian. RACF - limit accesses and use RACF command to audit all and every access with this example command: altdsd 'SYS1.PARMLIB' audit(all(READ)) To lockup WLM Policy - check out MVSADMIN.WLM.POLICY profile in FACILITY Class. Also look at MVSADMIN.XCF.WLM and other similar profiles. I *think* this profile STGADMIN.IGD.ACTIVATE.CONFIGURATION protects the SMS configuration activation. I am not sure about this, but ... Lockup in RACF this module DGTFPF05 in RACF PROGRAM Class to keep snoopers away from sensitive ISMF functions. You can then run daily/monthly reports for all accesses attempts. SMF - Check out SMF type 42 and the subtypes related to the member changes - Of course STOW and DESERV will create these SMF records. If you are using some other utilities or use RYO methods, no SMF records will be written. You can also consider FORCE_STATS = YES and STATS = ON in ISPF Configuration Utility, but then some clever jack-of-all-trades will bypass that. Trust me. >Does anyone else do anything like this, and if so, would you be prepared to >share your experiences, please? Experience? We investigated some change management software gazillion years ago, but the people dropped it because of costs and just being lazy to use it at all. One other way to do 'change control' - Only Read access is set on your parmlib datasets. Then you give and remove Update access just for the duration of the change and of course using proper documentation. Oh, before I forget - when RACF people are unavailable during an emergency change, what do you do then? A special id able to do those changes can help, but if that id was used x days ago and suddenly becomes revoked upon attempt to logon just makes things troublesome... One thing to consider - how do you ensure the people who do X, will really COMPLY with all things with Change Control even despite using some products to send out a NOTIFY to top-brass people when something has changed. Say, after an emergency change at 22:34, the next day, 'they' forget conveniently to work with Change Control. Just my few cents... I am reallynot a fan of change control anyways, ok, that is just me, but ... Groete / Greetings Elardus Engelbrecht ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
