Re: Should COBOL be lockedUP for good?...
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx>
- Date: Wed, 18 May 2005 18:16:40 +1200
Hi Kellie,
I read the whole of this thread and all the replies.
You are receiving some EXCELLENT advice, getting it for free from people who
have spent years in the real world, and, it seems to me you may be too
dismissive of the points being raised.
As you know, I am supportive of your "independent thought" stance and I
wouldn't want to see that stifled, but you do need to test some of your
ideas before you can really make claims about them.
You are allowing your emotional attachment to COBOL to blind you here. (It
isn't wise to do that with ANY language; it is just computer programming,
not life and death or a lifetime love affair...)
Both Richard and Bill (and some others) have tried to explain their
reservations to you and tried to point out some of the things you need to be
aware of. But it certainly looks as though your mind is already closed. That
is OK (as part of a learning curve; it is NEVER OK to close your mind,
really... :-)), but then, you can forgive Richard for asking why you asked
the question if you already have all the answers...
You may think it is fine to use the COBOL file system, but it isn't. It
isn't just about relative efficiency, it is about other software having
access to the data. Many years ago, right here in this forum, when I
suggested that the COBOL file system should be replaced by RDBs, wherever
possible, there were howls of indignation and I was seen as an anti-COBOL
idiot. (I'm actually neither...but people get emotional about computer
programming.) Today, people see there are real benefits in letting an
established system do the work for you...
The fact is that one of the nails in COBOL's coffin has been the file
system. People don't want to have write a program (or have one written for
them), every time access to corporate data is required. It was OK 40 years
ago when there was no other option; it ISN'T OK today. It is ironic that the
only thing actually "wrong" with the file system is that it is closed. As a
system for data management it is excellent. But so are modern databases, and
they have the advantage of handling locks, rollback, checkpoints, and all of
the facilities you realised you needed (I give you full credit for that...)
embedded in them and fully debugged and operational.
Richard in particular has explained at some length some of the
considerations with multiprocessing and multitasking and it isn't ALL to be
found on MSDN (although, I agree that is an excellent resource, and use it
myself).
Here's some general things to consider, and I wish you every success with
your system...
1. Don't let the technology you know and understand drive your requirements.
Sometimes you need to put aside your technical knowledge and try to
understand what is needed in plain English from a user point of view. It is
all too easy to think "requirement for random access. OK that means ISAM (or
VSAM or BTRIEVE or whatever your environment supports).". The tail does not
wag the dog. Get the WHOLE requirement then start looking at what technology
is most applicable. Do the homework and don't just use COBOL as a "one size
fits all" tool. That is one step away from "Everything I want to do, I can
do in COBOL". When I hear people say that, it immediately tells me they are
limited in their imagination and/or in what they want to do... The BEST
tools for the job. Sometimes it is COBOL; sometimes it isn't...
2. Accept that there is a knowledge base here that is worth considering.
That's why you come here, right? There is nothing wrong with questioning,
but maybe run a few tests, rather than rely on what you think OUGHT to be
the case. (I did this recently when you suggested some alternate forms of
input and validation... I'm sure you remember. The exercise was enlightening
to me and there were a number of useful spin-offs. Not to mention that a
number of people provided useful considerations and input. If, after 40
years of programming, I am not above employing an empirical approach when
appropriate, don't you think you could too? :-)
The sad fact is that what you read in the manuals (and on MSDN) is not
ALWAYS true... (I know...shock! horror!). When people with the experience
base of Richard Plinston and Bill Klein are giving you a heads up, it is
polite to at least listen...and wise to consider what they say (I certainly
do...). (If you think you are not getting a fair hearing or being
understood, then do some experiments and repost.)
3. I believe you have what it takes to be a really successful problem
solver. BUT, you lack experience. Accept that. It isn't a fault. Be thankful
there are people here who will share THEIR experience with you (and for
FREE!), just as you will in years to come...
Finally, I have deliberately refrained from answering your questions, even
though I have some opinions about the solutions. This is a time when you
really must evaluate the answers for yourself, and consider all the opinions
you have had.
Best,
Pete.
<snip>
.
- Prev by Date: screenio and web development?
- Next by Date: Re: screenio and web development?
- Previous by thread: Re: Should COBOL be lockedUP for good?...
- Next by thread: Re: Should COBOL be lockedUP for good?...
- Index(es):
Relevant Pages
|
