How to Move Cheaply Out of COBOL
in [Cobol]
|
From: Pete Dashwood on 25 May 2010 11:53 Howard Brazee wrote: > 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. Yes and no. For example, imagine an invoicing system with an invoice object. There will be a method that calculates the line total by multiplying the quantity sold by the unit price, then applying any discounts, and taxes. If the unit price or tax rate change then the library doesn't change. Only the attributes of the invoice object are affected. (And they are retrieved from a database when the object attributes are populated.) If it was decided that the process was to be changed, say calculations must be applied in a diffferent order, for example,(specifications changed) then there are several ways to approach this. For myself, I would NOT change the library (in fact, I might not have the source code, so I couldn't anyway...) Instead, I would rewrite the line total calculation method and have it override the original method, retaining the same interface. Any other methods that use this method will still function correctly because the method signature hasn't changed. > > 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. It isn't hard to only override the method in systems that need the new process, and leave it in systems that don't. > > When code is used many places, sometimes it is useful to avoid > implementing changes globally. I think it depends on the change. Using objects and layers means that objects can control behaviour by means of attributes. (e.g. you could add an attribute to the object that told it whether to override the method or not. It is then very simple for the invoker of the method to set that attribute before invoking the method. That is just one way, there are many. The general idea is to encapsulate behaviours and let the consumer decide how they want the behaviour modified, if they want it modified. Pete. -- "I used to write COBOL...now I can do anything."
From: HeyBub on 6 Jun 2010 11:53 Pete Dashwood wrote: > > 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), ... And therein lies the weakness, the flaw, the vulnerability. One of the biggest obstacles to advancement of the human condition, world peace, and quite possibly the cure for cancer, is the unfettered tinkering with the data. I've worked in more than one shop where weekly catastrophes were routinely discovered to lie at the feet of uninhibited - in the guise of emergency - use of Easytrieve! This handy program for generating "ad hoc" reports was sometimes used to "correct" the data. Due to bumbling, mistake, and quite possibly malice, spurious figures were sometimes introduced into the data. For example: * An oil well depth of -17,000 feet. The definition of well depth meant that this value asserted there were over three miles of pipe sticking straight up in the air! * A logged temperature of 88 degrees, supposedly Kelvin. This temperature would freeze crude oil into something as hard as an anvil. * And so on. It may be obvious that the criminal is the culprit in a jail-break, but some blame has to lie with the fool that gave him the hacksaw in the first place. Only by limiting those who were able to read and write to pious monks and not turning literacy loose on the great unwashed, were we able to pass down faithful reproductions of Holy Writ. No wait...
From: Anonymous on 6 Jun 2010 14:37 In article <Qq2dnSDon6nhWZbRnZ2dnUVZ_sqdnZ2d(a)earthlink.com>, HeyBub <heybub(a)NOSPAMgmail.com> wrote: [snip] >Only by limiting those who were able to read and write to pious monks and >not turning literacy loose on the great unwashed, were we able to pass down >faithful reproductions of Holy Writ. > >No wait... .... and consider that there are other views of the world, that, say, one that has at the center of the Celebration of Adulthood a demonstration of one's ability to read, in public, from the Holy Writ. DD
From: Pete Dashwood on 6 Jun 2010 18:34 HeyBub wrote: > Pete Dashwood wrote: >> >> 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), ... > > And therein lies the weakness, the flaw, the vulnerability. > > One of the biggest obstacles to advancement of the human condition, > world peace, and quite possibly the cure for cancer, is the > unfettered tinkering with the data. :-) "unfettered tinkering", eh? > > I've worked in more than one shop where weekly catastrophes were > routinely discovered to lie at the feet of uninhibited - in the guise > of emergency - use of Easytrieve! Yes, if you give a power drill to a 4 year old and leave the room, expect to find holes in the furniture when you come back. People need to be trained not only in the use of tools , but also in when to apply them, and the use of the tools needs to be supervised or locked out without proper presentation of credentials and authorisation. You have completed your "apprenticeship" and satisfied your mentors that you are now a capable and responsible IT prefessional who can be allowed access to important data. You get a certificate and a set of credentials (account and password) that give you the keys to the data resource. Unfortunately, mostly, this doesn't happen. If a man using a Bobcat to excavate his garden cuts through a main power supply cable and plunges a few suburbs into darkness, should we blame the diesel powered tool or the glucose powered man using it? The point is that it doesn't matter whether the tool is Easytrieve or Crystal Reports, if you don't have proper access protocols and audit trails, you deserve whatever chaos ensues. > > This handy program for generating "ad hoc" reports was sometimes used > to "correct" the data. Due to bumbling, mistake, and quite possibly > malice, spurious figures were sometimes introduced into the data. For > example: > * An oil well depth of -17,000 feet. The definition of well depth > meant that this value asserted there were over three miles of pipe > sticking straight up in the air! Software without "sanity checks" (like not allowing negative values for something like a hole in the ground) is likely to generate tears. Software engineers who don't understand what they are doing are also likely to cause much wailing and gnashing of teeth. > > * A logged temperature of 88 degrees, supposedly Kelvin. This > temperature would freeze crude oil into something as hard as an anvil. > > * And so on. > > It may be obvious that the criminal is the culprit in a jail-break, > but some blame has to lie with the fool that gave him the hacksaw in > the first place. Or the protocols which permitted a hacksaw to be passed. > > Only by limiting those who were able to read and write to pious monks > and not turning literacy loose on the great unwashed, were we able to > pass down faithful reproductions of Holy Writ. > And the World became a better place :-) > No wait... Pete. -- "I used to write COBOL...now I can do anything."
From: Howard Brazee on 7 Jun 2010 09:54
On Sun, 6 Jun 2010 10:53:31 -0500, "HeyBub" <heybub(a)NOSPAMgmail.com> wrote: >* An oil well depth of -17,000 feet. The definition of well depth meant that >this value asserted there were over three miles of pipe sticking straight up >in the air! That's funny - but I have seen similar confusing with plus and minus debits and credits. It's funny to compare consumer debit and credit cards when their names describe what they are to the banks, not the consumers. But consumers don't generally know what the accounting terms mean anyway. -- "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 |