Declining Cobol job market

<docdwarf@panix.com> wrote in message news:g95jm9$k9h$1@reader1.panix.com...
> In article <nvtbb4df0274jo54pbau02ri2r7a6dof5q@4ax.com>,
> Robert <no@e.mail> wrote:
>
> [snip]
>
>>Last week a recruiter said a place might take six weeks to make a
>>decision. I responded,
>>"they've created a filter that insures the person they hire will be one
>>who cannot find a
>>job in six weeks."
>
> I've had those... 'they love you, they want you, they need you but... they
> won't be ready for you for (n) weeks.'
>
> 'That's all right... as long as their checks clear the bank for the next
> (n) weeks I'll be happy to accomodate their schedule.'
>
> 'Checks? They're not going to pay you, they just want you to wait.'
>
> 'They want me to dedicate my time to fulfilling their business requirement
> of starting in (n) weeks... and not get paid for it? I can't do that...
> but I'm willing to compromise, I'll take three-quarters of my rate for
> theo waiting period.'
>
> 'No... they just want you to wait, do nothing... and not get paid.'
>
> 'Oh... well, they're offering an n-month contract, let's add in the lost
> earnings into the projected total and raise the rate to make up for it.'
>
> 'You can't do that... I agreed to a rate!'
>
> 'You may have agreed to a rate... I can't agree to waiting six weeks
> without pay. You want something with that kind of flexibility call a
> car-rental office; Avis is listed on the stock-exchange... I'm not.'
>
> DD
>
Amen!

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

On Fri, 29 Aug 2008 02:40:59 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:


>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.)
>
>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.

And I know people who use CoBOL professionally who don't understand
the underlying/generated machine language... not that it really
matters anymore.

And I think this point is not only very important, but it is a basis
for much of the criticism that older generations have for newer
generations work. We *want* our old skills to matter more.

....

>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... :-)

In this case, I can better understand being brainwashed to do things
IBM's way than Microsoft's way. In both cases, we had the tools to
do our job - but it is more obvious now that platforms should not
matter. It is more obvious now that being locked into one vendor's
product can be costly.

I prefer to give up some power for flexibility.

(getting back - I think - to the original topic),

As someone who is "happily disabled" and getting paid NOT to work for a living
<G>, I am not certain of what the status is of what I am about say. However,
from the input that I receive in other places, I think it is.

It seems to me that if you live in the US, Western Europe, or ANZAC/Japan
("industrial Pacific Areas - whatever that is now generalized as), that there
ARE COBOL "jobs". The number may be declining but not as much as some within
this forum would suggest. HOWEVER, such jobs are:

- for full time employees
- annual salaries that are NOT comparable (even with benefits) to "previous
COBOL contract" work
- often with Mainframe (or similarly "not glitzy") skills required
- may require living in "other areas" and may not (initially) allow for
telecommuting

I read into the original post (I may be mistaken - but don't think that I am)
that these restrictions were NOT acceptable to the poster - and I can certainly
understand that. However, I think there is a difference between "COBOL jobs
declining" (which is probably true any way you look at it) and "COBOL jobs that
meet my requirements - that I used to be able to meet - are declining".

P.S. It often surprises me how this forum is dominated by "contractors" rather
than full-time employees. (There certainly are some of the latter, but not a
percentage that I think reflects employed COBOL programmers.) I can think of
several reasons for this, but that is another thread ... (note subject line of
this note matches the actual content <G>)

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

"Howard Brazee" <howard@brazee.net> wrote in message
news:i1idb4taqqtg1hljse3s29066um2p6l25i@4ax.com...
> On Fri, 29 Aug 2008 02:40:59 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
>>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.)
>>
>>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.
>
> And I know people who use CoBOL professionally who don't understand
> the underlying/generated machine language... not that it really
> matters anymore.
>
> And I think this point is not only very important, but it is a basis
> for much of the criticism that older generations have for newer
> generations work. We *want* our old skills to matter more.
>
> ...

A very good point, Howard. I agree.
>
>>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... :-)
>
> In this case, I can better understand being brainwashed to do things
> IBM's way than Microsoft's way. In both cases, we had the tools to
> do our job - but it is more obvious now that platforms should not
> matter. It is more obvious now that being locked into one vendor's
> product can be costly.
>
> I prefer to give up some power for flexibility.

I think most people do... especially in a market that changes rapidly and
frequently.

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

On Thu, 28 Aug 2008 09:40:59 -0500, Pete Dashwood wrote
(in article <6hnrnpFn895uU1@mid.individual.net>):

>
>
> "PaulR" <paul.raulerson@gmail.com> wrote in message
> news:0001HW.C4DB87AB00094E66B01AD9AF@news.suddenli nk.net...
>> On Wed, 27 Aug 2008 18:15:13 -0500, Pete Dashwood wrote
>> (in article <6hm5g2FmvtrfU1@mid.individual.net>):
>>
>>>
>>>
>>> "PR" <paul.raulerson@gmail.com> wrote in message
>>> news:e41e894f-f8aa-4e3f-9b6b-932190cacd0d@8g2000hse.googlegroups.com...
>>> On Aug 25, 11:04 pm, Robert <n...@e.mail> 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.


>
> 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. :/


>>
>> 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. (?) I disagree.

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

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.

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


>
>> 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.

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.

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


>>
>> 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....

> 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.

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.

We can play back and forth with specifics if you wish. But I doubt we woudl
convince each other of much of anything!
>>
>> 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."
>
>
>

"PaulR" <paul.raulerson@gmail.com> wrote in message
news:0001HW.C4DCF0390018373EB01AD9AF@news.suddenli nk.net...
> On Thu, 28 Aug 2008 09:40:59 -0500, Pete Dashwood wrote
> (in article <6hnrnpFn895uU1@mid.individual.net>):
>
>>
>>
>> "PaulR" <paul.raulerson@gmail.com> wrote in message
>> news:0001HW.C4DB87AB00094E66B01AD9AF@news.suddenli nk.net...
>>> On Wed, 27 Aug 2008 18:15:13 -0500, Pete Dashwood wrote
>>> (in article <6hm5g2FmvtrfU1@mid.individual.net>):
>>>
>>>>
>>>>
>>>> "PR" <paul.raulerson@gmail.com> wrote in message
>>>> news:e41e894f-f8aa-4e3f-9b6b-932190cacd0d@8g2000hse.googlegroups.com...
>>>> On Aug 25, 11:04 pm, Robert <n...@e.mail> 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 sheet 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."
>>
>>
>>
>
>

On Thu, 28 Aug 2008 19:55:23 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>P.S. It often surprises me how this forum is dominated by "contractors" rather
>than full-time employees. (There certainly are some of the latter, but not a
>percentage that I think reflects employed COBOL programmers.) I can think of
>several reasons for this, but that is another thread ... (note subject line of
>this note matches the actual content <G>)

One reason is that contracting puts workers in a variety of
environments. Contractors see new ways of doing things and have to
adjust. Contractors also are less likely to seek advice from the
people they work for, and seek elsewhere for their long-term business
contacts.

Since many companies like to keep their employees working in a single
predictable niche, it is easy to get comfortable not stretching too
much while waiting to retire.

On Thu, 28 Aug 2008 19:55:23 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>(getting back - I think - to the original topic),
>
>As someone who is "happily disabled" and getting paid NOT to work for a living
><G>, I am not certain of what the status is of what I am about say. However,
>from the input that I receive in other places, I think it is.
>
>It seems to me that if you live in the US, Western Europe, or ANZAC/Japan
>("industrial Pacific Areas - whatever that is now generalized as), that there
>ARE COBOL "jobs". The number may be declining but not as much as some within
>this forum would suggest. HOWEVER, such jobs are:
>
> - for full time employees
> - annual salaries that are NOT comparable (even with benefits) to "previous
>COBOL contract" work
> - often with Mainframe (or similarly "not glitzy") skills required
> - may require living in "other areas" and may not (initially) allow for
>telecommuting

I was referring to non-mainframe jobs. The other three factors do not apply. My sources,
primarily indeed.com, show permanent as well as contracting positions. I'm not rooted to
one city.

>I read into the original post (I may be mistaken - but don't think that I am)
>that these restrictions were NOT acceptable to the poster - and I can certainly
>understand that. However, I think there is a difference between "COBOL jobs
>declining" (which is probably true any way you look at it) and "COBOL jobs that
>meet my requirements - that I used to be able to meet - are declining".
>
>P.S. It often surprises me how this forum is dominated by "contractors" rather
>than full-time employees. (There certainly are some of the latter, but not a
>percentage that I think reflects employed COBOL programmers.) I can think of
>several reasons for this, but that is another thread ... (note subject line of
>this note matches the actual content <G>)

On Aug 27, 7:15*pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "PR" <paul.rauler...@gmail.com> wrote in message
>
> news:e41e894f-f8aa-4e3f-9b6b-932190cacd0d@8g2000hse.googlegroups.com...
> On Aug 25, 11:04 pm, Robert <n...@e.mail> wrote:
>

[PR]
> 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..
>

Why? Answer: If it is needed to create sufficient _intersection_
(overlap of knowledge among stakeholders) "to get the job done", a
matter of great interest to PR and Robert, as indicated by their
posts.

I'd settle for just a bit more willingness to listen to the CoBOL
folks, let alone asking them to "learn COBOL".

A simple anecdote illustrates...

I was working as a QA/Tester on a rather large point-of-sale (POS)
systems development project. It was to be a procurement in the
hundreds of millions of dollars, both hardware and software, for a
national market.

The system was being written in C++ (this was about 1998 or so), and
the development group was maybe forty or so programmers, designers,
team leads, and database people. Ostensibly O-O, they did the O-O
"design" at the end of the project, after the client (a quasi-
government agency) insisted upon it. So I suppose the project had a
bit of the cowboy "let's just start writing the code" type of flavor.
I know that I had the honor of logging the 10,000th defect against the
system, reflecting a "let's just throw it over the wall to the
testers" type of attitude one might expect under those circumstances.

To the CoBOL aspect of this... the client had a requirement, a natural
one, that the system be able to interface with their National office,
dumping the day's financial transactions and totals into their
Centralized Accounting System (let's call it CAS). For this
requirement, the C++ team had specification of the record layout, and
the field names, and the field data types, which were described in
Picture notation. No binaries or even Comp-3's were required. Only
straight text of X(n)'s and some numeric pics, but some were signed.

Well, the positive numbers went through just fine. But the
"negatives", reflecting "credits" or "adjustments" (in accounting
lingo) sent over resulted in the client CAS people observing that the
file was causing abends in CAS. I logged it as a defect in the defect
tracking system, but it wound up being "closed invalid" or "closed, no
change required" because the C++ Team Lead insisted that a visual
inspection of the file showed that the minus ("-") sign was indeed
present in the file layout according to the field specification.

I protested - but you must TALK with the CAS people to find out more!
Their program was abending! Yes, a sign is required, but in CoBOL the
sign may be SEPARATE, and if SEPARATE, it may be LEADING, or TRAILING.
If not SEPARATE, you may need to send the sign as an "overpunch"
character.

And yes, what I was saying might as well have been written in Sanskrit
for all that I was listened to, which was not at all. There were other
more pressing bugs to fix than this one, final user acceptance testing
was still some months away, and the Team Leads, junior to me in age
and experience, but senior in authority and in C++ experience, just
blew the whole thing off.

I'm sure it was worked out eventually, after I was gone. For all I
know, the CAS people modified their program, or changed the compiler
default with a compiler directive override, to make the processing
agree with what the POS system was sending to CAS.

So let me offer CLC another single data point - my own experience is
that CoBOL folks are more receptive to learning from the new folks
than the new are receptive to learning from the old.
But after all, I am only a single data point. It is up to the Reader
to do the full integration of views and arrive at his own conclusions.

Ever the optimist, I look forward to an imminent change in my own
organization where I will be working with (for) someone younger who is
more familiar with the new technologies. Already I feel that he is
listening to me. This holds promise of being a really good thing,
where each of us can learn a lot from each other.

Ken

On Aug 27, 11:37*pm, PaulR <paul.rauler...@gmail.com> wrote:
> On Wed, 27 Aug 2008 18:15:13 -0500, Pete Dashwood wrote
> (in article <6hm5g2Fmvtr...@mid.individual.net>):
>
>
> > "PR" <paul.rauler...@gmail.com> wrote in message
> >news:e41e894f-f8aa-4e3f-9b6b-932190cacd0d@8g2000hse.googlegroups.com...

> > On Aug 25, 11:04 pm, Robert <n...@e.mail> wrote:
>
> 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 believe it worthwhile to try to differentiate between skepticism and
resistance. Have we not all been exposed to the situation to the
huckster who sells the client some newfangled thing that doesn't just
work out? And understanding the fact that the newfangled thing does
not get purchased in isolation, but enters a "context" of people,
hardware, users, and installed base, means that assessing the
appropriateness of the newfangled thing in that context is a non-
trivial task, requiring much judgment and experience.

>
> I swear, I head that exact sentence from an arrogant idiot one time. WhenI
> asked how he planned to deploy something like that - he actually simperedand
> snickered and said -"well- that s *your* job isn't it?"- Hide quoted text-

Under these circumstances, it is well to ask oneself, "Just what _is_
the agenda of this manager?" Could be, his Agenda does not offer
sufficient Intersection with the Project to make it a success. It may
make him rich, or offer him a promotion out before the sh*t hits the
fan, however.

Ken