Gary, You're welcome. It took me quite some time, observing the flow of messages through SMTP, to figure out what was going on. Some helpful soul at IBM SMTP support then filled in a few more blanks, but eventually I got the picture (I think). The "traditional"[1] SMTP server is written in PASCAL and has been around since TCP/IP was made available on the mainframe. It's a single-task process, not a multi-tasker. In a round-robin fashion, SMTP goes thru the list of tasks it has to perform (not necessarily in the order I'm writing here and I'm omitting some detail for brevity and/or may not be 100% correct, but you'll get the picture): - at server start, process stored messages waiting to be sent, build work-to-do queue -[A] process one spool file in its entirety and store all mail messages it contains in dynamically allocated disk datasets (1 address book file and 1 message contents file per email) - generate error messages to sender if spool file processing problem, store it - listen on TCP/IP for other mail servers wanting to send mail to the mainframe - if IP connection pending, connect and receive 1 mail message from 1 IP server, store it in disk datasets, disconnect - check stored messages ... what can I send where? - connect to 1 IP mail server, send 1 message, disconnect - anything to be sent via NJE? If so, format it and send it - anything to be sent to local user? Format to TRANSMIT/RECEIVE format and spool it - update address book file and mark as Sent any mail that was successfully sent - check address book file. Finished sending to all names in distribution list? If so, delete address book and contents file - update work-to-do queue with whatever just happened - If no more work to do, set timer wait, sleep a few seconds, then repeat from [A].
As you can see, only one action is performed at any given moment in time. While a large multi-email spool file is being processed, none of the other steps in the list above happen ... that's where the performance bottlenecks come in. And now you know the most likely cause of SMTP server performance problems. --- [1] I'm not talking about the USS/Unix-based mail package here. I'd love to be able to lay hands on it and experiment with it, specifically to see if it can multi-task, but I haven't gotten a chance yet to open this can of worms. Regards, Ulrich Krueger -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gary Green Sent: Friday, November 30, 2007 12:16 To: [email protected] Subject: Re: Send email from MVS cobol Ulrich, Thanks for the information. I did not know that SMTP was so single-minded! That answers a question of why it took so long to get some emails "out the door" at a client I was at back in 01. It was a PITA but not enough for the client to dedicate my billable hours to finding the answer. ---------------------------------------------------------------------- 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
