I considered changing the multiThreaded parms rather than the default, and spending time experimenting with parms was going to be the next investigation step.
For our Chg Mgmt System, we have to put the Triggers on manually when going into production, anyway. So here, some people are not fond of file-triggers.
"Multithreaded job action (MLTTHDACN)
Thread problems was about all that I could think of to cause this ugly inconsistent behavior.
Even though the design is being changed on this project, I am afraid on the next project we have that uses a Trigger-Feeding-DataQueue design, that this problem will raise its ugly head again.
If it does, I will alert the group & be back here asking "Why?"
I absolutely endorse the logging of the data-queue entries used in C/S apps, which is why there is a shadow file in the app that mirrors each send entry of QSNDDTAQ with a write of the same structure of the DQ entry to a database file. (When you get to client server apps like this, you have to be sure you actually know what those Microsoft people are doing on the other side of the wire.)
Unfortunately, logging the actual entry into a dataqueue to a journal did not seem possible (not using Mimix Journals the way we have them configured, anyway).
Thanks to everyone for their help with this.