Thanks to all those for attending the Visual COBOL webinar on Thursday. Here's the Q & A transcript from the webinar:

Q: I’m currently using Object COBOL on Server Express in a Linux environment. We use a main menu program and then via linkage call in up to 1000 other programs. All is good except that still limited to 80 char line displays @ 24 rows and want to break out.

A: Visual COBOL character applications can use more than the standard 80 cols by 24 rows, see our ACCEPT/DISPLAY documentation for more details.

If you really want to breakout, then it’s time to switch to a more graphical presentation. As Mike demonstrated on the webinar, .NET has some great options for you. Amongst other things, the effort involved will depend upon how many screens you have, how coupled the business logic is to the user interface and whether you want web or thick client access to the application.

Good news is, we can help assess and advise. If you want to know more, please contact me directly: scot.nielsen@microfocus.com

Q. I make heavy use of collections, sorted collection, dictionary’s & character arrays. I have object references that for my linkage. What does this mean for me? How do I move them to managed code? And recode 2000 programs?

A: If you’re moving from native OO programs to .Net, you will certainly need to review which classes in the base class library routines you’re using today, these aren’t supported under .NET as you’ll need to find equivalents.

One way forward here is to write some new classes with the same names as the native OO classes and wrap .NET classes that do the same thing.
If you can tell us your most used classes, we can help get you started?

Q. What path should I invoke to quickly educate procedural COBOL to object oriented?

A: We provide web based training to help developers get started with the new IDE and which also covers OO basics:
www.microfocus.com/.../

Besides this, the principles behind any good Java or C# OO training will be equally applicable to COBOL.

Moving to .NET and JVM is a great way to enhance existing COBOL applications but COBOL developers can continue to write procedural code on the platforms. It is really only where COBOL interfaces with OO systems that the need for OO becomes necessary. This part of the application can be written by any developer skilled in OO programming.

Q: Are there any other methods for database connections to be shared aside from sql server stored procedures?

A: When using embedded SQL within a COBOL program, you can use the SET CONNECTION statement or when using ADO, BIND CONNECTION.