Re: CA-OPS/MVS to IBM's System Automation?
On Wed, 27 Oct 2010 12:44:49 +0800 Timothy Sipples wrote: :>Binyamin Dissen writes: :>>If ALERTs are issued for normal events, they no longer have value :>>as ALERTs. :>Ah, but who decides whether they're "normal" or not (and then what actions, :>if any, to take)? The person taking the action that would cause the unneeded alert. :>Any even moderately capable console that collects SNMP alerts also has the :>capability to triage and filter them according to evolving rules that :>define "normalcy." But if the alert never gets sent, then that filtering :>decision has already been made -- and *could* be made very badly. I tend to :>prefer reality and transparency. :>As I alluded to, it is possible to initiate additional alerts, such as: :>09:55 Information: Application XYZ123 will have 30 minute planned outage :>starting in 5 minutes. :>10:00 ALERT: Application XYZ123 is now offline. That increases the number of ALERTs, as the one receiving the second message has to pay attention to the first one in order to know that the ALERT is not really an ALERT. Of course, one could downgrade the level of the second message to "information" in this context, but one may as well (from the context of ALERTs) simply not deliver it (or, perhaps, always deliver "XVZ123 is now offline" to those that wish to subscribe to "information" messages. :>There's also the issue of testing at the console (and beyond). If the :>alerts never get sent, how do you know that the real ones work (or even go :>anywhere)? The above example is the equivalent of a fire drill, or alert :>rehearsal. I tend to prefer that. Your opinions and practices may vary. I am not arguing against drills. What I am arguing against is issuing an ALERT when normal operations are taking place. For example, let use say that XYZ123 is always scheduled offline on Sunday. Is there a need for an ALERT when it goes down for Sunday? Or, perhaps, the ALERT should only be delivered when it goes offline outside the schedule? :>And there's yet another reason to avoid obfuscation: to measure SLAs :>accurately. If you're "secretly" downing applications, is that getting :>reflected in Service-Level Agreement measurements? Probably not, and :>perhaps with accurate knowledge you wouldn't be downing applications so :>often (or at all), and/or somebody else could make an informed decision :>whether or not to improve the SLA of particular application functions. Way :>too many IT folks think that SLAs are only about "unplanned" hard-stop :>system-level outages. The end-user perspective is much more about "can I :>get my work done?" and that really is the only correct perspective. "Can I :>get my work done?" is answered by looking at end-to-end service delivery, :>both planned and unplanned outages, missed response time goals (not just :>"down" outages), plus some other factors (e.g. "I can't log in!") Then, again, it is not an ALERT but an information message. Perhaps the person subscribes to all messages on his work computer but only subscribes to ALERTs from his PDA. By sending "XYZ123 is offline" as an ALERT, there will not be the context that XYZ123 was scheduled to be offline. :>Anyway, this discussion borders on the philosophical, but now you know my :>philosophy. :-) -- Binyamin Dissen 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-OPS/MVS to IBM's System Automation?
Binyamin Dissen writes: >If ALERTs are issued for normal events, they no longer have value >as ALERTs. Ah, but who decides whether they're "normal" or not (and then what actions, if any, to take)? Any even moderately capable console that collects SNMP alerts also has the capability to triage and filter them according to evolving rules that define "normalcy." But if the alert never gets sent, then that filtering decision has already been made -- and *could* be made very badly. I tend to prefer reality and transparency. As I alluded to, it is possible to initiate additional alerts, such as: 09:55 Information: Application XYZ123 will have 30 minute planned outage starting in 5 minutes. 10:00 ALERT: Application XYZ123 is now offline. There's also the issue of testing at the console (and beyond). If the alerts never get sent, how do you know that the real ones work (or even go anywhere)? The above example is the equivalent of a fire drill, or alert rehearsal. I tend to prefer that. Your opinions and practices may vary. And there's yet another reason to avoid obfuscation: to measure SLAs accurately. If you're "secretly" downing applications, is that getting reflected in Service-Level Agreement measurements? Probably not, and perhaps with accurate knowledge you wouldn't be downing applications so often (or at all), and/or somebody else could make an informed decision whether or not to improve the SLA of particular application functions. Way too many IT folks think that SLAs are only about "unplanned" hard-stop system-level outages. The end-user perspective is much more about "can I get my work done?" and that really is the only correct perspective. "Can I get my work done?" is answered by looking at end-to-end service delivery, both planned and unplanned outages, missed response time goals (not just "down" outages), plus some other factors (e.g. "I can't log in!") Anyway, this discussion borders on the philosophical, but now you know my philosophy. :-) - - - - - Timothy Sipples Resident Enterprise Architect STG Value Creation & Complex Deals Team IBM Growth Markets (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-OPS/MVS to IBM's System Automation?
On Tue, 26 Oct 2010 13:18:03 +0800 Timothy Sipples wrote: :>Glenn Miller asks: :>>Why send out 'alerts' to the 'world' when :>>we are shutting down a Started Task, say for maintenance. :>I can definitely see both sides to the argument. My view is that alerts :>should reflect reality, and that nobody is omniscient. If system XYZ is :>going down, then the normal "XYZ going down" alert(s) should get sent. If ALERTs are issued for normal events, they no longer have value as ALERTs. :>There's nothing that prevents sending additional alerts, though. :>I also get very nervous when manual steps are required to reenable alerts, :>even leaving aside the potential security issues. To err is human. Agree. -- Binyamin Dissen 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-OPS/MVS to IBM's System Automation?
Glenn Miller asks: >Why send out 'alerts' to the 'world' when >we are shutting down a Started Task, say for maintenance. I can definitely see both sides to the argument. My view is that alerts should reflect reality, and that nobody is omniscient. If system XYZ is going down, then the normal "XYZ going down" alert(s) should get sent. There's nothing that prevents sending additional alerts, though. I also get very nervous when manual steps are required to reenable alerts, even leaving aside the potential security issues. To err is human. - - - - - Timothy Sipples Resident Enterprise Architect STG Value Creation & Complex Deals Team IBM Growth Markets (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-OPS/MVS to IBM's System Automation?
We did that same migration about 5 years ago during the 'transformation' to IBM as part of the outsource to IBM Global Services. One of the key 'facilities/functions' we "lost" was the use of the OPS/MVS "OPSAOF" operator command. The "OPSAOF" command allows a console operator ( or anyone/anything else ) to LIST, ENABLE or DISABLE OPS/MVS Rules. We used "OPSAOF" to disable some OPS/MVS Message rules that would get triggered when any of our very important Started Tasks would get shutdown, like during the shutdown of z/OS prior to an IPL. We were told that SA/390 had no facility like "OPSAOF". For example, at the beginning of our z/OS shutdown process, we had the following commands issued: OPSAOF DISABLE MSG.msgrule1 OPSAOF RESETAUTO MSG.msgrule1 OPSAOF DISABLE MSG.msgrule2 OPSAOF RESETAUTO MSG.msgrule2 . etc etc etc etc ... Disabling these OPS/MVS "MSG Rules" would prevent unnecessary SNMP messages being sent ( by these "MSG Rules" to our CA-Unicenter server. Note that the "RESETAUTO" command will keep the "MSG Rule" disabled when OPS/MVS starts, say during the next IPL/Startup. Then at the end of our z/OS startup process, we had the following commands issued: OPSAOF ENABLE MSG.msgrule1 OPSAOF SETAUTO MSG.msgrule1 OPSAOF ENABLE MSG.msgrule2 OPSAOF SETAUTO MSG.msgrule2 . etc etc etc etc ... We also would disabled an individual "MSG Rule" whenever we needed to shutdown a specific Started Task. Why send out 'alerts' to the 'world' when we are shutting down a Started Task, say for maintenance. HTH Glenn Miller -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SPAM-LOW: Re: CA-OPS/MVS to IBM's System Automation?
The reason to convert would be money. We would be forced to do the conversion in house, or not at all. -- John McKown Maranatha! <>< Sent from my Vibrant Android phone. On Oct 22, 2010 6:24 AM, "Marc Heimlich" wrote: SFI (www.streamfoundry.com) has done 3 TSA migrations in the last six months. We can help. Marc heiml...@streamfoundry.com --Original Message-- From: Andreas Steinberg Sender: IBM-MAIN To: IBM-MAIN ReplyTo: IBM-MAIN Subject: SPAM-LOW: Re: CA-OPS/MVS to IBM's System Automation? Sent: Oct 22, 2010 3:46 AM John, we did it 5 years ago with a lot of help by consultants. Because we dropped NetView off before that, it came back again through the backdoor. And because of the pricing model we were not amused. IMHO many things are easier using OPS, some don't work, so you need to have System Automation if you want to use GDPS for example. On the other hand the IBM software is very huge, for our things to do it is too big, we are using less than 50% of the features. My operators actually are able to handle it, but they don't like it, cause it is too complicated. HTH Andreas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Sent from my Verizon Wireless BlackBerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SPAM-LOW: Re: CA-OPS/MVS to IBM's System Automation?
SFI (www.streamfoundry.com) has done 3 TSA migrations in the last six months. We can help. Marc heiml...@streamfoundry.com --Original Message-- From: Andreas Steinberg Sender: IBM-MAIN To: IBM-MAIN ReplyTo: IBM-MAIN Subject: SPAM-LOW: Re: CA-OPS/MVS to IBM's System Automation? Sent: Oct 22, 2010 3:46 AM John, we did it 5 years ago with a lot of help by consultants. Because we dropped NetView off before that, it came back again through the backdoor. And because of the pricing model we were not amused. IMHO many things are easier using OPS, some don't work, so you need to have System Automation if you want to use GDPS for example. On the other hand the IBM software is very huge, for our things to do it is too big, we are using less than 50% of the features. My operators actually are able to handle it, but they don't like it, cause it is too complicated. HTH Andreas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Sent from my Verizon Wireless BlackBerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA-OPS/MVS to IBM's System Automation?
John, we did it 5 years ago with a lot of help by consultants. Because we dropped NetView off before that, it came back again through the backdoor. And because of the pricing model we were not amused. IMHO many things are easier using OPS, some don't work, so you need to have System Automation if you want to use GDPS for example. On the other hand the IBM software is very huge, for our things to do it is too big, we are using less than 50% of the features. My operators actually are able to handle it, but they don't like it, cause it is too complicated. HTH Andreas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
