Skip to main content

[archive] Java Cobol calls with CVM too slow

  • August 29, 2006
  • 8 replies
  • 0 views
D

[Migrated content. Thread originally posted on 28 August 2006]

Hi,

I have got the wonderful task to create a Java program that has to access to contents in our Cobol Vision files via a client server connection.

To do that I created a vision file access object factory object in Java that is kept in an RMI container on the server. The container also includes a CVM object. Both objects are instanciated only one time when the RMI container starts up and remain there until I shut down the RMI container.

Every time I need generic access to the vision files on the server the client sends a request to the file access class factory which creates an access object for the matching file on the server. It is kept there as long as the Java program uses it. All access mechanisms to the vision files are done with I$IO calls.

Running that sort of "rich client - server" combination I came to the following unsatisfying results:

1. The access is very slow. It takes more than two minutes to read 4000 records.

2. The amount of data that gets processed varies from 400 to 900 records before my RMI access mechanism comes back with an odd error message. I couldn't figure out the reasons why this happens for there is almost no information about it.

I already tried several solutions to tune the access to the files and I am getting pretty desperate about the thing.

I have got the feeling that the CVM object causes some memory violation issues while it is bound into the RMI container. Also the cobol wrapping and the access mechanisms seem to be very slow.

Is there anybody who has made similar experiences? I would really appreciate some support if there is any,

Chefdecuisine

    8 replies

    D

    [Migrated content. Thread originally posted on 28 August 2006]

    Hi,

    I have got the wonderful task to create a Java program that has to access to contents in our Cobol Vision files via a client server connection.

    To do that I created a vision file access object factory object in Java that is kept in an RMI container on the server. The container also includes a CVM object. Both objects are instanciated only one time when the RMI container starts up and remain there until I shut down the RMI container.

    Every time I need generic access to the vision files on the server the client sends a request to the file access class factory which creates an access object for the matching file on the server. It is kept there as long as the Java program uses it. All access mechanisms to the vision files are done with I$IO calls.

    Running that sort of "rich client - server" combination I came to the following unsatisfying results:

    1. The access is very slow. It takes more than two minutes to read 4000 records.

    2. The amount of data that gets processed varies from 400 to 900 records before my RMI access mechanism comes back with an odd error message. I couldn't figure out the reasons why this happens for there is almost no information about it.

    I already tried several solutions to tune the access to the files and I am getting pretty desperate about the thing.

    I have got the feeling that the CVM object causes some memory violation issues while it is bound into the RMI container. Also the cobol wrapping and the access mechanisms seem to be very slow.

    Is there anybody who has made similar experiences? I would really appreciate some support if there is any,

    Chefdecuisine
    We've got a COBOL developer under 35 as well... but I agree you're in a very small demographic :)
    D

    [Migrated content. Thread originally posted on 28 August 2006]

    Hi,

    I have got the wonderful task to create a Java program that has to access to contents in our Cobol Vision files via a client server connection.

    To do that I created a vision file access object factory object in Java that is kept in an RMI container on the server. The container also includes a CVM object. Both objects are instanciated only one time when the RMI container starts up and remain there until I shut down the RMI container.

    Every time I need generic access to the vision files on the server the client sends a request to the file access class factory which creates an access object for the matching file on the server. It is kept there as long as the Java program uses it. All access mechanisms to the vision files are done with I$IO calls.

    Running that sort of "rich client - server" combination I came to the following unsatisfying results:

    1. The access is very slow. It takes more than two minutes to read 4000 records.

    2. The amount of data that gets processed varies from 400 to 900 records before my RMI access mechanism comes back with an odd error message. I couldn't figure out the reasons why this happens for there is almost no information about it.

    I already tried several solutions to tune the access to the files and I am getting pretty desperate about the thing.

    I have got the feeling that the CVM object causes some memory violation issues while it is bound into the RMI container. Also the cobol wrapping and the access mechanisms seem to be very slow.

    Is there anybody who has made similar experiences? I would really appreciate some support if there is any,

    Chefdecuisine
    Hi,

    1. The access is very slow. It takes more than two minutes to read 4000 records.
    Chefdecuisine


    I am not surprised by your numbers, but then, the CVM was never designed to be pumping large amounts of data back and forth in a sequential pattern, let alone be used as a file interface.
    The CVM is an API to execute a COBOL application, it will never be a good alternative for accessing data. Sorry, but that is just not what it was made for.

    I assume you do not open and close the file for each file access, but open once and leave them open for the lifetime of the object? If not, you certainly have a potential for improvements there. Opening a file is a rather expensive operation performancewise.
    D

    [Migrated content. Thread originally posted on 28 August 2006]

    Hi,

    I have got the wonderful task to create a Java program that has to access to contents in our Cobol Vision files via a client server connection.

    To do that I created a vision file access object factory object in Java that is kept in an RMI container on the server. The container also includes a CVM object. Both objects are instanciated only one time when the RMI container starts up and remain there until I shut down the RMI container.

    Every time I need generic access to the vision files on the server the client sends a request to the file access class factory which creates an access object for the matching file on the server. It is kept there as long as the Java program uses it. All access mechanisms to the vision files are done with I$IO calls.

    Running that sort of "rich client - server" combination I came to the following unsatisfying results:

    1. The access is very slow. It takes more than two minutes to read 4000 records.

    2. The amount of data that gets processed varies from 400 to 900 records before my RMI access mechanism comes back with an odd error message. I couldn't figure out the reasons why this happens for there is almost no information about it.

    I already tried several solutions to tune the access to the files and I am getting pretty desperate about the thing.

    I have got the feeling that the CVM object causes some memory violation issues while it is bound into the RMI container. Also the cobol wrapping and the access mechanisms seem to be very slow.

    Is there anybody who has made similar experiences? I would really appreciate some support if there is any,

    Chefdecuisine
    No, I do not open and close them each time I read a record. I access to the data in the usual way:

    1. open
    2. start
    3. read next until certain criteria reached
    4. close

    Ok, I understand that the CVM wasn't designed for heavy duty file access and I could live with that if there wouldn't be that exception mentioned in point 2 in my post. I get an exception after a certain amount of processes. The RMI connection works fine as long as I don't include a CVM object. If I include it the program terminates after a varying time span. That even happens if I don't use the CVM for any operations.

    The message I get is:

    java.rmi.UnmarshalException: Error unmarshaling return header; nested exception is:
    java.io.EOFException
    at sun.rmi.transport.StreamRemoteCall.executeCall(Unknown Source)
    at sun.rmi.server.UnicastRef.invoke(Unknown Source)
    at RMIObjects.UWRMITestObject_Stub.doSomething(Unknown Source)
    at labelDisplay.UWLabelEditorGUI.(UWLabelEditorGUI.java:308)
    at mainClient.UWLabelEditor.main(UWLabelEditor.java:26)
    Caused by: java.io.EOFException
    at java.io.DataInputStream.readByte(Unknown Source)
    ... 5 more
    D

    [Migrated content. Thread originally posted on 28 August 2006]

    Hi,

    I have got the wonderful task to create a Java program that has to access to contents in our Cobol Vision files via a client server connection.

    To do that I created a vision file access object factory object in Java that is kept in an RMI container on the server. The container also includes a CVM object. Both objects are instanciated only one time when the RMI container starts up and remain there until I shut down the RMI container.

    Every time I need generic access to the vision files on the server the client sends a request to the file access class factory which creates an access object for the matching file on the server. It is kept there as long as the Java program uses it. All access mechanisms to the vision files are done with I$IO calls.

    Running that sort of "rich client - server" combination I came to the following unsatisfying results:

    1. The access is very slow. It takes more than two minutes to read 4000 records.

    2. The amount of data that gets processed varies from 400 to 900 records before my RMI access mechanism comes back with an odd error message. I couldn't figure out the reasons why this happens for there is almost no information about it.

    I already tried several solutions to tune the access to the files and I am getting pretty desperate about the thing.

    I have got the feeling that the CVM object causes some memory violation issues while it is bound into the RMI container. Also the cobol wrapping and the access mechanisms seem to be very slow.

    Is there anybody who has made similar experiences? I would really appreciate some support if there is any,

    Chefdecuisine
    I could live with that if there wouldn't be that exception mentioned in point 2 in my post.


    You seem to have this easily reproduceable at a reasonable scale, so I would suggest you take this to tech support with example code and data. Chances are this is known stuff that is fixed and they might even have a workaround for you.
    D

    [Migrated content. Thread originally posted on 28 August 2006]

    Hi,

    I have got the wonderful task to create a Java program that has to access to contents in our Cobol Vision files via a client server connection.

    To do that I created a vision file access object factory object in Java that is kept in an RMI container on the server. The container also includes a CVM object. Both objects are instanciated only one time when the RMI container starts up and remain there until I shut down the RMI container.

    Every time I need generic access to the vision files on the server the client sends a request to the file access class factory which creates an access object for the matching file on the server. It is kept there as long as the Java program uses it. All access mechanisms to the vision files are done with I$IO calls.

    Running that sort of "rich client - server" combination I came to the following unsatisfying results:

    1. The access is very slow. It takes more than two minutes to read 4000 records.

    2. The amount of data that gets processed varies from 400 to 900 records before my RMI access mechanism comes back with an odd error message. I couldn't figure out the reasons why this happens for there is almost no information about it.

    I already tried several solutions to tune the access to the files and I am getting pretty desperate about the thing.

    I have got the feeling that the CVM object causes some memory violation issues while it is bound into the RMI container. Also the cobol wrapping and the access mechanisms seem to be very slow.

    Is there anybody who has made similar experiences? I would really appreciate some support if there is any,

    Chefdecuisine
    I'm under 35 too...
    D

    [Migrated content. Thread originally posted on 28 August 2006]

    Hi,

    I have got the wonderful task to create a Java program that has to access to contents in our Cobol Vision files via a client server connection.

    To do that I created a vision file access object factory object in Java that is kept in an RMI container on the server. The container also includes a CVM object. Both objects are instanciated only one time when the RMI container starts up and remain there until I shut down the RMI container.

    Every time I need generic access to the vision files on the server the client sends a request to the file access class factory which creates an access object for the matching file on the server. It is kept there as long as the Java program uses it. All access mechanisms to the vision files are done with I$IO calls.

    Running that sort of "rich client - server" combination I came to the following unsatisfying results:

    1. The access is very slow. It takes more than two minutes to read 4000 records.

    2. The amount of data that gets processed varies from 400 to 900 records before my RMI access mechanism comes back with an odd error message. I couldn't figure out the reasons why this happens for there is almost no information about it.

    I already tried several solutions to tune the access to the files and I am getting pretty desperate about the thing.

    I have got the feeling that the CVM object causes some memory violation issues while it is bound into the RMI container. Also the cobol wrapping and the access mechanisms seem to be very slow.

    Is there anybody who has made similar experiences? I would really appreciate some support if there is any,

    Chefdecuisine
    Ok! I give in. I already changed the profile. So no more complains s'il vous plait. ;)
    D

    [Migrated content. Thread originally posted on 28 August 2006]

    Hi,

    I have got the wonderful task to create a Java program that has to access to contents in our Cobol Vision files via a client server connection.

    To do that I created a vision file access object factory object in Java that is kept in an RMI container on the server. The container also includes a CVM object. Both objects are instanciated only one time when the RMI container starts up and remain there until I shut down the RMI container.

    Every time I need generic access to the vision files on the server the client sends a request to the file access class factory which creates an access object for the matching file on the server. It is kept there as long as the Java program uses it. All access mechanisms to the vision files are done with I$IO calls.

    Running that sort of "rich client - server" combination I came to the following unsatisfying results:

    1. The access is very slow. It takes more than two minutes to read 4000 records.

    2. The amount of data that gets processed varies from 400 to 900 records before my RMI access mechanism comes back with an odd error message. I couldn't figure out the reasons why this happens for there is almost no information about it.

    I already tried several solutions to tune the access to the files and I am getting pretty desperate about the thing.

    I have got the feeling that the CVM object causes some memory violation issues while it is bound into the RMI container. Also the cobol wrapping and the access mechanisms seem to be very slow.

    Is there anybody who has made similar experiences? I would really appreciate some support if there is any,

    Chefdecuisine
    I just wanted to make sure you didn't feel alone... :)

    I liked it...
    D

    [Migrated content. Thread originally posted on 28 August 2006]

    Hi,

    I have got the wonderful task to create a Java program that has to access to contents in our Cobol Vision files via a client server connection.

    To do that I created a vision file access object factory object in Java that is kept in an RMI container on the server. The container also includes a CVM object. Both objects are instanciated only one time when the RMI container starts up and remain there until I shut down the RMI container.

    Every time I need generic access to the vision files on the server the client sends a request to the file access class factory which creates an access object for the matching file on the server. It is kept there as long as the Java program uses it. All access mechanisms to the vision files are done with I$IO calls.

    Running that sort of "rich client - server" combination I came to the following unsatisfying results:

    1. The access is very slow. It takes more than two minutes to read 4000 records.

    2. The amount of data that gets processed varies from 400 to 900 records before my RMI access mechanism comes back with an odd error message. I couldn't figure out the reasons why this happens for there is almost no information about it.

    I already tried several solutions to tune the access to the files and I am getting pretty desperate about the thing.

    I have got the feeling that the CVM object causes some memory violation issues while it is bound into the RMI container. Also the cobol wrapping and the access mechanisms seem to be very slow.

    Is there anybody who has made similar experiences? I would really appreciate some support if there is any,

    Chefdecuisine
    No-one was complaining :)

    Someone has to hold the fort when us old-buggers shuffle off this mortal coil...

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement