Highlighted
Contributor.
Contributor.
291 views

RunUnit recommended approach with wrapper

Jump to solution

Hi,

I have completed a proof of concept task involving building Procedural COBOL as managed code and creating a COBOLjvm wrapper that binds/unbinds the DB connection and calls the now managed procedural COBOL.

Having completed a Java test harness to call the wrapper successfully I now want to integrate the wrapper into our Java application and use the RunUnit class as it's a multi-user application deployed on a application server.

Looking at the documentation and forum postings it seems you use either add/getInstance or call methods of RunUnit. The docs mainly refer to using SmartLinkage so any tips to the recommended approach when using a wrapper class would be much appreciated. I had thought of adding the wrapper to the RunUnit. 

 

0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: RunUnit recommended approach with wrapper

Jump to solution

So you are creating the connection in Java and then passing it to the wrapper in the RunUnit where it will do a EXEC SQL BIND CONNECTION and then call the procedural COBOL programs.

I believe that should work just fine.

Remember to invoke the StopRun method on the RunUnit when you are done with it to release any resources that have been allocated.

finally
   {
    // Destroy the run unit
       runUnit.StopRun();
   }

View solution in original post

3 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: RunUnit recommended approach with wrapper

Jump to solution

There is a demo program in the Samples browser that demonstrates a Java web application running under Tomcat that will invoke a JVM COBOL wrapper class that will then create the RunUnit and call various JVM procedural COBOL programs through the RunUnit. Select RunUnit in the left hand pane and then Airport Demo (Managed, RunUnit, Eclipse) in the right hand pane.

If you are creating your database connection within the wrapper then you should probably create your RunUnit in Java, add an instance of the wrapper class to it and invoke it thru the RunUnit so that you isolate and protect your connections from each other.

The ilsmartlinkage directive is for use on procedural COBOL programs. It causes the compiler to generate classes for the parameters passed in the linkage section so that Java can instantiate the class, populate the data fields and pass them directly to the COBOL program where they will be mapped onto the linkage section items. If you are calling the procedural COBOL from an OO COBOL class there is really no need to do this as the COBOL types can be used directly.

 

0 Likes
Highlighted
Contributor.
Contributor.

Re: RunUnit recommended approach with wrapper

Jump to solution

Thanks for the advice Chris, it's much appreciated.

I added the bind connection to the wrapper as I wanted the existing COBOL modules to be modified as little as possible, OpenESQL  permitting.

So had planned to add the wrapper to a new RunUnit as follows -

try (RunUnit runUnit = new RunUnit()) {
CobolWrapper wrapper = new CobolWrapper(recNum, getDataSource());
runUnit.Add(wrapper);
wrapper.callCobolProc();
}
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: RunUnit recommended approach with wrapper

Jump to solution

So you are creating the connection in Java and then passing it to the wrapper in the RunUnit where it will do a EXEC SQL BIND CONNECTION and then call the procedural COBOL programs.

I believe that should work just fine.

Remember to invoke the StopRun method on the RunUnit when you are done with it to release any resources that have been allocated.

finally
   {
    // Destroy the run unit
       runUnit.StopRun();
   }

View solution in original post

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.