Before I had the tools to fully automate SW installations on remote systems, I had a pseudo manual method: CMDSRUN. Basically I place the commands to run in a file, CMDSRUN (a 230 lines exec) reads that file and issues these commands one by one. By default, the exec pauses before and after each command, during the pause you can enter any other CP/CMS command, tell to skip the command, or exit. A log is maintained. Advantages: you don't forget required commands, you make less typing errors. I can send it to any requester.
2007/8/23, Jeff Gribbin, EDS <[EMAIL PROTECTED]>: > > Hi Anne, > Unless you discover a bug in CP (HIGHLY unlikely) then nothing that you d > o > in a Class G virtual machine can impact the first-level system (other tha > n > maybe in terms of excessive resource consumption if your system is > <ahem>, "inappropriately" tuned <grin>). > > Maybe it's the, "do it all again on first level" that's worrying you ... > > Well, > I tend not to, "do it all again" because I only keep the maintenance > materials on second-level - what I do for first-level is to identify the > > RESULTS of the maintenance and then copy just those parts that a running > > system requires, "up" to first level. I do this, "by hand" and set things > > up on first-level in a very manual and (relatively) labour-intensive way. > > If I don't use any automatic procedures then it's much harder to > be, "surprised" because the quantum value of each step is sufficiently > > small for me to be usually be able to fully grasp its impact before I tak > e > it - if I manually enter ten commands rather than run an EXEC containing > > those ten commands then I have time to think between each micro-step and > > confirm to myself that I'm still comfortable with what I'm about to do. > > The downside is that you have to dig around a bit and discover what is > > truly, "The tip of the iceberg" that is actually NEEDED to run the > system / subsystems and learn how to migrate those essentials to first- > level. You have to develop skills with some of the elemental commands > (such as, say, DEFNSS), but the payback is that you end up with a far > greater awareness of the detail of what's going on in your system which > > then spins off into better problem diagnosis and analysis skills and > better ways of ensuring that maintenance is non-disruptive. > > If that seems like, "all too much" and you DO want to simply, "do it all > > again" then I suggest investing effort in replicating as complete a model > > as you can of your first-level environment in your second-level system. > > Then, when you, "do it second-level" you can look for and learning how to > > deal with any unexpected side-effects that might arise (such as TCPIP > suddenly going off the air). > > The other thing of course, which I'm SURE I don't really need to tell you > , > is to take copious notes - document exactly what you did and what happene > d > as a result - including all those things that you thought at first > happened but then it turned out that they didn't, plus all those things > > that you didn't notice had happened and only discovered afterwards. > > Hmm - I'm preaching again - does any of that help or am I off-target? (If > > yes, please rephrase the question and I - plus many others, I'm sure <g> > - > will take another shot at it.) > > Regards > > Jeff Gribbin > -- Kris Buelens, IBM Belgium, VM customer support
