File Summary Storage location

P> [...] thousands of files that are rapidly being created and
P> deleted [...]
P> Currently our system creates triplets for files (3 files per job
P> instance). [...]
P> Files are received by one multi-threaded process, handled and
P> delegated by 2nd multi-threaded process and finally processed
P> and deleted by 3rd multi-thread process. [...]

JdeBP> Modern electronic mail transport systems have much the
JdeBP> same design.

P> Funny you recognize this.

Not really.

P> I can't speak about gmail today, but a good deal our framework
P> issue is based on the idea that it still has legacy logic to
support
P> the old slip/uucp naming convention and transport methods. This
P> is where we got the 64k sequential limit (actually 5 digits).
P> SendMail had the same problem before Eric modernize it by
P> completely letting go of slip/uucp for 100% smtp support. I was
P> told as much by John Klensin (RFC 2821 current editor) that I
P> will have to let go just like Eric did. :-)

mmdf.html>

It's ironic that the advantages of Sendmail in the 1980s are
disadvantages now.

P> So WCSMTP is alittle ahead of the curve in this aspect. :-)

Ah! Hector Santos.

P> - ProcessA(), the SMTP receiver using GetTempFileName() to spool
P> incoming files. It signals ProcessB(). [...]
P> - ProcessB(), the SMTP router, processes the spool and creates the
P> triplets (*.DAT/XQT/CMD) UUCP format ready files for outbound
P> mail, and pairs (*.D/*X) for local imports, moves them to a
gateway
P> spool. [...]
P> - ProcessC(), the gateway, imports the *.D/X for local hosted mail.
P> - ProcessD(), the SMTP outbound, process qthe *.DAT/XQT/CMD by
moving it
P> into another outbound queue.
P> [...]
P> So once we deprecate the uucp/slip baloney, we should
P> be ok. I can't wait. :-)

Most modern MTS softwares evolve towards the same multi-daemon design
and queue structure, which has been around since the middle 1980s.
Those who don't understand MMDF and ZMailer are condemned to reinvent
them, slowly.