Have you looked at the Visual COBOL for Eclipse product in conjunction with DevHub? This would allow you to develop your application using the Eclipse IDE on Windows and allow you to connect to DevHub on your HP system to do remote development directly on the Unix box. Just a thought anyways...

If you are deploying as a 64-bit application then you should be compiling it and testing the application as 64-bit also. In some cases your application might require some code changes if redefining pointer data items, etc. There is a section that covers this in the docs here.

You shouldn't see any real degradation in performance when going to 64-bit.

Can you please provide more detail on where you are seeing a slow-down?

We're in a Microsoft C# .NET shop if you exclude the legacy cobol applications so Eclipse isn't really on the table. Visual Studio knowledge is high, and the possibility of teaching younger developers cobol is being considered. Having prior IDE knowledge seen as a big bonus obviously.

OK, nice to have confirmation that the thoughts about being 64-bit all the way is a valid decision as there can be situations where results can change even though a lot of the older legacy code probably won't be affected since the NE/SE combo has worked well enough.

We're looking at slow downs from a hardware perspective, even if all developer PC's meet requirements, and from a configuration, settings perspective. Hence the question about 32-bit vs 64-bit. Where we see clear differences between Net Express and Visual Cobol are

• Animate/Debugging start up times - if you put a breakpoint on the 1st executable line to match NE, VC is a lot slower reaching that first line of code to give you control
• Animate/Debugging run times - here we have seen things running 3-5 times faster in Net Express

It's also quite obvious that intellisense has problems with procob (Oracle precompiler). Developers getting "the visual cobol extension is running slowly do you want to uninstall it" isn't uncommon. We have filed incidents that have been fixed, but it's clear that this external precompiler isn't VC's best friend. But we're still looking to see clear patterns here, there seems to be a difference depending on how you code your embedded sql for instance.

But if this isn't influenced by if a project is 32 or 64-bit it's not really relevant for this question. We need to find clear examples where Visual Cobol struggle and file new incident reports.

Hi  

It's not clear whether you were comparing a 32-bit or 64-bit Net Express application with a 64-bit Visual Studio application. However,

If you have a 64-bit application then the debugger runs in pseudo-remote mode so a separate process is used to debug the application which has to communicate with the Visual Studio IDE so it will be slower than debugging 32-bit. The difference in performance that you have found is significant though so it is worth raising an incident to get that investigated further. Debugging a 64-bit application in Net Express will be doing largely the same.

In terms of getting to the initial statement, when you start debugging the project is checked to determine whether the outputs are up-to-date. For a project with a large number of source files that may take some time. You didn't mention which product version you are trying but if you are using 6.0 I would recommend installing the latest patch update ie update 2, as that includes a fix for a delay when starting debugging.

Gael

We do not build 64-bit applications with Net Express so it's strictly 32-bit. Then source code is moved to the HP-host and built with Server Express 64-bit.

When moving to Visual Cobol we felt that being 64-bit all the way was an advantage, but we're not so sure now considering performance hits plus other bugs. We have an open incident with watchpoints that only occur with 64-bit solutions, and we were just informed that this will be fixed in Visual Cobol 7, i.e. summer 2021.

At the moment it feels like mirroring the old set-up 32-bit in Net Express and 64-bit in Server Express is a better choice for Visual Cobol even if it means backtracking from the current solution. There does not seem to be anything on the plus side developing in 64-bit on windows at least for us.

Robert,

Thanks for the additional details.

The watchpoints issue you are having shouldn't need you to wait for 7.0. More news on that soon hopefully.

With regards to the performance issues, even if you are going to stay on 32-bit for your Windows development, it would still be really useful if you can raise an incident with an example of the enormous difference in performance between the two targets so that we can determine the cause.

Thanks.

Gael

,

In 6.0 patch update 3 which will be available later this month the watchpoint values will be displayed when debugging 64-bit.

As background, in versions of the product prior to 6.0, the values of data items in the watchpoints window were obtained by requesting the variables by from the debugger by name. However, if you had a watchpoint named X in Program1 and stepped into Program2 which also had a variable named X when the window updated its contents the value of X in Program2 was displayed. For 6.0, that was changed to show the actual watchpoint value but it did not work when debugging 64-bit which is the open incident that you mentioned. In patch update 3 the code for the watchpoints window has been updated so that if the new mechanism fails it reverts back to how it worked before so you will be able to see values until such time as the incident is fully resolved.

Gael