The problem with these "user created" or "shop standard" way of doing things, 
is they are half hazzard.

You (or your Operator), ends up being comfortable knowing they can't shutdown 
the VM system, without a little effort.  

Well, you bring up a new release (and forget to implement the shutdown fix), 
and you go into production, wham!
Or you (or your Operator) goes to another shop, which doesn't have a shutdown 
fix applied...wham!

It needs to be done, by VM Development (and no system config option to enable 
or bypass it) and we will just move on from there.  

Of course it won't be done.  For example, the new Pipes, should be a standard 
part of CMS.  If you are worried about breaking something, then name the new 
Pipes, PIPE2  (Like EXEC2 was to EXEC).  But it just needs to be there.  You 
can't write anything, for distribution with the new Pipes as you can't depend 
on it being there.  

Same goes for the cut and paste prefix commands for xedit.  Everyone has a set. 
 They are all different.
And a submit command to submit a member or a currently xedited member to a 
guest (CMSBATCH, VSE, MVS, etc).  Many of us have our own PUNCH command so we 
can have "included" members.  

But that is the problem with development folks.  They sit on the same machine, 
day after day, year after year and think all the "user add ons" is a one time 
thing.  The user add ons seem to take more time putting on a VM system then the 
install of VM!

I've been arguing with the CA folks that develop Vollie.  They finally got rid 
of the macro level code in the Panvalet interface, which means we can move to 
CICS/TS.  But instead of rewritting their shutdown process, they got rid of it. 
 CICS won't shutdown.  They recommended just doing CEMT PERFORM SHUTDOWN IMMED 
like they do.  They didn't have any idea what problems that cause in a 
production CICS system.  Developers!  

Ok, too many Coke Classics <G>.

Tom Duerbusch
THD Consulting



Law of Cat Thermodynamics

  Heat flows from a warmer to a cooler body, except in the case
  of a cat, in which case all heat flows to the cat.


>>> George Haddad <[EMAIL PROTECTED]> 11/7/2007 3:26 PM >>>
Alan Ackerman wrote:
> 1. I have never accidentally shut down a VM system. But then, I don't hav
> e any userids with class A 
>   
Nor have I ... but  once did something wrong on a Sysgen (one of my 
first) in the SP3 era that promptly corrupted the Sys directory area --- 
long before there were NODIRECT opts during startup. Fortunatley it was 
on a dedicated test sys (SFDCS2 -- fo AA's amusement). One of my mentors 
was able to help me recover with standalone tools.
> (or class D) privileges. It always makes me cringe when I see a userid wi
> th class ABCDEFG. Like 
> walking around with a loaded gun in your pocket! 
>
> I have a CLASSA EXEC that issues:
>
> SET PRIVCLAS * +A
> CP command
> SET PRIVCLAS * -A
>
> when I really need a class A command.
>   
My practice as well.
> 2. We have a mod to CP SHUTDOWN that requires the system name on the SHUT
> DOWN command. 
> Too many times an operator has shut down the wrong system.
>   
Good one. I have always changed the class ever since OVRD became 
available, but never made such a mod. I *did* modify the startup prompts 
when the CLEAN start became avail (ESA?). To an inexperienced VMer 
(which most of our Ops were), it was just too tempting a name for one to 
try before waking up their Sysprogs. The mod consisted of  removing 
"CLEAN" from the menu of choices, then changing the name in case one of 
the smart Ops happened to read a manual. If an IPL would have failed 
badly enough to need a CLEAN, they would have to call me, and under my 
guidance, they would get access to the renamed option.
> Since at least the 1984 Apple Human Interface Guidelines, it's been expec
> ted that you ask the 
> user before you let him/her do something irretreivable. 
>   
Good practice. If only  more vendors would adhere to it.

Reply via email to