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 <[email protected]> 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 [email protected] 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 [email protected] with the message: INFO IBM-MAIN
