Re: Restrict Operator offline command
On Mon, 18 Sep 2006 11:10:54 -0500, Richard Pinion [EMAIL PROTECTED] wrote: Loss of employment might make an impression. Errare humanum est. Sacking the poor guy (for all I know, he may just have a faulty keyboard on which the 1 key is dead) will NOT prevent this type of event from happening again in the future in any way. 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: Restrict Operator offline command
Ted MacNEIL wrote: anyone got any ideas on how to ensure it does not happen again. Public flogging? Execution? Hire new operators? Well, I'd suggest something more humanitarian. ...no, not poison injection g I would ask: WHY the h.ll they do VARY ... OFFLINE ? probably because it is needed (is it ???) Probably it is a part of repetitive procedure, not ad hoc action. Probably the addresses are not changed frequently. SO, let them start IEFBR14 procedure with proper COMMAND statement. // V -,OFFLINE //STEP1 EXEC PGM=IEFBR14 the above is much less error prone. Of course it is not a solution for random requests, but let's be honest: who is the requestor, why the requestor don't do it himself ? My $0.02 -- Radoslaw Skorupka Lodz, Poland -- 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: Restrict Operator offline command
I don't think it's a question of lack of sense of humour, but rather the excessive noise on this list. Seemingly every thread deteriorates into discussions of ancient hardware/software or semantics and grammar or politics or crime. Hit em up side the head with a bat adds little value to the discussion. So somebody tries to steer it back to relevancy and gets chastized for it. Lose-lose all around. Don Imbriale On Tue, 19 Sep 2006 03:46:18 +, Ted MacNEIL [EMAIL PROTECTED] wrote: The OP talked about an easy-to-make finger check. If you're going to take drastic measures to punish such mistakes: Ya'no! Nobody has a sense of humour anymore! -- 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: Restrict Operator offline command
Thanks to all who replied , we look into cmdx. Regards Gerard Ceruti -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Don Imbriale Sent: 19 September 2006 05:15 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Restrict Operator offline command I don't think it's a question of lack of sense of humour, but rather the excessive noise on this list. Seemingly every thread deteriorates into discussions of ancient hardware/software or semantics and grammar or politics or crime. Hit em up side the head with a bat adds little value to the discussion. So somebody tries to steer it back to relevancy and gets chastized for it. Lose-lose all around. Don Imbriale On Tue, 19 Sep 2006 03:46:18 +, Ted MacNEIL [EMAIL PROTECTED] wrote: The OP talked about an easy-to-make finger check. If you're going to take drastic measures to punish such mistakes: Ya'no! Nobody has a sense of humour anymore! -- 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 __ Standard Bank Disclaimer and Confidentiality Note This e-mail, its attachments and any rights attaching hereto are, unless the context clearly indicates otherwise, the property of Standard Bank Group Limited and/or its subsidiaries (the Group). It is confidential, private and intended for the addressee only. Should you not be the addressee and receive this e-mail by mistake, kindly notify the sender, and delete this e-mail, immediately and do not disclose or use same in any manner whatsoever. Views and opinions expressed in this e-mail are those of the sender unless clearly stated as those of the Group. The Group accepts no liability whatsoever for any loss or damages whatsoever and howsoever incurred, or suffered, resulting, or arising, from the use of this email or its attachments. The Group does not warrant the integrity of this e-mail nor that it is free of errors, viruses, interception or interference. Licensed divisions of the Standard Bank Group are authorised financial services providers in terms of the Financial Advisory and Intermediary Services Act, No 37 of 2002 (FAIS). For information about the Standard Bank Group Limited visit our website http://www.standardbank.co.za ___ -- 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: Restrict Operator offline command
I don't think it's a question of lack of sense of humour, but rather the excessive noise on this list. Seemingly every thread deteriorates into discussions of ancient hardware/software or semantics and grammar or politics or crime. Hit em up side the head with a bat adds little value to the discussion. You're right it does. But, I was trying to point out (in a round about way), that sometimes termination of an employee is the only choice. The OP pointed out that it happened more than once. In some cases, once is barely acceptable. But! Twice? NO WAY! When in doubt. PANIC!! -- 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: Restrict Operator offline command
On 19 Sep 2006 13:26:21 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (Ted MacNEIL) wrote: I don't think it's a question of lack of sense of humour, but rather the excessive noise on this list. Seemingly every thread deteriorates into discussions of ancient hardware/software or semantics and grammar or politics or crime. Hit em up side the head with a bat adds little value to the discussion. You're right it does. But, I was trying to point out (in a round about way), that sometimes termination of an employee is the only choice. The OP pointed out that it happened more than once. In some cases, once is barely acceptable. But! Twice? NO WAY! Yes, even good operators can fat-finger a command more than once, given years in which to do it. And, of course, there are enough operators that even if each gets only one bite, it can wreak havoc on SLAs. We implemented the auto-ops rule after *good* operators made the mistake. Yes, you can fire people for two typos. As I said, though, all that will do is make sure that no command is entered without a lng look to make sure it's right. (Or, you'll have so much turnover that you'll never have to worry about what a good operator will do.) How long do you want system start-up and shut-down to take? As shown by some of the responses, this problem is endemic, rather than the fault of individual operators. I did not object to the humor, per se, but to the idea that *any* punishment is correct for this mistake. There are other errors for which I've jokingly commented about the desirability of breaking someone's thumbs. But it was always when people did things when they should have known (or did know) better. Typos do not fall into that category. (Speaking of people who should know better, how about adding a -- line to separate your sig?) -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot 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: Restrict Operator offline command
(Speaking of people who should know better, how about adding a -- line to separate your sig?) There's one there. The problem is that I had to switch away from my BlackBerry ID to a yahoo one for my BlackBerry, under POP3. (RIM is learning customer support from CA MS). So, I have two sig lines to deal with, and each e-mailer fighting it. I didn't realise it was a problem, since I don't read my own posts. When in doubt. PANIC!! -- 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: Restrict Operator offline command
This discussion answer's an age-old question of the universe: Why does VM ( VM/ESA, z/VM, etc. ) restrict the range of the device VARY command? vary offline 2000-2100 17:36:43 HCPCPS6000E The range of device numbers cannot exceed 256. Ready(06000); T=0.01/0.01 17:36:43 vary online 2000-2100 17:36:46 HCPCPS6000E The range of device numbers cannot exceed 256. Ready(06000); T=0.01/0.01 17:36:46 Guess I have an answer. Glenn Miller --- This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. ABN AMRO Bank N.V, which has its seat at Amsterdam, the Netherlands, and is registered in the Commercial Register under number 33002587, including its group companies, shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. --- -- 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: Restrict Operator offline command
Loss of employment might make an impression. -- 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: Restrict Operator offline command
On Mon, 18 Sep 2006 17:57:27 +0200, Ceruti, Gerard G [EMAIL PROTECTED] wrote: Hi All For the second time we have had an operator issue a vary command from the master console that spanned nearly all our hardware devices, of course to all systems in the sysplex, the command v f00-f002,offline resulted in us having to ipl all the systems to recover. z/OS 1.7 changes the way VARY processing is done. That may provide the relief you are after. It runs much faster. There have been presentations at recent SHAREs about it. Tom Marchant -- 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: Restrict Operator offline command
On Mon, 18 Sep 2006 17:57:27 +0200, Ceruti, Gerard G [EMAIL PROTECTED] wrote: Hi All For the second time we have had an operator issue a vary command from the master console that spanned nearly all our hardware devices, of course to all systems in the sysplex, the command v f00-f002,offline resulted in us having to ipl all the systems to recover. Has anyone perhaps had a similar problem and what solution was used to stop is happening again ?, also anyone got any ideas on how to ensure it does not happen again. Our current thinking is around an assembler exit to trap all vary commands, but trying to avoid that solution . We are a Top Secret shop. Regards Gerard Ceruti Some have done it with MPF or generalized console exit (IEAVMXIT), some with the commands installation exit, and still others automation. We use automation. I'm sure if you search the archives for VARY OFFLINE you'll find more information. Maybe even some samples on the CBT. Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: Restrict Operator offline command
We use automation to check the range. If it is 'excessive', we require the operators to enter a password. That usually gets their attention enough to actually look at the command they entered and correct it if necessary. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ceruti, Gerard G Sent: Monday, September 18, 2006 11:57 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Restrict Operator offline command Hi All For the second time we have had an operator issue a vary command from the master console that spanned nearly all our hardware devices, of course to all systems in the sysplex, the command v f00-f002,offline resulted in us having to ipl all the systems to recover. Has anyone perhaps had a similar problem and what solution was used to stop is happening again ?, also anyone got any ideas on how to ensure it does not happen again. Our current thinking is around an assembler exit to trap all vary commands, but trying to avoid that solution . We are a Top Secret shop. *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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: Restrict Operator offline command
anyone got any ideas on how to ensure it does not happen again. Public flogging? Execution? Hire new operators? When in doubt. PANIC!! -- 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: Restrict Operator offline command
On Mon, 18 Sep 2006 11:11:25 -0500 Tom Marchant [EMAIL PROTECTED] wrote: :On Mon, 18 Sep 2006 17:57:27 +0200, Ceruti, Gerard G :[EMAIL PROTECTED] wrote: :Hi All :For the second time we have had an operator issue a vary command from :the master console that spanned nearly all our hardware devices, of :course to all systems in the sysplex, the command v f00-f002,offline :resulted in us having to ipl all the systems to recover. :z/OS 1.7 changes the way VARY processing is done. That may provide :the relief you are after. It runs much faster. I am curious how varying the devices offline faster will help, but -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: Restrict Operator offline command
if it's the same operator the second time around: baseball bat appropriately applied may do the trick -- 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: Restrict Operator offline command
if it's the same operator the second time around: baseball bat appropriately applied may do the trick Or, force feed them their fingernails (up to their elbows). R.A. Heinlein (I forget which novel/short story). When in doubt. PANIC!! -- 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: Restrict Operator offline command
For the second time we have had an operator issue a vary command from the master console that spanned nearly all our hardware devices, of course to all systems in the sysplex, the command v f00-f002,offline resulted in us having to ipl all the systems to recover. Has anyone perhaps had a similar problem and what solution was used to stop is happening again ?, also anyone got any ideas on how to ensure it does not happen again. Our current thinking is around an assembler exit to trap all vary commands, but trying to avoid that solution . We are a Top Secret shop. After we went 4 char device addresses we had this happen twice in a few weeks - different operator, different shift. I knocked up a cmdx exit to restrict all vary ranges to 32 (consecutive) devices. The DASD management folks whinge and moan whenever they are moving a lot of devices, but if I'm feeling particularly magnanimous I'll deactivate the exit on the sandpit for them, and they do their work there. Hasn't caused any major ructions, and has saved a couple of incidents I know of. Shane ... (this customer has no automation software deployed) -- 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: Restrict Operator offline command
On 18 Sep 2006 13:11:58 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) Mickey [EMAIL PROTECTED] wrote: Ted MacNEIL wrote: anyone got any ideas on how to ensure it does not happen again. Public flogging? Execution? Hire new operators? I'm still in favor of removing the head and putting on a pike outside the building as a warning to future employees that some actions come with a heavy price. The OP talked about an easy-to-make finger check. If you're going to take drastic measures to punish such mistakes: 1. You're going to run out of operators fairly quickly, or 2. you'll find that it takes at least 5 minutes for any operator to enter any command. Firing operators for blatant, flagrant mistakes can make sense. But *everyone* makes typos. Since we *can* protect ourselves from ourselves, we ought to. We used OPS/MVS. It didn't take long to whip up a rule which limited vary offline to only a few at a time, unless a special keyword was entered. I know: Protection is much less fun than retaliation. In the long run, it's a lot more rewarding. N.B. It doesn't take 4-digit device numbers to cause this kind of problem. It's easy to transpose and type V 230-32F,OFFLINE when that should have been 230-23F. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot 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: Restrict Operator offline command
On Sep 18, 2006, at 4:46 PM, Shane Ginnane wrote: SNIP After we went 4 char device addresses we had this happen twice in a few weeks - different operator, different shift. I knocked up a cmdx exit to restrict all vary ranges to 32 (consecutive) devices. The DASD management folks whinge and moan whenever they are moving a lot of devices, but if I'm feeling particularly magnanimous I'll deactivate the exit on the sandpit for them, and they do their work there. Hasn't caused any major ructions, and has saved a couple of incidents I know of. It seems like we have gone forward and then reverse. 30 years ago there was a restriction as to how many devices and paths (IIRC 16) you could vary on or off at one time. IIRC our IBM SE wrote a STC that (among other things) allowed the operator to vary on(off) 256 devices (paths) on at one time. This was an MP environment, it was a great STC as you could do many other things with an outstanding WTOR (too many to mention here). We also had an major issue with comm task taking a hit once an hour (or so) and he had to intercept (IIRC) the D23. Just with that one STC we saved many an IPL and lots of operator aggravation. Hats off to Jim Garner. Ed Shane ... (this customer has no automation software deployed) -- 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: Restrict Operator offline command
The OP talked about an easy-to-make finger check. If you're going to take drastic measures to punish such mistakes: Ya'no! Nobody has a sense of humour anymore! When in doubt. PANIC!! -- 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: Restrict Operator offline command
On Mon, 18 Sep 2006 17:57:27 +0200, Ceruti, Gerard G [EMAIL PROTECTED] wrote: Hi All For the second time we have had an operator issue a vary command from the master console that spanned nearly all our hardware devices, of course to all systems in the sysplex, the command v f00-f002,offline resulted in us having to ipl all the systems to recover. I would use an automated operations product that would intercept anything from the command line of a console with multi-targets. So a VARY (xxx-xxx),... would get stopped. It might get re-issued for similar devices (e.g., V (800-80F),ONLINE might get re-issued by the automation if this was known to it as a bank of tape drives, or some such). You are not the first to have this happen. And it is why different entities (e.g., banks, utilities, etc.) have such rules. Now how does the Automated Operations software know IT issued the command and not someone else? Because they use subsystem consoles as opposed to real consoles and know their ID, etc. etc. Later, 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
