Re: SMTP Log? -- MIDRANGE-L

We are using MAILTOOL, and in talking with Brad we decided to get the Plus
addon to cut out the potential problems with using MSF. We are now sending
out 200-300 emails a week from the server and want something more reliable.

In the meantime I ended MSF (ENDMSF) then restarted it with *clear (STRMSF
*CLEAR) to clear out the old unsent emails until we have this new part up
and running.
--
Mike Wills
http://mikewills.info
P: (507) 933-0880 | Skype: koldark

On Thu, Apr 1, 2010 at 1:24 PM, Scott Klement
<midrange-l@xxxxxxxxxxxxxxxx>wrote:

How are you creating these e-mails?

One of the most common (and aggravating) things about this system is the
horrible QtmmSendMail() API that folks seem to insist on using for their
mail tools. To use this API, you create an IFS stream file containing
the message, then call the API and tell it about the recipients of the
message and what the stream file is called. The API then hands it off
to the batch jobs that handle mail to do the processing.

The problem is... if your program proceeds to reuse that same stream
file, it has an excellent chance of changing it before the batch job
gets ahold of it.

You write an e-mail to customer A (let's say A="Alice"). You create a
stream file containing the relevant details of Alice's account status
with you. You now call QtmmSendMail and tell it that this stream file
is to be sent to Alice. After you're done, you replace the stream file
with details for Bob (Customer B=Bob)... But the batch job that
handles e-mail is working at the same time, and it's sending that stream
file to Alice... due to the timing, you may change the stream file as
it's being sent to Alice -- and therefore Alice gets Bob's data.
Meanwhile your program continues, and cues up an E-mail to go to Bob...
Now the batch job starts to process it, but your program has now
changed the stream file to be for Charlie... so Charlie gets Bob's
data... all depending on whether your program runs faster or the
background e-mail software runs faster.

Personally, I don't use the QtmmSendMail() API. It's not easy to use.
It's not easy to troubleshoot, and it doesn't notify you when it's done
with your stream file.

Instead, I use sockets to talk directly to the SMTP server. It's not
really any harder (indeed, once you've turned your SMTP program into a
reusable service program, it's considerably easier, because
QtmmSendMail() has such a crappy interface.) Talking SMTP directly,
the background server has no knowledge of your file on disk... it just
knows what you've sent over the socket. Once you get a response code
from it, you know it accepted your message.

Plus, you have the option to connect to any SMTP server (not just the
one IBM provides with i)

And it's much easier to troubleshoot, because you've coded better error
logging and tracing into your application. Vs. IBM's messages like
"Something in a parameter is invalid." leaving you to guess what the
problem was... or even worse, the fact that if the server decides not
to relay your message, you don't find out at all unless you check the
logs or have a bounce account that it's sent to.

On 4/1/2010 1:04 PM, Mike wrote:

It happened again! This time we were sending out AP payment notices and

some

customers received other customers' water bills or invoices from AR. From
9/09 in both cases. Is there a queue somewhere that may hold these emails
that could get cleared out?

--
Mike Wills
http://mikewills.info
P: (507) 933-0880 | Skype: koldark

On Wed, Mar 31, 2010 at 10:06 AM, Mike<koldark@xxxxxxxxx> wrote:

The utility bill doesn't even have any attachments. The AR invoice does,
but the utility bill points the customer to our website for details.

--
Mike Wills
http://mikewills.info
P: (507) 933-0880 | Skype: koldark

On Wed, Mar 31, 2010 at 9:41 AM,<rob@xxxxxxxxx> wrote:

Keep an eye on it.

I've found that a bulk emailing with attachments should be done at it's
own time. It was a real hoot when paystubs went to the wrong people.

Hey,

we've now outsourced payroll, direct deposit is mandatory, and if you

want

to look at your stub go to their website.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: Mike<koldark@xxxxxxxxx>
To: Midrange Systems Technical Discussion<midrange-l@xxxxxxxxxxxx>
Date: 03/31/2010 10:01 AM
Subject: Re: SMTP Log?
Sent by: midrange-l-bounces@xxxxxxxxxxxx

Thanks guys for the tips. I couldn't find anything. We are going to

call

it
a glitch until it happens again. Everything about it is just weird.

--
Mike Wills
http://mikewills.info
P: (507) 933-0880 | Skype: koldark

On Tue, Mar 30, 2010 at 10:56 AM, James Perkins
<jrperkinsjr@xxxxxxxxx>wrote:

If you have journaling turned on it is journaled in the QZMF journal.
Try DSPJRN QZMF.
--
James R. Perkins

On Tue, Mar 30, 2010 at 07:54, Mike<koldark@xxxxxxxxx> wrote:

Is there any logs created by the SMTP server? I am tracking down a

mailing

issue and am having a heck of a time figuring out the source of the

problem.

Saturday morning we had 4 customer emails go out from our AR system

(which

is on generated at the time they print invoices) when no one was in

the

building. The only thing that got sent out that day was from an

automatic

job that emails out our water bills (different system from AR). The
"original" invoice email was send in August of last year. It was

emailed

out

again on Saturday to a different person. For example, the original

was

sent

to ar@xxxxxxxxxxx, CCed: ar@xxxxxxxxxxxxx, and at one point BCCed
me@xxxxxxxxxxxxx so I could monitor the emails to make sure they

were

sending okay. On Saturday, the same email sent out to

customer@xxxxxxxxxxxx

BCCed me@xxxxxxxxxxxxxx The copy of my email had it marked as sent

on

Aug.

'09 was TO: ar@xxxxxxxxxxxx I am going to check the headers of the

replies

to see what I can see in those yet.

Have you seen that before?

--
Mike Wills
http://mikewills.info
P: (507) 933-0880 | Skype: koldark
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)

mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.