On 12/11/2021 7:12 PM, Bill Gunshannon wrote:
> On 12/11/21 2:25 PM, Arne Vajhøj wrote:
>> On 12/11/2021 1:40 PM, Bill Gunshannon wrote:
>>> On 12/11/21 11:51 AM, Arne Vajhøj wrote:
>>>> And all the largest systems are distributed. They use
>>>> Hadoop, Cassandra, Kafka etc.. Traditional technologies
>>>> does simply not scale to that level.
>>>
>>> You wanna bet?  While some of the frontend stuff has mofrated to
>>> the typical web crap the IRS for example is still a Unisys OS2200
>>> shop with the code being mostly Legacy ACOB carried forward from
>>> its origination on a UNIVAC 1100.
>>
>> Yes. And that system may have been a big system 30 years ago.
>
> The US IRS is one of the biggest ISes in the world.  Large enough
> that some of the biggest contracting companies in the United States
> looked at an RFP to replace it and said it probably couldn't be
> done.  And so it is still written mostly in COBOL running on Unisys
> OS2200.
>
>>
>> But today large systems are NNN/NNNN nodes, NNNN CPU's, N/NN TB memory
>> and N PB disk.
>
> In what way does that contradict what I said above?  Or are you one
> of those people who think IBM Mainframe still means 360/40.

A z15 max out at 24 CPU with 190 cores for application and OS
and 40 TB memory 192 IO cards.

The largest Unisys (the 8300) is as far as I can read only
8 CPU with 64 cores for application and OS and 512 GB of memory.

It just doesn't scale to what companies with large data processing
requirements need today.

11 years ago(!) the largest Hadoop cluster had 2000 CPU with 22400
cores, 64 TB memory and 21 PB data on disk.

Arne

On 12/11/2021 7:24 PM, Bill Gunshannon wrote:
> On 12/11/21 3:23 PM, Arne Vajhøj wrote:
>> On 12/11/2021 1:40 PM, Bill Gunshannon wrote:
>>> On 12/11/21 11:51 AM, Arne Vajhøj wrote:
>>>> If there were then the salaries for Cobol programmer would
>>>> sky rocket.
>>>
>>> COBOL programmers have already been receiving 6 figure salaries.
>>> the biggest reason for the lack of publicly viewable job offerings
>>> has more to do with job stability than lack of jobs.
>>>
>>> ----------------------------------------------------
>>>
>>> Defense Finance and Accounting Service
>>>
>>> Salary
>>> $92,914 - $120,789 per year
>>>
>>> "Use Integrated Database Management System (IDMS), Common Business
>>> Oriented Language (COBOL), and Job Control Language (JCL) in a
>>> mainframe environment to design software for Payroll Systems used
>>> by the Defense Finance and Accounting Service."
>>>
>>> -------------------------------------------------------
>>>
>>> This announcement or similar ones has been running almost constantly
>>> for as long as I have been following the the business.  More than 20
>>> years.
>>
>> The above snippet does not say whether it is 0/5/10/20 years of
>> experienced they are looking for or whether it is in New York/Boston
>> /Seattle/San Francisco/Mountain View or Kansas/Arkansas
>> /Missouri/Alabama they are looking
>
> I didn't post the whole thing.  In typical government form it is
> several pages long with most of it being boilerplate.  DFAS is in
> Indiana (which is why I never applied for a position.)  Experience
> would be evaluated from your resume.  But minimum starting salary
> is still $95K.

For Indiana and not top-10% then that is probably fine.

>   I would be happy with that.

I suspect that you do not have a brand new astronomical mortgage
and 3 kids to put through college in a few years.

> How much are VMS
> programmers making these days?

No idea. But probably similar to developers on other platforms.

>> So it is hard to say whether it is a great salary or a
>> crap salary.
>>
>> But it is not a sky rocket salary.
>
> Seriously?  I just took a quick look at Java Programmers on Indeed.
> Most of the jobs are for half of that.  And a lot of those were in
> NYC where a 1 bedroom apartment starts at $2000 a month.

????

Average developer salaries in the US is somewhere in the 100-110 range.

O'Reilly -
https://www.zdnet.com/article/heres-how-much-money-you-can-make-as-a-developer-in-2021/

Burning Glass / Dice -
https://insights.dice.com/2020/10/13/12-programming-languages-that-pay-ultra-high-salaries/

Glass Door / Octoparse -
https://www.octoparse.com/blog/15-highest-paying-programming-languages-in-2017

Indeed / Daxx (Python only, but be state) -
https://www.daxx.com/blog/development-trends/python-developer-salary-usa

Code Platoon -
https://www.codeplatoon.org/the-best-paying-and-most-in-demand-programming-languages-in-2021/

Statista / Indeed -
https://www.indeed.com/career-advice/finding-a-job/highest-paid-programmers-by-language

There is obviously some uncertainty involved in such numbers.

But given that they all end up with very similar numbers from
different sources, then they seems very plausible.

Trying to hire a Java developer in NYC for half of 95K is a joke.

NYC salaries are significant higher than average due to high cost
of living.

Java salaries are at average or slightly above - it is a sort of meat
and potato language today - solid demand - but not super hot.

The latest and greatest tend to be a lot higher than average due to
demand exceeding supply.

Rust, Go, Scala etc..

A few years ago Ruby and Swift.

Arne

On 12/11/2021 7:12 PM, Bill Gunshannon wrote:
> On 12/11/21 2:25 PM, Arne Vajhøj wrote:
>> On 12/11/2021 1:40 PM, Bill Gunshannon wrote:
>>> On 12/11/21 11:51 AM, Arne Vajhøj wrote:
>>>> On 12/11/2021 8:20 AM, Bill Gunshannon wrote:
>>>>>             Kind of like COBOL.  It is probably one of the
>>>>> most used languages for serious business applications in use
>>>>> today.  Some of the largest information systems in the world
>>>>> are written in it.  Everybody is affected by its use every day.
>>>>
>>>> If an application:
>>>> - is processing money
>>>> - first version was written before 1995
>>>> - has not been rewritten after 1995
>>>> then there is a good chance that it is in Cobol.
>>>
>>> And, not just processing money.
>>>
>>>> And a lot of those applications are very important applications.
>>>>
>>>> But I am not so sure that it is one of the most used languages.
>>>
>>> I didn't say most used languages.  I limited myself to serious
>>> business.  There is no COBOL version of Candy Crush.
>>>
>>>> The estimate is that Cobol is about 200 billion out of 3 trillion lines
>>>> of code (7%). And based on hiring statistics it looks like Cobol
>>>> work is like 1% of development work being done.
>>>
>>> Many of the times those hiring statistics are compiled by thge
>>> people trying to kill COBOL.
>>
>> I am very skeptical about such a conspiracy theory.
>
> Not a conspiracy theory.  A lot of the polls done today have a
> pre-desired conclusion and they are made to fit it.  I point
> this out to pollsters on Indeed all the time.  It's like asking
> "Yes or no.  Have you stopped beating your wife?"  :-)

But this is no a pollster asking some people.

This is counting actual job posts posted by companies that
does not know they are being counted and most likely do not care.

>>>                            I have watched the number of COBOL
>>> jobs publicly advertised rise by  more than 1000% in the past
>>> 5-10 years.
>>
>> Hmmm.
>>
>> At the big job sites the number of Cobol jobs has decreased by
>> 2/3 the last 15 years.
>
> Based on what numbers?

dice.com search for Cobol done by me:

January 2005 - 1019
March 2006 - 1326
March 2007 - 1230
November 2016 - 434
December 2018 - 373
July 2019 - 228
today - 314

To me that looks like -2/3.

Obviously one could suspect that dice.com market share has decreased
causing the drop.

But when looking at other languages then that is not the case. The
Java numbers are 9573 - 15273 - 16518 - 15397 - 29992 - 14767 - 16685,
which is fluctuating a bit but are definitely not dropping 2/3.

Arne

On 12/12/2021 2:12, Bill Gunshannon wrote:
> On 12/11/21 2:25 PM, Arne Vajhøj wrote:
>> On 12/11/2021 1:40 PM, Bill Gunshannon wrote:
>>> On 12/11/21 11:51 AM, Arne Vajhøj wrote:
>>>> On 12/11/2021 8:20 AM, Bill Gunshannon wrote:
>>>>>             Kind of like COBOL.  It is probably one of the
>>>>> most used languages for serious business applications in use
>>>>> today.  Some of the largest information systems in the world
>>>>> are written in it.  Everybody is affected by its use every day.
>>>>
>>>> If an application:
>>>> - is processing money
>>>> - first version was written before 1995
>>>> - has not been rewritten after 1995
>>>> then there is a good chance that it is in Cobol.
>>>
>>> And, not just processing money.
>>>
>>>> And a lot of those applications are very important applications.
>>>>
>>>> But I am not so sure that it is one of the most used languages.
>>>
>>> I didn't say most used languages.  I limited myself to serious
>>> business.  There is no COBOL version of Candy Crush.
>>>
>>>> The estimate is that Cobol is about 200 billion out of 3 trillion lines
>>>> of code (7%). And based on hiring statistics it looks like Cobol
>>>> work is like 1% of development work being done.
>>>
>>> Many of the times those hiring statistics are compiled by thge
>>> people trying to kill COBOL.
>>
>> I am very skeptical about such a conspiracy theory.
>
> Not a conspiracy theory.  A lot of the polls done today have a
> pre-desired conclusion and they are made to fit it.  I point
> this out to pollsters on Indeed all the time.  It's like asking
> "Yes or no.  Have you stopped beating your wife?"  :-)
>
>>
>>>                            I have watched the number of COBOL
>>> jobs publicly advertised rise by  more than 1000% in the past
>>> 5-10 years.
>>
>> Hmmm.
>>
>> At the big job sites the number of Cobol jobs has decreased by
>> 2/3 the last 15 years.
>
> Based on what numbers?  15 years ago Indeed would list maybe 10
> or 15.  Just did a search for COBOL: Page 1 of 2,462 jobs.
> Even if half of them are bogus it's still a lot.
>
>>
>>>                   I have followed and even been involved with some of
>>> the largest COBOL users and watched their hiring practices. Believe it or not, not everyone hires thru Indeed,
>>> Monster or Dice.
>>
>> Not everyone.
>>
>> But assuming that Cobol is many times more required in the total
>> job market than there seems like wishful thinking from someone that
>> likes Cobol.
>
> Or someone who has noit drunk the koolaid and is trying to enlighten
> people to something that is being hidden.  Regardless of the reason.
>
>>
>>>> And all the largest systems are distributed. They use
>>>> Hadoop, Cassandra, Kafka etc.. Traditional technologies
>>>> does simply not scale to that level.
>>>
>>> You wanna bet?  While some of the frontend stuff has mofrated to
>>> the typical web crap the IRS for example is still a Unisys OS2200
>>> shop with the code being mostly Legacy ACOB carried forward from
>>> its origination on a UNIVAC 1100.
>>
>> Yes. And that system may have been a big system 30 years ago.
>
> The US IRS is one of the biggest ISes in the world.  Large enough
> that some of the biggest contracting companies in the United States
> looked at an RFP to replace it and said it probably couldn't be
> done.  And so it is still written mostly in COBOL running on Unisys
> OS2200.
>
>>
>> But today large systems are NNN/NNNN nodes, NNNN CPU's, N/NN TB memory and N PB disk.
>
> In what way does that contradict what I said above?  Or are you one
> of those people who think IBM Mainframe still means 360/40.
>
> bill
>

Where I work (government land administration) started in 2014 I was told I was there for a two-year project to move
several hundred COBOL programs to a Windows database system. Seven years later, it's due to be comleted "by the end of
2022."
Several dozen programmers working on and around the project, also mantaining the (still operational, live system) COBOL.
Just saying...

--
Mike R.
Home: http://alpha.mike-r.com/
QOTD: http://alpha.mike-r.com/qotd.php
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
and: http://alpha.mike-r.com/jargon/T/top-post.html
Missile address: N31.7624/E34.9691

On 12/11/21 7:29 PM, Bill Gunshannon wrote:
>
> Brian,
>   I tried to reply to your email but your system refused it for reasons
> I can't fathom.  Sorry.  I didn't ignore you.
>
> bill

Another bounce. Claims my address is in an RBL. I seriously
doubt it. Sorry, I give up.

bill

On 12/11/21 7:38 PM, Arne Vajhøj wrote:
> On 12/11/2021 7:12 PM, Bill Gunshannon wrote:
>> On 12/11/21 2:25 PM, Arne Vajhøj wrote:
>>> On 12/11/2021 1:40 PM, Bill Gunshannon wrote:
>>>> On 12/11/21 11:51 AM, Arne Vajhøj wrote:
>>>>> And all the largest systems are distributed. They use
>>>>> Hadoop, Cassandra, Kafka etc.. Traditional technologies
>>>>> does simply not scale to that level.
>>>>
>>>> You wanna bet?  While some of the frontend stuff has mofrated to
>>>> the typical web crap the IRS for example is still a Unisys OS2200
>>>> shop with the code being mostly Legacy ACOB carried forward from
>>>> its origination on a UNIVAC 1100.
>>>
>>> Yes. And that system may have been a big system 30 years ago.
>>
>> The US IRS is one of the biggest ISes in the world.  Large enough
>> that some of the biggest contracting companies in the United States
>> looked at an RFP to replace it and said it probably couldn't be
>> done.  And so it is still written mostly in COBOL running on Unisys
>> OS2200.
>>
>>>
>>> But today large systems are NNN/NNNN nodes, NNNN CPU's, N/NN TB
>>> memory and N PB disk.
>>
>> In what way does that contradict what I said above?  Or are you one
>> of those people who think IBM Mainframe still means 360/40.
>
> A z15 max out at 24 CPU with 190 cores for application and OS
> and 40 TB memory 192 IO cards.
>
> The largest Unisys (the 8300) is as far as I can read only
> 8 CPU with 64 cores for application and OS and 512 GB of memory.
>
> It just doesn't scale to what companies with large data processing
> requirements need today.
>
> 11 years ago(!) the largest Hadoop cluster had 2000 CPU with 22400
> cores, 64 TB memory and 21 PB data on disk.
>

And yet the IRS is doing it just fine. Go figure.

And then we have DFAS which is an IBM shop handles payroll for all
the military and civilians in DOD. A bit more than any company I
can think of.

And then we also have the DOD EMR system. Every member of the
military, all their dependents, all the retirees that are still
getting care at an MTF (like me!) That's and IBM mainframe, too.
and the application is written in COBOL.

Seems that COBOL and mainframes are doing just fine. Maybe
some of those businesses don;t really need all that hardware
and were sold a real bill of goods because the guys making
the decisions aren't really qualified for the job. :-)

Just so you will know where I am coming from on this, there is
a strong move to push "modernization" of mainframes. The current
definition of "modernization" is move to a different platform and
re-write all your applications in the language du jour. Sound
familiar? It should. The same tack is frequently used where VMS
is today.

bill

On 12/11/21 8:13 PM, Arne Vajhøj wrote:
> On 12/11/2021 7:24 PM, Bill Gunshannon wrote:
>> On 12/11/21 3:23 PM, Arne Vajhøj wrote:
>>> On 12/11/2021 1:40 PM, Bill Gunshannon wrote:
>>>> On 12/11/21 11:51 AM, Arne Vajhøj wrote:
>>>>> If there were then the salaries for Cobol programmer would
>>>>> sky rocket.
>>>>
>>>> COBOL programmers have already been receiving 6 figure salaries.
>>>> the biggest reason for the lack of publicly viewable job offerings
>>>> has more to do with job stability than lack of jobs.
>>>>
>>>> ----------------------------------------------------
>>>>
>>>> Defense Finance and Accounting Service
>>>>
>>>> Salary
>>>> $92,914 - $120,789 per year
>>>>
>>>> "Use Integrated Database Management System (IDMS), Common Business
>>>> Oriented Language (COBOL), and Job Control Language (JCL) in a
>>>> mainframe environment to design software for Payroll Systems used
>>>> by the Defense Finance and Accounting Service."
>>>>
>>>> -------------------------------------------------------
>>>>
>>>> This announcement or similar ones has been running almost constantly
>>>> for as long as I have been following the the business.  More than 20
>>>> years.
>>>
>>> The above snippet does not say whether it is 0/5/10/20 years of
>>> experienced they are looking for or whether it is in New York/Boston
>>> /Seattle/San Francisco/Mountain View or Kansas/Arkansas
>>> /Missouri/Alabama they are looking
>>
>> I didn't post the whole thing.  In typical government form it is
>> several pages long with most of it being boilerplate.  DFAS is in
>> Indiana (which is why I never applied for a position.)  Experience
>> would be evaluated from your resume.  But minimum starting salary
>> is still $95K.
>
> For Indiana and not top-10% then that is probably fine.
>
>>                     I would be happy with that.
>
> I suspect that you do not have a brand new astronomical mortgage
> and 3 kids to put through college in a few years.

I still have a mortgage and handle it just fine with my retirement
check. :-) By the way, the average salary where I live is ion the
15K-20K range. Someone earning what that job offered would be a
king. And, yes, we do have some jobs in that area. And some of
them are actually COBOL programmers. (In the insurance business.)

>
>>                                                 How much are VMS
>> programmers making these days?
>
> No idea. But probably similar to developers on other platforms.

I guess a better question would have been what one could expect as
a starting salary for VMS. Most of the people doing VMS today are
dinosaurs with long seniority, I am sure.

>
>>> So it is hard to say whether it is a great salary or a
>>> crap salary.
>>>
>>> But it is not a sky rocket salary.
>>
>> Seriously?  I just took a quick look at Java Programmers on Indeed.
>> Most of the jobs are for half of that.  And a lot of those were in
>> NYC where a 1 bedroom apartment starts at $2000 a month.
>
> ????
>
> Average developer salaries in the US is somewhere in the 100-110 range.

A quick perusal of Indeed seems to contradict that. While some
jobs list a high end over 100K the low end is usually 20K-40K.
Amazon is paying 30K to stuff boxes around here.

>
> O'Reilly -
> https://www.zdnet.com/article/heres-how-much-money-you-can-make-as-a-developer-in-2021/
>
>
> Burning Glass / Dice -
> https://insights.dice.com/2020/10/13/12-programming-languages-that-pay-ultra-high-salaries/
>
>
> Glass Door / Octoparse -
> https://www.octoparse.com/blog/15-highest-paying-programming-languages-in-2017
>
>
> Indeed / Daxx (Python only, but be state) -
> https://www.daxx.com/blog/development-trends/python-developer-salary-usa
>
> Code Platoon -
> https://www.codeplatoon.org/the-best-paying-and-most-in-demand-programming-languages-in-2021/
>
>
> Statista / Indeed -
> https://www.indeed.com/career-advice/finding-a-job/highest-paid-programmers-by-language
>

I used to get the SANS pay survey results. According to them
I should have been making well over $100K. It never happened.

>
> There is obviously some uncertainty involved in such numbers.
>
> But given that they all end up with very similar numbers from
> different sources, then they seems very plausible.

Unless part of the purpose is to steer the crowd in a certain direction.
After 25 years in academia I can assure I saw it happening.

>
> Trying to hire a Java developer in NYC for half of 95K is a joke.
>
> NYC salaries are significant higher than average due to high cost
> of living.
>
> Java salaries are at average or slightly above - it is a sort of meat
> and potato language today - solid demand - but not super hot.
>
> The latest and greatest tend to be a lot higher than average due to
> demand exceeding supply.
>
> Rust, Go, Scala etc..
>
> A few years ago Ruby and Swift.

Based on that you would expect COBOL to be at the top. There is
still demand. DFAS and IRS constantly hiring. Other places I
have personal experience with also have a need. And supply is
very close to zero. I am not aware of any University in the US
today that offers even a basic course in COBOL programming. Not
even in their CIS degree programs. They choose instead to attack
COBOL if they mention it at all and steer students away from even
looking at it.

There was a Representative in Congress (from my State, actually)
here that recently proposed a bill to fund a push to get legacy
stuff (like COBOL) back into education because of the strong need
for it in the IT world. Someone like the department I used to
work for could get as much as $2,000,000 in grant money and all
they would have to do to qualify would be to offer courses in
things like COBOL. I told them about it. No interest. "Too
much paperwork." And yet the required paperwork was a mere
fraction of what is required for your average NSF grant. Think
about that. Teach one copurse that used to be on the books
anyway 15 years ago and get $2,000,000. And maybe more next
year. Assuming you didn't want to divert current faculty to
the task, you could hire a new faculty member for maybe $250,000
to cover pay and benefits. $50,000 to get him and office and
the rest is in the departments coffers. And yet, no interest.

How would you explain that?

bill

In article <j1meamF7ourU1@mid.individual.net>, Bill Gunshannon
<bill.gunshannon@gmail.com> writes:

> On 12/11/21 7:29 PM, Bill Gunshannon wrote:
> >
> > Brian,
> >   I tried to reply to your email but your system refused it for reasons
> > I can't fathom.  Sorry.  I didn't ignore you.
> >
> > bill
>
> Another bounce. Claims my address is in an RBL. I seriously
> doubt it. Sorry, I give up.

It might very well be (by mistake) in some RBL.

On 12/12/2021 9:46 AM, Bill Gunshannon wrote:
> On 12/11/21 8:13 PM, Arne Vajhøj wrote:
>> On 12/11/2021 7:24 PM, Bill Gunshannon wrote:
>>> On 12/11/21 3:23 PM, Arne Vajhøj wrote:
>>>> On 12/11/2021 1:40 PM, Bill Gunshannon wrote:
>>>>> On 12/11/21 11:51 AM, Arne Vajhøj wrote:
>>>>>> If there were then the salaries for Cobol programmer would
>>>>>> sky rocket.
>>>>>
>>>>> COBOL programmers have already been receiving 6 figure salaries.
>>>>> the biggest reason for the lack of publicly viewable job offerings
>>>>> has more to do with job stability than lack of jobs.
>>>>>
>>>>> ----------------------------------------------------
>>>>>
>>>>> Defense Finance and Accounting Service
>>>>>
>>>>> Salary
>>>>> $92,914 - $120,789 per year
>>>>>
>>>>> "Use Integrated Database Management System (IDMS), Common Business
>>>>> Oriented Language (COBOL), and Job Control Language (JCL) in a
>>>>> mainframe environment to design software for Payroll Systems used
>>>>> by the Defense Finance and Accounting Service."
>>>>>
>>>>> -------------------------------------------------------
>>>>>
>>>>> This announcement or similar ones has been running almost constantly
>>>>> for as long as I have been following the the business. More than 20
>>>>> years.
>>>>
>>>> The above snippet does not say whether it is 0/5/10/20 years of
>>>> experienced they are looking for or whether it is in New York/Boston
>>>> /Seattle/San Francisco/Mountain View or Kansas/Arkansas
>>>> /Missouri/Alabama they are looking
>>>
>>> I didn't post the whole thing. In typical government form it is
>>> several pages long with most of it being boilerplate. DFAS is in
>>> Indiana (which is why I never applied for a position.) Experience
>>> would be evaluated from your resume. But minimum starting salary
>>> is still $95K.
>>
>> For Indiana and not top-10% then that is probably fine.
>>
>>> I would be happy with that.
>>
>> I suspect that you do not have a brand new astronomical mortgage
>> and 3 kids to put through college in a few years.
>
> I still have a mortgage and handle it just fine with my retirement
> check. :-) By the way, the average salary where I live is ion the
> 15K-20K range. Someone earning what that job offered would be a
> king. And, yes, we do have some jobs in that area. And some of
> them are actually COBOL programmers. (In the insurance business.)
>
>>
>>> How much are VMS
>>> programmers making these days?
>>
>> No idea. But probably similar to developers on other platforms.
>
> I guess a better question would have been what one could expect as
> a starting salary for VMS. Most of the people doing VMS today are
> dinosaurs with long seniority, I am sure.
>
>>
>>>> So it is hard to say whether it is a great salary or a
>>>> crap salary.
>>>>
>>>> But it is not a sky rocket salary.
>>>
>>> Seriously? I just took a quick look at Java Programmers on Indeed.
>>> Most of the jobs are for half of that. And a lot of those were in
>>> NYC where a 1 bedroom apartment starts at $2000 a month.
>>
>> ????
>>
>> Average developer salaries in the US is somewhere in the 100-110 range.
>
> A quick perusal of Indeed seems to contradict that. While some
> jobs list a high end over 100K the low end is usually 20K-40K.
> Amazon is paying 30K to stuff boxes around here.
>
>>
>> O'Reilly -
>> https://www.zdnet.com/article/heres-how-much-money-you-can-make-as-a-developer-in-2021/
>>
>>
>> Burning Glass / Dice -
>> https://insights.dice.com/2020/10/13/12-programming-languages-that-pay-ultra-high-salaries/
>>
>>
>> Glass Door / Octoparse -
>> https://www.octoparse.com/blog/15-highest-paying-programming-languages-in-2017
>>
>> Indeed / Daxx (Python only, but be state) -
>> https://www.daxx.com/blog/development-trends/python-developer-salary-usa
>>
>> Code Platoon -
>> https://www.codeplatoon.org/the-best-paying-and-most-in-demand-programming-languages-in-2021/
>>
>>
>> Statista / Indeed -
>> https://www.indeed.com/career-advice/finding-a-job/highest-paid-programmers-by-language
>>
>
> I used to get the SANS pay survey results. According to them
> I should have been making well over $100K. It never happened.
>
>>
>> There is obviously some uncertainty involved in such numbers.
>>
>> But given that they all end up with very similar numbers from
>> different sources, then they seems very plausible.
>
> Unless part of the purpose is to steer the crowd in a certain direction.
> After 25 years in academia I can assure I saw it happening.
>
>>
>> Trying to hire a Java developer in NYC for half of 95K is a joke.
>>
>> NYC salaries are significant higher than average due to high cost
>> of living.
>>
>> Java salaries are at average or slightly above - it is a sort of meat
>> and potato language today - solid demand - but not super hot.
>>
>> The latest and greatest tend to be a lot higher than average due to
>> demand exceeding supply.
>>
>> Rust, Go, Scala etc..
>>
>> A few years ago Ruby and Swift.
>
> Based on that you would expect COBOL to be at the top. There is
> still demand. DFAS and IRS constantly hiring. Other places I
> have personal experience with also have a need. And supply is
> very close to zero. I am not aware of any University in the US
> today that offers even a basic course in COBOL programming. Not
> even in their CIS degree programs. They choose instead to attack
> COBOL if they mention it at all and steer students away from even
> looking at it.
>
> There was a Representative in Congress (from my State, actually)
> here that recently proposed a bill to fund a push to get legacy
> stuff (like COBOL) back into education because of the strong need
> for it in the IT world. Someone like the department I used to
> work for could get as much as $2,000,000 in grant money and all
> they would have to do to qualify would be to offer courses in
> things like COBOL. I told them about it. No interest. "Too
> much paperwork." And yet the required paperwork was a mere
> fraction of what is required for your average NSF grant. Think
> about that. Teach one copurse that used to be on the books
> anyway 15 years ago and get $2,000,000. And maybe more next
> year. Assuming you didn't want to divert current faculty to
> the task, you could hire a new faculty member for maybe $250,000
> to cover pay and benefits. $50,000 to get him and office and
> the rest is in the departments coffers. And yet, no interest.
>
> How would you explain that?
>
> bill

Ego

We're smarter than you are, do what we say

Desire to impose one's expectations on others

Human intellegence is a myth

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 12/10/21 16:09, Robert A. Brooks wrote:
> On 12/10/2021 10:46 AM, chris wrote:
>
>> The other point is, do the original owners really care enough, or
>> even at all, when so much licensed software is out there and is
>> obsolete and no longer sold ?.
>
> The answer to that question is not relevant as a point of law.
>
>> Ethical dilemmas everywhere in life and we all have to make our
>> own choices...
> There is no "ethical dilemma" here. The ownership is not in question,
> nor is there any "life-or-death" situation at hand.
>
> You can ignore that, but that's not an ethical dilemma.
>

Well it is if you normally do the right thing, but have to
make a choice as to continue usage where there is no legal
process to allow it.

In all the early Sun machines, the os license came with the machine
to use indefinately. That no doubt contributed to their success and
the company had the right ethos and sense of fair play.

Onerous licensing terms always cause problems in the end and DEC
always were primarily about the money, irrespective of how good
the systems were. All relationships in life depend on trust and
no one likes being screwed to the floor over licensing...

Chris

On 12/10/21 20:25, Joerg Hoppe wrote:
> Hi,
>> Almost all books and so on have something like "All rights reserved. No
>> portion of this document may be reproduced in any form without prior
>> written permission from the publisher."
>>
>> There are exceptions for quoting short portions for criticism, fair use,
>> and so on.
>>
> And tons of documents on bitsavers contain these clause.
> Nonetheless we still scan, publish and use them.
> Maybe we steal, but nobody complains and nobody has a financial loss.
>
> Surely had my VMS 4.0 source code fiche pack strict licenses on it, in
> 1985.
> Would HPE enforce these today? (I learned HPE still owns the OpenVMS VAX
> rights, VSI got Alpha, Itanium and x64).
>
> Whom to ask?
>
> Joerg

....and in the future, if vsi go broke, would all the current vms users
stop using vms when the current license expires ?. That's what should
happen, after all.

You are already hostage to fortune, with considerable risk, compared to
other industry standard and current solutions, so VSI need to make the
term and conditions as flexible as possible...

Chris

On 12/12/21 11:50 AM, Dave Froble wrote:
> On 12/12/2021 9:46 AM, Bill Gunshannon wrote:
>> On 12/11/21 8:13 PM, Arne Vajhøj wrote:
>>> On 12/11/2021 7:24 PM, Bill Gunshannon wrote:
>>>> On 12/11/21 3:23 PM, Arne Vajhøj wrote:
>>>>> On 12/11/2021 1:40 PM, Bill Gunshannon wrote:
>>>>>> On 12/11/21 11:51 AM, Arne Vajhøj wrote:
>>>>>>> If there were then the salaries for Cobol programmer would
>>>>>>> sky rocket.
>>>>>>
>>>>>> COBOL programmers have already been receiving 6 figure salaries.
>>>>>> the biggest reason for the lack of publicly viewable job offerings
>>>>>> has more to do with job stability than lack of jobs.
>>>>>>
>>>>>> ----------------------------------------------------
>>>>>>
>>>>>> Defense Finance and Accounting Service
>>>>>>
>>>>>> Salary
>>>>>> $92,914 - $120,789 per year
>>>>>>
>>>>>> "Use Integrated Database Management System (IDMS), Common Business
>>>>>> Oriented Language (COBOL), and Job Control Language (JCL) in a
>>>>>> mainframe environment to design software for Payroll Systems used
>>>>>> by the Defense Finance and Accounting Service."
>>>>>>
>>>>>> -------------------------------------------------------
>>>>>>
>>>>>> This announcement or similar ones has been running almost constantly
>>>>>> for as long as I have been following the the business.  More than 20
>>>>>> years.
>>>>>
>>>>> The above snippet does not say whether it is 0/5/10/20 years of
>>>>> experienced they are looking for or whether it is in New York/Boston
>>>>> /Seattle/San Francisco/Mountain View or Kansas/Arkansas
>>>>> /Missouri/Alabama they are looking
>>>>
>>>> I didn't post the whole thing.  In typical government form it is
>>>> several pages long with most of it being boilerplate.  DFAS is in
>>>> Indiana (which is why I never applied for a position.)  Experience
>>>> would be evaluated from your resume.  But minimum starting salary
>>>> is still $95K.
>>>
>>> For Indiana and not top-10% then that is probably fine.
>>>
>>>>                     I would be happy with that.
>>>
>>> I suspect that you do not have a brand new astronomical mortgage
>>> and 3 kids to put through college in a few years.
>>
>> I still have a mortgage and handle it just fine with my retirement
>> check.  :-)  By the way, the average salary where I live is ion the
>> 15K-20K range.  Someone earning what that job offered would be a
>> king.  And, yes, we do have some jobs in that area.  And some of
>> them are actually COBOL programmers.  (In the insurance business.)
>>
>>>
>>>>                                                 How much are VMS
>>>> programmers making these days?
>>>
>>> No idea. But probably similar to developers on other platforms.
>>
>> I guess a better question would have been what one could expect as
>> a starting salary for VMS.  Most of the people doing VMS today are
>> dinosaurs with long seniority, I am sure.
>>
>>>
>>>>> So it is hard to say whether it is a great salary or a
>>>>> crap salary.
>>>>>
>>>>> But it is not a sky rocket salary.
>>>>
>>>> Seriously?  I just took a quick look at Java Programmers on Indeed.
>>>> Most of the jobs are for half of that.  And a lot of those were in
>>>> NYC where a 1 bedroom apartment starts at $2000 a month.
>>>
>>> ????
>>>
>>> Average developer salaries in the US is somewhere in the 100-110 range.
>>
>> A quick perusal of Indeed seems to contradict that.  While some
>> jobs list a high end over 100K the low end is usually 20K-40K.
>> Amazon is paying 30K to stuff boxes around here.
>>
>>>
>>> O'Reilly -
>>> https://www.zdnet.com/article/heres-how-much-money-you-can-make-as-a-developer-in-2021/
>>>
>>>
>>>
>>> Burning Glass / Dice -
>>> https://insights.dice.com/2020/10/13/12-programming-languages-that-pay-ultra-high-salaries/
>>>
>>>
>>>
>>> Glass Door / Octoparse -
>>> https://www.octoparse.com/blog/15-highest-paying-programming-languages-in-2017
>>>
>>>
>>> Indeed / Daxx (Python only, but be state) -
>>> https://www.daxx.com/blog/development-trends/python-developer-salary-usa
>>>
>>> Code Platoon -
>>> https://www.codeplatoon.org/the-best-paying-and-most-in-demand-programming-languages-in-2021/
>>>
>>>
>>>
>>> Statista / Indeed -
>>> https://www.indeed.com/career-advice/finding-a-job/highest-paid-programmers-by-language
>>>
>>>
>>
>> I used to get the SANS pay survey results.  According to them
>> I should have been  making well over $100K.  It never happened.
>>
>>>
>>> There is obviously some uncertainty involved in such numbers.
>>>
>>> But given that they all end up with very similar numbers from
>>> different sources, then they seems very plausible.
>>
>> Unless part of the purpose is to steer the crowd in a certain direction.
>> After 25 years in academia I can assure I saw it happening.
>>
>>>
>>> Trying to hire a Java developer in NYC for half of 95K is a joke.
>>>
>>> NYC salaries are significant higher than average due to high cost
>>> of living.
>>>
>>> Java salaries are at average or slightly above - it is a sort of meat
>>> and potato language today - solid demand - but not super hot.
>>>
>>> The latest and greatest tend to be a lot higher than average due to
>>> demand exceeding supply.
>>>
>>> Rust, Go, Scala etc..
>>>
>>> A few years ago Ruby and Swift.
>>
>> Based on that you would expect COBOL to be at the top.  There is
>> still demand.  DFAS and IRS constantly hiring.  Other places I
>> have personal experience with also have a need.  And supply is
>> very close to zero.  I am not aware of any University in the US
>> today that offers even a basic course in COBOL programming.  Not
>> even in their CIS degree programs.  They choose instead to attack
>> COBOL if they mention it at all and steer students away from even
>> looking at it.
>>
>> There was a Representative in Congress (from my State, actually)
>> here that recently proposed a bill to fund a push to get legacy
>> stuff (like COBOL) back into education because of the strong need
>> for it in the IT world.  Someone like the department I used to
>> work for could get as much as $2,000,000 in grant money and all
>> they would have to do to qualify would be to offer courses in
>> things like COBOL.  I told them about it.  No interest.  "Too
>> much paperwork."  And yet the required paperwork was a mere
>> fraction of what is required for your average NSF grant.  Think
>> about that.  Teach one copurse that used to be on the books
>> anyway 15 years ago and get $2,000,000.  And maybe more  next
>> year.  Assuming you didn't want to divert current faculty to
>> the task, you could hire a new faculty member for maybe $250,000
>> to cover pay and benefits. $50,000 to get him and office and
>> the rest is in the departments coffers.  And yet, no interest.
>>
>> How would you explain that?
>>
>> bill
>
> Ego
>
> We're smarter than you are, do what we say
>
> Desire to impose one's expectations on others
>
> Human intellegence is a myth
>
>

Exactly. Those of us who have been around since before then
watched it happen. OOP came out. Academia pushed it as the
ultimate paradigm. Languages that had been around successfully
doing what they did for decades grafted OOP into their languages
and forced it down people's throats. Object COBOL came out.
COBOL practitioners of the art laughed and announced that the
emperor really had no clothes on at all and refused to re-write
all their applications in the new paradigm. Academia's reaction
was to take a page out of the Amish rule book. They shunned COBOL.
They stopped teaching it even in CIS courses where it was still
the most practical language to get the job done. They attacked
it claiming weaknesses that didn't exist. They told students
that even learning COBOL would ruin them as programmers (shades
of Dijkstra!!)

On 12/10/21 20:12, Arne Vajhøj wrote:
> On 12/10/2021 10:46 AM, chris wrote:
>> If you are a developer, you should try to walk the walk in terms
>> of ethics and try to do the right thing. In the real world though,
>> people will do whatever needs to be done to find a solution if there
>> seems to b an insurmountable obstacle.
>>
>> The other point is, do the original owners really care enough, or
>> even at all, when so much licensed software is out there and is
>> obsolete and no longer sold ?. Similar case here, where I was trying
>> find detail on the write boot block code for early SunOs for historical
>> purposes. Found the complete source cd online and was able to complete
>> the task. No profit involved, other than keeping some old machines
>> alive.
>>
>> Ethical dilemmas everywhere in life and we all have to make our
>> own choices...
>
> I don't think there is much ethical dilemma here.
>
> There should be no doubt that following the law is the etical
> solution here.
>
> Arne
>

Well, that's my whole point, but if no license is available from the
original vendor, or they have ceased to exist, the user should stop
using the product, irrespective of the effect on their business ?.

Imho, it's a gross breach of good faith and trust for a vendor to
provide no means of continuance in such cases...

Chris

On 12/12/2021 6:32 PM, Bill Gunshannon wrote:
> Exactly.  Those of us who have been around since before then
> watched it happen.  OOP came out.  Academia pushed it as the
> ultimate paradigm. Languages that had been around successfully
> doing what they did for decades grafted OOP into their languages
> and forced it down people's throats.  Object COBOL came out.
> COBOL practitioners of the art laughed and announced that the
> emperor really had no clothes on at all and refused to re-write
> all their applications in the new paradigm.  Academia's reaction
> was to take a page out of the Amish rule book.  They shunned COBOL.
> They stopped teaching it even in CIS courses where it was still
> the most practical language to get the job done.  They attacked
> it claiming weaknesses that didn't exist.  They told students
> that even learning COBOL would ruin them as programmers (shades
> of Dijkstra!!)

Nice story, but it has nothing to do with reality.

Computer Science never liked Cobol - they were on the Algol
and Pascal wagon back in the 60's and 70's.

Lesser academic educations teaching programming typical
dropped Cobol in the 90's due to lack of demand.

(and non-IT areas like Physics, Medicine and Economics were
Fortran back then)

Cobol first got OO features in 2002.

It is pretty obvious from the timeline that lack of interest
in OO Cobol was not the reason for Cobol's missing presence
in education.

Computer science did push OOP back in the 80's and 90's. But
the industry was very much involved as well (Apple: object-pascal
and objective-c; Borland: later Turbo Pascal, Delphi;
Microsoft: C++; SUN: C++, Java). And even some of the
academic research was funded by the industry (AT&T, Xerox etc.), so
OO is not an academic thing.

And it has thrived because of the value it provides - not because
universities pushed it. The last 10-20 years Computer Science
has pushed FP not OOP. But true FP has never really caught on
in the industry. Most OOP languages got a few FP features and
they are used for convenience, but not enough to be true FP.

Arne

On 12/12/2021 9:22 AM, Bill Gunshannon wrote:
> On 12/11/21 7:38 PM, Arne Vajhøj wrote:
>> On 12/11/2021 7:12 PM, Bill Gunshannon wrote:
>>> On 12/11/21 2:25 PM, Arne Vajhøj wrote:
>>>> On 12/11/2021 1:40 PM, Bill Gunshannon wrote:
>>>>> On 12/11/21 11:51 AM, Arne Vajhøj wrote:
>>>>>> And all the largest systems are distributed. They use
>>>>>> Hadoop, Cassandra, Kafka etc.. Traditional technologies
>>>>>> does simply not scale to that level.
>>>>>
>>>>> You wanna bet?  While some of the frontend stuff has mofrated to
>>>>> the typical web crap the IRS for example is still a Unisys OS2200
>>>>> shop with the code being mostly Legacy ACOB carried forward from
>>>>> its origination on a UNIVAC 1100.
>>>>
>>>> Yes. And that system may have been a big system 30 years ago.
>>>
>>> The US IRS is one of the biggest ISes in the world.  Large enough
>>> that some of the biggest contracting companies in the United States
>>> looked at an RFP to replace it and said it probably couldn't be
>>> done.  And so it is still written mostly in COBOL running on Unisys
>>> OS2200.
>>>
>>>>
>>>> But today large systems are NNN/NNNN nodes, NNNN CPU's, N/NN TB
>>>> memory and N PB disk.
>>>
>>> In what way does that contradict what I said above?  Or are you one
>>> of those people who think IBM Mainframe still means 360/40.
>>
>> A z15 max out at 24 CPU with 190 cores for application and OS
>> and 40 TB memory 192 IO cards.
>>
>> The largest Unisys (the 8300) is as far as I can read only
>> 8 CPU with 64 cores for application and OS and 512 GB of memory.
>>
>> It just doesn't scale to what companies with large data processing
>> requirements need today.
>>
>> 11 years ago(!) the largest Hadoop cluster had 2000 CPU with 22400
>> cores, 64 TB memory and 21 PB data on disk.
>
> And yet the IRS is doing it just fine.  Go figure.

Sure. They got a mid-size problem and their system capable
of handling mid-size problems does fine.

Those that have a very large problem would not be fine.

Of course IRS could get the same mid-size capability for way
less money on a different platform, but porting is probably
expensive. And they do not have any competitors to worry about! :-)

> And then we have DFAS which is an IBM shop handles payroll for all
> the military and civilians in DOD.  A bit more than any company I
> can think  of.
>
> And then we also have the DOD EMR system.  Every member of the
> military, all their dependents, all the retirees that are still
> getting care at an MTF (like me!)  That's and IBM mainframe, too.
> and the application is written in COBOL.

Yes.

I suspect they fit pretty nicely with my original description:
- is processing money
- first version was written before 1995
- has not been rewritten after 1995

> Seems that COBOL and mainframes are doing just fine.

IBM's mainframe revenue is decreasing over time (it spikes
every year they release a new model and plummets when there
is no new model, but the trend is downwards). Still significant
money though.

Decreasing revenue is not doing fine.

> Just so you will know where I am coming from on this, there is
> a strong move to push "modernization" of mainframes.  The current
> definition of "modernization" is move to a different platform and
> re-write all your applications in the language du jour.

My impression is that it is like:

90% : too expensive and risky to port so stay
4% : port to Cobol on Linux/Windows
4% : port to Java on Linux/Windows
2% : port to C# on Windows

(Java is from 1995 and C# is from 2002 so not anything new)

Arne

On 2021-12-10, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 12/10/2021 8:16 PM, Dave Froble wrote:
>> On 12/10/2021 6:59 PM, Arne Vajhøj wrote:
>>> On 12/10/2021 4:56 PM, Dave Froble wrote:
>>>> We are talking hypothetical here.  I'm not advocating anything today.
>>>>
>>>> Don't vendors make a commitment to customers when they sell them the
>>>> use of
>>>> something like VMS?  If so, and the vendor defaults, isn't that an
>>>> issue?
>>>> Don't customers have any rights?  Is it really stealing to continue
>>>> to use a
>>>> product that one purchased in good faith?
>>>
>>> If VSI sell you a license to run VMS from time 1-JAN-2022 to forever
>>> or from 1-JAN-2022 to 31-DEC-2023, then you have a right to exactly that.
>>
>> But VSI also says you can purchase another year of support, right?
>
> I don't think VSI has made legal commitments that you will be able
> to purchase what you can today indefinitely out in the future.
>

I also don't think they have stated they will not raise prices
beyond a certain percentage per year in the future.

For the record, I don't think VSI would do something like raising
the prices by a stupid percentage per year, but any successor
organisation which bought VSI's assets may consider doing that once
they realised they had a captive market for the time-limited licences
(at least for the short term).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-12-10, Dave Froble <davef@tsoft-inc.com> wrote:
> On 12/10/2021 2:23 PM, Simon Clubley wrote:
>>
>> Ownership of assets doesn't cease just because a company fails.
>>
>> You are setting yourself and your customers up for a future owner
>> of the VSI assets to come after you, especially if you reduce the
>> resale value of those assets by coming up with a way to bypass the
>> need for existing VMS customers to purchase more of those assets.
>
> If there is an entity that allows my customers to continue, then there isn't an
> issue, is there?
>

What do you do if someone buys VSI's assets but will only sell you a
new licence for a 500% markup (for example) ?

When you bought your time-limited licences, did you also get a guarantee
that future price rises would be limited to a certain percentage and was
that guarantee written in such a way that is binds any successor organisation
which buys VSI's assets ?

>>
>> You know what VSI have done by putting time limits on production
>> licences and you could port away today if the risk is unacceptable
>> to you.
>
> Porting is not an option.
>

Really ? Are you sure ? Have you talked to the various porting outfits
that move VMS code to Linux ? Or do they not support DEC Basic ?

>> That is your legal option to remove this risk.
>>
>> Why do you think so many people are angry with VSI for introducing
>> time-limited production licences instead of just saying that they
>> will patch VMS to bypass the licences if VSI fails ?
>>
>> They clearly understand the legal issues and risks involved with trying
>> to do what you suggest.
>
> Ok Simon, I'll turn things around. If you had customers depending on VMS, or
> any software, and the vendor went away, and your customers needed to continue to
> use their applications, what would you do? Would you do whatever was necessary
> for your customers to continue, or, would you tell your customers "too bad, you
> lose"?
>
> I'm talking right now, today, no time for your port, or anything else.
>

If you have let things get that far without any planning then you have
not done any of the standard business planning for what do you do if
a critical vendor goes bust.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 12/12/2021 8:35 AM, Henry Crun wrote:
> Where I work (government land administration) started in 2014 I was told
> I was there for a two-year project to move several hundred COBOL
> programs to a Windows database system. Seven years later, it's due to be
> comleted "by the end of 2022."
> Several dozen programmers working on and around the project, also
> mantaining the (still operational, live system) COBOL.
> Just saying...

Delayed IT projects are not that unusual.

But it sounds like they are getting there and not going back.

Arne

On 2021-12-10, Dave Froble <davef@tsoft-inc.com> wrote:
>
> It occurs to me this can be reversed. Customers have an implied, if not more
> specific, contract with the vendor. Should another entity acquire the software,
> and not fulfill this contract, perhaps they could be sued to force them to honor
> the contract. Acquire the product, you also acquire the responsibilities.
>
> This could be fun. Lawyers could have a field day.
>

Your contract has an expiry date. You have no rights once that expiry
date is passed.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2021-12-10, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 12/10/2021 8:11 PM, Bill Gunshannon wrote:
>> On 12/10/21 8:05 PM, Dave Froble wrote:
>>> So, in your opinion, should customers continue to stick with VMS?
>>
>> Not my call to make.  I no longer have a dog in the fight.
>> If the p[people using VMS feel comfortable staying there that's fine.
>> Obviously, many already have not.  I think the current owners are a
>> better bet than the last. At least the current owners actually want
>> to see it succeed. But only the current users can make the decision
>> of whether or not to stay.  And assume all the risks that entails.
>
> The risk seems pretty low to me.
>
> The x86-64 port is almost complete that means new and cheap
> hardware available for many years to come.
>

It's not the hardware that's the problem in the minds of many people.

It's the fact that VMS is the road less travelled these days and it
comes with restrictions (time-limited production licences) that many
find unacceptable and which is not a problem in what these days are
more mainstream operating systems.

IOW, when asking people to choose VMS, you are asking them to go
down the road less travelled _and_ you are asking them to choose
a much more restrictive licence that they would not have to do if
they stayed with a mainstream operating system.

Now imagine how that looks in the eyes of a upper manager that has
no real emotional bond to VMS.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 12/12/21 7:34 PM, chris wrote:
> On 12/10/21 20:12, Arne Vajhøj wrote:
>> On 12/10/2021 10:46 AM, chris wrote:
>>> If you are a developer, you should try to walk the walk in terms
>>> of ethics and try to do the right thing. In the real world though,
>>> people will do whatever needs to be done to find a solution if there
>>> seems to b an insurmountable obstacle.
>>>
>>> The other point is, do the original owners really care enough, or
>>> even at all, when so much licensed software is out there and is
>>> obsolete and no longer sold ?. Similar case here, where I was trying
>>> find detail on the write boot block code for early SunOs for historical
>>> purposes. Found the complete source cd online and was able to complete
>>> the task. No profit involved, other than keeping some old machines
>>> alive.
>>>
>>> Ethical dilemmas everywhere in life and we all have to make our
>>> own choices...
>>
>> I don't think there is much ethical dilemma here.
>>
>> There should be no doubt that following the law is the etical
>> solution here.
>>
>> Arne
>>
>
> Well, that's my whole point, but if no license is available from the
> original vendor, or they have ceased to exist, the user should stop
> using the product, irrespective of the effect on their business ?.
>
> Imho, it's a gross breach of good faith and trust for a vendor to
> provide no means of continuance in such cases...
>

Companies come and go. Most don't want to fail, but it happens.
But I hardly think it is their fault that a customer doesn't take
appropriate actions to protect their future. Back in my mainframe
days we used to have COOP plans. Now, they were more targeted at
disasters like 9/11 but the idea is sound for even less disastrous
situations. If one sees a possibility (no matter how vague) of a
situation that could result in their demise they really should make
the effort to plan for it. And those plans should be updated and
maybe even movced up in priority if the vagueness seems to be fading
and the threat seems closer.

bill

On 12/13/21 1:53 PM, Arne Vajhøj wrote:
> On 12/12/2021 9:22 AM, Bill Gunshannon wrote:
>> On 12/11/21 7:38 PM, Arne Vajhøj wrote:
>>> On 12/11/2021 7:12 PM, Bill Gunshannon wrote:
>>>> On 12/11/21 2:25 PM, Arne Vajhøj wrote:
>>>>> On 12/11/2021 1:40 PM, Bill Gunshannon wrote:
>>>>>> On 12/11/21 11:51 AM, Arne Vajhøj wrote:
>>>>>>> And all the largest systems are distributed. They use
>>>>>>> Hadoop, Cassandra, Kafka etc.. Traditional technologies
>>>>>>> does simply not scale to that level.
>>>>>>
>>>>>> You wanna bet?  While some of the frontend stuff has mofrated to
>>>>>> the typical web crap the IRS for example is still a Unisys OS2200
>>>>>> shop with the code being mostly Legacy ACOB carried forward from
>>>>>> its origination on a UNIVAC 1100.
>>>>>
>>>>> Yes. And that system may have been a big system 30 years ago.
>>>>
>>>> The US IRS is one of the biggest ISes in the world.  Large enough
>>>> that some of the biggest contracting companies in the United States
>>>> looked at an RFP to replace it and said it probably couldn't be
>>>> done.  And so it is still written mostly in COBOL running on Unisys
>>>> OS2200.
>>>>
>>>>>
>>>>> But today large systems are NNN/NNNN nodes, NNNN CPU's, N/NN TB
>>>>> memory and N PB disk.
>>>>
>>>> In what way does that contradict what I said above?  Or are you one
>>>> of those people who think IBM Mainframe still means 360/40.
>>>
>>> A z15 max out at 24 CPU with 190 cores for application and OS
>>> and 40 TB memory 192 IO cards.
>>>
>>> The largest Unisys (the 8300) is as far as I can read only
>>> 8 CPU with 64 cores for application and OS and 512 GB of memory.
>>>
>>> It just doesn't scale to what companies with large data processing
>>> requirements need today.
>>>
>>> 11 years ago(!) the largest Hadoop cluster had 2000 CPU with 22400
>>> cores, 64 TB memory and 21 PB data on disk.
>>
>> And yet the IRS is doing it just fine.  Go figure.
>
> Sure. They got a mid-size problem and their system capable
> of handling mid-size problems does fine.

Mid-size? Do you have any iodea what the US IRS is and what they do?

>
> Those that have a very large problem would not be fine.
>
> Of course IRS could get the same mid-size capability for way
> less money on a different platform, but porting is probably
> expensive. And they do not have any competitors to worry about! :-)

Expense wasn't the problem. They have pretty deep pockets. :-)
The problem was the ability to accomplish a port given the constraints
they run under. Realize, of course, it was not the IRS that wanted
the "modernization" Their system works just fine. As is usually
the case it was outsiders (thinking much like it appears you do) who
were driving the bus.

>
>> And then we have DFAS which is an IBM shop handles payroll for all
>> the military and civilians in DOD.  A bit more than any company I
>> can think  of.
>>
>> And then we also have the DOD EMR system.  Every member of the
>> military, all their dependents, all the retirees that are still
>> getting care at an MTF (like me!)  That's and IBM mainframe, too.
>> and the application is written in COBOL.
>
> Yes.
>
> I suspect they fit pretty nicely with my original description:
> - is processing money
> - first version was written before 1995
> - has not been rewritten after 1995
>
>> Seems that COBOL and mainframes are doing just fine.
>
> IBM's mainframe revenue is decreasing over time (it spikes
> every year they release a new model and plummets when there
> is no new model, but the trend is downwards). Still significant
> money though.
>
> Decreasing revenue is not doing fine.

Well, long after VSI ans VMS are gone I expect IBM and zSystems
(probably even iSystems) will still be around, I seem to remember
that one of the original purposes of VAX and VMS was to kill IBM's
small systems. Didn't happen. The only company I know first hand
was trounced by DEC was Pr1me and that was more their fault than
DEC's.

>
>> Just so you will know where I am coming from on this, there is
>> a strong move to push "modernization" of mainframes.  The current
>> definition of "modernization" is move to a different platform and
>> re-write all your applications in the language du jour.
>
> My impression is that it is like:
>
> 90% : too expensive and risky to port so stay
> 4%  : port to Cobol on Linux/Windows
> 4%  : port to Java on  Linux/Windows
> 2%  : port to C# on  Windows
>
> (Java is from 1995 and C# is from 2002 so not anything new)
>
> Arne

bill

On 12/13/21 1:26 PM, Arne Vajhøj wrote:
> On 12/12/2021 6:32 PM, Bill Gunshannon wrote:
>> Exactly.  Those of us who have been around since before then
>> watched it happen.  OOP came out.  Academia pushed it as the
>> ultimate paradigm. Languages that had been around successfully
>> doing what they did for decades grafted OOP into their languages
>> and forced it down people's throats.  Object COBOL came out.
>> COBOL practitioners of the art laughed and announced that the
>> emperor really had no clothes on at all and refused to re-write
>> all their applications in the new paradigm.  Academia's reaction
>> was to take a page out of the Amish rule book.  They shunned COBOL.
>> They stopped teaching it even in CIS courses where it was still
>> the most practical language to get the job done.  They attacked
>> it claiming weaknesses that didn't exist.  They told students
>> that even learning COBOL would ruin them as programmers (shades
>> of Dijkstra!!)
>
> Nice story, but it has nothing to do with reality.

Well, I was there and my view is somewhat different than yours.

>
> Computer Science never liked Cobol - they were on the Algol
> and Pascal wagon back in the 60's and 70's.

There was no CS in the 60's and only later in the 70's It was
just a sideline for math departments. In any event, most CS
departments had two tracks CS and CIS. CS played with Unix
and C and CIS was COBOL, PL/1 (in IBM dominated areas like
Marist College) and even some RPG and 360 BAL.

>
> Lesser academic educations teaching programming typical
> dropped Cobol in the 90's due to lack of demand.

We kept a COBOL course on the books well into the 90's but it
was never offered. COBOL was used in a mandatory (for both CS
and CIS programs) course, Until the early 2000's. It was done
using DEC COBOL until the day they made me remove the last VMS
machines from my data center. It was not unsuitability that
resulted in these changes it was politics. Both VMS and COBOL
were seen as "legacy". Something the students shouldn't even
be introduced to. VMS was easier to get rid of because all
they had to do was tell me to get rid of the hardware. COBOL
took a little longer (and a lot more work) because the course
using it had to be redone.

>
> (and non-IT areas like Physics, Medicine and Economics were
> Fortran back then)
>
> Cobol first got OO features in 2002.
>
> It is pretty obvious from the timeline that lack of interest
> in OO Cobol was not the reason for Cobol's missing presence
> in education.

Really? Then where do you assign the blame?

>
> Computer science did push OOP back in the 80's and 90's. But
> the industry was very much involved as well (Apple: object-pascal
> and objective-c; Borland: later Turbo Pascal, Delphi;
> Microsoft: C++; SUN: C++, Java). And even some of the
> academic research was funded by the industry (AT&T, Xerox etc.), so
> OO is not an academic thing.

It started there and once they stopped teaching non-OOP pardigms
what did the people coming out to places like AT&T, Apple, Xerox,
etc. know other than OOP?

>
> And it has thrived because of the value it provides - not because
> universities pushed it. The last 10-20 years Computer Science
> has pushed FP not OOP. But true FP has never really caught on
> in the industry. Most OOP languages got a few FP features and
> they are used for convenience, but not enough to be true FP.

Sadly, I think OOP is going to be here a long time. I am just
glad the people working where it is not a good fit have resisted
it. I still do COBOL. Mostly just for fun, but it is still
interesting. You should go over to Rosetta Code and see all the
things COBOL does that aren't even in its wheelhouse.

bill

On 12/13/2021 3:26 PM, Bill Gunshannon wrote:
> On 12/13/21 1:53 PM, Arne Vajhøj wrote:
>> On 12/12/2021 9:22 AM, Bill Gunshannon wrote:
>>> On 12/11/21 7:38 PM, Arne Vajhøj wrote:
>>>> On 12/11/2021 7:12 PM, Bill Gunshannon wrote:
>>>>> On 12/11/21 2:25 PM, Arne Vajhøj wrote:
>>>>>> On 12/11/2021 1:40 PM, Bill Gunshannon wrote:
>>>>>>> On 12/11/21 11:51 AM, Arne Vajhøj wrote:
>>>>>>>> And all the largest systems are distributed. They use
>>>>>>>> Hadoop, Cassandra, Kafka etc.. Traditional technologies
>>>>>>>> does simply not scale to that level.
>>>>>>>
>>>>>>> You wanna bet?  While some of the frontend stuff has mofrated to
>>>>>>> the typical web crap the IRS for example is still a Unisys OS2200
>>>>>>> shop with the code being mostly Legacy ACOB carried forward from
>>>>>>> its origination on a UNIVAC 1100.
>>>>>>
>>>>>> Yes. And that system may have been a big system 30 years ago.
>>>>>
>>>>> The US IRS is one of the biggest ISes in the world.  Large enough
>>>>> that some of the biggest contracting companies in the United States
>>>>> looked at an RFP to replace it and said it probably couldn't be
>>>>> done.  And so it is still written mostly in COBOL running on Unisys
>>>>> OS2200.
>>>>>
>>>>>>
>>>>>> But today large systems are NNN/NNNN nodes, NNNN CPU's, N/NN TB
>>>>>> memory and N PB disk.
>>>>>
>>>>> In what way does that contradict what I said above?  Or are you one
>>>>> of those people who think IBM Mainframe still means 360/40.
>>>>
>>>> A z15 max out at 24 CPU with 190 cores for application and OS
>>>> and 40 TB memory 192 IO cards.
>>>>
>>>> The largest Unisys (the 8300) is as far as I can read only
>>>> 8 CPU with 64 cores for application and OS and 512 GB of memory.
>>>>
>>>> It just doesn't scale to what companies with large data processing
>>>> requirements need today.
>>>>
>>>> 11 years ago(!) the largest Hadoop cluster had 2000 CPU with 22400
>>>> cores, 64 TB memory and 21 PB data on disk.
>>>
>>> And yet the IRS is doing it just fine.  Go figure.
>>
>> Sure. They got a mid-size problem and their system capable
>> of handling mid-size problems does fine.
>
> Mid-size?  Do you have any iodea what the US IRS is and what they do?

Yes.

But you told what HW they are running on. And from that it is
an mid-size task.

>> Those that have a very large problem would not be fine.
>>
>> Of course IRS could get the same mid-size capability for way
>> less money on a different platform, but porting is probably
>> expensive. And they do not have any competitors to worry about! :-)
>
> Expense wasn't the problem.  They have pretty deep pockets. :-)
> The problem was the ability to accomplish a port given the constraints
> they run under.

It is a hard thing to port. The CPU/memory/disk requirement are
mid size. But the requirements are very large.

US Tax rules supposedly consist of 2500 pages of law and 9000
pages of regulations. That is 29 volumes of 400 pages. Hard
problem.

And anybody think that they would simplify rules to make a
port easier or even just freeze rules during a port??

:-)

Arne

On 12/13/21 3:44 PM, Arne Vajhøj wrote:
> On 12/13/2021 3:26 PM, Bill Gunshannon wrote:
>> On 12/13/21 1:53 PM, Arne Vajhøj wrote:
>>> On 12/12/2021 9:22 AM, Bill Gunshannon wrote:
>>>> On 12/11/21 7:38 PM, Arne Vajhøj wrote:
>>>>> On 12/11/2021 7:12 PM, Bill Gunshannon wrote:
>>>>>> On 12/11/21 2:25 PM, Arne Vajhøj wrote:
>>>>>>> On 12/11/2021 1:40 PM, Bill Gunshannon wrote:
>>>>>>>> On 12/11/21 11:51 AM, Arne Vajhøj wrote:
>>>>>>>>> And all the largest systems are distributed. They use
>>>>>>>>> Hadoop, Cassandra, Kafka etc.. Traditional technologies
>>>>>>>>> does simply not scale to that level.
>>>>>>>>
>>>>>>>> You wanna bet?  While some of the frontend stuff has mofrated to
>>>>>>>> the typical web crap the IRS for example is still a Unisys OS2200
>>>>>>>> shop with the code being mostly Legacy ACOB carried forward from
>>>>>>>> its origination on a UNIVAC 1100.
>>>>>>>
>>>>>>> Yes. And that system may have been a big system 30 years ago.
>>>>>>
>>>>>> The US IRS is one of the biggest ISes in the world.  Large enough
>>>>>> that some of the biggest contracting companies in the United States
>>>>>> looked at an RFP to replace it and said it probably couldn't be
>>>>>> done.  And so it is still written mostly in COBOL running on Unisys
>>>>>> OS2200.
>>>>>>
>>>>>>>
>>>>>>> But today large systems are NNN/NNNN nodes, NNNN CPU's, N/NN TB
>>>>>>> memory and N PB disk.
>>>>>>
>>>>>> In what way does that contradict what I said above?  Or are you one
>>>>>> of those people who think IBM Mainframe still means 360/40.
>>>>>
>>>>> A z15 max out at 24 CPU with 190 cores for application and OS
>>>>> and 40 TB memory 192 IO cards.
>>>>>
>>>>> The largest Unisys (the 8300) is as far as I can read only
>>>>> 8 CPU with 64 cores for application and OS and 512 GB of memory.
>>>>>
>>>>> It just doesn't scale to what companies with large data processing
>>>>> requirements need today.
>>>>>
>>>>> 11 years ago(!) the largest Hadoop cluster had 2000 CPU with 22400
>>>>> cores, 64 TB memory and 21 PB data on disk.
>>>>
>>>> And yet the IRS is doing it just fine.  Go figure.
>>>
>>> Sure. They got a mid-size problem and their system capable
>>> of handling mid-size problems does fine.
>>
>> Mid-size?  Do you have any iodea what the US IRS is and what they do?
>
> Yes.
>
> But you told what HW they are running on. And from that it is
> an mid-size task.
>
>>> Those that have a very large problem would not be fine.
>>>
>>> Of course IRS could get the same mid-size capability for way
>>> less money on a different platform, but porting is probably
>>> expensive. And they do not have any competitors to worry about! :-)
>>
>> Expense wasn't the problem.  They have pretty deep pockets. :-)
>> The problem was the ability to accomplish a port given the constraints
>> they run under.
>
> It is a hard thing to port. The CPU/memory/disk requirement are
> mid size. But the requirements are very large.
>
> US Tax rules supposedly consist of 2500 pages of law and 9000
> pages of regulations. That is 29 volumes of 400 pages. Hard
> problem.
>
> And anybody think that they would simplify rules to make a
> port easier or even just freeze rules during a port??
>

You missed the big one. No down time. The new system would have
to go into operation functioning perfectly from not just day one,
but from minute one. It's a 24 hours a day 365 days a year (except
every four years when it is a 366 day) job :-). How many large
scale porting projects have you seen accomplish that?

bill