Thanks for the feedback. Once again, I am solving a "problem" that doesn't really exist other than in my own mind.
-- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-691-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Brian Westerman > Sent: Tuesday, October 26, 2010 1:23 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Design question for a UNIX facility similar to > TSO SEND command > > Sorry John, > > I didn't see you original request. We ran into the same type > of issues when > deveoping SyzMAIL that send the job end condition codes (max > and/or all of > them , plus statistics from all of the steps) to the notify > "UserID". We > wanted to expand that function to provide more than just the "highest > condition code" and get it to other subsystems (CICS, IMS, Etc.) and > platforms and we ended up, after a lot of testing and > customer feedback, > picking standard EMAIL as the delivery method, mostly because of the > perceived nuisance factor that the people who didn't already > get any form of > the notify message, didn't want to get it if it had to be > like the TSO one > and be received "uncontrolled". > > We looked into sending to the -nix users directly since we > can build the > table any way we wanted, but we found that they also were not > interested in > getting the same type of interruption that TSO users have > lived with for a > long long time. In fact, we have found since the introduction, that a > feature which we thought would probably never be used, the ability to > redirect and NOT send the notification directly to the TSO > UserID is one of > the big selling points of the software. It allows the user > (or site) to > choose to only send the email and redirect the TSO send to > either a log file > or kill it completely. > > Once you provide the ability to send the message(s) to a > group of interested > parties, and/or a catch-all email entity that gathers the > step and ending > condition codes for every job the ends like SyzMAIL does, the > whole reason > for the interruption caused by the send goes away. > > Basically it turns out that apparently given the choice, the > TSO user would > rather not get the interruption caused by the message either. > I can't tell > you how many times I have received one myself and hit enter > automatically > before I realized what the message said. For us it's fairly > easy to go look > at syslog and see it again, or look at the job, but I had > never considered > how difficult that function was for a average user until we > started to get > the notes from users who were actually thanking us for the > product. That > was a real strange happening, normally our client support > expects problem > reports, which thankfully are VERY infrequent, and the > positive comments > coming in randomly were completely unexpected. > > Brian > > ---------------------------------------------------------------------- > 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
