How to Move Cheaply Out of COBOL
Ubiquitous
Internet Editor
Federal News Radio
Many federal agencies are using machines that are running software developed
25 to 35 years ago, and they're still going strong.
These machines are using the COmmon Business-Oriented Language (COBOL) to get
things done.
Invented in 1959 by Naval officer Grace Hopper, COBOL is still a prevalent
force throughout the federal government.
There are still about 200 billion lines of the code in live operation, and 75
percent of business-critical applications and 90 percent of financial
transactions use it.
It's a very secure, easy-to-learn language, but it's running into some
problems now that the Obama administration has issued modernization
initiatives such as the Open Government Directive.
Joe Moyer is regional director of Micro Focus, a company that's helping
federal agencies move their platforms from COBOL to newer ones.
"It is a very secure and solid and very good language for transactional
business. It's really running the critical mission applications in our our
government today. So, when these applications have been around for so long,
how do you make changes? How does the government address this issue?" Moyer
explained.
COBOL does its job, but it is old, and the Obama administration is running
into problems. Since one of its goals is to modernize government while
lowering costs, COBOL is becoming a bit of a sticking point.
"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?"
Moyer says his company provides a solution that could enable the government to
reuse what it has with a software appliance that moves applications from COBOL
to one like Windows or Unix.
And then there's also the Open Government Directive.
A lot of agency information is being held hostage, so to speak, by COBOL.
Moyer explained that the IRS, SSA and even parts of DHS and DoD still use
COBOL in a closed environment.
"Can you really go to an SOA environment or to cloud computing from the
mainframe? . . . We can actually take a COBOL application and move it to [an]
open environment. . . . [COBOL] works. It's a fantastic language. It's written
in English. It's very easy to develop, and that's why many agencies have not
moved off it yet. So, with the Obama administration's modernization
initiatives, why not save millions and millions of dollars while keeping that
secure language behind the scenes."
Pete Dashwood
Moyer is marketing Micro Focus. And it is not a bad solution but it neglects
the fact that COBOL cannot be a long term solution. (To be fair, you can
hardly expect a marketing spokesperson to understand the subtle differences
between technical paradigms; his job is to market a COBOL solution and
ensure an ongoing revenue stream for the company, not to raise awareness of
WHY COBOL needs to be replaced.)
Re-compiling existing code for .NET simply enables a platform transfer, it
DOESN'T open up the COBOL resources so they can be easily integrated with
other languages and packages. To do that, the COBOL needs to be wrapped as
objects, and if you are going to wrap it as objects, there is no need for a
.NET compiler. (The .NET platform is designed to accommodate objects that
are not managed code, using InterOP services.)
Continuing development in COBOL is fine as an interim measure while people
are being trained in newer languages and techniques but ultimately you
either salvage or rewrite the code you have. Either way, just recompiling it
to run on the .NET platform simply perpetuates the use of COBOL "as it is".
Many companies are finding that, in today's world, that is proving to be
simply not enough.
Modern tools and techniques deal with objects and layers and traditional
COBOL doesn't. (OO COBOL as implemented by MicroFocus and Alchemy, to name
just two major players, is a step in the right direction, but it is
expensive and the OO features were bolted onto it, so it can never be as
powerful as languages designed to manage objects from the day they were
conceived.)
PRIMA is committed to providing tools that move traditional COBOL into the
new world of Object Orientation. We already have tools that enable fully
automated conversion of COBOL file-based solutions to be moved to Relational
database. That is an important step, because it opens up the data resource
without requiring manual amendment or rewrite of existing code. (The tools
amend the code automatically to access the new RDB, so it continues to
function logically as it always has, but now other tools and other languages
can access the data, as well as COBOL.) Both the new database and the code
that accesses it can be generated automatically from existing COBOL
copybooks.
The process is a simple 3 step one and we have tools that do each step fully
automatically:
1. Create a new Relational database that is functionally equivalent to the
existing file base. (A set of tables on a Relational Data Base (RDB) is
generated in at least 2NF for each existing indexed file.)
2. Objects are generated (callable locally or remotely from the desktop or a
web page) to manage each of the generated table sets. These are COM server
components, and are referred to as Data Access Layer (DAL) objects).
3. Existing programs that access the indexed files are transformed to invoke
the DAL objects that manage the table sets. (As the DAL objects can be used
with any language that supports COM (including COBOL - both OO and standard)
they provide a useful separation between Business logic and Data layers and
can be used for future development as well as the existing applications. In
effect these objects are "future proof".)
Having achieved a stable base that is running existing applications against
the new RDB, the next step is to refactor existing COBOL code into objects
also.
This process is currently mainly manual, but we are developing tools to
automate aspects of it and hope eventually to make it "mostly automated"
Ancillary tools generate load modules that read the indexed files and write
the table sets, generate Host Variables for ESQL (DECLGEN), and a number of
other tasks that are tedious (and error prone...) when done manually.
Please visit http://primacomputing.co.nz and read my statement about how
this approach differs from a straight conversion using .NET COBOL.
For a graphic representation see
http://primacomputing.co.nz/COBOL21/mig.aspx
As for the topic of this thread, our base toolset comes at under half the
price of a .NET COBOL compiler. Furthermore we engage with and support
anyone using our tools, to ensure their migration is successful and as
"painless" as possible.
Pete.
--
"I used to write COBOL...now I can do anything."
Joel C. Ewing
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? If so, then that is a
ridiculously expensive choice and their cheapest solution would be to
immediately move to latest hardware that gives much more bang per buck
with lower environmental, energy, and maintenance costs. If these are
mission-critical applications, changing to other less-robust platforms
that are harder to manage for Disaster Recovery may be cheaper in the
short term than using modern mainframes, but could be a very unwise
long-term move.
There seems to be all sorts of confusion here about potentially distinct
choices for programming language, hardware choices, and Operating System
platforms. If there is one thing the last 30 years has taught, mass
conversion to the latest and greatest programming language or
programming paradigm of the day is not something to be undertaken
lightly and doesn't guarantee that one will end up with something that
is as efficient or costs any less to run and maintain than the original.
There are modern mainframe platforms that support COBOL quite well, and
modern COBOL has supported OO programming techniques and relational
databases for years.
I don't think Grace Hopper would have described herself as the inventor
of COBOL. She did invent the first programming language, Flow-Matic,
the concept of using English phrases in a programming language,
contributed significantly to the CODASYL committee that extended
Flow_Matic into what became COBOL, and was also the major player in the
adoption of COBOL by the military.
Pete Dashwood
I thought this was a very good response, Joel. I agree with what you said,
but I wanted to expand some of it so have done so below :-)
I think it is all relative. Basically, I agree with you on this. If you have
been running something for years and you can afford to do it, then it can't
be "very very expensive" (If it was you would have sought an alternative
years ago...)
In fact, if you are using older hardware and it is being supported and
maintained, it is probably cheaper to run now than it has ever been.
Certainly it's book value will be far less (if you own it) than it was when
you bought it.
>
> Are they really running these applications on "older mainframes" --
> stuff from water-cooled days or earlier? If so, then that is a
> ridiculously expensive choice and their cheapest solution would be to
> immediately move to latest hardware that gives much more bang per buck
Again, many people who are not in the mainframe world forget that mainframe
technology has also advanced and taken advantage of new hardware. I remember
a company I worked for paying half a million dollars for an IBM 360-30 with
32K of memory. Obviously, that same machine today could probably be
purchased in a garage sale for around $1000 if you could find one.The point
is that mainframe costs were exorbitant as long as there was little
alternative. Now there are alternatives and the mainframe vendors (mainly
IBM) have had to recognise this and respond.
> with lower environmental, energy, and maintenance costs. If these are
> mission-critical applications, changing to other less-robust platforms
> that are harder to manage for Disaster Recovery may be cheaper in the
> short term than using modern mainframes, but could be a very unwise
> long-term move.
I'm not sure that is a persuasive argument any more. For a long time
mainframe people were saying that the networks could not be as secure or
"robust" as a mainframe (with some justification), but I believe that is not
the case any longer. A corporae Intranet can be every bit as secure if
proper steps are taken to make it so, and redundant arrays at remote
locations mean that disaster recovery can be effected in moments, event if
the local nodes are completely wiped out. I think some of these are old
arguments that are now moot.
>
> There seems to be all sorts of confusion here about potentially
> distinct choices for programming language, hardware choices, and
> Operating System platforms. If there is one thing the last 30 years
> has taught, mass conversion to the latest and greatest programming
> language or programming paradigm of the day is not something to be
> undertaken lightly and doesn't guarantee that one will end up with
> something that is as efficient or costs any less to run and maintain
> than the original.
Certainly, platform migration based on fashion alone is a foolish move.
However, in the case of COBOL it isn't about fashion. Object Orientation has
been with us for a long time now and it isn't going away. It underpins
computing and IT in such a pervasive way that it simply cannot be ignored if
you need anything more than the simplest kinds of batch processing. For
existing COBOL functions to be able to be leveraged into the modern world
and interact with other packages and applications, COBOL has to put on an
Object mantle. Traditionally, there haven't been the skills available to do
this (the majority of "COBOL programmers" know COBOL and understand
procedural processing very well; it is not easy to make the transition to a
new paradigm like OO and they find it difficult. I know this from personal
experience having made the necessary transition many years ago, and helped a
number of others to make it. Once you have done it, it is easy to forget
that you "sweated it" for a while. However, the benefits definitely make it
worth the effort.), and there hasn't been perception of the need to do it.
It is only in the past decade or so, as the rest of the world has shown it
can produce applications cheaply and easily that leave COBOL gasping, that
corporate IT departments have had to sit up and take notice.
Now there is a situation where most corporations are voting with their feet
and looking for ways to get out of COBOL. This is what has largely led to
the "bad reputation" COBOL is perceived to have, and has led in turn to
Universities dropping it. COBOL is mostly still taught in a cursory fashion
as part of a "History of Computing" module. (They have to respond to the
needs of industry and industry needs people who understand objects and
layers.)
The problem with this is that there is a HUGE existing investment in COBOL
and nobody wants to simply write this off, even if that were possible. The
last decade has seen increasing efforts to address this with packages and
platform migrations and there have been some disasters. (There have also
been some success stories, but we don't really tend to hear about those
except in a marketing context, and most people are sceptical of anything
they hear in a marketing context... :-))
If someone comes along with a "solution" that says: "Don't worry, it's OK.
You can do what you've always done and keep on writing procedural code, but
now you can move it off your "very, very expensive" platform", you can
hardly blame people for embracing it. IT can report that they are now
running on a modern network, nobody needs to be retrained, and the status
quo remains intact, which makes everybody feel comfortable... until Reality
bites and they find that new packages with the functionality they require
can't work with their monolithic procedural code, their existing code is
using network resources at an alarming rate and the cost savings they were
promised don't eventuate because they are continually upgrading and
extending the network to accommodate their converted legacy, and they are
unable to enjoy newer features and facilities in their environment because
COBOL doesn't support it yet.
(After a while, the tech people get tired of forever playing "catch up" in
OO COBOL and simply move to Java, C# or VB.NET, biting the bullet on
retraining because they are now motivated to expand their skill sets. This,
of course, is what they should have done in the first place...)
The truth is that if you want to live in Rome, you have to act like a Roman.
(Otherwise you are consigned to the ghetto of expats and can never enjoy the
full benefits of Roman citizenship.). If COBOL is to succed in an OO world
it needs to be open (DB rather than flat files) and it needs to be Objects
and Layers.
That is why I have ensured that my company, at least, uses this approach. It
doesn't matter how you cut it, there is expense in moving off COBOL.(of
course, there may be even more expense in trying to retain it). You can
invest that expense in a planned long term direction to bring the essential
parts of your legacy into the modern world, or you can use it to simply buy
time and prolong the staus quo.
>There are modern mainframe platforms that support
> COBOL quite well, and modern COBOL has supported OO programming
> techniques and relational databases for years.
Yes, it has, Joel. Unfortunatey the COBOL community never really embraced
it, and, to be fair, it is only becoming gradually apparent to many, why
they need to.
>
> I don't think Grace Hopper would have described herself as the
> inventor of COBOL. She did invent the first programming language,
> Flow-Matic, the concept of using English phrases in a programming
> language, contributed significantly to the CODASYL committee that
> extended Flow_Matic into what became COBOL, and was also the major
> player in the adoption of COBOL by the military.
And that was all over 50 years ago. Kudos to her, but it isn't relevant to
solving IT problems in present time. The world has moved on.
Objects and Layers.
SkippyPB
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. So what if
the language is over 50 years old. It has, in recent years, been
upgraded and enhanced not only by IBM but other companies as well. 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.
Regards,
--
////
(o o)
-oOO--(_)--OOo-
There are three kinds of men. The ones that learn by reading. The few
who learn by observation. The rest of them have to pee on the electric fence
for themselves.
--Will Rogers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
Pete Dashwood
> 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.
docd...@panix.com
Joel C. Ewing <jREMOVEc...@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
docd...@panix.com
Pete Dashwood <dash...@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
Howard Brazee
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
Howard Brazee
>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.
SkippyPB
wrote:
>On Mon, 24 May 2010 13:34:14 +0000 (UTC), docd...@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? Where is the
control? It's not there. Business rules change often which is
probably why in 20 years OO hasn't caught on because it is just not
practical. You cannot expect the compiler manufacturer to supply
these "libraries" as part of the compiler.
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.
Regards,
--
////
(o o)
-oOO--(_)--OOo-
"It's not getting any smarter out there, people. You have to come to
terms with stupidity and make it work for you."
-- Frank Zappa
docd...@panix.com
Howard Brazee <how...@brazee.net> wrote:
>On Mon, 24 May 2010 13:34:14 +0000 (UTC), docd...@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.
Seems like there's a need to trot this one out every few years since it
was originally posted nigh a decade-and-a-half back... relating incidents
I read about in the mid-1980s, nigh two-and-a-half decades back. From
<http://groups.google.com/group/comp.lang.cobol/msg/6c29c3f3dc17173c?hl=en&lr=&ie=UTF-8>
--begin quoted text:
Heresy! It is a Well-Known Fact that if you give someone training they
will immediately jump ship to a higher-paying company because said company
is foolish enough to think that a person, trained, is more valuable than a
person, untrained... don't they know that Gratitude Is Enough?
> [snippage]
> The result is new and revised programs being written in the style and spirit of
> COBOL 74, or even COBOL '68.
Now, repeat after me: 'The responsibility for the allocation,
co-ordination and motivation of personnel and resources towards the
accomplishment of a stated Executive goal is that of Management.' Repeat
again.
Let's look at it another way... assume that an organisation has invested a
great deal of money in the upgrading of the physical plant. If sufficient
investment has been made then it is likely that serious consideration will
be given to upgrading the security system (new locks, etc.) to prevent
these improvement from 'walking off'. Also consider the common term of
'golden handcuffs', a recognised metaphor for increasing salary/benefits
to prevent human capital from *physically* walking away. Now, consider
the investment of money in humans to upgrade skills in order to make them
more valuable to the company. Consider how many times you have seen a
corporate policy stating that an increase in salary/benefits accompanies
the successful completion of such an upgrade (courses).
Years ago the Wall Street Journal did a story on one of the major NY
houses... I think it was Morgan Stanley or Morgan Guaranty or the like.
They hired *only* the 'unhireable'... kids with BAs in Library Science,
Art History, etc... they put these kids through two years of hell, 60 - 70
hr weeks, and turned them into *crackerjack* programmers... and then saw
said kids being hired away by the competition at double or triple the
salary. When asked why a raise did not accompany the completion of the
course the HR representative replied 'Oh, we cannot do that... all the
money has been taken up by training.' (compare this with 'Oh, we cannot
upgrade the door-locks... all the money went into oil-paintings to hang on
the walls.')
After a few years of seeing themselves serve as Wall Street's unofficial
programming school the company finally 'wised up'... and cancelled the
program entirely.
--end quoted text
>
>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.
It is one thing to learn a computer programming at home, Mr Brazee... and
quite another to learn the various skills and disciplines necessary to
make sure that various chunks of code are not stomping all over each other
and creating Bad Data. Of course 'the database' now takes care of all
such matters but having the skills necessary to analyse system/transaction
flow to a point where a READ WITH LOCK does what it should, rather than
hang up a system to a point where it needs to be re-IPL'd, is not
something usually found in a '... For Dummies' book.
>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.
I believe the latest trend in such circles are 'consolation bonuses', Mr
Brazee, where Corner-Office Idiots award each other large sums *not*
because their companies did well... but because the companies, while doing
badly, did not do *as badly* as their competitors. I've never heard of
such remuneration being bestowed on a cubicle-dweller.
DD
Howard Brazee
<swie...@Nospam.neo.rr.com> wrote:
>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? Where is the
>control? It's not there. Business rules change often which is
>probably why in 20 years OO hasn't caught on because it is just not
>practical. You cannot expect the compiler manufacturer to supply
>these "libraries" as part of the compiler.
The ideal seems to be to separate business rules out from the I/O as
much as possible, often putting them in with the data in a database.
When you do that, it doesn't matter much whether the person writing
the portal understands the business.
Pete Dashwood
> In article <85t3c3...@mid.individual.net>,
> Pete Dashwood <dash...@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.
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. However, this is a subjective judgement
based on a limted sample so it is probably fair to exclude it from this
argument. Let's say COBOL costs the same to maintain as anything else. It
still loses on purchase and development costs.
>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? :-)
> 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.
This is where the methodology used in the particular shop has a bearing
also. If the general requirements are pretty much established and the
company's core business is not changing then everything is fine. But many
companies are in fiercely competitive markets which are dynamic and they
need to be responsive to opportunities, before their competitors are.
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.
"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.
>
> 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...). 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.
> 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.)
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?
Someone is charged with getting the best deal possible for the company. This
person finds that COBOL development and maintenance is NOT a good deal (even
when stacked up against the profit the company is making, and the fact that,
for the most part, the COBOL applications are running well) and the IT
department is costing more than other operational areas of the company. (I
am thinking here of an Australian insurance company who, when faced with an
annual IT bill of around 24 million, simply closed it down, sold it off then
leased it back for 8 million. They never worried about it when times were
good, but when floods and drought ravaged Queensland and they were forced to
pay out millions, it focused their attention...). Said person will look for
another solution. Modern languages and approaches, when subjected to CBA and
ROI analysis come out looking much better than COBOL, so COBOL has to go.
"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.
Seems to me that is a reasonable and expected response. To do anything less
would be a dereliction of duty.
It isn't ONLY about cost savings (although that is certainly the major
factor).
The fact is that COBOL is no longer the "only game in town" and hasn't been
for a couple of decades. The days when the company's operations and
administration all centred on the central mainframe, and that processor
necessarily processed EVERYTHING, are over. Departments have people in them
who are computer savvy (many have degrees in computing) and they are quite
capable of doing their own thing (even doing it very well). [I worked in one
UK company where there were 3 times as many people with IT related degrees
OUTSIDE the IT department than there were such people INSIDE it. They were
smart users and it was very hard for IT to control them and tie down the
loose cannons that were running around. Eventually (after many lunches with
middle managers, listening and taking on board their reasons for not wanting
to adhere to IT policy) we worked out a mutually beneficial policy that
suited everyone. The secret is not for IT to try and control the data
resource, but to make sure that it is coherent, accessible, and contains
core information requirements. Most reasonable people (within and outside
the IT department can recognise the necessity for this) and work willingly
towards it. There should be no problem with departments implementing their
own localised "IT systems" as long as audit trails are kept and core
business requirements are posted.]
So, in addition to your point about managers wanting to save money, there is
the fact that the overall company is more computer savvy than it was 20
years ago, new people are joining who are not only computer literate, but
are fluent in the techniques of networks, objects, and layers, and they see
COBOL (and other non-OO languages) as a quaint old-fashioned remnant of the
history of computing, not as part of its present.
It is simply not possible to get the whole company to learn COBOL, and there
are political objections to having to go cap in hand to IT whenever you want
a new report, especially when you can generate it yourself from a local
spreadsheet or database.
All of these factors are contributing to the impetus to move away from
Pete Dashwood
> On Mon, 24 May 2010 13:34:14 +0000 (UTC), docd...@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.
This (as is usual from you, Howard) is just eminently sensible. One reason
for the economic success of Japan is exactly such long term strategic views.
Failure to train workers because they will go to the competition, results
from really short-sighted management. It has been with us for years and it
is shameful. Employee loyalty is earned by treating people as "valuable" and
recognising you need to pay more for trained people than untrained ones. The
companies that actually do this (sadly, still a minority) are better places
to work, and enjoy higher morale and a better bottom line than their
competitors who still treat people like cannon fodder.
I've worked in both kinds of place and seen it at first hand. Places where
people enjoy going to work are simply more productive than places where they
don't. Corporate cultures that value ideas, thoughts, and discussion and
make it safe for all employees to say what they think, even if it doesn't
match the "party line", are stronger and better places to work and they
attract the brightest people.
The top management schools are teaching this, successful companies are
living it, so it is to be hoped that the rising generation of managers will
embrace it and we will see better companies with more enlightened management
in the years ahead.
Pete Dashwood
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,
docd...@panix.com
Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>docd...@panix.com wrote:
>> In article <85t3c3...@mid.individual.net>,
>> Pete Dashwood <dash...@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
Howard Brazee
<dash...@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.
Howard Brazee
>*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".
docd...@panix.com
Howard Brazee <how...@brazee.net> wrote:
>On Tue, 25 May 2010 13:59:58 +0000 (UTC), docd...@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
Pete Dashwood
> On Wed, 26 May 2010 01:33:25 +1200, "Pete Dashwood"
> <dash...@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.
HeyBub
>
> 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
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...
docd...@panix.com
HeyBub <hey...@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
Pete Dashwood
> 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...
Howard Brazee
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.
Howard Brazee
<dash...@removethis.enternet.co.nz> wrote:
>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?
Possibly not. What are the laws and expectations for digging in
that man's property? Some places he doesn't have any rights to what
is below his property, other places he has full rights. If someone
is leasing a right of way for a power line, he has responsibility.
...
>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.
Too bad kids don't learn to use slide rules. Teaching them to
estimate and make sanity checks is even more useful than understanding
proportion and significant digits.
HeyBub
>
> 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.
>
My point exactly. EasyTrieve allowed the unwashed to place a value
of -17,000 feet in a database where the standard was the reverse. The
original data edit program, designed by programmers (modest bow here), would
laugh at such a value, but EasyTrieve (or similar) in the hands of a cretin
would not.
My point was that making databases available to the masses through
easy-to-use tools invites ruination, islands disappearing, mothers smelling
like elderberries, and the earth turning into one giant scab.
Howard Brazee
wrote:
>My point exactly. EasyTrieve allowed the unwashed to place a value
>of -17,000 feet in a database where the standard was the reverse. The
>original data edit program, designed by programmers (modest bow here), would
>laugh at such a value, but EasyTrieve (or similar) in the hands of a cretin
>would not.
We are moving from an IDMS system that included some flat files and
users who wrote some EasyTrieve to a PeopleSoft/Oracle system with
tools such as Cognos (against the data warehouse), and SQLQuery.
Getting rid of the mainframe is supposed to pay for most of this -
getting rid of application programmers is what will provide the bigger
cost savings.
It reminds me of when they invented CoBOL and wouldn't need
programmers anymore.
They really, really need to know the data, and really, really need to
check their results, as it is very easy to pull out of the data
warehouse data that look pretty good and assume it tells what we need.
I don't see that this issue was nearly as important with EasyTrieve
when it pulled more simple data, from the database or from frozen
files.
>My point was that making databases available to the masses through
>easy-to-use tools invites ruination, islands disappearing, mothers smelling
>like elderberries, and the earth turning into one giant scab.
But that's the next guy's problem.
Pete Dashwood
My point would be that that can only happen if you let it. Making databases
available is not the problem. Giving access to data is fine as long as you
ensure that the people given the access are answerable for what they do,
that you KNOW what they did (audit), and that you (and they...)can UNDO what
they did as quickly and easily as they did it.
It is when access is given WITHOUT these kinds of checks and balances that
wickets get decidedly sticky. The same applies to ANY data repository,
whether it is an ISAM/VSAM file only accessible by an application, a
Relational DB accessible by SQL, or a Content Addressable store accessible
from a number of cores simultaneously. The technology is irrelevant; it is
how it is managed that decides whether it is safe or not.
So often in this forum I have seen people posting with the idea that an
indexed file accessed from COBOL is somehow "safer" than a Relational
Database accessed from COBOL, because the RDB can be accessed by "anybody"
who knows SQL and has access. It is nonsense. ("Anybody" could also run the
COBOL app. that accesses the indexed file, or write their own app to do
whatever they liked...) There is no substitute for proper management and
stewardship of the data resource. Locking it up just makes it less useful.
Pete.
Pete Dashwood
> On Mon, 7 Jun 2010 10:28:02 -0500, "HeyBub" <hey...@NOSPAMgmail.com>
> wrote:
>
>> My point exactly. EasyTrieve allowed the unwashed to place a value
>> of -17,000 feet in a database where the standard was the reverse. The
>> original data edit program, designed by programmers (modest bow
>> here), would laugh at such a value, but EasyTrieve (or similar) in
>> the hands of a cretin would not.
>
> We are moving from an IDMS system that included some flat files and
> users who wrote some EasyTrieve to a PeopleSoft/Oracle system with
> tools such as Cognos (against the data warehouse), and SQLQuery.
> Getting rid of the mainframe is supposed to pay for most of this -
> getting rid of application programmers is what will provide the bigger
> cost savings.
>
> It reminds me of when they invented CoBOL and wouldn't need
> programmers anymore.
Yes, when you have been part of it for years and know what is going on, it
is hard to accept a lesser solution. But in 5 years time, you'll be off
playing golf and the new crew will be familiar with Cognos and Oracle. And
some of the projected cost savings may then actually eventuate... :-)
>
> They really, really need to know the data, and really, really need to
> check their results, as it is very easy to pull out of the data
> warehouse data that look pretty good and assume it tells what we need.
Then BI should be reviewing the warehouse and refining it. User interface
should make it easy to flag ambiguous data for special checking.
I learned this lesson in my early twenties when it became apparent to me
that Management would believe anything written on green lineflo.
I deliberately arranged for some outrageous figures to appear in a
Management report, and sure enough, all Hell broke loose. I was carpeted and
warned that any similar behaviour would result in loss of job. My defence,
(to the CEO) was that if the people getting the reports knew their stuff
they should have instantly realised it was a joke. (He did, and smiled when
they first presented these figures to him). I kept my job and only did one
or two more pranks before I moved on, and then grew up and lost my sense of
humour... :-)
Your point elsewhere is well taken that it is important for people to learn
to make sanity checks and estimations that "keep data honest".
>
> I don't see that this issue was nearly as important with EasyTrieve
> when it pulled more simple data, from the database or from frozen
> files.
I think it was just as important then as it is now, Howard. The difference
is in the quality and quantity of data that is available through the
warehouse, and the fact that more data available means more care is needed
in interpreting it. There are more subtleties now than was previously the
case, and that can be a two-edged sword.
>
>> My point was that making databases available to the masses through
>> easy-to-use tools invites ruination, islands disappearing, mothers
>> smelling like elderberries, and the earth turning into one giant
>> scab.
>
> But that's the next guy's problem.
I contend that it shouldn't be a problem at all, if data resources are
administered and managed properly.
docd...@panix.com
Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
[snip]
>I kept my job and only did one
>or two more pranks before I moved on, and then grew up and lost my sense of
>humour... :-)
From http://en.wikisource.org/wiki/Beyond_Good_and_Evil/Chapter_IV :
--begin quoted text:
The maturity of man--that means, to have reacquired the seriousness that
one had as a child at play.
--end quoted text
DD
Howard Brazee
<dash...@removethis.enternet.co.nz> wrote:
>My point would be that that can only happen if you let it. Making databases
>available is not the problem. Giving access to data is fine as long as you
>ensure that the people given the access are answerable for what they do,
>that you KNOW what they did (audit), and that you (and they...)can UNDO what
>they did as quickly and easily as they did it.
Who is the "you" above who has the power to do the above? Someone
on this forum?
Pete Dashwood
> On Tue, 8 Jun 2010 13:24:45 +1200, "Pete Dashwood"
> <dash...@removethis.enternet.co.nz> wrote:
>
>> My point would be that that can only happen if you let it. Making
>> databases available is not the problem. Giving access to data is
>> fine as long as you ensure that the people given the access are
>> answerable for what they do, that you KNOW what they did (audit),
>> and that you (and they...)can UNDO what they did as quickly and
>> easily as they did it.
>
> Who is the "you" above who has the power to do the above? Someone
> on this forum?
Try substituting "one" for "who" if you feel more comfortable (it makes me
uncomfortable to use the impersonal pronoun). :-)
Yes, I have the power to do the above in my company. Sometimes that power
will be vested in a committee, sometimes in an individual, but ultimately,
someone has to be responsible.
If an IT professional realises that no-one is responsible for these things
in the organization where they work, then it would be unprofessional not to
point this out and get it addressed...
Sometimes, DBAs (good ones, at least...), absorb much of this into their
other duties.