Highlighted
Absent Member.
Absent Member.
5230 views

Acucobol to Visual Cobol

[Migrated content. Thread originally posted on 19 August 2011]

We are looking at the possibility of upgrading from Extend 9 to Visual Cobol. One of the questions I asked about compatibility was if I could take a very basic Acucobol batch processing program and simply recompile as is in Visual Cobol, but was told I could not, I would have to make amendments. If anyone on the forum has been through the exercise of converting from Extend to to Visual Cobol, I would be grateful to read your comments on the complexity (or ease) of the exercise. Also is an extensive (as against basic) knowledge of .NET required to fully utilize the advantages of Visual Cobol?
0 Likes
10 Replies
Highlighted
Absent Member.
Absent Member.

RE: Acucobol to Visual Cobol

I assume your batch program has minimal, if any, Acu GUI aspects, so it should compile, possibly with minimum changes. You also need to check if you have any ACU extensions that are not implemented in Visual COBOl.

Visual COBOL will compile to native code,(i.e. you can compile on the commmand line), so for the purpose of your exercise you do not need to compile through Visual Studio, but you would have to decide later about choosing .NET
or Java, if you need a GUI front-end.

Hope this helps.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Acucobol to Visual Cobol

Thanks very much for your comments. I was using the example of a very simple batch program, in the sense of 'if I cant even compile a simple batch program without amendments, what about the rest?'
In actual fact, most of the Acu programs are far more complex, making full use of just about every aspect of GUI, and also slightly out of the norm things like creating and modifying applications of Excel and Outlook using the CREATE, INQUIRE, MODIFY etc verbs, screens with side by side grids, independent of each other but linked logically, byte stream processing using things like CBL_OPEN_FILE, CBL_READ_FILE etc' I could go on forever with examples, but maybe I phrased my question wrongly. I really need to know two things.

1. I would really appreciate comments from anyone who has been through the conversion from Acu Extend to Visual Cobol, as to whether or not it was a complex process. Rightly or wrongly, I get the impression that Visual Cobol is more an extension of MF Cobol, so a MF Cobol user would have much less problems than an Acu Extend user.

2. Again, coming from anyone who has been through the exercise, is there adequate documentation on what is/is not supported, and what needs to be amended for complex Acu programs to compile and run under Visual Cobol?
0 Likes
Highlighted
New Member.

RE: Acucobol to Visual Cobol

Cat66;
We are in the same boat as you are, and are also looking for more detailed information on what exactly will work, and what will not. Our application makes extensive use of Acu GUI and C$/W$ calls. So far, we have not been able to get a detailed list of what is and is not supported, as well as what will and will not be supported in future releases.

-Chris
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Acucobol to Visual Cobol

cat66 and GMC,
I am sure that there are a lot more of us are wondering same thing like you guys. It seems like that MF would or could give us more guidelines as to how to migrate from Extend to VisualCobol. Because of lack of information, I am also looking into migrating to Fujitsu Cobol as well.

One of the advantages with Fujitsu is that there is no additional cost for deployment. No runtime charges! And it seems like they are more Acucobol friendlier than MF is.

Questions to cat66 and GMC:
Do you guys use Vision File system? If yes, would you be still use Vision if and when you migrate? I am thinking when I migrate I want to get away from any ISAM system and use Sql database. I wish there were a tool to convert the cobol FDs to somewhat normalized Sql tables.


0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Acucobol to Visual Cobol

Thank you all for your posts and for what is an important topic. Quite a few points have been raised so I would like to try to give you a response to each.

First of all, I read that there is concern about the amount of effort to upgrade to Visual COBOL. As well as others on the Forum here, you are not alone because Micro Focus can help. As well as simplifying the product install and configuration, Micro Focus’ Technical Services experts can help you plan and execute your upgrade. Additionally, plans are underway to build out a more comprehensive set of materials to help existing customers, no matter what their current product, upgrade to Visual COBOL, which means you can do more yourselves.

Second, there were a list of technical queries. While we cannot confirm every aspect without a detailed technical discussion about your current application characteristics, Micro Focus is aiming to ensure all clients can take forward existing applications into the new Visual COBOL environment. We welcome a detailed technical planning meeting to agree the upgrade strategy based on your particular application characteristics and requirements.

Let’s now tackle some of the technical questions that have been raised in this thread. I will enumerate them below.

1. “Is an extensive (as against basic) knowledge of .NET required to fully utilize the advantages of Visual Cobol?”

Certainly, if your objective is to modernize the application using technology available within .NET, a working knowledge of the .NET framework will serve you well but his doesn’t mean you need to become an expert in .NET overnight. Visual COBOL’s integration within Visual Studio 2010 and .NET should allow you to draw on skills within your organization that may not typically support COBOL applications. If C# or VB teams are actually involved in implementation, then SmartLinkage technology is one example that will allow these developers to support modernization efforts around core business functions written in COBOL.

2. Regarding ACUCOBOL-GT:
As noted, Visual COBOL does not support ACUCOBOL windowing syntax extensions nor ACUCOBOL Graphical Technology within R4.

In addition to documentation, we’re also investigating further technical solutions that will help move AcuGT to Visual COBOL, and further details will be made available at the earliest possibility.

3. Regarding details of compatibility for C$/W$ routines:
General information on Visual COBOL compatibility for ACU COBOL applications can be found here together with a list of runtime routines here. C$ runtime routines are currently available for native code applications only. To confirm, the CBL_ routines you have mentioned here are available in managed code.

4. Regarding data file access under Visual COBOL:

The Vision file system is supported for native Visual COBOL applications. For managed applications, there are 2 options:

a) Call out to a native program to perform file handling from the managed code application. This can be achieved using the PInvoke mechanism to call native programs from managed code, an example of this is included in the demos.

b) Alternatively, convert Vision data files to a Micro Focus format. Micro Focus will provide automated tooling to perform this conversion but this can be achieved manually today by unloading the data into a sequential file using ACU data file utilities and then using the Micro Focus rebuild utility to create the desired indexed format structure.

Another point noted is that the whole discussion suggests wanting to move to Visual COBOL, which of course is just fine. But what is the motivation to upgrade – is it the desire to move headlong into .NET, or something else? Your motivation to upgrade will shape how you get there and the time you take. Micro Focus continues to support Acu and have recently issued a further confirmation of this that takes your support out to 2016 at least. By providing commitment to our Acu customers on their existing technology, as well as providing further and further assistance to support upgrades to Visual COBOL, we hope to help support all our customer community.

Other vendor options were mentioned too – and of course you do have such choices. But our experience tells us that other vendors in the COBOL space fall short of the breadth and depth that Micro Focus provides. They don’t support all platforms, don’t have the same level of relationship with Microsoft (thereby affecting their .NET solution), do not have our level of compatibility, and cannot provide 24/7 global support. We believe our overall value in supporting your critical applications makes us unique.

A question back to this discussion thread to finish – would you value a “journey planner” document that helps you identify and plan for particular upgrade activities in your move to Visual COBOL? What would you like to see in particular? We’d love to hear from you directly via the Forum.

Thanks again for the question.

Scot Nielsen
Visual COBOL Product Manager
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Acucobol to Visual Cobol

0 Likes
Highlighted
New Member.

RE: Acucobol to Visual Cobol

Scot,
Thanks for your reply. At my company, our concerns boil down to this: The conversion process you describe would likely take us 2 to 4 years (we are a relatively small shop with 30 years of code). That means to us that the 5 year comittment by Microfocus requires us to take action sooner rather than later. We can not take a chance that we would end up with an unsupported platform, or that we would have to rush out a partially complete and buggy upgrade. If Visual COBOL won't provide support for AcuGT style screen handling and graphical technology, then it would only make sense for us to change our UI to something entirely different (HTML5?). It doesn't make sense to us to make changes that are tantamount to a total system rewrite, and NOT reevaluate the entire architecture.

I am not trying to make this sound too negative, but I AM trying to paint a clear picture of how our decision will be made. Our system is totally woven around Acu graphical interface and syntax, and if that is no longer supported, somewhere around 40-50% of our programs would need to be totally rewritten (these programs are designed to work with a DISPLAY/ACCEPT/validate/next-field type of functionality, with business logic totally woven into the screen handling code), with many (most?) of the others requiring partial re-coding to deal with their more basic UI needs. In the days of n-tiered software, web-accessibility, SAAS, etc, any significant change to the basic way our system works needs to be examined carefully before we continue on our current track.

I don't know how many other AcuGT customers have the screen handling logic as entwined in their programs as we do, but without support for Acu graphical technology, Visual COBOL is not a good option for our company.

-Chris
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Acucobol to Visual Cobol

Scot, my thanks also for the reply, but we would be in a very similar position to GMCfourX4. From my understanding of your reply we could also be in for a rewrite, thus management would definitely also consider other options, as in, 'if we have to rewrite anyway, we already use .NET/C# for other applications, so why bother buying Visual Cobol?' if you see what I mean.
In answer to UDSNet re Vision files, yes, we do use them extensively, but I am going to have a closer look at Acu SQL to see what that offers. I emphasize I havent looked at it at all yet, due to other priorities, so I only have a vague idea of its capabilities.
0 Likes
Highlighted
New Member.

RE: Acucobol to Visual Cobol

Scot,
Is there any additional information available relating to adding ACU-GT compatibility to Visual COBOL?

Thanks,
-Chris
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Acucobol to Visual Cobol

GMCfourX4 and cat66,

You may want to join the ACUCOBOL-GT Modernization group.   We have developed and are continuing to develop a tool which modernizes ACUCOBOL-GT into Visual COBOL.    Vision files, SQL Graphic Technology,  C$ are all issues which the tool addresses.

If you would like to join the group please send me, Larry.Hines@Microfocus.com, a note requesting access.

Thanks,

Larry

Larry Hines, PhD
Software Systems Developer, Sr. Principal
Micro Focus

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.