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

Reply via email to