Would you suggest developing a massive new system that is PC friendly in COBOL? ...

Definitely not.

I do .NET development and SQL Server development/administration. The last company I worked for had a lot of COBOL running on an AS400. We would leave the COBOL alone as long as it was running fine and didn't need anything new added. As soon as maintenance issues or new features came up we would work on a conversion path.

We had no need, interest, or time to bother with re-writing it just for the sake of changing the language.

Dave,

I think that you and I are on common ground. Don't fix what isn't broken.

Thanks...

I agree that most of these legacy COBOL processes should be left in place unless there is a return on investment to re-write them. When it comes to batch processing flat files, I guess COBOL is state of the art, if that's the limit of your current data processing needs. For many organizations, going from COBOL to a relational SQL database wouldn't be just an upgrade of programming code, but also an upgrade of the hardware, OS, and staff as well.

Likewise, I've got a 2002 mini-van that was paid for several years back. It gets 15 MPG, drips oil, and one of the sliding doors doesn't work right, but I have no plans to replace it with a new $$,$$$ hybrid until the thing stops running. Especially since I'm not the family member who drives it every day. ;-)

"The universe is complicated and for the most part beyond your control, but your life is only as complicated as you choose it to be."

Would you suggest developing a massive new system that is PC friendly in COBOL? ...

Definitely not.

I do .NET development and SQL Server development/administration. The last company I worked for had a lot of COBOL running on an AS400. We would leave the COBOL alone as long as it was running fine and didn't need anything new added. As soon as maintenance issues or new features came up we would work on a conversion path.

We had no need, interest, or time to bother with re-writing it just for the sake of changing the language.

Dave,

I think that you and I are on common ground. Don't fix what isn't broken.

Thanks...

I agree that most of these legacy COBOL processes should be left in place unless there is a return on investment to re-write them. When it comes to batch processing flat files, I guess COBOL is state of the art, if that's the limit of your current data processing needs. For many organizations, going from COBOL to a relational SQL database wouldn't be just an upgrade of programming code, but also an upgrade of the hardware, OS, and staff as well.

Likewise, I've got a 2002 mini-van that was paid for several years back. It gets 15 MPG, drips oil, and one of the sliding doors doesn't work right, but I have no plans to replace it with a new $$,$$$ hybrid until the thing stops running. Especially since I'm not the family member who drives it every day. ;-)

As I mentioned before, I was developing COBOL using SQL databases (DEC Rdb) 25 years ago, so I don't think there is anything about SQL that forces you to abandon COBOL.

There are a lot of mainframe applications that use COBOL to access SQL (DB2 and Oracle) databases. In theory, there is nothing preventing development of COBOL to access SQL Server databases.

There are plenty of good reasons to move away from COBOL, especially for new development, but most of the reasons you have posted just show a lack of understanding of the technology.

My first encounter with a Computer was an IBM 1130, I was a student at a nearby College and the Computer was at the University. We went there one night as a special visit. We typed in our Birth Date and it old us our Day of the Week that we were born. Magic Stuff.This was 1975.

I really only got into Computers when I discovered that they could play games and print out Soft-Porn.