Vikesh, I think you too have hit on the performance limits of the old SMTP server program. SMTP is a single-task process. It can only do one thing at a time. So, the tasks of - process one SPOOL file - store the email message(s) inside of that SPOOL file on disk and build the distribution list and addressbook files for each message - listen on the network for incoming mail (replies, bounced mail notifications, etc), receive and store those - contact the mail server to send one or more email messages - update addressbook files for each sent message - delete message files from disk when addressbook file says, it's been sent to all recipients are performed round-robin, one after the other. Each of these functions takes time, including some built-in times to wait for things to happen (listen on network, establish session with mail server, file DYNALLOC, etc). As far as I know from previous experience, there's not much you can do to speed things up, except to make sure that SMTP gets all the CPU cycles it wants by running it in the highest possible performance group. This might shave off a second or two per mail message. It also helps SMTP performance, if the mail server you're sending to is not too busy and can respond to SMTP's requests as quickly as possible, perhaps even receiving more than one mail message per connection request.
Luckily for you, each email seems to arrive on SPOOL as one single email message per SPOOL file. You can bunch multiple email messages into one SPOOL file (the program logic allows it), but I strongly advise against ever using this technique. SMTP can do nothing else while processing a SPOOL file into outgoing messages and storing them on disk. A multi-message SPOOL file can take a long time to process and not a single message is sent while that happens. And another few words of warning: Do NOT ever cancel SMTP while you have a large backlog of emails stored on disk, waiting to be sent. Upon restart, SMTP first has to process all the addressbook files, one at a time, to reestablish the "to-do-list" and that will take a long time, too, before SMTP resumes its "normal" round-robin processing. Also ensure, that you do not run out of disk space, including VTOC space on the disk(s) where your HLQ.TCPMAIL.** files are stored ... this causes nasty failures in SMTP. Running DFHSM or DFDSS disk backups on those disks may also lead to failures, if SMTP tries to DYNALLOC a dataset and gets an enqueue conflict. Beware!! There's just one thing I can say: Hang tough. And also take a look at the z/OS 1.11 announcement letter. There's mention of a redesigned SMTP server that's supposed to perform better. There may be light at the end of the tunnel ... Regards, Ulrich Krueger -----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Vikesh Bhoola Sent: Wednesday, August 19, 2009 08:18 To: IBM-MAIN@bama.ua.edu Subject: SMTP delivery delay Goodday, We are running SMTP server on z/OS 1.9 on one of our LPARs. The emails from various LPARs are routed to this system via NJE. The emails are relayed to a MS-Exchange Server through this SMTP server. We have been flooded by a process that needs to send out emails. We noticed that there is a +/- 15-20sec delay between each of the Delivery statements. The system is not CPU/ I/O constraint. <snipped some text> We currently on a backlog of over 3000 notes. At this rate we will only catch up in 12-13 hours if no further notes are received. Your assistance is very much appreciated. Kind Regards, Vikesh Bhoola Please Note: This email and its contents are subject to our email legal notice which can be viewed at http://www.sars.gov.za/Email_Disclaimer.pdf ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
