Customer is using a C# front end that calls a managed code COBOL class which in turn calls a native COBOL .dll. The C# program is creating a new instance of a RunUnit (MicroFocus.COBOL.RuntimeServices.RunUnit) and then calling the managed COBOL program by adding it to the RunUnit. Is it OK for the managed COBOL to call the native COBOL .dll when it is part of a RunUnit?
Yes, you can call native COBOL .dlls from managed COBOL when they are part of a RunUnit instance. The native runtime has a “one rununit” per process model, so in effect the native code will be shared between all the managed RunUnits. The native and managed RunUnit have no interaction with each other, so a CANCEL in managed code has no effect on the native RunUnit. The same goes for open files, they will not be shared between the two RunUnits. This in itself might not be a problem if the program is stateless or serialized… ie: local-storage based and no shared resources. Alternatively, if the managed code is self-hosted, you could associate a managed RunUnit with a thread and make the native code thread-local or REENTRANT”2” based, thus creating a model that allows both to co-exist, very similar in concept to an apartment model. Another approach is to pass the managed RunUnit id to the native code and if you have variables that need to be “managed RunUnit local” use the managed RunUnit id as an index.