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
