Microsoft Makes Push for COBOL Migration

Bah humbug... by __aavhli5779 · 2003-11-09 11:15 · Score: 4, Insightful

Aren't most COBOL applications deployed on big iron?

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

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

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

Re:Bah humbug... by Anonymous Coward · 2003-11-09 11:28 · Score: 5, Interesting

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

Microfocus is a little late to the table.

The system is running of a $40,000 Dell server, and replaced a mainframe that was costing almost $1M a year to lease/maintain. It's very doable.
Re:Bah humbug... by darnok · 2003-11-09 11:38 · Score: 5, Interesting

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

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

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

That's my take on things, but I'd be very interested to hear from anyone who sees mainframe COBOL code being used to do anything different.
Re:Bah humbug... by Anonymous Coward · 2003-11-09 11:50 · Score: 3, Insightful

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

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

*sigh*
Re:Bah humbug... by ericman31 · 2003-11-09 11:59 · Score: 4, Insightful
That's my take on things, but I'd be very interested to hear from anyone who sees mainframe COBOL code being used to do anything different.

You're pretty much dead on. Sun and HP systems have had more horsepower than mainframes for quite a while now. They are nearly as stable too. But there's a couple issues:
- A lot of mainframe code dates back to the 70's. Trying to migrate it would be a nightmare. Modular rewrites, one little piece at a time is more likely to succeed.
- CICS, TSO, MVS, VSAM, etc. is dead on reliable. Our mainframe sysplex outages can be measured in mere minutes per year.
- There are simply too many migration scenarios where the system was eventually migrated off the mainframe, but the managers who initiated the migration were no longer managers when it was complete due to budget overruns, delays, and other problems. CIO's learn from this, and aren't willing to go there if they don't have to.
Dell servers running Windows are nowhere the reliability level of Sun/IBM/HP RISC servers running UNIX, let alone the mainframes. Mainframe shops are not willing to risk mission critical money makers on unproven, unreliable upstarts.
--
In my universe I'm perfectly normal, it's not my fault you don't live in my universe.
Re:Bah humbug... by karit · 2003-11-09 13:21 · Score: 4, Informative

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

--
http://blog.karit.geek.nz/
Re:Bah humbug... by llefler · 2003-11-09 15:24 · Score: 3, Insightful

You are of course, speaking from experience, right?

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

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

--
It is amazing what you can accomplish if you do not care who gets the credit. -- Harry Truman
Re:Bah humbug... by danheskett · 2003-11-09 16:35 · Score: 3, Insightful

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

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

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

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

A lot of mainframes are needed. A lot are required. But most are not.
Re:Bah humbug... by dperkins · 2003-11-09 17:16 · Score: 3, Insightful

Umm, Actually, we are currently migrating several tax systems from a government mainframe system to a Sun Solaris system. Mirrored solaris boxes running an Oracle database, mounted from an EMC SAN. IO is not an issue, and we are running Microfocus Cobol for our back-end batch.
I would like to say, however, that much to my disappointment, we will be going forward with .NET in future projects. We have actually taken a look at COBOL.Net from Fujitsu, and though I don't think we will be using it, .NET is where we are heading. Mainframes, however, are seen as the proprietary means of locking folks in, not .NET.
Companies that have been locked into mainframes for so long are trying to escape from that "Big Iron Prison" to Microsoft. Ironic, isn't it? :)

--
My sig hates me. That's ok, I never cared for it much anyway.
Re:Bah humbug... by llefler · 2003-11-09 17:37 · Score: 3, Interesting

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

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

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

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

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

--
It is amazing what you can accomplish if you do not care who gets the credit. -- Harry Truman
Re:Bah humbug... by cotopaxi · 2003-11-09 22:00 · Score: 3, Insightful

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

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

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

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

*sigh* Clusters come nowhere near the level of fault tolerance you get in big iron. In a real fault-tolerant system, there are multiple paths for all transactions; in essence, you're running the same code on two (or more) CPUs. If one fails, you have zero downtime, other than a quick reroute in hardware to compensate (you probably wouldn't even notice it). To the best of my knowledge, there is no clustering solution which comes close to this, whether based on linux, Unix or Windows.
Yes, clusters can do a job which is "good enough" to replace expensive mainframes, but there are some cases where they aren't good enough, especially banking where you have to be 100% confident that every transaction is logged correctly.
Re:Bah humbug... by stripes · 2003-11-10 05:07 · Score: 3, Informative

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

Think about hardware at the gate level, your adders are a bunch of flip flops. A whole lot of them. And very very tiny ones holding very little charge. A cosmic ray striking one can change it's value (I think only form one to zero, or zero to one depending on the process and wether charged or discharged represents a zero or a one). If the cosmic ray hits one of the flip flops that is being used to produce a value about to go to a live register and then off to memory it can change the results from what your code should calulate to something with a one bit error. Maybe a low bit and the result is off by pennies, maybe a high bit and the result is so amazingly off that an assert later in the code catches it, or just a human eyeballing the results would. Worse yet something in the mid rage that nobody notices until far too late (if ever).
This is the same thing that ECC in memory helps prevent (ECC can't protect against multiple bit failures, but while a box with multiple gigs of memory will likely get a soft memory error in your lifetime, multiple bit errors before the scrubber finds them is really really really amazingly unlikely).
It is a force that gets worse as we go to lower voltage systems (less of a hit needed to flip values), and as we get greater densities (more likelyhood of the cosmic ray hitting something other then dead space -- at least I think so on this one).
It can be combated by having ECC on register and cache values (or even parity as long as the bits are "big enough" that a single cosmic ray hit won't flip multiple bits!), but having similar checks on ALU operations, or just sending the values through identical ALUs that are on diffrent parts of the chip and compairing them after (rerun any cycle where the results differ, either totally in hardware or trapping to the OS to let it restart the instruction after logging the hit). Not rocket science, but it makes for a more costly CPU, and it makes for a slightly slower CPU (in fact much slower when you factor in the extra transistors used for correctness checks that a "normal" CPU would use for cache or some other performance boosting geegaw).
As for documentation I don't recall where I saw studies done, probbaly in one of the ACM or IEEE procedings, but if you don't have access to them comp.risks might turn something up (and a lot of other stuff that might be more worth worring about :-)

Just announced... by fredbox · 2003-11-09 11:19 · Score: 5, Funny

Microsoft Visual COBOL++.NET 2003

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

--
His name was Robert Paulsen.

manged?? by Anonymous Coward · 2003-11-09 11:19 · Score: 4, Funny

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

I think the correct spelling is mangled.

hog wash by Anonymous Coward · 2003-11-09 11:21 · Score: 3, Interesting

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

200 billion lines? by Lxy · 2003-11-09 11:21 · Score: 3, Funny

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

--

There is no reasonable defense against an idiot with an agenda
:wq

Re:200 billion lines? by nonregistered · 2003-11-09 11:39 · Score: 3, Funny

Or zero lines of... Ooops. I guess I should posted earlier.
Re:200 billion lines? by Tisephone · 2003-11-09 11:41 · Score: 3, Funny

Yeah, 4 lines containing 200 billion parentheses.

--
"Neque enim lex est aequior ulla, quam necis artifices arte perire sua."

What are the Linux COBOL solutions? by beamdriver · 2003-11-09 11:22 · Score: 5, Interesting

Has anyone used Tiny Cobol or Open Cobol

Oh no! by Danathar · 2003-11-09 11:25 · Score: 5, Funny

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

I DO NOT want to have to debug visual COBOL!

Why would you? by msgmonkey · 2003-11-09 11:25 · Score: 4, Interesting

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

Re:Why would you? by Tablizer · 2003-11-09 11:44 · Score: 5, Interesting

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

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

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

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

--
Table-ized A.I.

Re:As much as I hate MS this is very smart. by Jameth · 2003-11-09 11:26 · Score: 4, Funny

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

Sounds about right... by dillon_rinker · 2003-11-09 11:28 · Score: 3, Funny

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

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

Re:Sounds about right... by jvollmer · 2003-11-09 11:38 · Score: 3, Funny

Want your COBOL code to be hairless, oozy, and irritated?
Hairless, oozy, and irritated? You're talking about Ballmer, right?
If it's not Consolidated Lint, it's just fuzz!

Speaking of Gartner... by checkitout · 2003-11-09 11:30 · Score: 4, Interesting

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?

Re:As much as I hate MS this is very smart. by ericman31 · 2003-11-09 11:31 · Score: 4, Insightful

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

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

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

--
In my universe I'm perfectly normal, it's not my fault you don't live in my universe.

Don't hold your breath... by Dinosaur+Neil · 2003-11-09 11:31 · Score: 5, Insightful

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

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

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

Good thing I'm not bitter.

--
"I'm a scientist! I don't think, I observe!" - Dr. Clayton Forrester

Emulation? by G4from128k · 2003-11-09 11:33 · Score: 3, Funny

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

--
Two wrongs don't make a right, but three lefts do.

The Latest From Microsoft R&D... by cmacb · 2003-11-09 11:40 · Score: 3, Funny

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

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

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

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

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

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

Re:Yikes by ericman31 · 2003-11-09 11:42 · Score: 5, Interesting

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

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

--
In my universe I'm perfectly normal, it's not my fault you don't live in my universe.

if it ain't broke, don't fix it! by kraksmoka · 2003-11-09 11:50 · Score: 4, Interesting

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

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

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

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

--
"You never want a serious crisis to go to waste." - Rahm Emanuel

Re:if it ain't broke, don't fix it! by azzy · 2003-11-09 12:12 · Score: 5, Funny

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

Inertia, maintenance and programmers by Anonymous Coward · 2003-11-09 11:52 · Score: 5, Insightful

Just some thoughts,

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

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

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

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

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

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

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

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

finally ..

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

This is not new news... by madmarcel · 2003-11-09 11:54 · Score: 4, Insightful

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

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

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

Re:Why not just recompile COBOL for Linux? by lurker412 · 2003-11-09 12:02 · Score: 3, Informative

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

The issue is not COBOL.. by Garg · 2003-11-09 12:02 · Score: 5, Insightful

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

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

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

Batch. These are the payroll-type systems that run in the background, are are mostly ignored by people claiming to be able to migrate systems. The thing is, these systems are full of extensions for mainframe-type filesystems or databases, like VSAM or IMS. So while MicroFocus handles some of that stuff correctly, it won't handle it all.

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

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

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

Garg

--
Garg
Alumnus, Xavier's School for Gifted Youngsters

Circle Ten? by sbaker · 2003-11-09 12:13 · Score: 3, Funny

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

--
www.sjbaker.org

Re:As much as I hate MS this is very smart. by molarmass192 · 2003-11-09 12:13 · Score: 3, Insightful

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

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

--

Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato

Re:Why was COBOL so prevalent in the first place? by Multics · 2003-11-09 12:19 · Score: 3, Informative

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

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

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

-- Multics

A joke. by Mr_Icon · 2003-11-09 12:21 · Score: 5, Funny

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.

Talk about walking into a buzzsaw by salesgeek · 2003-11-09 12:25 · Score: 3, Informative

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

C0b0l is teh l33t by UltraSkuzzi · 2003-11-09 12:31 · Score: 3, Funny

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.

heard about Object Oriented Cobol? by Jamie+Zawinski · 2003-11-09 13:43 · Score: 4, Funny

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

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

Without JCL (& other stuff) it just won't matt by PinchDuck · 2003-11-09 15:06 · Score: 5, Insightful

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

In My Day... by tspauld98 · 2003-11-09 15:20 · Score: 3, Interesting

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

Re:As much as I hate MS this is very smart. by ericman31 · 2003-11-09 15:24 · Score: 5, Interesting

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

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

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

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

--
In my universe I'm perfectly normal, it's not my fault you don't live in my universe.

If FORTRAN is a forcast ... by twitter · 2003-11-09 15:46 · Score: 3, Insightful

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

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

--

Friends don't help friends install M$ junk.

Re:Try x86 assembler.NET :) by Leeji · 2003-11-09 16:03 · Score: 3, Funny

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

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

--
It all goes downhill from first post ...

Re:.NET and C# by big-giant-head · 2003-11-09 18:08 · Score: 3, Informative

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

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

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

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

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

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

--

So Long and Thanks for all the Fish.

Economics 101 people!! by DukeyToo · 2003-11-10 02:25 · Score: 3, Insightful

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

They can keep it by carldot67 · 2003-11-10 09:27 · Score: 3, Interesting

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

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

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

Check this out:

No specs

No doco

Some of it was in mainframe assembler

Object orientated? ha ha ha

Structured programming? oh my god ha ha ha

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

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

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

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

I think you get the picture.

Screw that.

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

--
I wish at was Friday, but I dont want to wish my life away. So I wish it was last Friday.

Slashdot Mirror

Microsoft Makes Push for COBOL Migration

53 of 487 comments (clear)