Re: report splitting

[Wayne Bickerdike]

Isn't this an OS390 O/S?, if so, I'm not sure what SDSF REXX interfaces are
supported.

I have developed some SDSF REXX code (sorry Ed Jaffe ). It does
exactly what Tony is looking for.

We have some Windows apps that talk back to Tivoli Workload Scheduler and
all the output ends up in a Tivoli bucket started task with the output in a
JES2 writer. The problem we had was linking some Windows task with the
originating z/OS batch job.

This is how we dealt with it:
We read the Tivoli STC output and parse the writer output.
This contains the original z/OS job name and any return code and failure
information.
We scrape this output and create a new job name that matches the
originating job.
The new output is printed using IEBGENER.
We purge the writer output from the STC, so it won't be seen again.
The job is picked up by our output manager (OMCS) and archived.

It's clunky but it gives the end user the ability to look at the job with
its original name.







On Sat, Aug 29, 2020 at 11:29 AM Steve Smith  wrote:

> I suggest the original output be directed to a regular file, which would
> make reading it for the split much simpler.  If that's not an allowed
> change, oh well (or ow, hell?).
>
> I think I might suggest to the client that I could replace the existing
> vendor product for say, 50% of the cost.  That should give you the
> motivation to find the time to write it.
>
> sas
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Grant Taylor]

On 8/28/20 5:46 PM, Seymour J Metz wrote:

A DSN *is* a standard bounce.


Yes.  But not all bounces are DSNs.



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Grant Taylor]

On 8/28/20 5:44 PM, Seymour J Metz wrote:
Doing a direct to MX session will let you see rejection messages, 
but your firewall may not allow that and even if it does you could 
get a subsequesen DSN.


If you are the sending system, you would be the one to generate said 
DSN.  So ... why would you generate a DSN when you already know that the 
recipient is not valid.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: report splitting

[Steve Smith]

I suggest the original output be directed to a regular file, which would
make reading it for the split much simpler.  If that's not an allowed
change, oh well (or ow, hell?).

I think I might suggest to the client that I could replace the existing
vendor product for say, 50% of the cost.  That should give you the
motivation to find the time to write it.

sas

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: report splitting

[Ed Jaffe]

On 8/28/2020 4:37 PM, Gibney, Dave wrote:

How about with APIs available with E(JES)  :)  ?



Haha! Thanks Dave for pointing out (E)JES' API can be called from HLASM, 
COBOL, C/C++ and similar machine-speed languages (as well as REXX and 
Java). SDSF's is REXX and Java only.


In this case, I might suggest using any of SSI 80, SDSF, (E)JES, perhaps 
even IOF or others, to dynamically allocate the sysout needing to be 
split to an input DD of your choice (e.g., for SPOOL BROWSE).


Then dynamically allocate an output DD to sysout using TSO/E ALLOC or 
whatever.


Then, in a real, machine-speed program (not a REXX)...

1. OPEN both DDs, loop and copy records input -> output until the split
   separator is reached.
2. Once reached, CLOSE, re-allocate, and re-OPEN the output DD. Loop
   back to #1 above and continue as before until the next separator or
   EOF is reached.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Seymour J Metz]

I agree that a mail to SPOOL gateway would be nice and an RFE would be 
appropriate. I'm not sure that I would call dropping the facility a glaring 
deficiency, but it is certainly unfortunate.

I assume that IBM simply wants people to use an e-mail client off of the 
mainframe.

No, adding errors-to doesn't change anything; you still need an external mail 
application to read the response once SMTP is gone.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Friday, August 28, 2020 9:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On Fri, 28 Aug 2020 13:01:54 +, Seymour J Metz wrote:

>Once CSSMTP has submitted your e-mail, it has no involvement. You should get a 
>DSN if there is a problem, but, unlike SMTP, CSSMTP does not handle incoming 
>mail.

The inability to handle Delivery Status Notifications is a glaring
deficiency of CSSMTP, worthy of an RFE to repair this regression.

Might this be partly mitigated by supplying an "Errors-to:" header?

Was security a motivator for ending support of incoming mail,
possibly because DSNs often reproduce the entire, possibly
sensitive, email bodies?

-- gil

--
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

Re: Sending email from the Mainframe

[Seymour J Metz]

Note that silently dropping suspected spam, or silently moving it to a junk 
folder, greatly increases the cost of false positives. A well managed mail 
system sends 55x responses and DSNs for suspected spam. 

Also note that a user may be sorting legitimate mail based on, e.g., source, 
subject,  and that he may not examine all of his inboxes with the same 
frequency.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Joel C. Ewing 
Sent: Friday, August 28, 2020 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

You seem to be asking for an impossibility here because the email
protocol as currently implemented doesn't support this.There is no
way for a sender of email to distinguish between email that is accepted
by its target domain but classed (correctly or incorrectly) as  spam and
thrown into the bit bucket to protect end users and make spammers waste
their transmission resources, and email that is accepted and actually
stored for retrieval by the recipient.  Some servers won't even tell a
sender if the target email account doesn't exist, because that info is
also useful to spammers.   So, "successful" transmission to the target
domain can occur even when there will be no actual delivery to any end
user, and email rejection by the receiving domain is only a subset of
the potential failures.

Even successful receipt and successful storage of an email by the target
domain doesn't mean that the intended recipient will ever login to the
account, retrieve it and actually read it.   In fact, the user's local
email client may even have additional filters that trash some received
email based on his own criteria.  Acceptance by the domain's mail server
doesn't mean the email will ever be "delivered" to the actual end user.

The email protocol does still allow for requesting a return email
receipt when the email is actually opened, but that was one of the first
features grossly abused by spammers wanting to locate actively-used
email accounts; so all reasonable email clients default to suppression
of automatic "receipt" responses.  It would have to be a highly unusual
situation before most informed users would ever allow a receipt to be
returned.

Being able to accurately verify successful delivery of email to an
actual email account would be a tremendous boon to spammers and other
undesirable users of emai, so I wouldn't expect to see this situation
change until much better ways of dealing with that problem exist.

The only way at present to know for certain that email was actually
sent, delivered, and read requires co-operation by the recipient to send
a return email reply that has content that clearly demonstrates it is
not just an automated response to the  received email.  Other than that,
there is always room for some uncertainty that a failure could have
occurred that prevented receipt.
Joel C Ewing

On 8/28/20 6:57 AM, Sasso, Len wrote:
> Does anyone have JCL that sends an email, using CSSMTP, from the Mainframe 
> and if it is unable to be delivered, for any reason, sends an email back to 
> the Sender with a corresponding message?
>
>
> Thank You and Please Be Safe!
>
> Len Sasso
> Systems Administrator Senior
> CSRA, A General Dynamics Information Technology Company
> 327 Columbia TPKE
> Rensselaer, NY 12144
>
> Office Hours: M-F  7 AM - 3:45 PM
> Out-Of-Office: Friday, August 28, 2020  Noon - 3:45 PM
> Phone: (518) 257-4209
> Cell: (518) 894-0879
> Fax: (518) 257-4300
> len.sa...@gdit.com
> URL: www.gdit.com
>
>
>
>
...

--
Joel C. Ewing

--
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

Re: Sending email from the Mainframe

[Seymour J Metz]

A DSN *is* a standard bounce.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu>
Sent: Friday, August 28, 2020 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On 8/28/20 7:36 AM, Paul Gilmartin wrote:
> The inability to handle Delivery Status Notifications is a glaring
> deficiency of CSSMTP, worthy of an RFE to repair this regression.

DSNs / MDNs / other non-standard bounces don't need to come back into
CSSMTP.  The just need to come back into an SMTP server.  It can be any
SMTP server, including the main corporate SMTP server.

It is entirely possible to send messages from CSSMTP and have the
bounces go back to a different server, and then collect bounces or
otherwise process them there.

> Might this be partly mitigated by supplying an "Errors-to:" header?

Unnecessary.

> Was security a motivator for ending support of incoming mail,
> possibly because DSNs often reproduce the entire, possibly
> sensitive, email bodies?

You can influence what is returned by using the optional "RET=HDRS"
parameter to the MAIL FROM statement.  Standards compliant servers
should only return the headers and not the message body.



--
Grant. . . .
unix || die

--
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

Re: Sending email from the Mainframe

[Seymour J Metz]

Only use a web bug if you know that the receiving system won't treat it as spam 
and that the recieving mail client is configured to render HTML.

Doing a direct to MX session will let you see rejection messages, but your 
firewall may not allow that and even if it does you could get a subsequesen DSN.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu>
Sent: Friday, August 28, 2020 12:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

On 8/28/20 7:39 AM, Joel C. Ewing wrote:
> You seem to be asking for an impossibility here because the email
> protocol as currently implemented doesn't support this.

There is a way to have a relatively good indication if a message was
displayed or not.  It relies on HTML and unique per message URLs.  But
even that is not guaranteed.  It's just considerably more likely to
succeed than other methods.

> There is no way for a sender of email to distinguish between email
> that is accepted by its target domain but classed (correctly or
> incorrectly) as  spam and thrown into the bit bucket to protect end
> users and make spammers waste their transmission resources, and email
> that is accepted and actually stored for retrieval by the recipient.

Agreed.  It's very difficult, neigh impossible, to accurately detect
good email addresses.

> Some servers won't even tell a sender if the target email account
> doesn't exist, because that info is also useful to spammers.   So,
> "successful" transmission to the target domain can occur even when
> there will be no actual delivery to any end user, and email rejection
> by the receiving domain is only a subset of the potential failures.

However you can flip the logic on it's head.  You can detect known bad
email addresses and "fail fast".

If your JCL / job is doing it's own SMTP (and not relying on something
else to do it on it's behalf) it can deduce the SMTP rejections and have
a high degree of certainty that the email address has a problem.  This
also means that your JCL / job is not dependent on the DSN because it
has visibility to the SMTP status codes directly.

Remember, the DSN is a way for a sending SMTP server to notify a sender
which is outside of the SMTP exchange that there was a problem during /
inside of the SMTP exchange.

> The email protocol does still allow for requesting a return email
> receipt when the email is actually opened, but that was one of
> the first features grossly abused by spammers wanting to locate
> actively-used email accounts; so all reasonable email clients default
> to suppression of automatic "receipt" responses.

This is actually not part of the SMTP protocol.  Message Disposition
Notifications are a feature implemented by email clients and the senders
desire to receive one is conveyed by a header in the message.  The SMTP
server is oblivious to this.

SMTP is Delivery Status Notification
eMail client is Message Disposition Notification

> It would have to be a highly unusual situation before most informed
> users would ever allow a receipt to be returned.

I have on occasion responded to / allowed an MDN request.  But as a
general rule I have my email client prompt me and I almost always deny
the request.  About the only time I'll allow it is if it's from someone
I know on a topic that I am willing to voluntarily share that information.

> The only way at present to know for certain that email was actually
> sent, delivered, and read requires co-operation by the recipient to
> send a return email reply that has content that clearly demonstrates it
> is not just an automated response to the  received email.  Other than
> that, there is always room for some uncertainty that a failure could
> have occurred that prevented receipt.

There's a reason that Message Disposition Notifications use the term
"disposition".  Meaning that the message was displayed or printed.
There is no way that a computer can guarantee that the message was
actually read.  At least not currently.



--
Grant. . . .
unix || die

--
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

Re: report splitting

[Gibney, Dave]

How about with APIs available with E(JES)  :)  ?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Ed Jaffe
> Sent: Friday, August 28, 2020 4:30 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: report splitting
> 
> On 8/28/2020 3:40 PM, Gibney, Dave wrote:
> > I think I've recently seen SDSFand Rexx examples  here sufficient to make a
> start at this.
> 
> 
> Okay, if they are short reports.
> 
> I would *NOT* process millions or even hundreds of thousands of lines of
> SPOOL data using REXX.
> 
> 
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://urldefense.com/v3/__https://www.phoenixsoftware.com/__;!!JmP
> EgBY0HMszNaDT!8RW9pqhvk9C2XPbzNFyzvD38ee1iTMzRRmQaChJ3RI-
> tv0pwnQ-MUUg6QOgJbA$
> 
> 
> 
> This e-mail message, including any attachments, appended messages and
> the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to
> be
> free of any virus or other defect that might affect any computer system into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
> 
> --
> 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

Re: report splitting

[Ed Jaffe]

On 8/28/2020 3:40 PM, Gibney, Dave wrote:

I think I've recently seen SDSFand Rexx examples  here sufficient to make a 
start at this.



Okay, if they are short reports.

I would *NOT* process millions or even hundreds of thousands of lines of 
SPOOL data using REXX.



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: report splitting

[Gibney, Dave]

I think I've recently seen SDSFand Rexx examples  here sufficient to make a 
start at this.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Tony Thigpen
> Sent: Friday, August 28, 2020 3:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: report splitting
> 
> I need to clarify that we can't touch the programs. All the original
> programmers are gone and with them their knowledge. The one contract
> programmer they have is only allowed to make regulatory changes.
> 
> This has to be done with a process that gets the reports out of the JES2
> queue and puts them back in as separate reports. It just need simple "if
> I see this on a header line, break up the report" logic.
> 
> I have written this for z/VSE before, I guess I just need to allocate
> the time to convert the z/VSE code to z/OS.
> 
> Tony Thigpen
> 
> Mike Schwab wrote on 8/28/20 5:17 PM:
> > https://urldefense.com/v3/__http://www.mabu.org/jcl-
> reference.pdf__;!!JmPEgBY0HMszNaDT!5liv5KBe8CS6-
> gtdU2bN0DxEO_hZAwtFGMCiJaPoAjGSf9-VlAHW08m6V1d6ww$  OS/390
> 2.10 from 2000 reference.
> > Same example is on
> >
> https://urldefense.com/v3/__https://www.ibm.com/support/knowledgece
> nter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieab600/outst.htm__;!!JmPEgBY0H
> MszNaDT!5liv5KBe8CS6-gtdU2bN0DxEO_hZAwtFGMCiJaPoAjGSf9-
> VlAHW08n1GeuG9Q$
> >
> > //OUT1  OUTPUT  DEST=STLNODE.WMSMITH
> > //OUT2  OUTPUT  CONTROL=DOUBLE
> > //DSDD  SYSOUT=C,OUTPUT=(*.OUT1,*.OUT2)
> >
> > So set one to print, and one to hold, then reference both.
> >
> > On Fri, Aug 28, 2020 at 8:21 AM Tony Thigpen  wrote:
> >>
> >> All,
> >>
> >> I have an old OS/390 2.10 system that I need to support for a few more
> >> years until the customer finishes their off-platform migration.
> >>
> >> The current project involves removing costly third-party software that
> >> is providing minimal returns for a large cost. One of those products is
> >> a report archive system, but the only part still being used is the
> >> function of 'report splitting' which just sticks the reports back into
> >> the JES2 queue as separate reports.
> >>
> >> While writing something is fun, I don't really have time to write this
> >> one as there are other things I need to write first.
> >>
> >> I don't see anything on the CBT that addresses this, but there may be a
> >> small item in a larger bundle that I can't identify from the contents of
> >> FILE001. Or, someone may have some basic code they can share so that I
> >> don't have to re-invent the wheel on this one.
> >>
> >>
> >> Tony Thigpen
> >>
> >> --
> >> 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: report splitting

[Tony Thigpen]

I need to clarify that we can't touch the programs. All the original 
programmers are gone and with them their knowledge. The one contract 
programmer they have is only allowed to make regulatory changes.


This has to be done with a process that gets the reports out of the JES2 
queue and puts them back in as separate reports. It just need simple "if 
I see this on a header line, break up the report" logic.


I have written this for z/VSE before, I guess I just need to allocate 
the time to convert the z/VSE code to z/OS.


Tony Thigpen

Mike Schwab wrote on 8/28/20 5:17 PM:

http://www.mabu.org/jcl-reference.pdf OS/390 2.10 from 2000 reference.
Same example is on
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieab600/outst.htm

//OUT1  OUTPUT  DEST=STLNODE.WMSMITH
//OUT2  OUTPUT  CONTROL=DOUBLE
//DSDD  SYSOUT=C,OUTPUT=(*.OUT1,*.OUT2)

So set one to print, and one to hold, then reference both.

On Fri, Aug 28, 2020 at 8:21 AM Tony Thigpen  wrote:


All,

I have an old OS/390 2.10 system that I need to support for a few more
years until the customer finishes their off-platform migration.

The current project involves removing costly third-party software that
is providing minimal returns for a large cost. One of those products is
a report archive system, but the only part still being used is the
function of 'report splitting' which just sticks the reports back into
the JES2 queue as separate reports.

While writing something is fun, I don't really have time to write this
one as there are other things I need to write first.

I don't see anything on the CBT that addresses this, but there may be a
small item in a larger bundle that I can't identify from the contents of
FILE001. Or, someone may have some basic code they can share so that I
don't have to re-invent the wheel on this one.


Tony Thigpen

--
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

Re: Sending email from the Mainframe

[Grant Taylor]

On 8/28/20 11:46 AM, Statler, David wrote:
You may be able to utilize the "Undeliverable" feature in the CSSSMTP 
Config setup. You can specify the action to take (store or delete) 
on a dead letter and a unix directory to store it in.


What does CSSMTP do if I send email from a perfectly valid (corporate) 
email address and it's unable to send my original message to the 
recipient(s) for some reason?


I would expect that CSSMTP would generate a bounce (proper RFC DSN) and 
send it to the my perfectly valid (corporate) email address.


That's what other contemporary MTAs do and what the RFCs indicate should 
be done.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: report splitting

[Mike Schwab]

http://www.mabu.org/jcl-reference.pdf OS/390 2.10 from 2000 reference.
Same example is on
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieab600/outst.htm

//OUT1  OUTPUT  DEST=STLNODE.WMSMITH
//OUT2  OUTPUT  CONTROL=DOUBLE
//DSDD  SYSOUT=C,OUTPUT=(*.OUT1,*.OUT2)

So set one to print, and one to hold, then reference both.

On Fri, Aug 28, 2020 at 8:21 AM Tony Thigpen  wrote:
>
> All,
>
> I have an old OS/390 2.10 system that I need to support for a few more
> years until the customer finishes their off-platform migration.
>
> The current project involves removing costly third-party software that
> is providing minimal returns for a large cost. One of those products is
> a report archive system, but the only part still being used is the
> function of 'report splitting' which just sticks the reports back into
> the JES2 queue as separate reports.
>
> While writing something is fun, I don't really have time to write this
> one as there are other things I need to write first.
>
> I don't see anything on the CBT that addresses this, but there may be a
> small item in a larger bundle that I can't identify from the contents of
> FILE001. Or, someone may have some basic code they can share so that I
> don't have to re-invent the wheel on this one.
>
>
> Tony Thigpen
>
> --
> 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

Re: report splitting

[Matthew Stitt]

Look into file 527 on the CBT tape.  There is a callable sub-program that 
allows a COBOL (or any other language) program to change a f SYSOUT file 
characteristics.  Close the report file in the program, change what you want 
changed, then open the report file.  This creates a separate SYSOUT each time.  
There may be example programs in file 529 to use this sub-progarm.

Matthew

On Fri, 28 Aug 2020 10:46:47 -0700, Ed Jaffe  
wrote:

>On 8/28/2020 6:20 AM, Tony Thigpen wrote:
>>
>> The current project involves removing costly third-party software that
>> is providing minimal returns for a large cost. One of those products
>> is a report archive system, but the only part still being used is the
>> function of 'report splitting' which just sticks the reports back into
>> the JES2 queue as separate reports.
>
>
>Unless you need to split on a "special" boundary, I would just use
>SEGMENT= on the SYSOUT DD statement.
>
>
>--
>Phoenix Software International
>Edward E. Jaffe
>831 Parkview Drive North
>El Segundo, CA 90245
>https://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: report splitting

[Ed Jaffe]

On 8/28/2020 6:20 AM, Tony Thigpen wrote:


The current project involves removing costly third-party software that 
is providing minimal returns for a large cost. One of those products 
is a report archive system, but the only part still being used is the 
function of 'report splitting' which just sticks the reports back into 
the JES2 queue as separate reports.



Unless you need to split on a "special" boundary, I would just use 
SEGMENT= on the SYSOUT DD statement.



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Statler, David]

You may be able to utilize the "Undeliverable" feature in the CSSSMTP Config 
setup. You can specify the action to take (store or delete) on a dead letter 
and a unix directory to store it in.

David

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Sasso, Len
Sent: Friday, August 28, 2020 6:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

Does anyone have JCL that sends an email, using CSSMTP, from the Mainframe and 
if it is unable to be delivered, for any reason, sends an email back to the 
Sender with a corresponding message?


Thank You and Please Be Safe!

Len Sasso
Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144

Office Hours: M-F  7 AM - 3:45 PM
Out-Of-Office: Friday, August 28, 2020  Noon - 3:45 PM
Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
URL: 
https://protect2.fireeye.com/v1/url?k=d6ec75ce-8aadedc4-d6eeb904-0cc47a6d17ce-a101fbc807c29bfb&q=1&e=755c3fc4-a8e5-4af5-b36f-63034689dc4b&u=http%3A%2F%2Fwww.gdit.com%2F





From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Friday, July 24, 2020 5:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Sending email from the Mainframe



 [External: Use caution with links & attachments]

Grant Taylor asks:
>What happens to email if CSSMTP (AT-TLS) is configured to *require* 
>encryption and the receiving system doesn't support encryption?

Fundamentally the same thing(s) that happen when the network connection is down 
or too slow (times out), for whatever reasons. Network encryption is part and 
parcel of the network path. This class of failures must already be catered for. 
In this case, Len Sasso's organization is mandating TLS 1.2+, and I agree with 
Shmuel Metz who wrote:
>If management has decreed that all SMTP traffic be encrypted, then 
>barring a configuration error the relay will accept encrypted traffic.

Moreover, it's entirely possible that your attitude would only increase relay 
administrators' burdens, the people who currently have to manage, support, 
monitor, and audit the e-mail traffic from the one and only system still 
transmitting over an unencrypted connection, a connection modality they'd very 
much like to retire as quickly as possible. You know, that "old, obsolete 
mainframe" that you're actively arguing should actually be as old and obsolete 
as you can possibly force it to be. (TLS is *really* not new.) Or it's entirely 
possible that the relay administrators aren't inclined or equipped to provide 
even mediocre service levels for unencrypted connections, or even that there's 
a lone dedicated relay gathering dust in a wiring closet somewhere to support 
this one unencrypted connection, a relay that nobody left in the organization 
even understands or really knows about, that isn't backed up or DR protected, 
that still runs on a 10 Mbps Ethernet segment that miraculously hasn't been 
disconnected yet. Hence the unencrypted connection is MORE prone to failure, 
not less. All very possible, even predictable and likely. And I haven't even 
gotten to the regulatory issues and penalties.

Conceivably you could also reduce or eliminate your personal security 
authentication failure planning and handling (hopefully automated) 
responsibilities if you effectively disable your SAF security provider, such as 
RACF. Then those few pesky authentication and authorization rejections wouldn't 
occur, and everyone could just go to the pub and stay there (or whatever). 
That's the logical consequence of your argument, isn't it? I don't think you've 
got a strong argument.

Sorry to be blunt here, but I feel compelled to offer my personal view (as 
always). My colleagues (and I mean that word expansively, in and out of
IBM) work really hard to deliver and support truly cutting edge capabilities, 
including downright amazing security capabilities, in/for this unique and 
indispensable platform. And this community, overall, often works really hard to 
put these capabilities into practice, in many cases literally to keep 
civilization functioning. Then there are a few people who manage a few of these 
systems, and...well, let's all strive to do better, OK?

[Why am I expecting a minor Twitter storm now? :-)]

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: IN

Re: report splitting

[Gibney, Dave]

Run the report files through their sort product. Depending on how complicated 
the split criteria is, it might be quite simple to split. 

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Tony Thigpen
> Sent: Friday, August 28, 2020 6:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: report splitting
> 
> All,
> 
> I have an old OS/390 2.10 system that I need to support for a few more
> years until the customer finishes their off-platform migration.
> 
> The current project involves removing costly third-party software that
> is providing minimal returns for a large cost. One of those products is
> a report archive system, but the only part still being used is the
> function of 'report splitting' which just sticks the reports back into
> the JES2 queue as separate reports.
> 
> While writing something is fun, I don't really have time to write this
> one as there are other things I need to write first.
> 
> I don't see anything on the CBT that addresses this, but there may be a
> small item in a larger bundle that I can't identify from the contents of
> FILE001. Or, someone may have some basic code they can share so that I
> don't have to re-invent the wheel on this one.
> 
> 
> Tony Thigpen
> 
> --
> 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

Re: Sending email from the Mainframe

[Grant Taylor]

On 8/28/20 7:39 AM, Joel C. Ewing wrote:
You seem to be asking for an impossibility here because the email 
protocol as currently implemented doesn't support this.


There is a way to have a relatively good indication if a message was 
displayed or not.  It relies on HTML and unique per message URLs.  But 
even that is not guaranteed.  It's just considerably more likely to 
succeed than other methods.


There is no way for a sender of email to distinguish between email 
that is accepted by its target domain but classed (correctly or 
incorrectly) as  spam and thrown into the bit bucket to protect end 
users and make spammers waste their transmission resources, and email 
that is accepted and actually stored for retrieval by the recipient.


Agreed.  It's very difficult, neigh impossible, to accurately detect 
good email addresses.


Some servers won't even tell a sender if the target email account 
doesn't exist, because that info is also useful to spammers.   So, 
"successful" transmission to the target domain can occur even when 
there will be no actual delivery to any end user, and email rejection 
by the receiving domain is only a subset of the potential failures.


However you can flip the logic on it's head.  You can detect known bad 
email addresses and "fail fast".


If your JCL / job is doing it's own SMTP (and not relying on something 
else to do it on it's behalf) it can deduce the SMTP rejections and have 
a high degree of certainty that the email address has a problem.  This 
also means that your JCL / job is not dependent on the DSN because it 
has visibility to the SMTP status codes directly.


Remember, the DSN is a way for a sending SMTP server to notify a sender 
which is outside of the SMTP exchange that there was a problem during / 
inside of the SMTP exchange.


The email protocol does still allow for requesting a return email 
receipt when the email is actually opened, but that was one of 
the first features grossly abused by spammers wanting to locate 
actively-used email accounts; so all reasonable email clients default 
to suppression of automatic "receipt" responses.


This is actually not part of the SMTP protocol.  Message Disposition 
Notifications are a feature implemented by email clients and the senders 
desire to receive one is conveyed by a header in the message.  The SMTP 
server is oblivious to this.


SMTP is Delivery Status Notification
eMail client is Message Disposition Notification

It would have to be a highly unusual situation before most informed 
users would ever allow a receipt to be returned.


I have on occasion responded to / allowed an MDN request.  But as a 
general rule I have my email client prompt me and I almost always deny 
the request.  About the only time I'll allow it is if it's from someone 
I know on a topic that I am willing to voluntarily share that information.


The only way at present to know for certain that email was actually 
sent, delivered, and read requires co-operation by the recipient to 
send a return email reply that has content that clearly demonstrates it 
is not just an automated response to the  received email.  Other than 
that, there is always room for some uncertainty that a failure could 
have occurred that prevented receipt.


There's a reason that Message Disposition Notifications use the term 
"disposition".  Meaning that the message was displayed or printed. 
There is no way that a computer can guarantee that the message was 
actually read.  At least not currently.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Grant Taylor]

On 8/28/20 7:36 AM, Paul Gilmartin wrote:

The inability to handle Delivery Status Notifications is a glaring
deficiency of CSSMTP, worthy of an RFE to repair this regression.


DSNs / MDNs / other non-standard bounces don't need to come back into 
CSSMTP.  The just need to come back into an SMTP server.  It can be any 
SMTP server, including the main corporate SMTP server.


It is entirely possible to send messages from CSSMTP and have the 
bounces go back to a different server, and then collect bounces or 
otherwise process them there.



Might this be partly mitigated by supplying an "Errors-to:" header?


Unnecessary.


Was security a motivator for ending support of incoming mail,
possibly because DSNs often reproduce the entire, possibly
sensitive, email bodies?


You can influence what is returned by using the optional "RET=HDRS" 
parameter to the MAIL FROM statement.  Standards compliant servers 
should only return the headers and not the message body.




--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Grant Taylor]

On 8/28/20 5:57 AM, Sasso, Len wrote:
Does anyone have JCL that sends an email, using CSSMTP, from the 
Mainframe and if it is unable to be delivered, for any reason, sends 
an email back to the Sender with a corresponding message?


I'm guessing that since CSSMTP is involved, the JCL / job is not 
speaking SMTP to a receiving server.


I'm not aware of any way that a job can know if there was a hard error 
(early rejection) if it's not doing the SMTP itself.  Maybe there is a 
way to ask CSSMTP to try to send the message and return an error to the 
calling job.


But both of these would only reliably detect a hard error (4xy, 5xy) 
from the receiving SMTP server and wouldn't work for anything downstream 
of that.


For anything downstream of that, you will need to rely on (hopefully) 
industry standard / RFC defined DSNs, or worse, home grown bounces.


(More about this in a reply to Paul's comment.)



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Paul Gilmartin]

On Fri, 28 Aug 2020 08:39:33 -0500, Joel C. Ewing wrote:
>
>  It would have to be a highly unusual
>situation before most informed users would ever allow a receipt to be
>returned.
>
... very dangerous - there's tremendous fraud involved.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Joel C. Ewing]

You seem to be asking for an impossibility here because the email
protocol as currently implemented doesn't support this.    There is no
way for a sender of email to distinguish between email that is accepted
by its target domain but classed (correctly or incorrectly) as  spam and
thrown into the bit bucket to protect end users and make spammers waste
their transmission resources, and email that is accepted and actually
stored for retrieval by the recipient.  Some servers won't even tell a
sender if the target email account doesn't exist, because that info is
also useful to spammers.   So, "successful" transmission to the target
domain can occur even when there will be no actual delivery to any end
user, and email rejection by the receiving domain is only a subset of
the potential failures.

Even successful receipt and successful storage of an email by the target
domain doesn't mean that the intended recipient will ever login to the
account, retrieve it and actually read it.   In fact, the user's local
email client may even have additional filters that trash some received
email based on his own criteria.  Acceptance by the domain's mail server
doesn't mean the email will ever be "delivered" to the actual end user.

The email protocol does still allow for requesting a return email
receipt when the email is actually opened, but that was one of the first
features grossly abused by spammers wanting to locate actively-used
email accounts; so all reasonable email clients default to suppression
of automatic "receipt" responses.  It would have to be a highly unusual
situation before most informed users would ever allow a receipt to be
returned.

Being able to accurately verify successful delivery of email to an
actual email account would be a tremendous boon to spammers and other
undesirable users of emai, so I wouldn't expect to see this situation
change until much better ways of dealing with that problem exist.

The only way at present to know for certain that email was actually
sent, delivered, and read requires co-operation by the recipient to send
a return email reply that has content that clearly demonstrates it is
not just an automated response to the  received email.  Other than that,
there is always room for some uncertainty that a failure could have
occurred that prevented receipt.
    Joel C Ewing

On 8/28/20 6:57 AM, Sasso, Len wrote:
> Does anyone have JCL that sends an email, using CSSMTP, from the Mainframe 
> and if it is unable to be delivered, for any reason, sends an email back to 
> the Sender with a corresponding message?
>
>
> Thank You and Please Be Safe!
>
> Len Sasso
> Systems Administrator Senior
> CSRA, A General Dynamics Information Technology Company
> 327 Columbia TPKE
> Rensselaer, NY 12144
>
> Office Hours: M-F  7 AM - 3:45 PM
> Out-Of-Office: Friday, August 28, 2020  Noon - 3:45 PM
> Phone: (518) 257-4209
> Cell: (518) 894-0879
> Fax: (518) 257-4300
> len.sa...@gdit.com
> URL: www.gdit.com
>
>
>
>
...

-- 
Joel C. Ewing

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Paul Gilmartin]

On Fri, 28 Aug 2020 13:01:54 +, Seymour J Metz wrote:

>Once CSSMTP has submitted your e-mail, it has no involvement. You should get a 
>DSN if there is a problem, but, unlike SMTP, CSSMTP does not handle incoming 
>mail.

The inability to handle Delivery Status Notifications is a glaring
deficiency of CSSMTP, worthy of an RFE to repair this regression.

Might this be partly mitigated by supplying an "Errors-to:" header?

Was security a motivator for ending support of incoming mail,
possibly because DSNs often reproduce the entire, possibly
sensitive, email bodies?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: report splitting

[Carmen Vitullo]

the only thing I can think of is RMDS, if its still available, you don't need 
to use the RMDS repository and can be used to split out reports to different 
recipients

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

report splitting

[Tony Thigpen]

All,

I have an old OS/390 2.10 system that I need to support for a few more 
years until the customer finishes their off-platform migration.


The current project involves removing costly third-party software that 
is providing minimal returns for a large cost. One of those products is 
a report archive system, but the only part still being used is the 
function of 'report splitting' which just sticks the reports back into 
the JES2 queue as separate reports.


While writing something is fun, I don't really have time to write this 
one as there are other things I need to write first.


I don't see anything on the CBT that addresses this, but there may be a 
small item in a larger bundle that I can't identify from the contents of 
FILE001. Or, someone may have some basic code they can share so that I 
don't have to re-invent the wheel on this one.



Tony Thigpen

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Carmen Vitullo]

There are products that can do this, JES2MAIL is one we use, z/osmf can be used 
but I have configured z/osmf to use the lan (MS) smtp server and use jes2eds 
notification
//NFY NOTIFY EMAIL='u...@domain.com' after the jobcard. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Sending email from the Mainframe

[Seymour J Metz]

Once CSSMTP has submitted your e-mail, it has no involvement. You should get a 
DSN if there is a problem, but, unlike SMTP, CSSMTP does not handle incoming 
mail.

There is a mechanism for requesting acknowledgement of successful delivery, but 
it is optional and often abused; many sites do not support it.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Sasso, Len 
Sent: Friday, August 28, 2020 7:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sending email from the Mainframe

Does anyone have JCL that sends an email, using CSSMTP, from the Mainframe and 
if it is unable to be delivered, for any reason, sends an email back to the 
Sender with a corresponding message?


Thank You and Please Be Safe!

Len Sasso
Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144

Office Hours: M-F  7 AM - 3:45 PM
Out-Of-Office: Friday, August 28, 2020  Noon - 3:45 PM
Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
URL: www.gdit.com





From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Friday, July 24, 2020 5:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Sending email from the Mainframe



 [External: Use caution with links & attachments]

Grant Taylor asks:
>What happens to email if CSSMTP (AT-TLS) is configured
>to *require* encryption and the receiving system doesn't
>support encryption?

Fundamentally the same thing(s) that happen when the network connection is
down or too slow (times out), for whatever reasons. Network encryption is
part and parcel of the network path. This class of failures must already
be catered for. In this case, Len Sasso's organization is mandating TLS
1.2+, and I agree with Shmuel Metz who wrote:
>If management has decreed that all SMTP traffic be encrypted,
>then barring a configuration error the relay will accept
>encrypted traffic.

Moreover, it's entirely possible that your attitude would only increase
relay administrators' burdens, the people who currently have to manage,
support, monitor, and audit the e-mail traffic from the one and only
system still transmitting over an unencrypted connection, a connection
modality they'd very much like to retire as quickly as possible. You know,
that "old, obsolete mainframe" that you're actively arguing should
actually be as old and obsolete as you can possibly force it to be. (TLS
is *really* not new.) Or it's entirely possible that the relay
administrators aren't inclined or equipped to provide even mediocre
service levels for unencrypted connections, or even that there's a lone
dedicated relay gathering dust in a wiring closet somewhere to support
this one unencrypted connection, a relay that nobody left in the
organization even understands or really knows about, that isn't backed up
or DR protected, that still runs on a 10 Mbps Ethernet segment that
miraculously hasn't been disconnected yet. Hence the unencrypted
connection is MORE prone to failure, not less. All very possible, even
predictable and likely. And I haven't even gotten to the regulatory issues
and penalties.

Conceivably you could also reduce or eliminate your personal security
authentication failure planning and handling (hopefully automated)
responsibilities if you effectively disable your SAF security provider,
such as RACF. Then those few pesky authentication and authorization
rejections wouldn't occur, and everyone could just go to the pub and stay
there (or whatever). That's the logical consequence of your argument,
isn't it? I don't think you've got a strong argument.

Sorry to be blunt here, but I feel compelled to offer my personal view (as
always). My colleagues (and I mean that word expansively, in and out of
IBM) work really hard to deliver and support truly cutting edge
capabilities, including downright amazing security capabilities, in/for
this unique and indispensable platform. And this community, overall, often
works really hard to put these capabilities into practice, in many cases
literally to keep civilization functioning. Then there are a few people
who manage a few of these systems, and...well, let's all strive to do
better, OK?

[Why am I expecting a minor Twitter storm now? :-)]

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
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

Re: Sending email from the Mainframe

[Sasso, Len]

Does anyone have JCL that sends an email, using CSSMTP, from the Mainframe and 
if it is unable to be delivered, for any reason, sends an email back to the 
Sender with a corresponding message?


Thank You and Please Be Safe!

Len Sasso
Systems Administrator Senior
CSRA, A General Dynamics Information Technology Company
327 Columbia TPKE
Rensselaer, NY 12144

Office Hours: M-F  7 AM - 3:45 PM
Out-Of-Office: Friday, August 28, 2020  Noon - 3:45 PM
Phone: (518) 257-4209
Cell: (518) 894-0879
Fax: (518) 257-4300
len.sa...@gdit.com
URL: www.gdit.com





From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Friday, July 24, 2020 5:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Sending email from the Mainframe



 [External: Use caution with links & attachments]

Grant Taylor asks:
>What happens to email if CSSMTP (AT-TLS) is configured
>to *require* encryption and the receiving system doesn't
>support encryption?

Fundamentally the same thing(s) that happen when the network connection is
down or too slow (times out), for whatever reasons. Network encryption is
part and parcel of the network path. This class of failures must already
be catered for. In this case, Len Sasso's organization is mandating TLS
1.2+, and I agree with Shmuel Metz who wrote:
>If management has decreed that all SMTP traffic be encrypted,
>then barring a configuration error the relay will accept
>encrypted traffic.

Moreover, it's entirely possible that your attitude would only increase
relay administrators' burdens, the people who currently have to manage,
support, monitor, and audit the e-mail traffic from the one and only
system still transmitting over an unencrypted connection, a connection
modality they'd very much like to retire as quickly as possible. You know,
that "old, obsolete mainframe" that you're actively arguing should
actually be as old and obsolete as you can possibly force it to be. (TLS
is *really* not new.) Or it's entirely possible that the relay
administrators aren't inclined or equipped to provide even mediocre
service levels for unencrypted connections, or even that there's a lone
dedicated relay gathering dust in a wiring closet somewhere to support
this one unencrypted connection, a relay that nobody left in the
organization even understands or really knows about, that isn't backed up
or DR protected, that still runs on a 10 Mbps Ethernet segment that
miraculously hasn't been disconnected yet. Hence the unencrypted
connection is MORE prone to failure, not less. All very possible, even
predictable and likely. And I haven't even gotten to the regulatory issues
and penalties.

Conceivably you could also reduce or eliminate your personal security
authentication failure planning and handling (hopefully automated)
responsibilities if you effectively disable your SAF security provider,
such as RACF. Then those few pesky authentication and authorization
rejections wouldn't occur, and everyone could just go to the pub and stay
there (or whatever). That's the logical consequence of your argument,
isn't it? I don't think you've got a strong argument.

Sorry to be blunt here, but I feel compelled to offer my personal view (as
always). My colleagues (and I mean that word expansively, in and out of
IBM) work really hard to deliver and support truly cutting edge
capabilities, including downright amazing security capabilities, in/for
this unique and indispensable platform. And this community, overall, often
works really hard to put these capabilities into practice, in many cases
literally to keep civilization functioning. Then there are a few people
who manage a few of these systems, and...well, let's all strive to do
better, OK?

[Why am I expecting a minor Twitter storm now? :-)]

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
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