Modern applications, both on the PC or those running on servers, have requirements to cater for multiple instances of the application running at the same time - for example, in a multi-user environment, each user running a session simultaneously with other users.
Many COBOL applications are traditionally single user programs and run as single sessions each independent of each other and are not ready for running in a multi-user environment. If you try to run several instances of the same application simultaneously, you can get issues such as file locking and memory isolation breaking down because suddenly the same resource set is being used by multiple users.
It is possible to fix this with rewriting the code but that would require significant code changes.
Micro Focus Enterprise Developer solves this with a construct called a Run Unit that can co-exist in the same process . A Run Unit is collection of one or more programs that share the same address space, lock tables, and OpenESQL connections. When using the runtime services type RunUnit you can create multiple Run Units in the same process, with all individual Run Units being isolated from each other.
A COBOL program in one Run Unit will not normally access the memory of a program in another Run Unit. There is isolation between them. Also, file locks are held for each Run Unit - if a program in one Run Unit holds a file lock it will not be accessible to a file handling program in another Run Unit in the same process.
Run Units are specified by the runtime assembly Micro Focus Runtime (Interop RuntimeServices) (which appears as a MicroFocus.COBOL.RuntimeServices reference in your project) (for .NET) and the runtime class com.microfocus.cobol.runtimeservices.RunUnit (in JVM COBOL).
To do this, the calling program creates a Run Unit and creates an instance of the COBOL type that contains the program. Then the program instance can be invoked within the new Run Unit.
Note that you leave the existing procedural COBOL unchanged.
Managed COBOL code (including any programs, classes, enum, or valuetypes) that uses EXEC SQL statements must be used in a managed RunUnit with the exception of .NET code executing under the control of the SQL Server as SQLCLR stored procedures or types. This is because this code is automatically executed in managed RunUnits so no change is required for these applications.
If the code being executed requires to be executed in a multi-user environment or a thread pool environment, then the use of managed RunUnits is also recommended but not required provided that the code is naturally coded for thread-safety.