Cobol - (no subject)

Author

(no subject)

James J. Gavan

2006-05-07, 6:55 pm

Pete Dashwood wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:l1P6g.128538$WI1.52140@pd7tw2no...
>
> <snip>>
>
>
> The documentation is a help file that documents the Methods, Properties, and
> Events. Anyone developing components for other people to use would be crazy
> NOT to provide such documentation (no one would buy it if you were selling
> it) and the fact that this is being imposed from Head Office doesn't mean
> they don't have to document it. If I were required to use it I would simply
> ask politely for the documentation... In the meantime, I'd make a start on
> it using the approach described below.
>
> But such a scenario is extremely unlikely. People who work in this
> environment KNOW that components need to be documented, especially as source
> code will not be provided. I think I have mentioned here on several
> occasions that writing the help file for a component can sometimes take more
> time than the development of the component itself. The Help file provides a
> quick reference via hyperlinks to whatever you are interested in, and it
> also has 'background' as to why certain approaches were adopted.
>
>
>
> Should have checked the documentation before using the Properties... If it
> was being developed for international use it is likely that different sets
> of properties would become visible, depending on the country. Set the
> country code and suddenly a new set of properties is enabled...
>
>
>
>
> Easily. You apply an Object Browser to it and it SHOWS you the Interfaces,
> Methods and Properties supported by the component.
>
> Anybody working with OO components will make frequent use of such a tool. A
> very entertaining afternoon can be spent (and I've done this a couple of
> times since I acquired Visual Studio, which comes with an absolutely
> excellent Object Browser) just looking at all the ActiveX and COM components
> which are provided with Windows...:-) There is amazing stuff sitting right
> there on your computer, free for you to use, all you need to do is find it.
> Object Browsing is a bit like treasure hunting... :-)
>
> Pete.
>
>
Oi ! Who said anything about components ? (I knew you would comment
anyway - that's why I didn't mention your, "Yer don't need source"). Or
are you now extending the component family to include discrete written
classes for an installation's own DB Tables and COBOL files, plus of
course those record classes.

I agree that you have to have documentation with your class/component if
the source is to be hidden from the serfs. (Reference to Michael M's
'expensive' people producing those DB copy files and the 'also rans',
the cheap labour, incorporate them into their programs without really
needing to know which way is up - and of course - compile. Uggh).

But bear in mind I wrote they don't necessarily produce GETs/SETs - YOU
do, but that doesn't mean its the only way. So MOVE x of anObject is a
perfectly valid alternative. Think a name and address block - why a
series of -

getName
getAddressLine1
getAddressLine2
getCity etc..., or

MOVE name of xxxx to my-name
MOVE AddressLine1 to of xxx to my-AddressLine1 etc.

shortcut the damn thing -

MOVE CustomerAddressData of xxx to my-AddressData

Now think back on OO before you got the component buzz - so called total
ENCAPSULATION is theoretically possible and desirable. But it is not
the whole story. Given a Treeview, for example, that I want to change
icons from Red to Green when 'actioned' - chances are the supporting
classes available may not appear to have the feature to do this - but
the inheritee has it available from its inheritor class - and it is as
easy as pie to override providing YOU HAVE THE SOURCE.

Actually Treeview is a fascinating control that you can embrace all
sorts of changes in, colouring horizontal and vertical hierachial lines
, hang combo droplists on to Labels, substitute Checkboxes On/Off icons
instead of folders or 'balls' etc. Nobody is likely to want the complete
set but given access to SOURCE such features are fairly easily incorporated.

Let's lump three topics together -

(a) Frank commenting about using tools like EXCEL etc., followed by
Peter saying he got the shove, (the nice term over here is "We had to
let him go"), because as DP he suggested it might be desirable if he had
a watching brief over what individual end-users were doing with these
tools. Indirectly this topic ties in with (c) below to some extent.

Practical horror story on above. Some smart cookie in downtown real
estate about 15 years back decides he'll set up a DB, (can't recall what
the tool was). He had already started on it keying in quite a bit of
data, at lest 2,000 properties. Had me and a non-IT guy in to see if we
were interested in getting involved. Questions raised, observations made.

Then we have a second meeting. Tell us he has already incorporated some
changes in the DB - "Took some time", he said. "I had to re-design the
tables and enter the data all over again". Ouch, what about exporting
and importing back to the DB - had I suggested it he would have thought
exporting/importing had something to do with Canada's trade deficit.

(b) Michael M. points out, and a correct observation, you use your
experienced expensive folks under the DBA to produce SQL copy files to
be used by serfs - short answer to that one would be to be include the
routines in OO classes - but how many here actually have access to an OO
compiler.

(Actually the 27-year old g

that lives next door to me - moves out in
June - is a 6' 6" turd with not very much between the ears, colourless
and humourless, and fits into Michael's scenario. As he told me with a
painful look, he finds his job "Stressful and challenging". He knows two
words 'Oracle' and 'Java'. Well he knows three words - 'DBA' - he trots
off to see him for one of those wonderful copy files as necessary. 'DB2'
is not even in his vocabulary as a passing thought).

(c) Then one of your latest - and the one which really troubles me - Hey
! I'll be stone dead before it has any real impact, (although it is
partially happening in (b) above). You'll be in your dotage hoping some
kind soul wheels you in your chair down to the beach occasionally.

You wrote eventually we finish up with a grand Lego set - folks just
plugging bits together. Well the toy Lego you can see and kick - but not
your Lego components. Inevitably it will finish up with a few
powerhouses producing these computer Lego sets. Just like commerce has
superseded borders by going international - we will have these tool
powerhouses calling the shots. It will of course work just great, (at a
price when they have shut off much of the junior competition).

Here we are in 2006 - what happens in 2056 ? If the production of
computer Lego tools is constrained to a few powerhouses, what happens
when some inquisitive kid called 'Steve' or 'Bill' thinks he'd like to
get into this game - where does he start, having to face the Cabal set
up by the current producers ?

Fortunately some humans are inquisitive and imaginative and will break
through the firewall created by those powerhouses. But it will be tough.
Meanwhile the silent majority will go along with what is, not giving a
thought to new approaches until such time as they happen; then there's
the timelag before they are proven and accepted.

Jimmy

Pete Dashwood

2006-05-07, 6:55 pm

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:7kW6g.130268$P01.86836@pd7tw3no...
> Pete Dashwood wrote:
> Oi ! Who said anything about components ?

You did.
There is more than one type of component. An OO Class packaged as a .DLL
(which is what you described) only needs to be registered to be browseable
with an Object Browser. (There are probably Browsers that don't even require
it to be registered.)
If it happens to have been wrapped as a COM DLL it is then a component; if
it includes certain interfaces it is an ActiveX component.

(I knew you would comment
> anyway - that's why I didn't mention your, "Yer don't need source"). Or
> are you now extending the component family to include discrete written
> classes for an installation's own DB Tables and COBOL files, plus of
> course those record classes.
>
I don't need to extend the component family. See above. OO Classes, packaged
as .DLLs are one type of component.

> I agree that you have to have documentation with your class/component if
> the source is to be hidden from the serfs. (Reference to Michael M's
> 'expensive' people producing those DB copy files and the 'also rans', the
> cheap labour, incorporate them into their programs without really needing
> to know which way is up - and of course - compile. Uggh).
>
This has been a very effective approach for some decades now.

> But bear in mind I wrote they don't necessarily produce GETs/SETs - YOU
> do, but that doesn't mean its the only way. So MOVE x of anObject is a
> perfectly valid alternative. Think a name and address block - why a series
> of -
>
> getName
> getAddressLine1
> getAddressLine2
> getCity etc..., or
>
> MOVE name of xxxx to my-name
> MOVE AddressLine1 to of xxx to my-AddressLine1 etc.
>
> shortcut the damn thing -
>
> MOVE CustomerAddressData of xxx to my-AddressData
>
Makes no difference. It is just a different property. Move x of an Object is
just another form of GET/SET. (I thought that was covered by the previous
poster...)

>
> Now think back on OO before you got the component buzz - so called total
> ENCAPSULATION is theoretically possible and desirable. But it is not the
> whole story.

Who suggested that it was? You'd normally add polymorphism, reuse,
inheritance and interfacing before you'd even suggest that that MIGHT be the
whole story...

> Given a Treeview, for example, that I want to change icons from Red to
> Green when 'actioned' - chances are the supporting classes available may
> not appear to have the feature to do this - but the inheritee has it
> available from its inheritor class - and it is as easy as pie to override
> providing YOU HAVE THE SOURCE.

It's as easy as pie to obtain this behaviour, whether you have the source or
not, if it is written properly.

> Actually Treeview is a fascinating control that you can embrace all sorts
> of changes in, colouring horizontal and vertical hierachial lines , hang
> combo droplists on to Labels, substitute Checkboxes On/Off icons instead
> of folders or 'balls' etc. Nobody is likely to want the complete set but
> given access to SOURCE such features are fairly easily incorporated.
There are many treeview controls, not just one. All the ones I've come
across utilise a node collection for the data and allow the facilities you
describe by a combination of Properties and Methods. You don't need source
to use them. Having it is no bad thing if you want to work at such a low
level but there is nothing to be gained by doing so if the code was well
written in the first place. Why would anyone rewrite well written working
code?

You don't need access to source if it is written properly and exposes the
right methods and properties. I use several treeviews and do not have the
source of them. Actually any one of them would meet my needs; I have a
number because I was driven by curiosity to see if any one of them was
better then the others :-)

I also have a MUCH more complex scheduling grid component that I have no
source for (It has over 200 methods) and produces text in a range of colours
determined by a property.

Source is definitely NOT a requirement if you are using objects.
>
> Let's lump three topics together -
>
> (a) Frank commenting about using tools like EXCEL etc., followed by Peter
> saying he got the shove, (the nice term over here is "We had to let him
> go"), because as DP he suggested it might be desirable if he had a
> watching brief over what individual end-users were doing with these tools.
> Indirectly this topic ties in with (c) below to some extent.
>
> Practical horror story on above. Some smart cookie in downtown real estate
> about 15 years back decides he'll set up a DB, (can't recall what the tool
> was). He had already started on it keying in quite a bit of data, at lest
> 2,000 properties. Had me and a non-IT guy in to see if we were interested
> in getting involved. Questions raised, observations made.
>
> Then we have a second meeting. Tell us he has already incorporated some
> changes in the DB - "Took some time", he said. "I had to re-design the
> tables and enter the data all over again". Ouch, what about exporting and
> importing back to the DB - had I suggested it he would have thought
> exporting/importing had something to do with Canada's trade deficit.
>
> (b) Michael M. points out, and a correct observation, you use your
> experienced expensive folks under the DBA to produce SQL copy files to be
> used by serfs - short answer to that one would be to be include the
> routines in OO classes - but how many here actually have access to an OO
> compiler.

Or you write general purpose access modules (as we did in the 70s) that are
cappable of carrying out ANY action on a given table or tables and CALL
them. The same effect is achieved today (much more efficiently) by stored
procedures which are tailored to a given action against a given database or
table. These are under control of the DBMS and can run asynchronously. The
application only needs to trigger them. ESQL is kind of 'quaint' in this
environment... I haven't written any for years... Stored [procedures are an
extension of OO philosophy really, because you are storing the methods to
handle data, along with the data that will be handled. It took me a while
to warm to this idea, but once I saw some experts working with it I was
sold.
>
> (Actually the 27-year old g

that lives next door to me - moves out in
> June - is a 6' 6" turd with not very much between the ears, colourless and
> humourless, and fits into Michael's scenario. As he told me with a painful
> look, he finds his job "Stressful and challenging". He knows two words
> 'Oracle' and 'Java'. Well he knows three words - 'DBA' - he trots off to
> see him for one of those wonderful copy files as necessary. 'DB2' is not
> even in his vocabulary as a passing thought).
>
> (c) Then one of your latest - and the one which really troubles me - Hey !
> I'll be stone dead before it has any real impact, (although it is
> partially happening in (b) above). You'll be in your dotage hoping some
> kind soul wheels you in your chair down to the beach occasionally.

Nope, that ain't gonna happen... I'm gonna buy one of those super groovy
electric chairs, tweak it a bit and drive myself to the beach when they pull
my license... :-)

>
> You wrote eventually we finish up with a grand Lego set - folks just
> plugging bits together.

Yes, I believe we will end up with end users configuring software to do what
they want. They'll do this by graphically 'assembling Lego' where each block
will represent a configurable Business process. (under the covers there will
be many such blocks, but the user may not be aware of them). And they'll
probably refer to the process as 'programming', in memory of the ancient art
that was so important in the latter half of the twentieth century...

Have you seen Visual Studio :-)? You can write code (in any of C#, VB, C++
(in fact you can mix them if you want because the source is unimportant),
and a few Scripting languages), create a component from it in minutes, join
that to other components using drag and drop, then deploy the whole lot as
either a distributed application with Remote Procedure Calls for a network,
ASP pages for a web server, or a static Windows desktop application (with NO
runtime fees for any of it...)

It is a very long way from coding COBOL, even if you decide to write a code
based solution, rather than using components.

> Well the toy Lego you can see and kick - but not your Lego components.

Why would you want to kick either of them?

>Inevitably it will finish up with a few powerhouses producing these
>computer Lego sets.

Why not? WE tolerate it with motor cars...

Just like commerce has
> superseded borders by going international - we will have these tool
> powerhouses calling the shots. It will of course work just great, (at a
> price when they have shut off much of the junior competition).
>
Yes, I think that is a possible scenario..
..
> Here we are in 2006 - what happens in 2056 ? If the production of computer
> Lego tools is constrained to a few powerhouses, what happens when some
> inquisitive kid called 'Steve' or 'Bill' thinks he'd like to get into this
> game - where does he start, having to face the Cabal set up by the current
> producers ?
>
By 2056 there will be no requirement for manual programming of computers.
Computers will simply do whatever you ask them to do, a la 'Hal'.

There are some major breakthroughs in the pipeline already, and,
statistically, we can expect at least one iconoclastic development that will
change the whole game. The powerhouses you describe will probably still be
around, but it is very unlikely they will be building Lego sets for
commercial computer programming.

> Fortunately some humans are inquisitive and imaginative and will break
> through the firewall created by those powerhouses.

Just like the imaginative innovative people who have broken through the
stranglehold of GM, Ford, et al in the motor industry? Around 30 brands
worldwide have it sewn up. How long is it since we saw a new successful
marque of autmobile? OK... DeLorean :-). Is anybody suffering? I don't see
major protest marches because Toyota or BMW cannot be effectively competed
with in their markets.

Instead, while the rest of the world drives a Ford and dreams of a BMW the
Germans drive a BMW and dream of a Mercedes...:-)

>But it will be tough. Meanwhile the silent majority will go along with what
>is, not giving a thought to new approaches until such time as they happen;
>then there's the timelag before they are proven and accepted.

I thought your point was they would not happen... guess I lost this
somewhere. You appeared to be saying no bright young people would get a look
in, and now you are saying innovation will happen anyway.

So, if the big cartels are innovating, they'll probably be employing bright
young people and paying them more than if they tried to start up their own
companies...Doesn't that mean that the rest of us are right to simply 'go
along with what is'?

I'm not sure what you are actually getting at here.

But I really don't think it matters. Computer programming is a dying art.
Configurable packages will take care of it within the next 10 - 20 years;
you won't have to wait for 2056...

In house IT will be relegated to care of the network, configuring servers,
upgrading the OS, help desk and training, and installing new software. Users
will put their own applications together using much better tools than are
currently available. Core business processes will be run by SAP, Siebel,
ORACLE and a couple of others that are likely to emerge. EDI and B2B will
grow and the web will pervade our lives and businesses to an extent not even
seen yet. Wireless internet will mean we are always on line and this alone
will change the way in which people do business.

The last thing you need to worry about is how I see components being glued
together...:-)

Pete.

Sponsored Links