Microsoft Makes Push for COBOL Migration 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."
Bah humbug... (Score:5, Insightful)
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
Anybody who migrates to
How seriously do you think this will really be taken up? I posit: "not much".
Re:Bah humbug... (Score:5, Interesting)
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... (Score:3, Insightful)
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... (Score:4, Informative)
Re:Bah humbug... (Score:4, Informative)
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... (Score:3, Insightful)
Re:Bah humbug... (Score:5, Informative)
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... (Score:3, Interesting)
Re:Bah humbug... (Score:5, Interesting)
> 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
- 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,
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! (Score:5, Interesting)
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! (Score:2, Interesting)
Re:if it ain't broke, don't fix it! (Score:5, Funny)
Re:if it ain't broke, don't fix it! (Score:3, Informative)
First off, "solid state" means "no moving/mechanical switching", which a room full of relays does not fit the definition of.
Re:Bah humbug... (Score:5, Insightful)
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... (Score:3, Insightful)
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 Microfo
Re:Bah humbug... (Score:2)
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... (Score:3, Insightful)
Re:Bah humbug... (Score:3, Insightful)
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 wh
Re:Bah humbug... (Score:3, Insightful)
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 thos
Comment removed (Score:4, Insightful)
Re:Bah humbug... (Score:3, Interesting)
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 ove
Re: (Score:3, Insightful)
Re:Bah humbug... (Score:3, Insightful)
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... (Score:3, Interesting)
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 inte
As much as I hate MS this is very smart. (Score:2, Insightful)
--ken
Re:As much as I hate MS this is very smart. (Score:5, Funny)
Re:As much as I hate MS this is very smart. (Score:5, Insightful)
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. (Score:4, Insightful)
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. (Score:3, Insightful)
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
Re:As much as I hate MS this is very smart. (Score:5, Interesting)
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.
Re: (Score:2, Interesting)
Just announced... (Score:5, Funny)
Available 3rd quarter 2005. Look for Visual COBOL# in 2007.
What about (Score:3, Funny)
Re:Just announced... (Score:2)
Re:Just announced... (Score:2)
manged?? (Score:4, Funny)
I think the correct spelling is mangled.
hog wash (Score:3, Interesting)
200 billion lines? (Score:4, Funny)
Re:200 billion lines? (Score:2)
Re:200 billion lines? (Score:3, Funny)
Re:200 billion lines? (Score:2)
Re:200 billion lines? (Score:2)
Re:200 billion lines? (Score:3, Funny)
Re:200 billion lines? (Score:2, Funny)
What are the Linux COBOL solutions? (Score:5, Interesting)
If FORTRAN is a forcast ... (Score:4, Insightful)
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.
COBOL migration (Score:3, Informative)
Just from browsing freshmeat: OpenCOBOL [freshmeat.net]
Oh no! (Score:5, Funny)
I DO NOT want to have to debug visual COBOL!
Re:Oh no! (Score:2)
And by the way, Visual COBOL is either a MicroFocus or Microsoft product.
Why would you? (Score:5, Interesting)
Re:Why would you? (Score:5, Interesting)
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 (Score:2)
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
Sounds about right... (Score:4, Funny)
That's right, folks!
Re:Sounds about right... (Score:3, Funny)
Hairless, oozy, and irritated? You're talking about Ballmer, right?
If it's not Consolidated Lint, it's just fuzz!
Speaking of Gartner... (Score:5, Interesting)
Considering that Gartner has been charged with bias from some circles already, this can't help things.
Who Owns Gartner? [informationweek.com]
Yeah, this isn't so interesting, really. (Score:3, Insightful)
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
Re:Yeah, this isn't so interesting, really. (Score:3, Insightful)
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... (Score:5, Insightful)
Migrating COBOL apps to PC platforms won't happen on a large scale for two reasons:
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... (Score:2)
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
Economics (Score:2)
Re:Don't hold your breath... (Score:2)
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
Emulation? (Score:4, Funny)
Manged (Score:2, Funny)
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 (Score:3, Insightful)
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 (Score:2, Informative)
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 al
The Latest From Microsoft R&D... (Score:3, Funny)
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... (Score:2, Insightful)
> 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).
interesting mentality (Score:3, Insightful)
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? (Score:2)
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 t
Re:Why not just recompile COBOL for Linux? (Score:3, Informative)
Inertia, maintenance and programmers (Score:5, Insightful)
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
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... (Score:5, Insightful)
Visual Basic and Visual C++ where very distinct languages. The
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. (Score:3, Funny)
Did the author intend to say managed or mangled ?
The issue is not COBOL.. (Score:5, Insightful)
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:
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.
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.. (Score:3, Interesting)
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
Circle Ten? (Score:4, Funny)
A joke. (Score:5, Funny)
"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 (Score:4, Informative)
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.
Support (Score:3, Interesting)
C0b0l is teh l33t (Score:3, Funny)
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.
COBOL runs on Unix and Linux (Score:3, Informative)
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? (Score:5, Funny)
It's called "ADD ONE TO COBOL GIVING COBOL."
(Yes, this joke is at least 15 years old...)
Just what we needed (Score:3, Funny)
The stability of Microsoft combined with the elegance of COBOL.
Without JCL (& other stuff) it just won't matt (Score:5, Insightful)
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... (Score:3, Interesting)
oh, and btw, I'm not a COBOL programmer. just someone who respects them enormously. Props to the host team!
tims
You forgot the codebase is growing (Score:3, Informative)
You could have known this 5 days go though... # 2003-11-04 15:43:28 Microsloth courts COBOL (articles,microsoft) (rejected)
Solution: (Score:3, Interesting)
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.
Grrrrr! (Score:3, Insightful)
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!! (Score:3, Insightful)
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 (Score:3, Interesting)
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.
Re:Yikes (Score:5, Interesting)
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.
Re:People Actually Use COBOL? (Score:3, Informative)
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? (Score:3, Informative)
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
Re:Why was COBOL so prevalent in the first place? (Score:3, Insightful)
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
Re:Why was COBOL so prevalent in the first place? (Score:4, Informative)
COBOL histories can be found here [legacyj.com] and here [oevelen.com]. 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
Re:Try x86 assembler.NET :) (Score:4, Funny)
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 [worldonline.dk] is beautiful :)
Re:.NET and C# (Score:3, Insightful)
Now, I FAR prefer C# the language to Java the language, but C# is tied to a platform.
Re:.NET and C# (Score:3, Informative)
On what?? I find my java programs perform quite well on a 25 cpu *nix box....
Thats the problem with
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
Re:old-skool programming (Score:3, Insightful)
"Lazy" doesn't come into it - you'd be incompetent if you suggest
Re:old-skool programming (Score:3, Interesting)
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 bak