Thank you for the reply, yes it turns out this is the very problem. With further research it turns out in 2004 there was a large number of people who had this problem. While the Orchestration does not directly read from the MQSeries queue, I assumed the performance hit would not be significant so used a 12 second delay functoid to determine when there were no more messages.
Apparently a message is read from the queue by the MQSeries adapter (possible transformation), sent through the Receive Location (perhaps more transformations), written to the BizTalkMsgBoxDb, read by the Pub/Sub service and routed to my orchestration. Seems 12 seconds was way too low resulting in many zombie processes and discarding 33,303 messages out of 65,861. WOW!
I changed the delay to 20 minutes and the very first test had a single Orchestration go zombie on me due to a 23:16 minute gap in processing one message and the next. At least that time I only discarded 67 out of 65,861.
Final result is I changed the delay to 60 minutes. This will process all message, batching them into groups of 500 but the final batch of messages will be delayed that 60 minutes while the Orchestration takes that time to figure out there are no messsages. For our process this will not be a real issue.
We did look at some sample of going to a database instead but we have a very limited time to fix this and could not consider an alternative unless we could not get this working and 60 minute delay does seem to resolve the issue. For the next release I may be able to revisit this design.
Thank you for the help.