Home > Archive > Cobol > September 2007 > Basement tinkerers and inventors
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Basement tinkerers and inventors
|
|
| Graham Hobbs 2007-08-29, 6:55 pm |
| Odd notes I made about BT/I's:
- am just exploring any value/interest to a group/groups for BT/I's
(basement tinkerers and inventors) or is there a place already for
these people; are there many of us, what are we doing?
- BT/I by implication means PC software development; IBM Main, COBOL,
etc seem mostly geared to the high end
- is a BT/I scope too wide e.g. projects in java, cobol, web, VB,
mainframe, non-mainframe, drivers ... ad infinitum?
- what would be a reasonable sub titles?
- my personal interests would be groups ltitled 'BT/I Websphere
Developer for z/OS' and 'BT/I Cobol, CICS, VSAM, DB2'
- five years ago I wrote letters to IBM, Microfocus, Microsoft and
McKinney about something I was developing; there are at least three
black holes on this planet
- via such groups I would be interested in listening to people with
similiar interests, financial constraints, tiny company size,
technical problems, etc.
- is all this naive, impractical, not needed?
Thanks
Graham Hobbs
--
Posted via a free Usenet account from http://www.teranews.com
| |
| Pete Dashwood 2007-08-29, 6:55 pm |
|
"Graham Hobbs" <ghobbs@cdpwise.net> wrote in message
news:sacbd317pn8beqpj24k6artmc2736cb1f6@
4ax.com...
> Odd notes I made about BT/I's:
>
> - am just exploring any value/interest to a group/groups for BT/I's
> (basement tinkerers and inventors) or is there a place already for
> these people; are there many of us, what are we doing?
>
> - BT/I by implication means PC software development; IBM Main, COBOL,
> etc seem mostly geared to the high end
>
> - is a BT/I scope too wide e.g. projects in java, cobol, web, VB,
> mainframe, non-mainframe, drivers ... ad infinitum?
>
> - what would be a reasonable sub titles?
>
> - my personal interests would be groups ltitled 'BT/I Websphere
> Developer for z/OS' and 'BT/I Cobol, CICS, VSAM, DB2'
>
> - five years ago I wrote letters to IBM, Microfocus, Microsoft and
> McKinney about something I was developing; there are at least three
> black holes on this planet
>
> - via such groups I would be interested in listening to people with
> similiar interests, financial constraints, tiny company size,
> technical problems, etc.
>
> - is all this naive, impractical, not needed?
>
> Thanks
> Graham Hobbs
>
I think it's a very good idea, Graham, and I'll certainly support such a
group. I spend a lot of my time (when not actually working or doing revenue
generating work) doing exactly what you describe. I never thought of it as
"tinkering" but I have certainly been glad I did the work I did later, when
the skills acquired have paid off.
Perhaps a better name for the group could be agreed?
"Tinkering" sounds pretty amateurish and some of what people produce in
their spare time is far from that. On the other hand you might not want it
to be too serious so "tinkering" might fit. You should be aware that in
certain cultures, association with Tinkers is not a desirable attribute,
even to this day... :-)
Anyway, whatever you decide to call it, if you start such a group, I'll
definitely contribute and support it.
Pete.
--
"I used to write COBOL...now I can do anything."
>
> --
> Posted via a free Usenet account from http://www.teranews.com
>
| |
| Graham Hobbs 2007-08-31, 6:58 pm |
| Peter,
Massive response eh?
Graham
On Thu, 30 Aug 2007 11:35:39 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>
>
>"Graham Hobbs" <ghobbs@cdpwise.net> wrote in message
> news:sacbd317pn8beqpj24k6artmc2736cb1f6@
4ax.com...
>
>I think it's a very good idea, Graham, and I'll certainly support such a
>group. I spend a lot of my time (when not actually working or doing revenue
>generating work) doing exactly what you describe. I never thought of it as
>"tinkering" but I have certainly been glad I did the work I did later, when
>the skills acquired have paid off.
>
>Perhaps a better name for the group could be agreed?
>
>"Tinkering" sounds pretty amateurish and some of what people produce in
>their spare time is far from that. On the other hand you might not want it
>to be too serious so "tinkering" might fit. You should be aware that in
>certain cultures, association with Tinkers is not a desirable attribute,
>even to this day... :-)
>
>Anyway, whatever you decide to call it, if you start such a group, I'll
>definitely contribute and support it.
>
>Pete.
--
Posted via a free Usenet account from http://www.teranews.com
| |
| Pete Dashwood 2007-08-31, 9:57 pm |
|
"Graham Hobbs" <ghobbs@cdpwise.net> wrote in message
news:kf3hd3p50jgkp6dtg0sbhv6cmqlftf2r1o@
4ax.com...
> Peter,
> Massive response eh?
> Graham
>
It's CLC... :-)
At least you got your question ("...are there many of us, what are we
doing?") answered :-)
PC development is the "poor relation" in this newsgroup. The majority of
COBOLlers are working on mainframes.
The ones using COBOL on their PCs are still using the same approaches they
do at "work" (mainframe), that's why we see requests here for help with
SCREEN SECTION and Compiler options and command lines.
The people who are REALLY into PC development are moving away from COBOL
because there are much better options available now for PC development.
If you're working daily in a world of Linux and Ruby or PHP or C# and
Windows, you really only have a passing interest in COBOL. (or none at
all...)
(I come here because I cherish this news group as a last bastion of free
speech (if they ever start censoring or moderating it, I'm out of here...),
and because over the years, I have come to "know" many of the people in it
and recognise that, despite the idiosyncrasies :-), there are some very
bright people here who are worth exchanging ideas with. Notwithstanding the
attention to minutiae and the pedantry over things COBOL, there are often
amusing and entertaining posts here. But the off topic posts are much more
interesting than the on topic ones, for the most part, in my opinion.)
Most people here have never seen or used an Object Browser, have no idea how
to leverage components that are already present on their PCs into their own
applications, wouldn't know what scripting is or why you might want to use
it (yet they are expert at Sanskrit JCL:-)), and are not inclined to learn
Object Orientation (which is the basis for PC development).
They simply aren't PC developers.
While I realise you find the response (or, more correctly, lack of it...)
disappointing, it is really only to be expected.
I'm optimistic that there must be some Usenet forums for PC Tinkerers
and/or Inventors, and if there aren't, then maybe there should be... :-)
I'll happily discuss what I'm considering as projects for PC development and
how I intend going about it, by personal mail if you want to exchange ideas
with someone.
Pete.
| |
| Robert 2007-09-01, 3:58 am |
| On Sat, 1 Sep 2007 12:47:41 +1200, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:
>The people who are REALLY into PC development are moving away from COBOL
>because there are much better options available now for PC development.
Prgramming is programming. The operating system doesn't change the rules of logic, Boolean
algebra nor good design. You are referring to a cultural change, not so much a technical
change.
>If you're working daily in a world of Linux and Ruby or PHP or C# and
>Windows, you really only have a passing interest in COBOL. (or none at
>all...)
I worked in shop where we did all Cobol development and testing on Windows, then deployed
on Linux without ever testing there. We could as well have deployed on mainframe. Java
people are comfortable with the concept.
>Most people here have never seen or used an Object Browser,
The Web Express workbench has one.
have no idea how
>to leverage components that are already present on their PCs into their own
>applications
Web Express makes it easy to use OLE objects.
>, wouldn't know what scripting is or why you might want to use
>it (yet they are expert at Sanskrit JCL:-)), and are not inclined to learn
>Object Orientation (which is the basis for PC development).
OO is not the basis for PC development, it's the basis for modern programming. Unix people
are as much into OO as PC people. Because it wasn't invented in 1974, mainframers adopt a
wait and see attitude. They hope this too will pass.
>They simply aren't PC developers.
They simply aren't Real Programmers.
| |
| Pete Dashwood 2007-09-01, 3:58 am |
|
"Robert" <no@e.mail> wrote in message
news:q5lhd3phrd6b1sd4cqedl8c1qqf5e2s9t9@
4ax.com...
> On Sat, 1 Sep 2007 12:47:41 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
>
>
> Prgramming is programming. The operating system doesn't change the rules
> of logic, Boolean
> algebra nor good design. You are referring to a cultural change, not so
> much a technical
> change.
Did I say it was technical... :-)?
In fact, I see it as a complete paradigm shift involving technical,
cultural, and economic change.
>
>
> I worked in shop where we did all Cobol development and testing on
> Windows, then deployed
> on Linux without ever testing there. We could as well have deployed on
> mainframe. Java
> people are comfortable with the concept.
>
Is that shop still running?
>
> The Web Express workbench has one.
> have no idea how
>
> Web Express makes it easy to use OLE objects.
>
>
> OO is not the basis for PC development, it's the basis for modern
> programming.
Yes it is, but you are wrong to say that that makes it "not the basis for PC
development". Perhaps your statement requires an "only" inserted after not?
>Unix people
> are as much into OO as PC people.
As far as I am concerned, Unix people ARE PC people. I use "Personal
Computer" pretty loosely. I klnow Unix is running on mainframes.
Because it wasn't invented in 1974, mainframers adopt a
> wait and see attitude. They hope this too will pass.
>
>
> They simply aren't Real Programmers.
Maybe.:-) The term "programmer" is taking on new meanings.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Robert Jones 2007-09-01, 6:58 pm |
| On Aug 29, 6:59 pm, Graham Hobbs <gho...@cdpwise.net> wrote:
> Odd notes I made about BT/I's:
>
> - am just exploring any value/interest to a group/groups for BT/I's
> (basement tinkerers and inventors) or is there a place already for
> these people; are there many of us, what are we doing?
>
> - BT/I by implication means PC software development; IBM Main, COBOL,
> etc seem mostly geared to the high end
>
> - is a BT/I scope too wide e.g. projects in java, cobol, web, VB,
> mainframe, non-mainframe, drivers ... ad infinitum?
>
> - what would be a reasonable sub titles?
>
> - my personal interests would be groups ltitled 'BT/I Websphere
> Developer for z/OS' and 'BT/I Cobol, CICS, VSAM, DB2'
>
> - five years ago I wrote letters to IBM, Microfocus, Microsoft and
> McKinney about something I was developing; there are at least three
> black holes on this planet
>
> - via such groups I would be interested in listening to people with
> similiar interests, financial constraints, tiny company size,
> technical problems, etc.
>
> - is all this naive, impractical, not needed?
>
> Thanks
> Graham Hobbs
>
> --
> Posted via a free Usenet account fromhttp://www.teranews.com
There's no harm asking, but I would have thought that much of the
computer side of Google Groups was relevant in such areas as
comp.lang.* alt.lang.* and bit.listserve.*. Many people interested in
the main frame side do make useful developments as a sideline, though
there isn't the mass market there as opposed to developing for PCs.
There is a website, whose name and address I forget, that provides a
forum or market exchange for people who wish to supply and obtain
programming services for specific specified tasks, not an IT Jobs
forum. I believe it also provides a means for payment for the
specific tasks too. I think this has come up in earlier discussions
in this group, but again I don't remember what the topic title was.
Good luck anyway
Robert
| |
| Alistair 2007-09-01, 6:58 pm |
|
Robert wrote:
>
> OO is not the basis for PC development, it's the basis for modern programming. Unix people
> are as much into OO as PC people. Because it wasn't invented in 1974, mainframers adopt a
> wait and see attitude. They hope this too will pass.
>
>
> They simply aren't Real Programmers.
So: the only real programmers program on PCs?
The only real programmers use Assembler (some would argue that they
patch their code in machine code).
| |
| Robert 2007-09-01, 6:59 pm |
| On Sat, 1 Sep 2007 15:39:57 +1200, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:
>"Robert" <no@e.mail> wrote in message
> news:q5lhd3phrd6b1sd4cqedl8c1qqf5e2s9t9@
4ax.com...
>
>Did I say it was technical... :-)?
>
>In fact, I see it as a complete paradigm shift involving technical,
>cultural, and economic change.
In the Good Old Days, before 1990, the most important design constraint was inadequate
hardware. Compensating for slow hardware caused bad design practices to be accepted as the
norm. When machines became fast enough, some people didn't get it, they continued solving
a problem that no longer existed. OO was an attempt to break that by simply changing the
word order of programming languages. The old languages were verb initial, MOVE A TO B; OO
languages are object initial, B:COPY(A). Picture language in two dimensions, with verbs on
one axis and nouns on the other, grammar being the intersection of the two. OO rotates the
tableau ninety degrees.
Is that enough of a change? Is it a change at all? Some will quickly point out that the
word order of assignment, B = A, used in languages other than Cobol has always been OVS.
There is not a big difference between natural languages that are verb initial, for example
Gaelic and Biblical Hebrew, compared to most languages, which are subject initial. Oddly,
there are no object initial natural languages, which explains why Jedi sounds
other-worldly.
Experimental linguists have discovered that verb initial languages are the most difficult
to learn because of "information loss" during parsing. For more on this see
www.nbu.bg/cogs/events/2002/gruening.pdf
At another level, OO can be seen as a packaging convention that puts all logic related to
a data element (datum) in one program. In the Good Old Days, when we wanted to know
everything about an element, we had to search hundreds of source programs. Now we're told
it's all in one collection of methods. Is it really? The methods read "update element to
the value passed" and "compare element to the object passed". Now we don't search hundreds
of programs for the element name, instead we search hundreds of programs for the method
name. Is this an improvement?
>Is that shop still running?
ESRX is the darling of Wall Street, for having the greatest long term growth. If you had
invested $1K in ESRX in 1992, your stock would be worth $60K today. By comparison, the
same investment in MSFT would be worth $15K, in IBM would be worth $3K.
We processed and stored 50M transactions per month using an anemic Unix box that cost
under $10K.
>
>As far as I am concerned, Unix people ARE PC people. I use "Personal
>Computer" pretty loosely. I klnow Unix is running on mainframes.
The computing landscape is no longer divided into two camps: mainframes and PCs (desktops
and laptops). On the contrary, those two are now on the sidelines. The main players are
'servers' running Big Unix and Big Windows. They are the core processors of most telephone
companies, airline reservations, credit cards, medical claims and other high volume
applications. Historically, 10K transactions per second was thought to be the limit for
the largest single computer. Now we have Unix boxes that routinely process 20-40K per
second. They do with 100-500 parallel processes, all doing the same thing. It's awesome to
watch, and even more of a rush knowing you wrote the code. :)
>Because it wasn't invented in 1974, mainframers adopt a
>
>Maybe.:-) The term "programmer" is taking on new meanings.
The word programmer is no longer used. We were engineers in the '90s, until real engineers
objected. Now we're developers. Those who couldn't make the cut are called testers and
production supporters.
| |
| Robert 2007-09-02, 3:55 am |
| On Sat, 01 Sep 2007 14:23:41 -0700, Alistair <alistair@ld50macca.demon.co.uk> wrote:
>
>Robert wrote:
>
>So: the only real programmers program on PCs?
>
>The only real programmers use Assembler (some would argue that they
>patch their code in machine code).
Assemblers are a crutch. Real programmers become one with the metal. They write whole
programs in microcode, execute them with a single machine instruction. You can't beat the
speed, but debugging is a XXXXX. You learn to get it right the first time.
| |
| tlmfru 2007-09-02, 6:56 pm |
|
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
news:5jrr5fF10sr7U1@mid.individual.net...
>
>
> Most people here have never seen or used an Object Browser, have no idea
how
> to leverage components that are already present on their PCs into their
own
> applications, wouldn't know what scripting is or why you might want to use
> it (yet they are expert at Sanskrit JCL:-)), and are not inclined to learn
> Object Orientation (which is the basis for PC development).
>
> They simply aren't PC developers.
>
> Pete.
>
>
One could point out that a great many developments that we all routinely use
every day in all aspects of our lives were developed in a "garage" (or other
un-equipped environment) using only the absolute minimum of tools. Mashing
up existing tools and components should be looked upon, I'd say, as an
adjunct to development, rather than development itself. I wouldn't be so
stubborn as to insist that one has to develop all the tools and functions
needed oneself - after all, I use somebody else's I/O system & screen
handler all the time - but I fall back on my saying: the easier it is to do
something, the easier it is to do it badly.
I'm working on a program to reformat documents such that all occurrences of
a word or phrase are listed, sentence by sentence, together. I'm actually
doing a treatise on roses and I find that the particular bits of text I want
to bring together are usually scattered all over the place. It rapidly gets
to be a pain to do it by hand. Anybody know of a program or function that
will do this?
PL
| |
| Robert Jones 2007-09-02, 6:56 pm |
| On Sep 1, 6:46 pm, Robert Jones <rjon...@hotmail.com> wrote:
> On Aug 29, 6:59 pm, Graham Hobbs <gho...@cdpwise.net> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> There's no harm asking, but I would have thought that much of the
> computer side of Google Groups was relevant in such areas as
> comp.lang.* alt.lang.* and bit.listserve.*. Many people interested in
> the main frame side do make useful developments as a sideline, though
> there isn't the mass market there as opposed to developing for PCs.
> There is a website, whose name and address I forget, that provides a
> forum or market exchange for people who wish to supply and obtain
> programming services for specific specified tasks, not an IT Jobs
> forum. I believe it also provides a means for payment for the
> specific tasks too. I think this has come up in earlier discussions
> in this group, but again I don't remember what the topic title was.
>
> Good luck anyway
>
> Robert
I found the link as follows
http://www.rentacoder.com/RentACode...?txtFromURL=AId
| |
| Pete Dashwood 2007-09-02, 9:55 pm |
|
"tlmfru" <lacey@mts.net> wrote in message
news:C7ECi.27807$Pv4.5233@newsfe19.lga...
>
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
> news:5jrr5fF10sr7U1@mid.individual.net...
> how
> own
>
> One could point out that a great many developments that we all routinely
> use
> every day in all aspects of our lives were developed in a "garage" (or
> other
> un-equipped environment) using only the absolute minimum of tools.
> Mashing
> up existing tools and components should be looked upon, I'd say, as an
> adjunct to development, rather than development itself. I wouldn't be so
> stubborn as to insist that one has to develop all the tools and functions
> needed oneself - after all, I use somebody else's I/O system & screen
> handler all the time - but I fall back on my saying: the easier it is to
> do
> something, the easier it is to do it badly.
>
> I'm working on a program to reformat documents such that all occurrences
> of
> a word or phrase are listed, sentence by sentence, together. I'm actually
> doing a treatise on roses and I find that the particular bits of text I
> want
> to bring together are usually scattered all over the place. It rapidly
> gets
> to be a pain to do it by hand. Anybody know of a program or function that
> will do this?
>
> PL
>
Have a look at a technique called "Keyword in Context" (KWIC) I think IBM
originally developed it for searching tape files, but it is also very
effective for processing documents.
I used it many years ago for something very similar to what you are
describing, and wrote a COBOL implementation of it. (I might still have a
copy of the source code on a machine somewhere...I never throw away anything
I wrote.)
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| tlmfru 2007-09-03, 6:55 pm |
|
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in
actually doing a treatise > > on roses and I find that the particular bits
of text I want to bring together are usually[color=darkred]
hand. Anybody know > > of a program or function that will do this?[color=darkred]
> Have a look at a technique called "Keyword in Context" (KWIC) I think IBM
> originally developed it for searching tape files, but it is also very
> effective for processing documents.
>
> I used it many years ago for something very similar to what you are
> describing, and wrote a COBOL implementation of it. (I might still have a
> copy of the source code on a machine somewhere...I never throw away
anything
> I wrote.)
>
> Pete.
Zounds! I have actually heard of that but only in the context of an IBM
product that we discredited as much as possible - I was working for Univac
at the time and nothing IBM did was above contempt! So I never looked into
it. Thanks for the tip.
But, damnation, if it does what I want, it means that somebody thought of
it, a long time ago, and that there probably isn't anything new in the world
of programming! If so, you may be right in your contention that everything
can be done using objects ...
Incidentally: harking back to our slight dispute on "never doing
maintenance": I once wrote an application to take data from time-clocks &
report on the results. After about 18 months, some of the clocks began to
duplicate the occasional raw data record. My solution was to compare the
record to the previous one & if they were the same to skip - this worked
because the clocks were polled one at a time and the employee/time/date
combination was unique. Whether or not they still do it I neither know nor
care! With your philosophy, how would you have handled this?
Cheers
PL
| |
| Pete Dashwood 2007-09-03, 9:55 pm |
|
"tlmfru" <lacey@mts.net> wrote in message
news:K_WCi.24945$Zk5.1860@newsfe23.lga...
>
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in
> actually doing a treatise > > on roses and I find that the particular bits
> of text I want to bring together are usually
> hand. Anybody know > > of a program or function that will do this?
> anything
>
> Zounds! I have actually heard of that but only in the context of an IBM
> product that we discredited as much as possible - I was working for Univac
> at the time and nothing IBM did was above contempt! So I never looked
> into
> it. Thanks for the tip.
>
> But, damnation, if it does what I want, it means that somebody thought of
> it, a long time ago, and that there probably isn't anything new in the
> world
> of programming! If so, you may be right in your contention that
> everything
> can be done using objects ...
>
> Incidentally: harking back to our slight dispute on "never doing
> maintenance": I once wrote an application to take data from time-clocks &
> report on the results. After about 18 months, some of the clocks began to
> duplicate the occasional raw data record. My solution was to compare the
> record to the previous one & if they were the same to skip - this worked
> because the clocks were polled one at a time and the employee/time/date
> combination was unique. Whether or not they still do it I neither know
> nor
> care! With your philosophy, how would you have handled this?
>
My philosophy, huh? :-)
(Pops in ping-pong ball eyes, puts on saffron robe and adopts the lotus
position...)
Ah, Glasshopper, truly it is important to be still, as the stones do not
hear the babbling brook.
Listen, in the silence, to the sound of the time clock object collecting the
clock-ins. That is what it does.
See the report program, feeding on the stream of data from the clock-in
object. That is what it does.
But hark! Is that the sound of choking from the report program, what is it
spitting out? A duplicate record!
Perhaps age has worn away the reliabilty of the clock-in device, even as the
wind and rain tear down the mountains over time.
We could change the report program to ignore the surplus data, but would you
ask the leopard to change its spots because it has indigestion?
We could change the clock-in object to ignore the surplus data, but does the
worm become a snake?
We could have the clock-in devices checked and regulated and restore them,
even as the Spring restores the leaves of the mighty banyan.
This is the best solution, for it requires no software intervention, and
heals the deterioration in our devices.
But perhaps the clock devices are no longer supported, or the compay that
sold them to us has ceased to trade..
Then we must do what we can in software.
Even as the mountain streams provide the succulent crayfish that are not
found in the rivers, so we must look to the source of our solution. The
closer to the source the anomaly can be checked, the better for everything
that lives downstream, even the tributaries and feeds that have not formed
yet.
How to make the data palatable to the report program and make no change to
the Clock-in Class?
A new Class can be created with a few lines of code. It inherits all of the
methods of the Clock-in Class and overrides the one that returns the data to
a feeder (GetClockData), so that duplicates are ignored. Let's call it the
"Filter" Class. The report program now instantiates the filter object
instead of the clock-in object. The interface is exactly the same; it is a
one line change in the Data Divison of the report program, to point it to
the new .dll (The report program is a procedural program anyway and as such
will be subject to maintenance...but the idea is to minimise the
maintenance)
Any programs that use other methods in the clock-in object remain unscathed.
The clock-in class has not been changed. Any clients that use the
GetClockData method and cannot deal with duplicate data, can now use the
Filter Class override of it instead. No other methods have been changed, no
interfaces have been altered, everything works as it always has and no
regression testing is required.
Truly, Glasshopper, there are more things in my philosophy than you may
readily conceive...
Does the camel suffer because it is not a horse?
Bending the Tao of OO and components to contrived examples that are not OO
and component based is not a good way to understand the Tao of OO and
Components.
The  ness of the Lake is not experienced by looking at it.
Only when we enter the waters are we truly refreshed.
(Stands up, saffron robe falls off, revealing naked corpulence, takes out
ping-pong ball eyes, ... blushes and exits stage right, leaving room and
dignity behind...)
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| tlmfru 2007-09-06, 6:55 pm |
|
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
news:5k3nvnF20gicU1@mid.individual.net...
>
>
> A new Class can be created with a few lines of code. It inherits all of
the
> methods of the Clock-in Class and overrides the one that returns the data
to
> a feeder (GetClockData), so that duplicates are ignored. Let's call it the
> "Filter" Class. The report program now instantiates the filter object
> instead of the clock-in object. The interface is exactly the same; it is
a
> one line change in the Data Divison of the report program, to point it to
> the new .dll (The report program is a procedural program anyway and as
such
> will be subject to maintenance...but the idea is to minimise the
> maintenance)
>
> Any programs that use other methods in the clock-in object remain
unscathed.
> The clock-in class has not been changed. Any clients that use the
> GetClockData method and cannot deal with duplicate data, can now use the
> Filter Class override of it instead. No other methods have been changed,
no
> interfaces have been altered, everything works as it always has and no
> regression testing is required.
Actually, only one program was affected: the edit/file update. I follow
what you're saying. Thanks.
>
> Truly, Glasshopper, there are more things in my philosophy than you may
> readily conceive...
Kwai Chen Caine's Master, in an unusually opaque mood: Grasshopper, my son,
be like the willow, which turns green in summer.
Kwai Chen Caine: I don't understand, master.
>
> Does the camel suffer because it is not a horse?
The camel is the only one of God's creatures which knows God's real name:
that's why it looks so arrogant and (I dare say) pities the horse for not
being a camel.
>
> Bending the Tao of OO and components to contrived examples that are not OO
> and component based is not a good way to understand the Tao of OO and
> Components.
Not contrived - it happened! As you point out, OO is a different approach,
and if I'm going to shamelessly crib your experience, I have to ask
questions if I don't see my way clear ...
>
> The ness of the Lake is not experienced by looking at it.
So much for virtual reality, thank Bog.
>
PL
| |
| Pete Dashwood 2007-09-06, 6:55 pm |
|
"tlmfru" <lacey@mts.net> wrote in message
news:3mVDi.39738$Pv4.1513@newsfe19.lga...
>
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
> news:5k3nvnF20gicU1@mid.individual.net...
> the
> to
> a
> such
> unscathed.
> no
>
> Actually, only one program was affected: the edit/file update. I follow
> what you're saying. Thanks.
>
You're welcome :-)
>
> Kwai Chen Caine's Master, in an unusually opaque mood: Grasshopper, my
> son,
> be like the willow, which turns green in summer.
>
> Kwai Chen Caine: I don't understand, master.
>
>
> The camel is the only one of God's creatures which knows God's real name:
> that's why it looks so arrogant and (I dare say) pities the horse for not
> being a camel.
>
>
> Not contrived - it happened! As you point out, OO is a different
> approach,
> and if I'm going to shamelessly crib your experience, I have to ask
> questions if I don't see my way clear ...
Sure. The trouble is, Peter, that in the past I have spent hours here trying
toexplain OO approaches and how they differ, only to be told that there is
no advantage, because the example that was presented, was non-OO based. It's
like trying to fix a car with a banana, and then grizzling because a spanner
can do it better.
I am now reticent about it and gave up long ago trying to persuade anyone to
this approach. The example you gave, while I agree it is not contrived in a
non-OO environment, is a "contrived" example for an OO solution. The
approach would be different if OO was in use. (There wouldn't be an
edit/file update, for a start... the decomposition levels would be lower,
with different methods of the same class communicating with each other and
the outside world. I tried to imply that in my response.)
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| tlmfru 2007-09-09, 3:55 am |
|
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
news:5kbg35F2u8h5U1@mid.individual.net...
>
>
> I am now reticent about it and gave up long ago trying to persuade anyone
to
> this approach. The example you gave, while I agree it is not contrived in
a
> non-OO environment, is a "contrived" example for an OO solution. The
> approach would be different if OO was in use. (There wouldn't be an
> edit/file update, for a start... the decomposition levels would be lower,
> with different methods of the same class communicating with each other and
> the outside world. I tried to imply that in my response.)
>
> Pete.
> --
I didn't state, because it wasn't needed for the purposes of the question,
that there were daily, w -to-date, wly, month-to-date, monthly,
year-to-date and yearly requirements for reporting. Nor did I state, for
the same reason, that a complete time record involved from one to six raw
records from the clock. But now you've flummoxed me. I don't see how you
can possibly NOT have an edit-file update function, unless the approach is
to retain all the raw data and reiterate the edit/assembly/resolution
function every time a report is run.
?????
PL
| |
| Pete Dashwood 2007-09-09, 3:55 am |
|
"tlmfru" <lacey@mts.net> wrote in message
news:wlJEi.71657$rH6.32624@newsfe22.lga...
>
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
> news:5kbg35F2u8h5U1@mid.individual.net...
> to
> a
>
> I didn't state, because it wasn't needed for the purposes of the question,
> that there were daily, w-to-date, wly, month-to-date, monthly,
> year-to-date and yearly requirements for reporting. Nor did I state, for
> the same reason, that a complete time record involved from one to six raw
> records from the clock. But now you've flummoxed me. I don't see how you
> can possibly NOT have an edit-file update function, unless the approach is
> to retain all the raw data and reiterate the edit/assembly/resolution
> function every time a report is run.
>
> ?????
The edit/validation function would be a separate entity (Method) from the
file update function (Method). That's what I mean by a lower level of
decomposition. It also implies a higher level of encapsulation, but I have
no intention of going into a detailed OO design on this application :-)
I'm sorry, Peter. I know you asked the question in good faith and I tried to
answer it in kind (and at the same time amuse) but it is precisely the
discourse we are now entering into that I promised myself I wouldn't
participate in, some years back.
No more from me on this. If you want to talk or ask about OO, fine, I'm up
for that, but not in the context of an application that was never designed
with an OO solution in mind. For me, it is like trying to explain the colour
red to a blind man... Even if I wanted to (and I might have, once) I soon
realised how futile it is. There are basic concepts that are different to
the ones you currently hold. Everything I posit is measured in terms of the
current concepts and not in terms of the new ones required for proper
understanding. Typically, ITSA kicks in and my time is simply wasted.
If you are serious about getting some grounding in OO, I recommend "SAM's
Teach yourself Java 2 in 24 hours" by Rogers Cadenhead. It is one of the
best written text books I have ever encountered and after a couple of ws
with it I understood much more than I had after three months of OO COBOL. It
was then pretty easy to go back to OO COBOL and pick it up. But, by then I
had realised how clunky COBOL is in this regard (compared to the simple
elegance of Java), and, further encouraged by a complete lack of response
from Fujitsu when I enquired about their DotNET COBOL compiler, I was
already looking for an alternative. After considerable consideration (mainly
on how I could get into a modern OO environment and not lose the decades of
investment in COBOL) I have opted for C#. It is simpler than C, has all the
good things that are in Java, and brings a few more that are specific to
itself. Most importantly for me, it opens the DotNET framework and allows
my legacy COBOL components to run as unmanaged code under InteropServices,
thereby giving me the best of both worlds.
(It is gratifying to me to see that I am not alone in this evaluation;
figures released last month show the two hottest languages in terms of
growth currently are C# and Ruby on Rails. C# use in Europe increased to 54%
last year and is still rising...)
As you might expect, the more I write in it, the more facile and confident I
become with it, and I no longer think COBOL when looking to develop
something new. However, I would never discount or diminish the experience I
had with COBOL, hence my tagline.:-)
Pete.
--
"I used to write COBOL...now I can do anything."
|
|
|
|
|