RE: Paging software for the iSeries

> I think this is a sticking point that gives the trouble. We have the
> SMTP Server and the Mail Server Framework. Aside from these, there's the
> protocol known as <SMTP>. For the first two, I've never been clear which
> is responsible for rejecting e-mail when DASD threshholds are reached
> nor how it relates to _outgoing_ e-mail.
>
> But neither of those are the same as <SMTP> itself. That implies that an
> SMTP client program ought to be able to send e-mail regardless of DASD
> threshhold. The simple requirement would be not to go through the SMTP
> Server.

Here's the way that I look at it...

There's basically two different types of programs that use the SMTP
protocol.  They're called Mail User Agents (MUA) and Mail Transport Agents
(MTA.)  The IBM SMTP server is an MTA.  As are similar products, like
Sendmail, Postfix, QMail, etc.  E-mail clients are usually MUAs, Eudora,
Outlook, Mozilla/Netscape's E-mail client, etc.

I guess you could call SNDDST, QtmmSendMail, SNDEMAIL, and similar
utilities MUAs as well, though I don't know that much about them, so I
can't be sure.

The MUA's job is to take an e-mail message from a user (or program) and
use the SMTP protocol to communicate that to an MTA.   It's usually an
interactive program, which if it can't connect to the MTA, simply fails
outright, reporting an error to the user.

The MTA's job is to be more robust.  It saves the mail to disk.  It tries
to forward it to the mail exchanger than handles the destination mailbox,
but if that fails, it keeps retrying.  It does things like log messages,
creating message-id's for tracking, sends notification messages to the
user when something fails, or to the postmaster when there's a more severe
error...  it's a background service (or "daemon") whos job is to make sure
that the mail gets where it's going.

Nowadays, MTA's frequently also have anti-spam and virus scanning features
built into them.

So, I guess what I'm getting at is that my program which sends pages, etc,
is an MUA.   It does not need DASD, because it creates the message in
memory and then forwards it to an MTA.  No need to write it to disk.

However, IBM's SMTP server is an MTA, and therefore won't work when it's
out of disk...

Of course, I do have an MTA, it's just not running on my '400.  It's on a
FreeBSD box.  The way I have the disk partitioned on my freeBSD box,
e-mail is in it's own partition.  If things like log files or user
applications run out of space (yes, there is something similar to a DASD
threshold in FreeBSD) they won't affect e-mail.  Likewise, if someone
should "mail-bomb" me (or some similar attack) my e-mail would stop, but
my applications would continue to work.   So far, that's never happened.

But, I can always have my program connect to any SMTP server that's
willing to accept e-mail from me.   Just like you might configure your
outlook to send it's mail to your ISP's mail server, or something like
that, I can do the same with my paging software.

> I have a CL program that uses the IBM Custom Technology Center socket
> APIs to send SMTP mail regardless of the state of my SMTP Server. I
> could also write an ILE RPG program to do the same if I wanted to take
> the time.

Heh.  I wouldn't even consider doing something like that in CL.  But
that's neither here nor there :)

> The point that can be made from Scott's comment is that an SMTP client
> program is just another sockets program that connects to some remote
> system on port 25 and sends data. It ought to work as long as TCP/IP is
> working.

Every piece of TCP/IP software is "just another sockets program."  From
low level stuff like ping and traceroute all the way up to really high
level stuff like web browsers and newsreaders.   Every program that
communicates over the internet is "just another sockets program."

> As for the original question, I used to use a PC program that did
> paging. I'd connect to it, send an SMTP message and it did the rest.
> Cheap. I haven't looked for it for a few years, but a Google search
> should show some hits.

If you're just writing an MUA, an SMTP client is a fairly simple program,
and doesn't need to be all that robust.

If you're writing an MTA, however, it's not so simple.  You have to do
some fairly advanced string parsing, plus queueing of messages, and
keeping track each one so that it can be resent properly... they can get
very complex.

If you find that SNDDST or QtmmSendMail is not performing to your specs,
however, write yourself a simple MUA.  That's not so difficult.

> One advantage was that any system that could do SMTP outbound could use
> it. Disadvantage was that it used SMTP -- obviously worthless if the
> message was "TCP/IP is down." Of course, dialing out is also worthless
> if the message is "Modem unavailable."

And that's where the REAL problem lies.  Any computer system will have
problems reporting some errors, you can only take it so far.   For example
"A tornado just tore apart my computer room" is the kind of message you'll
be unlikely to ever be able to deliver... :)

With modem, the modem itself might get fried.  Or the telephone lines
could be down.  Or the paging company's lines/modem/computer could be
down.  Or "all circuits are busy, please try again" could be reported by
the phone company.

Likewise, Internet could be down because of your network card, or router,
or internet service line, or the ISP's equipment, or the paging company's
equipment...

So, you have to define under what circumstances your "error notification"
software will work, and decide for yourself if it's acceptable.