Well, I'm another OT who doesn't use PUT2PROD. First, I see no reason to take on the unneccessary risks associated with PUT2PROD.
Second, I like my modified version of the traditional IBM service process even better than the documented traditional IBM service process. Let's take, for example, the "Place the Test Build Disks into Production" step for the MAINT 190 and 193 disks (pg 3-72 & 3-73 in the Service Guide) . The documented process is to copy/DDR test disks to the production disks. Yuck! Anybody with an active link to the production disks is likely to get toasted real quick because their in core copy of the directory no longer matches the physical disk. And that little note about making a backup copy of the production disk first always makes me smile. (And not just because there's no similar note in the PUT2PROD process.) Do it off hours? Why should I when I can do something better during normal hours? So, what do I do instead? I edit MAINT's directory to swap the disk addresses - test becomes production and production becomes test. After the IPL to put CP into production (which doesn't have to be immediately after) I can leisurely copy/DDR them the other direction - current production disk (old test) to current test disk (old production) without risk. Also, note that my "backup" of the production disk is the production disk itself. I've been doing it this way since the early 80's (right after the first time I got burned doing service the standard way). There's nothing more satisfying than doing this all during normal hours, requesting the operators to IPL during the night, and getting a good night's sleep. Brian Nielsen On Fri, 2 Jun 2006 07:50:17 -0400, Alan Altmark <[EMAIL PROTECTED]> wrote: >But without you Old Timers :-) actually using the "new" tools we provide >(how long has PUT2PROD been around?), and calling in the problems and ba d >ideas, improvements are slowed to a snail's pace. PUT2PROD is intended to >put service into production. If it isn't doing that correctly, causing >more harm than good, let us know. (Call it in.) But please don't just >turn away from it and ignore it. If OTs won't use it, what hope do >newbies have? > >Alan Altmark >z/VM Development >IBM Endicott >======================== ========================= ========================
