How to Move Cheaply Out of COBOL
in [Cobol]
|
From: Pete Dashwood on 25 May 2010 09:33 SkippyPB wrote: > On Mon, 24 May 2010 08:25:57 -0600, Howard Brazee <howard(a)brazee.net> > wrote: > >> 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. > > The issue I have with OO at least as it applies to the mainframe and > the industry I am most famaliar with, banking, how can you have > "libraries" with predetermined rules from the complier manufacturer > when those rules change more often than a baby's diaper? I've had a bit of exposure to Banking, Steve and count Chase Manhattan, Citibank, Banco Hispano Americano, and Deutsche Bank on my CV. You've asked a fair question so I'll try and answer it. First, the "libraries" may or may not be supplied by the compiler vendor. However, it is unreasonable to expect that if a compiler vendor is intending to do business with a major Bank, they would have something to sweeten the deal? Like a set of useful Banking Classes, written in the language of the compiler they are selling? (Microsoft's .NET has over 80,000 classes in it (for FREE) and that is not application specific; third parties provide libraries for specific industries.) The "libraries" contain Classes and these may or may not have rules. (Things that are governed by rules can have attributes to accommodate those rules and the specific attributes can be updated globally at every diaper change. :-) Doing this can automatically change the behaviour of the Class, without further programming. ) Consider a Class called "Loan". Objects of this Class have certain attributes (properties) and methods (behaviours). Some of the attributes might be: type of Loan amount term interest rate current balance method of payment frequency of payment early termination penalty credit checked source raised by raised date approved by approved date customer account Some of the methods might be: Create Loan Terminate loan Recalculate loan Apply to DB Populate Loan attributes Generate history report Generate statement for a given month Validate attributes Now, instead of havng to design your Loan file from scratch, if you have such a library provided, you have a start point. Suppose it has some advanced methods like a what-if analysis, discounted cash flow, NPV of funds, future values etc? All written and debugged out of the box. Instead of having to write code to do the above, it is all written and debugged for you. The methods work.Not only that but they are inherent in the object, so every time you instantiate a loan object, and invoke the 'populate attributes' method (probably providing a customer account), you immmediately have all of this stuff at your fingertips. For a Banking application, such Classes would also have the source code supplied (for security; the Bank won't run code they cannot see) so you can look at the application code you didn't have to write :-) But really it doesn't matter. You are not going to maintain these methods. You may override some or all of them and you may add others specific to your Bank, but it is the Object that is important, not the source. If you have a screen (say a CICS BMS map) that contains the attributes, you can load the Object's attributes from the screen buffer, invoke the "validate" method, then invoke the "Apply to DB" method. In OO parlance this is called "persisting" an object. The above is a clumsy contrived example but I hope it makes the point that Banking, just like most other applications, can be implemented using an Object Model just as easily as it can be with a procedural model. > Where is the > control? It's not there. Why isn't it? If you control who can instantiate an object and under what conditions, how is the control not there? Furthermore, my loan object can run on the desktop or a web page, remotely or locally, and in all these instances it is still subject to defined controls and permissions. Say a customer moves to another town. The new local branch can process her loan exactly as the originating branch did, instantly, and in real time with no further programming effort by anybody at the new or the old branch. Don't run away with the myth that only mainframes have control. (If you've ever had to manage Group Policies and ACLs under Windows you'd realize how offensive that is :-)) > Business rules change often which is > probably why in 20 years OO hasn't caught on because it is just not > practical. It is very practical and it isn't necessary for the compiler vendor to supply the object libraries. (see above). If the "rules" change (say a global interest rate rise of 3 points, applied to all customers except ones with some specified criterion), that will be applied to all the customers it should be, whether the system is object oriented or it isn't. OO "hasn't caught on" not because it isn't practical (it is...very...) but for the very reason we are having this conversation; a lack of awareness of the techniques and the model on the part of COBOL guys and their managers. I think this is changing, by the way. As more of the traditional COBOL base (insurance companies, banks, airlines...) move to distributed networks the pressure on COBOL and procedural development increases. One way is to wrap the procedural code as service objects and make it part of a SOA, but as exposure to objects increases and programmers become more confident with the object model, they soon come to realise that developing new Classes in COBOL is just unwieldy. COBOL gets relegated to being "legacy objects" and eventually is replaced. >You cannot expect the compiler manufacturer to supply > these "libraries" as part of the compiler. > Given what they charge for COBOL, I certainly WOULD expect them to provide some kind of added value (God knows, the toolset is Spartan enough...). But, again, it doesn't matter WHO supplies it as long as they have expertise in the field and their classes are thoroughly documented and debugged. > Now you'll probably say well the IT department does that. Well we've > been doing that for 50 years. They're called subroutines and they > don't add to the cost of the compiler. Surprisingly enough, I agree with you here. Modular procedural programming is an important step forward and the use of modules does give many of the advantages of an object oriented system. However OOP is not just modular programming re-invented; there are MANY further benefits in using objects which are not available with modular programming. Object orientation is a different paradigm from even modular procedural programming, but many of the differences are subtle and too much to go into here. Besides, I'm not an evangelist for OOP and I'm not on commission. (I honestly don't care whether people use it with COBOL or not...why would I? :-) ) I've simply taken time to respond to your fair question because it was honestly asked and I understand your position on it Cheers, Pete. -- "I used to write COBOL...now I can do anything."
From: Anonymous on 25 May 2010 09:59 In article <861qs8F6sfU1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: >docdwarf(a)panix.com wrote: >> 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. > >Nope, I considered both. Although some accountants would argue that a Cost >Benefit Analysis should arrive at an overall projected ROI. > >The subtle difference is that CBA is projected or estimated (and therefore >subject to bias), while the ROI is historical fact and difficult to argue >with. Those who have seen minor, inexpensive changes result in great savings or Grand, Earth-Moving Plans proven to be so ill-thought-out that a company goes under might debate that 'historical fact and difficult to argue with' bit. > >In terms of CBA, COBOL has a higher up front cost (software, tools, >ancillaries) than alternatives, a higher development cost (it is very labour >intensive to write, compared to alternatives), and a higher ongoing >maintenance cost (again because it is labour intensive, but really because >there is simply more of it than there is with alternative languages. I find >conservatively a 3:1 ratio between COBOL and C# (given that both are >written by competent programmers) with 700 lines of C# generally being >equivalent ot 2000 lines of COBOL. By your own admission, Mr Dashwood, what you've found is (linguistic tense of 'found' is past) is a made thing, a 'factum'; since you assert CBA is projected or estimated there seems to be a bit of conflict here. A higher development cost might be due to a tendency to 'keep the code supple', allowing for ease in modification; this might result in a lower ongoing maintenance cost. The conservative figures you posit are interesting but a bit more formalised study might be in order; are there any studies performed by others you might present of two different systems, each of more-or-less identical systems - order entry, inventory management, payroll tracking for organisations of 100,000 employees or more - each written in a different language and the resulting expense-records for both over the same period of time, say, minimally five years? >However, this is a subjective judgement >based on a limted sample so it is probably fair to exclude it from this >argument. Oh... well, in the future it might be interesting to keep an eye out and see what might be found; hard data make, quite frequently, for discussions that are entirely different than discussions based on subjectives. >Let's say COBOL costs the same to maintain as anything else. It >still loses on purchase and development costs. Not for companies who purchased it long enough ago (3 years, in the USA) so that the expense of the purchase has been completely depreciated. > > >>Yes, COBOL costs a whole bunch of cash >> to spec out and amplement, tune the JCL. get the CA/CI split *just* >> right... > >Agreed. >> >> ... but once all that's done... that's it. > >Except that we would just like this one small change ... :-) > >And it took so long to develop that the requirements have changed, so can >you tell us when Release 2 will be ready, please? :-) Easily enough done... it is the same as with any other data processing project: on time, on spec or on budget, you get to pick two *and* you get to live with your choices. > > > >> 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. > >Yes, that matches my experience also :-) BUT, ONLY if the 'tweak here and >pinch there' is TECHNICAL and not related to FUNCTIONAL requirements. If one expectes code written for a particular function to assume another function one might have the same kind of satisfaction as one would get out of using a tool designed for one function - say, a micrometer - for another function, eg driving 20d nails into oak planks. Different functions, different tools; it is the same with programs. [snip] >Even if dynamic markets are not an issue the methodology has a bearing on >the maintenance. Large monolithic programs developed in COBOL using the >traditional Waterfall, are very costly to maintain. A 'tweak here and a >pinch there' can cause unforeseen consequences in unexpected places. Even in >other programs than the one maintained, if downstream feeds have been >affected by the pinch or tweak. This might be a reason to have a Shop Standard which limits such Q'abbas of Code... you know, a different design, something like a driver, function routines and called subroutines. I believe the CALL imperative was introduced a few decades back; that programs can still be designed poorly is not, I would say, the responsibility of the programmer. > >"Soup du Jour" programs, being Object Oriented are far less likely to suffer >from this problem. Instead of the "unit of intelligennce" in the program >being a "line of code" it is typically an "object" (component). So the >"granularity" of the solution is larger and it is easier to pull and replace >components than it is to find and fix a given line of code. It is like >fixing a modular stereo; you may replace the amplifier, rather than find the >particular resistor or diode that is failing. At least you have the >option... With COBOL, you don't. With COBOL, you do... when you've designed appropriately. > >> >> 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. > >This is a different part of the argument and I agree with what you are >saying. COBOL skills are becoming scarcer as demand for them drops and, like >any market place, this means they become more valuable in the short term. >(When demand becomes zero, they are worth nothing...). 'A cynic is one who knows the price of everything and the value of nothing', said Mr Wilde... don't let's try to confuse 'value' and 'worth'; this is a reason I spoke of Mere Money. >Of course, if they >are priced too high then this contributes to COBOL itself becoming >non-viable and industry looks for other (cheaper) solutions. That is >precisely one of the factors leading to the current decline of COBOL; it >costs too much and the people who can do it cost more than people with skill >in other languages, who can also do it. So, COBOL people are retained >because they HAVE to be (usually to keep legacy running) until another >solution is found. .... and then, despite having (n) decades of experience getting computers to do what people *mean*, instead of what people *say*, they get The Boot because... because of what reason, Mr Dashwood? Might it be that they Cost Too Much? > > >> 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. > >(It seems from the above you agree with my posit that COBOL is expensive to >maintain.) No, Mr Dashwood. I state that someone with (n) decades will, most likely, cost more than someone with less experience. The language involved is not a matter of consideration. > >I don't think it is quite as simple or black and white as that but wouldn't >you expect that to be the case? I would expect that if Experience is the Dearest Teacher then someone might realise it will cost more money to pay someone taught by the Dearest Teacher than to pay someone else who had a web-tutorial in the latest buzzwords, yes. > >Someone is charged with getting the best deal possible for the company. *There* is the rub, Mr Dashwood... 'the best deal possible' over what period of time? Is it a better deal for the company to have code that, while being old enough to vote, is rock-solid and Just Keeps Running... or is it the best deal to find an group of 18-year-olds who cobble something together in GWBASIC that will require a complete rewrite when your organisation buys out a competitor? (Granted, the examples were chosen as extremes but I believe the picture has been sketched.) *That* is the primary reason for ROI analysis... that can be measured over years while CBA is more task-oriented. [snip] >"Guys who fix this cost money". If we didn't have this we wouldn't need to >fix it. Is there some other way we can administer our business without it >costing us an arm and a leg? There is...? OK, let's do that. Right... so let's do it by designing it to be simple to fix and require as little fixing as possible. DD
From: Howard Brazee on 25 May 2010 11:16 On Wed, 26 May 2010 01:33:25 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >Instead of having to write code to do the above, it is all written and >debugged for you. The methods work.Not only that but they are inherent in >the object, so every time you instantiate a loan object, and invoke the >'populate attributes' method (probably providing a customer account), you >immmediately have all of this stuff at your fingertips. They work - according to some standard specifications. As long as those specifications don't change, the library shouldn't change. There can be a downside - for instance when a governing body changes some requirements, and you need to apply that change to some, but not all of your systems. When code is used many places, sometimes it is useful to avoid implementing changes globally. -- "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 25 May 2010 11:20 On Tue, 25 May 2010 13:59:58 +0000 (UTC), docdwarf(a)panix.com () wrote: >*There* is the rub, Mr Dashwood... 'the best deal possible' over what >period of time? Is it a better deal for the company to have code that, >while being old enough to vote, is rock-solid and Just Keeps Running... or >is it the best deal to find an group of 18-year-olds who cobble something >together in GWBASIC that will require a complete rewrite when your >organisation buys out a competitor? (Granted, the examples were chosen as >extremes but I believe the picture has been sketched.) *That* is the >primary reason for ROI analysis... that can be measured over years while >CBA is more task-oriented. For many, ROI can be defined as "how I can leverage this project gets me a promotion or new job before the full costs get accounted for". -- "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: Anonymous on 25 May 2010 11:26
In article <gjqnv5th6uvmsquh7hmat6djv8fosq4ne4(a)4ax.com>, Howard Brazee <howard(a)brazee.net> wrote: >On Tue, 25 May 2010 13:59:58 +0000 (UTC), docdwarf(a)panix.com () wrote: > >>*There* is the rub, Mr Dashwood... 'the best deal possible' over what >>period of time? Is it a better deal for the company to have code that, >>while being old enough to vote, is rock-solid and Just Keeps Running... or >>is it the best deal to find an group of 18-year-olds who cobble something >>together in GWBASIC that will require a complete rewrite when your >>organisation buys out a competitor? (Granted, the examples were chosen as >>extremes but I believe the picture has been sketched.) *That* is the >>primary reason for ROI analysis... that can be measured over years while >>CBA is more task-oriented. > >For many, ROI can be defined as "how I can leverage this project gets >me a promotion or new job before the full costs get accounted for". The world may be full of Humpty Dumptys, Mr Brazee, but they do not, I believe, constitute an accepted body for definitions of the Terms of Art used by Accountants. ( http://dictionary.reference.com/browse/roi : the amount of profit, before tax and after depreciation, from an investment made, usually expressed as a percentage of the original total cost invested. Abbreviation: ROI) DD |