Changing runtime from Acucorp to ..???

[dingus23]

We need to change runtime environment mainly due to significant raise in prices from Acucorp.
Short description of our application:

Vision file system
Screen painter
Platform independent
Runs in Citrix/unix environment


Do anyone have experience in how to change runtime compiler with as little work with proprietary code as possible? Are there any translators that would make the transition less painful?
Which compiler would yoy recommend in terms of price and flexibility with acucorp's?

I have been looking at OpenCobol but has recently been released so I fear it might be too young and unfinished..

Answers will be greatly appreciated!

Ole

 

[TonHu]

OpenCobol is already rather old, but only fairly recent it has reached a more mature phase, by going to a 1.x release.

3 years ago we tried to parallel develop a 'better' version of OC (windows-capable (borland C++), less bugs/undesired behaveour, better MF compliant), but management pulled the plug because of the 'vendor lock-in' that it would place on the internal R&D dep. and other dependencies they didn't want to get bound by.

We're still on MF, and are trying to phase out all Cobol apps, but that is going to take some years ;-)

HTH
TonHu

 

[Truusvlugindewind]

MF/acu is/are the best but come with a price...
Look at you sources, re-compile with the ANSI-85 switch active. Count the errors and blame yourself

As long as you code ANSI-85-compliant cobol you can consider Open- or Tiny Cobol. If you used a lot of "extra features" it can become cumbersome and porting work has to be done.
So calculate the costs of porting v.s. the licence fees of MF/acu.

 

[3gm]

You're facing a tough problem.

There are limited options that work in both Citrix and Unix AND you have to replace the indexed file access (Vision) in both environments. The screen painter is also proprietary AFAIK. AcuCOBOL is the only product I've used where you can truly compile on one platform and run on another without a recompile.

I'll also bet you've taken advantage of lots of other AcuCOBOL extensions (non-ANSI-85) as the prior poster points out. Those are going to be a bear to replace (and do so in a platform independent way to boot).

Your senior management is going to have to figure out the long-term financial costs of a significant re-write (in some other flavor of COBOL or even a different language) versus paying Microfocus' license prices (and whatever price increases they decide to implement in coming years).

Good luck!

Glenn

 

[dingus23]

Thanks, these answers saved me a lot of research.
Yes, quite clearly this is a RUI issue. our deleopers estimated the job to 3 years so I really doubt this project will be executed.

 

[Truusvlugindewind]

I worked both with MF and ACU in the past. Now that the've assimilated you could speak that MF has a monopoly position. The've never been cheap, but affordable. Has that changed dramatically now? It would be a shame: I've always advised people in that direction...

b.t.w. IBM still sells COBOL on P and I series. Doesn't have be a mainframe you know.

 

[dingus23]

Yes it has changed dramatically. They have multiplied our prices by 5! We've had a very good deal until now but I have spoken to others who have had a x3, x4 increase..

Needless to say, we look at all options to avoid being dependent on them anymore. A total regeneration is the only way I'm afraid..

 

[webrabbit]

I have an old (DOS based) system written in Micro Focus COBOL. I want to upgrade it to Windows, but the MF runtime license fees are exhorbitant, many hundreds of times what I charge for my system. I am switching to R/M COBOL, since that is more comaptible at the low level. R/M (Liant) runtime license fees are reasonable. Fujitsu has no runtime license fees.