Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Microsoft Makes Push for COBOL Migration

Cliff posted more than 10 years ago | from the trusting-your-legacy-code-to-.NET dept.

Microsoft 487

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


GNAA Announces responsibility for kernel backdoor (-1, Troll)

Anonymous Coward | more than 10 years ago | (#7430575)

GNAA Announces responsibility for kernel backdoor
By Tim Copperfield
Raleigh, NC - GNAA (Gay Nigger Association of America) this afternoon announced one of their loyal members was responsible for planting the "backdoor" inside the popular opensores operating system, Lunix [redhat.com] (Stocks [yahoo.com] , Websites [google.com] ).

In a shocking announcement this afternoon, GNAA representative goat-see revealed that the mistery hacker who penetrated high-security defenses of the Lunix "source code" repository and injected viral gay nigger seed deep inside the kernel was indeed a full-time GNAA member.
"This is serious," goat-see began. This is a first event of such magnitude since GNAA opened its doors to new members in 1996. Until now, we were gathering new members by announcing our group information on a popular troll website, slashdot.org [kuro5hin.org] , but this is a whole new era. By injecting our holy gay nigger seed right into the Lunix kernel, we will be able to immediately collect thousands of members. "Make the most of the next six weeks," he added. "We will grow in numbers more than you can possibly imagine".
Insertion of the GNAA backdoor came right between the consideration of Novell [novell.com] to buy out the entire Lunix Kernel programming team, and will most likely positively affect the decision. By adding all the gay niggers working for Novell with the gay niggers developing Lunix kernel source, GNAA will be all-powerful and will begin plotting our next plans to add "backdoors" into the next favorite operating system, BeOS [microsoft.com] .

About GNAA
GNAA (GAY NIGGER ASSOCIATION OF AMERICA) is the first organization which
gathers GAY NIGGERS from all over America and abroad for one common goal - being GAY NIGGERS.

Are you GAY [klerck.org] ?
Are you a NIGGER [mugshots.org] ?
Are you a GAY NIGGER [gay-sex-access.com] ?

If you answered "Yes" to all of the above questions, then GNAA (GAY NIGGER ASSOCIATION OF AMERICA) might be exactly what you've been looking for!
Join GNAA (GAY NIGGER ASSOCIATION OF AMERICA) today, and enjoy all the benefits of being a full-time GNAA member.
GNAA (GAY NIGGER ASSOCIATION OF AMERICA) is the fastest-growing GAY NIGGER community with THOUSANDS of members all over United States of America. You, too, can be a part of GNAA if you join today!

Why not? It's quick and easy - only 3 simple steps!

First, you have to obtain a copy of GAY NIGGERS FROM OUTER SPACE THE MOVIE [imdb.com] and watch it.

Second, you need to succeed in posting a GNAA "first post" on slashdot.org [slashdot.org] , a popular "news for trolls" website

Third, you need to join the official GNAA irc channel #GNAA on EFNet, and apply for membership.
Talk to one of the ops or any of the other members in the channel to sign up today!

If you are having trouble locating #GNAA, the official GAY NIGGER ASSOCIATION OF AMERICA irc channel, you might be on a wrong irc network. The correct network is EFNet, and you can connect to irc.secsup.org or irc.isprime.com as one of the EFNet servers.
If you do not have an IRC client handy, you are free to use the GNAA Java IRC client by clicking here [nero-online.org] .

About Lunix
Lunix is an operating system. An operating system is the basic set of programs and utilities that make your computer run. Some other common operating systems are Unix (and its variants BSD, AIX, Solaris, HPUX, and others); DOS; Microsoft Windows; Amiga; and Mac OS.
Lunix is Free Software. Now, just because it's Free, doesn't necessarily mean it's free. Think "free" as in "free speech," not "free beer," as we in the Free Software/Open Source community like to say. In a nutshell, software that is free as in speech, like Lunix, is distributed along with its source code so that anyone who receives it is free to make changes and redistribute it. So, not only is it ok to make copies of Lunix and give them to your friends, it's also fine to tweak a few lines of the source code while you're at it -- as long as you also freely provide your modified source code to everyone else. To learn more about free software and the major software license it is distributed under, called the General Public License (GPL), go here [com.com] .

If you have mod points and would like to support GNAA, please moderate this post up.
By moderating this post as "Underrated", you cannot be Meta-Moderated! Please consider this.

| ______________________________________._a,____ |
| _______a_._______a_______aj#0s_____aWY!400.___ |
| __ad#7!!*P____a.d#0a____#!-_#0i___.#!__W#0#___ |
| _j#'_.00#,___4#dP_"#,__j#,__0#Wi___*00P!_"#L,_ |
| _"#ga#9!01___"#01__40,_"4Lj#!_4#g_________"01_ |
| ________"#,___*@`__-N#____`___-!^_____________ |
| _________#1__________?________________________ |
| _________j1___________________________________ |
| ____!4yaa#l___________________________________ |
| ______-"!^____________________________________ |
` _______________________________________________'

Bah humbug... (4, Insightful)

tehdely (690619) | more than 10 years ago | (#7430576)

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... (5, Interesting)

Anonymous Coward | more than 10 years ago | (#7430641)

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... (3, Insightful)

Anonymous Coward | more than 10 years ago | (#7430744)

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.


Re:Bah humbug... (5, Interesting)

darnok (650458) | more than 10 years ago | (#7430683)

> 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.

if it ain't broke, don't fix it! (4, Interesting)

kraksmoka (561333) | more than 10 years ago | (#7430742)

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! (2, Interesting)

Anonymous Coward | more than 10 years ago | (#7430766)

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:Bah humbug... (4, Insightful)

ericman31 (596268) | more than 10 years ago | (#7430778)

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.

Incorrect (0)

Anonymous Coward | more than 10 years ago | (#7430700)

COBOL applications are generally deployed in base 185B.

Props to MAUS, G4b3, Davez0r, the Memory Of Dave-o, Ponch, AXJ, Matt's mom, and myself, Marc The Pirate.

Re:Bah humbug... (1)

UniverseIsADoughnut (170909) | more than 10 years ago | (#7430726)

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

Yes, but it's old big Iron. So in many , if not most cases, that mainframe can be replaced by a small server or even a desktop.

Re:Bah humbug... (1, Interesting)

Anonymous Coward | more than 10 years ago | (#7430729)

Having talked with employees of companies that develop banking solutions with windows farms, (BankOne, Londong Bridge, etc) the biggest reason why they stay in the small to medium business market is because the HARDWARE can't keep up, not the software.

Mission critical applications can be run in a windows environment. In 4-5 years I wouldn't be surprised if the hardware will be at a point that it can match the performance of a mainframe, for much less cost.

Re:Bah humbug... (1)

brrrrrrt (628665) | more than 10 years ago | (#7430792)

Don't be too quick to assume.. I couldn't believe this myself when I first heard, but I recently learned that the majority of teller machines runs on Windows.

More Links Needed (0, Funny)

Anonymous Coward | more than 10 years ago | (#7430580)

Requesting more links in the story; Not enough blue clicky things.

frist piss (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7430581)

i'm pissing in taco's mouth

As much as I hate MS this is very smart. (2, Insightful)

Ken Broadfoot (3675) | more than 10 years ago | (#7430587)

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


Re:As much as I hate MS this is very smart. (4, Funny)

Jameth (664111) | more than 10 years ago | (#7430632)

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. (1)

obsidianpreacher (316585) | more than 10 years ago | (#7430647)

You have to admit, this is the most innovative thing Microsoft has done. Ever.
What you mean? There was the ... wait, no, that was done by Xerox. How about the ... nope, Apple, that time. Well what about ... hmm, nope, that was Mosaic. Well, there's always the ... no ... not even sure who did that, but it wasn't Microsoft.


Hmm ... sad to say, but I think you're right!

Re:As much as I hate MS this is very smart. (4, Insightful)

ericman31 (596268) | more than 10 years ago | (#7430651)

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. (2, Interesting)

asifyoucare (302582) | more than 10 years ago | (#7430679)

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

I assume the parent had his tongue firmly in his cheek, but I don't have any mod points for +1 funny.

This is an initiative from MicroFocus rather than from Microsoft. I'm sure that MS would love to have those big-iron applications ported to their platforms, but it probably isn't going to happen.

People want to migrate from the language, not from their platforms. C/C++ and Java are good candidates for these applications, particularly on 64-bit chips (think big dollar amounts represented as cents).

Microfocus specialises in PC COBOL, so this move to integrate with Visual Studio makes sense for them, but they'll remain a niche player. I expect most of their sales are to poor business students who have to endure a semester of COBOL.

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

Anonymous Coward | more than 10 years ago | (#7430773)

Q. Who is the smart one? The small company who maintaines legacy asset's that is getting a load of free publicty or the large company who wants a slice of the action?

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

Anonymous Coward | more than 10 years ago | (#7430803)

Yes, I agree Microsoft are being smart but not that smart given that Microsoft used to license Micro Focus COBOL and badge it as their own. So they are not exactly getting *all* the profit they could have been getting... Q. Why did'nt they just license Micro Focus Net Express with .NET as Microsoft COBOL for .NET?

hi (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7430589)

i love slashdot

Just announced... (5, Funny)

fredbox (207869) | more than 10 years ago | (#7430591)

Microsoft Visual COBOL++.NET 2003

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

What about (2, Funny)

bersl2 (689221) | more than 10 years ago | (#7430654)

COBOLScript in the next version of IE?

Re:What about (1)

rekkanoryo (676146) | more than 10 years ago | (#7430708)

And COBOL++Script in IE 9.0 (two revisions of Windows after Longhorn) to throw in the object orientation.

Re:What about (0)

Maxhrk (680390) | more than 10 years ago | (#7430751)

i will bet my $50 bucks said that there is (insert large way-over-head numbers here) vulterbilities. No doubt Ms blaster author is eager to blast M$ once more. See?! microsoft is doomed to be victim of it.

Businessmen are smart (-1, Troll)

RoadkillBunny (662203) | more than 10 years ago | (#7430592)

Why would anyone trust their business to Microsoft? They update your computer to the newest patches without your permssion. While this might be good for the average idoit, I mean Microsoft user, it isn't good for a company. I mean why should they modify your computer without you permssion? You owe they computer, they don't... No wait, they owe YOU


Re:Businessmen are smart (0)

Anonymous Coward | more than 10 years ago | (#7430612)

Learning the difference between "OWE" and "OWN" might be something you should look into.

Re:Businessmen are smart (0)

Anonymous Coward | more than 10 years ago | (#7430648)

You should really not be such a troll. If you knew anything about Microsoft and their automatic updates, you will know that:

1: In it's current default setting, Microsoft Windows Update manager only downloads and does not force you to install anything.

2: Most home users do not use this feature to install anything, leaving them open to security vulns. I've heard that MS is thinking about having the default setting be to auto-update instead of just download. Please note that this is configurable, and if you really don't want to install the patches cause you're a complete moron, then you don't have to.

3. Businesses have multiple ways of dealing with auto update. The first is that most businesses don't load XP straight from CD onto the machines. They create images and use those images to install the machines with the software their employees will need for their job. In other words, businesses have the ability to make the image itself not have this feature turned on if they don't want to. For a small business who does install straight from CD because they don't have the resources to manage images and such, well, it's just a couple clicks away to change it.

4. Corporations with things like the AD have something called GPO (or can use it) - that enables them to force installation of patches and other things at logon or at other times. Alternately, they can use logon scripts to do it.

5. IIRC, corporations also have control over what windows update site their computer go to. They can host an internal windows update site which only has approved patches on it. This way, the IT guys determine what is needed and what isn't and only the approved patches are there for their employees to install.

Disabling auto-update and requiring installation via GPO or installation scripts is probably the best choice for businesses. It allows for the IT deparment to decide what gets installed and what doesn't.

And remember, these features can always be turned off.

So stop trolling.

Re:Businessmen are smart (0)

Anonymous Coward | more than 10 years ago | (#7430808)

The average idiot should be able to spell idiot. Someday, you too may be an average idiot, if you work hard at it.

manged?? (4, Funny)

Anonymous Coward | more than 10 years ago | (#7430594)

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

I think the correct spelling is mangled.

Re:manged?? (0)

Anonymous Coward | more than 10 years ago | (#7430616)

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

I think the correct spelling is mangled.

No, it's KOBOLD.

Fucking /. (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#7430596)

Move along dorks, nothing to see here.

Haven't you fuckoes got anything better to
do than complain about M$ all day? Go out
and write some fscking code for a change.

You fucking whinning fucks.

Re:Fucking /. (-1, Offtopic)

RoadkillBunny (662203) | more than 10 years ago | (#7430609)

You are right, I got better stuff to do. But why shouldn't I be allowed my fun time swearing at Microsoft as you get fun time swearing at us? I can code, but not while on Windows. That stupid program crashes when I try to reboot and keeps running...


Re:Fucking /. (0)

Anonymous Coward | more than 10 years ago | (#7430745)

Seems to me every single /. user who does not use Windows has no idea even how to use this simple OS. I haven't crashed but one time in 18 months and reboot only when I want to on all 5 of my Win2K machines. The one crash was my fault for installing Yahoo IM. I have an NT server with an uptime from the day SP5 came out. I laugh every time I hear someone say they can't make MS work more than 1 hr at a time.

Better than whining about whining... (0)

Anonymous Coward | more than 10 years ago | (#7430701)

Don't you think?

Re:Fucking /. (1)

ninejaguar (517729) | more than 10 years ago | (#7430733)

Jesus, Bill, if you're posting on /., who's running MacroShaft? Your robotic employees might starting forming their own opinions without you behind the whip. What the hell were you thinking?

= 9J =

hog wash (3, Interesting)

Anonymous Coward | more than 10 years ago | (#7430600)

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.

Re:hog wash (1)

iksrazal_br (614172) | more than 10 years ago | (#7430811)

"that is such a joke, migrate Cobol to .NET."

Agreed. There a culture in the works here. I have to connect to these Cobol/Natural mainframe montrosities with Java and C in the Brazillian government. And those 40 something types who wrote that complex nastiness are now managers with turf to protect.

Need some comic relief? Imagine those same people whose sole purpose is to get the same weekly paycheck, betting their ass by removing those mainframes they love and replacing them with their Windows boxen that get a virus a week. .Net? They've never heard of it - Java's been around a lot longer and they haven't even got there yet.

How long is legacy? I`ve seen lots of projects get cancelled trying to replace it.


.NET and C# (0)

Anonymous Coward | more than 10 years ago | (#7430601)

I really like .NET - I find that the .NET class library is both wide and deep and that C# applications generally outperform their Java counterparts by a large margin.

I have to give MS credit here - .NET is an excellent platform, and Visual Studio .NET is a powerful, easy-to-use IDE.

200 billion lines? (3, Funny)

Lxy (80823) | more than 10 years ago | (#7430602)

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

Re:200 billion lines? (2, Funny)

McSnarf (676600) | more than 10 years ago | (#7430660)

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.

COBOL migration (2, Informative)

bersl2 (689221) | more than 10 years ago | (#7430613)

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

Just from browsing freshmeat: OpenCOBOL [freshmeat.net]

Yeah right.. (0)

Anonymous Coward | more than 10 years ago | (#7430615)

Well, at least cobol is a simple language. They might actually get it right.

I can't honestly see any reasons why anyone would want to work on an open source project to migrate cobol systems... The only people with any stake in this are big businesses.

Oxymoronic (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#7430622)

You write "open source" and market in the same sentence, as if the two have anything to do with one another. There is no "lost" market; there is no market at all when you give it away.


Yikes (1)

gss (86275) | more than 10 years ago | (#7430623)

Who in their right mind would migrate that much COBOL? If it's currently running on an old mainframe I would think it's a really big risk to migrate existing code onto a new platform, one would be better off leaving it on the mainframe until peices of it could be rewritten in a more modern language. Glad I'm not on any of those projects.

Re:Yikes (5, Interesting)

ericman31 (596268) | more than 10 years ago | (#7430711)

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.

Oh no! (5, Funny)

Danathar (267989) | more than 10 years ago | (#7430625)

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!

Re:Oh no! (1)

tb3 (313150) | more than 10 years ago | (#7430674)

And I call Visual Basic "The COBOL of the nineties". Produced the same kind of spagetti-code legacy apps that COBOL did.

And by the way, Visual COBOL is either a MicroFocus or Microsoft product.

Re:Oh no! (1)

dbIII (701233) | more than 10 years ago | (#7430785)

BASIC was literally almost DEAD until microsoft came out with Visual Basic.
No, pascal was almost dead until it was revived in the form of visual basic - and the new version looks a lot like java to me now.

Why would you? (4, Interesting)

msgmonkey (599753) | more than 10 years ago | (#7430626)

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? (1)

HermesT (694672) | more than 10 years ago | (#7430690)

msgmonkey wrote:
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.
Many programs have to be extended now and again to perform new tasks because the as the world changes requirements do too. Also, coders don't want to write any new code in old fashioned languages (like COBOL). That being said, its easier to write extensions in the same language as the rest of the program, for many reasons. For instance: 1) with a single language, any interface can be used by all parts of the program. 2) The same debugger can be used to identify bugs throughout the entire program 3) coders don't have to think in multiple languages. Since modern-day coders don't want to write extentions in cobol and don't want the hang-ups of dealing with two languages at once, migrating old programs into a new languages is reasonable.

Re:Why would you? (5, Interesting)

Tablizer (95088) | more than 10 years ago | (#7430716)

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?

tinycobol exists (1)

pantherace (165052) | more than 10 years ago | (#7430630)

sourceforge webpage [sourceforge.net]

Doesn't implement everything. Judging from the state of a university, much of the cobol stuff needs to be replaced, because to get useful things out of it requires all sorts of research, because very very few people know how to write it without breaking systems in use for 20 years or so, that do work.

Of course, what they are replacing it with often has a worse reputation (in one instance a university is going with peoplesoft, a program dumped by another university in the state because for the same thing, it wouldn't work well at all)

opensource cobol (1)

Janek Kozicki (722688) | more than 10 years ago | (#7430634)

there are at least two of them: OpenCOBOL [freshmeat.net] , TinyCOBOL [freshmeat.net]

can anybody imagine all those COBOL proffesionals (all at twice my age) migrating to something new, just because it's new?

bullshit, it all works now, who needs changes?

Re:opensource cobol (0)

Anonymous Coward | more than 10 years ago | (#7430658)

can anybody imagine all those COBOL proffesionals (all at twice my age) migrating to something new, just because it's new?

Can you imagine all these COBOL profesionals who are twice your age being retired or dead in the next 20 years?

Sounds about right... (3, Funny)

dillon_rinker (17944) | more than 10 years ago | (#7430640)

...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... (3, Funny)

jvollmer (456588) | more than 10 years ago | (#7430685)

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... (4, Interesting)

checkitout (546879) | more than 10 years ago | (#7430649)

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? [informationweek.com]

Re:Speaking of Gartner... (1, Insightful)

Anonymous Coward | more than 10 years ago | (#7430725)

And Microsoft advertises of Slashdot.

So what's your point again?

Yeah, this isn't so interesting, really. (2, Insightful)

King_TJ (85913) | more than 10 years ago | (#7430650)

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. (2, Insightful)

Jeff DeMaagd (2015) | more than 10 years ago | (#7430699)

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.

Don't hold your breath... (5, Insightful)

Dinosaur Neil (86204) | more than 10 years ago | (#7430652)

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.

Re:Don't hold your breath... (1)

The Snowman (116231) | more than 10 years ago | (#7430718)

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...

This is the problem. Why fix it when it already works and the people who understand how to work on it are retiring and dying from old age? And the fact that mainframes are a huge scam? For example, take the Unisys mainframe where I work. We do not own it, we rent it. It sits in a room. We get to use less than half of its power. CPUs and hard disks sit idle. If we want access to them, we get to pay more money to Unisys for something we already have.

Big iron has its advantages, but cost is a huge disadvantage. I would rather run a small cluster of commodity (x86) hardware, where labor is cheap and easy to come by, than a mainframe where labor is expensive and hard to come by.

Economics (1)

Detritus (11846) | more than 10 years ago | (#7430782)

It's not a scam, it's simple economics. It's cheaper for Unisys or IBM to design and ship fewer unique hardware configurations. That's why you get CPUs and other devices that can be upgraded by changing a jumper or loading a new set of microcode. Many calculator manufacturers do something similar. They crank out millions of generic calculator boards. The actual model and feature set is determined by the case and keyboard.

Re:Don't hold your breath... (1)

cactopus (166601) | more than 10 years ago | (#7430794)

Plus nobody seems to consider the premise that mainframe systems perhaps... "aren't dying."

Everything has its ups and downs like the business cycle. Mainframes were big... then horizontal scaling and PC's... now mainframes are coming back in a big way. With a brand spanking new z series box you can have virtual Linux boxen by the 100's or 1000's... and you get IBM's rock solid reliability. So TCO goes up on price of single box and way way down on prices of MANY pieces of hardware that are replaced over and over and over again, man-hours of support, babying, nurse-maiding, trying to adapt projects to a different design mentality, etc., power consumption of x 1000 PC's, software license costs (for the Windows route and also for middleware) on a x boxes scale rather than buy what you need scale... hmmm.

People like to ignore mainframes because they "taste" old... they're not gadgety for the whiz bang kiddiez , they don't do DirectX gamez, and most of all they're too complex for the new crop of compsci students that garbage uni's are turning out these days to wrap their feeble minds around.

Manged (2, Funny)

Nemi (627009) | more than 10 years ago | (#7430666)

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

From dictionary.reference.com:

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

Gotta love a binary shreader...

Please proofread before posting! (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#7430669)

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

Clearly you meant mangled.

Algol 58 ? (1)

polyp2000 (444682) | more than 10 years ago | (#7430670)

Is that some sort of Joke ?

I think linus should push for an Algol 58 port for the linux kernel. I mean we can't be outdone by the big boys at redmond.

I couldnt resist

Market analysis or wishful thinking (2, Insightful)

Space cowboy (13680) | more than 10 years ago | (#7430671)

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....


Why was COBOL so prevalent in the first place? (0)

Anonymous Coward | more than 10 years ago | (#7430673)

I don't know much about COBOL, how did it become the main language for mainframes 20 years ago? C was around then, right?

Re:Why was COBOL so prevalent in the first place? (-1)

Lxy (80823) | more than 10 years ago | (#7430760)

the simple explanation:

A language was needed for "business" programmers. C++ was too complex and too picky for mere mortals to code in, and BASIC, well, why would you write a business app in a language that screams "I'm for beginners!"?

COBOL was born to give non-programmers a language that was easy to code and easy to read. It was a dumb idea from the start, and look where we are today....

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

Anonymous Coward | more than 10 years ago | (#7430816)

Uhh, I don't think C++ was around before Cobol.

Re:Why was COBOL so prevalent in the first place? (1, Informative)

Blair16 (683764) | more than 10 years ago | (#7430814)

COBOL was originally designed by the military to be a language that even managers could read and understand exactly what was happening. The original COBOL specification didn't even have comments!! Statements looked like this:

add this to that giving something-new.
multiply x by y giving z rounded. perform function until condition.
stop run.

Statements are called sentences. Groups of statements are called paragraphs. You get the picture. The reason that it became so popular was because it was designed by the military, and they coded everything in it. Then when those coders went to go work in the corporate world, they took COBOL with them.

Better solution exists (2, Informative)

Anonymous Coward | more than 10 years ago | (#7430675)

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).

The Latest From Microsoft R&D... (3, Funny)

cmacb (547347) | more than 10 years ago | (#7430696)

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?.....

interesting mentality (2, Insightful)

Animaether (411575) | more than 10 years ago | (#7430739)

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.

Why not just recompile COBOL for Linux? (1)

Theovon (109752) | more than 10 years ago | (#7430749)

I've noticed /.'ers mentioning two COBOL compilers (OpenCOBOL and TinyCOBOL). It makes me wonder why more mainframe COBOL apps aren't just redeployed on Linux. No rewriting, nothing. How hard could it be to write a COBOL compiler that also inserts code to emulate quirks of the old OS and compiler?

I'm surprised this doesn't happen more often.

Indeed, one idea that seems obvious to me is to create a shell and environment that runs under GNU/Linux which looks and acts like the mainframe interface, except that when you compile COBOL (or other languages), it compiles to native (ie. x86) machine language.

Re:Why not just recompile COBOL for Linux? (3, Informative)

lurker412 (706164) | more than 10 years ago | (#7430789)

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.

Re:Why not just recompile COBOL for Linux? (1)

ksi440 (691272) | more than 10 years ago | (#7430818)

COBOL is just the beginning of the story. They would have to:
  • port JCL to shell scripts
  • Move from CA-7 to cron
  • create COBOL libraries/intrinsics to emulate tape interfaces, record-based( not stream ) files, console alerts, etc, etc
  • figure out how to move from modular, role based security like RACF or TopSecret to a less integrated uid/guid/file permissions based model
  • on and on, and on and on.
While there are parts of the mainframe world that are archaic, there's other parts that are much more mature than linux. It's not just a recompile.

Inertia, maintenance and programmers (5, Insightful)

Anonymous Coward | more than 10 years ago | (#7430753)

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... (4, Insightful)

madmarcel (610409) | more than 10 years ago | (#7430757)

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. (2, Funny)

smartin (942) | more than 10 years ago | (#7430786)

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 ?

The issue is not COBOL.. (5, Insightful)

Garg (35772) | more than 10 years ago | (#7430791)

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.


People Actually Use COBOL? (1)

Beg4Mercy (32808) | more than 10 years ago | (#7430817)

I had a professor who told me that the following is an actual valid line of code in COBOL:


Is this actually true or was he bullshitting us? Why would anybody turn a simple mathematical statement into something so long to type? He also told us "COBOL is a dead language designed to allow middle-managers program early computers without knowing what they were actually doing." I believe him. In retrospect, he was biased, but he was sure funny to listen to.

Excuse my ignorance, but: People still actually USE COBOL??

I thought it died along with vacuum tubes. :)
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account