How to Move Cheaply Out of COBOL
in [Cobol]
|
From: Pete Dashwood on 23 May 2010 12:27 SkippyPB wrote: > On Fri, 21 May 2010 13:27:20 -0500, "Joel C. Ewing" > <jREMOVEcCAPSewing(a)acm.org> wrote: > <snipped> > I have to go with Joel here about costs. While the government usually > isn't on the forefront of technology, I believe they have switched off > of the Burroughs mainframes that used to run everything to IBM's zOS > hardware. As for using COBOL to run the bulk of their applications, > there is absolutely nothing wrong with that in my opinion. There wouldn't be, if those applications hadn't changed for 40 years... (and some of them haven't, so you are right about those ones, at least :-)) The problem is not with COBOL as a language. They would have the same problem if their applications were written in Fortran or Algol or PL/1. The access and distribution of data in the modern world requires a network. People and departments need to be able to share data and have open access to it, using standard tools like spreadsheets and databases. Procedural languages like those mentioned, and including COBOL, are just not good at this. The network needs objects it can run locally and remotely, distributing data and processing power so everybody has the fastest possible access, whether updating Tax tables or inputting GNP data, or getting information on demand. For batch processing (and provided the data is held in open repositories like a Relational Database that can be accessed for ad hoc enquiries and updates, rather than locked into an indexed file that requires a program to be written so it can be accessed), there is certainly nothing "wrong" with using COBOL. However, it is NOT the best tool even for this job. It is limited to ESQL and that is heading for obsolescence. Functional programming and LINQ can retrieve and manipulate data using multiple cores and parallel processing with a fraction of the IO that ESQL requires. >So what if > the language is over 50 years old. Agreed, the problem is not about how old the language is. It is about what it can do, in a modern environment running on modern platforms. > It has, in recent years, been > upgraded and enhanced not only by IBM but other companies as well. But that means nothing if the users don't embrace those enhancements. OO COBOL has been around for nearly 20 years now. It was a huge software engineering effort to produce it, and the people responsible realized the way things were heading and didn't want COBOL to miss the boat. Unfortunately, the user community failed to share the same vision and the boat sailed with COBOL standing on the jetty. > It > is well situated to be a cost effective language for the mainframe for > the next 50 years...far more than any of the current soup de jour > languages. No it isn't, Steve :-) Even with your careful "for the mainframe" qualification I would have to disagree. (Even assuming that "mainframes" as we currently understand the term are around in 50 years...). The "mainframe" role is changing and it is far more likely to be a network attached "super server" than the central core of all processing that it once was. As for COBOL's "cost effectiveness"... It is the MOST expensive programming language available. It costs more to buy, it costs more to write and it costs MUCH more to maintain than a "soup du jour" language like C# or Java, for example. COBOL: The compiler costs thousands of dollars, there are no prewritten libraries to speak of, although it can usually interface to prewritten libraries written in other ("soup du jour") languages (think about that; as one of the oldest languages in existence wouldn't you think there would be a HUGE base of available COBOL code to be reused?). It has to be written line by line (although COPY books can help with some of this, but they carry their own problems with things like versioning), and the maintenance of it is highly labour intensive with few decent tools and a diminishing skill base. The next 50 years? I don't think so. Maybe the next 5 or 6 :-) C# (and other "soup du jour" languages like Java, C++, VB.NET, etc): Compiler is FREE, Tools are FREE, and they come with around 80,000 prewritten objects which are debugged and ready to roll. (Also FREE) How did they get so far ahead of COBOL when they haven't been around half as long? Because they are PRODUCTIVE languages. You can write more powerful code in a fraction of the time, the tools are better, debugging is easier, and a single statement simply does more than COBOL does. Consequently, development and maintenance are less labour intensive and therefore considerably cheaper than is the case for COBOL. You may not LIKE the new languages but they are here to stay (until they evolve into even better incarnations of themselves.) Actually, once you make the jump and get immersed in the new technology, you realise how deceptively powerful it is. There are all kinds of facilities at your fingertips with tools that help you utilise them and online help available 24/7, from others who have done what you're attempting, complete with sample code and tutorials, for FREE. I worked with COBOL for over 40 years, made a living directly from it for 25, and absolutely loved writing it. But today, I have no hesitation in saying I would MUCH rather write C#. It is just a whole heap less aggravation. I can make things happer more quickly and easily and they are slicker things :-). My applications look and feel better thanks to cool user interfaces that are not just good looking, but useful as well. My productivity has increased out of sight and I can do ehancements and roll them out in time frames I could only dream of before. Millions of people every day are getting into computer programming. The free availability of compilers, tools, and training materials mean that anyone with a mind to can write applications for anything from a desktop or mobile PC, through the Web, to a PDA or mobile phone. Programming is no longer an exclusive club. We have seen in this very forum recently where people are even getting into mainframe programming, using their PCs. It is the "soup du jour" languages that have made it possible, not COBOL. Pete. -- "I used to write COBOL...now I can do anything."
From: Anonymous on 24 May 2010 09:18 In article <FoAJn.13334$Gx2.4508(a)newsfe20.iad>, Joel C. Ewing <jREMOVEcCAPSewing(a)acm.org> wrote: [snip] >I would take issue much earlier in the original comments starting with >the "These applications are very, very expensive to run on older >mainframes,...". > >Are they really running these applications on "older mainframes" -- >stuff from water-cooled days or earlier? Oh boy... Clean Rooms and Halon alarms! [snip] >There seems to be all sorts of confusion here about potentially distinct >choices for programming language, hardware choices, and Operating System >platforms. In my experience, Mr Ewing, what is usually wanted is the latest-in-fashion interface running code that does *exactly* the same thing as the Old System did (and a wee bit more, of course) and can be implemented without anyone needing the skill to spell 'ROI' and maintained by part-timers recruited from the local high-school G4m3r'z Club. When it gets pointed out that professional security, profesional quality and other professional-type stuff needed to pass a Real Audit and/or keep a system chugging through a billion or so transactions a day with worldwide access (perhaps Mr Trembley might hide a grin at that thought) will Cost Real Money, require Real Machinery and necessitate employing people with Real Skills that Don't Come Cheap... my experience is that a hand gets waved and someone says they are a Big-Picture Guy. DD
From: Anonymous on 24 May 2010 09:34 In article <85t3c3FkerU1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: [snip] >As for COBOL's "cost effectiveness"... It is the MOST expensive programming >language available. It costs more to buy, it costs more to write and it >costs MUCH more to maintain than a "soup du jour" language like C# or Java, >for example. Mr Dashwood, our experiences may have been different... but I believe in your assertoion about programming costs you many be negelecting a few things like CBA and ROI. Yes, COBOL costs a whole bunch of cash to spec out and amplement, tune the JCL. get the CA/CI split *just* right... .... but once all that's done... that's it. this is precisely the 'difficulty' (note the ') that mamy folks are concerned about. I, along with others, have worked with code that is old enough to vote... and a tweak here, a pinch there, a change from an EXAMINE to an INSPECT... and the code's back to doing what it was intended to do, ie Make The Company More Money. The 'problem' (again, note the ') from the management side is that folks who have the skills to do this are few and far between... and We Cost Money. That the amount we cost, when compared to the amount the functioning systems earns the corporation, is minimal, is dismissed with another wave of the hand... guys who can fix this Cost Money, let's replace everything (never mind *that* cost) so when fixing's needed the guys who can do it are less expensive. DD
From: Howard Brazee on 24 May 2010 10:10 On Fri, 21 May 2010 05:21:13 -0400, Ubiquitous <weberm(a)polaris.net> wrote: >"These applications are very, very expensive to run on older mainframes, >whether that's an IBM or Unisys platform. There's really just a few ways >government will address this issue -- do you rewrite these applications into >Java, which could take years and years? Do you replace them and go to a COTS >package -- and that's a little difficult when an application could have 30 >million lines of COBOL code going to an ERP? Or, do you do nothing and keep >paying the expensive cost to maintain these applications?" Why re-write them in Java? Does Java run more cheaply than CoBOL? Tendencies I have seen have been to replace custom software with packages. And say, this time we really mean it about not customizing - if our business doesn't fit the software - change the business. Many of those packages still have significant CoBOL in them, but we don't see them, we don't maintain them, so it doesn't matter. -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison
From: Howard Brazee on 24 May 2010 10:25
On Mon, 24 May 2010 13:34:14 +0000 (UTC), docdwarf(a)panix.com () wrote: >The 'problem' (again, note the ') from the management side is that folks >who have the skills to do this are few and far between... and We Cost >Money. That the amount we cost, when compared to the amount the >functioning systems earns the corporation, is minimal, is dismissed with >another wave of the hand... guys who can fix this Cost Money, let's >replace everything (never mind *that* cost) so when fixing's needed the >guys who can do it are less expensive. A big issue with this is that much of society has moved to a short term view. Businessmen have followed the lead of politicians here, and the idea of educating our own workers is seen as an expense that won't pay out. It won't pay out because the workers are likely to take this new skill to competitors, and it won't pay out because the managers will have the short term costs in their resumes as well. But it is possible to find people who used Java in school and at home. They don't need business experience to put Java on their resumes. And it's easy to avoid analyzing how long it takes them to learn the business side of their work. I'd love to see companies offering delayed bonuses. The CEO gets real nice stock options that can't be cashed for 10 years. The company (and other entities) would be better off switching to long term strategies. -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison |