Coming soon: Turbo COBOL from Micro Focus :-)
Pete Dashwood
took the choice bits).
http://www.sdtimes.com/link/33459
I always had a soft spot for Borland. Sorry to see them go.
Pete.
--
"I used to write COBOL...now I can do anything."
paolor...@gmail.com
I thought VisOCOBOL was Turbo COBOL!
I agree with you about Borland, Pete. They brought excellent value
compilers in C, BASIC, C++ and Pascal to 'the masses', along with an
excellent text mode windowing library known as TurboVision. I still
have these compilers and am still using them. For me, Delphi was one
of the best RAD tools for Windows with an elegantly designed OO
version of Pascal known as Object Pascal.
Paul - Melbourne, Australia.
Rene_Surop
better (or it may bring downward trend, IF they bought a bad apple).
Stephen Kelly first came into the picture by acquiring AccuCobol, and
stepping up until then. I would personally think that in this time of
financial crisis, their acquisition will put them later in an
excellent position.
It's really a game of chess in business. I could probably say it is
right, maybe if MF will try to think of Turbo COBOL... and offering it
for free, then it will be a Cobol Rocks The World 'again'.
Pete Dashwood
The COST of a COBOL compiler is a contributing factor to COBOL's decline,
but it is not a major factor. (The OVERALL cost or "cost of ownership" when
you consider what it costs to maintain procedural code as opposed to
maintaining object oriented components, IS an important factor. The point is
that if they gave it away it still wouldn't change perception or reality.)
Much more important reasons are that the COBOL paradigm is of limited
relevance in today's environments, and the fact that other languages
(whether we like to admit it or not) are simply better suited to Network
programming. You can argue that COBOL is well suited to a centralized batch
processing environment (and you'd be right...), you can argue that COBOL can
do what many of the newer languages can do (and you'd be right again, but
now you are on a sticky wicket because being able to do something and being
able to do it efficiently, quickly, cheaply, and easily, are two importantly
different considerations), or you can argue "Well, I've always used COBOL
and everything I want to do I can do in COBOL" and it becomes apparent that
you have limited horizons and are not really interested in modern computing,
or even getting the maximum and best from COBOL. (That, of course, is a your
prerogative and a perfectly valid choice; my comment was not intended to be
judgemental...)
I have a friend who learned BASIC for the Sinclair Spectrum (taught
himself... a true enthusiast). When he found he could use BASIC on his PC
he was delighted. But he still expects things to work as they did on his
Sinclair Spectrum... He has never moved on to Visual Basic and so he can
never move on to .NET. The concepts of objects and components are just
mysterious and confusing to him. (Yet he is far from being an idiot...) He
told me the last time I saw him that he was going to get into Web
programming because he found the desktop so limited... I hope he does. Doing
so will expand his BASIC horizons as well.
The existing COBOL codebase cannot guarantee COBOL jobs indefinitely. COBOL
programmers need to use this breathing space to expand skill sets, and add
more tools to the toolbox.
BTW, Rene, I am not sure if private mail I sent you was received. Can you
check please? May have been thrown in the junkmail folder... :-)
William M. Klein
"> The COST of a COBOL compiler is a contributing factor to COBOL's decline,
> but it is not a major factor. (The OVERALL cost or "cost of ownership" when
> you consider what it costs to maintain procedural code as opposed to
> maintaining object oriented components, IS an important factor. The point is
> that if they gave it away it still wouldn't change perception or reality.)"
I think that the original Fujitsu V3 "free COBOL" that INCLUDED "OO COBOL" (at a
time whether there were both more COBOL applications and more programmers)
pretty well "proves" that NEITHER the paradigm nor the cost is what did kill (or
is killing) COBOL.
It is SO much perception *and* the fact that "converting" existing procedural
COBOL to OO COBOL is usually "not viable" (Why fix it, if it isn't broken).
This meant that existing programs and programmers never (seriously) considered
the conversion (or retraining) and that the "new COBOL" was not of interest to
"new programmers".
(Gross generalization in above statement, but the "general" view is what I think
did happen) Perception matters; actual availability and functionality is almost
in "last place" when selecting a programming language (especially for "new"
programmers).
--
Bill Klein
wmklein <at> ix.netcom.com
rip...@azonic.co.nz
wrote:
> re:
> "> The COST of a COBOL compiler is a contributing factor to COBOL's decline,
>
> > but it is not a major factor. (The OVERALL cost or "cost of ownership" when
> > you consider what it costs to maintain procedural code as opposed to
> > maintaining object oriented components, IS an important factor. The point is
> > that if they gave it away it still wouldn't change perception or reality.)"
>
> I think that the original Fujitsu V3 "free COBOL" that INCLUDED "OO COBOL" (at a
> time whether there were both more COBOL applications and more programmers)
> pretty well "proves" that NEITHER the paradigm nor the cost is what did kill (or
> is killing) COBOL.
>
> It is SO much perception *and* the fact that "converting" existing procedural
> COBOL to OO COBOL is usually "not viable" (Why fix it, if it isn't broken).
Not only that, but the OO features in C++ fixed problems in C that
were not a problem in Cobol or in the applications that were written
in Cobol.
For example OO caters for a class to create multiple objects, but
Cobol applications generally deal with one object and serially reuse
it. eg in processing transactions each could be created as an object
of the transaction class _or_ just have a transaction record area and
read each transaction into that one at a time.
As it happens I have found uses for OO Cobol. In using templates I
call a template program passing the array of name/value pairs to
merge. The template program only supports a single output stream at a
time. Implementing this as OO and having the templating as a class
means that several template streams can be created at the same time
without complications that would be caused in non-OO.
Or just output each template completely and then reset and output the
next stream.
Pete Dashwood
> re:
> "> The COST of a COBOL compiler is a contributing factor to COBOL's
> decline,
>> but it is not a major factor. (The OVERALL cost or "cost of
>> ownership" when you consider what it costs to maintain procedural
>> code as opposed to maintaining object oriented components, IS an
>> important factor. The point is that if they gave it away it still
>> wouldn't change perception or reality.)"
>
> I think that the original Fujitsu V3 "free COBOL" that INCLUDED "OO
> COBOL" (at a time whether there were both more COBOL applications and
> more programmers) pretty well "proves" that NEITHER the paradigm nor
> the cost is what did kill (or is killing) COBOL.
I disagree, but I enjoyed your post and I don't disagree as vehemently as
you might think :-)
At the time the V3 COBOL was made available Micro Focus had just stranded
the VisOC user base and withdrawn support for a product that people were
just starting to take an interest in. Fujitsu were quick to fill the gap,
and I, for one, was surprised by the quality of their product.
I have never had a beef with Fujitsu products; they have invariably been of
the highest standard. They suffered from bad English documentation, but that
was fixed. The rot set in when the American company laid off the people who
had provided fantastic support and replaced them with people who were
useless, and then went on to use the pointless remote registration scheme
which was supposed to protect against piracy but just caused inconvenience
and worry and succeeded in alienating much of what remained of the user
base. Honest users were unable to make copies of a mission critical software
development system.
And it meant your business was in the hands of the Casper system running
(hopefully) on a remote server somewhere in the USA. I say it was pointless;
it can be circumvented in minutes by anyone using modern techniques and
tools. If I WANTED to make a living out of pirating Fujitsu COBOL (hollow
laughter... like, who would want it?) I could produce as many unlocked
copies as I wanted to. I haven't and I wouldn't. But the fact that I can be
trusted (just like most of the professional user base) apparently cuts no
ice with Fujitsu.
> It is SO much perception *and* the fact that "converting" existing
> procedural COBOL to OO COBOL is usually "not viable" (Why fix it, if
> it isn't broken).
I absolutely agree that perception is a major player here. And I agree with
you that most COBOL sites "strongly resisted" the advent of OO COBOL. The
trouble is that now awareness is rising and it is too late for COBOL. I am
less upset about "user resistance and apathy" than I was a few years back. I
take your point that if something is working it is very hard to persuade
someone to change it. (When a certain approach has been working for DECADES
it is even harder. It requires imagination, knowledge of the industry, and
vision.) Nevertheless, it wouldn't have hurt to run a few pilot projects and
invest in some training... And I still haven't forgotten the scorn and even
vitriol with which posts here suggesting OO might be important and worth
looking at were received. (It was the same with RDB... I should have learned
:-) )
Anyone who was looking at what was happening in the industry could have
foreseen that OO was going to be a major player, but instead the Priests of
COBOL hunkered down in their fortresses hoping that the barbarians would
ride on past them. Most of the Barbarians did. They realised that slow
moving, heavily armoured, COBOL knights on large warhorses were no match for
their agility and speed, and, besides, COBOL was sowing the seeds of its own
destruction, no innovation (actually, there WAS innovation and OO COBOL was
released by a number of vendors DESPITE it not being in the standard - the
user base just rejected it), and 17 years to agree a standard, so they left
them in their fortresses.
When the castle gates finally opened the inmates emerged to a changed world.
A world where their one true religion was largely irrelevant. Anything the
Knights of COBOL could do, the Barbarians could do faster, cheaper, and more
elegantly. (Except for one thing, which was being overtaken by events
anyway...) And they could do more besides. The landscape was irrevocably
changed, the villagers were going about their business WITHOUT having to
come cap-in-hand to the COBOL priests, and a whole new attitude in a whole
new generation was coming on.
> This meant that existing programs and programmers
> never (seriously) considered the conversion (or retraining) and that
> the "new COBOL" was not of interest to "new programmers".
>
If the sites they were working on had been seriously investigating it, it
would have been seriously considered by "new programmers".
I don't think programmers were entirely to blame; there was a considerable
amount of short-sighted management around as well. I don't think anyone
maliciously neglected to further their training; it was more as you say: "If
it ain't broke, don't fix it."
Sadly, the pigeons are now coming home to roost. In just 15 years we have
seen the erosion of COBOL jobs and use of the language itself to the point
where no-one could seriously consider embarking on a career as a COBOL
programmer today.
The remaining future for COBOL programming is in leveraging it into the 21st
century. We are six years away from 2015 and, I have to say, what I am
seeing and hearing leads me to believe my prediction may have been generous;
I do not know of a single COBOL site (admittedly, my sample is small) that
plans on keeping COBOL as the major development language into the future.
Most sites still running COBOL are doing so because what they have works and
they are unsure of how to migrate or phase it out. Ask any COBOL IT manager:
"If someone came along with a magic bullet that could move all of your
applications into a distributed, component based, environment, like the
Internet or .NET, and allow your existing COBOL to run with other languages
in that environment, so you were no longer exclusively tied to COBOL, would
you take it?" See how many say: "No thanks, we're staying with COBOL..."
> functionality is almost in "last place" when selecting a programming
> language (especially for "new" programmers).
Fortunately the new breed are much more aware. They need to know more and
they do. The ones I have worked with have impressed me no end. These people
are quite happy to write a script, tailor a package with Java or C#, or pick
up some legacy COBOL processing and rebuild it in something else. They do
whatever needs to be done to get a result and they don't see everything as a
"nail". They are not obsessed by tools or ONE tool. If they have a "faith"
it is in objects and layers. Re-use and separation.
To most of them COBOL is a "quaint" and troublesome antiquity. They rebuild
code because they don't realise it can be salvaged. They never heard of OO
COBOL (and given the attitude to it in the COBOL community, who can blame
them?)
I am hoping to change some of that.
The best people to refactor COBOL code are COBOL programmers with a
knowledge of the business and the system . But if everyone believes the
existing code is a millstone and needs to be discarded, instead of an asset
that can be refactored and revalued, those people are not going to be around
very long. Point your colleagues at the COBOL 21 web site. Get your manager
to realise that COBOL, even legacy COBOL can be valuable. Make the point
that COBOL objects are valid objects and can play nicely with other objects.
If some of the team are C# people, get them to download the latest
string2num component which has a C# interface to make it easy to use in C#
as well as COBOL. (I have been very pleasantly surprised to see that in the
last week 26 people have downloaded this component, and 3 times that number
have visited the page and played with the component on-line. Overall the new
site has taken 130 unique hits during the week. Considering it is still
under construction in places, this is very encouraging.)
It is criminal to waste billions of lines of code because nobody knows it
can be refactored into objects.
Howard Brazee
<dash...@removethis.enternet.co.nz> wrote:
>The COST of a COBOL compiler is a contributing factor to COBOL's decline,
>but it is not a major factor. (The OVERALL cost or "cost of ownership" when
>you consider what it costs to maintain procedural code as opposed to
>maintaining object oriented components, IS an important factor. The point is
>that if they gave it away it still wouldn't change perception or reality.)
I'm disappointed in that "Total Cost of Ownership" doesn't seem to get
analyzed sufficiently. Instead "costs that go against my budget" are
much more important in decision making.
One reason it is so easy to find Java programmers, is that Java
programming has a low cost of entry. Shops don't need to worry about
finding Java programmers, and training costs seem minimal.
Same thing with hardware. Mainframe makers need to price their
products more obviously based upon usage, so that mainframes compete
with "just add another server". But that doesn't help when a
company can test out a service really cheaply without making a
commitment to upgrade later, unless that service is easy to add onto
the mainframe.
--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."
- James Madison
Howard Brazee
<dash...@removethis.enternet.co.nz> wrote:
>Anyone who was looking at what was happening in the industry could have
>foreseen that OO was going to be a major player, but instead the Priests of
>COBOL hunkered down in their fortresses hoping that the barbarians would
>ride on past them.
I don't think it was the Priests so much as the congregations. My
job is comfortable doing what I'm doing now, why should I make things
difficult on my co-workers by researching how to get an OO program
through Endevor and the process - and then having other CoBOL
programmers not know how to maintain it? I'm just here until
retirement - or maybe I'm a contractor with limited authority and
freedom to vary from de-facto standards.
>Most of the Barbarians did.
That tends to be how revolutions happen.
Bill Gunshannon
Howard Brazee <how...@brazee.net> writes:
> On Tue, 12 May 2009 00:01:50 +1200, "Pete Dashwood"
> <dash...@removethis.enternet.co.nz> wrote:
>
>>Anyone who was looking at what was happening in the industry could have
>>foreseen that OO was going to be a major player, but instead the Priests of
>>COBOL hunkered down in their fortresses hoping that the barbarians would
>>ride on past them.
>
> I don't think it was the Priests so much as the congregations. My
> job is comfortable doing what I'm doing now, why should I make things
> difficult on my co-workers by researching how to get an OO program
> through Endevor and the process - and then having other CoBOL
> programmers not know how to maintain it? I'm just here until
> retirement - or maybe I'm a contractor with limited authority and
> freedom to vary from de-facto standards.
>
>>Most of the Barbarians did.
>
> That tends to be how revolutions happen.
Or maybe the the Priest actually saw that the emperor really had not clothes
on at all!! I know some really large COBOL shops. None of them sees any
reason why they should change all that existing COBOL to anything OO. And
that even with the local academics all shouting as loudly as they cane that
"COBOL is dead, long live OO!!"
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
William M. Klein
--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dash...@removethis.enternet.co.nz> wrote in message
news:76qidgF...@mid.individual.net...
<snip>
>
> The remaining future for COBOL programming is in leveraging it into the 21st
> century. We are six years away from 2015 and, I have to say, what I am seeing
> and hearing leads me to believe my prediction may have been generous; I do not
> know of a single COBOL site (admittedly, my sample is small) that plans on
> keeping COBOL as the major development language into the future. Most sites
> still running COBOL are doing so because what they have works and they are
> unsure of how to migrate or phase it out. Ask any COBOL IT manager: "If
> someone came along with a magic bullet that could move all of your
> applications into a distributed, component based, environment, like the
> Internet or .NET, and allow your existing COBOL to run with other languages in
> that environment, so you were no longer exclusively tied to COBOL, would you
> take it?" See how many say: "No thanks, we're staying with COBOL..."
>
<snip>
Pete,
I wish that sometime you could visit SHARE (IBM mainframe user group). I
think you would be surprised how many fortune 500 companies (in the US) see the
mainframe as PART of their future - and included in this is COBOL. Things like
XML COBOL with and without SOA, CICS, etc are where LOTS of new development is
being done.
I know that DD, Arnold, Howard and a few other contractors who work with IBM
mainframe COBOL post in this forum. However, I do think that this part of the
existing COBOL base is significantly "under-represented" in comp.lang.cobol.
It may (or may not) be true/representative, but using "Usenet" (or even other
web based) "forums for discussing programming and language issues is NOT in the
"toolbox" of most of those in the environments where COBOL does still thrive.
It is also my impression that most of the shops doing major NEW development in
COBOL use "employees" and not contractors. This is another reason they are
under-represented in this forum.
I don't want to give the impression that I think that COBOL is always (or even
usually) the language of choice for new development in any environment.
HOWEVER, I do think that there is significant COBOL development being done - in
an environment that is NOT visible in comp.lang.cobol.
Howard Brazee
<wmk...@nospam.ix.netcom.com> wrote:
>I know that DD, Arnold, Howard and a few other contractors who work with IBM
>mainframe COBOL post in this forum. However, I do think that this part of the
>existing COBOL base is significantly "under-represented" in comp.lang.cobol.
I think a high percent of mainframe CoBOL programmers have limited
interest in exploring possibilities of the language - they are much
less likely to join a forum such as this. Those who have enough
interest to join are more likely to try new things. (Or those with
freedom to try new things may be more likely to be interested in
them).
Pete Dashwood
> In article <rcgg05p469rciao37...@4ax.com>,
> Howard Brazee <how...@brazee.net> writes:
>> On Tue, 12 May 2009 00:01:50 +1200, "Pete Dashwood"
>> <dash...@removethis.enternet.co.nz> wrote:
>>
>>> Anyone who was looking at what was happening in the industry could
>>> have foreseen that OO was going to be a major player, but instead
>>> the Priests of COBOL hunkered down in their fortresses hoping that
>>> the barbarians would ride on past them.
>>
>> I don't think it was the Priests so much as the congregations. My
>> job is comfortable doing what I'm doing now, why should I make things
>> difficult on my co-workers by researching how to get an OO program
>> through Endevor and the process - and then having other CoBOL
>> programmers not know how to maintain it? I'm just here until
>> retirement - or maybe I'm a contractor with limited authority and
>> freedom to vary from de-facto standards.
>>
>>> Most of the Barbarians did.
>>
>> That tends to be how revolutions happen.
>
> Or maybe the the Priest actually saw that the emperor really had not
> clothes on at all!! I know some really large COBOL shops. None of
> them sees any reason why they should change all that existing COBOL
> to anything OO. And that even with the local academics all shouting
> as loudly as they cane that "COBOL is dead, long live OO!!"
>
> bill
That is an ostrich viewpoint, Bill.
My piece was written with a degree of tongue-in-cheek but I mostly believe
what I wrote.
The reality is that it IS difficult for people who have worked a certain way
for years to believe that something new could be better. Especially when
there have been "false alarms" over the years (who could forget "The Last
One" closely followed a few years later by "The Next One". :-)).
Your large shops who see no reason to change will be overtaken by events as
surely as the dinosaurs were overtaken by the comet. It will take time, but
it will happen.
Procedural COBOL has a very limited remaining life span and I'm not saying
this as an Academic; I'm saying it as one who has spent 40 years living and
working in the real workplace.
Inability to see the Emperor's new clothes does not mean that the Emperor is
naked.
Pete Dashwood
> Much snippage, but see comment to which I reply below
>
>>
>> the 21st century. We are six years away from 2015 and, I have to
>> say, what I am seeing and hearing leads me to believe my prediction
>> may have been generous; I do not know of a single COBOL site
>> (admittedly, my sample is small) that plans on keeping COBOL as the
>> major development language into the future. Most sites still running
>> COBOL are doing so because what they have works and they are unsure
>> of how to migrate or phase it out. Ask any COBOL IT manager: "If
>> someone came along with a magic bullet that could move all of your
>> applications into a distributed, component based, environment, like
>> the Internet or .NET, and allow your existing COBOL to run with
>> other languages in that environment, so you were no longer
>> exclusively tied to COBOL, would you take it?" See how many say:
>> "No thanks, we're staying with COBOL..."
> <snip>
>
> Pete,
> I wish that sometime you could visit SHARE (IBM mainframe user
> group).
I'd like that. :-)
> I think you would be surprised how many fortune 500
> companies (in the US) see the mainframe as PART of their future -
> and included in this is COBOL. Things like XML COBOL with and without
> SOA, CICS, etc are where LOTS of new development is being done.
OK.
>
> I know that DD, Arnold, Howard and a few other contractors who work
> with IBM mainframe COBOL post in this forum. However, I do think that
> this part of the existing COBOL base is significantly
> "under-represented" in comp.lang.cobol.
Why do you suppose that is, Bill?
Is there still a culture of non-Internet/Usenet awareness and the idea that
PCs are toys and only mainframes are "real" computers?
>
> It may (or may not) be true/representative, but using "Usenet" (or
> even other web based) "forums for discussing programming and language
> issues is NOT in the "toolbox" of most of those in the environments
> where COBOL does still thrive.
So what planet are these people living on? No wonder COBOL is a tiny
minority of the programming community.
>It is also my impression that most of
> the shops doing major NEW development in COBOL use "employees" and
> not contractors. This is another reason they are under-represented
> in this forum.
This forum is not exclusively populated by contractors. There are many
permanent employees who lurk here. Some of them don't post because they
don't want to be publicly identified by their Boss or colleagues. On
occasion I have urged people who contacted me privately to post here and
they won't. It is also interesting that of the considerable number of people
who have registered on the web site since we first published the cobdata
tool, only a handful are names I recognise from this forum.
I believe there are COBOL people who DO want to know. If they work on one of
the sites you are describing there is no incentive for them to expand their
horizons. It is "same old, same old" as long as the site management can get
away with it.
>
> I don't want to give the impression that I think that COBOL is always
> (or even usually) the language of choice for new development in any
> environment. HOWEVER, I do think that there is significant COBOL
> development being done - in an environment that is NOT visible in
> comp.lang.cobol.
I guess it depends what you mean by "significant". In the context of all the
programming going on in the world today it is NOT significant. This is a
marked change from 20 years ago when it WAS significant and 30 years ago
when it was major.
I accept what you say and I know there are big sites where change comes
slowly. Nevertheless, these sites are under mounting pressure to adapt and
their main justification at the moment is the huge volumes of batch
processing they carry out. Over time that will slowly dissipate as better
transactional processing is introduced. It won't happen overnight, but it
will happen.
Here's a fun idea: Copy my hypothetical question from the start of this
message and circulate it round the next SHARE meeting. Ensure that they can
respond anonymously and see what the response is. If it is an overwhelming:
"No, I'm sticking with COBOL" then I'll stand corrected (at least as far as
"mainframe heartland" goes...)
You might also encourage some of them to post here... :-)
Pete Dashwood
> On Mon, 11 May 2009 11:18:11 -0500, "William M. Klein"
> <wmk...@nospam.ix.netcom.com> wrote:
>
>> I know that DD, Arnold, Howard and a few other contractors who work
>> with IBM mainframe COBOL post in this forum. However, I do think
>> that this part of the existing COBOL base is significantly
>> "under-represented" in comp.lang.cobol.
>
> I think a high percent of mainframe CoBOL programmers have limited
> interest in exploring possibilities of the language - they are much
> less likely to join a forum such as this. Those who have enough
> interest to join are more likely to try new things. (Or those with
> freedom to try new things may be more likely to be interested in
> them).
Sadly, I think you're right.
Just look at all the fun they are missing! :-)
Pete Dashwood
> On Mon, 11 May 2009 15:38:12 +1200, "Pete Dashwood"
> <dash...@removethis.enternet.co.nz> wrote:
>
>> The COST of a COBOL compiler is a contributing factor to COBOL's
>> decline, but it is not a major factor. (The OVERALL cost or "cost of
>> ownership" when you consider what it costs to maintain procedural
>> code as opposed to maintaining object oriented components, IS an
>> important factor. The point is that if they gave it away it still
>> wouldn't change perception or reality.)
>
> I'm disappointed in that "Total Cost of Ownership" doesn't seem to get
> analyzed sufficiently. Instead "costs that go against my budget" are
> much more important in decision making.
Yes, I agree 100%. It is only at very senior management levels where they
can afford to sit back and look at the bigger picture, in my experience.
>
> One reason it is so easy to find Java programmers, is that Java
> programming has a low cost of entry. Shops don't need to worry about
> finding Java programmers, and training costs seem minimal.
>
I remember when COBOL was like that... :-)
> Same thing with hardware. Mainframe makers need to price their
> products more obviously based upon usage, so that mainframes compete
> with "just add another server". But that doesn't help when a
> company can test out a service really cheaply without making a
> commitment to upgrade later, unless that service is easy to add onto
> the mainframe.
All of these things will take their toll on committment to mainframe
technology. Still, you and I will be retired by the time it happens... :-)
William M. Klein
Good or bad (and I can certainly see the "bad" in it), for "large COBOL <IBM>
mainframe shops"
A) They have a community of COBOL programmers available to them "at work". This
is the place where they go with ideas and questions. (And, yes, this means that
the answers they get are from those who "think" the same way they do).
B) "If it ain't broke, don't fix it" means that existing (traditional)
procedural COBOL technology DOES meet the business needs that they receive as
"requirements" for programming.
C) Many (most? I don't know) "employees" see programming as a "9 to 5" (actually
a little more) JOB and they have minimal if any interest in pursuing it out of
"work". If they have the "skill set" to do what their current job requires, why
would they try and expand it?
NOTE: As before "generalizations" in the above, but my GUESS is this is "more
true than false" (and probably well over a simple majority).
--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dash...@removethis.enternet.co.nz> wrote in message
news:76rqgrF...@mid.individual.net...
docd...@panix.com
Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
[snip]
>Your large shops who see no reason to change will be overtaken by events as
>surely as the dinosaurs were overtaken by the comet. It will take time, but
>it will happen.
Something about 'all is vanity' was said three millennia and change back,
Mr Dashwood. Perhaps a re-reading of Shelley's 'Ozymandias' is in order,
especially for those who think others should despair.
DD
Pete Dashwood
> In article <76rp4fF...@mid.individual.net>,
> Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>
> [snip]
>
>> Your large shops who see no reason to change will be overtaken by
>> events as surely as the dinosaurs were overtaken by the comet. It
>> will take time, but it will happen.
>
> Something about 'all is vanity' was said three millennia and change
> back, Mr Dashwood.
Was it Ecclesiastes? I can't seem to find the Bible that is usually in the
Bookcase... Perhaps God is punishng my atheist persuasion... :-)
Perhaps a re-reading of Shelley's 'Ozymandias' is
> in order, especially for those who think others should despair.
How indeed are the Mighty fallen...
My message was not intended to be one of despair, however.
All things will pass in the fullness of time. But that is no reason to
ignore change, today.
Pete Dashwood
> Pete,
> Good or bad (and I can certainly see the "bad" in it), for "large
> COBOL <IBM> mainframe shops"
>
> A) They have a community of COBOL programmers available to them "at
> work". This is the place where they go with ideas and questions. (And,
> yes, this means that the answers they get are from those who
> "think" the same way they do).
> B) "If it ain't broke, don't fix it" means that existing (traditional)
> procedural COBOL technology DOES meet the business needs that they
> receive as "requirements" for programming.
Sure, I understand. You already pointed out the "circularity" in this.
There was a time when the general public didn't know much about computer
technology and left it to the Priests.
I remember a certain mainframe installation in the Midlands of England where
a middle manager innocently asked: "How come this multi-million pound
mainframe of yours can't put a signature on a letter when my son can do it
on his 600 pound Amiga?"
There was no way he would ever accept the standard answer that had been
acceptable up until that time: "Sorry, the computer can't do that".
A small empire had been built in this place by one technical expert who was
not used to having his authority questioned. He gave the stock answer noted
above. The manager insisted; the expert terminated the discussion.
Later I went and saw the expert. I asked why he wouldn't do it and he told
me the same story (he was unaware of my background and thought I was part of
a management team committed to introducing change into the organisation
(which I was)). I mentioned the capabilities of AFP on the mainframe and he
started taking notice. He promised to read the manual, just to get rid of
me. A few days later I asked him when he was going to implement AFP. He said
it was way too difficult, pleaded huge workload, all the usual baloney. I
threatened to write the code myself and shame him. By now he believed I
would (he was right...) so he reluctantly did it and the middle manager got
signatures on his letters.
The point is that it would never have happened if the middle manager's kid
didn't have an Amiga. The "same old, same old" would have triumphed and they
would probably still be producng letters to customers on lineflo without
signatures.
Today's generation are MUCH more "computer savvy". They expect more and they
know it is possible, because the company down the road is doing it.
>
> C) Many (most? I don't know) "employees" see programming as a "9 to
> 5" (actually a little more) JOB and they have minimal if any interest
> in pursuing it out of "work".
Jeez, Bill, I really hope that isn't true. It would account for the crap
code most of us have encountered. I'm not suggesting that people should live
their work and not have other interests; but I can't imagine anyone being a
successful programmer who had no passion or affinity for it. I have worked
in IT all my working life since I was 20 years old. My passion for it has
never waned and even today, I still get a kick out of watching code I wrote
execute. Most of the people I have worked with have had similar committment
and the really successful ones have simply lived and breathed it. (I'm not
suggesting we should all do that, and I recognise there are different
drummers we all march to, but we spend at least a third of our lives in the
workplace; surely this requires us to go a bit further than "9 'til 5"? (I
can understand people doing a job they have intention of making their life's
work, because of circumstance or necessity, but this would be a "stop gap"
until something better came along. Programming is generally considered to be
a professional career.)
>If they have the "skill set" to do
> what their current job requires, why would they try and expand it?
>
Because they could be made redundant overnight, as so many have been over
the last 2 decades.
If you are a "one trick pony" and the circus closes down, you are bound for
the glue factory. Survival in the workplace, just as survival in the
wilderness, requires as many skills as you can muster. It's like learning to
swim or fly. You can do it because it looks like fun, or you can do it
because one day your life may depend on it, or maybe because both are good
reasons. Everything you learn, every new experience you undergo, helps you
grow as a person, and personal growth is more important than any job. So,
there can never be any excuse for "not wanting to know" (unless you have
decided to stop growing and have attained perfection... :-))
Given that new experiences and knowledge are pretty good for us, why not
kill two birds with one stone and learn something that is pertinent to the
workplace? You may actually generate revenue from this knowledge, it might
save your job one day, but even if it doesn't, it affords you more
"marketable strings" to your bow.
Some years ago I was enjoying a few beers with some friends in a bar. In
vino, veritas. One of the company stammered a bit then admitted he was
thinking of going to University but he was worried he could be too old (he
was in his forties). He wanted to be an opthalmologist. None of us had the
slightest inkling this was on his agenda; he had never spoken of it, as if
it were a deep dark secret. The conversation went like this:
"How many years will it take to get your degree?"
"Five years".
"So, how old will you be?"
"Forty eight."
"And how old will you be in five years if you DON'T do the course?"
"Forty eight...Hey! it comes out the SAME!"
He has a flourishing practice in a small South Island town and, last I heard
was very happy to go to work in the morning...
We should never give up on learning.
> NOTE: As before "generalizations" in the above, but my GUESS is this
> is "more true than false" (and probably well over a simple majority).
I agree it is very hard to know with any kind of certainty. All I can say is
I HOPE you are mistaken... :-)
Rene_Surop
> BTW, Rene, I am not sure if private mail I sent you was received. Can you
> check please? May have been thrown in the junkmail folder... :-)
>
> Pete.
Haven't received any of your email(s) yet.
Though I prepared my ZIP files for you (the one I forwarded for Cobol
Evolution contest), it seems that Yahoo mail won't upload it because
it's quite big. I manage to cut it into three (3) ZIP files though and
will send it to you shortly.
Bill Gunshannon
That is a matter of opinion.
>
> My piece was written with a degree of tongue-in-cheek but I mostly believe
> what I wrote.
I had no doubt of that.
>
> The reality is that it IS difficult for people who have worked a certain way
> for years to believe that something new could be better. Especially when
> there have been "false alarms" over the years (who could forget "The Last
> One" closely followed a few years later by "The Next One". :-)).
If you mean me, I fear you are mistaken, But then, you have never met
me and know little about me.
I "learn" very well. I started, like many, with things like Fortran,
360 Assembler and Basic. I learned Algol, COBOL, PL/I, Pascal, C, C++,
Ada, Java, a lot more assemblers and bunch of other languages that are
really too obscure to include in my list any more. 90% of the programming
I do today is still using procedural languages and, guess what, they do
the job just fine. Tkae less time to develop and consume less resources
as well. But wait, there's more.....
>
> Your large shops who see no reason to change will be overtaken by events as
> surely as the dinosaurs were overtaken by the comet. It will take time, but
> it will happen.
This is exactly what I hear from certain faculty members around here. it
should be pointed out, however that some of these faculty members have
never been anything but academics. Straight from student to faculty.
It is funny to listen to them telling students what it will be like
when they leave work and enter the IT world considering they have never
been there themselves.
It is even funnier when I talk to my cintacts in businesses like banking,
insurance and credit and they end out rolling on the floor ilaughing when
I tell them they are going to convert all their COBOL to Java (or some
other OO language dujour).
>
> Procedural COBOL has a very limited remaining life span and I'm not saying
> this as an Academic; I'm saying it as one who has spent 40 years living and
> working in the real workplace.
Things must be very different on your side of the equator. The only thing
keeping me from returning to full-time, very well payed employment as a
COBOL Programmer is a lack of current IBM Experience. There are more
jobs available than there are available people to fill them. And that
ratio is moving in the opposite direction you would seem to think. Not
conjecture, I have spoken with the people doing the COBOL work and have
been turned down for a job not because they wre cutting back on staff but
because I have not touched IBM for 30 years. I have, personnally done
COBOL as recently as 2 years ago and have had no point in the past 30
years where I was not surrounded by people doing COBOLof one sort or
another. I greatly regret the decision here to stop teaching COBOL,
even if it accounted for only one credit of a four credit course.
>
> Inability to see the Emperor's new clothes does not mean that the Emperor is
> naked.
Like I said, matter of opinion. Both views are possible. I have seen more
than enough evidence to support mine to my satisfaction.
Bill Gunshannon
William M. Klein
news:76t5i6F...@mid.individual.net...
<much snippage>
>
> If you mean me, I fear you are mistaken, But then, you have never met
> me and know little about me.
Bill,
In case it wasn't clear, I think that much/most of Pete's replies to "Bill" in
this thread were replies to my posts.
P.S. I appreciated what you said in the "snipped" text.
--
Bill Klein
wmklein <at> ix.netcom.com
<snip>
Bill Gunshannon
"Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
> William M. Klein wrote:
>> Much snippage, but see comment to which I reply below
>>
>>>
>>> The remaining future for COBOL programming is in leveraging it into
>>> the 21st century. We are six years away from 2015 and, I have to
>>> say, what I am seeing and hearing leads me to believe my prediction
>>> may have been generous; I do not know of a single COBOL site
>>> (admittedly, my sample is small) that plans on keeping COBOL as the
>>> major development language into the future. Most sites still running
>>> COBOL are doing so because what they have works and they are unsure
>>> of how to migrate or phase it out. Ask any COBOL IT manager: "If
>>> someone came along with a magic bullet that could move all of your
>>> applications into a distributed, component based, environment, like
>>> the Internet or .NET, and allow your existing COBOL to run with
>>> other languages in that environment, so you were no longer
>>> exclusively tied to COBOL, would you take it?" See how many say:
>>> "No thanks, we're staying with COBOL..."
>> <snip>
>>
>> Pete,
>> I wish that sometime you could visit SHARE (IBM mainframe user
>> group).
>
> I'd like that. :-)
I wish I had the employer support and time to take part in SHARE as
well. I am constantly trying to get the faculty here involved in
the IBM Academic Alliance (it is only open to faculty and grad
assistants, not academic support staff) because I think academia
has a warped view of the IT industry. More on that further down...
>
>> I think you would be surprised how many fortune 500
>> companies (in the US) see the mainframe as PART of their future -
>> and included in this is COBOL. Things like XML COBOL with and without
>> SOA, CICS, etc are where LOTS of new development is being done.
>
> OK.
I am not at all surprised. The mainframe, itself, may not be what it
was 30 years ago, but the job hs changed little and the mindset needs
to (and usually does) match the job, not the box in the corner.
>>
>> I know that DD, Arnold, Howard and a few other contractors who work
>> with IBM mainframe COBOL post in this forum. However, I do think that
>> this part of the existing COBOL base is significantly
>> "under-represented" in comp.lang.cobol.
>
> Why do you suppose that is, Bill?
>
> Is there still a culture of non-Internet/Usenet awareness and the idea that
> PCs are toys and only mainframes are "real" computers?
Somehow, I doubt that. It is probably more likely that the available
COBOL resources on USENET are so limited (one group) that they find
no real value here. One of the mosst common uses of programming
language newsgroups is to get help with some obscure problem with
a program or concept implementation. I expect that is much less
needed with COBOL. The problem set is much smaller as people who
do COBOL know what it is for and don't try to force it to do things
outside its own domain. Using myself as an example, when I was a
full-time COBOL programmer it wasn't the only language I used. At
the same time I did Fortran, various assemblers and it was during this
period that I actually learned Pascal because we had projects come
up for which Pascal was the best language based on task and environment.
(We actually tried Basic, Fotran-77 and COBOL first because we had no
in-house Pascal expertise. It was the obvious shortcomings of these
other languages for the project that resulted in my taking Jensen &
Wirth's book with me on vacation and coming back able to write Pascal
programs. Tell me I wasn't a geek in those days, sitting on the beach
reading " A Uers's Manual and Report"!!)
>
>>
>> It may (or may not) be true/representative, but using "Usenet" (or
>> even other web based) "forums for discussing programming and language
>> issues is NOT in the "toolbox" of most of those in the environments
>> where COBOL does still thrive.
>
> So what planet are these people living on? No wonder COBOL is a tiny
> minority of the programming community.
I think this perception is part of the ptoblem. See further down...
>
>>It is also my impression that most of
>> the shops doing major NEW development in COBOL use "employees" and
>> not contractors. This is another reason they are under-represented
>> in this forum.
>
> This forum is not exclusively populated by contractors. There are many
> permanent employees who lurk here. Some of them don't post because they
> don't want to be publicly identified by their Boss or colleagues. On
> occasion I have urged people who contacted me privately to post here and
> they won't. It is also interesting that of the considerable number of people
> who have registered on the web site since we first published the cobdata
> tool, only a handful are names I recognise from this forum.
>
> I believe there are COBOL people who DO want to know. If they work on one of
> the sites you are describing there is no incentive for them to expand their
> horizons. It is "same old, same old" as long as the site management can get
> away with it.
And, if that does the job that earns the money, what is wrong with it?
Why change just for the same of change?
>
>
>>
>> I don't want to give the impression that I think that COBOL is always
>> (or even usually) the language of choice for new development in any
>> environment. HOWEVER, I do think that there is significant COBOL
>> development being done - in an environment that is NOT visible in
>> comp.lang.cobol.
>
> I guess it depends what you mean by "significant".
Now we get tot he meat of the matter. This is exactly correct. So, tell
me, how "significant" is "Facebook"? (I am sure your opinion and mine are
diametrically opposite!!)
> In the context of all the
> programming going on in the world today it is NOT significant.
Again, this depends on your definition of "significant".
> This is a
> marked change from 20 years ago when it WAS significant and 30 years ago
> when it was major.
Same comment. I believe you are determining "significance" by amount of
code rather than by what the code is used for. There is a lot of work
being done with COBOL that the world can not do without. There is a lot
of work being done with Java that is just wasting cpu cycles.
>
> I accept what you say and I know there are big sites where change comes
> slowly. Nevertheless, these sites are under mounting pressure to adapt and
> their main justification at the moment is the huge volumes of batch
> processing they carry out.
I wonder how much of this work really is still "batch". I know of many
cases where the model is Web Frontend <-> COBOL Middleware <-> DB Backend.
Heck, I am in the early stages of just such a project myself just for fun.
Believe it or not, one of the reasons why I have chosen COBOL for the
Middleware is scalability. Depending on the size of the user's organization
this system will be able to use anything from a flat-file to a Database
as the backend with only minimal change to the program. Could this be
done with other languages? Sure, But then, they offer nothing additional
from COBOL and would likely make the development (both initial and maintenance)
much higher.
> Over time that will slowly dissipate as better
> transactional processing is introduced. It won't happen overnight, but it
> will happen.
If you mean "batch" going away, I agree. If you mean that in itself will
obsolete COBOL, well, you know where I stand on that.
>
> Here's a fun idea: Copy my hypothetical question from the start of this
> message and circulate it round the next SHARE meeting. Ensure that they can
> respond anonymously and see what the response is. If it is an overwhelming:
> "No, I'm sticking with COBOL" then I'll stand corrected (at least as far as
> "mainframe heartland" goes...)
I can't speak for SHARE, but I have brought this up with people I know
in the industries I mentioned earlier (one of them just this morning!)
and they still just laugh and get back to the COBOL listings. One that
I mentioned earlier (the one that rejected me for a lack of current
CICS experience but did want me as a Unix guy) was int he process of
hiring over 150 new COBOL people. I wonder if they had any luck finding
that many?
>
> You might also encourage some of them to post here... :-)
That I would find unlikely. They stand to gain nothing from it.
Pete Dashwood
No, I had no-one specific in mind. I was thinking more of site managers who
maintain the status quo... You were not being targeted :-)
>
> I "learn" very well. I started, like many, with things like Fortran,
> 360 Assembler and Basic. I learned Algol, COBOL, PL/I, Pascal, C,
> C++, Ada, Java, a lot more assemblers and bunch of other languages
> that are really too obscure to include in my list any more. 90% of
> the programming I do today is still using procedural languages and,
> guess what, they do the job just fine. Tkae less time to develop and
> consume less resources as well. But wait, there's more.....
Maybe for batch processes. You'd be pressed to maintain that position
against overall costs and development times.
>
>>
>> Your large shops who see no reason to change will be overtaken by
>> events as surely as the dinosaurs were overtaken by the comet. It
>> will take time, but it will happen.
>
> This is exactly what I hear from certain faculty members around here.
> it should be pointed out, however that some of these faculty members
> have never been anything but academics. Straight from student to
> faculty.
> It is funny to listen to them telling students what it will be like
> when they leave work and enter the IT world considering they have
> never been there themselves.
As I pointed out previously, such is not the case with me.
>
> It is even funnier when I talk to my cintacts in businesses like
> banking, insurance and credit and they end out rolling on the floor
> ilaughing when I tell them they are going to convert all their COBOL
> to Java (or some other OO language dujour).
I hope they're still laughing when they get their severance cheques...
>
>>
>> Procedural COBOL has a very limited remaining life span and I'm not
>> saying this as an Academic; I'm saying it as one who has spent 40
>> years living and working in the real workplace.
>
> Things must be very different on your side of the equator.
Unfortunately my experience spans both sides of the equator (although only a
single brief contract in the USA). It is a world wide trend as far as I can
establish. If it is not the case where you are, then that is interesting.
Bill made some points about the IBM mainframe heartland not seeing any need
to change what they do. I think a new generation of managers may have a
different view.
> The only
> thing keeping me from returning to full-time, very well payed
> employment as a COBOL Programmer is a lack of current IBM Experience.
It's hard to believe that is a show-stopper if they are desperate for
people. With the background you obviously have, they should realise it would
be easy for you to pick up in a very short time. Have you tried taking code
samples to an interview? I remember doing that on a couple of occasions in
my youth and it seemed to cut some ice.
> There are more
> jobs available than there are available people to fill them.
And yet you can't get a job. Something here doesn't add up.
>And that
> ratio is moving in the opposite direction you would seem to think.
> Not conjecture, I have spoken with the people doing the COBOL work
> and have been turned down for a job not because they wre cutting back
> on staff but because I have not touched IBM for 30 years.
Bill, I'll be frank. If I were interviewing for people (and it is sometimes
my wont to do so) and someone turned up who was really keen to work with
COBOL again, had the broad background you described earlier, and I knew
there was a limited supply of good candidates, I'd grab him with both hands.
Wouldn't you? The platform specific stuff (JCL, architecture, utilities,
etc.) is something that such a candidate would pick up very quickly.
Now, if we were hanging down with candidates who had in-depth current
platform experience, that would be different. But you are saying "there are
more jobs available than people to fill them".
If you are getting interviews and then been told you aren't suitable on the
basis of no current IBM experience, didn't they know that before they saw
you? If you simply can't get an interview, and the market is as you
describe, then it may be time to make some direct contact and get across a
table from someone who is a recruiting principal (rather than a pimp).
>I have,
> personnally done COBOL as recently as 2 years ago and have had no
> point in the past 30 years where I was not surrounded by people doing
> COBOLof one sort or another. I greatly regret the decision here to
> stop teaching COBOL,
> even if it accounted for only one credit of a four credit course.
The University has a responsibility to its students and to commerce. They
don't have unlimited resources, so they go for what they feel is the most
relevant. It would be "nice" if their students got some COBOL background,
but it is more important in today's world that they understand objects and
principles of programming.
I understand your position and why you feel the way you do. I wish you every
success with the job hunting.
>
>>
>> Inability to see the Emperor's new clothes does not mean that the
>> Emperor is naked.
>
> Like I said, matter of opinion. Both views are possible. I have
> seen more than enough evidence to support mine to my satisfaction.
Fair enough.
Pete Dashwood
> "Bill Gunshannon" <bill...@cs.uofs.edu> wrote in message
> news:76t5i6F...@mid.individual.net...
> <much snippage>
>>
>> If you mean me, I fear you are mistaken, But then, you have never
>> met me and know little about me.
>
> Bill,
> In case it wasn't clear, I think that much/most of Pete's replies to
> "Bill" in this thread were replies to my posts.
>
> P.S. I appreciated what you said in the "snipped" text.
Yes, so did I... :-)
Thanks for clearing up the "Bill" confusion, Bill (Klein) :-)
"Bills! Bills! Bills!" - (The Dean in "Dandy Dick" by Sir Arthur Wing
Pinero)
Pete Dashwood
As noted in private mail, I have it all and will get back to you as soon as
I can.
Bill Gunshannon
"William M. Klein" <wmk...@nospam.ix.netcom.com> writes:
> "Bill Gunshannon" <bill...@cs.uofs.edu> wrote in message
> news:76t5i6F...@mid.individual.net...
> <much snippage>
>>
>> If you mean me, I fear you are mistaken, But then, you have never met
>> me and know little about me.
>
> Bill,
> In case it wasn't clear, I think that much/most of Pete's replies to "Bill" in
> this thread were replies to my posts.
>
> P.S. I appreciated what you said in the "snipped" text.
Sometimes it is hard to keep the "Bill's" clear, but I was fairly certain
he meant me when he said ostrich!! :-)
Bill Gunshannon
So, a duck walks into a drugstore and asks the clerk for a Chapstick.
The clerk say, "Will that be cash?" The duck replied, "No, put it on
my bill."
Bill Gunshannon
My experience is greatly different from yours. Even using the simple
tasks the students do here, everything takes them longer with the
languages dujour than it did when we used things like Pascal and
COBOL. And, in specific regards to COBOL, dropping it from the one
course has required the course to be completely redesigned to the point
where much of what the course was intended to teach has been eliminated.
Hmmm..... What's wrong with that picture?
>>
>>>
>>> Your large shops who see no reason to change will be overtaken by
>>> events as surely as the dinosaurs were overtaken by the comet. It
>>> will take time, but it will happen.
>>
>> This is exactly what I hear from certain faculty members around here.
>> it should be pointed out, however that some of these faculty members
>> have never been anything but academics. Straight from student to
>> faculty.
>> It is funny to listen to them telling students what it will be like
>> when they leave work and enter the IT world considering they have
>> never been there themselves.
>
> As I pointed out previously, such is not the case with me.
>
>>
>> It is even funnier when I talk to my cintacts in businesses like
>> banking, insurance and credit and they end out rolling on the floor
>> ilaughing when I tell them they are going to convert all their COBOL
>> to Java (or some other OO language dujour).
>
> I hope they're still laughing when they get their severance cheques...
Most of the people I talk with are high enough up the food chain to know
if there was any threat of COBOL going away. Many of them are involved
in new COBOL development. I would expect someone just starting out today
could work their entire career and retire before any threat of being made
redundant becasue they were COBOL programmers.
>>
>>>
>>> Procedural COBOL has a very limited remaining life span and I'm not
>>> saying this as an Academic; I'm saying it as one who has spent 40
>>> years living and working in the real workplace.
>>
>> Things must be very different on your side of the equator.
>
> Unfortunately my experience spans both sides of the equator (although only a
> single brief contract in the USA). It is a world wide trend as far as I can
> establish. If it is not the case where you are, then that is interesting.
My contacts go a bit further than "wehre I am". I talk with COBOL people
all over the country. The job I mentioned interviewing for was several
states south of where I live now. Why do I say this? To point out that
at least in the US this is not a local phenomena.
> Bill made some points about the IBM mainframe heartland not seeing any need
> to change what they do.
It is not just IBM shops.
> I think a new generation of managers may have a
> different view.
Yeah, but it is usally about where the work is to be done rather than how
the work is to be done.
>
>
>> The only
>> thing keeping me from returning to full-time, very well payed
>> employment as a COBOL Programmer is a lack of current IBM Experience.
>
> It's hard to believe that is a show-stopper if they are desperate for
> people.
They are not desperate, yet. but as more and more schools drop COBOL
completely, well, one never knows. but then, I will probably be retired
by then.
> With the background you obviously have, they should realise it would
> be easy for you to pick up in a very short time. Have you tried taking code
> samples to an interview? I remember doing that on a couple of occasions in
> my youth and it seemed to cut some ice.
I think in an interview I could sell myself. But hiring practices in the
US have changed drasticly of late. Systems like RESUMIX are running the
show. If your resume doesn't have certain things in it in a form the
system can extract, you never get called for an interview. Like I said,
I got my foot in the door on one but when I tried to steer the interview
int he direction of the COBOL side of the house they made it clear they
were the Unix side and that was what they wanted me for.
>
>
>> There are more
>> jobs available than there are available people to fill them.
>
> And yet you can't get a job. Something here doesn't add up.
CICS..... While I have had many people tell me I could pick it up in
days there is no convincing HR people that. They have keywords and
if they aren;t in your resume, you don't get called. Being 60 doesn't
increase my chances, either.
>
>>And that
>> ratio is moving in the opposite direction you would seem to think.
>> Not conjecture, I have spoken with the people doing the COBOL work
>> and have been turned down for a job not because they wre cutting back
>> on staff but because I have not touched IBM for 30 years.
>
> Bill, I'll be frank. If I were interviewing for people (and it is sometimes
> my wont to do so) and someone turned up who was really keen to work with
> COBOL again, had the broad background you described earlier, and I knew
> there was a limited supply of good candidates, I'd grab him with both hands.
> Wouldn't you? The platform specific stuff (JCL, architecture, utilities,
> etc.) is something that such a candidate would pick up very quickly.
So would I. I also tell people that if I were interviewing I would take
one year of real experience over two years of college any day. So, how
old are you? All of the people in the interview I mentioned above were
young enough to be my grandkids. They place much less value on experience,
probably because they got where they are with very little.
>
> Now, if we were hanging down with candidates who had in-depth current
> platform experience, that would be different. But you are saying "there are
> more jobs available than people to fill them".
There are. And I am sure that at some point they will modify their
hiring practices. But that will likely be too late for me. (Actually,
it is now. If They offered me the job tomorrow I am not sure I would
bother.)
>
> If you are getting interviews and then been told you aren't suitable on the
> basis of no current IBM experience, didn't they know that before they saw
> you?
You must have missed that part. I don't get interviews. I get told up
front that my resume does not reflect the current IBM experience they
are looking for. The one interview I had was for a totally different
job and when I brought up the idea that I really would have prefered
a COBOL job I was told we are not interviewing for that.
> If you simply can't get an interview, and the market is as you
> describe, then it may be time to make some direct contact and get across a
> table from someone who is a recruiting principal (rather than a pimp).
The way things are being done over here nowadays, that is nearly impossible.
When it happens, I do well. I had a call yesterday from someone who had
seen my resume for a job that the HR people canceled the hiring process
for. This place called me out of the blue to talk about wethere or not I
would still be interested in the job if HR puts it out with additional
stipulations that were not in the original. This is an unusual case and
will probably not develop into anything but it at least does demonstrate
that just because someone doesn't get the interview doesn't mean they
aren't the right man for the job. (No, this isn't a COBOL job either, it's
another academic position.)
>
>
>>I have,
>> personnally done COBOL as recently as 2 years ago and have had no
>> point in the past 30 years where I was not surrounded by people doing
>> COBOLof one sort or another. I greatly regret the decision here to
>> stop teaching COBOL,
>> even if it accounted for only one credit of a four credit course.
>
> The University has a responsibility to its students and to commerce. They
> don't have unlimited resources, so they go for what they feel is the most
> relevant.
Nice thought, but not what I see. "The University" doesn't see itself
as having any responsibility other than handing out pieces of paper
every May. The academics don't want to prepare students for the real
world, they want to mold the real world in the concepts they see as
important. They want to drive the bus. We used to use Ada here as
a primary teaching language. That was when we were being told Ada was
the penultimate programming language and with the drive og the US
government everyone would use it. You can't imagine how many emails
I got from former students complaining about having to learn such a
useless (from a real world perspective) language. And then we moved
on to Java.
> It would be "nice" if their students got some COBOL background,
> but it is more important in today's world that they understand objects and
> principles of programming.
One of the strengths of our program has always been that we concentrate
on "principles of programming" and don't teach languages. But going
in the complete other direction is not, in my opinion, such a good idea
either.
>
> I understand your position and why you feel the way you do. I wish you every
> success with the job hunting.
Not to worry, in just a couple more years it won't matter and all of
my programming will be what I do for fun. Unless I get a call in my
relaxing years making an offer I can't refuse to bail out some place
the really needs that COBOL program maintained. :-)
>>
>>>
>>> Inability to see the Emperor's new clothes does not mean that the
>>> Emperor is naked.
>>
>> Like I said, matter of opinion. Both views are possible. I have
>> seen more than enough evidence to support mine to my satisfaction.
>
> Fair enough.
All the best. I really enjoy these discussions.
Pete Dashwood
> In article <76rqgrF...@mid.individual.net>,
> "Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
>> William M. Klein wrote:
>>> Much snippage, but see comment to which I reply below
>>>
>>>>
>> I believe there are COBOL people who DO want to know. If they work
>> on one of the sites you are describing there is no incentive for
>> them to expand their horizons. It is "same old, same old" as long as
>> the site management can get away with it.
>
> And, if that does the job that earns the money, what is wrong with it?
> Why change just for the same of change?
Because the WORLD is changing. Business is changing (and much of that change
is down to the advent and phenomenal acceptance of, the Internet)
People are now booking their airline travel themselves, as a matter of
course. Banking is done more and more online. Today I had information about
getting insured online. The company were proudly announcing their new
internet facility that lets you write your own policy and select the
premiums online. (At the moment it is limited to existing customers, and
only for certain types of insurance, but this is a pilot...) Banks,
insurance, airlines... all traditional bastions of the mainframe,
strongholds of COBOL... CHANGING the way they do business. Why? Because it
is a marketplace and change is inevitable. If they don't adapt, they will be
overrun by their competitors, who did.
It isn't change for the sake of change, it is change for the sake of
survival. Online systems aren't just a trendy fashion fad any more; they are
the vital essence of the business. Transactions represent the interaction
between the business model and the marketplace. If the marketplace changes,
so must the business model. A competitive marketplace is fluid and dynamic.
(As each "player" gains a competitive advantage, the others must adapt their
model to nullify it.) Your computer systems need to be able to match that
fluid dynamism. You can't take a year to implement systems any more. Why do
you think there is such a rising interest in "Agile" methodologies?
(Methodologies which are object and component based, BTW...)
The back office world you are talking about can remain cloistered from
these changes for a little while but not indefinitely.
The managers you mentioned who are laughing at the idea of change will
simply find one day they are called to account for not delivering what the
business needed. It will be no good saying: "but we've always done it that
way".
(Actually, I don't think they will be called to account at all. They will
simply be replaced by the new breed of manager. People who understand the
world of objects and layers and networks...)
>>
>>
>>>
>>> I don't want to give the impression that I think that COBOL is
>>> always (or even usually) the language of choice for new development
>>> in any environment. HOWEVER, I do think that there is significant
>>> COBOL development being done - in an environment that is NOT
>>> visible in comp.lang.cobol.
>>
>> I guess it depends what you mean by "significant".
>
> Now we get tot he meat of the matter. This is exactly correct. So,
> tell
> me, how "significant" is "Facebook"? (I am sure your opinion and
> mine are diametrically opposite!!)
For me, it has no significance at all. I'm not on it. Neither am I on any
other social network site (Oops, sorry, I have a slight presence on
LinkedIn), and I don't Blog or Tweet. Now, if your question was how
significant is FaceBook as a marketplace to you, then it would depend on
what you're selling. I don't think a lot of software gets sold through
Facebook or MySpace (I could be wrong... it must certainly be a market for
mobile appplications).
>> In the context
>> of all the programming going on in the world today it is NOT
>> significant.
>
> Again, this depends on your definition of "significant".
>
>> This
>> is a marked change from 20 years ago when it WAS significant and 30
>> years ago when it was major.
>
> Same comment. I believe you are determining "significance" by amount
> of
> code rather than by what the code is used for. There is a lot of work
> being done with COBOL that the world can not do without. There is a
> lot
> of work being done with Java that is just wasting cpu cycles.
>
>>
Ah, COBOL has the moral high ground... :-)
>> I accept what you say and I know there are big sites where change
>> comes slowly. Nevertheless, these sites are under mounting pressure
>> to adapt and their main justification at the moment is the huge
>> volumes of batch processing they carry out.
>
> I wonder how much of this work really is still "batch". I know of
> many
> cases where the model is Web Frontend <-> COBOL Middleware <-> DB
> Backend. Heck, I am in the early stages of just such a project myself
> just for fun. Believe it or not, one of the reasons why I have chosen
> COBOL for the Middleware is scalability. Depending on the size of
> the user's organization this system will be able to use anything from
> a flat-file to a Database
> as the backend with only minimal change to the program. Could this be
> done with other languages? Sure, But then, they offer nothing
> additional from COBOL and would likely make the development (both
> initial and maintenance) much higher.
You keep saying that but you offer no evidence. If you used a .NET language
instead of COBOL you wouldn't need middleware at all. (.NET blurs the
distinction between destop and web...all that matters is the framework and
components can run anywhere). How can it be faster to write COBOL than to
write nothing? The web frontend (using ASP.NET and C# compiled rather than
interpreted) can interface through a layer to data sources that can do
things COBOL can only dream of. Lambda functions and LINQ in C# can
generate and execute deferred dynamic SQL, optimizing it at runtime to suit
specific individual queries, and automatically assigning it to separate
cores and thread instances that ESQL could never do.The same datasources can
be available to any branch of the company, immediately, anywhere on earth. I
submit to you that this offers MUCH "additional to COBOL", and these
applications can be built far quicker than the equivalent in COBOL. (Having
done it both ways I am qualified to say this.)
>
>> Over time that will slowly dissipate as
>> better transactional processing is introduced. It won't happen
>> overnight, but it will happen.
>
> If you mean "batch" going away, I agree. If you mean that in itself
> will obsolete COBOL, well, you know where I stand on that.
OK. At least we agree on something... :-) (I'm surprised, Bill. I didn't
expect anyone here to agree with my assessment that batch processing will be
replaced by better transaction processing, but I'm thankful for small
mercies in CLC... :-))
>
>>
>> Here's a fun idea: Copy my hypothetical question from the start of
>> this message and circulate it round the next SHARE meeting. Ensure
>> that they can respond anonymously and see what the response is. If
>> it is an overwhelming: "No, I'm sticking with COBOL" then I'll stand
>> corrected (at least as far as "mainframe heartland" goes...)
>
> I can't speak for SHARE, but I have brought this up with people I know
> in the industries I mentioned earlier (one of them just this morning!)
> and they still just laugh and get back to the COBOL listings. One
> that
> I mentioned earlier (the one that rejected me for a lack of current
> CICS experience but did want me as a Unix guy) was int he process of
> hiring over 150 new COBOL people. I wonder if they had any luck
> finding
> that many?
Good or bad luck... :-)?
Pete Dashwood
> In article <76t9d7F...@mid.individual.net>,
> "Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
>> William M. Klein wrote:
>>> "Bill Gunshannon" <bill...@cs.uofs.edu> wrote in message
>>> news:76t5i6F...@mid.individual.net...
>>> <much snippage>
>>>>
>>>> If you mean me, I fear you are mistaken, But then, you have never
>>>> met me and know little about me.
>>>
>>> Bill,
>>> In case it wasn't clear, I think that much/most of Pete's replies
>>> to "Bill" in this thread were replies to my posts.
>>>
>>> P.S. I appreciated what you said in the "snipped" text.
>>
>> Yes, so did I... :-)
>>
>> Thanks for clearing up the "Bill" confusion, Bill (Klein) :-)
>>
>> "Bills! Bills! Bills!" - (The Dean in "Dandy Dick" by Sir Arthur
>> Wing Pinero)
>
> So, a duck walks into a drugstore and asks the clerk for a Chapstick.
> The clerk say, "Will that be cash?" The duck replied, "No, put it on
> my bill."
LOL!
A duck walks into a country general store right on noon and asks the
clerk:"Got any duckfood?"
The clerk politely responds that, although the store stocks most things,
they just don't carry duckfood.
Crestfallen duck waddles out.
Next day, exactly at noon, same duck enters the store and asks the clerk
again:"Got any duckfood?"
Clerk takes a deep breath and says:"I told you yesterday, we don't carry
duckfood. Please don't come in here again wasting my time."
Crestfallen duck waddles out.
The third day the process repeats and this time the clerk is very angry:"I
asked you nicely but you took no notice! OK,no more mister nice guy...if you
come in here tomorrow and ask for duckfood I'm gonna nail your webbed foot
to the floor!"
Crestfallen duck waddles out.
Next day at noon... the clerk feels his blood pressure rising but, to his
surprise, the duck says:"Got any nails?"
"Well, yes, we have all kinds of nails, let me just get some and you can
choose..."
The clerk goes to the nail bins and finds, to his horror, they have been
emptied and not replenished. He goes back to explain to the duck...
"Look, I'm really sorry and it is most unusal, but we seem to be all out of
nails just at the moment..."
The duck looks him in the eye and says: "Got any duckfood?"
Pete Dashwood
> In article <5ndOl.262722$BR.1...@en-nntp-04.dc1.easynews.com>,
> "William M. Klein" <wmk...@nospam.ix.netcom.com> writes:
>> "Bill Gunshannon" <bill...@cs.uofs.edu> wrote in message
>> news:76t5i6F...@mid.individual.net...
>> <much snippage>
>>>
>>> If you mean me, I fear you are mistaken, But then, you have never
>>> met me and know little about me.
>>
>> Bill,
>> In case it wasn't clear, I think that much/most of Pete's replies
>> to "Bill" in this thread were replies to my posts.
>>
>> P.S. I appreciated what you said in the "snipped" text.
>
> Sometimes it is hard to keep the "Bill's" clear, but I was fairly
> certain he meant me when he said ostrich!! :-)
Yes, I was responding to Bill Gunshannon when I said that . However it
wasn't meant to wound. The other references were to Bill Klein's post and,
again, were not personal.
Howard Brazee
I could retire now and work half time for the next year or two with
basically my current income. (Those who are doing this are expected
to keep the mainframe running until the PeopleSoft/Oracle/Sun system
takes over)
By then the mainframe will be gone, and so would be my job. So I am
continuing to work so that I have a job 3 years from now on our new
system. If my health gets worse, I'll be sorry, but I don't want to
be poor.
docd...@panix.com
Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>Bill Gunshannon wrote:
[snip]
>> 90% of
>> the programming I do today is still using procedural languages and,
>> guess what, they do the job just fine. Tkae less time to develop and
>> consume less resources as well. But wait, there's more.....
>
>Maybe for batch processes. You'd be pressed to maintain that position
>against overall costs and development times.
I'm not sure what are being called 'overall costs' here, Mr Dashwood...
but somewhere in my admittedly porous memory is the figure of 70 - 80% of
a shop's budget being spent on maintenance.
Now... what is 'maintenance'? It is the slogging-through of Anciente Code
to find the one spot where CUST-MAST-CODE is referred to and processing
directed accordingly, since the Days of the Roundheads there have only
been 'R'egular customers getting processed one way and 'S'pecial customers
getting processed another way... and now there are 'P'artially-unusual
customers who will get processed a third way.
Another ELSE IF is then stuffed in above the ELSE PERFORM
C167552-INVALID-CUSTTYPE THRU C167552-IC-EX to check for this 'P'... and
then C15000-SPECL-CUST (through C15000-SC-EX, of course) is copied and
pasted above this and below C10000-REG-CUST, renamed C12500-PARTL-CUST
(through -EX) and all of the 50% discounts are calculated at 25%... and
we're on our way, still using the 'same' program.
This is, as some folks have seen, how it is done as maintenance... but say
that someone copies the SPECCUST subroutine to PARTCUST and does the same,
making a new callable instead of another paragraph... or someone writes a
new partcust object which gets used instead of the current reglcust or
speccust... is this maintenance or development?
One 'develops' a new object or one 'maintains' a program older than the
developing language by a few decades... and the result is the same.
'Easier' and 'faster', of course, depend - as they seem to have always
depended - on the practioner, the programmer.
[snip]
>> The only
>> thing keeping me from returning to full-time, very well payed
>> employment as a COBOL Programmer is a lack of current IBM Experience.
>
>It's hard to believe that is a show-stopper if they are desperate for
>people. With the background you obviously have, they should realise it would
>be easy for you to pick up in a very short time.
Mr Dashwood, I know of a programmer who started working with DB2 in 1989.
During one of his down periods ten years back he taught himself PL/SQL to
use on Oracle jobs... and when he applied for them was told 'There aren't
any PL/SQL jobs in your background' and turned down.
Does this make sense? No, if you know anything about the skills
involved... yes, if you are looking for a specific set of letters in a
resume. As I've posted before: there are times when I've submitted my
bragsheet and heard 'I see a good amount of VSAM experience on IBM
mainframes here but the client is looking specifically for experience with
IDCAMS'.
[snip]
>Bill, I'll be frank. If I were interviewing for people (and it is sometimes
>my wont to do so) and someone turned up who was really keen to work with
>COBOL again, had the broad background you described earlier, and I knew
>there was a limited supply of good candidates, I'd grab him with both hands.
Mr Dashwood, you've mentioned more than a few times that you Do Things
Differently than other folks... and because of this you obtain different
results. As my Sainted Paternal Grandfather - may he sleep with the
angels! - used to say, 'Never use yourself as a comparative, you'll only
be disappointed.'
The narrow-sightedness Mr Gunshannon reports is reflected in my
experiences and, I believe, those of other folks... What I Would Do, by Mr
Dashwood, might not be applicable to De Rerum Natura in other places.
DD
Pete Dashwood
> In article <76t96iF...@mid.individual.net>,
> "Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
>> Bill Gunshannon wrote:
>>> In article <76rp4fF...@mid.individual.net>,
>>> "Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
>>>> Bill Gunshannon wrote:
>>>>> In article <rcgg05p469rciao37...@4ax.com>,
>>>>> Howard Brazee <how...@brazee.net> writes:
>>>>>> On Tue, 12 May 2009 00:01:50 +1200, "Pete Dashwood"
>>>>>> <dash...@removethis.enternet.co.nz> wrote:
> Most of the people I talk with are high enough up the food chain to
> know
> if there was any threat of COBOL going away. Many of them are
> involved
> in new COBOL development. I would expect someone just starting out
> today could work their entire career and retire before any threat of
> being made redundant becasue they were COBOL programmers.
There are a number of sometime COBOL programmers who thought that too.
Job security, whether you are permanent or contract, is an illusion. I have
seen really good people who spent 20 years with a company given the push
when it suited the company. In this day and age ANY company can go broke,
almost overnight. The more strings you have to your bow, the more chance you
have of finding SOME company that needs that skill.
<snip>
>>> Things must be very different on your side of the equator.
>>
>> Unfortunately my experience spans both sides of the equator
>> (although only a single brief contract in the USA). It is a world
>> wide trend as far as I can establish. If it is not the case where
>> you are, then that is interesting.
>
> My contacts go a bit further than "wehre I am". I talk with COBOL
> people all over the country. The job I mentioned interviewing for
> was several states south of where I live now. Why do I say this? To
> point out that
> at least in the US this is not a local phenomena.
>
>> Bill made some points about the IBM mainframe heartland not seeing
>> any need to change what they do.
>
> It is not just IBM shops.
>
>> I think a new generation of managers may
>> have a different view.
>
> Yeah, but it is usally about where the work is to be done rather than
> how the work is to be done.
>
I think that the COBOL people you are in contact with are looking at things
from the perspective of a COBOL programmer, exactly as you might expect them
to. As Bill (Klein) pointed out, if you are writing COBOL in an environment
that has used COBOL for many years and see COBOL as the way to go, then it
is unlikely you will see any need for change. But that doesn't mean there is
no need. It is forces that are way beyond the COBOL shop that are forcing
change. Sooner or later the effects of that change will be felt. But it
isn't necessarily a bad thing. It isn't even necessarily bad for COBOL.
Refactoring COBOL so it can be used alongside other languages is a very
worthwhile exercise.
<SNIP>
>>
>> Fair enough.
>
> All the best. I really enjoy these discussions.
>
Yes, it is very civilized to be able to disagree in a reasonable way...:-)
It makes me think there could yet be hope for the world :-)
Bill Gunshannon
And, you know what? I laughed just as hard even knowing what the
punchline was going to be.
Bill Gunshannon
I am not thinskined enough to be wounded by that. I have been called
much worse. And I am rather proud of the epithet "dinosaur". :-)
Pete Dashwood
> In article <76t96iF...@mid.individual.net>,
> Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>> Bill Gunshannon wrote:
>
> [snip]
>
>>> 90% of
>>> the programming I do today is still using procedural languages and,
>>> guess what, they do the job just fine. Tkae less time to develop
>>> and consume less resources as well. But wait, there's more.....
>>
>> Maybe for batch processes. You'd be pressed to maintain that position
>> against overall costs and development times.
>
> I'm not sure what are being called 'overall costs' here, Mr
> Dashwood... but somewhere in my admittedly porous memory is the
> figure of 70 - 80% of a shop's budget being spent on maintenance.
Yes, for COBOL shops. I have seen the same figures quoted on various
different sites.
Based on experience maintaining my own COBOL codebase for a number of years,
I think this is probably in the ball park.
Since moving off COBOL the time (money) spent in maintenance is around 40%.
This is not just because of the language change, it is also down to better
tools and different (better) ways of developing systems.
> [snip]
>
>>> The only
>>> thing keeping me from returning to full-time, very well payed
>>> employment as a COBOL Programmer is a lack of current IBM
>>> Experience.
>>
>> It's hard to believe that is a show-stopper if they are desperate for
>> people. With the background you obviously have, they should realise
>> it would be easy for you to pick up in a very short time.
>
> Mr Dashwood, I know of a programmer who started working with DB2 in
> 1989. During one of his down periods ten years back he taught himself
> PL/SQL to use on Oracle jobs... and when he applied for them was told
> 'There aren't any PL/SQL jobs in your background' and turned down.
(Didn't your Gran'pappy say something about disappointment resulting from
using yourself as an example...?)..
You entirely missed the point that this reaction may well depend on the
market place. If they were hanging down with PL/SQL candidates they could
afford to be picky. If they were desperate for them the outcome may have
been different. I have been around pimps long enough to know the dreadful
processes of buzzword matching they employ and I don't condone it. I know
they often enforce what they are told by the client without understanding it
also. Client says: "I want people with PL/SQL experience" ... pimp enforces
that to the letter. BUT, if there were no candidates with that experience
and one candidate who seemed pretty competent generally had the knowledge,
pimp MIGHT try and sell said candidate to client. (Especially if candidate
encouraged him to do so...) It is a market place.
>
> Does this make sense? No, if you know anything about the skills
> involved... yes, if you are looking for a specific set of letters in a
> resume. As I've posted before: there are times when I've submitted my
> bragsheet and heard 'I see a good amount of VSAM experience on IBM
> mainframes here but the client is looking specifically for experience
> with IDCAMS'.
(Again with the first person exemplar...Is that sound I hear Gran'pappy
spinning in his grave?)
Actually, I have no problem with you using first person examples... (Hey,
he's YOUR Granpappy... I mention it only to make the point that it is hard
to recount first hand experience without using the ...er.. first person...)
> [snip]
>
>> Bill, I'll be frank. If I were interviewing for people (and it is
>> sometimes my wont to do so) and someone turned up who was really
>> keen to work with COBOL again, had the broad background you
>> described earlier, and I knew there was a limited supply of good
>> candidates, I'd grab him with both hands.
>
> Mr Dashwood, you've mentioned more than a few times that you Do Things
> Differently than other folks...
No, I don't recall ever saying that. YOU said it, about me. All I have ever
done in this forum is truthfully report how I see things and what has been
my experience. I know people who do things very much the way I do and I know
other people who don't. It really doesn't matter.
You conveniently snipped the next two words to make it look like I was
talkng about myself when, in fact, I was using myself as a template for what
I believe would be the reaction of most people. The words "wouldn't you?"
conveyed this but you saw fit to omit them and thus change the intended
meaning. I hope it wasn't done from malice... :-) In fact, Bill responded to
this question and agreed that he would.
> and because of this you obtain
> different results. As my Sainted Paternal Grandfather - may he sleep
> with the angels! - used to say, 'Never use yourself as a comparative,
> you'll only be disappointed.'
Sorry to disappoint your Grandaddy, but I have never been disappointed in my
own performance. I have recognised it could be improved and have attempted
to make adjustments over the years, but "disappointment"? No. I don't
believe in shame, blame or regret. Waste of time. If you screwed up, fix it,
learn from it, and move on.
>
> The narrow-sightedness Mr Gunshannon reports is reflected in my
> experiences and, I believe, those of other folks... What I Would Do,
> by Mr Dashwood, might not be applicable to De Rerum Natura in other
> places.
Possibly. However, it serves very well as an example which I know something
about. And I was not arguing that narrow-sightedness exists; I know very
well it does.
docd...@panix.com
Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>docd...@panix.com wrote:
>> In article <76rp4fF...@mid.individual.net>,
>> Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>>
>> [snip]
>>
>>> Your large shops who see no reason to change will be overtaken by
>>> events as surely as the dinosaurs were overtaken by the comet. It
>>> will take time, but it will happen.
>>
>> Something about 'all is vanity' was said three millennia and change
>> back, Mr Dashwood.
>
>Was it Ecclesiastes? I can't seem to find the Bible that is usually in the
>Bookcase... Perhaps God is punishng my atheist persuasion... :-)
Or re-enforcing it, Mr Dashwood... but this Web thingie is marvelous and
you might want to bookmark http://quod.lib.umich.edu/k/kjv/ .
>
>Perhaps a re-reading of Shelley's 'Ozymandias' is
>> in order, especially for those who think others should despair.
>
>How indeed are the Mighty fallen...
... and the new Mighty arise... and fall... and such, ever, is the way
things have been (or so it appears).
>My message was not intended to be one of despair, however.
>
>All things will pass in the fullness of time. But that is no reason to
>ignore change, today.
There's the rub, Mr Dashwood... be it slavery to the Fallen Past or
slavery to the Fashion du Mode, it is still slavery.
DD
docd...@panix.com
Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:
>docd...@panix.com wrote:
[snip]
>> Mr Dashwood, I know of a programmer who started working with DB2 in
>> 1989. During one of his down periods ten years back he taught himself
>> PL/SQL to use on Oracle jobs... and when he applied for them was told
>> 'There aren't any PL/SQL jobs in your background' and turned down.
>
>(Didn't your Gran'pappy say something about disappointment resulting from
>using yourself as an example...?)..
That he did, Mr Dashwood... hence my using the example of a programmer I
know.
>
>You entirely missed the point that this reaction may well depend on the
>market place.
I've heard similar tales from programmers across the whole of the United
States, Mr Dashwood... but I wonder if that constitutes 'a market place'
or 'a set of markets'; it used to be that I could hear a job description
and be fairly accurate in knowing what city the position was located in
because of the technologies requested. What was needed in Chicago
differed from what was best for Boston or all-right for Atlanta.
[snip]
>> Does this make sense? No, if you know anything about the skills
>> involved... yes, if you are looking for a specific set of letters in a
>> resume. As I've posted before: there are times when I've submitted my
>> bragsheet and heard 'I see a good amount of VSAM experience on IBM
>> mainframes here but the client is looking specifically for experience
>> with IDCAMS'.
>
>(Again with the first person exemplar...Is that sound I hear Gran'pappy
>spinning in his grave?)
What 'again'? My Sainted Grandfather warned against using one'sself as a
comparative, not against saying that something happened.
>
>Actually, I have no problem with you using first person examples... (Hey,
>he's YOUR Granpappy... I mention it only to make the point that it is hard
>to recount first hand experience without using the ...er.. first person...)
I try to make it my habit, Mr Dashwood, to emphasise my experience as
meagre, my views as parochial and my logical capacities strained by the
simplest of syllogisms... are you attempting to emphasise the porosity of
your own memory, as well?
[snip]
>
>
>> [snip]
>>
>>> Bill, I'll be frank. If I were interviewing for people (and it is
>>> sometimes my wont to do so) and someone turned up who was really
>>> keen to work with COBOL again, had the broad background you
>>> described earlier, and I knew there was a limited supply of good
>>> candidates, I'd grab him with both hands.
>>
>> Mr Dashwood, you've mentioned more than a few times that you Do Things
>> Differently than other folks...
>
>No, I don't recall ever saying that. YOU said it, about me. All I have ever
>done in this forum is truthfully report how I see things and what has been
>my experience. I know people who do things very much the way I do and I know
>other people who don't. It really doesn't matter.
>
>You conveniently snipped the next two words to make it look like I was
>talkng about myself when, in fact, I was using myself as a template for what
>I believe would be the reaction of most people. The words "wouldn't you?"
>conveyed this but you saw fit to omit them and thus change the intended
>meaning. I hope it wasn't done from malice... :-) In fact, Bill responded to
>this question and agreed that he would.
I saw them as rhetorical and the postulating of a hypothetical, Mr
Dashwood... Mr Gunshannon has not mentioned his being in such a position,
to the best of my recollection. That he mentioned Other Folks doing (a)
and you point out how you do (b) is an assertion that you Do Things
Differently than other folks... or so my meagre skills of logic permit me
to conclude.
[snip]
>> The narrow-sightedness Mr Gunshannon reports is reflected in my
>> experiences and, I believe, those of other folks... What I Would Do,
>> by Mr Dashwood, might not be applicable to De Rerum Natura in other
>> places.
>
>Possibly. However, it serves very well as an example which I know something
>about. And I was not arguing that narrow-sightedness exists; I know very
>well it does.
Apparently you do, Mr Dashwood... apparently you do.
DD
Howard Brazee
wrote:
>My experience is greatly different from yours. Even using the simple
>tasks the students do here, everything takes them longer with the
>languages dujour than it did when we used things like Pascal and
>COBOL. And, in specific regards to COBOL, dropping it from the one
>course has required the course to be completely redesigned to the point
>where much of what the course was intended to teach has been eliminated.
>Hmmm..... What's wrong with that picture?
One thing that's wrong is that the language de jour is designed to
work on the problems de jour. Why should we expect that the new tool
will be better at everything the old tool did?
Howard Brazee
wrote:
>They are not desperate, yet. but as more and more schools drop COBOL
>completely, well, one never knows. but then, I will probably be retired
>by then.
Perception matters. If employers believe all their future
prospective programmers will be Java programmers, they will consider
environments that will use Java programmers.
Unfortunately for them and us, this isn't the right approach. They
shouldn't planning around experts at using a particular tool such as
CoBOL or Java, but learn how to find people who can work with the
business and use multiple tools.
There will never be another one-shop language like CoBOL filling up IS
shops everywhere. IS is too complicated, pervasive, and broad in its
scope for one tool to fit all needs. We talk about the paradigm
change to OO, but a more important paradigm change needs to be in the
work place - in HR, in IS management, and in the minds of the
programmers. Our jobs aren't supplying CoBOL nor XML nor Java - but
defining what our jobs should be hasn't been defined across business
at all well.
Howard Brazee
>Does this make sense? No, if you know anything about the skills
>involved... yes, if you are looking for a specific set of letters in a
>resume. As I've posted before: there are times when I've submitted my
>bragsheet and heard 'I see a good amount of VSAM experience on IBM
>mainframes here but the client is looking specifically for experience with
>IDCAMS'.
Very true, I'd laugh more if I weren't crying.
Howard Brazee
>I'm not sure what are being called 'overall costs' here, Mr Dashwood...
>but somewhere in my admittedly porous memory is the figure of 70 - 80% of
>a shop's budget being spent on maintenance.
Whenever I see an IS shop moving from old technology to new
technology, I find the number of people who are employed behind the
scenes going up, while the number of people who work on applications
going down.
Some of that is because the new technology isn't in a closed room, so
we have new vulnerabilities to security and privacy needs. Some of
it is because we have so many different types of hardware, operating
systems, and software.
Bill Gunshannon
Howard Brazee <how...@brazee.net> writes:
> On 12 May 2009 13:41:52 GMT, bill...@cs.uofs.edu (Bill Gunshannon)
> wrote:
>
>>They are not desperate, yet. but as more and more schools drop COBOL
>>completely, well, one never knows. but then, I will probably be retired
>>by then.
>
> Perception matters. If employers believe all their future
> prospective programmers will be Java programmers, they will consider
> environments that will use Java programmers.
And if it will take them thousands of man-months to re-write everything?
>
> Unfortunately for them and us, this isn't the right approach. They
> shouldn't planning around experts at using a particular tool such as
> CoBOL or Java, but learn how to find people who can work with the
> business and use multiple tools.
>
> There will never be another one-shop language like CoBOL filling up IS
> shops everywhere. i
I don't think there ever was. I know in the COBOL shops I have worked
in there were other languages involved in many systems.
> IS is too complicated, pervasive, and broad in its
> scope for one tool to fit all needs. We talk about the paradigm
> change to OO, but a more important paradigm change needs to be in the
> work place - in HR, in IS management, and in the minds of the
> programmers. Our jobs aren't supplying CoBOL nor XML nor Java - but
> defining what our jobs should be hasn't been defined across business
> at all well.
One language never fit all. That won't change, But, like many
other things, being old also doesn't mean it needs to be replaced.
Bill Gunshannon
Howard Brazee <how...@brazee.net> writes:
> On Tue, 12 May 2009 14:36:31 +0000 (UTC), docd...@panix.com () wrote:
>
>>I'm not sure what are being called 'overall costs' here, Mr Dashwood...
>>but somewhere in my admittedly porous memory is the figure of 70 - 80% of
>>a shop's budget being spent on maintenance.
>
> Whenever I see an IS shop moving from old technology to new
> technology, I find the number of people who are employed behind the
> scenes going up, while the number of people who work on applications
> going down.
Yeah, that always amazed me. We (the University datacenter, not my
department) used to be an IBM shop with locally written applications
for all the administrative work needed to run a College. Then one
day the IBM Mainframe went out the door, replaced by a DEC Mini running
SCT Banner. And the Programmer Shop hired more people. They are at
least twice as large as they were when we maintained in house apps.
And, the current apps are much less flexible.
Howard Brazee
wrote:
>> Perception matters. If employers believe all their future
>> prospective programmers will be Java programmers, they will consider
>> environments that will use Java programmers.
>
>And if it will take them thousands of man-months to re-write everything?
Even in the old CoBOL environments, periodically we needed to re-write
most everything, moving from one platform to another. And nowadays
there are quite a few systems that people sell that are purported to
offer more new goodies at less cost (to their careers). So when
management compares such products, one criterion used is how difficult
it will be to maintain in the future.
New business systems tend to be organized around one live database,
data warehouses, and ways for their customers/salesmen/warehouse
workers/etc to use those databases. OO isn't a necessary part of
this process, but the companies that set up these systems know which
tools make their product look better to their customers (higher
management).
To go to this system, we have to re-write everything anyway, and maybe
the expensive older programmers will retire, allowing them to hire
kids.
When a company changes its process, re-writing old code to fit isn't
what they want. They want new code designed to the new process and
the new database.
docd...@panix.com
Howard Brazee <how...@brazee.net> wrote:
[snip]
>To go to this system, we have to re-write everything anyway, and maybe
>the expensive older programmers will retire, allowing them to hire
>kids.
Is it my imagination... or do younger workers also cost the company less
overall, as well?
DD
Pete Dashwood
> On 12 May 2009 13:41:52 GMT, bill...@cs.uofs.edu (Bill Gunshannon)
> wrote:
>
>> They are not desperate, yet. but as more and more schools drop COBOL
>> completely, well, one never knows. but then, I will probably be
>> retired by then.
>
> Perception matters. If employers believe all their future
> prospective programmers will be Java programmers, they will consider
> environments that will use Java programmers.
>
> Unfortunately for them and us, this isn't the right approach. They
> shouldn't planning around experts at using a particular tool such as
> CoBOL or Java, but learn how to find people who can work with the
> business and use multiple tools.
>
> There will never be another one-shop language like CoBOL filling up IS
> shops everywhere. IS is too complicated, pervasive, and broad in its
> scope for one tool to fit all needs. We talk about the paradigm
> change to OO, but a more important paradigm change needs to be in the
> work place - in HR, in IS management, and in the minds of the
> programmers. Our jobs aren't supplying CoBOL nor XML nor Java - but
> defining what our jobs should be hasn't been defined across business
> at all well.
Hear, Hear!
I have believed this for some time now, but this is the first time I have
seen anyone express it simply.
When I first moved away from using the Waterfall and into a completely
different development model I realised that although the new model was much
better, it wasn't perfect. Later I came to realise that there will never be
a single perfect methodology for very much the reasons you mention, Howard.
These days I take what has worked previously (including aspects of the
Waterfall, where appropriate) and try to adapt to the requirements (and
perceptions and expectations) of the job in hand. Some things definitely
work better than others, but I haven't found any ONE formal methodology that
is best for ALL circumstances. The Agile movement has got the closest in my
opinion, but even that is not "perfect".
Certainly we won't see the like of COBOL again. The world that spawned it
has gone.
As for finding people "who can work with the business and use multiple
tools", the rising generation is getting closer to this. They are getting a
broader, less language specific IT education and are more aware of the tools
and techniques available. But they lack business knowledge and can only
really acquire it on the job. (If they go for business knowledge in their
college education they end up with an MBA or Accounting qualification and
never go into programming.)
The fundamental programming paradigm has changed in response to the advent
of the Network. There is no going back to the procedural paradigm, except
for learning purposes and for batch processing. But you are absolutely right
that new paradigms for management and the rest of the business are also
emerging and some of these are not well understood yet, or even recognised
to be required by managers in the business.
IT is the tail of the organization; it is not the dog. Designing systems
around a particular toolset/language is just silly. The needs of the
business have to be identified and recognised, not by technocrats who see
everything through IT filters, but by business people who are helped to sit
down and analyse and enumerate what they actually need and want. (The role
of the Business Analyst is still a useful one. I was very surprised on the
last project I managed that many of the Business Analysts had NO programming
background. As time went by, I realized what a valuable role they fulfilled
nonetheless. Identifying and helping the business to untangle complex use
case scenarios, ensuring that business requirements were identified in the
correct logical sequence and stated clearly, and "thinking ahead" to
identify probable problems so that programming could have advanced notice,
were all valuable activities carried out by these people. Having at least
one of them present in JAD workshops was good for both the business and the
programmers.)
The days when an Applications Analyst interviewed someone in the business
and then wrote a specification that should be implemented verbatim (as if
the programmer were a mere automaton, not required to think, and just an
extension of the analyst) are over. At least, they are in organizations that
embrace change and view the future with eagerness rather than trepidation or
reluctance.
In what is fundamentally a programming forum, such as this one, it is normal
that the programmer's view is prevalent. This view concerns itself with
technology, languages, tools and paradigm shifts. But it is important to
remember that this is not the whole picture, even of it is an important part
of it.
Systems development in a modern environment is part of a joint effort. It
isn't about a given language or tool, it is about identifying a business
requirement then co-operating with all interested parties to use technical
skill and expertise in order to meet that requirement.
Pete Dashwood
> In article <cr9j05l9qo9jo0ead...@4ax.com>,
> Howard Brazee <how...@brazee.net> writes:
>> On 12 May 2009 13:41:52 GMT, bill...@cs.uofs.edu (Bill Gunshannon)
>> wrote:
>>
>>> They are not desperate, yet. but as more and more schools drop
>>> COBOL completely, well, one never knows. but then, I will probably
>>> be retired by then.
>>
>> Perception matters. If employers believe all their future
>> prospective programmers will be Java programmers, they will consider
>> environments that will use Java programmers.
>
> And if it will take them thousands of man-months to re-write
> everything?
This is why I am in favour of salvaging as much as possible. You can wrap
COBOL code as objects in minutes. There is no need to rewrite thousands of
lines of perfectly good code. Once it is wrapped it can be used with other
language objects and they can interact with it, instead of requiring
functionality to be re-developed, just for the sake of a new language. If
you haven't already, please read my thoughts on this at:
http://primacomputing.co.nz/cobol21
>
>>
>> Unfortunately for them and us, this isn't the right approach. They
>> shouldn't planning around experts at using a particular tool such as
>> CoBOL or Java, but learn how to find people who can work with the
>> business and use multiple tools.
Amen to that! This is one of the most significant and important sentences
that anyone has written in this forum for a considerable time.
>>
>> There will never be another one-shop language like CoBOL filling up
>> IS shops everywhere. i
>
> I don't think there ever was. I know in the COBOL shops I have worked
> in there were other languages involved in many systems.
I think you have to discount Assembler, Bill. It is primarily used in a
support role and systems programming environment.
I agree with Howard that COBOL WAS a one-shop language. I spent around 25
years making a living from COBOL and the sites I worked on (many and varied)
it was the only game in town. New requirements were immediately identified
in terms of COBOL. No attempt was made to look at the requirement purely as
a problem requiring solution; COBOL was the Way, the Truth, and the Life.
Maybe later (say, from the 1980s...) other things were put in the mix, but
for decades, COBOL ruled as King. (And it was a good reign which served us
well)
>
>> IS is too complicated, pervasive, and broad in its
>> scope for one tool to fit all needs. We talk about the paradigm
>> change to OO, but a more important paradigm change needs to be in the
>> work place - in HR, in IS management, and in the minds of the
>> programmers. Our jobs aren't supplying CoBOL nor XML nor Java -
>> but defining what our jobs should be hasn't been defined across
>> business at all well.
>
> One language never fit all.
It certainly did on commercial sites for a considerable time. It was MADE to
fit.
> That won't change, But, like many
> other things, being old also doesn't mean it needs to be replaced.
>
Sure it does... :-) We are all heading for the knacker's yard and will be
replaced in due time.
Arnold Trembley
> In article <76rqgrF...@mid.individual.net>,
> "Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
>> William M. Klein wrote: (snip)
>>> I know that DD, Arnold, Howard and a few other contractors who work
>>> with IBM mainframe COBOL post in this forum. However, I do think that
>>> this part of the existing COBOL base is significantly
>>> "under-represented" in comp.lang.cobol.
>> Why do you suppose that is, Bill?
>>
>> Is there still a culture of non-Internet/Usenet awareness and the idea that
>> PCs are toys and only mainframes are "real" computers?
>
> Somehow, I doubt that. It is probably more likely that the available
> COBOL resources on USENET are so limited (one group) that they find
> no real value here. One of the mosst common uses of programming
> language newsgroups is to get help with some obscure problem with
> a program or concept implementation. I expect that is much less
> needed with COBOL. (snip)
There are dozens of COBOL programmers in my shop, perhaps hundreds, many
of them contractors, plus overseas contractors in India. They all have
internet access and use it to read IBM manuals. I've yet to find
another programmer in my shop who has ever heard of usenet, or knows how
to get to usenet.
If they've heard of comp.lang.cobol at all, they would think it is owned
by Google Groups. I once knew a COBOL programmer who used Deja News to
search comp.lang.cobol until Deja News went away, but he's retired now.
In my opinion you could make a better argument that usenet is dead, not
COBOL. I know many people who are not programmers but who use the
internet a lot, and they have no idea what usenet is.
For the applications I work with, COBOL is the best alternative for the
foreseeable future. It is stable, scalable, efficient, well-supported
by IBM, and programmers are available. It may not be exciting or sexy,
but the applications are profitable, and they work.
Pete Dashwood
Thanks Arnold.
I found your post enlightening and saddening at the same time.
Usenet isn't dead, BTW... there are new groups being added almost daily.
Fortunately, most Internet users are unaware of it, just as the people you
described are. While people are subscribing to blogs, social networks, and
news feeds (RSS) they have little need for a "user group" or even any kind
of shared interest group. And yet, almost every time I log on to my News
server it tells me that "new groups are available" and asks if I want to
subscribe to them. (the current count is over 90,000 available groups...)
This group (comp.lang.cobol) is extremely valuable because it is an
unmoderated group and it isn't owned or controlled by any specific
corporation.
That makes it one of the last bastions of free speech left on the planet.
It is a tribute to the people who come here that there is little flaming and
abuse; most groups need a moderator to ensure that.
I see it as a useful place where some very bright (and funny :-)) people can
hang out and posting here is often a form of stress relief for me. I can get
really fed up with what I'm doing and can spend an hour here, then go back
to it refreshed and recharged.
If IBM programmers are unaware that this group exists or that there are
specifc IBM groups for them (Bill posted some recently) then I see that as a
sad loss for them. I hope some more of them come here.
Bill Gunshannon
Not necessarily your imagination but something many people have
tried to push out as reality. Unless you say that because they
have less experience they have lower salaries, which is paying
for less skill and not because they are younger, other expenses
to the company are pretty much the same regardless of age. Well,
I guess there is number of vacation days, too, but that again is
not because of age but experience.
Bill Gunshannon
"Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
> Bill Gunshannon wrote:
>> In article <cr9j05l9qo9jo0ead...@4ax.com>,
>> Howard Brazee <how...@brazee.net> writes:
>>>
>>>
>>> There will never be another one-shop language like CoBOL filling up
>>> IS shops everywhere. i
>>
>> I don't think there ever was. I know in the COBOL shops I have worked
>> in there were other languages involved in many systems.
>
> I think you have to discount Assembler, Bill. It is primarily used in a
> support role and systems programming environment.
Didn't mean just assembler. My first COBOL shop also used Fortran.
My second used COBOL, Fortran, Basic, CTS (Conversation Timesharing
which looked like a stripped down Basic) and after my arrival Pascal.
Next COBOL shop wasn't really a COBOL shop but it used it. And they
used a whole bunch more.
>
> I agree with Howard that COBOL WAS a one-shop language. I spent around 25
> years making a living from COBOL and the sites I worked on (many and varied)
> it was the only game in town. New requirements were immediately identified
> in terms of COBOL. No attempt was made to look at the requirement purely as
> a problem requiring solution; COBOL was the Way, the Truth, and the Life.
>
> Maybe later (say, from the 1980s...) other things were put in the mix, but
> for decades, COBOL ruled as King. (And it was a good reign which served us
> well)
And all those I listed above were 1979 and on. So, it looks like if
COBOL shops were one-trick ponies it started changing by 1980.
>>
>>> IS is too complicated, pervasive, and broad in its
>>> scope for one tool to fit all needs. We talk about the paradigm
>>> change to OO, but a more important paradigm change needs to be in the
>>> work place - in HR, in IS management, and in the minds of the
>>> programmers. Our jobs aren't supplying CoBOL nor XML nor Java -
>>> but defining what our jobs should be hasn't been defined across
>>> business at all well.
>>
>> One language never fit all.
>
> It certainly did on commercial sites for a considerable time. It was MADE to
> fit.
True I guess for most pure business shops. But then, many of them were
also likely to run RPG as well.
>
>
>> That won't change, But, like many
>> other things, being old also doesn't mean it needs to be replaced.
>>
>
> Sure it does... :-) We are all heading for the knacker's yard and will be
> replaced in due time.
I'm ready. Someone please replace me!! I think I hear a golf course calling
my name.
docd...@panix.com
Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>In article <gud05e$eur$1...@reader1.panix.com>,
> docd...@panix.com () writes:
>> In article <aomj05di0kbecerpc...@4ax.com>,
>> Howard Brazee <how...@brazee.net> wrote:
>>
>> [snip]
>>
>>>To go to this system, we have to re-write everything anyway, and maybe
>>>the expensive older programmers will retire, allowing them to hire
>>>kids.
>>
>> Is it my imagination... or do younger workers also cost the company less
>> overall, as well?
>
>Not necessarily your imagination but something many people have
>tried to push out as reality. Unless you say that because they
>have less experience they have lower salaries, which is paying
>for less skill and not because they are younger, other expenses
>to the company are pretty much the same regardless of age. Well,
>I guess there is number of vacation days, too, but that again is
>not because of age but experience.
Lower salaries, lower insurance premiums, fewer benefits that come from
seniority (vacation time, tuition reimbursement), greater ability to
concentrate on corporate matters due to fewer family distractions... time,
money and concentration.
(small humor: a worker in a related group recently gave birth to a child
and was not available for the 'workload-plus' that other, childless
members of the group were carrying... talk turned to grumbling about this
and someone said 'So she chose to have a kid... why should *I* have to
pick up her slack? *I* didn't have a kid!'
My response was 'You didn't have it? Haw... you didn't even get the
questionable pleasure of being allowed to watch its being conceived!')
DD
Bill Gunshannon
docd...@panix.com () writes:
> In article <7708gfF...@mid.individual.net>,
> Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>>In article <gud05e$eur$1...@reader1.panix.com>,
>> docd...@panix.com () writes:
>>> In article <aomj05di0kbecerpc...@4ax.com>,
>>> Howard Brazee <how...@brazee.net> wrote:
>>>
>>> [snip]
>>>
>>>>To go to this system, we have to re-write everything anyway, and maybe
>>>>the expensive older programmers will retire, allowing them to hire
>>>>kids.
>>>
>>> Is it my imagination... or do younger workers also cost the company less
>>> overall, as well?
>>
>>Not necessarily your imagination but something many people have
>>tried to push out as reality. Unless you say that because they
>>have less experience they have lower salaries, which is paying
>>for less skill and not because they are younger, other expenses
>>to the company are pretty much the same regardless of age. Well,
>>I guess there is number of vacation days, too, but that again is
>>not because of age but experience.
>
> Lower salaries,
Not specific to age. A 60 year old guy with no experince is going to get
a lower salary, too. You are paying less for lower ability, not age.
> lower insurance premiums,
I've heard this before, but never saw any evidence to support it. Our
plan (Blue Cross/Blue Shield) seems to be based totally on numbers and
single or family coverage. And par tof that difference is carried by
the individual.
> fewer benefits that come from
> seniority (vacation time, tuition reimbursement),
Same as pay. Not becasue of age, per se, but level of experience.
> greater ability to
> concentrate on corporate matters due to fewer family distractions...
Don't get that one at all. Younger people have families, too, and are
more likely to have family related problems that distract them from their
jobs. All my family is married and moved away and my wife has her own
career. No family distractions at all, really.
> time,
We all have the same amount of time. Younger people are much more likely
to have a social life outside of work. I know I don't!!
> money
Money?
> and concentration.
I would expect that 22 year old is much more distracted than I or my peers
are. They have so much to worry about.... Acne... The girl in the next
cubicle... Those "Three Doors Down" tickets they are bidding for on Ebay...
>
> (small humor: a worker in a related group recently gave birth to a child
> and was not available for the 'workload-plus' that other, childless
> members of the group were carrying... talk turned to grumbling about this
> and someone said 'So she chose to have a kid... why should *I* have to
> pick up her slack? *I* didn't have a kid!'
Sounds like a management problem. What I do outside the office should
have no bearing whatsoever on what my office workload is.
>
> My response was 'You didn't have it? Haw... you didn't even get the
> questionable pleasure of being allowed to watch its being conceived!')
I have never thought of it as a sepctator sport.
docd...@panix.com
A sixty-year-old person has, in many cases, a few decades to garner a bit
of work experience. It may not be specific to the task at hand, true...
but unless the older worker has been out of the workforce, period, they
have a greater amount of work experience. When a worker stays in a
particular field the disparity becomes obvious. From
<http://www.businessfairfield.com/webpdf/NextSteps.pdf> :
--begin quoted text:
The report also noted that jobs held by older workers in the utilities and
management industries paid the highest median quarterly earnings, each
exceeding $17,000 in the fourth quarter of 2006. Other high paying
industries for older workers include finance and insurance, manufacturing,
mining, construction, and 6 professional and technical services. The
report found that older workers (65+) saw their median earnings increase
by as much as 7.4% across the industry spectrum, supporting the view that
older workers with appropriate skills are rewarded financially.
[snip]
Older workers tend to emphasize experience over job skills. However,
experience is often a code word for age, a negative in a job interview.
--end quoted text
>
>> lower insurance premiums,
>
>I've heard this before, but never saw any evidence to support it. Our
>plan (Blue Cross/Blue Shield) seems to be based totally on numbers and
>single or family coverage. And par tof that difference is carried by
>the individual.
From http://www.cbo.gov/ftpdocs/87xx/doc8712/10-31-HealthInsurModel.pdf :
--begin quoted text:
Individual-Level Expected Health Spending. Individual-level expected
health spending is estimated as the product of five factors:
Expected health spending = age-sex factor x health factor x experience
factor x state cost factor x base
Age-Sex Factor. The age-sex factor is the ratio of expected spending per
person within a specific age-sex group to overall expected spending per
person.
[snip]
Age-sex factors for the nonelderly range from 0.46 for children ages 2 to
17 to 2.8 for 64-year-old males.
--end quoted text
Note that age-sex factor is multiplicative and increases with age. Other
factors may mitigate this... but age-sex is still a multiplicative factor
in the expected health-spending equation.
>
>> fewer benefits that come from
>> seniority (vacation time, tuition reimbursement),
>
>Same as pay. Not becasue of age, per se, but level of experience.
Not according to any HR schedules I have ever seen... but my experience,
granted, is limited. (n) years with the firm = (y) weeks of vacation, no
matter what courses one passes.
>
>> greater ability to
>> concentrate on corporate matters due to fewer family distractions...
>
>Don't get that one at all. Younger people have families, too, and are
>more likely to have family related problems that distract them from their
>jobs. All my family is married and moved away and my wife has her own
>career. No family distractions at all, really.
From http://www.usatoday.com/news/health/2005-11-16-young-wed_x.htm :
--begin quoted text:
The average age at first marriage in the USA has been inching upward;
it's now 26 for women and 27 for men.
--end quoted text
Assuming a college-graduation age of 22 if you have a new hire with the
latest technology fresh out of school that's a half-decade without a
spouse.
[snip]
>> (small humor: a worker in a related group recently gave birth to a child
>> and was not available for the 'workload-plus' that other, childless
>> members of the group were carrying... talk turned to grumbling about this
>> and someone said 'So she chose to have a kid... why should *I* have to
>> pick up her slack? *I* didn't have a kid!'
>
>Sounds like a management problem. What I do outside the office should
>have no bearing whatsoever on what my office workload is.
How old one is should have no bearing whatsoever on how suitable a person
is for being hired. That it is seen otherwise has resulted in a variety
of anti-age-discrimination laws and successful age-discrimination
lawsuits. 'Should be' does not equal 'is'.
>> My response was 'You didn't have it? Haw... you didn't even get the
>> questionable pleasure of being allowed to watch its being conceived!')
>
>I have never thought of it as a sepctator sport.
http://www.stlyrics.com/lyrics/avenueq/theinternetisforporn.htm
DD
Bill Gunshannon
But even within the same field changing jobs can out you back at the
beginning. A few years ago I turned down a job because while the
salary was nice they wanted me to go back to 1 week of vacation and
wait almost 10 years until I got another. Just like a guy hired off
the street. My age not withstanding!!
And, if you happen to be changing fields it doesn't matter if you had
30 years experience in the previous field, you are entry level and will
be paid accordingly, regardless of your age. As a matter of fact, if
you are starting over and are already middle-aged or worse, you will
probably be offered even less than the younger guy because they will
see more of a future long-term development in him.
>
> --begin quoted text:
>
> The report also noted that jobs held by older workers in the utilities and
> management industries paid the highest median quarterly earnings, each
> exceeding $17,000 in the fourth quarter of 2006. Other high paying
> industries for older workers include finance and insurance, manufacturing,
> mining, construction, and 6 professional and technical services. The
> report found that older workers (65+) saw their median earnings increase
> by as much as 7.4% across the industry spectrum, supporting the view that
> older workers with appropriate skills are rewarded financially.
>
> [snip]
>
> Older workers tend to emphasize experience over job skills. However,
> experience is often a code word for age, a negative in a job interview.
>
> --end quoted text
Ain't that a fact!! I have always gotten a kick out of the idea that
it is illegal to ask an applicants age but you can ask for his entire
work history. When your work history goes back 40 years, how old do
you think the applicant is? And then there is education information.
If I graduated from High School in 1968 I'll bet they can come real
close to computing my age without having to ask me.
>
>>
>>> lower insurance premiums,
>>
>>I've heard this before, but never saw any evidence to support it. Our
>>plan (Blue Cross/Blue Shield) seems to be based totally on numbers and
>>single or family coverage. And par tof that difference is carried by
>>the individual.
>
> From http://www.cbo.gov/ftpdocs/87xx/doc8712/10-31-HealthInsurModel.pdf :
>
> --begin quoted text:
>
> Individual-Level Expected Health Spending. Individual-level expected
> health spending is estimated as the product of five factors:
>
> Expected health spending = age-sex factor x health factor x experience
> factor x state cost factor x base
>
> Age-Sex Factor. The age-sex factor is the ratio of expected spending per
> person within a specific age-sex group to overall expected spending per
> person.
>
> [snip]
>
> Age-sex factors for the nonelderly range from 0.46 for children ages 2 to
> 17 to 2.8 for 64-year-old males.
>
> --end quoted text
>
> Note that age-sex factor is multiplicative and increases with age. Other
> factors may mitigate this... but age-sex is still a multiplicative factor
> in the expected health-spending equation.
Yes, but is that what the insurance company is paying or what they are
billing the companies who use them? I always assumed they averaged the
risk out over all of a client company's employees.
>
>>
>>> fewer benefits that come from
>>> seniority (vacation time, tuition reimbursement),
>>
>>Same as pay. Not becasue of age, per se, but level of experience.
>
> Not according to any HR schedules I have ever seen... but my experience,
> granted, is limited. (n) years with the firm = (y) weeks of vacation, no
> matter what courses one passes.
Right, time with company, not age determines vacation time. 20 year old
and 40 year old start on same day. Both have 1 week vacation. 5 years
later one is 25 and the other 45. Both have 2 weeks vacation. Pretty
much the same with tuition reimbursement except that the older person is
much less likely to be interested in it.
>
>>
>>> greater ability to
>>> concentrate on corporate matters due to fewer family distractions...
>>
>>Don't get that one at all. Younger people have families, too, and are
>>more likely to have family related problems that distract them from their
>>jobs. All my family is married and moved away and my wife has her own
>>career. No family distractions at all, really.
>
> From http://www.usatoday.com/news/health/2005-11-16-young-wed_x.htm :
>
> --begin quoted text:
>
> The average age at first marriage in the USA has been inching upward;
> it's now 26 for women and 27 for men.
>
> --end quoted text
>
> Assuming a college-graduation age of 22 if you have a new hire with the
> latest technology fresh out of school that's a half-decade without a
> spouse.
>
> [snip]
And when he reaches 50, you have an experienced professional who has no
kids cause they are all married and moved away. And what about his SO
or whatever they are calling it now-a-days when they live together but
aren't married. Same distractions a a spouse with less statistics to show
for it.
>
>>> (small humor: a worker in a related group recently gave birth to a child
>>> and was not available for the 'workload-plus' that other, childless
>>> members of the group were carrying... talk turned to grumbling about this
>>> and someone said 'So she chose to have a kid... why should *I* have to
>>> pick up her slack? *I* didn't have a kid!'
>>
>>Sounds like a management problem. What I do outside the office should
>>have no bearing whatsoever on what my office workload is.
>
> How old one is should have no bearing whatsoever on how suitable a person
> is for being hired.
I agree, but reality is seldom the same as utopian ideas.
> That it is seen otherwise has resulted in a variety
> of anti-age-discrimination laws and successful age-discrimination
> lawsuits. 'Should be' does not equal 'is'.
Most cases of age discrimination in hiring cn not be proved and almost
never result in a lawsuit. The hiring company would have to be total
idiots to handle it in a way that resulted in a lawsuit.
>
>>> My response was 'You didn't have it? Haw... you didn't even get the
>>> questionable pleasure of being allowed to watch its being conceived!')
>>
>>I have never thought of it as a sepctator sport.
>
> http://www.stlyrics.com/lyrics/avenueq/theinternetisforporn.htm
bill
docd...@panix.com
Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>In article <guevml$qm9$1...@reader1.panix.com>,
> docd...@panix.com () writes:
>> In article <770ajeF...@mid.individual.net>,
>> Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>>>In article <guergf$ahu$1...@reader1.panix.com>,
>>> docd...@panix.com () writes:
[snip]
>>>> Lower salaries,
>>>
>>>Not specific to age. A 60 year old guy with no experince is going to get
>>>a lower salary, too. You are paying less for lower ability, not age.
>>
>> A sixty-year-old person has, in many cases, a few decades to garner a bit
>> of work experience. It may not be specific to the task at hand, true...
>> but unless the older worker has been out of the workforce, period, they
>> have a greater amount of work experience. When a worker stays in a
>> particular field the disparity becomes obvious. From
>> <http://www.businessfairfield.com/webpdf/NextSteps.pdf> :
>
>But even within the same field changing jobs can out you back at the
>beginning. A few years ago I turned down a job because while the
>salary was nice they wanted me to go back to 1 week of vacation and
>wait almost 10 years until I got another. Just like a guy hired off
>the street. My age not withstanding!!
'The salary was nice'... you mean better than a kid without the
experience? As for the vacation bit... I've had that discussion with
managers before, the mantra is always 'HR won't let us'.
[conjecture snipped]
>> --begin quoted text:
>>
>> The report also noted that jobs held by older workers in the utilities and
>> management industries paid the highest median quarterly earnings, each
>> exceeding $17,000 in the fourth quarter of 2006. Other high paying
>> industries for older workers include finance and insurance, manufacturing,
>> mining, construction, and 6 professional and technical services. The
>> report found that older workers (65+) saw their median earnings increase
>> by as much as 7.4% across the industry spectrum, supporting the view that
>> older workers with appropriate skills are rewarded financially.
>>
>> [snip]
>>
>> Older workers tend to emphasize experience over job skills. However,
>> experience is often a code word for age, a negative in a job interview.
>>
>> --end quoted text
>
>Ain't that a fact!!
Ain't that what I've been saying... and you've been disagreeing with?
>I have always gotten a kick out of the idea that
>it is illegal to ask an applicants age but you can ask for his entire
>work history.
Even easier... you cannot ask age but you can ask for birth-date.
When your work history goes back 40 years, how old do
>you think the applicant is? And then there is education information.
>If I graduated from High School in 1968 I'll bet they can come real
>close to computing my age without having to ask me.
>
>>
>>>
>>>> lower insurance premiums,
>>>
[snip]
>> From http://www.cbo.gov/ftpdocs/87xx/doc8712/10-31-HealthInsurModel.pdf :
[snip]
>> Note that age-sex factor is multiplicative and increases with age. Other
>> factors may mitigate this... but age-sex is still a multiplicative factor
>> in the expected health-spending equation.
>
>Yes, but is that what the insurance company is paying or what they are
>billing the companies who use them? I always assumed they averaged the
>risk out over all of a client company's employees.
If that is the case... then the higher the number of older employees the
greater the average rate and the higher the overall multiplicative factor,
an impetus to Keep The Geezers Out.
>>>> fewer benefits that come from
>>>> seniority (vacation time, tuition reimbursement),
>>>
>>>Same as pay. Not becasue of age, per se, but level of experience.
>>
>> Not according to any HR schedules I have ever seen... but my experience,
>> granted, is limited. (n) years with the firm = (y) weeks of vacation, no
>> matter what courses one passes.
>
>Right, time with company, not age determines vacation time.
Hence... an older worker, one with the company longer, generates more
expense.
[snip]
>Pretty
>much the same with tuition reimbursement except that the older person is
>much less likely to be interested in it.
Not in my experience. Younger workers come in already trained in the
newer technologies; when an older worker requests a course the run into
Educational Catch-22:
If you are doing your job you already know it and you don't have to learn
it so you aren't entitled to reimbursement.
If you have to learn it then it isn't part of your job and is not
work-related and you aren't entitled to reimbursement.
[snip]
>> Assuming a college-graduation age of 22 if you have a new hire with the
>> latest technology fresh out of school that's a half-decade without a
>> spouse.
>>
>> [snip]
>
>And when he reaches 50, you have an experienced professional who has no
>kids cause they are all married and moved away.
... and will be accustomed to earning a Decent Wage. Can't have *that*,
now can we?
[snip]
>> How old one is should have no bearing whatsoever on how suitable a person
>> is for being hired.
>
>I agree, but reality is seldom the same as utopian ideas.
This is what I have been asserting from the start, that what the Hiring
Office approves is not always what is most productive for the company.
>> That it is seen otherwise has resulted in a variety
>> of anti-age-discrimination laws and successful age-discrimination
>> lawsuits. 'Should be' does not equal 'is'.
>
>Most cases of age discrimination in hiring cn not be proved and almost
>never result in a lawsuit.
Cite? I'll accept 'most' as a mere 50.1% over a ten-year span across 30%
of the country.
(did you know that 86.725% of all UseNet statistics are made up on the
spot?)
>The hiring company would have to be total
>idiots to handle it in a way that resulted in a lawsuit.
Best not to hire them in the first place because 'we've found a better
fit' (who just happens to be younger, of course)... but what to do with
the ones you already have?
<http://www.minnpost.com/businessagenda/2009/05/05/8567/3m_faces_another_age-discrimination_lawsuit>
<http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9025759>
These are just three... from 3M, Livermore Labs and Best Buy.
Manufacturing, research and retail, and some of the biggest in their
fields.
The best and the brightest, in my experience, do not wind up in HR... and
that is where such decisions are made.
DD
Howard Brazee
wrote:
>> (small humor: a worker in a related group recently gave birth to a child
>> and was not available for the 'workload-plus' that other, childless
>> members of the group were carrying... talk turned to grumbling about this
>> and someone said 'So she chose to have a kid... why should *I* have to
>> pick up her slack? *I* didn't have a kid!'
>
>Sounds like a management problem. What I do outside the office should
>have no bearing whatsoever on what my office workload is.
But when you take vacation, medical leave, paternal leave, or
whatever, does the amount of work the office has go down?
Howard Brazee
wrote:
>Right, time with company, not age determines vacation time. 20 year old
>and 40 year old start on same day. Both have 1 week vacation. 5 years
>later one is 25 and the other 45. Both have 2 weeks vacation. Pretty
>much the same with tuition reimbursement except that the older person is
>much less likely to be interested in it.
I got my masters when I was older than those ages - mainly because I
didn't have confidence that my skills would keep me in a job until
retirement.
Getting a degree to have a job would apply to those who haven't
started their careers, and those who notice that their careers are
changing away from their skills.
Howard Brazee
>If that is the case... then the higher the number of older employees the
>greater the average rate and the higher the overall multiplicative factor,
>an impetus to Keep The Geezers Out.
One problem with older workers is that so many companies and unions
have pension plans that are largely funded by empty promises. (see
American auto companies).
So they don't want to hire people who will retire on their shift.
If they just contributed to externally run pension plans, then the
retirement moneys won't ever come due (as expenses to the company).
I'm not sure that most tech companies find great value in employees
sticking around for decades, so if someone is a good fit and intends
to retire in 5 years, that could be a good thing. He might stick
around longer than the kid who is just wanting to salary jump.
Howard Brazee
wrote:
>I'm ready. Someone please replace me!! I think I hear a golf course calling
>my name.
When Tiger Woods retires, will he take up CoBOL?
Bill Gunshannon
The salary offered was comensurate with my level of expertise and above
the amount I had set as my target.
> As for the vacation bit... I've had that discussion with
> managers before, the mantra is always 'HR won't let us'.
Pretty much what they said.
>
> [conjecture snipped]
>
>>> --begin quoted text:
>>>
>>> The report also noted that jobs held by older workers in the utilities and
>>> management industries paid the highest median quarterly earnings, each
>>> exceeding $17,000 in the fourth quarter of 2006. Other high paying
>>> industries for older workers include finance and insurance, manufacturing,
>>> mining, construction, and 6 professional and technical services. The
>>> report found that older workers (65+) saw their median earnings increase
>>> by as much as 7.4% across the industry spectrum, supporting the view that
>>> older workers with appropriate skills are rewarded financially.
>>>
>>> [snip]
>>>
>>> Older workers tend to emphasize experience over job skills. However,
>>> experience is often a code word for age, a negative in a job interview.
>>>
>>> --end quoted text
>>
>>Ain't that a fact!!
>
> Ain't that what I've been saying... and you've been disagreeing with?
Sorry, I didn't zero in on your saying age discrimination. I saw
"facts" being posted that tried to justify the situation financially
and via other means than just, "I don't want to hire that old bastard."
>
>>I have always gotten a kick out of the idea that
>>it is illegal to ask an applicants age but you can ask for his entire
>>work history.
>
> Even easier... you cannot ask age but you can ask for birth-date.
Actually, I don't believe that is true. I think (with the exception
of the government) you can not ask for Date of Birth. But I have
been out of that part of the business for a long time.
>
> When your work history goes back 40 years, how old do
>>you think the applicant is? And then there is education information.
>>If I graduated from High School in 1968 I'll bet they can come real
>>close to computing my age without having to ask me.
>>
>>>
>>>>
>>>>> lower insurance premiums,
>>>>
>
> [snip]
>
>>> From http://www.cbo.gov/ftpdocs/87xx/doc8712/10-31-HealthInsurModel.pdf :
>
> [snip]
>
>>> Note that age-sex factor is multiplicative and increases with age. Other
>>> factors may mitigate this... but age-sex is still a multiplicative factor
>>> in the expected health-spending equation.
>>
>>Yes, but is that what the insurance company is paying or what they are
>>billing the companies who use them? I always assumed they averaged the
>>risk out over all of a client company's employees.
>
> If that is the case... then the higher the number of older employees the
> greater the average rate and the higher the overall multiplicative factor,
> an impetus to Keep The Geezers Out.
Yeah, but not likely to affect onesies. More likely just try to keep
the average at some common point. get that guy with experience but
offset it with another guy fresh out of school.
>
>>>>> fewer benefits that come from
>>>>> seniority (vacation time, tuition reimbursement),
>>>>
>>>>Same as pay. Not becasue of age, per se, but level of experience.
>>>
>>> Not according to any HR schedules I have ever seen... but my experience,
>>> granted, is limited. (n) years with the firm = (y) weeks of vacation, no
>>> matter what courses one passes.
>>
>>Right, time with company, not age determines vacation time.
>
> Hence... an older worker, one with the company longer, generates more
> expense.
No, a 30 year old who has been there 10 years cost the same as a 50 year
old who has been there 10 years. Age does not necessarily equate to time
with any particular company. When I was in the contractor game (belt-way
bandit) nobody had 10 years with any company. staying in one place for
very long was considered stagnating and actually decreased your value.
4-5 years between job changes was common and real go-getters cahnged
every 2-3 years.
>
> [snip]
>
>>Pretty
>>much the same with tuition reimbursement except that the older person is
>>much less likely to be interested in it.
>
> Not in my experience. Younger workers come in already trained in the
> newer technologies; when an older worker requests a course the run into
> Educational Catch-22:
>
> If you are doing your job you already know it and you don't have to learn
> it so you aren't entitled to reimbursement.
>
> If you have to learn it then it isn't part of your job and is not
> work-related and you aren't entitled to reimbursement.
Oh, sorry again. I thought you were talking about College Tuition Benifits
which some companies offer. Not training for the current job. College
Tuition Benifits can be a downside with younger employees. You pay for
them to get an education and they are still mobile enough to go out with
the education you paid for and find a better job.
>
> [snip]
>
>>> Assuming a college-graduation age of 22 if you have a new hire with the
>>> latest technology fresh out of school that's a half-decade without a
>>> spouse.
>>>
>>> [snip]
>>
>>And when he reaches 50, you have an experienced professional who has no
>>kids cause they are all married and moved away.
>
> ... and will be accustomed to earning a Decent Wage. Can't have *that*,
> now can we?
I have been in my current job for 20 years. They don't pay me what I
consider a decent wage. And, unlike my younger counterparts who, having
no real comittments, can easily look for another job it has been my
spouse who has kept me (until recently) from looking for a better paying
job. Unfortunately, I now have to fight the age wall.
>
> [snip]
>
>>> How old one is should have no bearing whatsoever on how suitable a person
>>> is for being hired.
>>
>>I agree, but reality is seldom the same as utopian ideas.
>
> This is what I have been asserting from the start, that what the Hiring
> Office approves is not always what is most productive for the company.
No argument there. And newer methods, like relying on systems like
RESUMIX actually go further to finding you the least qualified people
while specificly excluding those who are probably better.
>
>>> That it is seen otherwise has resulted in a variety
>>> of anti-age-discrimination laws and successful age-discrimination
>>> lawsuits. 'Should be' does not equal 'is'.
>>
>>Most cases of age discrimination in hiring cn not be proved and almost
>>never result in a lawsuit.
>
> Cite? I'll accept 'most' as a mere 50.1% over a ten-year span across 30%
> of the country.
I put in for a job.
I have 30 years of IT experience specific to the job.
I am 59 years old.
I present myself well at the interview.
The manager says, "Make him an offer."
HR offers me $40,000/yr, half what I am earning in my current position.
Was this age discrimination?
Care to try and prove it?
>
> (did you know that 86.725% of all UseNet statistics are made up on the
> spot?)
I thought it was 89% of all statistics are made up?
>
>>The hiring company would have to be total
>>idiots to handle it in a way that resulted in a lawsuit.
>
> Best not to hire them in the first place because 'we've found a better
> fit' (who just happens to be younger, of course)... but what to do with
> the ones you already have?
See my example above. Much better to just get the person to turn the
offer down. Then he can never say he was discriminated against. He
was, in fact, offered a job that he declined.
>
> <http://www.minnpost.com/businessagenda/2009/05/05/8567/3m_faces_another_age-discrimination_lawsuit>
>
> <http://esciencenews.com/sources/physorg/2009/02/04/lawrence.livermore.lab.faces.age.discrimination.lawsuits>
>
> <http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9025759>
>
> These are just three... from 3M, Livermore Labs and Best Buy.
> Manufacturing, research and retail, and some of the biggest in their
> fields.
I'll take a look. I can always use a good laugh.
>
> The best and the brightest, in my experience, do not wind up in HR... and
> that is where such decisions are made.
How true. I was once told, "Because you are currently on active duty
with the Army (I was attending a 6 month school) and we want to fill
this position right away, we will not make you an offer." Supposedly
illegal as my Army Reserve status can not be held against me, but....
Oh yeah, the organization that did that - The US Army. It was a DA
Civilian position.
Bill Gunshannon
Howard Brazee <how...@brazee.net> writes:
> On 13 May 2009 16:25:18 GMT, bill...@cs.uofs.edu (Bill Gunshannon)
> wrote:
>
>>> (small humor: a worker in a related group recently gave birth to a child
>>> and was not available for the 'workload-plus' that other, childless
>>> members of the group were carrying... talk turned to grumbling about this
>>> and someone said 'So she chose to have a kid... why should *I* have to
>>> pick up her slack? *I* didn't have a kid!'
>>
>>Sounds like a management problem. What I do outside the office should
>>have no bearing whatsoever on what my office workload is.
>
> But when you take vacation, medical leave, paternal leave, or
> whatever, does the amount of work the office has go down?
If you agreed to let me take the time off when you hired me and weren't
prepared to deal with it, management problem.
As for how age realtes to this, I am in the older catagory. :-) I can
not remember the last time I took a sick day. My daughter, 30 years my
younger, uses all of hers every year.
docd...@panix.com
Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>In article <guf2vm$aqh$1...@reader1.panix.com>,
> docd...@panix.com () writes:
>> In article <770f5fF...@mid.individual.net>,
>> Bill Gunshannon <bill...@cs.uofs.edu> wrote:
[snip]
>>>Ain't that a fact!!
>>
>> Ain't that what I've been saying... and you've been disagreeing with?
>
>Sorry, I didn't zero in on your saying age discrimination.
Well, glad we got that cleared up, then... on to the next?
DD
William M. Klein
I have only been working with IBM mainframe COBOL shops since 1978. (I know
there are posters here who worked in/with such shops before that).
Almost ALL of the shops that I know of had a mix of (at least) Assembler, COBOL,
and PL/I. In addition, Fortran was relatively common and (eventually) C/C++ were
added to the mix. You could get a "glimpse" of this from the IBM User group
paper "Language Futures" that was published (I think) in the early 1990s. That
paper (and a lot of other things) led to the IBM delivery of
Language Environment (LE)
which (long before and SLIGHTLY) like '.NET" CLR provides a common "urn-time
environment" for all (most) IBM mainframe programming languages. One of its
major goals was to "ease" the mixture of languages in the same application (much
less same shop. Interestingly enough, the first (early) release of LE provided
only for mixing COBOL and C. (PL/I came in the next release and Fortran - was
relatively early - but with restrictions).
I am certain that there were some "COBOL only" shops out there (in IBM mainframe
world) somewhere, but they were in the minority from AT LEAST the mid-70's - and
probably earlier. (In part, I think this was due to IBM "pushing" PL/I for
quite a while - while the business community was still happy with COBOL)
--
Bill Klein
wmklein <at> ix.netcom.com
Pete Dashwood
Ouch! My experience is that RPG was treated with scorn and derision in COBOL
shops and generally never got through the door.
Commercial shops fell into one of 3 categories:
1. COBOL.
2. PL/1
3. RPG
...with each defending their turf with vigour. There was very little (NONE
with PL/1 : COBOL) "cross pollination" between these camps.
>>
>>
>>> That won't change, But, like many
>>> other things, being old also doesn't mean it needs to be replaced.
>>>
>>
>> Sure it does... :-) We are all heading for the knacker's yard and
>> will be replaced in due time.
>
> I'm ready. Someone please replace me!! I think I hear a golf course
> calling my name.
>
> bill
--
Pete Dashwood
> (previous info snipped),
>
> I have only been working with IBM mainframe COBOL shops since 1978. (I
> know there are posters here who worked in/with such shops before
> that).
> Almost ALL of the shops that I know of had a mix of (at least)
> Assembler, COBOL, and PL/I.
1978. 2 years before 1980...:-)
There was very little "mixing" (apart from Assembler) in the places I worked
during the 60s and 70s. I never saw a site where both PL/1 and COBOL were
in common use. There might be a pilot project, but after that it would
revert back to what it was.
I feel sure that this changed in the 80s when C and Java were added to the
mix, and I'm not questioning what you said about the "evolution" of LE.
(By the time LE arrived, I was no longer working on mainframe COBOL.)
My comments where I said that "COBOL was King" were based on experience in
the 60s and 70s.
In addition, Fortran was relatively
> common and (eventually) C/C++ were added to the mix.
I knew one NCR site where Fortran was the main language (in the 1960s) and
CDC used it extensively and as a matter of course. (In fact, I was involved
in the "commercial applications" division they set up which used their COBOL
compiler, in the early 1970s... we had to scrape the cobwebs off the COBOL
and everyone thought it was a very strange thing...actually, their COBOL
compiler was excellent, like most of their other hardware and software.)
With the exception of those two instances, I never saw Fortran used on a
cmmercial site for anything other than interest/entertainment vale. I taught
myself Fortran in the 60s because I thought it might be useful. It never
was... (for me, at least; I accept it was of great use to a number of other
people)
You could get a
> "glimpse" of this from the IBM User group paper "Language Futures"
> that was published (I think) in the early 1990s. That paper (and a
> lot of other things) led to the IBM delivery of
> Language Environment (LE)
>
> which (long before and SLIGHTLY) like '.NET" CLR provides a common
> "urn-time environment" for all (most) IBM mainframe programming
> languages. One of its major goals was to "ease" the mixture of
> languages in the same application (much less same shop. Interestingly
> enough, the first (early) release of LE provided only
> for mixing COBOL and C. (PL/I came in the next release and Fortran -
> was relatively early - but with restrictions).
> I am certain that there were some "COBOL only" shops out there (in
> IBM mainframe world) somewhere, but they were in the minority from AT
> LEAST the mid-70's - and probably earlier.
Disagree.
> (In part, I think this
> was due to IBM "pushing" PL/I for quite a while - while the business
> community was still happy with COBOL - yes, PL/1 pilot projects were run
> and the results were skewed so that COBOL was retained. IBM simply banged
> their heads against a wall for the most part and that is why the language
> fell into disuse, (unlike COBOL... :-))
That is certainly not my recollection. It was mainly COBOL up until the late
70s in the places where I worked. (Australasia and Europe). I see 1980
(approximately) as the date when things started to change and the final nail
was the advent of PCs in the early 80s. By 1985 I was out of mainframe
programming and into client/server.
However, stepping back from this, I don't think it is important enough to
argue about, and experiences may well differ in different places.
Clark F Morris
<dash...@removethis.enternet.co.nz> wrote:
>William M. Klein wrote:
>> (previous info snipped),
>>
>> I have only been working with IBM mainframe COBOL shops since 1978. (I
>> know there are posters here who worked in/with such shops before
>> that).
>> Almost ALL of the shops that I know of had a mix of (at least)
>> Assembler, COBOL, and PL/I.
>
>1978. 2 years before 1980...:-)
>
>There was very little "mixing" (apart from Assembler) in the places I worked
>during the 60s and 70s. I never saw a site where both PL/1 and COBOL were
>in common use. There might be a pilot project, but after that it would
>revert back to what it was.
>
>I feel sure that this changed in the 80s when C and Java were added to the
>mix, and I'm not questioning what you said about the "evolution" of LE.
>
>(By the time LE arrived, I was no longer working on mainframe COBOL.)
>
>My comments where I said that "COBOL was King" were based on experience in
>the 60s and 70s.
>
I suspect that even then most shops had something like Data Analyzer,
DYL260, DYL280 or Easytrieve. I know my relatively small shop had the
first three with DYL280 replacing DYL280 replacing Data Analyzer. To
support our engineers we had Fortran. I helped debug a couple of
Fortran programs without knowing Fortran.
William M. Klein
Fortran application. TWA had an "online" IMS transaction system that used
Fortran for the "trig functions" and had "real-time" input from flights in
process. I don't think this type of application was COMMON, but when COBOL
programs needed "advanced math" features (even statistics), they did call
Fortran (or PL/I) subroutines.
The "phone company" (in the US) before divesture (early 1980's) was completely
"mixed COBOL-PL/I".
An interesting "variation" on this was Telon - which was an "application
generator" (eventually bought by Panasophic, but originally from its own
company). The thing that I liked most about it was that you used the same
front-end (that created "macros") and these could then be used to generate:
- COBOL or PL/I code
- CICS tor IMS (DC) applications
ADF, IBM's "application generator" (for IMS - CSP was more CICS oriented) had
full support for subroutines in either COBOL or PL/I.
--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dash...@removethis.enternet.co.nz> wrote in message
news:771elbF...@mid.individual.net...
Pete Dashwood
> On Thu, 14 May 2009 14:40:42 +1200, "Pete Dashwood"
> <dash...@removethis.enternet.co.nz> wrote:
>
>> William M. Klein wrote:
>>> (previous info snipped),
>>>
>>> I have only been working with IBM mainframe COBOL shops since 1978.
>>> (I know there are posters here who worked in/with such shops before
>>> that).
>>> Almost ALL of the shops that I know of had a mix of (at least)
>>> Assembler, COBOL, and PL/I.
>>
>> 1978. 2 years before 1980...:-)
>>
>> There was very little "mixing" (apart from Assembler) in the places
>> I worked during the 60s and 70s. I never saw a site where both PL/1
>> and COBOL were in common use. There might be a pilot project, but
>> after that it would revert back to what it was.
>>
>> I feel sure that this changed in the 80s when C and Java were added
>> to the mix, and I'm not questioning what you said about the
>> "evolution" of LE.
>>
>> (By the time LE arrived, I was no longer working on mainframe COBOL.)
>>
>> My comments where I said that "COBOL was King" were based on
>> experience in the 60s and 70s.
>>
> I suspect that even then most shops had something like Data Analyzer,
> DYL260, DYL280 or Easytrieve.
Gimme a break, Clark :-)
Of course there were utilities in use (why didn't you mention IDCAMS in the
same context?)
I was talking about PROGRAMMING LANGUAGES...
> I know my relatively small shop had the
> first three with DYL280 replacing DYL280 replacing Data Analyzer. To
> support our engineers we had Fortran. I helped debug a couple of
> Fortran programs without knowing Fortran.
I bet that was fun... :-)
<snip>
Pete Dashwood
> From my personal knowledge, but TWA and United (Airlines) used mixed
> COBOL / Fortran application. TWA had an "online" IMS transaction
> system that used Fortran for the "trig functions" and had "real-time"
> input from flights in process. I don't think this type of
> application was COMMON, but when COBOL programs needed "advanced
> math" features (even statistics), they did call Fortran (or PL/I)
> subroutines.
Or, the South Pacific Program Library if you lived where I did...
>
> The "phone company" (in the US) before divesture (early 1980's) was
> completely "mixed COBOL-PL/I".
Fair enough.
I'd love to have been a fly on the wall when they were discussing how to
implement new systems, given the Evangelical zeal of both camps... :-)
>
> An interesting "variation" on this was Telon - which was an
> "application generator" (eventually bought by Panasophic, but
> originally from its own company). The thing that I liked most about
> it was that you used the same front-end (that created "macros") and
> these could then be used to generate: - COBOL or PL/I code
> - CICS tor IMS (DC) applications
Yes, I worked on contract on a Telon site in the UK for a short time.
>
> ADF, IBM's "application generator" (for IMS - CSP was more CICS
> oriented) had full support for subroutines in either COBOL or PL/I.
I remember a certain manager in Germany being persuaded that ADF would
replace IMS in COBOL and insisting on its use. Ingenious programmers kept
finding things it couldn't do that required them to use COBOL. Eventually it
was dropped. Although I wasn't in favour at the time, in hindsight, I think
he may have had a point. Whenever we objected to the inefficiency of it he
would say: "The hardware will get better, and efficiency won't matter." He
was proved right in that respect. Another of his "quotable quotes" was:
"It's only COBOL..." :-) It used to drive the team wild, especially when
they were grappling with old, overmaintained spaghetti code that they had
inherited... :-)
Arnold Trembley
> (snip)
>
> I found your post enlightening and saddening at the same time.
It actually makes me sad, too. I've tried talking people into trying
usenet, how to connect to a news server, subscribe to groups, and I can
see their eyes glaze over. It's just too much work for them.
>
> Usenet isn't dead, BTW... there are new groups being added almost daily.
>
> Fortunately, most Internet users are unaware of it, just as the people you
> described are. While people are subscribing to blogs, social networks, and
> news feeds (RSS) they have little need for a "user group" or even any kind
> of shared interest group. And yet, almost every time I log on to my News
> server it tells me that "new groups are available" and asks if I want to
> subscribe to them. (the current count is over 90,000 available groups...)
>
> This group (comp.lang.cobol) is extremely valuable because it is an
> unmoderated group and it isn't owned or controlled by any specific
> corporation.
>
> That makes it one of the last bastions of free speech left on the planet.
>
> It is a tribute to the people who come here that there is little flaming and
> abuse; most groups need a moderator to ensure that.
>
> I see it as a useful place where some very bright (and funny :-)) people can
> hang out and posting here is often a form of stress relief for me. I can get
> really fed up with what I'm doing and can spend an hour here, then go back
> to it refreshed and recharged.
>
> If IBM programmers are unaware that this group exists or that there are
> specifc IBM groups for them (Bill posted some recently) then I see that as a
> sad loss for them. I hope some more of them come here.
>
> Pete.
Ditto. I have learned many useful things from comp.lang.cobol and have
been entertained as well. I find it easier and faster to navigate
usenet groups than html based forums, and in my opinion the content is
more interesting here.
With kindest regards,
Bill Gunshannon
"Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
> William M. Klein wrote:
>> From my personal knowledge, but TWA and United (Airlines) used mixed
>> COBOL / Fortran application. TWA had an "online" IMS transaction
>> system that used Fortran for the "trig functions" and had "real-time"
>> input from flights in process. I don't think this type of
>> application was COMMON, but when COBOL programs needed "advanced
>> math" features (even statistics), they did call Fortran (or PL/I)
>> subroutines.
>
> Or, the South Pacific Program Library if you lived where I did...
Or NAG Lib. But then, that would be using Fortran. :-)
Howard Brazee
wrote:
>As for how age realtes to this, I am in the older catagory. :-) I can
>not remember the last time I took a sick day. My daughter, 30 years my
>younger, uses all of hers every year.
My job converts a percentage of my excess sick leave into vacation at
the end of the fiscal year. This is the first year where I won't
have any converted, with 350 hours accrued, and the maximum is 360
hours. That's including family sick leave. Some people love
accruing a day of sick leave so that they can use it ASAP. I love
having a cushion so that I can have an extended hospital stay if I
need it.
But I need to take 48 hours of vacation before July 1 or loose it. I
take just as much vacation as the person who doesn't worry about being
at the max - but it's nice having the leave in the bank, so to speak.
Or money in the bank if I retire.
docd...@panix.com
Howard Brazee <how...@brazee.net> wrote:
>On 13 May 2009 19:15:20 GMT, bill...@cs.uofs.edu (Bill Gunshannon)
>wrote:
>
>>As for how age realtes to this, I am in the older catagory. :-) I can
>>not remember the last time I took a sick day. My daughter, 30 years my
>>younger, uses all of hers every year.
>
>My job converts a percentage of my excess sick leave into vacation at
>the end of the fiscal year.
This is an area where I get completely lost and, at times, moderately
amused and/or annoyed. 'Sick leave' is time when one receives full salary
for days when one cannot get to work because one is ill (or needs to care
for one who is ill). Some companies roll them over (up to a certain
number of hours), some have a 'use it or lose it' policy.
Healthy people, then, do not benefit from this benefit. There are also
other kinds of leave that are 'use it or lose it'... and (depending on
carry-over policy) can result in difficulties. An employee wants to take
a week off but a manager never approves the leave... or, even better, 'an
emergency came up' and the manager withdraws approval. The end of the
year comes, the benefit isn't used, it is lost.
This is similar to some of the difficulties with National Holidays, when
lots o' folks are not only off the job but looking to make use of the same
public resources (the beach, a park, the highways)... this is just plain
inefficient. On the other hand, of course, National Holidays, in a way,
help foster a kind of group-identification, eg 'We are Americans and it is
the Fourth of July... of *course* We celebrate!'
What I've seen proposed - and never implemented, of course - is the policy
of (n) days off, period, with full bankability or remuneration. Do you
want to work on St Crispin's Day? Fine, as long as your job can be
accomplished then show up to an empty building and pound away at your
keyboard... in my experience you'll most likely be more productive, as
well.
Don't want to take off the National Holidays and you have good health and
your Personal Life is such that days off are not needed? Fine, bank
'em... but at the end of (period) or at your time of termination you get
paid for them, in full, *at the maximum rate you earned during your
employment*.
It's that 'maximum rate' part that gives management a financial incentive
to approve requests for leave; if they don't pay for it now then they pay
for it later... and, quite often, 'later' means it Costs More Money.
Anyone seen any flying pigs lately?
DD
Howard Brazee
>>My job converts a percentage of my excess sick leave into vacation at
>>the end of the fiscal year.
>
>This is an area where I get completely lost and, at times, moderately
>amused and/or annoyed. 'Sick leave' is time when one receives full salary
>for days when one cannot get to work because one is ill (or needs to care
>for one who is ill). Some companies roll them over (up to a certain
>number of hours), some have a 'use it or lose it' policy.
>
>Healthy people, then, do not benefit from this benefit.
Companies that roll over sick leave do so because many people use sick
leave for "mental health" - they didn't feel like coming in that day.
This is an incentive for those to not call in tired. I don't know if
it works.
>There are also
>other kinds of leave that are 'use it or lose it'... and (depending on
>carry-over policy) can result in difficulties. An employee wants to take
>a week off but a manager never approves the leave... or, even better, 'an
>emergency came up' and the manager withdraws approval. The end of the
>year comes, the benefit isn't used, it is lost.
>
>This is similar to some of the difficulties with National Holidays, when
>lots o' folks are not only off the job but looking to make use of the same
>public resources (the beach, a park, the highways)... this is just plain
>inefficient. On the other hand, of course, National Holidays, in a way,
>help foster a kind of group-identification, eg 'We are Americans and it is
>the Fourth of July... of *course* We celebrate!'
I like it when two state troopers are talking - "When is your 4th of
July this year?" They get standard public employee holidays - but
not on the holiday itself.
>What I've seen proposed - and never implemented, of course - is the policy
>of (n) days off, period, with full bankability or remuneration. Do you
>want to work on St Crispin's Day? Fine, as long as your job can be
>accomplished then show up to an empty building and pound away at your
>keyboard... in my experience you'll most likely be more productive, as
>well.
Near the end of its life, The Rocky Flats plant negotiated a change in
its policy with its unions.
They gave them an extra day or two of personal leave - no questions
asked. But they replaced their sick leave with an insurance policy.
This insurance policy didn't require any particular amount of time
worked. If one got a heart attack on one's first day at work - one
was covered. It would pay (maybe 70% of one's salary) for as long as
one was out - or until it got converted to permanent disability.
The unions didn't like it and had to be bribed with those extra
personal leave days. But it makes lots of sense to me.
>Don't want to take off the National Holidays and you have good health and
>your Personal Life is such that days off are not needed? Fine, bank
>'em... but at the end of (period) or at your time of termination you get
>paid for them, in full, *at the maximum rate you earned during your
>employment*.
>
>It's that 'maximum rate' part that gives management a financial incentive
>to approve requests for leave; if they don't pay for it now then they pay
>for it later... and, quite often, 'later' means it Costs More Money.
Later is someone else's problem. Or at least it isn't management's
problem of the hour.
When I left the USAF, I had a month's leave accrued. I tried to get
that leave, but they paid me for it instead. If I had received that
leave, I would have accrued another day of leave while on leave. And
there are some benefits that depend on how much service one has (for
instance if one hasn't qualified for full GI Bill, or if one has his
minimum retirement years).
>Anyone seen any flying pigs lately?
Clark F Morris
<dash...@removethis.enternet.co.nz> wrote:
Are you making that comment in facetiousness? You could do a number
of things in DYL280 that were/are difficult or almost impossible in
COBOL. It even implemented the MOVE CORRESPONDING equivalent the way
it should be done (in terms of allowing the programmer to know which
field moves were generated). DYL260 also was a heck of a lot more
powerful than IDCAMS and reminded me of RPG301 (for the RCA 301). Data
Analyzer was a report generator that generated Fortran code. All
three made report writing a lot simpler than COBOL for most reports.
SkippyPB
I don't remember all of the specifics because it was so long ago but I
do recall we (my team members and I) did a teller system conversion
where one of the main componenets of the conversion was a DYL260
program. I think we used it to create some object code which was then
loaded into the teller station controller. We could have done it in
Assembler but I was the only Assembler guru on the team and I was too
busy teaching the operations staff how to run IBM (they were coming
off of Buroughs) and doing System Programmer things and supporting a
deposits conversion that I wrote (in Cobol). On of my team members
took up the task of writing the DYL and did a bang up job. He was
just a COBOL programmer.
>>> I know my relatively small shop had the
>>> first three with DYL280 replacing DYL280 replacing Data Analyzer. To
>>> support our engineers we had Fortran. I helped debug a couple of
>>> Fortran programs without knowing Fortran.
>>
>>I bet that was fun... :-)
>>
>><snip>
>>
>>Pete.
Regards,
////
(o o)
-oOO--(_)--OOo-
"President Union will address the nation on the state of the Bush."
-- Hampton Pearson, news reporter, WBZ TV
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
Michael Wojcik
>
> In my opinion you could make a better argument that usenet is dead, not
> COBOL. I know many people who are not programmers but who use the
> internet a lot, and they have no idea what usenet is.
Some might say this is precisely why Usenet isn't dead.
Usenet scales better than a lot of the alternatives, such as ad hoc
email, email list servers, chat, etc. But it still only scales so far
before it becomes unusable. And it lacks standard mechanisms for
reducing noise.
So Usenet has only remained practical for its users because it's
relatively unknown and unpopular, compared to the total number of
Internet users.
The same can be said for lots of resources, of course. Of the people
who contribute to the typical public library in the US (ie, local
taxpayers), few make much if any use of it; and if that library has a
reference desk, even fewer ever use that. A library reference desk can
be a terrific resource (even in the era of the Google-Wikipedia
information hegemony), and it might be nice in some abstract sense if
more people used it, but it's still a good resource for those who do.
I don't say this to contradict Arnold's basic point (which I believe
is simply that few of the COBOL programmers he knows are even aware of
Usenet, perhaps because they haven't felt the need to look for
something like comp.lang.cobol); I'm merely noting that popularity can
be the enemy of value.
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Michael Wojcik
> ... provides a common "urn-time environment"
In which TRUTH = BEAUTY, of course.
We now return you to your regularly-scheduled flowery tale, already in
progress.
HeyBub
Couple of points:
1. Some usenet services (i.e., Giganews) do a great deal to delete "noise"
(spam, etc.).
2. Local libraries should be burnt and the ashes scattered. On my last visit
to my local library, on a whim I asked: "Do you have Encyclopedia Judaica?"
"Uh, no," was the response.
"Hmm, Marquis Who's Who?" Same answer.
"Cumulative Books In Print? Congressional Record? Federal Register?" Again,
no.
Here's what they DID have:
Hand puppets, computer games, art work, DVDs and CDs, current best-sellers,
and a spinner rack with historical romances (also know as 'bodice rippers')
with the legend: "Leave two, take two." The libraries have not only
abrogated their role as a repository of knowledge, they actively compete
with bookstore.
There are even libraries in Berkely that loan out tools. Yes, TOOLS. Like
ladders, electric drills, post hole diggers, scaffolding, lawnmowers, cement
mixers, garden tillers, wheel-barrows, saws, routers, lathes, bandsaws, shop
vacuums, everything. This, of course, puts the tool-rental companies out of
business.
Burn 'em, I say.
Michael Wojcik
>
> 1. Some usenet services (i.e., Giganews) do a great deal to delete "noise"
> (spam, etc.).
I wasn't referring to spam. My Usenet provider (newsguy) apparently
does a pretty good job of filtering out spam; and there are Usenet
user agents with decent Bayesian filtering. (Thunderbird, alas, is not
one of them, because its filtering doesn't actually work with NNTP. If
the Thunderbird team doesn't get on the ball soon it'll be time to
look at other clients.)
I meant the noise that clutters up the typical web forum, where
no-content attacks, off-topic posts, and other nonsense predominates.
(Of course there are forums, such as 4chan's b-channel, where that
*is* the content, but those are a special case.)
The relatively high barrier to entry for Usenet - its low profile with
casual Internet users, despite Google Groups, etc - keeps a lot of the
ninnies out.
> 2. Local libraries should be burnt and the ashes scattered.
Suffice it to say that we disagree here. Your local library is not the
model for all local libraries, and you are not the model for all
customers of local libraries.
Pete Dashwood
> HeyBub wrote:
>>
>> 1. Some usenet services (i.e., Giganews) do a great deal to delete
>> "noise" (spam, etc.).
>
> I wasn't referring to spam. My Usenet provider (newsguy) apparently
> does a pretty good job of filtering out spam; and there are Usenet
> user agents with decent Bayesian filtering. (Thunderbird, alas, is not
> one of them, because its filtering doesn't actually work with NNTP. If
> the Thunderbird team doesn't get on the ball soon it'll be time to
> look at other clients.)
>
> I meant the noise that clutters up the typical web forum, where
> no-content attacks, off-topic posts, and other nonsense predominates.
Sorry Michael, couldn't let that go... :-)
Throughout the long history of this forum, the off-topic posts have proven
to be every bit as valuable, and, at times, even more valuable, than the
on-topic posts.
It depends on what you want.
If you want something that is dry, regulated, and merely informative, fine,
use a moderated newsgroup.
But if you want something that is lively, often amusing, and generally
entertaining as well as incidentally informative, then you should feel right
at home here.
The "nonsense" you refer to can be the best part.
Over the years this group has made me angry, irritated me, annoyed me, as
well as made me laugh out loud and even moved me occasionally,
but most of all it has stimulated me (and I have tried to return the
favour).
It is important that we shouldn't take ourselves too seriously; it is only
Usenet.
> (Of course there are forums, such as 4chan's b-channel, where that
> *is* the content, but those are a special case.)
>
> The relatively high barrier to entry for Usenet - its low profile with
> casual Internet users, despite Google Groups, etc - keeps a lot of the
> ninnies out.
Hmmm... looking around this forum I'm not so sure... :-) (Hey, it was a
joke, people...)
>
>> 2. Local libraries should be burnt and the ashes scattered.
>
> Suffice it to say that we disagree here. Your local library is not the
> model for all local libraries, and you are not the model for all
> customers of local libraries.
Just as you are not the model for all Usenet users...
Variety and diversity are indeed, the spice of life.