Highlighted
Super Contributor.
Super Contributor.
1521 views

Life of a COBOL Run Unit called from C# backend of ASPX program

Jump to solution
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?
0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Life of a COBOL Run Unit called from C# backend of ASPX program

Jump to solution
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.

View solution in original post

0 Likes
5 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Life of a COBOL Run Unit called from C# backend of ASPX program

Jump to solution
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.
0 Likes
Highlighted
Super Contributor.
Super Contributor.

RE: Life of a COBOL Run Unit called from C# backend of ASPX program

Jump to solution
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?
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Life of a COBOL Run Unit called from C# backend of ASPX program

Jump to solution
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();
}
0 Likes
Highlighted
Super Contributor.
Super Contributor.

RE: Life of a COBOL Run Unit called from C# backend of ASPX program

Jump to solution
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 ... ?
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Life of a COBOL Run Unit called from C# backend of ASPX program

Jump to solution
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.

View solution in original post

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.