RM/COBOL vs FUJITSU = ? 3

[theotyflos]

Hi all,
I'm looking for opinions from anyone who has experience with both products/companies. Can anyone tell me about the differences between them and especially about the advantages and the disadvantages of each product compared to the other?

I'm curently using RM/COBOL 7 on unix, 7.50 + COBOL-WOW 3.12 on windows but looking to move to Fujitsu due to: a)lack of support from Liant and b)bugs in WOW.

Recently I went to fujitsu's page, read about Power Cobol and Net Cobol and found them interesting.

Any thoughts are welcome.

TIA.

 

[etom]

I have never used RM/Cobol but I do use PowerCobol (Cobol for Windows). My support from Fujitsu has been excelant but watch out for their licensing process. It can be tricky if you do not follow the directions. On initial installation it is only active for 30 days. You must then receive you activication code via e-mail. Once activated, if anything happens to your PC and you have to re-install, it requires a call to Fujitsu, an explaination as to why you need a new activation code. My PC crashed twice in one month. They had no problem is giving me new activation codes however, I did get a follow up phone call from them to further inquire on what my problems were.

The good side of licensing, there is a process to transfer your license from one machine to another. I have also found a good image backup of your whole system will restore with license intact.

I have found the product easy to learn and use for an old Mainframe programer like me (however I already had C++ experience). All the tools appear to be there.

If you really want to see it in action, you can download a trial version good for 30 days from their website. DO NOT DOWNLOAD THE STUDENT VERSION (VERSION 3). That version does not look anything like the current version.

I have not used the .NET version of their system yet so, I can not speak for that version. Hopefully someone out there can help on the comparison.

etom

 

[theotyflos]

Thanks for the answer etom,
I tried to download the trial version, but it seems that they don't allow getright to do the job, so i canceled it.
BTW, do you know what's the difference between netcobol and powercobol? What about stability? Did you encounter any crashes?

theotyflos.

 

[k5tm]

theotyflos,

There seems to be a communications problem...

You don't say what 'brand' of Unix, but the current version of RM/COBOL is version 8 on Unix and Windows and the current version of COBOL-WOW is version 4. There have been significant additions to the capabilities of COBOL-WOW since version 3.12.

The Unix ports of RM/COBOL support thin client WOW. Liant continues to add capabilities to COBOL-WOW to help our developer community keep modern-looking applications in front of their customers.

Tom Morrison

http://www.liant.com

 

[fredericofonseca]

theotyflos,

If you are thinking of converting to Fujitsu then you will have loads of problems.

First of all their Unix support is limited to
Solaris, HP-UX and Linux
If working with Linux not all features are available, mainly on what concerns to screen handling.

Be very careful on such a move.

Powercobol is the GUI development bit of Fujitsu COBOL. It is acceptable, but as you go from WOW you will find it very very different.

If you have previous experience with RM/PANELS I would advise the use of SP2 from

http://www.flexus.com

instead of Powercobol (and it also works with RM!!).

Regarding RM.
COBOL wow 4.x has a lot of improvements over the version you have, and you may consider having a look at it, especially it's thin client.

Regarding lack of support, there not much I can do there unless you buy from Portugal.
If you have specific issues regarding the lack of support then Tom is the person to speak with.

Regarding support from Fujitsu they can be very slow, and they will not help you unless your problem is really a BUG, and not just something you would like to know how to do.
There are loads of omissions on their documentation, and it is sometimes exasperating to try and find how to do something specially if it deals with objects (COM mainly).

All in all and depending on what type of problems you have with RM, and on what is your company idea for the future you may be better off by sticking with RM (and eventually change to SP2 if your problems are mainly/only from WOW).






Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[WMK]

Some thoughts and information (from a RELATIVELY unbiased COBOL observer):

Re Fujitsu:
- "NetCOBOL" is the "new" generic name for Fujitsu's product line. Don't confuse
NetCOBOL for Windows with
NetCOBOL for .NET

- Fujitsu's products have FULL support for the '85 Standard *plus* the intrinsic functions module (not yet supported by RM). In addition they have LOTS of support for many of the features from the 2002 ISO Standard (most particularly new OO support)

- If it is of interest to you, Fujitsu CLAIMS to have fairly good IBM mainframe COBOL compatibility (and to "keep this current&quot. In fact, IMHO, their IBM compatibility is not nearly as good as either Micro Focus or Realia - but is PROBABLY better than RM.

- Fujitsu had a MAJOR change in their support process and resources last year. From comments in CLC, it is my IMPRESSION that you will find "current" Fujitsu support to be SIGNIFICANTLY weaker than that from RM.

- Historically,(cut I don't know if this is still true) Fujtisu has had "easier" inter-language support for mixed C (or C++) and COBOL. In some cases, this may be important for Unix customers.

***

Re RM:

- RM has ALWAYS had a reputation for being a leader in "portability" (i.e. what works on one of their platforms, works the SAME on all platforms where their products are available)

- From reports in comp.lang.cobol, their support is among the best (including both "work-arounds" and bug fixes).

- RM has "fewer" extensions, so what works with RM (today) is most likely to work with other COBOL vendors - should you need/want to port to another compiler/environmentin the future.

- My imporessions is that MUCH of Fujtisu's development (not all) is being targetted to Microsoft .NET environment. Therefore, if you are looking for a Unix-like environment and FUTURE, RM may well be a better choice.

***

NOTE WELL:
I have not produced "production" code with either the Fujitsu or the RM products. Therefore, much of what I say in this note may not be current or reflect the impressions from either vendor's current customers.

Bill Klein

 

[k5tm]

Bill writes:
- Historically,(cut I don't know if this is still true) Fujtisu has had "easier" inter-language support for mixed C (or C++) and COBOL. In some cases, this may be important for Unix customers.

Agreed, but it is truly history now.

The CodeBridge part of RM/COBOL Developer package makes it reasonably easy to call modules coded in C with automatic type conversion between COBOL and C data types.

Also, after a Titanic Struggle With History you will now find COMP-5 in recent versions of RM/COBOL. COBOL General Discussion's own fredericofonseca was a very significant beta tester for COMP-5 producing a an RM/COBOL version of his Oracle OCI interface (

http://www.syssoft-int.com/who_we_are.htm).

(Thank you, Frederico!).

Tom Morrison

http://www.liant.com

 

[Truusvlugindewind]

IF nobody mentioning Micro Focus OR ACUcobol
THEN I will.

They both offer a very nice Windows IDE to develop your programs which will run very well on all kinds of unix/linux machines. Especially the GUI-support of ACU (*nic server --> thin-client on windows) has made quite an impression on me. And the XML integration: wow! I feel Acucorp is pushing cobol further.

The intergration Net Express (windows) Server Express (unix) of Micro Focus is also very powerfull.

 

[WMK]

I would be happy to "add" additional comments on AcuBOBOL and/or Micro Focus products. HOWEVER, I assumed that they were being "ignored" because of run-time licensing issues.

One might also look at IBM's products for the workstation.

Bill Klein

 

[theotyflos]

To Tom Morrison:

What do you mean by "communications problem"?

Unix is Sco Openserver v5.0.5,6,7. Windows 98,2k,XP.

By what I read in liant's site, the (MAJOR FROM MY POINT OF VIEW) differences between v8 and the previous versions are: comp-5 support, expression concatenation and empty groups. Still no functions, no OO, no multithreading. I wonder if these enhancements worth bying v8.

Theophilos Kanoutas.

 

[theotyflos]

To Truusvlugindewind:
I agree that ACU is fine (never saw MF), but also agree with Bill Klein about the run-time licensing.

Theophilos Kanoutas.

 

[Truusvlugindewind]

Okay, when money is an issue why do not we all become active on the COBOL Open Source initiatives?

http://open-cobol.sourceforge.net/

http://tiny-cobol.sourceforge.net/

I feel a bit guilty that I do not spend time to support those initiatives and when I have time I will .....

How do you all feel?

 

[Dimandja]

Truus,

I totally agree with you: we (COBOL professionals) need to support the Open COBOL initiative. Who else will?

It is my opinion that the high prices of COBOL compilers and the murky licensing issues are effectively contributing to the eventual demise of this great language.

New programmers would rather find a free and good compiler to hone their skills, than shell out $3,000 for a first effort. It makes sense.

I know vendors need to make money. A reasonably priced COBOL compiler will outsell anything out there today (C++ and Visual Basic for example).

Picture this: when I needed a compiler for my PC at home, I considered all the COBOL compilers mentioned above, but went for Standard Visual Basic. It was cheap ($100) and it would do windows, plus it has full access to Windows APIs and the .NET Framework. I liked it so much that I migrated to the full .NET enchilada: Visual Studio.NET.

This means that my next most likely COBOL compiler will be the one that can live fruitfully with .NET, such as NetCobol for .NET - if the price is right.

The moral of this story is: had I been able to find a (*horrors!* cheap or free) reasonable COBOL compiler (Kobol came close), I would, at this time, be willing to pay more for a full upgrade.

Open COBOL is probably the ticket to taking COBOL to everyone's desktop - something that current vendors have had trouble accomplishing, even though (and especially when) COBOL is the most popular computer language ever invented.

Dimandja

 

[theotyflos]

Dimandja,

I agree too but, it is very difficult for someone who is into production to find some spare time to spend to OpenCobol.

Vendors surelly need to make money, but we (developers) also need to make apps. And I don't think any of us ever paid for a product with money full of bugs.

 

[fredericofonseca]

(Thanks Tom. (Any new stuff on the way??))

so far I have only mentioned Fuji as this was what was mentioned on the OP.

As far as my experience goes it was a lot easier to convert to ACUCOBOL than any other (MF/FJ), but if you have programs developed with WOW you are targeting a BIG conversion to either.

Pricing. Unfortunatelly I can't speak for ACU as they don't release their prices anymore nor do they supply evaluations (at least not to my company), but last time I heard they were still lower than MF.
Portability is (was?) the same as RM/MF, thus a lot better than FJ which is very limited.







Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[Truusvlugindewind]

Dimandja,

A tip for your home PC. Try to get an old version of SuSE linux (the 6.x series). Install that on your PC. Next: install adabas-D, the database.

Look what automaticly came along: an old (evaluation) version of ACUcobol. And it works very well for free.

Adabas-D, by the way, is one of the few linux-databases with a proper cobol precompiler. it works great!

Bye bye Visial basic.....

 

[Dimandja]

I'll definitely give it a try. Especially since I am moving into the Linux arena.

Thanks for the tip, Truus.

Dimandja

 

[Crox]

I like open source.

 

[k5tm]

Theophilos,

Your original post indicated, in the same sentence:[ul][li]lack of support from Liant, and[/li][li]bugs in WOW.[/li][/ul]More recently you have equated lack of support from Liant with the absence of specific language features. My response regarding lack of communication was due to my presumption that somehow Liant had not been responsive to fixing bugs (not that we would ever be guilty of that ).

Your statement about the lack of certain language features is true, and it is true because, for Liant's market (which differs from those of Fujitsu and Micro Focus) the language features you mention are not the most needed by our customer base. The overwhelming majority of our customer base wants features that truly enhance the applications that our customers sell to their customers.

Mentioned earlier in this conversation was AcuCorp's XML support. The Liant XML Toolkit, using a different approach, is a substantially more capable product. The XML Toolkit is an enhancement that helps our customers meet their needs.

Stay tuned for the announcement of another product that some of our customers have already seen in action at our seminars. Here again, Liant's focus is on delivering capabilities that our customers can sell to their customers, in this case, the capabilities of integrating COBOL applications into Web Services (SOAP) and other web client agents (e.g. Internet Explorer).

Theophilos, it is not my intent here to provide a comprehensive defense of Liant's product development strategy, but rather to give some insight into a market perception that might differ from yours. I can assure you that we would love to do 'everything COBOL' but, like the child in an ice cream shop, we must pick one or two flavors because if we try to eat all the flavors , we will get very sick .

Tom Morrison

http://www.liant.com

 

[theotyflos]

Tom,

Lack of support is one thing, bugs is another and absence of features a different one. Don't confuse things. I did not equate the lack of support or the bugs with the absence of features. My previous post was the answer to yours, regarding the new features of v8.

Concerning the absence of features, I'm not happy :-( but I can live with that. But when I PAY for a product that has bugs, I ask for fixes and get no answer, I ask for help on how to overcome those bugs and still get no answer, then I CAN NOT live with that .

If I understand correctly, you state that you're not guilty (meaning responsible?) for fixing the bugs. THEN WHO IS? ME? (and what's the reason of having an "Online Technical Support Center" that's inoperative?). Wouldn't I be guilty if some of the money I gave you was counterfeit? How would you feel about that? How would you feel when the next car you buy with real money has "bugs" and the company you bought it from says to you "I'm not guilty about that".

You post "the language features you mention are not the most needed by our customer base" and "The overwhelming majority of our customer base wants features that truly enhance the applications" You mean that OO, threads, functions etc.etc.etc. don't enhance apps? May be even that I was the only one ever asked for them? That was a good one!!! Let me laugh!!!

Well Tom, I think your intetions here is to advertise and nothing else, and I'm really very sorry about that. I will stay tuned for the product you have in the pipeline, but let me tell you something: Before you take a step into your future, you should have correct your past first.

Theophilos Kanoutas