|
Sorry for the delay. Well actually when mine "crashes" it would even accept any incoming mails. Which basically means the AS/400 stops listening to port 25 altogether. And the only way to get out of this is to restart the SMTP server. Anyone has any ideas? Say how would you simulate a 'clog' in the mail stream? What causes it? Cheers! PaulMmn wrote: > I wouldn't have called it a crash, but we've had an ongoing intermittent > problem with SMTP Mail. We get a 'clog' in the outgoing mail stream. > Incoming mail works fine, but outgoing mail won't. > > Symptoms include complaints that mail won't send. If you look in subsystem > QSYSWRK, check the joblog for job QSMTPSRVR. The first few entries include > the number of jobs in the outgoing and incoming queues. If the numbers > aren't zero, you may have a clog, or the system may be slow. Only way to > tell is to ENDTCPSVR *SMTP, then re-start it. If the numbers go down, your > system is slow. If they stay the same, you may have a clog. Or the > recipient of one or more messages is temporarily unavailable; the message > may send later. > > Even at those times when things seemed their worst, outgoing mail would > trickle through, sometimes after -weeks.- IBM maintains that a single > 'faulty' message should have no effect on other messages. > > We've found no cure. The only work around is to ENDMSF and ENTCPSVR *SMTP. > Set the data area for SMTP to start and throw away the first mail item it > finds (Yes, it's lost). Start MSF and SMTP and examine the joblog. Repeat > until the outgoing queue is empty. Now restart both MSF and SMTP with the > cold-start options (to flush things out totally). > > After a cold start, SMTP behaves itself for a while (weeks, months). Then > a clog may happen again. > > IBM has taken dumps, logs, looked at the flight records, and poked around, > but without any definite answers. Going back a ways, one problem was that > AOL had so many name servers, but IBM only checked the first 2. If the > name servers you were after on AOL were down, the mail wouldn't send. This > has been fixed. > > Looking at the flight recorders is just about the only way to decipher the > problem; we just don't have the time to constantly monitor the files. > > We're currently running fine (knock on wood). However, we keep looking at > the joblog to make sure we're not clogged up again. > > --Paul E Musselman > PaulMmn@ix.netcom.com > > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: david@midrange.com > +--- -- Ferdinand Tang email: ferd@pacific.net.sg homepage: http://home.pacific.net.sg/~ferd/ ---------------------------------------------------------------- An ounce of application is worth a ton of abstraction. ---------------------------------------------------------------- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
