Gil, My code (that I earlier referred to) .. does the same ... but .. it does not
stop at just JES. Any and all 'dynamic' updates are monitored ... and ofcourse ... recorded. Hooking into an existing 'change management' product / procedure would be simple though I have only tried it with one product. Please note that this was something that I wrote just for personal satisfaction. What I fail to understand is the need for an actual command / service that does this function. More so, given that there are 'supposedly' few that are allowed to make 'dynamic' changes. My apologies for being dense. Kind Regards, Jim Thomas 617-233-4130 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Wednesday, October 14, 2009 3:18 PM To: [email protected] Subject: Re: JES2 Parmlib inconsistent with active definitions 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.16/2435 - Release Date: 10/14/09 06:33:00 ---------------------------------------------------------------------- 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
