On 2023-02-25 13:00, Neil Rieck wrote:
> I first used COBOL on an HP-3000 more than 40-years ago and would like to remind everyone here that a COBOL compiler license was always very expensive. Heck, some companies like IBM hung their reputations on being able to run COBOL programs -AND- that their compilers produced the largest amount of executable binary which is backwards from the way we think today. IIRC, full ISAM support was an optional purchase on all PDP-11 operating systems from DEC, but then DEC decided to bundle it with VMS primarily to support the never released COBOL-80 standard (later appeared as COBOL-85).

ISAM support was standard on at least RSX and RSTS/E. RMS is a standard
component. However, keywords like SORT in COBOL (it is a keyword,
right?) requires SORT-11 which was standard on RSTS/E but was/is a
separate layered product on RSX.

> comment: ISAM was important elsewhere on VMS including the fact that SYSUAF.DAT was indexed

Yeah, I don't think anything in RSTS/E or RSX on the system level used
indexed files. VMS I know a little bit less, but since RMS integration
went deeper in VMS, I'm not surprised if more things made use of it.

> I've only been working with Linux since 2016 but have been surprised about the quantity of good quality software in that eco-system which can be obtained for free. Anyone who has ever used gcc (gnu compiler collection) knows what I am typing about. This tool can generate C11 by the way.
>
> (CAVEAT: the down side of opensource is that if you discover a bug, it may take years to get it fixed. In some instances you are better off fixing the problem yourself then submitting the solution to the authors. This has happened to me more times than one would think. This happened to me last week with the python SOAP library known as zeep)

That downside is also an upside. If you discover a bug you do not have
to wait for the author to fix it. If it is urgent/important, you can fix
it immediately yourself. I would say that is a *big* upside.

Johnny

On 2/26/2023 10:05 AM, Johnny Billquist wrote:
> On 2023-02-25 13:00, Neil Rieck wrote:
>> I first used COBOL on an HP-3000 more than 40-years ago and would like
>> to remind everyone here that a COBOL compiler license was always very
>> expensive. Heck, some companies like IBM hung their reputations on
>> being able to run COBOL programs -AND- that their compilers produced
>> the largest amount of executable binary which is backwards from the
>> way we think today. IIRC, full ISAM support was an optional purchase
>> on all PDP-11 operating systems from DEC, but then DEC decided to
>> bundle it with VMS primarily to support the never released COBOL-80
>> standard (later appeared as COBOL-85).
>
> ISAM support was standard on at least RSX and RSTS/E. RMS is a standard
> component.

I was curious enough to look in my RSTS/E product biiklet from
83-84. No mention of an option there.

> However, keywords like SORT in COBOL (it is a keyword,
> right?) requires SORT-11 which was standard on RSTS/E but was/is a
> separate layered product on RSX.

In it's early days SORT was almost always a call to an external
routine for COBOL. At least it was in my experience with UNIVAC
and IBM.

>
>> comment: ISAM was important elsewhere on VMS including the fact that
>> SYSUAF.DAT was indexed
>
> Yeah, I don't think anything in RSTS/E or RSX on the system level used
> indexed files. VMS I know a little bit less, but since RMS integration
> went deeper in VMS, I'm not surprised if more things made use of it.

Today, it is hard to imagine any reason for using ISAM/VSAM. Small
Simple Databases like MySQL/MariaDB or SQLite can do a better job
and in most cases are probably just as easy to understand. GnuCOBOL
integrates both of them quite well.

>
>> I've only been working with Linux since 2016 but have been surprised
>> about the quantity of good quality software in that eco-system which
>> can be obtained for free. Anyone who has ever used gcc (gnu compiler
>> collection) knows what I am typing about. This tool can generate C11
>> by the way.
>>
>> (CAVEAT: the down side of opensource is that if you discover a bug, it
>> may take years to get it fixed. In some instances you are better off
>> fixing the problem yourself then submitting the solution to the
>> authors. This has happened to me more times than one would think. This
>> happened to me last week with the python SOAP library known as zeep)
>
> That downside is also an upside. If you discover a bug you do not have
> to wait for the author to fix it. If it is urgent/important, you can fix
> it immediately yourself. I would say that is a *big* upside.

That only works if you still have a real IT Department. Too many
businesses have outsourced all of this to the cloud and different
kinds of OPC (Other People's Computers) leaving themselves at the
mercy of other people to keep their business going. The IT world
has become no different than all the other business with supply
chain problems because they decided having it done in another
country was a wise decision.

bill

> different kinds of OPC (Other People's Computers)

Not to mention Other People's People.

De

On 2/26/2023 3:14 PM, bill wrote:
> On 2/26/2023 10:05 AM, Johnny Billquist wrote:
>> On 2023-02-25 13:00, Neil Rieck wrote:
>>> comment: ISAM was important elsewhere on VMS including the fact that
>>> SYSUAF.DAT was indexed
>>
>> Yeah, I don't think anything in RSTS/E or RSX on the system level used
>> indexed files. VMS I know a little bit less, but since RMS integration
>> went deeper in VMS, I'm not surprised if more things made use of it.
>
> Today, it is hard to imagine any reason for using ISAM/VSAM.  Small
> Simple Databases like MySQL/MariaDB or SQLite can do a better job
> and in most cases are probably just as easy to understand.

RDBMS would be the default today. SQLite for embedded.
MySQL/MariaDB or PostgreSQL or commercial for server.

There are still use cases for ISAM or to use a more
modern term NoSQL key value store. But I believe there
is little intersection between those use cases and
the use cases for Cobol today. Cobol is used for
money and money is stored in RDBMS.

Arne

On 2/26/2023 4:10 PM, Dennis Boone wrote:
> > different kinds of OPC (Other People's Computers)
>
> Not to mention Other People's People.
>

That's implied with OPC. :-)

bill

On 2/26/2023 3:14 PM, bill wrote:
> On 2/26/2023 10:05 AM, Johnny Billquist wrote:
>> On 2023-02-25 13:00, Neil Rieck wrote:
>>> (CAVEAT: the down side of opensource is that if you discover a bug,
>>> it may take years to get it fixed. In some instances you are better
>>> off fixing the problem yourself then submitting the solution to the
>>> authors. This has happened to me more times than one would think.
>>> This happened to me last week with the python SOAP library known as
>>> zeep)
>>
>> That downside is also an upside. If you discover a bug you do not have
>> to wait for the author to fix it. If it is urgent/important, you can
>> fix it immediately yourself. I would say that is a *big* upside.
>
> That only works if you still have a real IT Department. Too many
> businesses have outsourced all of this to the cloud and different
> kinds of OPC (Other People's Computers) leaving themselves at the
> mercy of other people to keep their business going.  The IT world
> has become no different than all the other business with supply
> chain problems because they decided having it done in another
> country was a wise decision.

Even if the company has kept an IT department with
software developers, then very few companies has
the necessary skill sets or the financials to fund fixing
large complex open source software like an OS or
a RDBMS.

Linux, Apache, MySQL, PHP, LibreOffice etc. are used
by hundreds of thousands or millions of companies
world wide. But how many of them could and would
take on fixing bugs in the source. I suspect that
would be counted in a few thousands.

Arne

On 2/26/2023 4:30 PM, Arne Vajhøj wrote:
> On 2/26/2023 3:14 PM, bill wrote:
>> On 2/26/2023 10:05 AM, Johnny Billquist wrote:
>>> On 2023-02-25 13:00, Neil Rieck wrote:
>>>> (CAVEAT: the down side of opensource is that if you discover a bug, it may
>>>> take years to get it fixed. In some instances you are better off fixing the
>>>> problem yourself then submitting the solution to the authors. This has
>>>> happened to me more times than one would think. This happened to me last
>>>> week with the python SOAP library known as zeep)
>>>
>>> That downside is also an upside. If you discover a bug you do not have to
>>> wait for the author to fix it. If it is urgent/important, you can fix it
>>> immediately yourself. I would say that is a *big* upside.
>>
>> That only works if you still have a real IT Department. Too many
>> businesses have outsourced all of this to the cloud and different
>> kinds of OPC (Other People's Computers) leaving themselves at the
>> mercy of other people to keep their business going. The IT world
>> has become no different than all the other business with supply
>> chain problems because they decided having it done in another
>> country was a wise decision.
>
> Even if the company has kept an IT department with
> software developers, then very few companies has
> the necessary skill sets or the financials to fund fixing
> large complex open source software like an OS or
> a RDBMS.
>
> Linux, Apache, MySQL, PHP, LibreOffice etc. are used
> by hundreds of thousands or millions of companies
> world wide. But how many of them could and would
> take on fixing bugs in the source. I suspect that
> would be counted in a few thousands.

My suspicions are no better than yours, but, I'd be surprised if there was even
100. System type software is different from application software.

--
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 2/26/2023 6:47 PM, Dave Froble wrote:
> On 2/26/2023 4:30 PM, Arne Vajhøj wrote:
>> Linux, Apache, MySQL, PHP, LibreOffice etc. are used
>> by hundreds of thousands or millions of companies
>> world wide. But how many of them could and would
>> take on fixing bugs in the source. I suspect that
>> would be counted in a few thousands.
>
> My suspicions are no better than yours, but, I'd be surprised if there
> was even 100.  System type software is different from application software.

Linux in 2019 had 4189 contributors.

PHP GitHub repo has 896 contributors.

LibreOffice GitHub repo has 1152 contributors.

Obviously the number of companies are less
than the number of individual contributors.

But there are some people out there and some
companies with such people.

Still a very small fraction of the entire pool
of software developers as that is being estimated
to be around 25 million.

Arne

On 2/26/2023 4:30 PM, Arne Vajhøj wrote:
> Linux, Apache, MySQL, PHP, LibreOffice etc. are used
> by hundreds of thousands or millions of companies
> world wide. But how many of them could and would
> take on fixing bugs in the source. I suspect that
> would be counted in a few thousands.

For most companies the benefit from open source is not
being able to fix bugs themselves, but that for *popular*
open source they have more than one option for paying
to get bugs fixed.

Arne

On 2023-02-25, Scott Dorsey <kludge@panix.com> wrote:
> John Dallman <jgd@cix.co.uk> wrote:
>>In article <ttd4ta$2j12a$2@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
>>wrote:
>>
>>> There are of course also some differences. C# got
>>> unsafe blocks with pointers (nobody use them) ...
>>
>>The main thing those are useful for is calling native code. It's way
>>easier than using JNI.
>
> Which of course defeats the whole purpose of having a sandbox... but that's
> Microsoft...
> --scott

Nothing to do with Microsoft, at least for me.

My experience with JNI is using it on Android.

My experience with JNI also tells me that whoever designed it had better
not hang around anyone using it in the real world. :-)

Simon.

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

On 2023-02-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 2/25/2023 7:36 PM, Arne Vajhøj wrote:
>> Java does have the ability to call native unsafe code via JNI (assuming
>> not blocked by a security manager).
>>
>> But in some weird way then the fact that using JNI is about as
>> much fun as getting a root canal treatment at the dentist has
>> probably helped keeping most Java WORA.
>
> Note that Java is getting a new way to call native code.
> "Foreign functions" has been in preview in since Java 16.
> I don't think it has been decided yet when it will be
> deemed production ready - maybe Java 21 or 22.
>

I wonder how long before it shows up in Android (and how much more
locked down Android will be by then. :-( ) ?

Simon.

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

On 2/26/2023 7:36 PM, Simon Clubley wrote:
> On 2023-02-25, Scott Dorsey <kludge@panix.com> wrote:
>> John Dallman <jgd@cix.co.uk> wrote:
>>> In article <ttd4ta$2j12a$2@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
>>> wrote:
>>>> There are of course also some differences. C# got
>>>> unsafe blocks with pointers (nobody use them) ...
>>>
>>> The main thing those are useful for is calling native code. It's way
>>> easier than using JNI.
>>
>> Which of course defeats the whole purpose of having a sandbox...

> My experience with JNI is using it on Android.
>
> My experience with JNI also tells me that whoever designed it had better
> not hang around anyone using it in the real world. :-)

JNI is very cumbersome to use.

But it was invented at a different time.

In 1996:
- Java was very small
- there were many times more C/C++ developers than Java developers
- there were a need for something very efficient because hardware
was way slower than today
- there was a need for a mechanism that could be implemented on
any platform
so they decided to do the glue code in C/C++ and not in Java.

Today the world is different and choices made back then are
no longer optimal.

But I do not see the new foreign function interface having
been a realistic option back then.

Arne

On 2/26/2023 6:47 PM, Dave Froble wrote:
> On 2/26/2023 4:30 PM, Arne Vajhøj wrote:
>> On 2/26/2023 3:14 PM, bill wrote:
>>> On 2/26/2023 10:05 AM, Johnny Billquist wrote:
>>>> On 2023-02-25 13:00, Neil Rieck wrote:
>>>>> (CAVEAT: the down side of opensource is that if you discover a bug,
>>>>> it may
>>>>> take years to get it fixed. In some instances you are better off
>>>>> fixing the
>>>>> problem yourself then submitting the solution to the authors. This has
>>>>> happened to me more times than one would think. This happened to me
>>>>> last
>>>>> week with the python SOAP library known as zeep)
>>>>
>>>> That downside is also an upside. If you discover a bug you do not
>>>> have to
>>>> wait for the author to fix it. If it is urgent/important, you can
>>>> fix it
>>>> immediately yourself. I would say that is a *big* upside.
>>>
>>> That only works if you still have a real IT Department. Too many
>>> businesses have outsourced all of this to the cloud and different
>>> kinds of OPC (Other People's Computers) leaving themselves at the
>>> mercy of other people to keep their business going.  The IT world
>>> has become no different than all the other business with supply
>>> chain problems because they decided having it done in another
>>> country was a wise decision.
>>
>> Even if the company has kept an IT department with
>> software developers, then very few companies has
>> the necessary skill sets or the financials to fund fixing
>> large complex open source software like an OS or
>> a RDBMS.
>>
>> Linux, Apache, MySQL, PHP, LibreOffice etc. are used
>> by hundreds of thousands or millions of companies
>> world wide. But how many of them could and would
>> take on fixing bugs in the source. I suspect that
>> would be counted in a few thousands.
>
> My suspicions are no better than yours, but, I'd be surprised if there
> was even 100.  System type software is different from application software.
>
>

Times have changed. In this factor as well as the rest.

My first full-time job as a programmer was doing applications
programming on a Univac 1100 mainframe. I was pretty good at
and I worked hard. The reward was a transfer from SAPB (Systems
Analysis and Programming Branch) to SSSB (Systems Software Support
Branch).

At one time IT departments had systems people as well as applications
people. I miss those days.

bill

On 2/26/2023 8:13 PM, bill wrote:
> On 2/26/2023 6:47 PM, Dave Froble wrote:
>> On 2/26/2023 4:30 PM, Arne Vajhøj wrote:
>>> Linux, Apache, MySQL, PHP, LibreOffice etc. are used
>>> by hundreds of thousands or millions of companies
>>> world wide. But how many of them could and would
>>> take on fixing bugs in the source. I suspect that
>>> would be counted in a few thousands.
>>
>> My suspicions are no better than yours, but, I'd be surprised if there
>> was even 100.  System type software is different from application
>> software.
>
> Times have changed.  In this factor as well as the rest.
>
> My first full-time job as a programmer was doing applications
> programming on a Univac 1100 mainframe.  I was pretty good at
> and I worked hard.  The reward was a transfer from SAPB (Systems
> Analysis and Programming Branch) to SSSB (Systems Software Support
> Branch).
>
> At one time IT departments had systems people as well as applications
> people.  I miss those days.

The code bases were smaller in those days.

Today you may have:
- OS 50 MLOC
- language compiler and runtime library 10 MLOC
- database 10 MLOC
- web server, cache server and MQ server 10 MLOC
- bunch of open source libraries 40 MLOC
giving a total of 120 MLOC.

Nobody want to touch such huge code base.

And nobody want to reimplement such huge code
bases (even if the company only need 1/10th of
the functionality resulting in only needing
1/10th of the code then it is prohibitive
expensive for anybody outside of top-100).

Arne

> My experience with JNI also tells me that whoever designed it had better
> not hang around anyone using it in the real world. :-)

You haven't lived until you've had to replace the Loonix JNI jar in a
search tool written in Jruby with one that works on your actual
platform.

De

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>
>Even if the company has kept an IT department with
>software developers, then very few companies has
>the necessary skill sets or the financials to fund fixing
>large complex open source software like an OS or
>a RDBMS.
>
>Linux, Apache, MySQL, PHP, LibreOffice etc. are used
>by hundreds of thousands or millions of companies
>world wide. But how many of them could and would
>take on fixing bugs in the source. I suspect that
>would be counted in a few thousands.

It's true. When I was starting out, every big DP shop had a systems
programmer whose job was to add useful site-specific features to the OS,
and to do the primary diagnosis when problems were found in the OS. They
might not have been able to fix bugs in the source but they could identify
where they were and they knew who to talk to at 1-800-IBM-CICS to get it
fixed.

As systems have become more complex and we have developed a greater need
for such people, we have been training fewer and fewer of them.

You could argue that the need for customized environments is reduced today,
now that standardized environments are more sophisticated. I don't agree
with that at all but it is a thing which could be debated.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On Friday, February 24, 2023 at 8:20:19 AM UTC-5, Simon Clubley wrote:
> On 2023-02-23, ultr...@gmail.com <ultr...@gmail.com> wrote:
> >
> > I HELPED MY SON WITH C++ AND C# IN COLLEGE ... SAME OLD C SAME OLD COMPILER/DEBUGGER ISSUES
> If you consider C# to be in any way related to C, then you are _very_
> seriously delusional.
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

it's not and I'm not ... C# is a gamers language.

On Friday, February 24, 2023 at 8:20:19 AM UTC-5, Simon Clubley wrote:
> On 2023-02-23, ultr...@gmail.com <ultr...@gmail.com> wrote:
> >
> > I HELPED MY SON WITH C++ AND C# IN COLLEGE ... SAME OLD C SAME OLD COMPILER/DEBUGGER ISSUES
> If you consider C# to be in any way related to C, then you are _very_
> seriously delusional.
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

but its design came from the same screwed up design of a language

On Thursday, February 23, 2023 at 5:05:50 PM UTC-5, Paul Gavin wrote:
> What, DEC C cannot be debugged?
>
> Working on some enhancements in a C based app on Alphas running 8.4.
> Can get to debugger just fine, step through code, look at data, set break points, etc., even from within ACMS.

never debugged dec c but if the compiler debugger is anything like C it is difficult ...

On 27/02/2023 16:49, ultr...@gmail.com wrote:
> On Thursday, February 23, 2023 at 5:05:50 PM UTC-5, Paul Gavin wrote:
>> What, DEC C cannot be debugged?
>>
>> Working on some enhancements in a C based app on Alphas running 8.4.
>> Can get to debugger just fine, step through code, look at data, set break points, etc., even from within ACMS.
>
> never debugged dec c but if the compiler debugger is anything like C it is difficult ...

Not that I used that much C, but I found it was normally easy to debug
if needed

--
Chris

On Mon, 2023-02-27 at 08:46 -0800, ultr...@gmail.com wrote:
> it's not and I'm not ... C# is a gamers language.

What did you expect from Microsoft? Their offerings have been crap
since the dawn of Computing!
--
Tactical Nuclear Kittens

On 2/27/2023 10:37 AM, Scott Dorsey wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>>
>> Even if the company has kept an IT department with
>> software developers, then very few companies has
>> the necessary skill sets or the financials to fund fixing
>> large complex open source software like an OS or
>> a RDBMS.
>>
>> Linux, Apache, MySQL, PHP, LibreOffice etc. are used
>> by hundreds of thousands or millions of companies
>> world wide. But how many of them could and would
>> take on fixing bugs in the source. I suspect that
>> would be counted in a few thousands.
>
> It's true. When I was starting out, every big DP shop had a systems
> programmer whose job was to add useful site-specific features to the OS,
> and to do the primary diagnosis when problems were found in the OS. They
> might not have been able to fix bugs in the source but they could identify
> where they were and they knew who to talk to at 1-800-IBM-CICS to get it
> fixed.

I remember those days ..

> As systems have become more complex and we have developed a greater need
> for such people, we have been training fewer and fewer of them.
>
> You could argue that the need for customized environments is reduced today,
> now that standardized environments are more sophisticated. I don't agree
> with that at all but it is a thing which could be debated.
> --scott

I'm with you on this. What I'm seeing is that some "standardized environments"
is actually "this is what you're going to get, don't ask for more".

Example: We've told our Codis customers that we're pretty much done. We
offered them the software so they could continue to use and maintain it. Lazy
bums. They have been looking at "cloud solutions". All too often they are
asking for things and are told "we can't do that". However, walk over to the
Codis system, and the same things have been happening for years.

Perhaps "standardized environments" aren't so good for everyone?

--
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 2/27/2023 11:47 AM, ultr...@gmail.com wrote:
> On Friday, February 24, 2023 at 8:20:19 AM UTC-5, Simon Clubley wrote:
>> On 2023-02-23, ultr...@gmail.com <ultr...@gmail.com> wrote:
>>>
>>> I HELPED MY SON WITH C++ AND C# IN COLLEGE ... SAME OLD C SAME OLD COMPILER/DEBUGGER ISSUES
>> If you consider C# to be in any way related to C, then you are _very_
>> seriously delusional.
>> Simon.
>>
>> --
>> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
>> Walking destinations on a map are further away than they appear.
>
> but its design came from the same screwed up design of a language
>

Of course, isn't it "monkey see, monkey do"? Lots of monkeys ...

--
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 2/27/2023 11:49 AM, ultr...@gmail.com wrote:
> On Thursday, February 23, 2023 at 5:05:50 PM UTC-5, Paul Gavin wrote:
>> What, DEC C cannot be debugged?
>> Working on some enhancements in a C based app on Alphas running 8.4.
>> Can get to debugger just fine, step through code, look at data, set break points, etc., even from within ACMS.
>
> never debugged dec c but if the compiler debugger is anything like C it is difficult ...

The VMS C compiler behaves pretty much like other VMS compilers.

The same VMS debugger is used for C as for any other (DEC/CPQ/HPE/VSI)
language.

Arne

On 2/27/2023 11:46 AM, ultr...@gmail.com wrote:
> On Friday, February 24, 2023 at 8:20:19 AM UTC-5, Simon Clubley wrote:
>> On 2023-02-23, ultr...@gmail.com <ultr...@gmail.com> wrote:
>>>
>>> I HELPED MY SON WITH C++ AND C# IN COLLEGE ... SAME OLD C SAME OLD COMPILER/DEBUGGER ISSUES
>> If you consider C# to be in any way related to C, then you are _very_
>> seriously delusional.
>
> it's not and I'm not ... C# is a gamers language.

The #1 area of usage for C# must be web applications and web services.

With backend applications, desktop apps and games sharing #2-#4 spots.

Arne