Oh yeah. Everything was logged, replicated, backed up, etc... There were two DBs used, Informix and MySQL.. both backed up daily, and using transactions (we did some hacking to replicate transactions in MySQL in various ways). Any files which were transfered anywhere were encrypted and digitally signed.

Second, the big problem with Perl in my opinion are the types of texts published about it. There are reams of books on the Perl language but very few about Perl as the language for architecting complex systems.

Well, in the book I just finished this is somewhat taken care of, in a roundabout way. It is about writing CGI apps with Perl. In the book, many things are shown, which as a whole should give the reader an idea of how to use the various Perl tools to write applications. Although the book is geared to CGI, the concepts are the same.
One of the problems I see, is that people (CIOs, et al) may not think Perl can do what it can do, so they use a buzzword compliant language. Hopefully, they use the Right Tool for the job. If that is C, so be it. If it is Java, then so it is.

I don't know that books on architecting complex systems with Perl would make people do it. First, you need to know how to architect a complex system, then choose the tool(s) to make it a reality. Another project we worked on was a portal between vendors. The central server for this was done in Java, and the grunt work with Perl. Many robust systems use different tools to accomplish what the blueprint lays out.

You need to write a concrete text showing HOW it is done and WHY Perl is best-suited for the job.

Do I? How would I show you how it is done (I can't show you the code)? Nothing magical was done, heavy DBI usage, cron jobs, CGI, some Win32 Perl, etc... Nothing that hasn't been explained a billion times already. Most of the it was on one side you have a FourGen interface into Informix, scripts that move data from Informix to MySQL, a web front end to MySQL, and scripts that move data from MySQL to Informix. Perl handled all EDI transactions, putting them into Informix, which replicated to MySQL, etc...Not brain surgery.. just timing and having a decent blueprint to create the system around (many flow charts, specs, test cases, and more flow charts).

For, if we had to do something of this scale and robustness, most of us we would be lost.

Why would people fail? The only reason I could think of is not knowing what Perl can do, or not knowing how to do it. That is the fault of the individual, not on the size of the system. I mean really, many systems today are "Put crap in a DB, take crap out of a DB". Figuring out what to do with the crap, validate the crap, munge the crap, display the crap, etc... are the details architects and developers need to figure out. That is the hard part.. writing it in Perl is the easy part.

Cheers,
KM