Comments (2)

By spgennard, January 19, 2010 11:39 am

The use of scripting languages with other languages has increased over the last couple of years, from a simple case of interoperability, reuse of scripting code to allowing your code to customised via the user of external scripts. All of which are real world examples I have seen customers use.

Interoperability between languages is very important to COBOL environments just as much as other languages. Some platforms such as Microsoft’s .Net with their CLR makes life much easier by allowing all languages to share a common infrastructure ie: the instruction set and the VM (MSIL and CLR) along with a base class library to get you started.

Environments such as Sun’s VM (JVM) provide two different approaches to interoperability with Java, the first is via JNI/JNA and the second is producing bytecode that runs as is on the VM.

Although the Micro Focus COBOL compiler does not support JVM bytecode or Java source generation it does have support for invoking classes/methods via the OO invoke verb.

This mechanism is very simple to use, you just need to let our object COBOL runtime know the class is a Java class, which can be done by placing $JAVA$ before the name of the class and ensuring the class itself can be found by the JVM itself usually by adding an extra directories or .jar files to the CLASSPATH environment variable.

With Java 6.0 and JSR 223 support for Java based scripting languages were provided via the package javax.script.

Java has a wealth of scripting languages from awk to xlst. My favourites being jpython, jruby and javascript.

The java.net website has a comprehensive list of scripting languages -
https://scripting.dev.java.net/.

To use the scripting packages, you first need to create a ScriptEngineManager, then use this to create a specific ScriptEngine object for your chosen scripting language and use it.

For example:

In COBOL this is quite simply:

The actual Javascript being execute is contained in the invoke statement, which is simply:

To use the above example, we first need to compile the code and run it.. which is done as follows:

This is just the start, the next thing piece that is required with interoperability to another language is the ability to pass parameters to in and out of the script. Luckily for us the clever chaps on the jsr group have provided ‘put’ and ‘get’ methods that allows us to simply put a name parameter and get the resulting updated or new parameter.

So consider the example, where we need to setup a parameter called ‘message’ for the script and then read a parameter called ‘replyMessage’ after the script has been executed. The javascript to do this is:

To setup the message parameter, we just need todo.

The after the script has executed, we just need to use the ‘get’ method..

The completed COBOL example below, uses a side file for the javascript too, the code is as follows:

As you can see from the code above, setting up parameter is pretty easy todo but sometimes we just want to execute a function in the scripting language such as:

The ScriptEngine object that we have created to use the scripting engine may implement an optional interface called javax.script.Invocable, if the scripting engine we are using does provide this interface then a method called invokeFunction(..) can be used.

In order to reduce the size of the COBOL code, I have coded a simple utils class in java as a simple proxy layer, the code is pretty simple but does make it easier for the COBOL to use the invokeFunction() method.

Which gives us the following output when executed.

The completed example is as follows:

Conclusions: Using a Java based scripting language from COBOL is quite easy, so feel free to use it. Now which scripting language should I use…?

Comments Off

By spgennard, December 5, 2009 11:56 am

Monitor’ing Java processes can be achieved using the jvmstat monitor classes provided in the JVM. The documentation is a bit sketchy but with a little experimenting it can be done.

Below is a little example that shows you how to get a list of active Java processes.. which of course can then be used for other things

Here’s the code…

And to see the code running..

Comments Off

By spgennard, December 5, 2009 12:53 am

While working on a project recently I need to find out the current process of the active running Java process (for tracing/auditing), however I never found a 100% perfect solution but did come across an acceptable solution to use the management classes to query its name, which happens to have encoding in it, so here is the quick solution:

Comments Off

By spgennard, November 24, 2009 12:27 am

Having read a recent bog about COBOL and type-safety, I though I would jot down some comments.

ANS85 COBOL is naturally is type-unsafe due as every data item being part of one memory region (or storage area), because of this it can make is difficult to talk to type-safe language such as Java or the CLR.

However, just like any computer language it does not stay still. Object oriented features were added to COBOL, at this point in time you we were given the verbs to create 100% type safe application.

The key to writing type safe code is the use OBJECT-REFERENCE will a TYPE and using them on in your methods and using the INVOKE verb.

For example:

The use of COBOL pictures can still be used, however for easy interop with other type-safe languages you really have to stick to the right types for your target environment when exposing your COBOL program to the other languages, this means if you are creating classes, the method to be consumed by other languages should use standard types, for .Net/CLR applications the use of CLS-COMPLIANT types is the right approach. For JVM applications, keep to the “core” java.lang types.

Keep to these simple rules and COBOL will happy interop with type-safe languages.

Comments Off

By spgennard, November 9, 2009 9:10 pm

Java is a very safe language if used in a normal way, however just like the CLR it can be used in an unsafe manor.

The main reason for using Java in a unsafe manor is performance, some unsafe operations are optimised by the JVM itself.

The boot class loader grants enough permissions to access a key undocumented class sun.misc.Unsafe. As I will state, this is an undocumented class and as the name implies it’s unsafe.

This class provides methods that allows you to manipulate objects and the memory of the objects directly.

For example, you could use it to access the object itself, lets look at an example to manipulate a String object.. not nice I hear you say…. and boy are you are so right. The purpose of this example is to demonstrate the power of the JVM if used to the extreme but not to demonstrate how to destroy the JVM.

Then, the output of the example on my little macbook is:

As you can see the String object is changed but the hashCode remains the same.

Even if the above example seems weird to the extreme and it is, I offer you one take home from this blog…

Be very careful what you place on your “bootclasspath!”