On Wed, 14 Oct 2009 14:46:56 -0500, Mark Zelden wrote: > ><soap box> >It's nice to dream. But why stop there? The entire operating system >is full of places you can make dynamic changes without "hardening" them. >z/OS PARMLIB is full of them. LNKLST, APF, EXITs, SMF, PPT, >Subsystems, ... and the list goes on. Then there are your major subsytems >(CICS, DB2, MQ, CICS, WAS) that also support dynamic changes. Some >changes survive recycles / restarts without overt action, some don't. > >This is what change control and procedures are meant for. If you don't >have both and enforce them, bad things will happen eventually. >I realize it's nice to have the double check but the best tool is probably >still a sledge hammer to the fingers of those that don't follow those >procedures. > ></soap box> > I'll dream on. What I'd consider an excellent control procedure is a system where:
o The master copy of the control file is updated using a controlled, trackable, auditable, revertible, ... etc. tool such as RCS, CVS, SCLM, whatever. o The updated control file is copied into the working area (PARMLIB, etc.) o A command is issued to refresh the active environment. I don't know how generally z/OS provides this, but for anything that can be dynamically modified from the console there should be no fundamental technical obstacle to refreshing from a library member. o Dynamic updates from the console are largely prohibited. The procedure above should suffice except for unforseen and urgent situations (e.g DASD containing PARMLIB is inaccessible.) o Refreshing from updated library member(s) has the advantage of greatly narrowing or closing the timing window between changes that must be coordinated. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
