Mark_Warren Absent Member.
Absent Member.
7146 views

What next?

Jump to solution

[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.
0 Likes
1 Solution

Accepted Solutions
Mark_Warren Absent Member.
Absent Member.

RE: What next?

Jump to solution
Hi Amy,

The answer is really "it depends" (isn't it always!). Bob England has shown that RM COBOL apps using WOW can be converted to Visual COBOL very successfully with R3. If some RM features, for example, XML extensions or some runtime calls are critical to the app, then you are better off waiting for R4 but you may still want to try R3 to start becoming familiar with the environment.
0 Likes
22 Replies
voyager Absent Member.
Absent Member.

RE: What next?

Jump to solution
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
0 Likes
Renzo Absent Member.
Absent Member.

RE: What next?

Jump to solution
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.

0 Likes
voyager Absent Member.
Absent Member.

RE: What next?

Jump to solution
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)
0 Likes
Micro Focus Expert
Micro Focus Expert

RE: What next?

Jump to solution
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,
0 Likes
voyager Absent Member.
Absent Member.

RE: What next?

Jump to solution
Hello,

Any solution for UTF-8?

Regards
0 Likes
Micro Focus Expert
Micro Focus Expert

RE: What next?

Jump to solution
The documentation for our Unicode support in COBOL can be found

Here:
0 Likes
Renzo Absent Member.
Absent Member.

RE: What next?

Jump to solution
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
0 Likes
Micro Focus Expert
Micro Focus Expert

RE: What next?

Jump to solution
Could you also give us the working-storage definitions too, as this can affect performance too (aka COBOL v native JVM types etc..)
0 Likes
Renzo Absent Member.
Absent Member.

RE: What next?

Jump to solution
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
0 Likes
Mark_Warren Absent Member.
Absent Member.

RE: What next?

Jump to solution
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.
0 Likes
voyager Absent Member.
Absent Member.

RE: What next?

Jump to solution
Hello,

I've been trying to install the following GUIs in Visual COBOL for Eclipse:

-Visual Editor (http://www.eclipse.org/vep/)
-Google Window Builder (http://code.google.com/intl/es/javadevtools/download-wbpro.html)

...but the installation procedure was not working properly for them.

It would be a great thing be able to integrate these tools within the IDE.

Regards
0 Likes
Micro Focus Expert
Micro Focus Expert

RE: What next?

Jump to solution
Hi Renzo,
I agree that the JVM version is a lot slower than native in your example. The problem I have with it though is that the example program is basically testing a NO OP being run tens of millions of times. I know that our generator team will have optimised any code construct similar to this which is probabaly why it is so much faster than the JVM version.

I'm not going to dispute that there will be times where the code generated for JVM will be slower than that generated for native code. However, we are not comparing like with like here. JVM code is run on a managed platform whereas a native executable is not.
I made a couple of changes to the code so that it was performing a simple arithmetical operation (repeatedly adding numbers). That gave a rough figure of JVM being eight times slower than the native exe. I then compiled the COBOL code to INT (the tried and trusted Micro Focus Intermediate code format which runs under our abstract machine) and found that JVM was now running about 20% faster.

I fully agree that we do need to devise and publish some benchmarks though. They are important but we also need to ensure that we are testing a representative sample of language constructs in a meaningful way. Whatever results come out, you can be sure we want to offer the best possible experience and generate the fastest code we can.

Regards,
0 Likes
Chris Whitty Absent Member.
Absent Member.

RE: What next?

Jump to solution
Hi voyager

The window builder plugin seems to require that Eclipse PDE is installed which we do not include in the version of Eclipse that we ship with our installer. If this is your problem then the easiest way to resolve it would probably be for you to download the Eclipse Classic version from here and then install both our update site and the window builder one into that.

With regards to the Visual Editor update site, on the Install new Software window, there is a check box labeled: "contact all update sites during install to find required software", do you have this enabled? If not then enable it and it should then resolve any dependency issues you may be having (You may need an internet connection at the time).

Let me know if this works for you or if you are seeing a different problem.
Regards
0 Likes
AmyM1 Super Contributor.
Super Contributor.

RE: What next?

Jump to solution
Mark Warren originally wrote:
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.


So what you are saying is that maybe I should wait until R4 is released before I go and purchase Bob England's COBOL WOW to Visual COBOL conversion tool? Or, are you just talking about the RM/COBOL language?
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.