× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.