Need negative info on Cobol 1

[Guest_imported]

I work for a city in texas, and we have a unix box with using cobol for programs. The city wants to know if we should stick with COBOL or move away. Everything I find is positive. Also, if we stay with COBOL do you guys think we should migrate with ORACLE for GUI apps or is there something better out there for this.

 

[Crox]

I prefer DB2 as the database system. Very important about considering a new develop platform is if it will be easier to maintain yes or no. There are a lot of development platforms. Most of them are very fast if you want to create something new. But integrate the new solution with what you have or import the old stuf into the new environment is often difficult.

Using a good editor like SPF/SE and a smart library with almost ready source, you can also create your applications very fast without the trouble when you want to combine the old and the new software. Building software using architectural components, you will have the best situation. When you do this and create skeletons with software and you teach your crew how to be smart with the editor, you will be the big winner.

By the way, comparing a COBOL environment with Oracle: a new release doesn't mean in that you have to convert all your COBOL software. The Oracle boys did those things many times in the past. I prefer COBOL a lot!

 

[dhecht]

In the past, one language was deemed more powerful than another language in terms of what application its syntax and semantics best lent itself to: COBOL, a business oriented language, FORTRAN, a scientific language.

IBM developed its mainframe software in a PL/1-like language PLSIII (later PLAS, later PLX), which had nice pointer capabilites used for parsing tokens, i.e., commands.

It wasn't until COBOL II that a field could be looked at as an array, a syntax called reference modification. C has always looked at character strings as arrays. Assembler has operations that allow for the manipulation of fields at the bit level. In short, each language contains capabilities that may or may not be of use in terms of the application being developed.

Today, I think, the "power" of a language is determined by its ability to embody object-oriented concepts such as encapsulation, abstraction, polymorphisim, and inheritance.

Furthermore,a languages such as JAVA, while supporting object-orientation, also provide mechanisms for supporting communications between hetero- or homogeneous distributed envrionments, most commonly an n-tier architecture, most notably a web tier.

The promised payoff is more portable, more quickly developed, more reusable, and more scalable applications. Aside from working storage and procedural copybooks and called modules, resusability in the COBOL world involves the COPY command.

If you find that the capabilities of an object-oriented language are essential in meeting the goals of your shop, then consider migrating.

 

[Crox]

The performance of JAVA is only a few percent of COBOL.

The newer COBOL compilers are also object oriented.

Object oriented should be a way of thinking, not the way you make code.

The copy statement in COBOL is a low kind of reusability.
Architectural concepts can help you to reuse programs. That can give you the speed you need.

 

[Thane]

For GUI I recommend the Flexus suite of tools. Thin client will let your COBOL applications continue to run on Unix but to present the UI on the Windows desktop. You get the best of both worlds.

http://www.flexus.com

 

[Crox]

Such a recommendation is nice especially with an example of code which shows us why you like it so much!