From your original problem statement, you appear to have all the information you need. Main is working. The subprocesses either don't have GRPNAM or GRPPRV or SYSNAM or SYSPRV, or the subprocesses don't have the translation of the logical name needed to redirect the creation of that pesky logical name into the group logical name table. That's a pretty narrow target area for a multi-process application, too.
Your error appears to be a simple one: you believe the code works, and that "something else" other than the code is at fault. Classic debugging mistake, that.
Do not ever assume that "working code" is "correct code."
Do not fear logging.
Do not fear the debugger.
An application bug is always assumed to be the programmer's bug, until the DRI (designated responsible individual) either does prove that the bug is within the code and then fixes it, or until the DRI proves the bug is somebody else's, and provides the new DRI with information and preferably a reproducer.
As for this case...
Check the process quotas on the created processes, check the privileges within the created processes, check the translation of the associated logical names within in the context of the processes, check the run-time logs that the processes are (or should be) creating for themselves and (if the processes are not creating logs either directly under program control or somewhat less desirably as an artifact of the output for the process) add logging to the processes.
The next round of checks are for programming bugs that seemingly inevitably lurk in code that is referred to as "working code" in a forum posting.
These can include failures to check status and IOSB consistently, failure to declare an IOSB in non-volatile storage, failure to specify an IOSB whereever it is an available or optional argument, failure to handle shared memory correctly and particularly within multiprocessors, colliding access to IOSBs or event flags across asynchronous code, failure to correctly allocate event flags for use, and there exist a wide variety of other potential bugs in this particular zoo.
Variations that can arise when porting code can involve not propagating ACLs or protection masks from previous system environments, file ownership and file protection differences, differences in privileges in the default context, and subsystem identifiers.
The core of the debugging effort for these cases typically involves the aforementioned application-integrated logging, and building with and using the OpenVMS debugger, and there are various (easy) ways to implement that. What follows is an example of how a detached process can use a DECterm X Window display (on the local box or a remote X Window Server system) to display debugging activity:
http://labs.hoffmanlabs.com/node/803Application-implemented debug logging and the OpenVMS Debugger are going to be two of the most useful approaches here.
