Microsoft Makes Push for COBOL Migration

geoff313 writes: "It would appear that Microsoft is making a real push for the migration of existing COBOL applications to Windows and their .Net platform. Micro Focus, a company who makes COBOL migration products and last year became a member of Microsoft's Visual Studio Industry Partner (VSIP) program, announced their Net Express with .Net product, a plug-in to Microsoft Visual Studio .Net 2003. It allows for COBOL code to be integrated and manged with other code in Visual Studio. In an interview with eWeek he declares that 'Micro Focus and Microsoft are bringing the mainframe to Windows and .Net'. This makes me wonder, are there any Open Source projects working to provide for this eventual migration? Gartner estimates that over 75% of business data is processed by an approximately 200 billions lines of COBOL, so this seems like a huge potential market to lose to Microsoft."

Comments

Bah humbug...

[__aavhli5779]

Aren't most COBOL applications deployed on big iron?

I doubt any Microsoft solution could honestly compete with the scalability and reliability of a true mainframe, and it doesn't state anywhere within the article that these .NET solutions will be deployed on big iron; rather, my assumption is that we are dealing with standard x86 server farms running Windows Server.

Anybody who migrates to .NET may find their projects more maintainable (if only because the number of COBOL coders is declining fast), but because of the underlying platform, they'll be introduced to a world of hassles, too, and I doubt businesses with mission-critical applications (like the big banks and insurance companies and what-not currently using COBOL on mainframes) will go for that.

How seriously do you think this will really be taken up? I posit: "not much".

Re:Bah humbug...

[Anonymous Coward]

I work for an insurance company, running a policy administration application running under Windows. We currently administer approximately 150,000 policies, and were recently acquired by another company. They're dumping their mainframe based admin system and we're taking on their policies as well. This system is written in COBOL, and at one time we were using Microfocus COBOL. The vendor switched to Fujitsu COBOL and the next version will be Fujitsu COBOL.net.

Microfocus is a little late to the table.

The system is running of a $40,000 Dell server, and replaced a mainframe that was costing almost $1M a year to lease/maintain. It's very doable.

Re:Bah humbug...

[darnok]

> Aren't most COBOL applications deployed on big
> iron?

That's been my experience too. Most COBOL work being done today seems to be primarily presenting existing data in different formats for consumption by Unix or Windows based systems.

There's no way this COBOL code is going to be migrated off the mainframe, for several reasons:
- it's being written and maintained by mainframe COBOL coders. They have no interest whatsoever in saying it's feasible/viable/cost-effective/... in porting this code to another platform, because doing so would probably put them out of a job
- this code tends to be built on top of old code, which is built on top of older code, which is built on top of ... It's very rare to find someone writing COBOL code from scratch; it's all based on changing proven existing code and thus carries a relatively tiny risk of problems occurring after deployment. Furthermore, it's quite common to take the output of one piece of COBOL code, and use that as the input for your new set of COBOL code. Add a few generations of this, and suddenly you're dealing with an enormous mass of COBOL code, possibly largely undocumented and written by guys who retired years ago, that you have to port across to get a single piece of functionality working. It's very difficult to even write test cases for this legacy code, since its original purpose may be totally forgotten and the only reason it still exists is to support all the newer code that's been layered on top of it. This is a big factor that tends to be conveniently forgotten by those who think a move off the mainframe to Windows or Unix is simply a matter of time. A change to the .NET platform, or any other platform for that matter, is simply not feasible for the vast majority of mainframe shops on this basis alone.
- as this code is primarily involved in presenting data in different formats, this work is best done as close to the database as possible. You don't want to be sending a big wad of data to another system, only to have 90% of it get thrown away and the remaining 10% formatted and consumed. It's generally cheaper to do this on the mainframe
- in the mainframe environment, .NET is often seen as a high risk option. Remember, CICS and MVS have been around for decades, and they're known to work close enough to perfectly. For the type of work COBOL is currently being used for, reliability is absolutely top priority; you don't want your huge transaction processing system to go off the air for even a few seconds while your Windows systems take an outage for patches to be applied.

That's my take on things, but I'd be very interested to hear from anyone who sees mainframe COBOL code being used to do anything different.

Re:Bah humbug...

[Anonymous Coward]

Yeah, but that mainframe (if it's an IBM/3x0 series) is effectively unkillable, whereas a PeeCee server eventually kills itself with its own heat...

I mean, not to troll, but that $1M is probably worth it. Mainframes are rock solid, incredibly dependable systems. Any PC system, no matter how nice, isn't. Instruction recovery, ensured datapath accuracy, automatic redundant verification... the closest you can get in the PC world is RAID, and that only covers storage.

*sigh*

Re:Bah humbug...

[ericman31]

That's my take on things, but I'd be very interested to hear from anyone who sees mainframe COBOL code being used to do anything different.

You're pretty much dead on. Sun and HP systems have had more horsepower than mainframes for quite a while now. They are nearly as stable too. But there's a couple issues:

• A lot of mainframe code dates back to the 70's. Trying to migrate it would be a nightmare. Modular rewrites, one little piece at a time is more likely to succeed.
• CICS, TSO, MVS, VSAM, etc. is dead on reliable. Our mainframe sysplex outages can be measured in mere minutes per year.
• There are simply too many migration scenarios where the system was eventually migrated off the mainframe, but the managers who initiated the migration were no longer managers when it was complete due to budget overruns, delays, and other problems. CIO's learn from this, and aren't willing to go there if they don't have to.

Dell servers running Windows are nowhere the reliability level of Sun/IBM/HP RISC servers running UNIX, let alone the mainframes. Mainframe shops are not willing to risk mission critical money makers on unproven, unreliable upstarts.

Re:Bah humbug...

[nzkoz]

..... Right. You're clearly someone who has never dealt with a mainframe. You could migrate those systems to a small unix server. Unfortunately, IO throughput will destroy your performance and your nightly batches will take 2 days to run.

Re: Bah humbug...

[Black Parrot]

> Aren't most COBOL applications deployed on big iron?

They're anticipating that you'll have to have a mainframe on your desktop to run the next release of Windows...

Re:Bah humbug...

[MeanMF]

Aren't most COBOL applications deployed on big iron? I doubt any Microsoft solution could honestly compete with the scalability and reliability of a true mainframe

Not all mainframe applications run on mainframes because they need the power and scalability - a whole lot run there because they were written when the mainframe was the only game in town. I'd bet that a vast majority of legacy applications running on mainframes could easily run on Intel servers without breaking a sweat.

Re:Bah humbug...

[karit]

You are missing his point. He is refering the internal workings not redunacy. The mainframes will double check their working so if errors in the datapath (ie in processor) are picked up and corrected. 80x86 (AFAIK) does not have this kind of checking built into the chip.

Re:Bah humbug...

[llefler]

You are of course, speaking from experience, right?

Not only are nightly batch cycles still used in mainframe environments, but I have also seen them in PC based SQL environments.

And I think you are missing the point; x86 servers may have plenty of CPU, you can even build clusters, but you simply don't have the I/O capacity. Consider a company with half a million 600meg tape cartridges in their library and 5-10,000 of those get cycled every night. Now I haven't been a tape ape for over 10 years, and those are still pretty big numbers.

Re:Bah humbug...

[danheskett]

The thing is you assume that all these places use tapes on a nightly basis when a good number have migrated to other storage mediums.. tapes are not everything..

A lot of mainframes can be replaced with a low-end PC running Linux or even Windows without any noticeable loss of performance.

I've seen $500k a year mainframes (leased, of course) replaced with a pair of $10k IBM x86 servers. Setup with failover in mind one PC could be yanked out and the other taking over the load in a fraction of a second without notice to users.

Saving your boss $480k a year will get you a lot of praise. I know the guy who did it. Look at it this way: they could afford to pay some $50k a year to babysit those two RH servers, buy new hardware each year to do preventive maintenance on, and still have an extra $400k a year saved. Multiply that over a decade, and you're talking the difference between profit and loss, good stock or bad stock.

A lot of mainframes are needed. A lot are required. But most are not.

Re:Bah humbug...

[dperkins]

Umm, Actually, we are currently migrating several tax systems from a government mainframe system to a Sun Solaris system. Mirrored solaris boxes running an Oracle database, mounted from an EMC SAN. IO is not an issue, and we are running Microfocus Cobol for our back-end batch.

I would like to say, however, that much to my disappointment, we will be going forward with .NET in future projects. We have actually taken a look at COBOL.Net from Fujitsu, and though I don't think we will be using it, .NET is where we are heading. Mainframes, however, are seen as the proprietary means of locking folks in, not .NET.

Companies that have been locked into mainframes for so long are trying to escape from that "Big Iron Prison" to Microsoft. Ironic, isn't it? :)

Re:Bah humbug...

[icebattle]

Sun and HP systems have had more horsepower than mainframes for quite a while now You obviously don't know anything about mainframes, so do some homework before you spout. HP and Sun offer nothing that comes close to the sheer brute performance of an IBM ESA or later box. I've worked on all three platforms, and although I would reccommend Unix, there is nothing in the universe that compares to the transactional throughput of a mainframe with VM or MVS. Nothing. Cheers.

Re:Bah humbug...

[Detritus]

A massive cluster of x86 systems is just a bunch of hardware. Where is the software that is going to turn it into a unified fault-tolerant system?

Re:Bah humbug...

[llefler]

I'm not assuming anything. I know the two companies I worked for are still running multiple mainframes and have huge tape libraries. One is a mutual funds company and the other is a telco. The telco processes enough transactions daily that it's not cost effective to spin that much storage. They run on monthly batches anyway.

I've seen $500k a year mainframes (leased, of course) replaced with a pair of $10k IBM x86 servers. Setup with failover in mind one PC could be yanked out and the other taking over the load in a fraction of a second without notice to users.

Those numbers are abnormal. If they were properly utilizing that $500k mainframe, it wouldn't be possible to replace it with a $10k x86 box. $10k doesn't buy much of an enterprise server. Our 4 processor Netfinity SQL server alone cost several times that much.

Companies that buy/lease 390s tend to need the capacity. Otherwise they're using AS/400, Sun or Alpha, and the hardware costs aren't enough higher to outweigh the fragile nature of x86 hardware.

A lot of people here seem to assume that mainframe means it was purchased in the 70s and hasn't been upgraded since. The only places I've seen that to be true are in universities and non-profits.

Re:Bah humbug...

[danheskett]

A lot of people here seem to assume that mainframe means it was purchased in the 70s and hasn't been upgraded since. The only places I've seen that to be true are in universities and non-profits.
Your perception is lacking, in my opinion.

Many have software (COBOL usually) that was originated in the 70's, and that ties them to mainframe hardware. If not for that crucial link, they'd never be anywhere near mainframe hardware. In the 1970's thats what there was - Big Iron. Now, there is a lot more for the low-end and medium-end stuff. If you have upgraded the hardware just to keep current (ie, not running on 30-yr old electronics) but not touched the software what MS has to offer might make sense. They are selling to those people who are running transactions that could be completed by a typical Wintel server in a few hours. These people use Mainframes because they are locked in to the legacy mainframe model.

MS is clearly not targetting the true Mainframe user. Those places that need mainframes - great, good on them. I dont think MS has any shot at that nor do they really want it. They want those people using mainframes that have less IO, less capacity, and less power than a late 1990's Pentium desktop PC. Those places can easily go out and buy a mid-range Dell server for about $10k, load it up with disks and RAM, and run this stuff from MS and live happily ever after - and probably save money as well.

That's the real bottom line here. If you need thousands of transactions a second you want a mainframe. If you want five nines or better, get a mainframe.

Where I am from there are dozens of places locally that have mainframes but really have no business with them. Supermarket chains of 50 stores with an 80's system. Local bank chains from the 70's running a water cooled IBM system to process a few thousand transactions a day. There is no credible technological reason these people aren't running a cluster of Linux PCs, Solaris boxes, or even a Windows farm. The only roadblock is the software.

Re:Bah humbug...

[abradsn]

Actually, there are several solutions available to cope with these issues. Both Linux and Windows support various ways of handling these problems.

Re:Bah humbug...

[BrokenHalo]

The other advantage of non-mainframe systems is that you don't have to pay a premium to the dwindling number of people who have both the skills and the interest to work on them.

True. Which is why, I suppose, Microsoft used to market a COBOL compiler many years ago (1990, I think I last saw it).

Looks like they've revived the project...

Re:Bah humbug...

[cotopaxi]

I work for a software company that does ERP systems for some niche industries - both the writing and the implementing. All of the business logic is written in Cobol.

Of our clients, nearly all of them used to be on mainframe systems. Over the years, most of them migrated to UNIX(either HPUX, AIX, or Solaris for us). We haven't done a new mainframe implementation in years - all of our current work is on UNIX(bigger more knowledgable clients) and Windows(smaller and much less savvy clients).

We use Microfocus NetExpress on Windows or ServerExpress on UNIX and have for years. We use either Tuxedo or CICS for a TP(yes CICS does run on Windows and UNIX). Not quite as safe as a mainframe, but we've had large UNIX sites experience nothing but small amounts of scheduled downtime over the years.

Now, will .net affect us? Nope. Many ERP systems providers are hugely interested in platform independence. All new development work is being done with EJBs using IBM Websphere's Enterprise suite(which includes CICS as the TXSeries product). I don't think many companies who service large businesses ever want to be locked in to a Microsoft solution, or have to maintain parallel development efforts to support their latest technology.

Re:Bah humbug...

[larien]

*sigh* Clusters come nowhere near the level of fault tolerance you get in big iron. In a real fault-tolerant system, there are multiple paths for all transactions; in essence, you're running the same code on two (or more) CPUs. If one fails, you have zero downtime, other than a quick reroute in hardware to compensate (you probably wouldn't even notice it). To the best of my knowledge, there is no clustering solution which comes close to this, whether based on linux, Unix or Windows.

Yes, clusters can do a job which is "good enough" to replace expensive mainframes, but there are some cases where they aren't good enough, especially banking where you have to be 100% confident that every transaction is logged correctly.

Re:Bah humbug...

[quantum bit]

Actually, in my experience, Windows (2000 Server running Exchange) clustering seems to make the service LESS reliable, not more...

Re:Bah humbug...

[stripes]

I've written programs that do trillions of operations and then run some numbers against them. In case of some weird hardware failure or human error the code is run on three machines at the same time (the program takes a few days to run). What you are saying is that along the way the x86 hardware will incorrectly compute data and return bunk results? As a programmer (though not a low-level type), I'd expect that this would have come to my attention by now. Can you provide some examples or documentation? Of course there was the now famous Pentium flaw, but otherwise, what is defect rate on x86 operations?

Think about hardware at the gate level, your adders are a bunch of flip flops. A whole lot of them. And very very tiny ones holding very little charge. A cosmic ray striking one can change it's value (I think only form one to zero, or zero to one depending on the process and wether charged or discharged represents a zero or a one). If the cosmic ray hits one of the flip flops that is being used to produce a value about to go to a live register and then off to memory it can change the results from what your code should calulate to something with a one bit error. Maybe a low bit and the result is off by pennies, maybe a high bit and the result is so amazingly off that an assert later in the code catches it, or just a human eyeballing the results would. Worse yet something in the mid rage that nobody notices until far too late (if ever).

This is the same thing that ECC in memory helps prevent (ECC can't protect against multiple bit failures, but while a box with multiple gigs of memory will likely get a soft memory error in your lifetime, multiple bit errors before the scrubber finds them is really really really amazingly unlikely).

It is a force that gets worse as we go to lower voltage systems (less of a hit needed to flip values), and as we get greater densities (more likelyhood of the cosmic ray hitting something other then dead space -- at least I think so on this one).

It can be combated by having ECC on register and cache values (or even parity as long as the bits are "big enough" that a single cosmic ray hit won't flip multiple bits!), but having similar checks on ALU operations, or just sending the values through identical ALUs that are on diffrent parts of the chip and compairing them after (rerun any cycle where the results differ, either totally in hardware or trapping to the OS to let it restart the instruction after logging the hit). Not rocket science, but it makes for a more costly CPU, and it makes for a slightly slower CPU (in fact much slower when you factor in the extra transistors used for correctness checks that a "normal" CPU would use for cache or some other performance boosting geegaw).

As for documentation I don't recall where I saw studies done, probbaly in one of the ACM or IEEE procedings, but if you don't have access to them comp.risks might turn something up (and a lot of other stuff that might be more worth worring about :-)

Re:Bah humbug...

[Zeinfeld]

I doubt any Microsoft solution could honestly compete with the scalability and reliability of a true mainframe,

Oh I think they could, just write the code in COBOL and you can be pretty certain that it will be fragile and bug ridden, particularly if you run 30 plus year old code that nobody has the source for.

Mainframe hardware can be pretty reliable - particularly if you compare against some of the crappy stuff sold by wannabees. But it is certainly not infalible and you can certainly get high end intel class boxes that are easily a match reliability wise. As for mainframe O/S being reliable I have to snigger there, there is no way to know how reliable MVS is, the operator will make so many errors that any the system makes will be lost in the noise. Reliability should be measured for the system as a whole, MVS creates so many opportunities for an operator to botch things up it isn't funny.

Microfocus has been in the cobol business for at least 20 years, what the story is about is being able to use Visual Studio as a development environment. That is pretty big news since only a complete masochist would want to develop code in an MVS environment. Unless you have tried Visual Studio, don't knock it, it leaves emacs in the dust.

I am not sure that Visual Cobol is going to be a great programming environment, a lot of the Visual C# features are made possible by the language design. But if you are going to endure the misery of cobol it is probably the best way to do it.

I suspect that a fair number of programmers would use the package to gradually migrate systems from Cobol on Mainframe to Cobol on dotNET to Cobol with SQL backend on dotNET to full C#/Java code with SQL backend.

As much as I hate MS this is very smart.

[Ken Broadfoot]

You have to admit, this is the most innovative thing Microsoft has done. Ever.

--ken

Re:As much as I hate MS this is very smart.

[Jameth]

I don't know, that paper clip was pretty damn innovative. I mean, who else would think to make something like that?

Re:As much as I hate MS this is very smart.

[ericman31]

Oh please! Sun Microsystems has had rehosting solutions for COBOL on the mainframe to their platforms for years. Look at:

• http://www.sun.com/migration/mainframe/sunps/
• http://www.sun.com/migration/mainframe/

This isn't innovative at all. Unless, of course, the only part of IT you have ever been involved with is PC's running Windows and a couple of small servers and don't know what the data center is all about.

Re:As much as I hate MS this is very smart.

[molarmass192]

the only part of IT you have ever been involved with is PC's running Windows and a couple of small servers

Although I don't like stereotypes, you've just described at least 3/4 of the posters on Slashdot with that one.

Re:As much as I hate MS this is very smart.

[ericman31]

If it makes you happy. But, remember those 200 billion lines of cobol? Those run in data centers that have mainframes. They run primarily banking and insurance transactional systems. Too many people make comments on here whose "IT experience" is limited to an SMB with 5 PC's and one server. You know what our Unix and Windows systems do? All the peripheral stuff that isn't mission critical, that isn't about the core transactions. Our mainframes run our daily and weekly transaction cycles and have been doing so for more than 25 years. They do it efficiently and well. Our enterprise is about moving those transactions through the system, day in and day out without fail. Reliability has to be measured in 4 and 5 9's. Show me a Windows shop (yours included) with 5 9's reliability on their core systems? Our core transactional system has not missed a cycle in more than 15 years. With major system enhancements due to state and federal regulatory changes, with Y2K, with HIPAA.

Re:As much as I hate MS this is very smart.

[ericman31]

But this is the standard that we have to adhere to because we provide claims payment, treatment authorization and such for insurance beneficiaries. Our SLA's with our customer only allow us 30 minutes of downtime for the entire system per week. That includes the mainframe sysplex, the point of sale system, the web access for doctors and pharmacies, the interactive voice systems and all of the claims entry points.

It's not about my data center kicking your data center's ass. This is the sort of hardware and software reliability that big data centers have to have. And this whole thread started from the idea that running COBOL within .NET was somehow innovative. The big iron shops (Sun, HP, IBM) have had COBOL migration or rehosting programs for years. I pointed out that the guy who thought this was innovative probably run a couple of windows PC's and a server. While that is necessary in the grand scheme of things, it isn't a really likely place to learn about big, mission critical IT. I used to work for a small business. We provided network services and integrations to other small and medium businesses. I thought I knew what reliability, scalability and uptime was all about until I went to work in a place where people literally might die if the system was down.

UNIX is so close to the mainframe in reliability terms these days that there is literally no way to differentiate. I can engineer a Solaris, AIX or HP-UX system to 5 9's reliability, and have as much, or more, processing power as a mainframe sysplex. But, the problem is all that COBOL code. It has to be moved. The original design of much of the world's core finance and insurance systems happened in the 1970's. The original designers are gone. The code is not well documented or commented because the people who wrote it, for the most part, didn't think it would still be running in COBOL, on mainframes, in 2003. Moving it in one big jump is scary, and high unlikely to happen.

We will move it, because you can't really innovate with COBOL anymore. Programmers are harder and harder to find, the SME's are retiring, and the best and brightest of the new generation are going to distributed platforms, especially Java. So, instead, we will move it one sub-system at a time to a new platform. Either a UNIX or Linux cluster, and the foundation will probably be Java. There is no confidence in the data center in Windows computing. We have had too many bad experiences with the few systems we have tried out. Bad by our standards. Granted, Windows can now achieve 3 9's, with good engineering and a LOT of tender loving care. 5 9's amounts to roughly 5 minutes of downtime per year. 3 9's amounts to roughly 500 minutes of downtime per year. 500 minutes of downtime means we might miss our SLA's for as many 15 weeks a year, depending on how the downtime worked out. That's a lot of lost revenue. And patients who can't get their treatment authorized on time or doctors not getting paid on time.

Just announced...

[fredbox]

Microsoft Visual COBOL++.NET 2003

Available 3rd quarter 2005. Look for Visual COBOL# in 2007.

Re:Just announced...

[Anonymous Coward]

That would be VISUAL COBOL++.NET 03

No need to waste the extra two columns for the century.

manged??

[Anonymous Coward]

It allows for COBOL code to be integrated and manged with other code in Visual Studio.

I think the correct spelling is mangled.

hog wash

[Anonymous Coward]

of all the financial companies that I know, none of them have any plan to replace mainframe with windows boxes. First off, the reliability of mainframes is rock solid and the code is old but robust. It's not the most flexible systems, but they provide 99.999% reliability and tremendous scalability. Windows can't scale to those levels worth shit. Maybe in 20 yrs windows will be half way, but it would require a fundamental rewrite of the entire operating system and all of .NET. Some one over at MS is smoking some serious crack. I know from first hand, most of the big financial firms on Wall street are moving to massive clusters of linux, but the plan is a 5-10 yr process. that is such a joke, migrate Cobol to .NET.

200 billion lines?

[Lxy]

Isn't that about 20 lines of C++?

Re:200 billion lines?

[McSnarf]

Well.... UNSTRING alone would mean a week of coding to a C++ programmer, never mind the mind boggling concept of ALTER x to PROCEED TO a,b,c DEPENDING ON i.

Re:200 billion lines?

[nonregistered]

Or zero lines of... Ooops. I guess I should posted earlier.

Re:200 billion lines?

[Tisephone]

Yeah, 4 lines containing 200 billion parentheses.

What are the Linux COBOL solutions?

[beamdriver]

Has anyone used Tiny Cobol or Open Cobol

COBOL migration

[bersl2]

This makes me wonder, are there any Open Source projects working to provide for this eventual migration?

Just from browsing freshmeat: OpenCOBOL

Oh no!

[Danathar]

This is just going to result in the resurgance of COBOL! Not the migration away from it! BASIC was literally almost DEAD until microsoft came out with Visual Basic. What do you think this will do for COBOL!

I DO NOT want to have to debug visual COBOL!

Why would you?

[msgmonkey]

As long as it works and there are no issues like Y2K why would you get rid of something that works? It's not like new machines wont run COBOL programs.

Re:Why would you?

[Tablizer]

As long as it works and there are no issues like Y2K why would you get rid of something that works? It's not like new machines wont run COBOL programs.

This issue is hotly debated at many medium and big companies and organizations. Their biggest fear seems to be finding developers who know mainframe issues. There is a lot of Go-to code and JCL subtleties, for example, in these programs. Go-to programming and JCL is not tought in the schools, especially hacky constructs left over from the 60's where every byte was expensive. Imagine a class called "Go-to Techniques 101" :-)

However, there seems to be a movement in India to create mass production "Mainframe Diploma Factories" that could potentially replenish, or even flood the mainframe market the way they did with web and client/server stuff.

Thus, mainframe labor future is fuzzy. But, insn't the future of ANY technology somewhat fuzzy? Do you really think Java is the final word on programming languages or the final fad?

Sounds about right...

[dillon_rinker]

...allows for COBOL code to be integrated and manged...

That's right, folks! .NET for ALL your COBOL needs! Want your COBOL code to be hairless, oozy, and irritated? Then .NET is for YOU!

Re:Sounds about right...

[jvollmer]

Want your COBOL code to be hairless, oozy, and irritated?

Hairless, oozy, and irritated? You're talking about Ballmer, right?

If it's not Consolidated Lint, it's just fuzz!

Speaking of Gartner...

[checkitout]

Information week has an article from Nov. 3, 2003 noting that 38% of Gartner's shares are owned by Microsoft, Oracle, Dell and a few other major players. All of whom would presumably benefit from what Gartner has to "report" about their respective fields of interest.

Considering that Gartner has been charged with bias from some circles already, this can't help things.

Who Owns Gartner?

Yeah, this isn't so interesting, really.

[King_TJ]

Most places running COBOL apps are doing so largely because the stuff "just works" and they have the "if it ain't broke, don't fix it" attitude about it.

In many cases, the biggest concern is that their legacy hardware will become so obsolete that they can't get service contracts or replacement parts for it anymore. If/when it reaches that point, they're probably going to consider it time to redo *everything* from scratch -- implementing new software along with new hardware to run it on.

I don't think there's really much of a market out there saying "Gee.... if only I could migrate all of these COBOL apps on our mainframes over to Windows and .NET!" Still, you can't blame Microsoft for trying. They're the experts at finding untapped markets and selling to them. They may even have moderate success, selling complete migration solutions to govt. agencies. "We'll contract out developers to move all those apps over to our new server farm and sell you the whole thing for price X!"

Re:Yeah, this isn't so interesting, really.

[Jeff DeMaagd]

I don't think legacy hardware is a problem at all. That market isn't like the PC market where the maker pretends that it didn't exist if it is more than three years old.

If you check out Sun, you'll find that they still sell parts for even their oldest systems. That and more is what the mainframe market is about.

Re:Yeah, this isn't so interesting, really.

[alangmead]

Sun has two designations for ceasing hardware support. There is "End-of-life", where they cease producing the production, and there is "end-of-service-life", where they cease providing replacement parts.

I'm assuming they do some sort of calculation for the likelihood of failure, the cost of storage, the income from support contracts, and figure out how many extra units to store for parts, (and the price for support contract renewal.)

Of course, they produce product for long after you would think they would. The Sun 220R had an EOL date of 05/2002, so you can order replacement parts until 2007.

I guess there are occational exceptions. If you look at the Sun-4c Page you'll notice that the EOSL date for models like the SPARCStation 1 and 2 were extended. I'm guessing that enough people kept signing support contracts for them, which made it worth it for Sun to keep the hardware around.

This EOSL document has an interesting list of Sun's products and their EOSL date.

All this, of course, is just buying parts from Sun. There is a big 3rd party market for older mainframe and minicomputer components. I know of a large Boston area company whose publishing company is finally being moved off of the PDP-11 system they have been using for the last 20 years. From what I understand, as companies decommission systems built on old DEC hardware, people will buy it up for recondition and resale.

Don't hold your breath...

[Dinosaur Neil]

Migrating COBOL apps to PC platforms won't happen on a large scale for two reasons:

1. Reliability - We used to "reboot" our mainframe once a month, whether we needed to or not. No way will mission critical applications end up on any system that dies on a daily/hourly basis.
2. Inertia - The reason for all those lines of godawful COBOL code is that it works. It runs and doesn't cost anything more to keep it running (at least not on the applications side of things; for some reason support time and effort doesn't count, no matter how much is required). There is a strong "if it ain't broke, don't fix it" mentality in the people that decide where to allocate programmer time.

I worked on the support side of a mainframe for sixteen years and my experience was that, so long as the reports showed up on the users desk in the morning, there was no problem no matter how many problems there were. Why would anyone invest any time and/or effort fixing something that "works" when there are so many newer and more interesting ways to waste money and make life harder for the support staff...

Good thing I'm not bitter.

What about

[bersl2]

COBOLScript in the next version of IE?

Emulation?

[G4from128k]

Maybe they are rewriting Virtual PC to run on the IBM 360.

Manged

[Nemi]

"It allows for COBOL code to be integrated and manged with other code in Visual Studio"

From dictionary.reference.com:

Manged:
adj. Refers to anything that is mangled or damaged, usually beyond repair.

Gotta love a binary shreader...

Market analysis or wishful thinking

[Space cowboy]

I don't really think MS has much of a chance of changing the big boys' COBOL machines. Sure they could do it faster, cheaper, etc., but given the real need for stability in the traditional cobol marketplace, wherefore MS ?

The only place I've seen banks roll out MS apps are in non-mission-critical systems (bank-staff desktops), although WinNT does seem to run Natwest's ATM machines. I've seen a blue screen of death on them a number of times, so maybe MS aren't so fanciful an option... Damn!

Naah, overall I can see the "client" (you have no power) machines running windows, but not the central (we are the business) machines getting within retching distance of windows....

Simon.

Better solution exists

[Anonymous Coward]

Why go with some brand new technology when there is already something solid that works?

There are a few CORBA-compliant ORBs out there supporting COBOL language bindings.

Today, without waiting for some new M$ product, you can develop a CORBA layer to sit on top of the COBOL code, and then interface to the existing code from whatever other environment you wish.

Sooo, to expand the system, you can write your new code in whatever language on whatever OS you choose and still leverage the old system. You can also start to re-implement servants done in COBOL with whatever, and the other servants should not be affected too much.

Seems to me that .NET may someday offer some of the cross-language benefits of CORBA, but will not be able to offer the cross-platform benefits. Oh, and it won't be free and you won't be able to change it.

(yeah, yeah I know about mono, but I doubt M$ will do much to support it and will probably try to kill it somehow).

Comment removed

[account_deleted]

Comment removed based on user account deletion

The Latest From Microsoft R&D...

[cmacb]

I don't know, but something about all of Microsoft's recent announcements make me wonder if I am not having one great big lucid dream experiences.

I guess it started with the active directory thing that starts to move everything about an individual user back to a central server. Then grabbing the Citrix technology to essentially turn a PC into a dumb terminal. Now all of a sudden they no longer want to hide the Command Line Interface and are coming out with a new one with supposedly decent scripting capabilities. Now this!

Well, you know you can sort of steer a lucid dream anywhere you want to go, so here is what's coming out soon from Redmond:

Punch Cards: No more worrying if that last CD backup you did of your system is really readable. Now anything on your system can be easily converted to 80 column Hollerith format. The new WinPunch will attach to a standard USB port and allow for both punching and reading of standard IBM punch cards. Special programs will allow your keyboard to be used to directly punch these cards, or you can program your own virtual IBM 029 drum card to speed up repetitive tasks.

Paper Tape: For you PDP and other non-IBM users there is WinPT which will have similar I/O capabilities but use either roll based paper tapes or the much preferred fold style. Thanks to new fabrication techniques and years of work by the Microsoft R& D lab much higher densities will be available than those you remember.

WinHenge: Tired of using those old techniques to figure out when the summer solstice will begin?.....

Re:The Latest From Microsoft R&D...

[Threni]

> Punch Cards: No more worrying if that last CD backup you did of your system is
> really readable.

If someone produced this method of backup it would be funny twice. Once as soon as it was released, and secondly in 100 years time when it's the only computer output from 2003 which is still readable (Actually, the joke might still be funny in a few thousand years time).

Re:Yikes

[ericman31]

one would be better off leaving it on the mainframe until peices of it could be rewritten in a more modern language.

I work in the health insurance industry. We run millions of health care transactions per day through our mainframes. We use midrange and distributed systems (Sun primarily, along with a few Windows systems) to bring the transactions in the door and do the business intelligence work afterwards. Last year we start our planning to move off the mainframe. It is exactly what you described. Take pieces (the easy ones first) and rewrite and rehost. We probably won't finish the effort before 2008, or so. Of course, our current transactional system has been in place on mainframes since about 1978. We haven't missed a weekly payment cycle in more than 15 years. Our Windows boxes (even the supposedly high availability ones) miss cycles on about a monthly basis. We have no intention of even considering Windows for the rewrite effort. We're looking at Sun/Solaris, IBM/AIX and Linux clusters.

interesting mentality

[Animaether]

this seems like a huge potential market to lose to Microsoft

That's right.. it's not a huge potential market to win - it's just another huge potential market to lose to Microsoft.

Is that really the main motive to start development on something ?

If the opensource developers were to 'lose' something to Microsoft due to lack of development by said opensource developers, then that's a deserved loss, no ?
In fact, if said opensource developers had no interest in developing said something before, why would they even care if 'they' lost the market for it to another developer - be it Microsoft or anybody else ?

That said, further comments already pointed out that such projects do exist, and thankfully not just born out of an interest to spite Microsoft.

if it ain't broke, don't fix it!

[kraksmoka]

COBOL on big iron will never die. that's for the same reason one of my clients' elevator system is powered by a 100 year old solid state system. he walked me upstairs to show it off. lots of zapping and clicking noises. the thing runs 15 stories worth of 2 elevators and has for 40 years in that building (yes, bought used).

that reason is reliability. if it ain't broke, don't fix it.

note, y2k required fresh re-writes on many mainframe systems, and those old COBOL guys had a field day. but notice too, that they didn't go thru the trouble of migration then, even tho the amounts spend would have justified it!

if it ain't broke, don't fix it!

Re:if it ain't broke, don't fix it!

[Anonymous Coward]

Actually an enormous amount of mainframe code was migrated/replaced for Y2K to Unix and 'standard' ERP systems. The reason you didn't hear about it was that a successful migration would have had to start at least 3-4 years eariler. A good chunk of that last minute Y2K COBOL stuff was the result of failed migration/replacement plans.

Re:if it ain't broke, don't fix it!

[azzy]

If it keeps you in a job, don't fix it completely.

Re:if it ain't broke, don't fix it!

[tzanger]

that's for the same reason one of my clients' elevator system is powered by a 100 year old solid state system. he walked me upstairs to show it off. lots of zapping and clicking noises.

Sorry dude, that ain't solid state. I work for a solid state power electronics manufacturer. You're describing old contactor-based motion control. Solid-state is all done with SCRs or IGBTs (or depending on age, GTOs even) -- no zapping or clicking unless something is hellishly wrong.

Re:if it ain't broke, don't fix it!

[Dun Malg]

COBOL on big iron will never die. that's for the same reason one of my clients' elevator system is powered by a 100 year old solid state system. he walked me upstairs to show it off. lots of zapping and clicking noises. the thing runs 15 stories worth of 2 elevators and has for 40 years in that building (yes, bought used).that reason is reliability. if it ain't broke, don't fix it.

First off, "solid state" means "no moving/mechanical switching", which a room full of relays does not fit the definition of. Second, I seriously doubt that system is 100 years old-- more likely it's closer to 60, as 100 years ago most elevators were operated by a man in a silly uniform pulling a lever in the elevator car. Third, relay-and-solenoid elevator controls aren't more reliable than modern electronic systems. The reason people don't replace them is because the cost is usually prohibitive, and the failure rate on older systems isn't usually bad enough to warrant replacement. It generally comes down to a question of "do you want to call the elevator tech every 2 weeks at $250 a visit to fix bad relays, or plop down $80,000 for installation of a new UNIX based electronic controller?"

Inertia, maintenance and programmers

[Anonymous Coward]

Just some thoughts,

1) Migration assumes that, the source code is available (in some cases it it may not be, but businesses will still run the program as it works, and wont spend good money recoding something that is not broke)

2) The target system behaves exactly like the source system. If not then you are redeveloping for the new system .. who would really want to do this for 30 year old code that works fine where it is.

3) Performance. Mainframes may have less relative power than some PC's or servers, but what they do they do well. (Would you trust printing bank statements for all your customers on a Windows machine ?). Our old mainframe used to run 500 users, and had less power+disc than my Windows XP machine. Can I run 500 users on this PC ? No, certainly not under windows (any varient).

4) Reliability. Most cobol applications (one assumes) are running on mainframes (or super minis). As such uptime can be figured in months, (not days as a certain Software Suppliers average uptime for web servers is). With some runs of cobol programs taking days, do you want to run them on something that might crash half way through.

5) Functionality. Yes, some of the functions of some cobol programs could be re-developed in less time/space than they currently are. There are reasons people may not redevelop. Some are for cost. The old adage "if it ain't broke, dont fix it" applies. The code still functions, dont frig with it.

6) Code size. Older mainframes optimised their code very very well. Can you honestly say that modern compilers (ie MS) do so as well? Whats the odds that the 50KB cobol program will be 5MB when recoded, with DLL's and pretty graphics.

7) Other features, such as use of tape drives to read data from. Disc drives that do hardware searching for you (ie ICL mainframes had CAFS, which the controller was given selection criteria and it read the disc for data matching). Such technology is not available on modern PC's or Servers "off the shelf". Thus there may be hidden costs in duplicating the environment, or even migrating the old data to a new environment.

Where I work, we are leaving old systems where they are. New replacements are purchased that have the duplicated or similar functions. It is in most cases not cost effective to "port" old code over.

finally ..

8) Programmer availability. How many now learn cobol at school/college/university ? most are into Java, C++, etc. Who wants to learn a dead end language when you can have a nice language that is more modern and will earn you money (and look good on your C.V.) Cobol programmers are a dying breed.

This is not new news...

[madmarcel]

AFAIK when M$ developed .net, they studied a large number of programming languages (java, c++, cobol, etc) and then developed the .net languages from there. Now, all the .net languages are meant to be able to be compiled and executed using one single run-time environment, so in order to get that to work the .net languages have...'converged'. (Must avoid using the word 'assimilated' here ;)

Visual Basic and Visual C++ where very distinct languages. The .net languages are not.
VB.net has become more like java. C# has become more like java, etc etc. I have no doubt that COBOL.net will be exactly the same.

The point is: You cannot take a 10 year old COBOL program and expect it to be able to compile using COBOL.net. You will probably have to rewrite the entire application into a sortof half mishmash of COBOL, VB and java ( -> COBOL.net :)

I'm confused.

[smartin]

It allows for COBOL code to be integrated and manged with other code in Visual Studio.

Did the author intend to say managed or mangled ?

Re:Why not just recompile COBOL for Linux?

[lurker412]

Many of the old COBOL applications rely on other components of the IBM mainframe environment. CICS, IMS, MVS etc. are often required. It is not just a matter of compiler quirks. The entire environment would need to be emulated. Not trivial.

The issue is not COBOL..

[Garg]

As a guy who's done mainframe programming for 23 years, here's why I think this won't have much of an impact.

First, you have to understand this isn't simply an issue of porting something from one platform to another. If it were, it would've been done a long time ago. Anybody else remember when industry pundits were talking about the last of the mainframes being unplugged in 1999 so we wouldn't have to deal with with Y2K? Sure, a few places migrated off the 'frame, but not many. And I would argue that any company capable of doing so, did so before Y2K.

Basically, there are two types of COBOL systems on the 'frame:

• Batch. These are the payroll-type systems that run in the background, are are mostly ignored by people claiming to be able to migrate systems. The thing is, these systems are full of extensions for mainframe-type filesystems or databases, like VSAM or IMS. So while MicroFocus handles some of that stuff correctly, it won't handle it all.
  
  And if it did, what have you gained? I've heard it said that if Windows is a car, UNIX is a racecar... and z/OS is a semi. While Intel or minicomputer (sorry, that's prbably an outdated term) systems can match mainframe MIPS, they can't match its throughput. So suddenly your batch payroll that ran for ten minutes on the 'frame and churns out the paychecks takes all day. Don't think many companies will make that trade.
• Online. These programs run under CICS usually, sometimes IMS or (more rarely) non-IBM TP monitors. These systems have all sorts of calls specific to CICS or whatever. (For example, you can't read the file system directly under CICS.) So the Windows COBOL things usually follow the 80/20 rule here, as far as what will work... but the 20% will kill you. Things like background tasks to communicate with remote systems over an APPC connection. (If that last sentence made you go "huh?", you may realize it's what you don't know that will doom a project of this sort.)

And the open-source COBOL efforts handle none of the batch or online extensions, so they're almost useless for migrating any of these systems.

So basically you undergo a huge, years-long set of projects and by the time you're done, you may have something that's cheaper, but is most likely just less reliable.

Garg

Re:The issue is not COBOL..

[nzkoz]

Exactly, every single UNIX / linux fan who says 'Stuff mainframes, run *nix' has essentially missed the point. Sure you can port the COBOL code over, but without CICS, DB2, VSAM, IMS et. al. your code will be basically worthless.

I'm a unix guy, I have a huge financial incentive to support this kind of migration. But it's not going to happen. At the bank where I work, all new development is Java on Unix, that's fine and dandy but the backend systems with their huge Multi terabyte VSAM files won't be rewritten any time soon.

Circle Ten?

[sbaker]

Windows, .NET *and* COBOL? Looks like Dante missed a circle.

Re:People Actually Use COBOL?

[samael]

Nope, still runs the vast majority of the banks and financial instituations the world over.

The line you give isn't valid COBOL, but

SUBTRACT EXPENSES FROM REVENUE GIVING PROFIT

is.

But then

COMPUTE PROFIT = REVENUE - EXPENSES

would do the same. (You can use COMPUTE to do most algebraic functions).

Re:Why was COBOL so prevalent in the first place?

[Multics]

Not to mention the COmmon Business Oriented Language predates all the aforementioned languages by at least 20 years.

COBOL histories can be found here and here. For quite a while, the language that was available on all sorts of mainframes that addressed business was COBOL. Then one could use FORTRAN for doing engineering & science. All other languages were in the noise, were research projects, or were only supported by a single vendor.

Selecting COBOL made very good sense then and in some cases probably even makes sense now for some classes of applications. Move Corresponding still does a lot of work in a single statement. New editors make working with the verbage easy compared to the venerable 80-column card.

-- Multics

A joke.

[Mr_Icon]

On the eve of the New Year 2000, an old programmer went out of his house to go to a party, but was run over by a bus before he could get there. His vision went dark, but then he saw wonderful white light and people in white clothes leaning over him.
"Where am I?" he said.
As soon as he spoke, everyone started cheering and congratulating each-other.
"What is going on?" he said, amidst the brouhaha.
"You see, this is many thousands of years after your time," told him one man in a white labcoat. "The medicine has made huge advancements, and now we are able to revive people who have died millenia ago."
"Wow," said the old programmer, "this is really great. But why me?"
"Well, you see, this is the year 9999 -- we are facing the Y10K problem, and your resume said that you know COBOL..."

Talk about walking into a buzzsaw

[salesgeek]

There are two issues here: First, the question of mission critical Microsoft. Second, the question of moving your software.

If I were you, Mr. CIO, I'd avoid this little stunt. Mainframes and the software mainframes run exist in mainframe form for three reasons:

* Speed - Process more data in less time
* Accuracy - With less mistakes
* Reliability - and a minimum of downtime

In none of these areas does Microsoft have a credible track record. You simply have to look elsewhere. Anyone who goes with MS on this is putting their carreer at risk.

That said - would migrating off of Cobol to a more modern development environment make sense? That's a situational question, and one that has to be answered on a case by case basis. In some cases, legacy software is a competitive advantage. In others, it's a business obstacle. In most cases, there's no compelling reason to do or not to do.

Re:Why was COBOL so prevalent in the first place?

[Anne Thwacks]

40 years ago Cobol was the only horse in town. Cobol dates from the 1950s, C from the 1970s.

C is most definitely NOT any better than Cobol for what Cobol does. There is nothing actually wrong with Cobol for the applications in which it is used.

Cobol is actually capable of structured use. The problem is that SOME programs written in Cobol were written so log ago, that we didnt know then what we know now. Cobol is not the problem - the problem, such as it is, is that the code is very old. As for lack of Cobol programmers, I am damn sure that anyone who can learn Java can learn Cobol in half the time it them took to learn Java. If offered a suitable salary

As for "The mainframe it runs on is getting old" IBM

C0b0l is teh l33t

[UltraSkuzzi]

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. COBALISTEHL33T.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "What they think they d0ing?! C0b0l is teh l33t! Someone tell microsoft to go back to the crap 86, we don't need him with our cool VT100 world!"
LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.

Low Cost, Works unchanged, 30 years later

[Anonymous Coward]

I have Cobol Binaries that still work unchanged, 30 years later. They get written once, then forgotten because they just work.

OTOH MS is the opposite of maintainable - things MUST be rewitten and recompiled yearly, and tested frequently with near weekly patches. What a merrygoround.

IBM's MVS is low, low cost, and you NEVER have to rewrite, retest and migrate the application yearly, if you went down th MS path.

Why would step onto a upgrade treadmill, with open ended costs. Try getting MS to commit to binary backward compatibility for more than 5 years.

The real value of COBOL is that business rules are neatly locked up, and stable and in one place. Swapping one mainframe for 1600 MS servers will devalue business efficiency by being lost in an ocean servers, and that re-development and upgrade work overshadows core business activity that really brings in real revenue.

There is no shortage of COBOL coders - but a shortage of managers who seek and reward those with true maintenance skills. ie porting COBOL, or VB5 apps to C++ or C#, would also be cheaper and more enduring than .NET.

Support

[Detritus]

I would add longevity of support. Is the company going to support their current hardware and software products in 5 years, 10 years, 20 years? Microsoft, and many other companies, have a bad habit of pushing something for a few years and then ditching it, leaving their customers dangling in the wind. Microsoft has a long list of products and technologies that are no longer supported.

COBOL runs on Unix and Linux

[iggymanz]

just fine. MicroFocus is available on Linux and your Unix of choice (I've actually done healthcare adjudication app porting & integration on Linux, AIX, and HP/UX). It has a C API so you can go back and forth between any langauge that supports that (I did Java via JNI). Fujitsu also makes a kick-butt enterprise grade COBOL compiler for Linux & your Unix of choice, and I'm sure there's plenty others out there.

That being said, for 1,000's of users, the mainframe is still the cheapest for price/user. In the 10's to 100's of users, Unix or Linux on server grade machine is dandy.

heard about Object Oriented Cobol?

[Jamie Zawinski]

It's called "ADD ONE TO COBOL GIVING COBOL."

(Yes, this joke is at least 15 years old...)

Just what we needed

[foistboinder]

The stability of Microsoft combined with the elegance of COBOL.

Without JCL (& other stuff) it just won't matt

[PinchDuck]

Unless MS and MF have created a really good replacement for JCL, and the ability to seamlessly convert between EBCDIC and ASCII on the fly, and seamlessly access all the data stored in all the DASD in all the datacenters, gin-joints, and big-iron holdout citadels spread throughout the world, it just won't matter.
JCL is the biggest holdup, I would think. COBOL programs perform several steps to a piece of data, kick out output files, and pass control to JCL, which, depending on the return code of the COBOL, will call one of several different alternatives. Having one stinking program run on your PC and having to hand-code all the JCL into batch filesis a massive waste of time. Not to mention that JCL is far more robust then an MS-DOS batch file. Finally, most PC's just don't have the throughput to match an IBM Mainframe with DASD on channel. Finally, you can tell an IBM shop that Windows is far more stable then it was 10 years ago, but it still doesn't compare to a mainframe for reliablility _and_ stability. A Windows server with five 9's reliablity isn't worth shit if the registry is corrupted. That just doesn't happen on mainframes.

In My Day...

[tspauld98]

good software engineering meant using the right tool for the right job. Only a web script kiddies with no mainframe exposure or experience would think this story is newsworthy. Every company or organization that I've had experience with and that has a mainframe always laughs at the idea that they would migrate anything off host. Just because Big Blue originally hired MS to do software has always translated to MS that they can play in this market. I like to quote Charlton Heston whenever somebody suggests that they are going to take my mainframe away, "from my cold, dead hands!!!"

oh, and btw, I'm not a COBOL programmer. just someone who respects them enormously. Props to the host team!

tims

If FORTRAN is a forcast ...

[twitter]

M$ COBOL will be a one way sink that won't last long. That's right, M$ I still remember how you waded into FORTRAN, added nifty little toy tools without getting the basics right and then sold it like a hot potato to Digital where it rested in peace. Another fine member of the Visual Studio. Pththth-fit!

Anyone tempted to migrate from their current platform and tools should look at the way things turned out in scientific computing. Efforts like f2c and g77, the GNU FORTRAN compiler, are far superior. Libraries available as Debian packages are also great. The differences are only getting larger as more people are attracted by the tools available. And yes, you can have a beowolf cluster of those. Microsoft had it's ass handed to them.

Re:Try x86 assembler.NET :)

[Leeji]

That reminded me of a web page I saw once, which took a lot of Googling to find.

In some perverse sort of way, this .NET web page using x86 assembler is beautiful :)

Re:Why was COBOL so prevalent in the first place?

[dasmegabyte]

It's always funny to me how much most managers in our field consider LANGUAGE to be the barrier to most tasks, when my experience it's really more a matter of knowledge of the type of code you're interfacing.

If you've written procedural code to process transactions in any language, from C to FoxPro to bleedin' VB Script, you should be able to manage COBOL code to process them with a good book and about a week's worth of "high error hacking." The language isn't the problem...it's the type of business logic employed, the type of parsing, the tricks used in that type of programming that really hold you up. The language is just a red herring.

And yet, the first thing people ask you is, "Do you know XxXxX language?" What they should be asking is, "Do you know a language LIKE XxXxX and have you experience in the field of YyYyY?"

Hiring based on task and not on "langauge" is something the industry is just now coming around to, and I think it's due to years of C programmers forced to sit on their thumbs because they knew how to write printer drivers but had never opened a window in their life.

You forgot the codebase is growing

[Lawrence_Bird]

by 5B lines per year, which is quite impressive.


You could have known this 5 days go though... # 2003-11-04 15:43:28 Microsloth courts COBOL (articles,microsoft) (rejected)

Re:.NET and C#

[corsec67]

Unfortunatly, C# is tied to the platform. The mono project is trying, but most of your .NET class library is not going to be ported by Microsoft to linux, so I don't think that .NET will help you much.

Now, I FAR prefer C# the language to Java the language, but C# is tied to a platform.

many factors

[Anonymous Coward]

I/O Throughput wise, SGI (silicon graphics) is king, but mainframes have a lot of interesting capabilities for 'application throughput'

OS: Lack of generality and portability in the OS lets you cut down overhead in servicing the hardware.

FS: Filesystems that are less general but tailored towards particular needs

TP: transaction subsystems tend to be less general than oracle or relational DBs but the simplicity allows speed and they can also be integrated with the OS, so there are less layers.

Hardware: Multiple busses, multiple controllers, specialized subsystems (IO processors, crossbar backplanes); this is available on bigtime UNIX systems as well.

Re:.NET and C#

[big-giant-head]

"C# applications generally outperform their Java counterparts by a large margin."

On what?? I find my java programs perform quite well on a 25 cpu *nix box....

Thats the problem with .NOT it only works on M$ and Intel CPU's.

Right now we are replacing a COBOL app with a cluster of big boxes running Java and Webspere. The nice thing is if we are unhappy with IBM, we could easily move to Sun Sparcs and Weblogic with very little changes to our app. Can't be done with .NOT you have your choice of Windoze or Windoze running on intel or amd.

Alot of big business are very pissed right now with MS over thier licensing and how virus prone thier OS is.

Add to this the fact that most COBOL code is written to a very specific hardware implementation. Most companies will eventully choose to rewrite thier COBOL apps, and given the previous reasons many of them won't even look at MS.

And worse...

[BrokenHalo]

I have Cobol Binaries that still work unchanged, 30 years later. They get written once, then forgotten because they just work.

I've seen a number of high-profile sites where 30-year-old binaries are still in use too; in some cases the source code was lost years ago, and the things were only maintainable by directly editing the object code.

It's not much fun to do that with COBOL compiler output, but it's do-able and saves a lot of time.

Yes, I'm that old. Want to make something of it? :-D

20 years

[Simple-Simmian]

In 20 years COBOL will still be around and .NET will be gone.
The Machines dealing with my water, power and banking were using this code in the 1970's and they still are.
It's cheaper than doing it the BillG way.

Message from earth to BillG and MonkeyBoy.
Before you start this battle it's over already.
These guys shilling for you on this are wasting their time.

Re:old-skool programming

[vidarh]

If it aint broke, don't fix it. Not many new applications are written in COBOL, but vast amounts were written, debugged and got to the point were they are business criticial. You don't rewrite business critical software in a different language unless you have a VERY good reason (translation: not unless you NEED to do changes that are so massive that rewriting the system from scratch and spending years getting the bugs out of it is worth it).

"Lazy" doesn't come into it - you'd be incompetent if you suggested someone rewrite a working system if the only reason is some perceived notion that the language is outdated.

Solution:

[master_p]

A Cobol-to-C++ translator.

From what I can see, Cobol is a procedural language, so it could be easily translated to C++ (no need to uses classes, just the functional part).

There is already a GCC backend, which means that Cobol maps to C++ perfectly.

And those 'goto' statements can be made as functions.

The translator app should also allow which database engine and library to use; the Cobol code that does database I/O would be replaced with calls to this engine.

This translator app could be made as backend to GCC: the Cobol compiler could produce C++ code instead of assembly code.

Re:old-skool programming

[gatkinso]

I can name several kludges and shortcomings of every technology you listed.

In 20 years my infant son will look at my code and "think WTF is this antique?"

But back to your point... a company with, say 2 million lines of cobol running on a mainframe that runs almost flawlessly. No major problems. Now, rewrite that code in something more modern, and redeploy on a more contemporary platform.

How long will this take? How much will it cost?

More importantly, how much more bread will it help that regional bakery (for example) sell?

Grrrrr!

[nurb432]

Cant these bastards leave anything alone? Do they have to conquer and destroy *everything*?

We don't need them anywhere near COBOL. They have no business here. COBOL is stable,
proven, supportable, and run on REAL machines.. not kiddy toys.

Someone needs to take these people out before they assimilate the entire planet. Someone needs
to start at the top, if you get my drift

Economics 101 people!!

[DukeyToo]

All of the arguments about I/O, porting code etc are pointless, because it eventually comes down to economics. If a company is spending $1,000,000 per year maintaining a mainframe, with code that can no longer grow, then there will come a time when they can no longer be competitive - they will have a huge overhead compared to their competitors, and will not be able to respond to market changes.

Mainframes *will* go away, *except* where there is not enough competition, or the cost of the mainframe is small in comparison with other cost centers.

I think that big banks will keep their mainframes, but eventually smaller, more agile banks will grow enough that the bigger banks can no longer compete. Then the big bank will either migrate or die.

They can keep it

[carldot67]

Confession: Many years ago I was a COBOL programmer at several big mainframe shops.

And I gotta tell you folks, Microsoft are welcome to it. It's a God-Awful language fit only for financial and other business applications. And for those who think financial applications are trivial, hence worth the pain of COBOL's God-Awfulness - think again. Financial apps are always having to react to changing rules, regulations and the latest fad from sales and marketing. Believe me (I have done both) molecular simulation is EASY compared to a large corporations general ledger. At least the value of PI never changes.

Example: A well-known US retail company's W10(? - USA tax) program comes to mind that I worked on briefly before skilfully offloading to some other poor sucker.

Check this out:

No specs

No doco

Some of it was in mainframe assembler

Object orientated? ha ha ha

Structured programming? oh my god ha ha ha

Code re-use? stop it! im pi**ing myself!

Variable names like W88_REC (erm, thats it) and code that was all over the place. GOTOs. GOTOs!

Example - every year the US states tinker with their tax levels. Sometimes, especially in the smaller states one guy is taxed in one state, but works in another, except on wednesdays if its raining and so on. So we had code everywhere that looked like this:

IF WS-STATE = 'TX'
THEN PERFORM U201-STATE-TX-W10
ELSE
IF WS-STATE = 'NH'
AND WS-HOME = 'NY'
THEN...
(and so on for 48 other states)

I think you get the picture.

Screw that.

Then there is that reliability issue. Microsoft OSs struggle to match Linux/BSD when the going gets a bit sticky. The level of reliability expected from a mainframe is another world altogether. I remember an old story about an IBM engineer who somehow managed to yank a whole chunk of memory from an OS390 core. Apparently that old chunk of iron soldiered bravely on for TWENTY minutes before ops' screens went red and it finally gave up the ghost, having cleanly swapped out all running processes and parked all the disks. Now THAT is a stable operating system and Im not even an IBM fan.