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

[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.

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.

[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.

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)

[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.

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,

[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,

Any solution for UTF-8?

Regards

[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.

The documentation for our Unicode support in COBOL can be found

Here:

[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.

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

[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.

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

[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.

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

[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.

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.

[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've been trying to install the following GUIs in Visual COBOL for Eclipse:

-Visual Editor (http://www.eclipse.org/vep/)
-Google Window Builder (code.google.com/.../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

[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.

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,

[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.

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

[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.

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?

[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.

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.

[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.

Renzo originally wrote:
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.

Hi Renzo,

I'm sure you've already heard this but there are significant differences in performance when compiling the code for debug vs. release. Also, Alex Turner has posted a great series of articles discussing the performance aspects of COBOL for JVM and benchmarking in general.

[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.

Hi Mark,

compiling with '$set noanim' gave me much better performance.

Thanks,

Renzo

[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.

Would like to see the 'type of build' (.EXE or .DLL) dropped down into the COBOL properties tab rather than at application tab level.

In NE5 I was able to develop code in the DEBUG build which could be built as either a .DLL OR a .EXE and likewise for the RELEASE BUILD.

This is not the case in VISCOBOL and must decide to have the code built as either a .DLL or a .EXE that builds in BOTH DEBUG & RELEASE modes upfront.

This means that I must have TWO independent solutions running (one for DEBUG builds and one for RELEASE builds) and, in turn, maintain TWO versions of the code. Not very clever!

[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.

Regarding Rmcobol compatibility, I see some differences between the Cobolwow designer and dot net Visual Cobol (managed windows application).

First when I double click on a control in Cobolwow, the editor pops open a drop-down listing all the events for that control. I can select the event to add and it is inserted into the form code. I don't see any easy way to insert events like that in Visual Cobol.

Also when I change the name of an existing control in Cobolwow, the event names (method id's?) for the control are automatically changed to match the new control name.

Also when I copy a control and paste it in Cobolwow, all of the coded events on the copied control are pasted with the new control.

These differences would affect my daily maintenance, debugging, and development significantly if we were to switch over from Cobolwow.

[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.

Hi Mar,

The Visual Studio designer is different from COBOL-WOW and offers a lot of flexibility. You can choose the event you want to handle in the Properties panel (usually down on the bottom right of the VS window). If you double-click on the event of interest, the editor window switches over to CBL code behind the control with the default handler template created and you just need to add the code to perform the work you need.

I'm not sure about the copy-paste scenario as I'm not really the expert but you should be able to do the same thing in that COBOL "code behind" the controls, just change the name of the object you want the code to apply to.

[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.

[quote]Mark S. originally wrote:
Would like to see the 'type of build' (.EXE or .DLL) dropped down into the COBOL properties tab rather than at application tab level.

Hi Mark, can you elaborate a little further on your requirement?

Is having different output types useful for being able to debug a COBOL program that would otherwise be built as a .dll or is there more to this?

Thanks[/quote]

[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.

Mark,
thanks for the shortcut to add control events: double click on the event name and the event method-id is inserted onto the form. Thats fine but I still need the other functionality cobolwow has if I want to maintain my current pace of maintenance and debugging.

first - in vc, take a form with a textbox and put code behind the gotfocus and lostfocus events. Now copy and paste that textbox to another textbox because you're tasked to add several textboxes to a form. Now insert the two events for the new control onto the form. Now go into the source and copy the code behind both events from the first textbox to the new textbox. Now do that again for the 3 or 4 other textboxes you need to add. I'm tired already just thinking about it. In cobolwow, I copy the textbox and paste it to a new textbox and all event code is automatically copied to the new control - I'm done.

the other issue, closely related: in vc take a control with gotfocus and lostfocus events and rename that control. The event names (method ids) are not renamed so you have to do it manually. If you don't do it you'll be creating confusion when you have a form with 20 or 30 controls on it and none of the event names match the control names. In cobolwow the event names are automatically renamed as soon as you rename the control.

I realize this functionality may not be desireable for everyone but it is how cobolwow works now. We rely on it heavily. With 2000 wow forms, many with dozens of controls on them, each control having at least two events, it would be a significant setback to our daily maintenance if we were to convert. Can you help?