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".
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.
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
This makes me wonder, are there any Open Source projects working to provide for this eventual migration?
Just from browsing freshmeat: OpenCOBOL
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
#
...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!
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!
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?.....
= 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
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
COBOL was originally designed by the military to be a language that even managers could read and understand exactly what was happening. The original COBOL specification didn't even have comments!! Statements looked like this:
...
add this to that giving something-new.
multiply x by y giving z rounded. perform function until condition.
end-perform.
stop run.
Statements are called sentences. Groups of statements are called paragraphs. You get the picture. The reason that it became so popular was because it was designed by the military, and they coded everything in it. Then when those coders went to go work in the corporate world, they took COBOL with them.
Chaos will always win out over order because chaos is more organized
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.
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
Mod parent informative. And yet, having just read this comment, I now feel I have been exposed to 10 times more COBOL than any human ever should ever survive.
Karma: It's all a bunch of tree-huggin' hippy crap!
COBOL histories can be found here and here. For quite a while, the language that was available on all sorts of mainframes that addressed business was COBOL. Then one could use FORTRAN for doing engineering & science. All other languages were in the noise, were research projects, or were only supported by a single vendor.
Selecting COBOL made very good sense then and in some cases probably even makes sense now for some classes of applications. Move Corresponding still does a lot of work in a single statement. New editors make working with the verbage easy compared to the venerable 80-column card.
-- Multics
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.
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
C is most definitely NOT any better than Cobol for what Cobol does. There is nothing actually wrong with Cobol for the applications in which it is used.
Cobol is actually capable of structured use. The problem is that SOME programs written in Cobol were written so log ago, that we didnt know then what we know now. Cobol is not the problem - the problem, such as it is, is that the code is very old. As for lack of Cobol programmers, I am damn sure that anyone who can learn Java can learn Cobol in half the time it them took to learn Java. If offered a suitable salary
As for "The mainframe it runs on is getting old" IBM
Sent from my ASR33 using ASCII
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.
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
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.
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
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).
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.
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
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.
It's always funny to me how much most managers in our field consider LANGUAGE to be the barrier to most tasks, when my experience it's really more a matter of knowledge of the type of code you're interfacing.
If you've written procedural code to process transactions in any language, from C to FoxPro to bleedin' VB Script, you should be able to manage COBOL code to process them with a good book and about a week's worth of "high error hacking." The language isn't the problem...it's the type of business logic employed, the type of parsing, the tricks used in that type of programming that really hold you up. The language is just a red herring.
And yet, the first thing people ask you is, "Do you know XxXxX language?" What they should be asking is, "Do you know a language LIKE XxXxX and have you experience in the field of YyYyY?"
Hiring based on task and not on "langauge" is something the industry is just now coming around to, and I think it's due to years of C programmers forced to sit on their thumbs because they knew how to write printer drivers but had never opened a window in their life.
Hey freaks: now you're ju
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.
Unfortunatly, C# is tied to the platform. The mono project is trying, but most of your .NET class library is not going to be ported by Microsoft to linux, so I don't think that .NET will help you much.
Now, I FAR prefer C# the language to Java the language, but C# is tied to a platform.
If I have nothing to hide, don't search me
.NET couldn't replace Java so now they're going after Cobol.
Weren't ALGOL and PL/I quite popular alternatives at the time, especially in Euroland?
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.
"C# applications generally outperform their Java counterparts by a large margin."
.NOT it only works on M$ and Intel CPU's.
.NOT you have your choice of Windoze or Windoze running on intel or amd.
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
Alot of big business are very pissed right now with MS over thier licensing and how virus prone thier OS is.
Add to this the fact that most COBOL code is written to a very specific hardware implementation. Most companies will eventully choose to rewrite thier COBOL apps, and given the previous reasons many of them won't even look at MS.
So Long and Thanks for all the Fish.
err.... Problem is, just because i can program, doesn't mean I can spell things like 'ENVIRONMENT DEVISION' or 'CALCULATION SPECFICATION!'
I'll stick with java thanks.
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.
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
Then some bright spark came up with PL/1 and RPG Lovely languages, though I did like advanced basic on the DG's
I had a pet once
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.
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.
are those pigs ? flying past the window ?
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 ----
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
This goal was attempted during the much ballyhooed Y2K fix. But it was still easier to repair the old programs rather than migrate them.
Well what do you know. He is absolutely correct. To the extent that purchasing an additional interop layer for $99.00 and running it on top of the existing NT OS can be considered the exact same thing as 'running UNIX because you're running NT and they're the same thing', it's indisputable.
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.
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?
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'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?