support: Customer Portal
Focused on delivering choice, investment protection and flexibility to organizations with valuable COBOL assets

Veryant Knowledge Base
Home > All Categories > isCOBOL Server and Thin Client > With thin client is there a way to update and push changes to programs live (on the fly), without having to kill and restart the isCOBOL Server?
Question Title With thin client is there a way to update and push changes to programs live (on the fly), without having to kill and restart the isCOBOL Server?

I have the isCOBOL Server running on AIX along with some test classes. The classes work just find from my Windows workstation but there is a problem. When we want to make a change to a program, we create a new class object. The object is copied into the correct location, but when we execute the program, the original class/object is displayed. No changes are apparent. Iíve also tried deleting the class/object completely from the AIX box and the program still runs. We need a way to be able to make changes on the fly without having to kill the server and then restart the server.


The reason for the behavior you noticed is that the JVM keeps copies of the classes in a memory cache and generally does not reload them from disk even if the disk file is replaced.

This sometimes creates a problem for COBOL. Veryant has solved this problem by implementing a custom class loader in the isCOBOL framework. isCOBOL Server can be configured to use its own class loader to allow replacing classes on the fly.

Here are the steps:
  1. Make sure that the directories and jar files containing the COBOL programs you want to be able to replace on the fly are NOT in the class path (i.e. not listed in the value of the CLASSPATH environment variable and not in the current directory if "." is in class path). For example, you could move those COBOL programs to a new directory.

  2. (NOTE: This step is required only for isCOBOL 2009 SP2 and earlier) Make sure that the initial COBOL program class file is in a directory in the class path. The initial (main) COBOL program must be in the class path for the "java" executable or isCOBOL Server to be able to load it. If you need to be able to replace the main program on the fly then create a new main program with one CALL statement that calls the original main program. Make sure the new main program is in the class path and move the original main program to a directory that is not in the class path.

  3. Specify the directory(s) containing the COBOL programs in the iscobol.code_prefix property setting. See below for the format of this property. One way to do this is to start the isCOBOL Server with a properties file containing your iscobol.code_prefix setting. For example, when using isCOBOL 2010 R1 and later, if your COBOL programs are in/usr/app/programs/onthefly then create a file named containing the line iscobol.code_prefix=/usr/app/programs/onthefly and then start the isCOBOL Server with
    java ...

    Using isCOBOL 2009 SP2 and earlier, if your main COBOL program is in /usr/app/programs/main and your other COBOL programs are in/usr/app/programs/onthefly then create a file named containing the line iscobol.code_prefix=/usr/app/programs/onthefly and then start the isCOBOL Server with CLASSPATH=$CLASSPATH:/usr/app/programs/main; java ...

By default, the isCOBOL Server caches classes in memory and does not reload them from disk unless memory reserves are low. This was chosen as the default behavior in order to have best out-of-the-box performance on all platforms with all types and versions JVMs. 

Note that the IBM JVM has a Shared Classes feature that helps reduce memory footprint and improve startup performance. Read about it at

So on AIX you could achieve great performance AND the on-the-fly abilty by using iscobol.code_prefix together with the java options -Xshareclasses[:name= ] and -Xscmx [k|m|g]

From the isCOBOL APS User Guide Runtime Framework Properties section:


This property lists the paths in which programs are searched. Paths must be separated by the ďnĒ character sequence or by the current operating system path separator. If not set, the list set in CLASSPATH is used instead.

All classes stored in paths identified by code_prefix are loaded into memory each time they are called if the program cancels these classes from memory (see CANCEL STATEMENT ). Otherwise, programs loaded by CLASSPATH, are always stored in memory until the Runtime Framework terminates.
Authored by: Veryant Support This question has been viewed 7856 times so far.
Click Here to View all the questions in isCOBOL Server and Thin Client category.
File Attachments File Attachments
There are no attachment file(s) related to this question.
How helpful was this article to you?
User Comments User Comments Add Comment
There are no user comments for this question. Be the first to post a comment. Click Here
Related Questions Related Questions
  1. In thin client mode how do I run a local external application like the Windows Calculator or Microsoft Excel?
  2. How do I set up isCOBOL Server (Application Server) and Thin Client?
  3. How do I capture client side errors when using a different look and feel (e.g. Nimbus)?
  4. How do I use Java Web Start to automatically download and launch the thin client?
  5. How do I use secure transport (SSL) with the isCOBOL thin client?
  6. How do I avoid having to edit the Java security policy to allow isCOBOL thin client applet to connect?
  7. The COBOL program suddenly terminates on the server and leaves thin client running with a blank screen
  8. How can I get the system-information data from the client computer?
  9. How do I download files from server to client using isCOBOL Thin Client?
  10. What are the Java version requirements on the client and server? Do they need to match?
  11. How do I resolve the error 'Application Blocked by Java Security' working with jnlp?
  12. Is there a way to simulate users and load-test the thin client?
  13. The user name shown by the -panel is the PC Name. Is it possible have the user id of our application?
  14. How can I get the local username?
  15. Is there a way to distribute multiple client connections on different servers?
  16. What's the meaning of the error 'Software Incompatiblity'
Article Information Additional Information
Article Number: 48
Created: 2009-08-31 5:32 PM
Rating: 1 Star
Article Options Article Options
Print Question Print this Question
Email Question Email Question to Friend
Export to Adobe PDF Export to PDF File
Export to MS Word Export to MS Word
Bookmark Article
Subscribe to Article Subscribe to Article
Search Knowledge Base Search Knowledge Base


© Veryant - All Rights Reserved
Veryant and isCOBOL are trademarks or registered marks of Veryant in the United States and other countries. All other marks are the property of their respective owners.