Slashdot Mirror
Microsoft Makes Push for COBOL Migration
geoff313 writes: "It would appear that Microsoft
is making a real push for the migration of existing COBOL applications to Windows and their .Net platform. Micro Focus, a company who makes
COBOL migration products and last year became a member of Microsoft's Visual
Studio Industry Partner (VSIP) program, announced their Net
Express with .Net product, a plug-in to Microsoft Visual Studio .Net
2003. It allows for COBOL code to be integrated and manged with other code in Visual Studio. In an interview with eWeek he declares that 'Micro Focus and Microsoft are bringing the mainframe to Windows and .Net'. This makes me wonder, are there any Open Source projects working to provide for this eventual migration? Gartner estimates that over 75% of business data is processed by an approximately 200 billions lines of COBOL, so
this seems like a huge potential market to lose to Microsoft."
Aren't most COBOL applications deployed on big iron?
.NET solutions will be deployed on big iron; rather, my assumption is that we are dealing with standard x86 server farms running Windows Server.
.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.
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".
Requesting more links in the story; Not enough blue clicky things.
You have to admit, this is the most innovative thing Microsoft has done. Ever.
--ken
Bitcoin pyramid: Join here: http://www.bitcoinpyramid.com/r/1427 it's FREE!
Microsoft Visual COBOL++.NET 2003
Available 3rd quarter 2005. Look for Visual COBOL# in 2007.
His name was Robert Paulsen.
It allows for COBOL code to be integrated and manged with other code in Visual Studio.
I think the correct spelling is mangled.
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.
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.
.NET is an excellent platform, and Visual Studio .NET is a powerful, easy-to-use IDE.
I have to give MS credit here -
Isn't that about 20 lines of C++?
There is no reasonable defense against an idiot with an agenda
:wq
Has anyone used Tiny Cobol or Open Cobol
Learning the difference between "OWE" and "OWN" might be something you should look into.
This makes me wonder, are there any Open Source projects working to provide for this eventual migration?
Just from browsing freshmeat: OpenCOBOL
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.
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.
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!
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.
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)
there are at least two of them: OpenCOBOL, TinyCOBOL
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?
#
#\ @ ? Colonize Mars
#
geez, I realy need to double check my spelling. Is there a way I can change it?
Cheers,
RoadkillBunny
...allows for COBOL code to be integrated and manged...
.NET for ALL your COBOL needs! Want your COBOL code to be hairless, oozy, and irritated? Then .NET is for YOU!
That's right, folks!
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.
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?
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.
.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!"
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
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.
"I'm a scientist! I don't think, I observe!" - Dr. Clayton Forrester
COBOLScript in the next version of IE?
Maybe they are rewriting Virtual PC to run on the IBM 360.
Two wrongs don't make a right, but three lefts do.
From dictionary.reference.com:
Manged:
adj. Refers to anything that is mangled or damaged, usually beyond repair.
Gotta love a binary shreader...
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
Electronic Music Made Using Linux http://soundcloud.com/polyp
I don't really think MS has much of a chance of changing the big boys' COBOL machines. Sure they could do it faster, cheaper, etc., but given the real need for stability in the traditional cobol marketplace, wherefore MS ?
The only place I've seen banks roll out MS apps are in non-mission-critical systems (bank-staff desktops), although WinNT does seem to run Natwest's ATM machines. I've seen a blue screen of death on them a number of times, so maybe MS aren't so fanciful an option... Damn!
Naah, overall I can see the "client" (you have no power) machines running windows, but not the central (we are the business) machines getting within retching distance of windows....
Simon.
Physicists get Hadrons!
I don't know much about COBOL, how did it become the main language for mainframes 20 years ago? C was around then, right?
Why go with some brand new technology when there is already something solid that works?
.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.
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
(yeah, yeah I know about mono, but I doubt M$ will do much to support it and will probably try to kill it somehow).
Comment removed based on user account deletion
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?.....
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.
Don't you think?
= 9J =
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.
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!
"You never want a serious crisis to go to waste." - Rahm Emanuel
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.
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.
Just some thoughts,
.. who would really want to do this for 30 year old code that works fine where it is.
..
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.
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 ;)
.net languages are not.
:)
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
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.
Mea navis aericumbens anguillis abundat
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 difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
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
Garg
Alumnus, Xavier's School for Gifted Youngsters
I found this example of scripting an asp+ page using fujitsu's cobol quite amusing. Wasn't much uglier than scripting asp 3.0.
The average idiot should be able to spell idiot. Someday, you too may be an average idiot, if you work hard at it.
I had a professor who told me that the following is an actual valid line of code in COBOL:
:)
REVENUE MINUS EXPENSES EQUALS PROFIT
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.
This stuff has been running for 30 years unchecked on a big-ass server in some back room. Who in their right mind is going to want to switch this over to .net and introduce 1 million new errors and make the company buy a new server, plus someone to maintain it.
Chaos will always win out over order because chaos is more organized
Eclipse has a project geared towards development and deployment of cobol applications on MS, Linux and Solaris.
Too bad it has gotten virtually no publicity; I'd like to have seen it declared before Microsoft's, and show that they're not the only "innovators" in town...
Windows, .NET *and* COBOL? Looks like Dante missed a circle.
www.sjbaker.org
IDENTIFICATION DIVISION.
;)
PROGRAM-ID. asklauraout.
ENVIRONMENT DIVISION.
DATA DIVISION.
LINKAGE SECTION.
01 NAME PIC X(6) VALUE "Laura".
01 PHONE PIC X(8) VALUE "123-1234".
01 QUESTION PIC X(30) VALUE "Want to go out friday?".
PROCEDURE DIVISION.
CALL NAME USING PHONE QUESTION.
EXIT PROGRAM.
Yeah I know, but I was inspired after reading this and thinking back to highschool when I had a Cobol course in the late 80's. As for Laura, well she never cared for the computer, but...
~~ Behold the flying cow with a rail gun! ~~
I don't care if it's even replaced by VB.NET. All I'll have to say is DIE COBOL DIE!
I'll be glad once that language has taken its dirt nap.
Slashdot is proof that Sturgeon's Law applies to mankind.
COBOL is currently running either on mainframes or on VMS clusters. If OpenVMS suddenly becomes available on the Intel architecture, everbody currently running COBOL will be mightily tempted to set up clusters of cheap Intel boxes running OpenVMS, which would represent yet another lost sale of Windows. Maybe Microsoft knows something about the oft-rumored port of Open VMS to the Intel architecture.
Which would you prefer, a fully working program, debugged for 20 years, that is portable to any machine every likey to be worth running it on?
Or a program newly ported to an untested environment from a company with a tradition of redefining the rules every 18 months?
Sent from my ASR33 using ASCII
On the eve of the New Year 2000, an old programmer went out of his house to go to a party, but was run over by a bus before he could get there. His vision went dark, but then he saw wonderful white light and people in white clothes leaning over him.
"Where am I?" he said.
As soon as he spoke, everyone started cheering and congratulating each-other.
"What is going on?" he said, amidst the brouhaha.
"You see, this is many thousands of years after your time," told him one man in a white labcoat. "The medicine has made huge advancements, and now we are able to revive people who have died millenia ago."
"Wow," said the old programmer, "this is really great. But why me?"
"Well, you see, this is the year 9999 -- we are facing the Y10K problem, and your resume said that you know COBOL..."
If you open yourself to the foo, You and foo become one.
Dude, you totally Owed that guy.
YLFIOne god, one market, one truth, one consumer.
How much do you do with your computer. Try running 15 tasks at once. Also, a program should never crash the OS. That crap was supposed to stop with the i386, but MS still hasn't gotten it quite right (albeit, it's better, but not by much).
Slashdot is proof that Sturgeon's Law applies to mankind.
...until you actually need to CHANGE what the program does. If it can work forever as a "black box" then keeping it the same is fine. However, somewhere down the road, that piece of software is going to need to be updated, or the hardware it's on will break with no replacement available. Leaving it the way it is is just running away from the problem. You should start migrating it NOW while the COBOL programmers are still around.
But there is another kind of evil that we must fear most... and that is the indifference of good men.
Both COBOL and Visual Basic are a response to a business advanced by the major programming language firm of the time.
In the early 1950s IBM pushed F0RTRAN as a replacement for assembly arguing (succesfully) that it allowed for a large increase in programmer productivity without much loss of system performance. F0RTRAN however was too "computer oriented" and many programmers with a strong business background found it difficult to express business ideas in terms of fortran succesfully. So an alternate language called COBOL was created which allowed for a better expression of business concpts at the cost of both performance and abstracting the details of how the machine was opperating.
In the early 1990s Microsoft pushed visual development in C++ (visual C++) as a replacement for standard C arguing (succesfully) that it allowed for a large increase in programmer productivity without much loss of system performance. Visuak C++ however was too "computer oriented" and many programmers with a strong business background found it difficult to express business ideas in terms of C++ succesfully. So an alternate language called Visual Basic was created which allowed for a better expression of business concpts at the cost of both performance and abstracting the details of how the machine was opperating.
So obviously it's important to look at these languages as a reaction to the dominant languages of their day. Understanding what they are reacting to.
BTW, COBOL is still going and growing VERY strong. COBOL-2002 is a new standard of the language, and code is still being written in it for many, many legacy applications.
There are two issues here: First, the question of mission critical Microsoft. Second, the question of moving your software.
If I were you, Mr. CIO, I'd avoid this little stunt. Mainframes and the software mainframes run exist in mainframe form for three reasons:
* Speed - Process more data in less time
* Accuracy - With less mistakes
* Reliability - and a minimum of downtime
In none of these areas does Microsoft have a credible track record. You simply have to look elsewhere. Anyone who goes with MS on this is putting their carreer at risk.
That said - would migrating off of Cobol to a more modern development environment make sense? That's a situational question, and one that has to be answered on a case by case basis. In some cases, legacy software is a competitive advantage. In others, it's a business obstacle. In most cases, there's no compelling reason to do or not to do.
-- $G
Yeah,
I was reading only comments of the kind: "This doesn't work because it's from Microsoft."
Sounds like an IBM manager from the 90's defending OS/2 on the desktop...
And what, if Microsoft's Cobol# just works?
At last, after all this time and all this wondering, we finally have an answer to the question "What is .NET";
It's a comprehensive set of tools for fixing things that aren't broken.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. COBALISTEHL33T.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "What they think they d0ing?! C0b0l is teh l33t! Someone tell microsoft to go back to the crap 86, we don't need him with our cool VT100 world!"
LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.
~UltraSkuzzi
This comment is liscensed by SCO.
xSeries (x86)
pSeries (RS6000)
iSeries (AS/400)
zSeries(the venerable s390 mainframe)
It's a pretty compelling story for producing cross platform, scalable applications while still making the best use of your current hardware investment.
Only a Fool would port to MicroFocus Cobol.
Of all the incompetent products Microsoft sells, ( VB 6, Access ), Microfocus Cobol was 10* worse.
We tried to port one of our systems to Microfocus, upper management directive..
We were able to "Discover" 15 bugs a month, every month, with every new release. These bozo's couldn't even get PIC statements to work reliably. They nearly drove us out of business.
We had to rewrite first to VBA and Access, then to C++ and Sql Server.
I wll never forgive the bozo's at Microfocus.
The fact that Microsoft bought them doesn't raise my expectation that the quality has improved.
A conversion from a mainframe to PC is the Kiss of Death for any system, if you move to Microfocus.
They're finally getting around to addressing their Y2K problems.
I have Cobol Binaries that still work unchanged, 30 years later. They get written once, then forgotten because they just work.
.NET.
OTOH MS is the opposite of maintainable - things MUST be rewitten and recompiled yearly, and tested frequently with near weekly patches. What a merrygoround.
IBM's MVS is low, low cost, and you NEVER have to rewrite, retest and migrate the application yearly, if you went down th MS path.
Why would step onto a upgrade treadmill, with open ended costs. Try getting MS to commit to binary backward compatibility for more than 5 years.
The real value of COBOL is that business rules are neatly locked up, and stable and in one place. Swapping one mainframe for 1600 MS servers will devalue business efficiency by being lost in an ocean servers, and that re-development and upgrade work overshadows core business activity that really brings in real revenue.
There is no shortage of COBOL coders - but a shortage of managers who seek and reward those with true maintenance skills. ie porting COBOL, or VB5 apps to C++ or C#, would also be cheaper and more enduring than
Don't blame/praise Microsoft for this. .net CLR and any company can join the visp program.
There is no indication that microsoft is activly backing this. Any company can write a language which runs on the
I would add longevity of support. Is the company going to support their current hardware and software products in 5 years, 10 years, 20 years? Microsoft, and many other companies, have a bad habit of pushing something for a few years and then ditching it, leaving their customers dangling in the wind. Microsoft has a long list of products and technologies that are no longer supported.
Mea navis aericumbens anguillis abundat
Ken,
Millions have tried before, all have failed. This is not a new idea, it is a failed one. Nothing works in the business world better than COBOL. Migration has been tried in the past, PCs didn't have the power then, as they still don't now. Just because a billion dollar corp like Microsoft thinks that it owns the world and what they say goes, doesn't mean that it will work.
Mainframe processing is just now getting more focus again, and because Microsoft can't have it, they want everyone to migrate from it. I remember when Microsoft wanted to run all their own software for their business function, and in less than two weeks, they switched back to their midrange AS/400 systems. Why, because their shit still don't work right. And now we are discussing the security issues. Imagine if Blaster had a phone home trojan and gave some user access to all of that Business data. No lost money there!!!
Place something witty here
Hint: transistors aren't 100 years old.
just fine. MicroFocus is available on Linux and your Unix of choice (I've actually done healthcare adjudication app porting & integration on Linux, AIX, and HP/UX). It has a C API so you can go back and forth between any langauge that supports that (I did Java via JNI). Fujitsu also makes a kick-butt enterprise grade COBOL compiler for Linux & your Unix of choice, and I'm sure there's plenty others out there.
That being said, for 1,000's of users, the mainframe is still the cheapest for price/user. In the 10's to 100's of users, Unix or Linux on server grade machine is dandy.
MS doesn't have much of an interest in changing the big boys' COBOL machines. They're helping to migrate business apps off the Mainframe, but it is in the form of complete rewrites of apps to a web enabled platform, not COBOL migration.
Back in 1996 when we first moved to Windows NT, the Mainframe developers were excited at the prospect of running MicroFocus COBOL. Not because they had any intention of migrating code off the mainframe, but because more often than not had need to write utilities or tools for the desktop.
Since they already knew COBOL very well, it made sense to them to write these programs on the desktop using what they knew well.
Microsoft understands this market better than you think. It's about interoperating.
"It allows for COBOL code to be integrated and manged with other code in Visual Studio."
I know this is a typo, but I think "manged" is appropriate.
Like when my Newton read my note "Pick Up Mother in Law", and converted it to "Pick Up Bother in Law". True.
Really this is more FUD from M$... Honest.
.NET would be way to expensive. If a migration does occur it would have to be over a LONG period of time 5-10 yrs actually.
.NET programmers know how to convert COBOL code...let me see your hands! I don't know one... The list goes on ...
Think about it for a second. Right now IT units are stretched to the limits as far as budgets are concerned. Moving to
First, you have to go through an exhaustive, costly and time consuming data conversion process. While that is going on you have to also retrain your COBOL programmers. How many
ohhhh.. but you can replace a mainframe with a BEOWULF CLUSTER
So suddenly your batch payroll that ran for ten minutes on the 'frame and churns out the paychecks takes all day.
I've heard this many times, but I wonder: what kind of technology makes this possible? I know, "massive I/O", but how do you get massive I/O? Why do mainframes from 20 years ago have such better throughput than high-end unix servers made today?
I'm under the impression that modern unix servers go largely as fast as physics and manufacturing will allow. So, how does the big iron go faster?
Why haven't Sun/IBM/HP/Apple emulated any of these technologies?
It seems there would be a monstrous market for a "massive I/O" unix machines, no matter the price, so where are the flying cars?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
It's called "ADD ONE TO COBOL GIVING COBOL."
(Yes, this joke is at least 15 years old...)
The stability of Microsoft combined with the elegance of COBOL.
Yet Another Web Site
1. Microsoft had nothing to do with this. Microfocus decided to write a COBOL plugin for VS.NET and paid the royalties to do so.
.NET is more than two years old. Fujitsu was pretty much the first ISV to start a third-party language on .NET very early into the .NET beta cycles. They had a version 1.0 product at pretty much the same time .NET was released. They had full VS.NET support, including visual designers for graphical applications and even web applications. Fujitsu's implementation of COBOL on .NET adheres 100% to the COBOL standard, including all of the features and primitive datatypes that have no equivalent in .NET (for those stupid fuckers that think that a .NET language is limited to .NET-isms.)
.NET
2. COBOL on
Fujitsu netCOBOL for
You forgot "Next."
We did this ourselves for a customer (insurance company) coming from HP-UX. With code being developed and expanded over a period of 25 years, there's a lot of business logic inside that just is _priceless_ for these companies.
By replacing their 10 year old systems with brand new, super-cheap, (comparable) super-fast Linux boxex, they are very satisfied (especially when fax/web/filesharing opensource tools are added for a low fee).
Just replicate the complete system as many times as appropriate, ala NASA.
Well seeing how MicroFocus makes a version of COBOL to run on basically PCs and migrating the big iron COBOL to MicroFocus COBOL is not that hard, this does seem to be an interesting migration path.
He's not a very good spokesperson, though. He forgot to refer to Microsoft as "M$"
M$ pushing a honnest, realistic line of businness, without threats, extorsions, or etc?? .net junk.
It is more than time for we to get out of those 1970ish interfaced Cobol APPS buried in mainframes.
Unfortunattely not even me could think of a way of bashing micro$oft off for that...All that is left for us to do is hurry up and deploy some PYTHON CGI, or anything nearly as maintenable, free (speech) and scalable before thay go further with their
-><- no
Relic of the 90s, right... When windows stops giving BSODs the jokes will be relics, not before. Clippy was a joke, is a joke and will remain a joke from the brilliant minds that produced MS Bob. Follow the link and look at the dog helper, ever seen that one before? Right! In the WinXP Search tool as the animated helper.
I like this quote from the last page of the Bob guide: "The Office Assistance included with Office 97 appear to be directly evolved from the Bob Guides." Yeah, nothing to make a joke about with Microsoft stuff. Move along.
Overly Critical Guy takes one for his hero, film at 11pm.
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
Unless MS and MF have created a really good replacement for JCL, and the ability to seamlessly convert between EBCDIC and ASCII on the fly, and seamlessly access all the data stored in all the DASD in all the datacenters, gin-joints, and big-iron holdout citadels spread throughout the world, it just won't matter.
JCL is the biggest holdup, I would think. COBOL programs perform several steps to a piece of data, kick out output files, and pass control to JCL, which, depending on the return code of the COBOL, will call one of several different alternatives. Having one stinking program run on your PC and having to hand-code all the JCL into batch filesis a massive waste of time. Not to mention that JCL is far more robust then an MS-DOS batch file. Finally, most PC's just don't have the throughput to match an IBM Mainframe with DASD on channel. Finally, you can tell an IBM shop that Windows is far more stable then it was 10 years ago, but it still doesn't compare to a mainframe for reliablility _and_ stability. A Windows server with five 9's reliablity isn't worth shit if the registry is corrupted. That just doesn't happen on mainframes.
I totally hated taking cobol. The only way i can describe it is programming with a collegiate dictionary strapped to your hands. The damned thing is needlessly wordy. i mean who thought replacing y = x +2 with make y the result of x plus 2 (or something, im not about to grab my book and find out.
for this, but I think that this is a good thing, if it takes off. Sure, Windows and PC hardware are not as reliable as mainframes, but this is a potentially large market, and anything that encourages Microsoft to make Windows more reliable, and PC makers to make more reliable hardware, is a good thing.
No data, no cry
good software engineering meant using the right tool for the right job. Only a web script kiddies with no mainframe exposure or experience would think this story is newsworthy. Every company or organization that I've had experience with and that has a mainframe always laughs at the idea that they would migrate anything off host. Just because Big Blue originally hired MS to do software has always translated to MS that they can play in this market. I like to quote Charlton Heston whenever somebody suggests that they are going to take my mainframe away, "from my cold, dead hands!!!"
oh, and btw, I'm not a COBOL programmer. just someone who respects them enormously. Props to the host team!
tims
"Ahhhh, best laid plans of mice and men... and Cookie Monster." -- Cookie Monster, Sesame Street
This is great. The last class I took for my bachelors was a COBOL class, and I know VB like the back of my hand. I could get paid to do this. Maybe that class wasn't a complete waste of time afterall. Who knew?
"Why do you consent to live in ignorance and fear?" - Bad Religion
MicroFocus has been doing COBOL on Microsoft operating systems for years.
.Net... If, in 5 years, Microsoft announces a .NetNG or .Net2008 or whatever then MicroFocus will follow.
.Net platform is sufficient to make people jump where they didn't jump before.
When Microsoft went GUI, so did MicroFocus. When Microsoft went 32 bit, so did MicroFocus. Now Microsoft is going
This is a "migration path" that has been open for a long time. I seriously doubt that the mere ability to target the
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.
Friends don't help friends install M$ junk.
That's cruel and unusual, rebooting a mainframe like that, you don't deserve to have it that good. Once a quarter is too often, you'll wear out the power button dude...they don't test those out very well you know.
That reminded me of a web page I saw once, which took a lot of Googling to find.
In some perverse sort of way, this .NET web page using x86 assembler is beautiful :)
It all goes downhill from first post
This question needs to be answered for us big iron neophytes. Lots more cache? Exotic and expensive busses? Inquiring minds want to know
Time for some tasty Shiner Bock!
That's what they were calling COBOL back when I was in college (around 1990). Suprised it's still a going concern, apart from applications that various parties were too cheap to maintain...
.Net, though....
Not in favor of migrating to
"Oh my God. This is terrible. This is the end of my Presidency. I'm fucked."; ~ Donald J. Trump
Why would any company migrate off of their mainframes. They are most likely fully paid off, need just a couple of grey beard coders to maintain it, and fully reliable. I don't see companyies giving there IT departments the funding needed to migrate without a benefit for the cost.
Never used it but Eclipse has a COBOL plug-in. Eclipse ( www.eclipse.org ) is 40 Million USD of free software from IBM: I suspect Microsoft simply playing catchup here as Eclipse is a force to be reckoned with.
I work with IBM iSeries, and it's the little things that count! In and idle box, the CPU literally does NOTHING. Not 2-3%, but 0% overhead. memory is handled by a seperate processor that gets requests as needed. Disk is the same--think SCSI on steroids. Terminal emmulation is seperate, tape backup, etc... The idea is that all the other tasks are "handled" by something else, no IRQ, DMA, I/o addresses to slow things down.
The other key is that big iron is designed around basicly terminal thru-put rather than graphics or multimedia. Again, the chips are ordered to maximize 1000 128kb connections to memory rather than just 1 process with Gb/s of bandwith that stops to wait for keyboard input!
On a moderen PC, windows spends most of its time just waiting...for user input, devices, memory management, etc...waiting that turns a 3GHz processor to about 1GHz of usefulness. I've thought that something like Optereon could make a splash in this area. It's idea of multiple channels is a first step to making PCs more mainframe like. But...that costs money in chipsets...notice the expense of Adaptec UltraSCSI controlers...You'd need them for every system to make a PC perform like at midrange for the same MHz.
I know the Enterprise had GE looking control panels and transitor / relay boards, but COBOL too? OK, I can believe it, but they will really be in deep do-not-do if they go Next Generation M$. To Boldly Blue Screen where no Blue Screen has ever gone! Just think what transporting would be like.
Friends don't help friends install M$ junk.
by 5B lines per year, which is quite impressive.
You could have known this 5 days go though... # 2003-11-04 15:43:28 Microsloth courts COBOL (articles,microsoft) (rejected)
It's not spite, it's horrid experience and survival instinct talking. The "developer" is Microsoft with TONS of money to blow on mindless adverts that will ruin everyone's day. It's bad enough that Microsoft has convinced people to use crap like VB and access. No one wants to imagine having to deal with Visual Cobol. The comments above speak for themsleves:
It's just another case of M$ pushing their own second rate crap onto the world. The fear is that they will be able to do it and there will be no alternative but to meet clueless demand with clueless M$ junk.
Friends don't help friends install M$ junk.
Micro Focus and Microsoft are bringing the mainframe to Windows and .Net'.
The infrastructure of many countries is on IBM mainframes. Haven't Microsft done enough damage already? It's one thing to witness senseless Internet damage; it's quite another to watch whole countries go down because of these bumbling idiots.
Someone please put Microsoft out of our misery before this gets totally OTT.
.NET couldn't replace Java so now they're going after Cobol.
Why would any self-respecting institution or government - or bank, insurance company, whatever - trust the public by making their software open source?
There are too many people here who think the world revolves around a freebie Linux desktop download.
I/O Throughput wise, SGI (silicon graphics) is king, but mainframes have a lot of interesting capabilities for 'application throughput'
OS: Lack of generality and portability in the OS lets you cut down overhead in servicing the hardware.
FS: Filesystems that are less general but tailored towards particular needs
TP: transaction subsystems tend to be less general than oracle or relational DBs but the simplicity allows speed and they can also be integrated with the OS, so there are less layers.
Hardware: Multiple busses, multiple controllers, specialized subsystems (IO processors, crossbar backplanes); this is available on bigtime UNIX systems as well.
The whole point of running fortran is the legacy code. For this, as you note, G77 rocks. It's also nice to have it available on a free modern OS will all sorts of other goodies not found together on any comercial platform.
Some people are moving to 90/95 for memory management and a hoped for portability, but it looks like the portability issues of the 90/95 remain the same. The hope was to make memory management as portable as FORTAN was. The lack of portablility of the C code, which is also standardized but pains mixed code, should be a clue to problems to come for fortran 90/95. There were some 90/95 to 77 converters the last time I looked, but most developers thought that 77 was a much more important effort.
In any case, M$ is not even in the ballpark. They gave up their fortran effort to DEC years ago after misleading a few people for a few years. M$'s compilers would not compile the legacy code so they were never really useful.
Friends don't help friends install M$ junk.
Reason: Don't use so many caps. It's like YELLING.
No it is not, you drooler.
It's like COBOL.
A conspiracy theory just occured to me. Linux runs on Big Iron (see Linux/390). Mono runs on Linux. COBOL.Net runs on Mono.
.NET for Big Iron. (unlikely) .NET to Linux, while sucking GPLed code from Mono, taking GPL to court and winning (likely)
Now deduce your favorite conspiracy....
A few coworkers deduced than either:
1. Windows will be ported to Big Iron, as we're already on the way with the Data Center versions of Windows. (extremely unlikely)
2. M$ will go open-source and embrace Mono as its
3. M$ will port
Those who can, do. Those who can't, consult.
Cobol = boring
Financial software = boring
Open source = volunteers in their spare time
You see the problem?
Be wary of any facts that confirm your opinion.
That said, I did work 2nd/3rd for a while...great "quality" time with my machine.
Is in 20 years we will have no legacy. Any code I write today is guaranteed to be replaced by the latest whiz bang technology that comes out in 3 or 4 years. Perfect example is the system I work on now. It was written 4 years ago in VB 6 and now VB 6 is no longer supported after 2006 (not totally sure on that). The whole system will be re-written by then and the cycle will continue. Anyone else feel so worthless because of this? I mean I will never be dragged out of retirement to fix bugs in 20 years. No one will look at some spaghetti code in 20 years and say who the f$@#@ck wrote this crap... I ought to wring his neck... It's kind of sad.
I have been working for a company, that did offer a lot of apps for Banks. They even programmed a java middleware thingy to get everything up2date. Guess what: nobody bought it. Another thing: since mainframes are expensive, the entire development for the mainframes was done on IBM Risc machines (AIX) with Microfocus Cobol. The thing could cross-compiled to get it to the customer. So, if they wanted to save money, the could have switched to Unix easily (CICS was using DB/2 as Database backend - just like on the mainframe).
So why would anyone in their right mind port this to Windows? As someone said before. Those RISC Unix Systems are way more reliable than an X86 Platform.
-- MicAttAck
Religon is an insult to human dignity.
Yes, it has GOTOs. There's nothing wrong with GOTOs, if they are used appropriately.
You realize that you are a minority on that opinion. Are you defending pure goto's or goto's mixed with nested blocks now favored?
Anyhow, my problem with goto's is that I could not find consistent patterns between different programmers. Perhaps if goto patterns were documented, you could better defend them.
Further, nested blocks allows code to have a visual structure (indentation) that generally reflects the flow structure. I don't know of a good goto counter-part to such visual cues.
Table-ized A.I.
I've seen a number of high-profile sites where 30-year-old binaries are still in use too; in some cases the source code was lost years ago, and the things were only maintainable by directly editing the object code.
It's not much fun to do that with COBOL compiler output, but it's do-able and saves a lot of time.
Yes, I'm that old. Want to make something of it? :-D
I seriously didn't think so much data was processed with COBOL. We have such wonderful things nowadays, like C, Perl, Python, SQL, XML. Do people still use COBOL cause they're too lazy to upgrade to something more efficient? Will I actually have to not blow off taking a class on COBOL??
sig?
The Machines dealing with my water, power and banking were using this code in the 1970's and they still are.
It's cheaper than doing it the BillG way.
Message from earth to BillG and MonkeyBoy.
Before you start this battle it's over already.
These guys shilling for you on this are wasting their time.
If you don't like what I write don't be a CS and mod it down. Refute it.
Yea I can't spell. So what is your point?
A Cobol-to-C++ translator.
From what I can see, Cobol is a procedural language, so it could be easily translated to C++ (no need to uses classes, just the functional part).
There is already a GCC backend, which means that Cobol maps to C++ perfectly.
And those 'goto' statements can be made as functions.
The translator app should also allow which database engine and library to use; the Cobol code that does database I/O would be replaced with calls to this engine.
This translator app could be made as backend to GCC: the Cobol compiler could produce C++ code instead of assembly code.
They're probably pushing for people to use VB.
From crap to crap... lateral shift.
on an IBM mainframe, don't worry about it! In other words, 'til hell freezes over.
I may be wrong, but most (if not all) of the housekeeping performed by JCL is now performed by the operating system.
I am very small, utmostly microscopic.
You can get COBOL compilers for just about any target. For example, there are also COBOL-to-JVM compilers (not that the JVM is any less proprietary than .NET). Interoperability with non-COBOL languages may, however, be a problem in either case because COBOL has some pretty oddball and low-level features.
.NET nor the JVM deliver those (yet?). That's why most COBOL applications will probably remain native for the time being.
Whether COBOL programmers will bite remains to be seen. I suspect what they are most interested in in a platform is performance, reliability, and predictability. Neither
Cant these bastards leave anything alone? Do they have to conquer and destroy *everything*?
We don't need them anywhere near COBOL. They have no business here. COBOL is stable,
proven, supportable, and run on REAL machines.. not kiddy toys.
Someone needs to take these people out before they assimilate the entire planet. Someone needs
to start at the top, if you get my drift
---- Booth was a patriot ----
Of course they will say this because .NET is a solution (and a bad one at that) looking for a problem. No one is using the damn thing. OO programming in this manner has already been done - Java - and that hasn't shifted critical systems written with COBOL at all.
The COBOL systems work, and that's all that matters.
I'm currently enrolled in CIS 314, Text Processing with COBOL.
And IBM was behind that effort. hmm.
QWest/US West did this, multiple times for probably a quarter billion dollars. So they ignore software engineering, they pay it some homage but pretty much ignore the science (rather than engineer a solution you probably need to cut through the tape and do it with a "tiger team," they have been aiming for CMM-3 for 15 years with no luck, go figure, me thinks in 15 more years they will have given up on CMM because it's too hard or they aren't smart enough or it costs to much more than they expected, or it's impossible.) some hot shot who thinks he'll make a VP starts advocating redoing something like the payroll system that has worked for 30 years. Several years later they kill the project, 10-15million in becuase it simply can't be done or they aren't smart enough or it costs too much more than they exepected or something. Then to make sure, they do it another time or two. Now we're not talking about switches and network infrastructure, we're talking about business infrastructure, stuff that you buy and implement SAP for. Not to bash Qwest, they do have some talented people but if they can't make an order system or payroll system migrate, there is no way in hell that you're going to cart blanche migrate Cobol to .NET and windows.
All of the arguments about I/O, porting code etc are pointless, because it eventually comes down to economics. If a company is spending $1,000,000 per year maintaining a mainframe, with code that can no longer grow, then there will come a time when they can no longer be competitive - they will have a huge overhead compared to their competitors, and will not be able to respond to market changes.
Mainframes *will* go away, *except* where there is not enough competition, or the cost of the mainframe is small in comparison with other cost centers.
I think that big banks will keep their mainframes, but eventually smaller, more agile banks will grow enough that the bigger banks can no longer compete. Then the big bank will either migrate or die.
Most writers regard truth as their most valuable possession, and therefore are most economical in its use - Mark Twain
Try sterling software COOL:GEN. From what I know :)
it allows one to write code then run it through this tool to generate COBOL. Thus, the programmer doesn't need to know COBOL at all. I'm sure it probably doesn't put comments into the cobol code either so it doesn't force one to change their bad habits either!
It's call MTP now right?
This goal was attempted during the much ballyhooed Y2K fix. But it was still easier to repair the old programs rather than migrate them.
He's right, you know...
I'd also have to throw in, if it still does the job, and it costs a lot of frickin' money to replace, why not leave it alone?
From my experience with some local businesses, many big corps cannot afford downtime. New computer systems in almost any form usually need allowance for some time to break them in. When you have an old COBOL system that is controlling your $100,000+/hr hardware/etc, you don't want to have to take that hardware offline in order to bring in a new system, especially with potential for errors. I wouldn't do this with linux, let alone an unstable and unpredictable monster like windows.
In addition to the downtime for replacement, you've also got downtime for spin-up, spin-down. Some systems are not capable of being shut off or turned on at the flip of a switch, there are things like power-buildup, heat, and many other factors involved, so even with a 100% successful replacement you're going to have a certain period down.
When a little time down time means a lot of money, you hold onto your pennies, and watch to make damn-sure that you're not replacing anything that doesn't need replacement. It's not the cost of the new technology that'll kill you, or even that you don't want something better, it's that what you have and how it runs is standing between your business and a lot of cash in downtime.
MicroFocus is late to the .NET game. Fujitsu Cobol has been on .NET since .NET began.
However, I see it going by keeping the mainframe and using it as a DB2 data store and migrating the application code to Java on Linux.
Microsoft has done this kind of thing in a whole lot of other markets. This one, however, has potential liability traps I don't think Microsoft has faced before.
The people running these old COBOL apps has probably had them running for many, many years. I'll bet, even through countless upgrades, the software mainly "just works". If it didn't, they certainly wouldn't still be using them after all these years!
Now, I have dealt with Microsoft OS's and compilers for the last 10 years and I can guarantee that Microsoft's COBOL.net is going to do anything else but "just work" for at least 3 years after it is released. And the people who would be depending on these systems to "just work" are those not afraid of lawsuits and they will have a really good handle on just how much each M$ gaffe costs them.
Microsoft should really delay any incursion into this market until they have taken care of their security and reliability issues.
She wants it and wants it now. So get crackin'.
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.
I wish at was Friday, but I dont want to wish my life away. So I wish it was last Friday.
I like your argumentation,
and I think I appreciate how Ada would be a good choice, but don't you think we would fall back to one of the current implementation (COBOL) main problem, that is, man power? I mean, the number of coders mastering Ada is certainly low, and depleting.
{Science sans conscience n'est que ruine de l'âme}
Heck yes, howdya think I know how to spell ENVIRONMENT correctly?
You know, Pascal and its brethren preceded C on the PC, and when C came to the PC it was an ugly thing to combine with segment registers (C-style pointer arithmetic assumes a flat memory model while Pascal didn't allow a lot of monkey business with pointers so the segment-register memory model didn't matter). Hey guys, it was MICROSOFT which pushed C on the PC and into the mind share it got (remember all that Hungarian notation of the MS Windows API's -- Windows was a C-thing).
Pascal was kind of a limited thing (no separately-compile modules and big global namespace) with a clunky syntax (if condition then begin . . . end else begin end vs if condition then . . . else . . . endif was hotly debated in the early 1980's). Wirth went off and did his Modula thingy (remember Modula?) while the US DOD went in the direction of Ada, and I am sure there were many now forgotten improved Pascals in those days.
Turbo Pascal was actually not Pascal but a Pascal follow-on because it really was not very adhering to whatever Pascal standard was extant. True Pascal files are really pointers and file operations are supposed to operate on those pointers -- very similar to the Gang of Four Cursor Pattern and never implemented in Turbo Pascal. Turbo Pascal retained the clumsy begin-end structure (how are you supposed to format and indent that anyway without having a waterfall of indents?) and the case-insensitive syntax (case-sensitive languages from C to Modula to Java area a pox on the land: MyClass myClass = new MyClass(); my foot!). Turbo Pascal also retained the compile speed that everyone else lost (Ada anyone?) and was a good balance between rigid type checking and allowing type casts to cheat (Modula anyone?). Even Wirth conceded that Turbo Pascal became the real-world Pascal instead of the various Pascal standards that were never implemented.
I heard Oberon was a work of art, an even leaner Pascal than Pascal that eschewed the object oriented revolution by promoting a more capable "with" statement together with the use of "case" statements to make polymorphic cases explicit in the code instead of being wrapped up in the layers of OO virtual function overrides. Then I heard of Oberon 2, which added objects, which meant Wirth caved. Oberon 2 morphed into Component Pascal, for which there is a Swiss version and an Australian .NET version, but with the case-sensitive syntax with the keywords in all caps giving these but-ugly source listings together with Wirth's gonzo versions of Object Pascal keywords and even more gonzo design patterns (the thing is such a theoretically pure answer to Delphi that I can't make head or tails of it, but I gave a SUN dude a fright telling him that there was this other thing that purported to do what Java does out there).
I love my Delphi; it is my Golden Hammer and I have so much experience with it that the legacy Pascal begin-end syntax just rolls off my typing fingers, and it compiles much much faster than C# (the SUN dude was annoyed that I pointed out that Delphi compiled much faster than anything on the planet -- he seemed to think an IBM Java was fast too).
The trouble is that I can't get my engineering students to use it -- distributing source code on the Web in Object Pascal is as good as any copy protection. They grudgingly use Java/C++ because "it can get them a job" but their first love is that VB of the numeric-computing world called Matlab. C# is really Object Pascal with C-style syntax, so that is perhaps a middle ground where I can meet my students. Java and C# prove that the C-style curly braces and prefix definitions won
JCL can be converted to Perl scripts (or your favorite scripting language) without much pain. I suspect the most of the conversion could automated.
EBCDIC and ASCII conversion has been around for ages, but figuring out which are the character fields could be a pain, as could the big-endian/little-endian conversion on the binary fields.
need a free COBOL editor for Windows?
I dont know about you, but my version of windows XP at home and the several installs of Windows2000 I use at work have never yet given BSODs. It truely IS a relic of the 90's.
Really remarkable, I guess that perspective shapes the reality. I know many people that have had BSODs in Win2K and WinXP. Of course I hear about many of the problems because of my 18 years in IT and people call me for answers. YMMV. One mans relic is another mans nightmare.
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
I have'nt seen so many "if it ain't broke, dont fix it" statements anywhere else.... :)
COBOL, the language that time forgot. At least somebody is remembering that all the boomers are dying and it doesn't take a rocket engineer to figure out that Mainframes are as about as needed as a stick to the head.
I'm surprised that with all the LAM development in the linux arena that somebody hasn't come up with the same thing.
COBOL's success on the mainframes goes to show how the emphasis on Business Computing is on Business and its unique requirements, and not on small-scale programming languages that are unproven with large accounts and currently restricts platform choice to WIntel.
Unless I have missed something MS specialise in the Micro.
And Micro means well, Not Very Big.
Someone tell me who the latest large corporate customers are likely to be - excluding mere Office Productivity users?