Will a COBOL Run Unit started in the subject way continue to run to its conclusion regardless of what happens in IIS; i.e., the app pool cycles or IIS gets stopped/hung/terminated?

A Run Unit is alive until the "StopRun" method is invoked on the RunUnit class.

Have a look at the session management events (session start/end), you might be able to use these to handle the life of rununit being used.

---

Will a COBOL Run Unit started in the subject way continue to run to its conclusion regardless of what happens in IIS; i.e., the app pool cycles or IIS gets stopped/hung/terminated?

My documentation is unavailable at the moment. But you mention invoking the "StopRun" method on the RunUnit class. This would be from the program that started the Run Unit in the first place?

We're trying to do a "fire and forget" approach, where the aspx program goes away after starting the Run Unit so it won't be able to invoke the "StopRun" method. Would a good ol' COBOL "STOP RUN" statement executed from within the Run Unit suffice?

---

Will a COBOL Run Unit started in the subject way continue to run to its conclusion regardless of what happens in IIS; i.e., the app pool cycles or IIS gets stopped/hung/terminated?

If the COBOL had a "stop run" in it's code, it would cause a COBOLStopRunException to be raised, which might depending on how this is handled cause the code outside of COBOL problems.

If you want to just "fire and forget", then wrapping the COBOL with a RunUnit create with a try/finally is a good approach.

MicroFocus.COBOL.RuntimeServices.RunUnit myRunUnit = new MicroFocus.COBOL.RuntimeServices.RunUnit();
try
{
// Call the COBOL program
result = myRunUnit.Call("Program1", "Alice", 21);
result2 = myRunUnit.Call("Program2");
}
finally
{
// Destroy the run unit
myRunUnit.StopRun();
}

---

Will a COBOL Run Unit started in the subject way continue to run to its conclusion regardless of what happens in IIS; i.e., the app pool cycles or IIS gets stopped/hung/terminated?

The following is what we have been using to call COBOL "programs" from C# code-behind of .aspx programs. The COBOL "programs" were originally separate batch programs executed from JCL on a mainframe. Now they are separate entry points in a COBOL class, each with a single method "InstanceMethod" (ACT01P is one of the entry points in the COBOL class):

MicroFocus.COBOL.RuntimeServices.RunUnit myRunUnit = new MicroFocus.COBOL.RuntimeServices.RunUnit();

try
{
ACT01P myCobol = new ACT01P();
myRunUnit.Add(myCobol);
sOutput = myCobol.InstanceMethod(ref param_control);
if (sOutput == "ERROR") { bError = true; } //Processing Error Notification, LogFile already written in COBOL
}
catch (Exception ex)
{
bError = true;
sLine = "**** ERROR:" ex.Message.ToString();
}
finally
{
myRunUnit.StopRun(); //Free Resources
}

The .aspx program that represents a "batch job" will execute a series of the above blocks, each referencing a different COBOL "program". But we've had all kinds of issues with IIS "sessions" going away when execution in a COBOL "program" is several minutes long and the jobs get interrupted and are incomplete.

So now we want the .aspx program to start a single COBOL "Task Driver" program, give it a list of the batch programs to execute, and then go off to something else, or terminate, without waiting for the "Task Driver" to come back.

What we had started playing with before starting this thread is:

MicroFocus.COBOL.RuntimeServices.RunUnit myRunUnit = new MicroFocus.COBOL.RuntimeServices.RunUnit();

try
{
TaskDriver myCobol = new TaskDriver();
myRunUnit.Add(myCobol);
myCobol.InstanceMethod(ref param_control); //Not coming back using "Stop Run" in COBOL
}
finally
{
myRunUnit.StopRun(); //Free Resources just incase
}

TaskDriver is an entry point in the same COBOL class above, and it does a "STOP RUN" after it finishes processing the list of batch programs. The "finally" clause is there as a guarantee that the run unit is gone. In preliminary testing we never get back from the try, which is what we want!

In your example you use "Call" instead of "Add". What are "Program1" and Program2", .exes or separate .dlls or ... ?

---

Will a COBOL Run Unit started in the subject way continue to run to its conclusion regardless of what happens in IIS; i.e., the app pool cycles or IIS gets stopped/hung/terminated?

The "Call" method is a dynamic CALL to the program, which is doing a dynamic search for it.. doing the "add" and then the Call.

So if you have a reference to the program, then doing the Add and using the instance of the program is the better of the two in terms of performance.

---