On Wed, Oct 18, 2017 at 6:39 PM, Jesse 1 Robinson <[email protected]> wrote:
> The dedicated console jockey is indeed a relic of the past. We depend on > alerts that responsible vendors issue in advance of key expiration. One > month should be sufficient for most products, but some customers may need > longer. Our ISVs are universally responsive to our reaching out for short > term extensions in cases where renewals get stalled in the finance > gauntlet. Our automation products are set up to detect alerts and notify > relevant people in one way or another. Customer choice. > > One important proviso. A product must begin issuing alerts while it's > running normally. That is, it's wholly insufficient to issue alerts only on > a restart. That's less a problem now than it once was when vendors seemed > to expect frequent IPLs. It's also helpful to keep a product running for a > limited period in noisy 'panic mode' after official expiration. In many > shops, the teckies have no power to issue POs but must deal the > consequences of corporate sluggishness. > Very good point! I'm not a vendor nor have I played one on TV. I don't know most shops. But I'd bet that a large majority of them have some way to send email from z/OS to "somewhere". So, as part of the installation and in the license for the product, require that a valid, authoritative email address be placed in the configuration information for the software. Assuming a yearly billing, have the product start sending notification notices to that email address some time in advance (say 30 days?). It might even be nice to have an "escalation" scheme. I.e. at expire minus 30 days, send a weekly email to "level 1" (grunt) email. At expire minus 14 days, send an email on MWF to "level 2" (grunt's manager) email. At expire minus 7 days, send a daily email to "level 3" (CIO?). If the product is sufficiently advanced, have it monitor how it is use and customize the CIO email with a subtle threat, such as "Product abc will expire on dd MMM yyyy. Your company runs this product 20 times a day. The product does ... " The "runs this product 20 times a day" is what is changed to emphasize how often it is used. Of course, if it is not used often, just omit that particular information. The above is label HBI#1 (Hare Brained Idea #1). Stay tuned for more episode in the HBI saga. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > [email protected] > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Lester, Bob > Sent: Wednesday, October 18, 2017 4:09 PM > To: [email protected] > Subject: (External):Re: Potential stupid question - MSUs > > Hi All, > > IMHO, console messages should be sufficient. Compuware, for example, > makes them hard to miss! > > OTOH, the above depends on someone/something actually monitoring the > console. That’s something that seems to be going away, and I think that's > just plain wrong. > > Thanks! > BobL > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Charles Mills > Sent: Wednesday, October 18, 2017 5:02 PM > To: [email protected] > Subject: Re: Potential stupid question - MSUs [ EXTERNAL ] > > What should a vendor product do when it expires or whatever? That's a > serious question. I'm a vendor product architect. We need the revenue -- > those pesky programmer salaries and all that. We don't have the resources > to audit every customer. Customers tend not to return vendor phone calls > and e-mails unless the customer wants something from the vendor -- that is, > assuming you can find a relevant contact at the customer. Not blaming the > customers or anything -- just looking for guidance from a customer. What > should the product do if not shut down. (It's already been squawking on the > console for 30 days, but no one reads that, of course.) > > Charles > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Jesse 1 Robinson > Sent: Wednesday, October 18, 2017 3:36 PM > To: [email protected] > Subject: Re: Potential stupid question - MSUs > > 'Dead wrong' seems a bit harsh. How about 'wounded wrong'? My claim that > companies don't set out to cheat vendors is naïve because I never > experienced it. Touche. But I did not waffle on the long-term consequences > of T&C violation even if inadvertent. You eventually have to pay regardless. > > I stand by my example of PSF excession. How would it have been if our > printers had stopped working in the middle of a 100K bill run at oh dark > thirty on a Tuesday morning? What would that have done to our customer > relationship with IBM? Yet we have had major business disruptions involving > *other* vendors who see fit to shut down their products until someone > negotiates a new contract. A lousy way to do business. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > [email protected] > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Ed Jaffe > Sent: Wednesday, October 18, 2017 11:18 AM > To: [email protected] > Subject: (External):Re: Potential stupid question - MSUs > > On 10/18/2017 10:42 AM, Charles Mills wrote: > > And yes, with the complexity of modern 'plexes and licenses, we have at > my current employer had customer, ahem, misunderstandings. > > And those "misunderstandings" have a mixed-bag of outcomes. Some customers > understand the concept of fair play, but in many cases the biggest lawyers > win. > > If, as Skip's company did (BTW, Skip is DEAD WRONG on this issue), you > "accidentally" use unlicensed IBM software, you will pay -- no question > about it because IBM's lawyers are as big or bigger than yours are *AND* > they own the operating system on which your business depends. But, when the > customer's lawyer is bigger than the ISV's lawyer, some have a tendency to > say, "Hey, Man. It was an accident and it won't happen again. It's really > your fault that your software doesn't enforce the contract T&Cs properly. > BTW, could you now spend money on a project to build protections into your > software to help us police this?" > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > age: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- I just child proofed my house. But the kids still manage to get in. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
