As yet another suggestion, if you have CICS Transaction Server Version 4.2 or later (in at least one region/LPAR) then CICS SupportPac CA1Y is available:
http://www.ibm.com/support/docview.wss?uid=swg24033197 This SupportPac includes both sending (SMTP) and receiving (IMAP and POP3) functions using JavaMail. The receiving functions are not tested in this specific CA1Y implementation, but JavaMail is well tested code. The receiving functions would allow your mainframe to monitor one or more e-mail inboxes for error messages, "unsubscribe" requests, etc. You can use practically any programming language you wish to access these functions, and you can also access these CICS-hosted CA1Y functions from external batch programs through normal CICS batch interfaces. You can even format and send rich e-mail content, including (for example) password-protected PDF file attachments. Please note that CICS SupportPacs are provided "as-is." Regardless of what implementation approach you take, I recommend at least encrypting the network connection(s) when sending/receiving e-mail, at least with server certificate authentication. I also recommend configuring any such connections so that, if adequate (or better) encryption cannot be negotiated, the connection will drop with a return error that surfaces and prompts corrective operator action. You also might want to think about how to assure that the recipient (machine or human) of these e-mails determines that they are genuine...and not from somebody else's "mainframe" promising a share of a faraway prince's oil wealth. :-) Most if not all e-mail security considerations apply to every platform, so if you've got some smart security people in your wider organization then it'd probably be a good idea to tap them. (N.B. "Smart security people" doesn't mean people who *always* say "no.") Note that e-mail is *always* asynchronous, even if you get return codes indicating the message was sent to the SMTP server (only the next hop in what could be a long e-mail transmission chain). You presumably have no control over whether and when the recipient reads your e-mails, much less what the recipient does. My observation is that e-mail tends to be overused in business workflows, much like FTP is overused. Think of these protocols as the batch-oriented protocols they are. If the business process really ought not be batch-oriented, then e-mail (and FTP) probably aren't the right protocols to choose. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA 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
