You can try running a "strace" on the translation on each differing system.
Strace is a system call trace, i.e. a debugging tool which prints out a trace of all the system calls made by a another process/program. The program to be traced need not be recompiled for this, so you can use it on binaries for which you don't have source. System calls and signals are events that happen at the user/kernel interface. A close examination of this boundary is very useful for bug isolation, sanity checking and attempting to capture race conditions.
In the simplest case strace runs the specified command until it exits. It intercepts and records the system calls which are called by a process and the signals which are received by a process. … System administrators, diagnosticians and trouble-shooters will find it invaluable for solving problems with programs for which the source is not readily available since they do not need to be recompiled in order to trace them. Students, hackers and the overly-curious will find that a great deal can be learned about a system and its system calls by tracing even ordinary programs. And programmers will find that since system calls and signals are events that happen at the user/kernel interface, a close examination of this boundary is very useful for bug isolation, sanity checking and attempting to capture race conditions. [
http://www.die.net/doc/linux/man/man1/strace.1.html]
To Run:
Put your inittrans statement in a translation.sh script (and put a "sleep 20" as the very first line)
Execute à ./translation.sh &
This will toss the translation into the background and pop out a PID to STDOUT for the backgrounded process
Before your sleep time set ends, type and Execute à strace –T –f –p PID# > /tmp/translation.log
This will generate a strace output showing what happens system call wise with the translation. You can then look for the 126 return on PROD and the 0 return on PREPROD in the log and try to figure out what is causing the error.