JvisualVM is a Java virtual machine monitoring, troubleshooting, and profiling tool.

In Java version 8 and earlier, JvisualVM was installed along with the Java Development Kit (JDK). The JvisualVM executable file was found in the JDK bin directory. Since Java version 9, JvisualVM is no longer installed along with the JDK, but a bleeding-edge distribution of this tool can be downloaded from visualvm.github.io and installed separately.

In this chapter we're going to see how to monitor the isCOBOL Server activity and the load using JvisualVM.

JvisualVM is a Java tool itself. The Java Virtual Machine (JVM) behind this tool should be of the same version of the JDK or JRE you’re going to attach and monitor. When using the tool installed along with the JDK, this rule is automatically respected. When using the alternative distribution from GitHub, you can configure the underlying JVM in the file etc/visualvm.conf. By default, the GitHub distribution of JvisualVM uses the default JVM in the system (the first java command found in the system Path).

When JvisualVM starts, it lists all the Java applications running on the local machine along with their PID. You should find the isCOBOL Server among these applications.

The name of the application changes depending on the command that you used to start the isCOBOL Server.

In order to monitor the isCOBOL Server process, you have to attach it. Just double click on the application name in the tree or right click on it and choose "Open" from the pop-up menu.

Note - the process may not appear in the list if:

Sometimes it’s not possible to start JvisualVM on the same machine where isCOBOL Server is running. In this case you have to set up a remote JMX connection. The most common case is where the server is a Linux/Unix box where no graphical desktop is available, so in this guide we’re going to see how to set up the JMX connection on Linux and how to attach to it from a Windows client. Assume that the IP address of the Linux server is 192.168.0.130.

First of all, we need to dedicate a port to the JMX connection. In this example, we’re using port 3333.

Change the isCOBOL Server startup command as follows:

After the isCOBOL Server has been started,

In order to monitor the isCOBOL Server process, you have to attach it. Just double click on the application name in the tree or right click on it and choose "Open" from the pop-up menu.

The Monitor page allows you to monitor the CPU and memory usage of the isCOBOL Server process in real time as well as the number of loaded classes and active threads.

You should pay particular attention to the Heap monitor.

The Heap is the amount of RAM memory that is allocated to store resources used by COBOL handles like bitmaps, fonts, ESQL cursors, etcetera. This memory has an initial size that can be configured through the -Xms Java option and a maximum size that can be configured through the -Xmx Java option. The Heap usage increases when the COBOL application loads a new resource and decreases when a garbage collection is performed.

The garbage collection is a procedure that takes care of removing inactive resources (e.g. a font or a bitmap whose handle has been destroyed) from the Heap memory. This procedure is automatically triggered by the JVM when the Heap usage is near the maximum amount of memory available or when the JVM is idle. You can force a garbage collection from the JvisualVM screen by clicking the "Perform GC" button. Be aware that this procedure consumes CPU and it may slow down connected clients that are working.

The "Heap Dump" button allows you to take a snapshot of the Heap in a given moment. By analyzing this snapshot you can find out which classes are using most of the memory.

The Threads page lists all the threads that were created in the isCOBOL Server’s JVM. By default all threads are shown, including the ones that are not running anymore. You can filter the list using the "View" combo-box on top of the list.

The list includes a timeline that shows how the threads state changes as time goes by. There are five possible states:

The isCOBOL Clients connected to the isCOBOL Server can be identified by their name:

An IscobolThread that stay in Running state without changing to Wait or Sleeping for a lot of time means that the Client may be in an infinite loop and it could slow down all the other connected Clients. You can take advantage of the administration panel in order to check which program and paragraph are being executed by that thread.

The "Thread Dump" button allows you to take a snapshot of the threads in a given moment. By analyzing this snapshot you can see the state and the stack of each thread.

If neither JvisualVM nor a JMX connection is available on the machine where Java is running, it’s still possible to take a Heap or a Thread dump by using command line tools installed in the JDK bin directory.

You just need to know the JVM process ID (PID) in the system. Use system tools to retrieve it, for example, on Linux/Unix you can use the ps command:

Once you know the PID of your JVM, use this command to take a Heap dump:

To take a Thread dump, instead, use:

JvisualVM can help you calculate the amount of RAM that is necessary for your COBOL application to run in thin client mode with a given number of concurrent users.

Suppose that you’re going to install your COBOL application on a production server where 100 users will connect and you need to suggest the amount of RAM that the server machine should provide. You can calculate it empirically in this way:

Now you can make the following calculation: Necessary_RAM = A + ((B - A) * 100).

JvisualVM can help you find memory leaks.

The steps are similar to the ones described above:

If B is greater than A, then a memory leak is possible. You should repeat steps from 3 to 6 multiple times to see if the difference between A and B increases.

A COBOL application generates a variable number of threads that run simultaneously. The number of threads generated depends on multiple factors. For example, threads may be created explicitly by the COBOL programs if they use PERFORM THREAD, CALL THREAD or CALL RUN statements, but threads may also be created internally by the runtime system to implement some features (e.g. the BEFORE TIME clause on the ACCEPT statements implies a thread that controls whenever the timeout expires).

JvisualVM can help you calculate the amount of concurrent threads generated by your COBOL application when running in thin client mode with a given number of concurrent users.

Suppose that you’re going to install your COBOL application on a production server where 100 users will connect and you wish to know the amount of concurrent threads that will run. You can calculate it empirically in this way:

Now you can make the following calculation: Number_of_Threads = A + ((B - A) * 100).

If the number of threads is very high, consider reducing the memory that Java dedicates to the threads stack by using the -Xss option. This will allow you to save some memory.