From: Pete Dashwood on


"Robert" <no(a)e.mail> wrote in message
news:4oc6q3d8r1acm34uj2rf24mpo244djrq5n(a)4ax.com...
> On Fri, 1 Feb 2008 10:43:08 +0000 (UTC), docdwarf(a)panix.com () wrote:
>
>>It might be seen as moderately amusing what has happened when someone who
>>frequently disparages 'the way things were done' confronts an example of
>>'how things were'.
>>
>>'What kind of foolishments are these? This IF is coded across screens and
>>screens, why wasn't it broken down into an EVALUATE and some in-line
>>PERFORMs?'
>>
>>'The code-base was laid down in 1975, a decade before those features were
>>available... and the shop didn't start using those features until the Y2K
>>conversion in 1998 and nobody since then has authorised the budget to
>>rewrite and re-test it.'
>
> I don't find it amusing. While and because old Cobolers were resisiting
> change, the world
> abandoned Cobol. Note past tense; it already happened.

Yes, it did. And the resistance of the COBOL community to new ideas was
certainly a major factor. However, it wasn't the ONLY factor, and many who
were previously resistant are now aware that certan nettles will have to be
grasped and bullets bitten anyway, with or without COBOL.

I have spotted a few things recently which make me think that COBOL may be
twitching for a while yet. Too soon for optimism, but a "resurrection" of
COBOL may not be out of the question. If it happens (and the chances are
slight in my opinion) it will require an attitude shift on the part of many
in the COBOL community (Managers, Analaysts and Programmers). However, that
shift is not as unlikely today as it was 10 years ago...

Time will tell. :-)

Pete.
--
"I used to write COBOL...now I can do anything."


From: Pete Dashwood on


"Robert" <no(a)e.mail> wrote in message
news:p4d6q3hg7qlidtj2sc556ttnkqtcduq5ki(a)4ax.com...
> On Fri, 1 Feb 2008 10:31:32 +0000 (UTC), docdwarf(a)panix.com () wrote:
>
>>In article <1u65q3l1v0rcriqpa82bvev2p8j9hiqcdq(a)4ax.com>,
>>Robert <no(a)e.mail> wrote:
>
>>>Manuals are as close as your Web browser.
>>
>>Mr Wagner, I saw my first DB2 installation in 1987... and I worked on
>>sites where consultants/contractors/hired guns were not allowed web-access
>>into the mid-1990s.
>
> I worked at place with such a policy in 2001. When I needed to look
> something up in a
> manual, I drove home to do it. Time per lookup was 30-45 minutes.
>
> Only gubbermint gets away with such inefficiency.

Hmmm... :-)

If I thought anyone on my team was beng that obtuse, they wouldn't be on it
for very long. :-)

Pete.
--
"I used to write COBOL...now I can do anything."


From: Pete Dashwood on


"Robert" <no(a)e.mail> wrote in message
news:5so6q3l17qiq3gf69mi6bfk976dh1p0hc5(a)4ax.com...
> On Fri, 1 Feb 2008 15:32:04 +0000 (UTC), docdwarf(a)panix.com () wrote:
>
>>In article <p4d6q3hg7qlidtj2sc556ttnkqtcduq5ki(a)4ax.com>,
>>Robert <no(a)e.mail> wrote:
>>>On Fri, 1 Feb 2008 10:31:32 +0000 (UTC), docdwarf(a)panix.com () wrote:
>>>
>>>>In article <1u65q3l1v0rcriqpa82bvev2p8j9hiqcdq(a)4ax.com>,
>>>>Robert <no(a)e.mail> wrote:
>>>
>>>>>Manuals are as close as your Web browser.
>>>>
>>>>Mr Wagner, I saw my first DB2 installation in 1987... and I worked on
>>>>sites where consultants/contractors/hired guns were not allowed
>>>>web-access
>>>>into the mid-1990s.
>>>
>>>I worked at place with such a policy in 2001.
>>
>>So, Mr Wagner... since you worked as such a place at some point is it
>>reasonable to conclude that you are working at such a place now?
>
> Web access is almost universal nowadays. But they need SOME way to lower
> contractors'
> social status. Denial of VPN access is a popular choice. Chicago roads
> were terrible
> this morning due to a snowstorm. Contractors had to drive in it while
> employees worked
> from home. The parking lot was more than half empty. There is no valid
> security reason
> when SecureID is used. VPN ports don't cost anything in royalties.
>
> Other places restrict contractors to one entry door. The reason is because
> administrators
> are too lazy to set them up in the security system, but it also serves as
> a social marker.

Contractors do have a choice, Robert.

If the corporate culture is such that contractors are despised, while being
considered necessary, then moves should be made to address that culture.
Maybe a round table with some Senior Managers, pointing out the fact that
such an attitude, apart from being immoral, is simply costly and
inefficient, and showing how contractors could bring much more to the table
if they were treated properly. (Where is the management logic in
demotivating an expensive resource?)

I have worked in places where contractors were treated exactly like
permanent staff (except for pay) and they were usually happier shops (for
everybody, not just the contractors...) Happy contractors are more likely to
share expertise with the locals and even go the extra mile occasionally
(driving home to check a manual is not "going the extra mile" in this sense
:-)) If a company recognises that they need contractor expertise, then they
should recognise that to maximise that expertise, it is wise to keep
everybody happy.

There will always be the disgruntled permies who resent the freedom of
contracting and the fact that someone doing "the same job" (whatever that
means...) is being paid more, but won't drop the cuddle blanket of paid
holidays, sick leave, insurance, (and perceived - it isn't real, and hasn't
been for decades- job security...) and go contracting themselves, and the
best way I've found to deal with them is to talk frankly (and without
antagonism or hostility) and remind them of why they are NOT contracting.
Once everybody knows where they stand it is easier to get on with the job,
without gnawing resentment.

Corporate culture is a major (although largely unrecognised) factor in
determining the success of IT projects. It is the reponsibility of managers
to ensure this culture is positive and that applies to permanent staff as
well as anybody else. If they can't treat their own staff properly, they
certainly won't treat contractors properly.

If it is a hopeless hierachic structure governed by mean spirited control
freaks who have no insight into motivating and treating people properly, and
all attempts to address this have failed, then, contractors should vote with
their feet. (So should permanent staff, but I recognise that it is much
harder for them. If it wasn't, they probably wouldn't be permanent in the
first place...)

Many years ago, I worked on such a site and I have never forgotten that
experience. I was pretty inexperienced at contracting and believed I HAD to
stay for the duration (six months); nowadays I would be out in four weeks
:-).

(Aside to young contractors - read your contract and cross out the paragraph
that says you cannot terminate, but they can give you one month. Make it the
same for both sides. If the agency protest that it is a "standard contract"
and "everybody signs it" tell them you won't. Do this AFTER you have been
interviewed and accepted by the client company.)

I hope the U.K. company I am referring to have moved on, and have better
managers now, but I have no intention of finding out...:-)

Pete.
--
"I used to write COBOL...now I can do anything."


From: William M. Klein on
"Robert" <no(a)e.mail> wrote in message
news:5so6q3l17qiq3gf69mi6bfk976dh1p0hc5(a)4ax.com...
> On Fri, 1 Feb 2008 15:32:04 +0000 (UTC), docdwarf(a)panix.com () wrote:
>
<snip>
> Web access is almost universal nowadays. But they need SOME way to lower
> contractors'
> social status. Denial of VPN access is a popular choice. Chicago roads were
> terrible
> this morning due to a snowstorm. Contractors had to drive in it while
> employees worked
> from home. The parking lot was more than half empty. There is no valid
> security reason
> when SecureID is used. VPN ports don't cost anything in royalties.
>
Robert,
As someone who lives in suburban Chicago, I am aware of what roads were like
today. I don't know a HUGE number of contractors, but the ones that I do know
were all (as usual) able to work from home. Are you on a current contract that
doesn't give you web access? About what percentage of those contractors that
you know are not able to work from home (when employees are)?


--
Bill Klein
wmklein <at> ix.netcom.com


From: Pete Dashwood on


--
"I used to write COBOL...now I can do anything."
"Judson McClendon" <judmc(a)sunvaley0.com> wrote in message
news:0zMoj.64189$vt2.19285(a)bignews8.bellsouth.net...
> "Robert" <no(a)e.mail> wrote:
>>
>> I don't find it amusing. While and because old Cobolers were resisiting
>> change, the world abandoned Cobol. Note past tense; it already happened.
>
> There were many other reasons for the demise of COBOL than resistance to
> change by old-timers.

Yes there were, but it was still a major one.

>And I think a lot of the resistance was because the
> old-timers knew that the new OO paradigm, for example, fit COBOL like a
> square peg in a round hole.

Nope. Most of the old timers (exactly like yourself, Judson... no offence)
never really got to understand OO or what it could do for them because they
wrote it off with ITSA instead of actually looking at it. People outside the
COBOL world were not so certain that there is only one RIGHT way, and did
not measure the new paradigm against an old one that they were convinced did
not need change. As a result, the world moved on, COBOL was left behind.

OO was added to COBOL by forward thinking vendors, recognising an important
emerging paradigm. It was a staggering feat of software engineering and did
not deserve to be shunned as it was by the COBOL community at large.

I used OO COBOL for almost a decade (mainly to build reusable components
which I still have a huge investment in) and found it excellent.


>I always knew that one of COBOL's greatest
> strengths was it's simplicity. Add OO, destroy the simplicity.

Absolutely not. "Simplicity" is a subjective thing, and usually relates to
that with which we are familiar. (I think Richard was the first to point
that out in this forum, and he is absolutely correct.)

When I first addressed OO COBOL (trying to learn it by experimentation, and
from the manual, as so many of us do when we can't get training...) I found
it complex and difficult.

I gave up and went to Java. Because it was completely different form COBOL
there was no chance to apply ITSAs, and within a week or two I had grasped
the concepts and was writing effective Java code.

As I wrote more, the concepts began to gel. I never tried to write COBOL in
Java; instead, I realised there are many ways to do things and this was a
completely new paradigm, with some very special advantages.

With this new found knowledge I went back and had another look at OO COBOL.
It all fell into place and was no longer complex or difficult. (It was
certainly more verbose, but that isn't necessarily a bad thing, especially
if you plan to maintain the code.)

BOTTOM LINE: OO, even OO COBOL, is NOT difficult, IF you set aside what you
already know, and take the new concepts on board WITHOUT deciding at some
point in the assimilation process that "it's just modular programming
re-invented", or any other ITSA consideration.


>The things
> that make COBOL great for its heyday are also things that do not fit
> current development paradigms.

True. Standard procedural COBOL IS a different paradigm to OO. It is a
different paradigm to OO COBOL.

>Another of COBOL's great strengths was the
> Data Division, and the ease and power of the hierarchical structures and
> data formatting in the Picture clause. But with standardized databases,
> XML, et al, those became irrelevant.

Yes, agreed.

> Consider Pete Dashwood. He embraced
> and championed OO COBOL diligently for years. But Pete has abandoned
> COBOL for other languages better suited to today's development needs. I
> don't want to put words in Pete's mouth, but I don't think his decision
> had anything to do with resistance by old-timers; I believe it was based
> on pragmatic evaluation of the relative strengths of the tools in today's
> development environment.

Partly. I have NOT "abandoned" COBOL (I really can't because I have too
large a code base). In fact I was writing COBOL yesterday... it was kind of
like walking through molasses, after using C#... :-) I was doing it for
someone else, not for myself...

Fortunately for me, most of my COBOL code base is components written in OO
COBOL (Fujitsu NetCOBOL and PowerCOBOL). When I realised DotNET was the way
to go, I needed to upgrade to Fujitsu NetCOBOL for .NET. It is an imperfect
product (there are limitations on what it implements as far as COBOL goes),
it costs several thousand dollars, and when I enquired about purchasing it
(having decided to bite the bullet and spend the money) they ignored me. I
asked again and never received a response. As a matter of principle, I don't
intend to beg some company to sell me their product, so I looked for other
options. I considered MicroFocus Net Express, but the runtime licensing
makes it a nonstarter as far as I'm concerned, and I would have had to
convert all my existing code anyway.

What to do?

MicroSoft were offering Visual Studio Express (which supports VB, C#, C++,
and some scripting languages) as a free download. I took it. Downloaded the
DotNet framework, along with some free videos on getting started and
immersed myself in it for a couple of weeks.

I decided to go with C# as rumour had it that it was "Java-like" and I
couldn't bring myself to go to VB after all these years... :-)

It didn't take long to realise that this was a whole new ball game. The
tools were light years ahead of the COBOL Editors I was used to, the
debuggers simple and visual (and you can set break points ANYWHERE, which
you cannot do in Fujitsu COBOL). It was breathtaking. Write code and it is
IMPOSSIBLE to make syntax errors; learn as you write. Intellisense shows you
the format and parameters of any method call you make as you code it, can't
misspell variable or property names or have to remember them; it's a
dropdown at the point in the code where you need it. Everything is visual;
point and click, minimum typing. And the power of it is phenomenal. Things
that took a day to do in COBOL were dropped into my projects in seconds...
sorry, it still just blows me away :-) The .Net framework has 80,000
classes, all immediately available as soon as you set a reference to them,
and all browseable. That's 80,000 components I didn't have to write, and
some of them are amazing.

Best of all, it's free :-)

Good, but what about the existing COBOL base?

Fortunately the FCL (Framework Class Library) provides something called
"InteropServices". This allows code that is NOT C# to run in the C#
environment as what is termed "unmanaged" code. This means that C# (more
properly, the CLR...) takes no responsibility for it (it does for anything
that IS C# (managed code) and raises handleable exceptions with great
explanations and diagnostics if your code runs off the rails), but runs it
"as is". Provided you haven't done anything stupid in it (subscripts out of
range, pointers to non-existent code, the usual rubbish), it works
perfectly.

As most of my COBOL components are COM compliant, Interop Services accepts
them very gracefully and even passes COM errors back through the normal
exception handling.

I love it! :-)

Now to the point: How did resistance from the COBOL community bring me to
this?

Well, if everyone had embraced OO COBOL when it was released, if people had
used OO COBOL as their preferred tool for network applications and standard
COBOL for the batch stuff, we would have a different world. COBOL would have
retained (probably even enhanced) its credibility. Components written in OO
COBOL would be running on the network and people using Java and other
languages would accept that OO COBOL had as much right to be there as
anything else. In fact, OO COBOL components would be playing nicely and
interacting with components in other languages.

(I can honestly say, that on the occasions when I have demonstrated COBOL
stuff to Java people they have always been interested and impressed... Their
normal perception of COBOL is as an outmoded batch processing language. That
would NOT be the case if OO COBOL had been embraced and propagated.)

Never mind. It's an ill wind that blows nobody any good... I'm pretty happy
at having been forced away from COBOL. can write applications much more
quickly and easily than I ever could, and, for the environments which I
target them (Windows and the Internet), I have much more power available
than I ever did with COBOL. Furthermore, I can still leverage my existing
COBOL, although some of it has to be refactored into COM components before
it can be easily reused in the new environments.

> I've made a similar change. I still support my
> clients who use COBOL, but I don't foresee developing any new systems in
> COBOL, except for those clients who want it. And they are steadily moving
> away from COBOL.
>
> To me it is clear that, if Old Cobolers, as you put it, had jumped on
> change as eagerly as anyone, we would still be watching COBOL's demise,
> maybe even sooner.

It's speculative, but I disagree for the reasons outlined above. While I
agree that this was not the ONLY factor in the demise of COBOL, I do believe
it was a MAJOR one.

>Their openness to change would have propelled them
> inevitably to the same objective conclusions about current development
> realities that me, and I think Pete also, to change.

Possibly. Not inevitably. If everyone was using OO COBOL, they probably
wouldn't need to look at other alternatives, any more than COBOL sites
looked at moving to PL/I in the old days (or vice versa).

Certainly, I find the verbosity of OO COBOL tedious now, but there are times
when a "self documenting" language is still useful, especially for
commercial development, and especially, if you have NOT adopted a component
based approach...

The thing that has really nailed this is the fact that maintenance of code
is no longer the primary consideration when systems are built with re-usable
components based on Object Classes. If you use component based design, you
rarely need to change code and even if you do, it is encapsulated and
minimal.

As the main justification for COBOL's verbosity is "ease of maintenance of
source code", and as this is now not the priority it once was, you have to
ask: "Why am I still using a verbose language when I'm not getting the
benefits that that verbosity is supposed to confer?" For me, that means C#
as preferred language. Quick, powerful, and fun to write.

>COBOL, in any form,
> just does not fit well into today's webcentric development environment,
> and no one here feels more regret over the passing of that simpler era
> than I do.

Well, I think COBOL CAN fit into today's webcentric development environment.
In fact, I know Richard has written CGI code in straight COBOL, and I have
used OO COBOL for both CGI and ISAPI. (It was a while ago; today I would use
ASP.NET and C#;) I'm currently trying to find time to evaluate Ajax and
Silverlight also, but the weather's too good... :-))

Pete.
--
"I used to write COBOL...now I can do anything."