Re: VARY too many devices offline
Q: What would you do with dishonest consultants? A: The same thing you do with dishonest interns, trainees, employees, managers, CEOs, Chairmen of the Board, etc. And it depends on who "you" is. A "you" with sufficient authority must be found to take the needed action and who can take into consideration all the repercussions of his action, such as the effect on morale if he does or does not do what many think he should. Consultants do not have a monopoly on dishonesty or making mistakes. Nor do employees have a monopoly on company loyalty. One size still does not fit all. --- 100% agreement, as far as it goes. Complete honesty and integrity have to be the top priority, but not the only one. I maintain that discrimination on the basis of ability is still an acceptable practice, provided methods of improvement are available. An operator who makes a mistake because of lack of education should have an oppurtunity to learn, and should be better supervised. An operator who willingly diverts funds, or other resources, to his private use and profit, to the company's detriment, should be terminated and, if possible and feasable, prosecuted. Every employee has an obligation to safeguard the stockholders from unethical and/or illegal activities that cause losses, either financial or in the public image of the company (resulting in indirect losses). As systems programmers, regardless of the actual title, we hold positions of high trust and, as such, we need to set high examples. Like Caesar's wife, Calpurnia, we have to not only BE pure, but also be PERCEIVED as pure. And we need to set an example for the PFCSK's that will follow us! -- 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
Re: VARY too many devices offline
On Oct 28, 2007, at 8:07 AM, (IBM Mainframe Discussion List) wrote: In a message dated 10/25/2007 1:15:00 PM Central Standard Time, [EMAIL PROTECTED] writes: What would you do with dishonest consultants? The same thing you do with dishonest interns, trainees, employees, managers, CEOs, Chairmen of the Board, etc. And it depends on who "you" is. A "you" with sufficient authority must be found to take the needed action and who can take into consideration all the repercussions of his action, such as the effect on morale if he does or does not do what many think he should. Consultants do not have a monopoly on dishonesty or making mistakes. Nor do employees have a monopoly on company loyalty. One size still does not fit all. Bill Fairchild Franklin, TN Bill, Point taken. Since the company I worked for was non-confrontational the whole incident was more or less swept under the carpet. Except for the additional person that was hired to keep any future trespassing from happening nothing really happened. It was a strange company as employees were extremely loyal and honest. There was no money handling (that I ever heard of) (except for petty cash) that was done at the site so honesty was really never an issue. They were strict when it came to expense accounts as one time I got called up and about a dinner I had at GUIDE and I had to redo parts of the expense report. I just reshuffled the distribution around. They grumbled a little bit. But it wasn't like I was extravagant I think I marked down I had a 26 dollar dinner (I was allowed $20). (this was in the 70's) . The computer operations was the hot spot about firing people. The manager there was the "man". He ran his "ship" like a captain in the 1600's, he let his managers get away with murder but the peons (operators) were regularly whipped. Despite that the operators were extremely loyal and really did work. The company (division) was pretty much run on a almost family type basis. The operations being the exception to the rule. I was not aware of the severe politics of the corporate headquarters until I was temporarily assigned there a few years later. I was asked to stay on but said no because of the politics. I am sure of this had occurred out of the corporate HQ that they would have been fired on the spot. We had a few political people that worked in the DC that made major mistakes that almost cost the company millions of dollars and they skated through without being fired (although in truth they were put in positions of less importance). The point to this was that people that were not employed by the company (consultants) were held to a different level than employees, it was a much more restrictive level. Just by that level alone they should have been let go. Ed -- 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
Re: VARY too many devices offline
In a message dated 10/25/2007 1:15:00 PM Central Standard Time, [EMAIL PROTECTED] writes: > What would you do with dishonest consultants? The same thing you do with dishonest interns, trainees, employees, managers, CEOs, Chairmen of the Board, etc. And it depends on who "you" is. A "you" with sufficient authority must be found to take the needed action and who can take into consideration all the repercussions of his action, such as the effect on morale if he does or does not do what many think he should. Consultants do not have a monopoly on dishonesty or making mistakes. Nor do employees have a monopoly on company loyalty. One size still does not fit all. Bill Fairchild Franklin, TN ** See what's new at http://www.aol.com -- 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
Re: VARY too many devices offline
1. Everyone can make a mistake, including those who claim otherwise. 2. Firing someone for an error is not good solution, at least as a rule. Education is better than terror. IMHO it is much better to avoid mistakes. How to do it: 2.1 Education. Skilled operator *understands* command, syntax, which reduces risk of some mistakes. Not applicable to Hal's example. 2.2 Procedures. Simply *avoid* risky commands. Do you want o vary some devices offline ? Why ? Can it be *scripted* ? Maybe this is well known, fixed range of devices. My operators do make mistakes. However they have never blew up any system. Never. I didn't give them an opportunity (chance) to do it. Everytime I hear about operator who blew up something, he did it while performing dangerous things. In Poland we say "ape with razor" or "you shouldn't give gun to a madman". If the action is dangerous, then you shouldn't rely on less educated staff. My $0.02 (after 40% taxes and 23% social sec). -- Radoslaw Skorupka Lodz, Poland Hal Merritt wrote: Personally, I'd view this as a management issue, not a technical issue. The root problem in my opinion was the need for an operator to issue the command in the first place. When you require human intervention, errors are to be expected and therefore tolerated. There are a number of such commands where a single keystroke error can and will bring you down. For example, try the command "$P PRINTER1", but hit enter rather than the space bar. (That is recoverable, but it is unlikely anyone will discover that until after the IPL.) So, yes, reassign the operators (all of them) and don't replace them. My $0.02 (before taxes) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jan MOEYERSONS Sent: Monday, October 22, 2007 7:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VARY too many devices offline Not being to tongue in cheek here.. but we used to fire the operator. Ed And what good does that do to the integrity of your systems??? Does that prevent anyone else from making a mistake? Did you never make a typo in any of the commands you ever entered? (If you never did, then that means you never entered any...) Jantje. -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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
Re: VARY too many devices offline
On Oct 25, 2007, at 7:13 PM, Tony wrote: Lots of people had there 2cents worth so I might as well give mine. A max units offline in SYSPARMS would kill this forever and surely take 10/20 minutes to code. Does anyone ever ask IBM to do anything these days or do we just sit back and take what we are given? Tony, Way back when 3.8 (?) there was a limit (IIRC) and people asked for it to be lifted. Its been AGES so I could be wrong but I am pretty sure there was a limit at one time. Ed -- 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
Re: VARY too many devices offline
On Oct 25, 2007, at 6:29 PM, Gerhard Adam wrote: Where do these scenarios get dreamed up? If you have a services issue, then you can always fire someone if they aren't living up to the terms (or your perception) of an agreement. If you're wrong, then a lawsuit by the other party may help clear things up. If you suspect something criminal, by all means you can see if a District Attorney is willing to go for it, otherwise you can pursue a civil suit. The rest is simply nonsense. Firing someone for a mistake is silly. Despite the melodramatic points raised, even when someone is KILLED, the individual responsible may be liable, but unless negligence or criminal intent can be proven its highly unlikely that they will be fired. In fact, from the legal perspective the individual making the mistake may not even be considered responsible if they can prove that they weren't adequately trained for the responsibility given to them. Adam Adam: I am not sure I agree with you (all the time). Most companies that I have seen have fired individuals for mistakes. It comes down, IMO the seriousness of the mistake. In a typical data center it is unlikely that it would cause a death but in a Hospital setting it is possible for that to happen. In the other extreme I have seen people save their jobs because of stupidity . A manager deleted dd statements out of a proc because not enough tape drives weren't available, if that wasn't bad enough it was a permanent change so backups of system volumes stopped happening for over 2 years before it was discovered that backups weren't being taken. Causing all sorts of chaos when the drive(s) went south. He blamed it on operations for not noticing it and got away with it. As to liability of an operator I have never heard of an operator being sued, maybe his/her boss but not an operator. After all corporate pockets are a lot deeper than a typical operators. What is the saying, you can't get blood from a turn-up. It may have happened but it would have to be rare. Besides I would think that management would rather have an operator as a scapegoat after all operators are pretty much a dime a dozen. I would think that a person testing blood would not have personal liability insurance but the company he/she works for would have liability insurance. After all you go after the entity with the deep pockets. Ed -- 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
Re: VARY too many devices offline
Lots of people had there 2cents worth so I might as well give mine. A max units offline in SYSPARMS would kill this forever and surely take 10/20 minutes to code. Does anyone ever ask IBM to do anything these days or do we just sit back and take what we are given? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Field, Alan C. Sent: 19 October 2007 15:14 To: IBM-MAIN@BAMA.UA.EDU Subject: VARY too many devices offline Yesterday someone issued an RO *ALL,V 708-7014,OFFLINE which led to a number of unplanned IPLs. Now mgmt wants to implement a fingerchecker. I searched CBT for a command exit that might ask something like "you really want to vary 26,000 devices offline?" How do others shops handle this, have you got an exit you'd be willing to share before we re-invent the wheel. Thanks, Alan -- 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 Free Edition. Version: 7.5.488 / Virus Database: 269.15.0/1076 - Release Date: 17/10/2007 19:53 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.10/1091 - Release Date: 24/10/2007 14:31 -- 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
Re: VARY too many devices offline
On Oct 25, 2007, at 4:29 PM, Ted MacNEIL wrote:
I was getting fed up with Ed Gould's constant talk of firing people.
Ed has been retired for so long that any opinion he has is not
worth listening to.
From STAR TREK ("Friday's Child"):
His words are unimportant, and we do not hear them!
Ted:
If you too busy to stop for gas you are going to run out of oil:)
Ed
--
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
Re: VARY too many devices offline
On Oct 25, 2007, at 4:21 PM, Eric Bielefeld wrote: I guess I saw the part about turning SMF recording off, but it didn't register. Yes, if they were stealing services or committing some act of fraud, maybe they should get fired. I used the quote below more because I was getting fed up with Ed Gould's constant talk of firing people. I know I have caused a few IPLs in my career. I don't think people should be fired for one or two honest mistakes. If someone makes mistakes over and over, thats one thing, but making one mistake that causes an outage shouldn't be grounds for firing. Stealing *IS* grounds for firing or do you want to have dishonest people working at you bank robbing you blind all the time .. Once is OK? Ed -- 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
Re: VARY too many devices offline
Where do these scenarios get dreamed up? If you have a services issue, then you can always fire someone if they aren't living up to the terms (or your perception) of an agreement. If you're wrong, then a lawsuit by the other party may help clear things up. If you suspect something criminal, by all means you can see if a District Attorney is willing to go for it, otherwise you can pursue a civil suit. The rest is simply nonsense. Firing someone for a mistake is silly. Despite the melodramatic points raised, even when someone is KILLED, the individual responsible may be liable, but unless negligence or criminal intent can be proven its highly unlikely that they will be fired. In fact, from the legal perspective the individual making the mistake may not even be considered responsible if they can prove that they weren't adequately trained for the responsibility given to them. Adam Yes, if they were stealing services or committing some act of fraud, maybe they should get fired. > A clue was given when it was said that SMF had been turned off. Now, if > charge-back accounting was being done AND these consultants were in some > way being charged for CPU time (and/or other resources) that they used > then this was a form of theft or embezzlement/fraud. > > That being the case: depending on what corporate counsel advised, I > would present them with a bill for 1.5 times their average use on a > weekend, point out specific points in any contract that shows or states > this is a material breach. -- 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
Re: VARY too many devices offline
On Oct 25, 2007, at 5:52 PM, Rick Fochtman wrote: What would you do with dishonest consultants? I'd be taking one really HARD LOOK at the selection process! Let's treat the whole problem, not just the most obvious symptom! Rick, The consultants came out of the departments pocket. Their budget was entirely outside of the DC budget. We had little to say (read no say) about how they spent their $$. Ed -- 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 -- 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
Re: VARY too many devices offline
A rogue oprerative may sneak in... I think they have a few times... But we will definitely find that person. And... As an added bonus... Whatever they thought they may have destroyed... It's all recoverable. SUPER DISCLAIMER - This is my own perception Not to be affiliated in any way with my company. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Thursday, October 25, 2007 6:53 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VARY too many devices offline What would you do with dishonest consultants? I'd be taking one really HARD LOOK at the selection process! Let's treat the whole problem, not just the most obvious symptom! -- 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 -- 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
Re: VARY too many devices offline
What would you do with dishonest consultants? I'd be taking one really HARD LOOK at the selection process! Let's treat the whole problem, not just the most obvious symptom! -- 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
Re: VARY too many devices offline
>I was getting fed up with Ed Gould's constant talk of firing people.
Ed has been retired for so long that any opinion he has is not worth listening
to.
>From STAR TREK ("Friday's Child"):
His words are unimportant, and we do not hear them!
-
Too busy driving to stop for gas!
--
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
Re: VARY too many devices offline
I guess I saw the part about turning SMF recording off, but it didn't register. Yes, if they were stealing services or committing some act of fraud, maybe they should get fired. I used the quote below more because I was getting fed up with Ed Gould's constant talk of firing people. I know I have caused a few IPLs in my career. I don't think people should be fired for one or two honest mistakes. If someone makes mistakes over and over, thats one thing, but making one mistake that causes an outage shouldn't be grounds for firing. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: "Thompson, Steve" <[EMAIL PROTECTED]> Eric: What would you do with dishonest consultants? A clue was given when it was said that SMF had been turned off. Now, if charge-back accounting was being done AND these consultants were in some way being charged for CPU time (and/or other resources) that they used then this was a form of theft or embezzlement/fraud. That being the case: depending on what corporate counsel advised, I would present them with a bill for 1.5 times their average use on a weekend, point out specific points in any contract that shows or states this is a material breach. It would also be pointed out, if the contract does not preclude it, that this behavior crossed the line of GRAND THEFT. And then tell them we would entertain a payment schedule to heal any breach that this behavior caused. But the situation would be well documented and would definitely be part of any future negotiations. Regards, Steve Thompson -- 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
Re: VARY too many devices offline
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Thursday, October 25, 2007 2:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VARY too many devices offline Eric: What would you do with dishonest consultants? A clue was given when it was said that SMF had been turned off. Now, if charge-back accounting was being done AND these consultants were in some way being charged for CPU time (and/or other resources) that they used then this was a form of theft or embezzlement/fraud. That being the case: depending on what corporate counsel advised, I would present them with a bill for 1.5 times their average use on a weekend, point out specific points in any contract that shows or states this is a material breach. It would also be pointed out, if the contract does not preclude it, that this behavior crossed the line of GRAND THEFT. And then tell them we would entertain a payment schedule to heal any breach that this behavior caused. But the situation would be well documented and would definitely be part of any future negotiations. Regards, Steve Thompson -- Opinions expressed are strictly my own -- -- 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
Re: VARY too many devices offline
On Oct 25, 2007, at 1:50 PM, Eric Bielefeld wrote: Ed - You sure have a thing about firing people. Its a good thing you're not employed now, as you can't fire anyone. Lets look at some of the costs of firing a bunch of consultants. Lets just say there were 5 consultants who did what you described. Say the average time they have been working was 6 months. By now they know the projects they are working on, and how your company does things. You would have your management throw out all the training and knowledge in your systems these people had, and more than likely waste most of the work they already did. Firing people or consultants for mistakes can be very expensive. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 Eric: What would you do with dishonest consultants? Ed -- 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
Re: VARY too many devices offline
Ed - You sure have a thing about firing people. Its a good thing you're not employed now, as you can't fire anyone. Lets look at some of the costs of firing a bunch of consultants. Lets just say there were 5 consultants who did what you described. Say the average time they have been working was 6 months. By now they know the projects they are working on, and how your company does things. You would have your management throw out all the training and knowledge in your systems these people had, and more than likely waste most of the work they already did. Firing people or consultants for mistakes can be very expensive. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: "Ed Gould" <[EMAIL PROTECTED]> They were not happy at all. I just wish the consultants had been fired. Ed -- 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
Re: VARY too many devices offline
David Long wrote: In 1989 I was working in a shop where the operator accidentally entered the ipl date as yy/mm/98 instead of yy/mm/89. This was not noticed until all the jobs that read tapes started failing because the tape datasets had expired. I ended up writing a little program to make the operator verify that the date was correct before the ipl could procede. But, the operator that made the mistake was fired on the spot. Right? ;-) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: VARY too many devices offline
Personally, I'd view this as a management issue, not a technical issue. The root problem in my opinion was the need for an operator to issue the command in the first place. When you require human intervention, errors are to be expected and therefore tolerated. There are a number of such commands where a single keystroke error can and will bring you down. For example, try the command "$P PRINTER1", but hit enter rather than the space bar. (That is recoverable, but it is unlikely anyone will discover that until after the IPL.) So, yes, reassign the operators (all of them) and don't replace them. My $0.02 (before taxes) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jan MOEYERSONS Sent: Monday, October 22, 2007 7:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VARY too many devices offline > >Not being to tongue in cheek here.. but we used to fire the operator. > >Ed > And what good does that do to the integrity of your systems??? Does that prevent anyone else from making a mistake? Did you never make a typo in any of the commands you ever entered? (If you never did, then that means you never entered any...) Jantje. NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
Re: VARY too many devices offline
On Oct 25, 2007, at 9:19 AM, David Long wrote: On Tue, 23 Oct 2007 18:29:02 -0500, Ed Gould <[EMAIL PROTECTED]> wrote: I wish the person this had happened to would pipe up, but to set the record more precisely because of a bad date RACF (This is hear say) did something to the (RACF) database that essentially rendered the system not operatrional. Just by IPLing (again) with the correct date was too late as the RACF database unusable. I do not know if they had backups or any specifics. I heard they were down for a day or so. Luckily this was a weekend. Ed Ed, In 1989 I was working in a shop where the operator accidentally entered the ipl date as yy/mm/98 instead of yy/mm/89. This was not noticed until all the jobs that read tapes started failing because the tape datasets had expired. I ended up writing a little program to make the operator verify that the date was correct before the ipl could procede. Dave Long Dave, Congratulations. At one place where I worked. We had to have two operators sign off on the date/time at IPL time. However one Sunday when I was testing they sill managed to flub it. It didn't matter as it was a IPL we were doing to test out an IPO. Speaking of "operator error", this was back 30 years or so. We had a data center that worked most weekends but not all. We had a consulting company come in and IPL the system (on their own with no operations people around). They IPLed with a wrong date (on purpose) and turned off SMF and a few other things. That Monday morning I was doing some research and ran across the IPL on a console that was out of view of the system console. I verified with the operations people that no one had worked and also within our sysprog group about IPL's and it was all denied. I took the console printout up to the VP of the data center and gave it to him and told him of my suspicions . The jobs that were run when the system was supposed to be down were of a division that had lots of contract programmers. The VP called up the division's manager and let him have it. After that the data center always had a baby sitter when no one was scheduled to work. He charged the other 3 divisions with the labor cost of the baby sitter. They were not happy at all. I just wish the consultants had been fired. Ed -- 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
Re: VARY too many devices offline
On Tue, 23 Oct 2007 18:29:02 -0500, Ed Gould <[EMAIL PROTECTED]> wrote: >I wish the person this had happened to would pipe up, but to set the >record more precisely because of a bad date RACF (This is hear say) >did something to the (RACF) database that essentially rendered the >system not operatrional. Just by IPLing (again) with the correct date >was too late as the RACF database unusable. I do not know if they had >backups or any specifics. I heard they were down for a day or so. >Luckily this was a weekend. > >Ed Ed, In 1989 I was working in a shop where the operator accidentally entered the ipl date as yy/mm/98 instead of yy/mm/89. This was not noticed until all the jobs that read tapes started failing because the tape datasets had expired. I ended up writing a little program to make the operator verify that the date was correct before the ipl could procede. Dave Long -- 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
Re: VARY too many devices offline
I had a problem with IPLing I think a year behind the current date. This was running under VM. VM was IPL'd with the wrong date, passing the date along to each guest. We had 5 DOS guests, one MVS guest, and one VS1 guest at the time. This was our first conversion of one of the DOS guests to MVS. I don't think there were any problems while running a year back, but something led me to check the date, and I discovered we had the wrong one. We shut everything down, and reIPL'd VM with the correct date, and brought everything back up. The only problem after coming back up was that anyone who had logged on TSO while the date was 1 year behind couldn't log on. That was me, and a few of the programmers and the operator. This led to my getting my 2nd TSO id, which I wanted in the beginning, but a girl who worked there for a while didn't want anyone to have 2 TSO ids. It so happened that she wasn't home, so I kind of sat there and couldn't even log on for about an hour, until she finally got home and called me. Then I logged on with her password and ID and reset my own ID. Needless to say, it didn't take much convincing to get a 2nd TSO id after that. -- RACF has the capability of disallowing a user to logon if he's been inactive for a certain number of days. We got stung by this at Clearing long ago, when even STC wasn't allowed to logon. We installed an exit to bypass that difficulty. I believe now that RACF has been altered such that started tasks aren't limited in that fashion. We also had a proc that could be started from the console to restore certain critical ID's so we could recover from a similar disaster in the future. When we first got stung, we were down for an entire CBOT trading session and the repercussions were VERY MESSY, to say the least. -- 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
Re: VARY too many devices offline
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Tuesday, October 23, 2007 6:29 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VARY too many devices offline On Oct 23, 2007, at 3:17 AM, Zaromil Tisler wrote: > On Tue, 23 Oct 2007 08:54:31 +0100, Kenny Fogarty wrote: > >> I agree, but, if the wrong date, or IPL parm, or whatever is entered, >> then the chances are you're going to have to re-IPL to rectify the >> situation. As you said above, if RACF doesn't start, you can go back >> to see why, and take steps to fix the issue. I wish the person this had happened to would pipe up, but to set the record more precisely because of a bad date RACF (This is hear say) did something to the (RACF) database that essentially rendered the system not operatrional. Just by IPLing (again) with the correct date was too late as the RACF database unusable. I do not know if they had backups or any specifics. I heard they were down for a day or so. Luckily this was a weekend. During Y2K testing, a future date was picked. Since all RACF IDs were beyond the revoke dates... So IPL with the correct date left them with having to do an OPERATOR override and allow a SPECIAL/AUDITOR ID (similar to IBMUSER, or it was IBMUSER) to logon even though it was revoked. Then it is a long laborious process to re-activate every revoked account. It was my understanding that this happened during a required Y2K test at a Nuclear plant. I'm told it got real interesting when all the access badges went dead as they hadn't been used for over 2 years as far as the security system was concerned. Regards, Steve Thompson -- Opinions expressed are my own. -- -- 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
Re: VARY too many devices offline
Tom, No one died, and no one got fired either. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Tom Schmidt <[EMAIL PROTECTED]> > Eric, > > Nobody died as a result of the operator error, right? ;) > > -- > Tom Schmidt > Madison, WI> Search the archives at http://bama.ua.edu/archives/ibm- main.html > -- 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
Re: VARY too many devices offline
On Tue, 23 Oct 2007 19:48:11 -0500, Eric Bielefeld wrote: >I had a problem with IPLing I think a year behind the current date. This >was running under VM. VM was IPL'd with the wrong date, passing the date >along to each guest. ...snip... >The only problem after coming back up was that anyone >who had logged on TSO while the date was 1 year behind couldn't log on. >That was me, and a few of the programmers and the operator. Eric, Nobody died as a result of the operator error, right? ;) -- Tom Schmidt Madison, WI -- 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
Re: VARY too many devices offline
I had a problem with IPLing I think a year behind the current date. This was running under VM. VM was IPL'd with the wrong date, passing the date along to each guest. We had 5 DOS guests, one MVS guest, and one VS1 guest at the time. This was our first conversion of one of the DOS guests to MVS. I don't think there were any problems while running a year back, but something led me to check the date, and I discovered we had the wrong one. We shut everything down, and reIPL'd VM with the correct date, and brought everything back up. The only problem after coming back up was that anyone who had logged on TSO while the date was 1 year behind couldn't log on. That was me, and a few of the programmers and the operator. This led to my getting my 2nd TSO id, which I wanted in the beginning, but a girl who worked there for a while didn't want anyone to have 2 TSO ids. It so happened that she wasn't home, so I kind of sat there and couldn't even log on for about an hour, until she finally got home and called me. Then I logged on with her password and ID and reset my own ID. Needless to say, it didn't take much convincing to get a 2nd TSO id after that. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: "Ed Gould" <[EMAIL PROTECTED]> I wish the person this had happened to would pipe up, but to set the record more precisely because of a bad date RACF (This is hear say) did something to the (RACF) database that essentially rendered the system not operatrional. Just by IPLing (again) with the correct date was too late as the RACF database unusable. I do not know if they had backups or any specifics. I heard they were down for a day or so. Luckily this was a weekend. Ed -- 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
Re: VARY too many devices offline
On Oct 23, 2007, at 2:54 AM, Kenny Fogarty wrote: How would you handle a person that scrutinizes blood for a living and mistakes a diagnosis ? In some case an operator is just as "guilty" as the blood analyzer. If you say thats not the same, I would agree but not in all I wouldn't even begin to make the analogy. But, mistakes happen. That's a fact of life, and, putting an unbearable amount of strain on someone, as in - make a mistake and you're fired, will not, under any circumstances, help that person to not make mistakes. In fact, I'd go as far as to say it would only make things worse. Well, I am not sure I agree with you about "worse". The operators usually had a great time (especially off day shift) The day shift only had one occurrence after that bad IPL. We (sysprogs) were consulted before any first time commands were entered so we were by the operators side as it was keyed in. Issues? not really the operators enjoyed their jobs and everyone was a little more productive. We did have an issue with delays of tape mounts we ended up buying hardware to monitor those events . The finger pointing was put squarely on the operators. But other than that the operators really liked their job (of course there were one or two exceptions) and everyone went about their own jobs happily. I think that department had the lowest turnover of any. If an operator put in a wrong date at IPL and (because of that) RACF refuses to come up and there is no backout or even worse datasets gets scratched because of the operator error which leads to a fine from say the SEC (or take you pick of agency). See all of those issues? All perfectly valid. But, if I were having to unravel the mess that came about from the wrong input at the console, the operator would not be the person who should be blamed. There should be contingency in place so that if RACF refuses to come up, we get alerted very early on as to why, and have steps in place to remedy the situation. Perhaps by re-IPL'ing. After all, that's what you're going to do in 99% of cases if a wrong parameter is passed at IPL time. See above reply If datasets get scratched, where's the back up? What's the contingency in place to restore the data. If there isn't one, that's not the guy who entered 'U' on the console instead of 'N''s fault. Backup in our case was 24 hours ago, I can't speak for the actual company that it happened to. There are degrees of error of course some are who cares to a possible company going bankrupt there are in the last case MANY people being out of work (possibly 1000's or more) would you not fire the person? If the company went bankrupt, it wouldn't be because someone varied off the wrong device. Hmmm well how about this scenario. System A is writing the master file to tape drive d system b varies online the same tape drive and it starts to write to that tape drive you would have a clobbered tape and not know it for some time . If it was discovered during the database load that the tape was no good. The database would not be loaded and the firm could not open the next day. Not far fetched at all. I think you are comparing apples and oranges. An operator can by mistake put the company out of business, a programmer can cause loss revenue and yes possibly a fine. I'd love to see how the wrong prompt on the console was traced back to the one thing that put the company out of business. Seriously, if anyone has any stories along those lines, I'd love to hear it. As would any maker of automation software, because it would be the most amazing sales pitch ever. See above and wait to see if the sysprog it happened to will pipe up. BUT that should have been found in QA before the program goes live. In other words their work is checked by others. QA can pick up a lot of things, but, for example, can QA pick up an application program that performs ten million inserts and no commit into a DB2 table, then, for whatever reason, abend, and have DB2 rollback all its work, thus rendering the objects unavailable for x hours? I've seen it done. - Didn't make the company go bankrupt though. It depends on the company. If its a matter of opening (or not) for daily trading chances are good they will be out of business. If its for a small business I might agree but small business's probably don't have mainframes either. An operator does not have this luxury. Yes programmers can make mistakes but (in most cases) its not a shut the front doors and turn off the power whoever is the last one to leave. An operator can do so with a small "oops". That is why an operator, IMO must go through several years of training so they CAN'T make stupid mistakes. I agree that console commands are free from any sort of QA, however, there are ways and means to ensure that mistakes are minimised. Automation products can help here, or, if they're not available, an application program can write out WTO or
Re: VARY too many devices offline
On Oct 23, 2007, at 3:17 AM, Zaromil Tisler wrote: On Tue, 23 Oct 2007 08:54:31 +0100, Kenny Fogarty wrote: I agree, but, if the wrong date, or IPL parm, or whatever is entered, then the chances are you're going to have to re-IPL to rectify the situation. As you said above, if RACF doesn't start, you can go back to see why, and take steps to fix the issue. I wish the person this had happened to would pipe up, but to set the record more precisely because of a bad date RACF (This is hear say) did something to the (RACF) database that essentially rendered the system not operatrional. Just by IPLing (again) with the correct date was too late as the RACF database unusable. I do not know if they had backups or any specifics. I heard they were down for a day or so. Luckily this was a weekend. Ed -- 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
Re: VARY too many devices offline
On Oct 23, 2007, at 9:51 AM, Jon Brock wrote: I hate to even think about the pain that might have caused. Jon Jon, A person here on the list had to go through the exercise maybe he will speak up and give details. Ed -- 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
Re: VARY too many devices offline
Yes, I quite agree with you. At our organization we do brainstorm about what could potentially go wrong and we admit that humans are error prone for a whole variety of reasons. So we do try to have contingencies planned as well as procedures to catch gross errors. My management is very strict that we should present the benefits and drawbacks of all of our procedures, and consider what could go wrong. Sometimes this makes us slow to implement new systems, but they do tend to be quite reliable. But they have to be, because many people depend upon our services, including the dispatch of police and ambulances, as well as payrolls for public services. On 10/23/07, Howard Brazee <[EMAIL PROTECTED]> wrote: > > On 22 Oct 2007 14:12:07 -0700, [EMAIL PROTECTED] (Zahir Hemini) > wrote: > > >This is exactly why there are products like CA OPS/MVS and Automan and > >probably a few others. People sometimes are new to a procedure, they do > >accidentally make mistakes, and read and write instructions incorrectly. > > Which is the response to the message that compared operator errors > with blood tester errors. > > People do make mistakes. When the results of likely mistakes are too > expensive, procedures and tools need to be created to minimize the > impact of those mistakes. > > Lots of software design is like the design of sidewalks which have > lines scored on them to encourage the breaks into a predictable > direction. Don't deny that errors happen- handle them. > > -- > 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 > -- 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
Re: VARY too many devices offline
On 22 Oct 2007 18:43:18 -0700, [EMAIL PROTECTED] wrote: > What >should happen to a computer operator in the US Marine Corps whose typo causes >an infantry platoon to be destroyed by friendly fire or a human error >resulting in a $1 loss? One size does not fit all. Let the punishment fit >the >crime. If that happens, punishment is too late.Management has screwed up relying on a system that is that vulnerable. -- 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
Re: VARY too many devices offline
On 22 Oct 2007 14:12:07 -0700, [EMAIL PROTECTED] (Zahir Hemini) wrote: >This is exactly why there are products like CA OPS/MVS and Automan and >probably a few others. People sometimes are new to a procedure, they do >accidentally make mistakes, and read and write instructions incorrectly. Which is the response to the message that compared operator errors with blood tester errors. People do make mistakes. When the results of likely mistakes are too expensive, procedures and tools need to be created to minimize the impact of those mistakes. Lots of software design is like the design of sidewalks which have lines scored on them to encourage the breaks into a predictable direction. Don't deny that errors happen- handle them. -- 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
Re: VARY too many devices offline
I hate to even think about the pain that might have caused. Jon or the operator who put a future date at IPL time and really screwed up RACF. (story I heard from another company) -- 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
Re: VARY too many devices offline
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Bob Shannon > > > Operators (especially console operators) are extremely > competent and > > if they screw up, IMO, they need to be fired. > > As a systems programmer I'm glad I wasn't fired every time I > screwed something up. Indeed. In that kind of environment I'd have become a machinist a long time ago (probably be a "former machinist" by now; I've certainly made my share of scrap in the shop working part-time). -jc- -- 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
Re: VARY too many devices offline
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Bob Shannon > Sent: Monday, October 22, 2007 4:34 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: VARY too many devices offline > > > > Operators (especially console operators) are extremely > competent and if > > they screw up, IMO, they need to be fired. > > As a systems programmer I'm glad I wasn't fired every time I > screwed something up. > > Bob Shannon Yea! Like the time under OS/VS1 that I compressed SYS1.LINKLIB using IEBCOPY. So much for __that__ system! Luckily for me, this shop had two 370/145's running the same version of the OS, so that I could use the 2nd system to recover SYS1.LINKLIB of the 1st one. This was when I was first in the business around 1979. Or, more recently, so of the problems that we've been having going from 1.6 to 1.8 (messed up the APF list and CAS9 failed - not a good thing since our IPL is automated). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: VARY too many devices offline
"Zaromil Tisler" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > On Tue, 23 Oct 2007 08:54:31 +0100, Kenny Fogarty wrote: > > >I agree, but, if the wrong date, or IPL parm, or whatever is entered, > >then the chances are you're going to have to re-IPL to rectify the > >situation. As you said above, if RACF doesn't start, you can go back > >to see why, and take steps to fix the issue. > > I absolutely agree. It is just ridiculous to make operators responsible for > design shortages in an operating system. How comes system programmers > haven't seen the danger of losing system(s) and / or data through a single > error (or a typo) in all these cases? > > -- > Zaromil Right, like the beautiful $PQ command in the early 80's, when it still was accepted without parameters, guess what it purged? After we discovered it, the command was corrected to require parameters. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- 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
Re: VARY too many devices offline
On Tue, 23 Oct 2007 08:54:31 +0100, Kenny Fogarty wrote: >I agree, but, if the wrong date, or IPL parm, or whatever is entered, >then the chances are you're going to have to re-IPL to rectify the >situation. As you said above, if RACF doesn't start, you can go back >to see why, and take steps to fix the issue. I absolutely agree. It is just ridiculous to make operators responsible for design shortages in an operating system. How comes system programmers haven't seen the danger of losing system(s) and / or data through a single error (or a typo) in all these cases? -- Zaromil -- 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
Re: VARY too many devices offline
> > How would you handle a person that scrutinizes blood for a living and > mistakes a diagnosis ? > In some case an operator is just as "guilty" as the blood analyzer. > If you say thats not the same, I would agree but not in all I wouldn't even begin to make the analogy. But, mistakes happen. That's a fact of life, and, putting an unbearable amount of strain on someone, as in - make a mistake and you're fired, will not, under any circumstances, help that person to not make mistakes. In fact, I'd go as far as to say it would only make things worse. > If an operator put in a wrong date at IPL and (because > of that) RACF refuses to come up and there is no backout or even > worse datasets gets scratched because of the operator error which > leads to a fine from say the SEC (or take you pick of agency). See all of those issues? All perfectly valid. But, if I were having to unravel the mess that came about from the wrong input at the console, the operator would not be the person who should be blamed. There should be contingency in place so that if RACF refuses to come up, we get alerted very early on as to why, and have steps in place to remedy the situation. Perhaps by re-IPL'ing. After all, that's what you're going to do in 99% of cases if a wrong parameter is passed at IPL time. If datasets get scratched, where's the back up? What's the contingency in place to restore the data. If there isn't one, that's not the guy who entered 'U' on the console instead of 'N''s fault. > There are degrees of error of course some are who cares to a possible > company going bankrupt there are in the last case MANY people being > out of work (possibly 1000's or more) would you not fire the person? If the company went bankrupt, it wouldn't be because someone varied off the wrong device. > I think you are comparing apples and oranges. An operator can by mistake put > the company out of business, a programmer can cause loss revenue and yes > possibly a fine. I'd love to see how the wrong prompt on the console was traced back to the one thing that put the company out of business. Seriously, if anyone has any stories along those lines, I'd love to hear it. As would any maker of automation software, because it would be the most amazing sales pitch ever. > BUT that should have been found in > QA before the program goes live. In other words their work is checked > by others. QA can pick up a lot of things, but, for example, can QA pick up an application program that performs ten million inserts and no commit into a DB2 table, then, for whatever reason, abend, and have DB2 rollback all its work, thus rendering the objects unavailable for x hours? I've seen it done. - Didn't make the company go bankrupt though. > An operator does not have this luxury. Yes programmers can > make mistakes but (in most cases) its not a shut the front doors and > turn off the power whoever is the last one to leave. An operator can > do so with a small "oops". That is why an operator, IMO must go > through several years of training so they CAN'T make stupid mistakes. I agree that console commands are free from any sort of QA, however, there are ways and means to ensure that mistakes are minimised. Automation products can help here, or, if they're not available, an application program can write out WTO or WTOR messages with meaningful text, which can also help an operator make a decision. Training does not, and never will ensure that mistakes are never made. Training educates, and helps people understand better, but it never, ever eradicates mistakes from any process. > Its possible that a programmer could write a program that > misdiagnoses a test (health) result and yes that could lead to the > persons death, but presumably there are other fingers in the stew to > catch the errors. I agree with that, and, broadly, that's the point I was trying to make. There should be enough tech support/ops support/sys progs around to see what went wrong, and implement some sort of contingency to rectify the mistake with the minimum of outage/cost to the company, be that restoring data, re-IPLing a system, or whatever. > In the case of an operator there is no way to catch all errors that could > cause a major issue. There are ways to catch all operator entries from the console via various automation products which can interrogate what has been entered, and take appropriate measures. > Catching a Vary is a small part of any possible error. Catching a bad date at > lets > say early on in the IPL process is impossible by any of the suggestions > mentioned as the exits (programs) are not available then. I agree, but, if the wrong date, or IPL parm, or whatever is entered, then the chances are you're going to have to re-IPL to rectify the situation. As you said above, if RACF doesn't start, you can go back to see why, and take steps to fix the issue. There must always be contingency plans in place to catch human errors, but, to go back to the original
Re: VARY too many devices offline
On Oct 22, 2007, at 11:28 PM, Mark Post wrote: On Mon, Oct 22, 2007 at 11:31 PM, in message <[EMAIL PROTECTED]>, Ed Gould <[EMAIL PROTECTED]> wrote: -snip- I don't believe that its a matter of "first error" but what the error was. This was your argument for most of this thread. Good to see you abandon it. Even so, I'm glad I never worked in the same group or even company as you. I would have left as soon as possible once I understood there was no room for human error. Mark, As I stated before errors are OK just as long as they don't hurt. Now the question comes in degrees of HURT. BTW I agreed in someways about errors and any decision to fire person to a degree. It was essentially (to me) how bad was the command and if it did any damage. I know of one time an operator typed in quiesce and it did exactly what it was supposed to do put the system in a wait state. Did it cause damage no (unless you count response time) that to me was a tossup but it did impact several hundred data entry types and 100 or so programmers. Was he fired? NO but he was talked to rather sharply. Did he screw up again, nope. Lesson learned. Ed -- 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
Re: VARY too many devices offline
>>> On Mon, Oct 22, 2007 at 11:31 PM, in message <[EMAIL PROTECTED]>, Ed Gould <[EMAIL PROTECTED]> wrote: -snip- > I don't believe that its a matter of "first error" but what the error > was. This was your argument for most of this thread. Good to see you abandon it. Even so, I'm glad I never worked in the same group or even company as you. I would have left as soon as possible once I understood there was no room for human error. Mark Post -- 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
Re: VARY too many devices offline
On Oct 22, 2007, at 8:00 PM, Mark Post wrote: On Mon, Oct 22, 2007 at 8:17 PM, in message <[EMAIL PROTECTED]>, Ed Gould <[EMAIL PROTECTED]> wrote: -snip- How would you handle a person that scrutinizes blood for a living and mistakes a diagnosis ? I'm sure it happens multiple times a day, all over the country. I doubt very much they get fired for the first error. That is when medical suits come into play, a lot of stuff is covered up by them. When is the last time you have ever heard of operator insurance? -snip- There are degrees of error of course some are who cares to a possible company going bankrupt there are in the last case MANY people being out of work (possibly 1000's or more) would you not fire the person? If it were their first error, probably not. The big bosses don't know/care who they just want someone to take the fall. I believe the answer to "not their first error" would be fire the guy. Its CYA time. -snip- That is why an operator, IMO must go through several years of training so they CAN'T make stupid mistakes. Ah, you're one of those people that believe humans can be trained into not making mistakes. Dr. Deming would be shaking his head in sadness over that, if he were still alive. It is, at best, a very misguided notion. Not sure Dr Deming is (or care) misguided I will leave to the reader. It all comes down to the seriousness of the error. I have done things by accident (no one was impacted other than myself) I have done other things that have impacted people. I admitted the mistake to management. Was it life or death, no, was it important sort of but no real damage was done. If it had been I would have expected to get fired. So should an operator. -snip- Being an operator is a lot like being an anethesiologist the skill to know how much sleeping gas to administer so the patient does not awake or die. The surgeon is one part (major) of the operation an operator is a helper. That is what an operator is a helper. I guess you've never heard of death by "medical misadventure." That also happens nearly every day. Not too many of them get fired either, for their first mistake. Hmmm... there was a case (in Chicago) earlier this year about a drunk doctor during an operation. He was fired. The person died. There was also a case of a doctor not treating a man because he was Jewish. BIG time lawsuit, As I recall the guy didn't die (but could be wrong) the doctor was fired. I don't believe that its a matter of "first error" but what the error was. The computer operator does not make life and death decisions he/ she run the system but as a consequence of entering incorrect command or response can cause major damage. Do you really want any joe blow guy off the street running a console and no consequences for not doing a bad job? That is why operators, IMO must be trained. Giving anyone improper training is a whole side issue and can be discussed forever. I would like to take the position that operators are highly trained individuals and they should be given pay commensurate with duties and *strictly* held responsible for their watch. Ed -- 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
Re: VARY too many devices offline
In a message dated 10/22/2007 5:09:38 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: >Operators (especially console operators) are extremely competent and if they screw up, IMO, they need to be fired. >That's just ridiculous. I have seen operators who knew much more about what certain messages meant than I, the resident guru, did. I have seen midnight shift operators retire to the underground parking structure to smoke marijuana. I worked at a DASD vendor shop with NO operators, 110 LPARs, extremely bright and competent guru developers who had unlimited hands-on access to consoles, and anyone who deleted a non-deletable I/O error message before the microcoders could look at it would be fired. Different environments have different requirements. What should happen to a computer operator in the US Marine Corps whose typo causes an infantry platoon to be destroyed by friendly fire or a human error resulting in a $1 loss? One size does not fit all. Let the punishment fit the crime. Bill Fairchild Plainfield, IL ** See what's new at http://www.aol.com -- 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
Re: VARY too many devices offline
>>> On Mon, Oct 22, 2007 at 8:17 PM, in message <[EMAIL PROTECTED]>, Ed Gould <[EMAIL PROTECTED]> wrote: -snip- > How would you handle a person that scrutinizes blood for a living and > mistakes a diagnosis ? I'm sure it happens multiple times a day, all over the country. I doubt very much they get fired for the first error. -snip- > There > are degrees of error of course some are who cares to a possible > company going bankrupt there are in the last case MANY people being > out of work (possibly 1000's or more) would you not fire the person? If it were their first error, probably not. -snip- > That is why an operator, IMO must go > through several years of training so they CAN'T make stupid mistakes. Ah, you're one of those people that believe humans can be trained into not making mistakes. Dr. Deming would be shaking his head in sadness over that, if he were still alive. It is, at best, a very misguided notion. -snip- > Being an operator is a lot like being an anethesiologist the skill to > know how much sleeping gas to administer so the patient does not > awake or die. The surgeon is one part (major) of the operation an > operator is a helper. That is what an operator is a helper. I guess you've never heard of death by "medical misadventure." That also happens nearly every day. Not too many of them get fired either, for their first mistake. Mark Post -- 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
Re: VARY too many devices offline
On Oct 22, 2007, at 5:41 PM, Kenny Fogarty wrote: It’s the concept of "one strike, you're out!" that I find amazing. What constitutes a mistake serious enough to put someone's livelihood at stake? With that kind of pressure hanging over anyone, how can they be expected to learn, and grow and enhance the company they're working for? Kevin: How would you handle a person that scrutinizes blood for a living and mistakes a diagnosis ? In some case an operator is just as "guilty" as the blood analyzer. If you say thats not the same, I would agree but not in all circumstances. If an operator put in a wrong date at IPL and (because of that) RACF refuses to come up and there is no backout or even worse datasets gets scratched because of the operator error which leads to a fine from say the SEC (or take you pick of agency). There are degrees of error of course some are who cares to a possible company going bankrupt there are in the last case MANY people being out of work (possibly 1000's or more) would you not fire the person? The gravity of the error is all important, of course. I think we've all seen enough horror stories over the years, where a command, or parameter has been entered in error, but from those horror stories, procedures got tightened, people were educated, things got better. People learn from mistakes, and go on to pass on their findings to their colleagues, to their peers and people act on that, and learn and improve. If you hang a sword of Damocles like that over everyone within an organisation, nothing would get done. Within a programming environment, has anyone ever written a 100% bug-free piece of code, that has lasted for all eternity, never once needing to be optimized or re-compiled or re-linked? Are bugs that are exposed over time by new releases of the operating system, or various subsystems classed as being serious enough to have your job and reputation absolutely caned? I just think it’s a nonsense concept and a nonsense approach. I think you are comparing apples and oranges. An operator can by mistake put the company out of business, a programmer can cause loss revenue and yes possibly a fine . BUT that should have been found in QA before the program goes live. In other words their work is checked by others. An operator does not have this luxury. Yes programmers can make mistakes but (in most cases) its not a shut the front doors and turn off the power whoever is the last one to leave. An operator can do so with a small "oops". That is why an operator, IMO must go through several years of training so they CAN'T make stupid mistakes. Its possible that a programmer could write a program that misdiagnoses a test (health) result and yes that could lead to the persons death, but presumably there are other fingers in the stew to catch the errors. In the case of an operator there is no way to catch all errors that could cause a major issue. Catching a Vary is a small part of any possible error. Catching a bad date at lets say early on in the IPL process is impossible by any of the suggestions mentioned as the exits (programs) are not available then. I would suggest an incorrect VARY command might cause some amount of grief but (probably) not enough get fired over. I know some places have intercepts to catch an incorrect vary command. That is almost as bad (IMO) as saying your fired as you don't trust your operators so I am going to attempt to intercept commands and double check them. There is no guarantee that the devices were not the right devices even with an exit. Being an operator is a lot like being an anethesiologist the skill to know how much sleeping gas to administer so the patient does not awake or die. The surgeon is one part (major) of the operation an operator is a helper. That is what an operator is a helper. Ed -- 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
Re: VARY too many devices offline
It’s the concept of "one strike, you're out!" that I find amazing. What constitutes a mistake serious enough to put someone's livelihood at stake? With that kind of pressure hanging over anyone, how can they be expected to learn, and grow and enhance the company they're working for? I think we've all seen enough horror stories over the years, where a command, or parameter has been entered in error, but from those horror stories, procedures got tightened, people were educated, things got better. People learn from mistakes, and go on to pass on their findings to their colleagues, to their peers and people act on that, and learn and improve. If you hang a sword of Damocles like that over everyone within an organisation, nothing would get done. Within a programming environment, has anyone ever written a 100% bug-free piece of code, that has lasted for all eternity, never once needing to be optimized or re-compiled or re-linked? Are bugs that are exposed over time by new releases of the operating system, or various subsystems classed as being serious enough to have your job and reputation absolutely caned? I just think it’s a nonsense concept and a nonsense approach. "Oh, that's a typo right there, on the console. It's been nice working with you, take some typing lessons next time, and leave your card on the table. Bye!" No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.15.5/1085 - Release Date: 22/10/2007 10:35 -- 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
Re: VARY too many devices offline
Sometimes that's called experience and the more of it one has obtained. The more opportunity one had for making mistakes. Normally you don't make the same mistake more than twice, especially when you have caused major damage. But that's the reason a company prefers someone with experience, so they will not have to pay for mistakes that an unexperienced person would make somewhere down the line. Although many companies are leaning towards trading experience for saving money. If fired for making a mistake. Most likely would result in employees concern with taking educated chances and stump their growing potential. Which is a lose - lose situation for the employee and company. The only constant is change and change constitutes mistakes. I for one, would rather have changes and grow and make some mistakes, then to stay stagnant and safe. Regards, Michael J Flores Triumph Performance and Technical Architecture AMEX Bob Shannon <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 10/22/2007 02:33 PM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject Re: VARY too many devices offline > Operators (especially console operators) are extremely competent and if > they screw up, IMO, they need to be fired. As a systems programmer I'm glad I wasn't fired every time I screwed something up. Bob Shannon Rocket Software -- 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 American Express made the following annotations on Mon Oct 22 2007 15:30:49 -- "This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." American Express a ajouté le commentaire suivant le Mon Oct 22 2007 15:30:49 Ce courrier et toute pièce jointe qu'il contient sont réservés au seul destinataire indiqué et peuvent renfermer des renseignements confidentiels et privilégiés. Si vous n'êtes pas le destinataire prévu, toute divulgation, duplication, utilisation ou distribution du courrier ou de toute pièce jointe est interdite. Si vous avez reçu cette communication par erreur, veuillez nous en aviser par courrier et détruire immédiatement le courrier et les pièces jointes. Merci. ** --- -- 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
Re: VARY too many devices offline
Kenny, I can't tell if you're agreeing with the comment that operators who screw up should be fired or if you're saying that idea/policy is ridiculous. All I can say is that if any/all of us who lurk on this listserv got the axe every time we screwed something up we'd be job hopping quite often. Something about an old saying "let him who is without sin cast the first stone" Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kenny Fogarty Sent: Monday, October 22, 2007 5:09 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: VARY too many devices offline Operators (especially console operators) are extremely competent and if they screw up, IMO, they need to be fired. That's just ridiculous. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.15.5/1085 - Release Date: 22/10/2007 10:35 -- 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
Re: VARY too many devices offline
Operators (especially console operators) are extremely competent and if they screw up, IMO, they need to be fired. That's just ridiculous. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.15.5/1085 - Release Date: 22/10/2007 10:35 -- 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
Re: VARY too many devices offline
> Operators (especially console operators) are extremely competent and if > they screw up, IMO, they need to be fired. As a systems programmer I'm glad I wasn't fired every time I screwed something up. Bob Shannon Rocket Software -- 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
Re: VARY too many devices offline
On Oct 22, 2007, at 3:58 PM, Howard Brazee wrote: On 22 Oct 2007 12:56:30 -0700, [EMAIL PROTECTED] (Jon Brock) wrote: Color me disbelieving. I think in the 30+ years I have been around OS360 and MVS and z/os, there has never been an operator mistake of a typo. I liked the time where the Vax operator put in a date a century in the future. DIR SINCE TOMORROW found the file I created before I called him. or the operator who put a future date at IPL time and really screwed up RACF. (story I heard from another company) Ed -- 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
Re: VARY too many devices offline
This is exactly why there are products like CA OPS/MVS and Automan and probably a few others. People sometimes are new to a procedure, they do accidentally make mistakes, and read and write instructions incorrectly. It is up to the systems management to make sure that proper process is in place to catch and disallow mistakes that will bring the systems down. It is perfectly legitimate to specify procedures that require certain devices to always be online, or online at specific times and dates. It is reasonable that these are documented and embedded into software procedures to ensure that they are adhered to. The operator should not be fired, but given education. The systems management that allowed this to happen are a better candidate for dismissal. On 10/22/07, Howard Brazee <[EMAIL PROTECTED]> wrote: > > On 22 Oct 2007 12:56:30 -0700, [EMAIL PROTECTED] (Jon Brock) wrote: > > >Color me disbelieving. > > > >I think in the 30+ years I have been around OS360 and MVS and z/os, > >there has never been an operator mistake of a typo. > > I liked the time where the Vax operator put in a date a century in the > future. DIR SINCE TOMORROW found the file I created before I called > him. > > -- > 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 > -- 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
Re: VARY too many devices offline
On 22 Oct 2007 12:56:30 -0700, [EMAIL PROTECTED] (Jon Brock) wrote: >Color me disbelieving. > >I think in the 30+ years I have been around OS360 and MVS and z/os, >there has never been an operator mistake of a typo. I liked the time where the Vax operator put in a date a century in the future. DIR SINCE TOMORROW found the file I created before I called him. -- 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
Re: VARY too many devices offline
On Oct 22, 2007, at 2:38 PM, Jon Brock wrote: Color me disbelieving. I think in the 30+ years I have been around OS360 and MVS and z/os, there has never been an operator mistake of a typo. Not buying this, either: I have seen operators make errors but the OS has caught all of them and no harm was done. Jan's take is correct: outlawing mistakes does not mean they won't happen. (They're "mistakes," see.) It also doesn't do much for protecting your system integrity; nor does it signify any sort of effective management. Demanding 100% correctness from your people on pain of termination is not only futile and irrational, it can be counter-productive. I'm not saying that errors should be taken lightly, but expecting that you'll never see someone type "V 110E-1107,OFFLINE" instead of "V 1103-1107,OFFLINE" is not realistic. And simply advocating a sacrificial firing or two doesn't really help. It's awfully easy to be free with someone else's livelihood. Jon, I find operators (in general) are an honest and a good lot. If they do make mistakes they generally step up to the plate and take responsibility. The places I have worked not just anyone can sit at a console, you must earn it. That means going from a print jockey to a tape jockey to a master console jockey. Along the lines if they make mistakes the average to poor ones never get promoted. So a master console type is extremely competent at his/her job. I have yet to see someone at a console that was not competent to do their job. Competent = no mistakes. I tend to judge people (operators) as to their position on the food chain. I have seen shift managers that do not fit into the competency issue, so I treat them *generally* less than console types. The above goes for non military type situations or union situations, that is a whole different ball of wax. Operators (especially console operators) are extremely competent and if they screw up, IMO, they need to be fired. Ed -- 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
Re: VARY too many devices offline
Color me disbelieving. I think in the 30+ years I have been around OS360 and MVS and z/os, there has never been an operator mistake of a typo. Not buying this, either: I have seen operators make errors but the OS has caught all of them and no harm was done. Jan's take is correct: outlawing mistakes does not mean they won't happen. (They're "mistakes," see.) It also doesn't do much for protecting your system integrity; nor does it signify any sort of effective management. Demanding 100% correctness from your people on pain of termination is not only futile and irrational, it can be counter-productive. I'm not saying that errors should be taken lightly, but expecting that you'll never see someone type "V 110E-1107,OFFLINE" instead of "V 1103-1107,OFFLINE" is not realistic. And simply advocating a sacrificial firing or two doesn't really help. It's awfully easy to be free with someone else's livelihood. Jon -- 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
Re: VARY too many devices offline
On Oct 22, 2007, at 7:05 AM, Jan MOEYERSONS wrote: Not being to tongue in cheek here.. but we used to fire the operator. Ed And what good does that do to the integrity of your systems??? Does that prevent anyone else from making a mistake? Did you never make a typo in any of the commands you ever entered? (If you never did, then that means you never entered any...) Jantje There is a difference between typing an email and operator console. If you cannot tell the difference then you shouldn't be an operator. Operators (or sysprog or whomever) that have access to the systems console MUST be aware of the fact and type accordingly. I think in the 30+ years I have been around OS360 and MVS and z/os, there has never been an operator mistake of a typo. If the operator was in doubt he opened the IBM Book. If that didn't answer his (her) question a call to his supervisor or friendly sysprog. There have been times when commands weren't as well documented (or weren't at all) that calls were made and we typed a instruction sheet for the operator(s). Sorry, mistakes on the console (in some cases) could be life threatening and therefore operators did NOT make any errors. Ed PS: I have seen operators make errors but the OS has caught all of them and no harm was done. pps: We had a case where the operator screwed up a IPL in the specify system parameters reply and we had to IPL again. The operator had a book (literally) thrown at him. The VP apologized but told him if he made another mistake he was out of there. He didn't. -- 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
Re: VARY too many devices offline
> >Not being to tongue in cheek here.. but we used to fire the operator. > >Ed > And what good does that do to the integrity of your systems??? Does that prevent anyone else from making a mistake? Did you never make a typo in any of the commands you ever entered? (If you never did, then that means you never entered any...) Jantje. -- 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
Re: VARY too many devices offline
On Oct 19, 2007, at 9:13 AM, Field, Alan C. wrote: Yesterday someone issued an RO *ALL,V 708-7014,OFFLINE which led to a number of unplanned IPLs. Now mgmt wants to implement a fingerchecker. I searched CBT for a command exit that might ask something like "you really want to vary 26,000 devices offline?" How do others shops handle this, have you got an exit you'd be willing to share before we re-invent the wheel. Thanks, Alan Not being to tongue in cheek here.. but we used to fire the operator. Ed -- 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
Re: VARY too many devices offline
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Field, Alan C. > > Yesterday someone issued an RO *ALL,V 708-7014,OFFLINE which > led to a number of unplanned IPLs. > > Now mgmt wants to implement a fingerchecker. > > I searched CBT for a command exit that might ask something > like "you really want to vary 26,000 devices offline?" > > How do others shops handle this, have you got an exit you'd > be willing to share before we re-invent the wheel. We use a "home-grown" exit that examines DISPLAY and VARY commands, requiring device addresses to be entered as 4-digit numbers and limiting ranges to 32 devices, and suppresses the command along with a console message if the operator "muffs" it. I'll seek permission to send you a copy off-list, if you wish. -jc- -- 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
Re: VARY too many devices offline
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Field, Alan C. > Sent: Friday, October 19, 2007 9:14 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: VARY too many devices offline > > Yesterday someone issued an RO *ALL,V 708-7014,OFFLINE which led to a > number of unplanned IPLs. > > Now mgmt wants to implement a fingerchecker. > > I searched CBT for a command exit that might ask something like "you > really want to vary 26,000 devices offline?" > > How do others shops handle this, have you got an exit you'd be willing > to share before we re-invent the wheel. > > Thanks, > > Alan We use CA-OPS/MVS to validate the range on all VARY commands. Do you have an automated operations package which can intercept operator commands? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
VARY too many devices offline
Yesterday someone issued an RO *ALL,V 708-7014,OFFLINE which led to a number of unplanned IPLs. Now mgmt wants to implement a fingerchecker. I searched CBT for a command exit that might ask something like "you really want to vary 26,000 devices offline?" How do others shops handle this, have you got an exit you'd be willing to share before we re-invent the wheel. Thanks, Alan -- 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
