Re: SyzMAIL/z new features
In 0765937696197027.wa.brianwestermansyzygyinc@listserv.ua.edu, on 12/01/2014 at 01:25 AM, Brian Westerman brian_wester...@syzygyinc.com said: I wondered how you might look at this request? Sending related SYSOUT seems reasonable, even if it takes a little more work, but sending arbitrary legacy or Unix files seems excessive. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SyzMAIL/z new features
I want to thank all of you who responded to me on the list and via private email. I compiled the suggestions and we had a strategy meeting today to discuss it. The results were that we will provide any one (or all) of the JES system datasets, or the entire job, but not specific user SYSOUT datasets within the job. Sending the individual USER sysout, MVS datasets (sequential, PDS, VSAM, etc.) and Unix files will instead be added as a feature of SyzCMD/z (the command scripting product). Again, I really do want to thank those of you who responded for the assistance, I actually used a lot of what was said verbatim, because it was describe much more eloquently than I could have. Thanks, Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SyzMAIL/z new features
That's my point, SyzSPOOL/z already does just that, and to add the capability to SyzMPF/z would place it in competition with our own product. Besides, getting the STEP and MAX condition codes with the runtime details is useful, but to send the entire job just because we can seems to be overkill. Especially in an Abend situation, who really wants 100,000+ lines of SYSABEND information when all they really want is to know that it abended and what the codes were. I can see sending the message log, or JCL log, but the entire job (which would be much easier than trying to separate the individual SYSOUTs) would really just tie up the email pipeline. Do you agree? Thanks for the info though, it is indeed far easier to send the whole job than to pick out individual sysouts. Brian On Mon, 1 Dec 2014 01:39:24 -0600, Mike Schwab mike.a.sch...@gmail.com wrote: I would say if they want more than the three system files you just send them the whole job. On Mon, Dec 1, 2014 at 1:25 AM, Brian Westerman brian_wester...@syzygyinc.com wrote: Hi, We had several user requests (at least 200) for the automatic StepCC/MaxCC eMail/SMS text product to allow the JES system datasets to be attached to the email, so that besides the stepCC's and MaxCC, the user can receive any or all of the JESJCL, JESMSGLG, and JESYSLG as attachments. I added that code and also added the ability to send JESJCLIN (the input JCL) even though I can't see a reason why anyone would normally want/need it. As a result of that extra little bit of coding, we had a meeting here and I was asked to (also) add the ability to send regular SYSOUT and even non-related files (sequential, PDS, VSAM, etc.) in the next release. I fought it as being absurd and beyond the scope of the product. Sending the JES system datasets was fairly simple because they have (sort of) static names, but the actual SYSOUT requires a bit more programming to derive and send, not to mention the effort required on the client's part to tell us (definitively) what they want sent in the way of other data. They (our client support) sent a query out to our client base and got back several hundred replies of Sure, and sounds good, but no one really had a good reason to get the SYSOUT or other datasets automatically that would make sense with respect to the programming effort. We already Send any datasets they want via email from our SyzSPOOL/z product (the spool manager) and it makes sense to do it there because we have much more control over what we are looking at on a job by job basis, and we can send it in usable formats (like PDF, Word, wtc.) but for the End-of-task MaxCC stuff, we really don't know (or care) about what SYSOUT might actually be there, and we sure can't be formatting SYSOUT on the fly. I'm okay with sending the JES system data, because the console messages and JCL resolution, etc. makes sense with respect to keeping track of what happened and maybe why a task got the condition codes it did, especially with an ABEND, but turning the product into a spool delivery product when we already have one seems to be counter-productive. I'm ready to stand firm on this, but over the holiday I have been thinking that I could be just being stubborn (or lazy) for no good reason, and as I respect what you guys think I wondered how you might look at this request? Brian Westerman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SyzMAIL/z new features
Hi, We had several user requests (at least 200) for the automatic StepCC/MaxCC eMail/SMS text product to allow the JES system datasets to be attached to the email, so that besides the stepCC's and MaxCC, the user can receive any or all of the JESJCL, JESMSGLG, and JESYSLG as attachments. I added that code and also added the ability to send JESJCLIN (the input JCL) even though I can't see a reason why anyone would normally want/need it. As a result of that extra little bit of coding, we had a meeting here and I was asked to (also) add the ability to send regular SYSOUT and even non-related files (sequential, PDS, VSAM, etc.) in the next release. I fought it as being absurd and beyond the scope of the product. Sending the JES system datasets was fairly simple because they have (sort of) static names, but the actual SYSOUT requires a bit more programming to derive and send, not to mention the effort required on the client's part to tell us (definitively) what they want sent in the way of other data. They (our client support) sent a query out to our client base and got back several hundred replies of Sure, and sounds good, but no one really had a good reason to get the SYSOUT or other datasets automatically that would make sense with respect to the programming effort. We already Send any datasets they want via email from our SyzSPOOL/z product (the spool manager) and it makes sense to do it there because we have much more control over what we are looking at on a job by job basis, and we can send it in usable formats (like PDF, Word, wtc.) but for the End-of-task MaxCC stuff, we really don't know (or care) about what SYSOUT might actually be there, and we sure can't be formatting SYSOUT on the fly. I'm okay with sending the JES system data, because the console messages and JCL resolution, etc. makes sense with respect to keeping track of what happened and maybe why a task got the condition codes it did, especially with an ABEND, but turning the product into a spool delivery product when we already have one seems to be counter-productive. I'm ready to stand firm on this, but over the holiday I have been thinking that I could be just being stubborn (or lazy) for no good reason, and as I respect what you guys think I wondered how you might look at this request? Brian Westerman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SyzMAIL/z new features
I would say if they want more than the three system files you just send them the whole job. On Mon, Dec 1, 2014 at 1:25 AM, Brian Westerman brian_wester...@syzygyinc.com wrote: Hi, We had several user requests (at least 200) for the automatic StepCC/MaxCC eMail/SMS text product to allow the JES system datasets to be attached to the email, so that besides the stepCC's and MaxCC, the user can receive any or all of the JESJCL, JESMSGLG, and JESYSLG as attachments. I added that code and also added the ability to send JESJCLIN (the input JCL) even though I can't see a reason why anyone would normally want/need it. As a result of that extra little bit of coding, we had a meeting here and I was asked to (also) add the ability to send regular SYSOUT and even non-related files (sequential, PDS, VSAM, etc.) in the next release. I fought it as being absurd and beyond the scope of the product. Sending the JES system datasets was fairly simple because they have (sort of) static names, but the actual SYSOUT requires a bit more programming to derive and send, not to mention the effort required on the client's part to tell us (definitively) what they want sent in the way of other data. They (our client support) sent a query out to our client base and got back several hundred replies of Sure, and sounds good, but no one really had a good reason to get the SYSOUT or other datasets automatically that would make sense with respect to the programming effort. We already Send any datasets they want via email from our SyzSPOOL/z product (the spool manager) and it makes sense to do it there because we have much more control over what we are looking at on a job by job basis, and we can send it in usable formats (like PDF, Word, wtc.) but for the End-of-task MaxCC stuff, we really don't know (or care) about what SYSOUT might actually be there, and we sure can't be formatting SYSOUT on the fly. I'm okay with sending the JES system data, because the console messages and JCL resolution, etc. makes sense with respect to keeping track of what happened and maybe why a task got the condition codes it did, especially with an ABEND, but turning the product into a spool delivery product when we already have one seems to be counter-productive. I'm ready to stand firm on this, but over the holiday I have been thinking that I could be just being stubborn (or lazy) for no good reason, and as I respect what you guys think I wondered how you might look at this request? Brian Westerman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
