tags:

views:

151

answers:

5

Hello!!!

A mid aged man developed software for the company he works before about 25 years ago... He has written everything in COBOL...It took me hours to understand how the system works! Well the company's server is too old (8 mb hard disk ) i think ... He doesnt use a database but stores the data in files... He told me that he wants to upgrade the system to something new... The old system uses AIX operating system.... He was wondering whether aix or linux is better ,i think that a distribution of linux might be better because there is much free software for linux... i dont know what is compatible for AIX... The company is some type of warehouse... He has developed a website for the clients to login and see some info ..The website is at remote server and he manualy copies and pastes the database at the remote server...

He wants to add the functionality to the web site of placing orders... However he isnt willing to update the old COBOL code and use a database at least...

The people in the company use the server's programms via telneting the server using somekind of telnet client....

My question for educational purposes... Is there any way to reuse the COBOL code and creating a web interface? Or if it is posible to create GUI program for the users while using the same code from cobol... Because i know that writing code to do same things in diferent places isnt good idea.. i mean the bussiness logic to exist in more than one places...

A: 

A Linux server with an installation of TinyCOBOL might be an option. I will keep a close eye on The Daily WTF, in hopes of hearing the rest of the story...

Jim Lewis
Yeah,actually he is interested in microfocus cobol..I dont know if this works on linux,aix...Anyways my question was about reusing that code... as an application server doesnt exist,or web services etc..In other words if it is possible to create a new distributed system using the old cobol code and not replacing it with something else
Parhs
+2  A: 

Run away!

At least until your client comes around to using a real database system to implement the order entry system. All transaction processing systems need to ensure ACID properties are maintained for every transaction. This is one of the fundamental reasons why real data processing systems use databases. Not using a DBMS is a sure formula for disaster (sooner or later).

Can COBOL be interfaced to a web service or a GUI type application? The answer is definitely yes and it is not an uncommon practice. Making it happen can be a more or less painful process depending on how the COBOL application is structured. If it has a Client/Server type structure, then you only need to replace the Client side components with web/GUI components, insert the appropriate middle-ware to connect to the server and you are pretty much done. If the COBOL application was developed as a big ball of mud, then you are in for a rough ride. Since your client developed his system on a stand-alone platform by himself, I am willing to bet serious money the "big ball of mud" model applies. Be prepared for the worst.

If this application only took "hours" instead of "months" to understand it doesn't sound all that complex - you may find rebuilding it from scratch is a viable option. However, don't underestimate the work in doing that either!

As for upgrading the AIX system or switching to Linux, I cannot help you.

Here are a couple of resources for COBOL on AIX that you might want to review:

If you choose to go the Linux route I would recommend checking out:

Your client expressed interest in MicroFocus COBOL. MicroFocus is probably the largest COBOL vendor outside of the mainframe market. They have a very good reputation. MicroFocus also supports web development on Linux platforms and tends to have good support for IBM COBOL dialects which may be a consideration if migrating from AIX.

My final words of advice are to run away until your client wakes up to the following facts:

  • Data and transactions need to be managed using a real DBMS that supports ACID.
  • tacking a web based order entry system onto a "ball of mud" is not a week-end project. It may require a complete refactoring and possibly a complete re-write of the existing system

BTW... If you want to retain a working relationship with this person, don't call his system a "ball of mud" even if it is one. He built this thing and probably sees it as one of his children.

NealB
BTW... If you want to retain a working relationship with this person, don't call his system a "ball of mud" even if it is one. He built this thing and probably sees it as one of his children.Thats true! hehe thats the way he thinksI think that transactions handling wasnt a problem for 25 for him... So ...
Parhs
A: 

Well yes that is the way he thinks... This system is his child for 25 years! And brough money to the company.Next week i'll see the source of one of his program... Actually he made about 5 different programs...

You said that it can be interfaced,the question is how??? Using what? Now the system works through telnet... If the solution is creating telnet connections at the interfacing application ,and fetch data this way... i think that this is totally POOR..

Parhs
@Parhs Forget telnet. Web enbled applicaionsneed to run on properly managed and secure web servers. You need to find a commercial Web Hosting service. The wholeapplication should run off of that (your local AIX or Linux boxthen becomes a development/test platform). Other solutionsare more complex and expensive than what you areprobably looking for.
NealB
A: 

One possible approach that I have used is to keep the COBOL core but expand around the edges. This fits in with "He wants to add the functionality to the web site of placing orders".

Microfocus provide a tool called Enterprise Server which allows COBOL to interact with web services. (It runs on both Linux and AIX).

If you have a COBOL program A and another COBOL program B and A calls B via the interface section, the tool allows you to expose B's interface section as a web service.

For program A, you then generate a client proxy and A can now call B via a web service.

Of course, because B now has a web service any other type of program (command line, Windows application, Java, ASP etc.) can now also call it.

Also, they have a product called COBOL.NET which runs inside Visual Studio and translates COBOL to MSIL. This means that you can then link in any .NET components.

So the approach is to keep the COBOL core but interface via web services and do new developments in any CLR compliant language (C#, VB etc.)

P.S. Be very careful of moving a COBOL system that uses big endian to a system that uses little endian and vice versa!

nzpcmad