Larry, If email sent from the mainframe is not time-critical (i.e., users don't expect to receive their email within a couple of minutes from the time the mainframe job created it), then you don't have to do anything. However, ... At my last shop, the mainframe was used to send email for just about everything: Job completion / abend notification (time-critical, high priority emails). Production report or data file distribution to individuals or small groups of people. Mass emails (emails generated with customized info to hundreds of individuals, not time critical)
When I joined up, the shop's biggest problem were those mass emails, as they all arrived at the SMTP server in one huge spool file. As I pointed out in other postings, while the SMTP server "digests" a large spool file and stores it on disk into 2 datasets per message (addressbook dataset and message contents dataset), it doesn't do anything else until end-of-file. For a spool file with, let's say, 3000 mail messages, this took up to 8 hours on our machine. Meanwhile, everything else was stuck behind this monster file. Nothing got sent, nothing got received and everything appeared to be stuck. I received numerous complaints from users about lousy email turnaround times. And even the operators more often than not thought that the SMTP server was "hung" and cancelled it. Well, that didn't help at all, because then it took SMTP forever to resume where it left off. After discussing this problem with IBM SMTP support (where they told me how SMTP "single-mindedly" goes about its business, doing one task at a time, in a round-robin fashion) and after doing some research on our in-house email procedures, I solved the problem by writing a little REXX Exec as a transparent back-end step to the mass - email generation PROC. The mass-email file was not written directly to spool, my REXX Exec broke it up and generated one spool file per email. That allowed the SMTP server to go about its business and quickly do its round-robin process of receive an email from spool and store it on disk, send a stored email, listen on TCPIP and receive mail from the network, and so on. In other words, while there were still numerous emails waiting to be read from spool, stored emails could be sent out with only a brief delay. OK, now you may say: "Some job just queued up 3000 mass emails. My important job abend notification is queued up as file #3001 behind all the mass mail. It's still going to sit in queue forever! Aaaahhhh!!!" And you were right. Initially my REXX Exec didn't take that into account. Having individual spool files, one per mail message, made SMTP perform much better. But while mass emails were being processed, others still suffered unacceptable, albeit shorter delays. JES2 output queue priorities to the rescue! It took a little fiddling with JES2 default queue priority and priority-aging setup values and a change to my REXX Exec to get it right. >From then on, mass emails were spooled at a lower-than-default queue priority. That means, all other email messages always went to the head of the line and processed through SMTP without having to wait behind _all_ the mass emails. "So what," you might say. "It still took you 8 hours to get the last of those 3000 mass emails out the door." Yes, you're right. But in those 8 hours, SMTP got those 3000 mails read in _and_ sent out the door. In these same 8 hours SMTP also processed hundreds of other emails in every which direction, in and out of the mainframe, with only a few minutes turnaround time. Nothing got stuck, nothing important got delayed and the users were happy. Had these 3000 emails been delivered in one huge spool file, it would have taken 8 hours to read the file, another 4 hours to send them all and then a few more hours to catch up on the backlog. The long and the short of this story is: The mainframe SMTP server can handle multiple email messages in one spool file. But if mail turnaround time is important to your shop, use only 1 mail message per spool file. You need to keep the SMTP server task turn mail messages around and not let it get bogged down doing one thing, while other activities pile up. If you have mail messages that are deemed more important than other traffic, use spool queue priorities. Regards, Ulrich Krueger -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gray, Larry - Larry A Sent: Friday, November 30, 2007 10:17 To: [email protected] Subject: Re: Send email from MVS cobol We only send email from our mainframe. We do not receive. Also, only batch jobs use the SMTP process, so it does not hurt in our instance. I wrote the program (written in COBOL) we use to format the emails. When I first wrote it, it was only called from JCL for a single email, so I required people to code the DD statement. Somewhere along the way, someone found out it could be called from a COBOL program. Then someone wanted to send multiple emails per step. All of this happened without the program being changed. It's a little late now to make that change. Larry Gray ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
