Re: Declining Cobol job market



"PaulR" <paul.raulerson@xxxxxxxxx> wrote in message
news:0001HW.C4DCF0390018373EB01AD9AF@xxxxxxxxxxxxxxxxxxxxxx
On Thu, 28 Aug 2008 09:40:59 -0500, Pete Dashwood wrote
(in article <6hnrnpFn895uU1@xxxxxxxxxxxxxxxxxx>):



"PaulR" <paul.raulerson@xxxxxxxxx> wrote in message
news:0001HW.C4DB87AB00094E66B01AD9AF@xxxxxxxxxxxxxxxxxxxxxx
On Wed, 27 Aug 2008 18:15:13 -0500, Pete Dashwood wrote
(in article <6hm5g2FmvtrfU1@xxxxxxxxxxxxxxxxxx>):



"PR" <paul.raulerson@xxxxxxxxx> wrote in message
news:e41e894f-f8aa-4e3f-9b6b-932190cacd0d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Aug 25, 11:04 pm, Robert <n...@xxxxxx> wrote:
In the 10 years I've been a Cobol/Unix contract programmer (13 gigs),
demand for Cobol in
the US has slowly been declining. Demand is now so low that it's
unreasonable to continue
pursuing Cobol jobs. With sadness, I'm switching my specialty to
PL/SQL
and affiliated
server side Unix tools. While working as a Cobol programmer, I spent
more
time solving SQL
problems than Cobol problems. Now I find there are a large number of
shops
doing 100% of
server side programming in PL/SQ. Apparently, there are more PL/SQL
shops
than Cobol
shops. How lame, but that's reality.


Well, while is unarguable that COBOL jobs have declined in quantity
over the past decade, I
have noticed that people who can "get the job done" are in ever
greater demand these days.
Doesn't matter if the do it in COBOL or Sanskrit, if it gets done on
time, works, and is
fast enough, it's a success.

A lot of COBOL programmers (and RPG programmers, and Assembler
programmers, and PL/1,
and Pascal, and Fortran, and <pick a "legacy" language of your choice>
programmers
actually fall right into that job description.

Most "web programmers" don't. Amazing - COBOL programmers can learn to
wrangle the web, but
web jockies seem to be unable to handle COBOL.

[Pete]

Motivation has much to do with it. Why would an accomplished Web
programmer
want to learn COBOL? You might as well ask a journalist to learn
Sanskrit.

Your statement that COBOL people "CAN learn to wrangle the Web" is
true,
but
they have great difficulty in doing so. (I have had to teach some of
them
and, just like learning OO concepts and usage in general, they struggle
with
it.) There is a tendency amongst people who have used COBOL for decades
to
believe it is the "right" way and any other way which is not congruent
with
it must be wrong. New, unfamiliar concepts and the associated jargon
are
considered "difficult and complex" and viewed with suspicion. Attempts
to
hang new ideas on old pegs result in "ITSA" when it should be "ITSLIKE"
and
fundamental misunderstandings ensue.

It comes down to mastering OO concepts. COBOL people are, generally,
not
good at it and people with no previous programming experience walk all
over
them, in my experience. I know which ones I'd rather teach.

While your opinions expressed above will be comforting to many who are
currently feeling a bit "unloved", the actuality is that there are good
and
bad COBOL programmers, just like there are good and bad Web
programmers,
and
generalizing about either group is simply suspect.

I have seen nothing that makes me think Legacy programmers are better
at
picking up new concepts or are generally more proficient at "getting
the
job
done", than anybody else. In fact, the evidence in my experience tends
to
the contrary, at least when it comes to learning new skills.

I would agree that most Legacy programmers are more disciplined in
their
approach, but that is often more to do with age and maturity than any
particular programming skill.

A person of normal ability, who is motivated and wants to learn
something,
can apply themselves to it and the degee of their success is
predictable,
depending on the levels of motivation, application, and ability.

It has little to do with whether they are a Legacy programmer or not.

[/Pete]

Now I wonder what that means...
[Pete]

It means your opinion is a generalization, is arguable, and is biased
to
the
result you would like to believe. :-)

Pete.


I am not so sure of that at all Pete - I keep encountering expensive web
"programmers" who are helpless without DreamWeaver. They know all the
right buttons to push, but have no idea what the buttons actually do.

I used to use Dreamweaver and still do occasionally, although these days
I
use mainly VS 2008 for Web development with ASP.NET and C# code behind
on
the server. Thisis not necessarily the "best" way to develop web sites,
but
it serves me well. (I keep an eye opn other emerging technology as
well...)

DW is an excellent tool. You say they get whiney when they can't use
Dreamweaver; I say you wouldn't expect a carpenter to build you a house
without power tools. (Doesn't mean he CAN'T... it's just better for all
concerned if the tools are good.)

No, but I expect a carpenter to be able to pick up a hammer if he needs to
,
and not be unable to work if a nail gun isn't available. I also don't
expect
them to use a nail gun to screw in a screw. Same analogy. Dreamweaver can
be
a very nice too, as can Visual Studio. In your hands (or mine) that is
what
Dreamweaver is - a *tool*. In the hands of the people I am talking about,
and these people make up a large majority of the web people in the job
market, they are crutches. The analogy above of a carpenter who can only
us a
nail gun is quite apt.

It doesn't necessarily have to be COBOL, it could be Java, Perl, or even
Visual Basic, whatever really fits the task at hand.

Your response is a good one, Paul. (It is quite pleasant to be able to have
a civilized debate on CLC and that is why I have responded to your mail.) I
believe both of us have different viewpoints that are actually
irreconcilable, but I don't think you are "wrong". There definitely ARE
people out there who are lost without tools, where an "oldtimer" more used
to working at a lower level, wouldn't be. I concede that. However, we
shouldn't be expecting people to work without tools and anyone on my watch
(whether they are working in old or new technology) gets all the help,
support, and encouragement I can give them. My job is to ensure they
succeed. Denying them facilities is not conducive to that.

I'm not sure that your calling a tool a "crutch" is quite fair, but I
understand what you are saying.

I think Howard made a very valid point. We WANT our skills to be important,
even when, really, they may have less relevance due to emerging technology.

I have worked in this game for 40 years. I have applied myself and learned
countless packages, tools, techniques, and (fortunately for me) never lost
the yearning for learning. (I'm still extending my education into new stuff
right now, even though there may be no immediate market for the skills
acquired... I just want to know.. :-)) BUT, I have seen, on so many
occasions, stuff that I sweated long hours to learn and become proficient
in, simply overtaken by events and rendered unnecessary.

Who needs NCR 500 machine code anymore? Burroughs B500 Assembler? IBM 3790
Macro Assembler? in depth knowledge of IBM 3330 micro-programming? ICL 1900
PLAN? CDC Cyber series COMPASS? FORTRAN? PERT (Actually, that is still handy
occasionally...), VAX VMS BASIC? ZX Spectrum BASIC? AS 400 RPG? (OK, some
people still make a living with that one...not me!), COBOL? (Oops...
sorry...delete that...:-))

The point is that it is in the nature of IT to move forward. Sometimes
driven by technology, sometimes driven by the marketplace, sometimes driven
by advances that are logical extensions of existing Computer Science. But
change is inevitable. People who don't like it and can't deal with it,
really shouldn't be here.

I don't feel bitter about it; it is the nature of IT. Sell what skills you
can, for as much as you can, while you can. Acquire new skills and repeat
the process.

It has worked for me and I have no regrets over my career which is now
drawing to a close. These days I only do the stuff I really want to do (and
actually enjoy), and the fact that I am able to call the shots is only
partially down to luck (we all need some of that occasionally :-)). I paid
my dues, put i the time and the effort, educated myself without waiting for
someone else to pay for it, and maximized my value throughout my career. I
loved my work and revelled in it. (Still do...:-)). I have never sat around
bewailing the fact that some skill I spent months or even years acquiring,
is no longer worth much. Get over it. Move on.




I think here are very few people who use DW professionally and don't
understand the underlying/generated HTML and XML... not that it really
matters anymore. I wrote my first web site in Notepad in 1995 using HTML
and
very bare bones CSS. I wouldn't do that today and I wouldn't expect
anyone
else to either.

As for web programmers being expensive, have you tried hiring COBOL
people
recently?

Much as I hate to say it, COBOL people are pretty cheap to hire these
days.
So are sysprogs for that matter...

Web guys seem to pop in expected six figure salaries. Some of them are
brilliant, but useless if they can't think oursite the <fill-in-the-blank>
box. We just hired a really GOOD web programmer at work, and believe me,
the two we tried before him were - best forgotten. :/

Fair enough. I think there is a difference between contract and permanent
employees, in attitude and expectation. Having worked for years in both
capacities I can say that for the last 30 years, I've been Freelance and
would not consider going full time (I'm too old now anyway... :-))

Your response made me think about the last time I needed to hire COBOL
people. I realised with a shock that is much longer ago than I thought, so
I'll stand corrected on current rates.



They get frustrated and whiney when you have to task them with say,
interfacing to a "legacy" system, and then come up with the dopiest
ideas
you
can imagine. I don't care what anyone says, replacing a 40+ year old
homegrown system on the mainframe is not going to happen by having a
good
mastery of Dreamweaver.

Well, if you "don't care what anyone says" about it, there is little
point
me debating it with you, is there..? :-)


Okay, that's fair. I listen. But if you tell me the moon is made of swiss
cheese, or that a PC network should replace the mainframe because the
mainframe is dead out of date technology, I don't promise to believe you.
:)

I have seen (and been instrumental in) replacing a number of decades old
mainframe COBOL systems with web based applications and the exercises
were
very successful. Dreamweaver may or may not be instrumental in this; the
fact is that web based systems provide distributed access 24/7 and do it
in
a way which is familiar to the majority of the population, who have never
had to cope with 4 character data entry on a green screen in order to
instigate a transaction.


Old argument between us here. You believe online transactional processing
in
the way of the future and will replace batch processing, if I remember
correctly. (?)

Yes, I do believe that when online systems have the capacity to model the
real world exactly in real time, batch processing as part of an overnight or
other scheduled window will become unnnecessary. OLTP would be creating
summarized, pivot, and data warehousing type layers by
multi-tasking/processing as the transaction progresses. I also believe that
the general public will gradually move away from paper based summaries as is
already happening. (I haven't had a paper Bank Statement (for example) for
over 3 years now. It isn't a problem. I can access my account and list
transactions on it for ANY time period up to six months, instantly, online,
if I want or need to and, of course, balances are available instantly on my
phone, or laptop.) The whole way in which we do business will chage and a
consequence of this will be removal of batch processing requirements.


I disagree. :)

Sure, so do many people. :-) I have no problem with that. (Actually, it
isn't really critically important in the broad scheme of things for the mid
to long term future...) I have never suggested that batch processing will
disappear overnight.


It is all based upon cost - batch processing is cheaper and easier to
control, IMNSHO of course.

That's arguable and costs are falling all the time. Even if what you say is
true, how long can you guarantee it?


As for front ending a transaction - you can easily drive a very nice
interactive web site directly from CICS these days, and the users never
see those nasty TRANS names. The front end is easy to separate from
the backend doing the heavy lifting processing.

Sure. SOA is one quite successful approach to levering the CICS legacy, and
an approach which I personally endorse. Nevertheless, the presentation layer
is best in a Web based environment where the full power of GUI can be
unleashed and is what people want and expect. New releases in technologies
like AJAX and WPF are going to change the whole way the Web works and move
it towards a more component based architecture.
I'm already moving this way in ASP.NET apps, but the latest releases have
some very interesting capabilities. I watched a demo a few weeks back of a
complete Web site with zoomable geographic maps, built completely from
scratch in just over two hours. Nothing prebuilt, no pre-existing data.
Presentation, business, and data layers all put together easily and
correctly using the latest generation of tools. It really is irrelevant
whether you understand the code being generated (not just HTML/XML/CSS...
this was using Ajax to run JavaScript on the client and C# as code-behind on
the server, all as re-usable components. The whole development environment
is visual. And the resulting site was just stunning. I reckon it would have
taken me about 4 days using DreamWeaver, 3 with VS 2008; they (MS) had it
running in under 3 hours, after fixing some server configuration problems
that all of us were quite relieved to see (it doesn't just happen to us :-))

Heck - I will do so fa as to say it is almost always the right thing to
do -
separating the two I mean.


A year or two back I would have emphatically agreed with you. Today, I'm a
bit more reticent. I'm all in favour of separation layers and have practiced
n-tier designs for around 15 years now. My reservation comes when you
combine data access layers and business logic as part of your "back end" and
then say :"Well, at least we have separated the user interface from the
grunt work..." :-) (This is definitely better than NOT separating it, but I
think it needs to go a bit further than that.) For me, it is about re-usable
components with consistent interfaces, embedded into an n-tier design.




Not if even if they know how to interface to MS SQL
Server. :)

COBOL people, on the other hand, tend to come in, figure out *why*
something
works, then *how* it works, and come up with elegant and cost effective
ways
to make things happen. Even fancy things like very complex web based
interfaces.

Oh man, I really wish... :-)



Let me rephrase that just slightly - average joe COBOL programmers tend
to
do
absolutely brilliant jobs in that environment, at least they do if they
are
nurtured a bit.

ANY technical person will do a better job in any environment if they are
"nurtured" a bit... :-)

"Brilliant" web designers tend to be more artist than engineer or
scientist.
They don't do so well in situations were ideas have to be turned into
engineering reality.

I disagree. But it is a generalization anyway so very difficult to prove
or
disprove.


That's true, nd it is a generalization. But it is far from difficult to
find
enough evidence to build a compelling case. Look at the difference between
say, lawyers and physicists. Subjects roughly the same level of
complexity,
but totally different mind sets and points of view. :)

Sorry, I see no relevance for this discussion between lawyers and
physicists... whole different ball game.

Or on a more mundane scale - say musicians and software engineers. Two
people
might be equally brilliant, but think in ways very alien to each other.

Certainly, the ways that people think and perceive are very subjective, but
that doesn't prevent a software engineer becoming an accomplished pianist or
mountaineer... There is no "right" way to think... contrary to what certain
historical figures may have insisted to be the case... :-) You either
succeed or you don't... as Master Yoda famously remarked: "Do or do not.
There is no try..." :-)

Experienced COBOL (or Assembler, or C, or Pascal, or...) software people
are
as different from the average experienced Web Designer as night and day.
:)

Not if they habitually build Web sites they're not. You seem to be persuaded
that skill sets are mutually exclusive. My own experience tells me they are
not. Yes, there is a famous psychological theory called interference, which
says (loosely) that when you acquire new skills you lose old ones. But this
theory is controversial and not fully validated. There are some skill sets
which, if you don't practise them, you lose them.(Whether you acquired new
ones or not...) I find if I don't play complex pieces of music for a while I
have to go back to the *** music and refresh my memory, for example.

As I said in my previous post, people can acquire skill if they are
motivated and have ability and application. They fact that many people do
not, is because they try, fail, and quit. In other words, the necessary
degree of application, motivation, and ability is not present.





OO concepts are not really anything new if you present them right. In
fact,
in plain simple truth, the best OO ideas are nothing more than the
distilled
wisdom of practical software programmers, engineers, and managers.
There
never has been anything revolutionary about it.

Yes and no. I had great difficulty in picking up these concepts when I
first
tried to do so via OO COBOL. I can relate to others having the same
trouble.
However, when I put COBOL down and looked at a "new" language which was
based on OO concepts, as if I had never programmed a computer before, it
all
clicked into place pretty quickly. I then went back to OO COBOL and had
no
further problems with it.


Yes, I had a similar experience. I think OO Cobol is a disaster
personally.
Reminds me of certain appendages connected to a bull....

It is a tragedy, in my opinion. The "affixing" of OO facilities into
standard COBOL is an incredible feat of software engineering. I have nothing
buit respect and admiration for the people who did it. Unfortunately, they
overestimated the perspicacity of the market they did it for.

COBOL wasn't destroyed by the vendors. It was the users and the pathetic
standards process... don't start me...:-)

It's all water under the bridge now, and I am calm. :-)


There are a number of conceptual differences between the procedural and
OO
paradigms. I already covered why this is difficult for many COBOL
programmers.


Smoke and mirrors Pete. When you get under the covers of any OO concept,
you
discover the techniques used to implement it and discover the concept is
not
so different after all.

If you really believe that then you haven't grasped the full implications of
Object Orientation. Sorry.

It is NOT smoke and mirrors, there are real benefits that cannot be achieved
by other methodologies. It isn't just about the mechanics of HOW it is
implemented, it is about WHAT you can do with it. However, I have promised
myself not to debate it here any more so I won't. No minds will be changed
(and actually, I don't care whether they are or not; as I have stated here
many times, I'm not on commission for OO approaches and I'm certainly not an
Evangelist for anything. It works for me and has revolutionised the way I
develop and the costs of development. It gave me components, and those are
the Keys to the Kingdom. Infinitely more than called modules could ever be.
I'm very happy with it. (Looking around... so is most of the rest of the
world... :-)), and it is therefore pointless for us to argue.

Even concepts like inheritance map back to the black box state machine
design
that IBM came up with after the disastrous MVS cost and schedule overruns.

So? It doesn't matter WHERE inheritance was developed from or how it came
about. It is what you can do with it that matters.

We can play back and forth with specifics if you wish. But I doubt we
woudl
convince each other of much of anything! :)

Precisely. See my comments above. Analysing the mechanics of OOP and saying
it is grounded in non-OO techniques, may well be true, but it misses the
point of using OO approaches.


The times I have seen COBOL programmers get into trouble with
understanding
OO have been when the "teacher" is a zealot for whatever methodolofy of
the
day they are pushing.

-)

No comment... Feedback on my courses was very positive... :-)


I doubt you fit into the zealot mode. Ed Yourdon came close at one point,
but
fortunately regained his senses. :)


Smalltalk, for instance. Or Java, or Oberon, or
Microsoft .NET. (Boy, those .NET guys will tell you Microsoft invented
the
whole idea!! Swear on a stack of bibles no less... :)

As I was programming computers before MicroSoft was incorporated, I tend
to
keep an even keel on this one. Besides, I was brainwashed by IBM in my
youth
so there isn't much chance of anyone else getting much of a look-in... My
personal preference is for the .NET environment but that is mainly
because I
have found it to be productive. I long ago gave up getting emotional
about
computer software, hardware, or environments. You might as well fall in
love
with the toaster... :-)

LOL! Agreed.

Anyway, you are right that there is resistance to change, but it is
often -
though not always - a sensible and well reasoned resistance. "Oh, we can
replace that mainframe over there, with 3000 individual PC's all running
Visual Basic applications that talk clientserver to a MS SQL database."

I swear, I head that exact sentence from an arrogant idiot one time.

Does the phrase "wind up" (as in compressing clockwork) mean anything to
you, Paul... ? :-)


When I
asked how he planned to deploy something like that - he actually
simpered
and
snickered and said -"well- that s *your* job isn't it?"


"Do not go gentle into that good night.
Rage, rage against the dying of the light."


Oh I went raging into the night, and with the coming of the morning light
had
a completely new proposal, one that did not include that simpering idiot!
:)


Unfortunately, as Dylan Thomas found, you can scream and yell all you
like
about the decline of the light, but entry into Darkness is inevitable.


The same poem also has this to say:

Wild men who caught and sang the sun in flight,
And learn, too late, they grieved it on its way,
Do not go gentle into that good night.





So will it be with COBOL.


Perhaps - but I doubt it will be in my lifetime. Or at least before I
retire
in another 12 years or so. :)

Best bet is to look for a decent flashlight... :-)

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







.