A recent browse of COBOL jobs showed that COBOL
alone is not really enough to get you employed. There are still
mainframe jobs and knowledge of that environment is good, but they will
be much more interested if you have network knowledge as well.I saw ads
for PHP, Java and COBOL, C# and COBOL, and Windows scripting that were
marked as "desirable".
In article <ivb3saFolqnU1@mid.individual.net>,
pete dashwood <dashwood@enternet.co.nz> wrote:
[snip]
A recent browse of COBOL jobs showed that COBOL
alone is not really enough to get you employed. There are still
mainframe jobs and knowledge of that environment is good, but they will
be much more interested if you have network knowledge as well.I saw ads
for PHP, Java and COBOL, C# and COBOL, and Windows scripting that were
marked as "desirable".
Every so often I'll get an email from someone asking for The Usual
Suspects (for an IBM shop that's five-to-seven years' of COBOL, VSAM,
CICS, DB2, FileAid and the like). I have two 'kepboard macros' that I use
to respond to such folks:
1) 'Sounds interesting. What kind of rate are they offering?'
... and if a response comes - and they rarely do - the hourly rates
offered are the same ones I used to see in 1985. This triggers the net keyboard macro:
2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
kind of rate are they offering almost forty years later?'
DD
2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
kind of rate are they offering almost forty years later?'
In article <smpngj$i2a$1@reader1.panix.com>, <docdwarf@panix.com> wrote:
2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
kind of rate are they offering almost forty years later?'
Presumably one warranted by the productivity of a programmer using the >language.
As the productivity (as measured by those paying for the production) of
COBOL programming diminishes relative to the productivity of python / go /
C# / whatever, the rates offered also languish. To improve rates for those >skilled in a particular tool, improve the productivity of the programmers >using the tool.
In article <smpngj$i2a$1@reader1.panix.com>, <docdwarf@panix.com> wrote:
2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
kind of rate are they offering almost forty years later?'
Presumably one warranted by the productivity of a programmer using the >language.
As the productivity (as measured by those paying for the production) of
COBOL programming diminishes relative to the productivity of python / go /
C# / whatever, the rates offered also languish. To improve rates for those >skilled in a particular tool, improve the productivity of the programmers >using the tool.
On Mon, 15 Nov 2021 14:32:36 -0000 (UTC), ime@panix.com (Randy Hudson) wrote:
In article <smpngj$i2a$1@reader1.panix.com>, <docdwarf@panix.com> wrote:
2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what >>> kind of rate are they offering almost forty years later?'
Presumably one warranted by the productivity of a programmer using the
language.
As the productivity (as measured by those paying for the production) of
COBOL programming diminishes relative to the productivity of python / go / >> C# / whatever, the rates offered also languish. To improve rates for those >> skilled in a particular tool, improve the productivity of the programmers
using the tool.
Do you have anything to support this claim?
Additionally, are you talking about modules or systems? Are you taking TCO into
consideration?
My experience differs depending on the requirement. There appears to be a tendency for developing MVP's, something a halfway decent Cobol developer doesn't consider to be a viable deliverable. MVP's are fine for
throw-away systems, not for core bussiness applications. "The old stuff"
or "legacy" is disguised by management and architects even though operationally it is cheap and has a low incidence rate. It's just not
sexy.
FYI: My scope encompasses many languages and technical platforms.
In article <tf25pg5pt7mo2arhlpdvc914jjb708dh7d@4ax.com>,
Joe <none@nowhere.whereo> wrote:
FYI: My scope encompasses many languages and technical platforms.
Probably more than mine; the last time I was paid for programming, I was >writing in BAL.
In article <smpngj$i2a$1@reader1.panix.com>, <docdwarf@panix.com> wrote:
2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
kind of rate are they offering almost forty years later?'
Presumably one warranted by the productivity of a programmer using the language.
As the productivity (as measured by those paying for the production) of
COBOL programming diminishes relative to the productivity of python / go /
C# / whatever, the rates offered also languish. To improve rates for those skilled in a particular tool, improve the productivity of the programmers using the tool.
On Mon, 15 Nov 2021 14:32:36 -0000 (UTC), ime@panix.com (Randy Hudson) wrote:
In article <smpngj$i2a$1@reader1.panix.com>, <docdwarf@panix.com> wrote:
2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what >>> kind of rate are they offering almost forty years later?'
Presumably one warranted by the productivity of a programmer using the
language.
As the productivity (as measured by those paying for the production) of
COBOL programming diminishes relative to the productivity of python / go / >> C# / whatever, the rates offered also languish. To improve rates for those >> skilled in a particular tool, improve the productivity of the programmers
using the tool.
Do you have anything to support this claim? Additionally, are you talking about modules or systems? Are you taking TCO into
consideration?
My experience differs depending on the requirement. There appears to be a tendency for developing MVP's, something a halfway decent
Cobol developer doesn't consider to be a viable deliverable. MVP's are fine for throw-away systems, not for core bussiness
applications. "The old stuff" or "legacy" is disguised by management and architects even though operationally it is cheap and has a
low incidence rate. It's just not sexy.
FYI: My scope encompasses many languages and technical platforms.
On 16/11/2021 05:34, Joe wrote:
On Mon, 15 Nov 2021 14:32:36 -0000 (UTC), ime@panix.com (Randy Hudson)
wrote:
In article <smpngj$i2a$1@reader1.panix.com>, <docdwarf@panix.com>
wrote:
2) 'Hey, good joke! Seriously, I was billing that rate in 1985...
what
kind of rate are they offering almost forty years later?'
Presumably one warranted by the productivity of a programmer using the
language.
As the productivity (as measured by those paying for the production) of
COBOL programming diminishes relative to the productivity of python /
go /
C# / whatever, the rates offered also languish. To improve rates for
those
skilled in a particular tool, improve the productivity of the
programmers
using the tool.
Do you have anything to support this claim? Additionally, are you
talking about modules or systems? Are you taking TCO into
consideration?
My experience differs depending on the requirement. There appears to
be a tendency for developing MVP's, something a halfway decent
Cobol developer doesn't consider to be a viable deliverable. MVP's
are fine for throw-away systems, not for core bussiness
applications. "The old stuff" or "legacy" is disguised by management
and architects even though operationally it is cheap and has a
low incidence rate. It's just not sexy.
FYI: My scope encompasses many languages and technical platforms.
If you look at TCO, COBOL is way behind at the end of the field.
COBOL Compilers continue to be exorbitant with mandatory updates and
service chanrges also required.
C#, VB.NET, RUST, Java, and Python are all FREE! And support is
available with a mouse click from a a community of millions.
Pete.
MVP's
are fine for throw-away systems, not for core business
applications. "The old stuff" or "legacy" is disguised by management
and architects even though operationally it is cheap and has a
low incidence rate. It's just not sexy.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 87:52:15 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,100 |
Messages: | 5,277,252 |