What next?

[Migrated content. Thread originally posted on 18 January 2011]

Now that Visual COBOL R3 is out, we're working on the plans for the next updates. What would like to see us delivering next? I can't guarantee that we'll be able to implement everything you ask for but it will be good input to the process.

Let's focus here on the tooling and product features. There's a similar thread running over on the COBOL Language forum if you have thoughts on what to do next with the COBOL language.
  • Hello,

    I'll be glad with a full integration with RM/COBOL; indexed files format, DISPLAY level, C$ routines, etc.

    If we could import all the programs that we actually have with no changes, it will be great!

    Regards
  • Hi Mark,

    what voyager asks here is also want I want as soon as possible.
    If Visual Cobol is the only road RM/Cobol developers can use, then we need more support for RM/Cobol in Visual Cobol. RM/Cobol ISAM support is a must.

    And if we want to use Cobol JVM, then we need better performance.
    I have done some performance tests between RM/COBOL versions, native Visual Cobol and Cobol JVM ...
    The Cobol JVM version of my test program is very, very slow compared to the RM version.

  • A colleague asked me whether there exists a solution for creating Windows forms using COBOL type JVM in Eclipse.

    I think maybe we could use Qt4, but it would be interesting to know whether there are plans to integrate something like WOW in Visual COBOL.

    Another thing: right now I just remembered that the UTF-8 support for RM / COBOL was almost zero.

    We are currently working with Asian languages, and we had to develop specific routines to allow viewing and editing of these characters.

    (By the way, "receive notifications on replies" doesn't work)
  • While there is no supplied solution for creating Windows forms in Eclipse, when using the COBOL JVM support you should be able to access any third party tooling in the same way as you would from any Java program. The ability to be able to call Java classes from COBOL allows for any windowing framework to be used (SWT, AWT, Swing etc) and there are several widely available painters for these technologies already. Creating our own version of something that already exists probably isn't the best way forward.

    Personally, I'd always reccommend separating the presentation code from the business logic - it's much easier to then update when the underlying OS is changed than relying on a proprietary GUI framework. I do realise that is an awfully lot easier said than done though!

    As far as Qt goes, it's not a framework I've had much experience of. As I understand it is written in C but has Java (and lots of others) language bindings. If I were to look at using this, I'd probably write my UI in Java utilising the QT bindings and then make the calls from my COBOL application (compiled to JVM) into the Java, perhaps with a thin layer of OO COBOL code. Interesting thoughts though.

    With respect to benchmarking of JVM COBOL - remember that this version is an EAP and that Java byte code is a managed language. I'd be interested in exactly what is so slow though - any more details? Our initial investigations suggest that the raw JVM performance is not significantly slower than native code. Is filehandling involved in your test program?

    Regards,
  • The documentation for our Unicode support in COBOL can be found

    Here:
  • Hi Darren,

    about Cobol JVM performance.
    All i did was compare the following :

    DISPLAY "BEGIN".
    PERFORM GET-TIMESTAMP.
    PERFORM VARYING TEL FROM 1 BY 1 UNTIL TEL = 999999999
    CONTINUE
    END-PERFORM.
    DISPLAY "EINDE".
    PERFORM GET-TIMESTAMP.

    GET-TIMESTAMP.
    ACCEPT WS-TS-DATE FROM CENTURY-DATE.
    ACCEPT WS-TS-TIME FROM TIME.
    DISPLAY WS-TS-DATE.
    DISPLAY WS-TS-TIME.

    Regards,

    Renzo
  • Could you also give us the working-storage definitions too, as this can affect performance too (aka COBOL v native JVM types etc..)
  • This is the working storage :

    01 WS-TS-DATE PIC 9(8).
    01 WS-TS-TIME PIC 9(8).
    01 TEL PIC 9(10).

    Regards,

    Renzo
  • Hi Voyager & Renzo,

    RM COBOL compatibility will be a key feature of the "R4" release. We're working on adding the RM file handler and other features to make it easy to move RM COBOL apps to Visual COBOL. We may not get everything, especially all the C$ runtime routines but we're focusing on the ones that have most impact or are not easily replaced by the Visual COBOL CBL_ calls. R4 is intended for release in Q2.