> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Simon Clubley
> via Info-vax
> Sent: Friday, November 11, 2022 2:19 PM
> To: info-vax@rbnsn.com
> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
> Subject: Re: [Info-vax] The real problem that needs solving to grow VMS
>
> On 2022-11-11, <kemain.nospam@gmail.com>
> <kemain.nospam@gmail.com> wrote:
> >
> > How about an application environment whereby the nature of the
> > application environment required a well established shared disk
> > strategy rather than a shared nothing strategy?
> >
> > Reference: Pro's and Con's of shared disk vs. shared nothing
> ><http://www.benstopford.com/2009/11/24/understanding-the-shared-
> nothing
> >-arch
> > itecture/>
> >
>
> Some reading for you Kerry:
>
> https://en.wikipedia.org/wiki/GFS2
>

If you had read one of my recent posts regarding this topic, you would have
seen where I stated "shared disk (OpenVMS, Linux GFS2 and z/OS)"

But I stated well established .. this fully supported GFS2 technology was
only integrated into RHEL since V5.3. (2010 timeframe). Also, GFS2 is not
currently widely used in the Linux world.

Combine that with 3 disk shadowing, cluster wide logicals, multi-site
clusters, cluster system disk upgrades etc.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 11/11/2022 7:21 PM, kemain.nospam@gmail.com wrote:
>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Simon Clubley via Info-vax
>> Sent: Friday, November 11, 2022 2:19 PM
>> On 2022-11-11, <kemain.nospam@gmail.com>
>> <kemain.nospam@gmail.com> wrote:
>>> How about an application environment whereby the nature of the
>>> application environment required a well established shared disk
>>> strategy rather than a shared nothing strategy?
>>>
>>> Reference: Pro's and Con's of shared disk vs. shared nothing
>>> <http://www.benstopford.com/2009/11/24/understanding-the-shared-nothing-architecture/>
>>
>> Some reading for you Kerry:
>>
>> https://en.wikipedia.org/wiki/GFS2
>
> If you had read one of my recent posts regarding this topic, you would have
> seen where I stated "shared disk (OpenVMS, Linux GFS2 and z/OS)"

Yep.

> But I stated well established .. this fully supported GFS2 technology was
> only integrated into RHEL since V5.3. (2010 timeframe).

That (2010 timeframe) is pretty new in the VMS world (8.4 was released
in 2010 I believe).

But that (release was January 20th 2009) is actually pretty well established
in the Linux world. RHEL is at 9.0 / 8.7 today. And 5.x is long out of
support.

> Also, GFS2 is not
> currently widely used in the Linux world.

True.

But that is because the IT world today use databases with
their own sync mechanisms not file system with an OS
provided DLM.

The demand is not there.

Arne

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj
> via Info-vax
> Sent: Friday, November 11, 2022 10:13 PM
> To: info-vax@rbnsn.com
> Cc: Arne Vajhøj <arne@vajhoej.dk>
> Subject: Re: [Info-vax] The real problem that needs solving to grow VMS
>
> On 11/11/2022 7:21 PM, kemain.nospam@gmail.com wrote:
> >> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Simon
> >> Clubley via Info-vax
> >> Sent: Friday, November 11, 2022 2:19 PM On 2022-11-11,
> >> <kemain.nospam@gmail.com> <kemain.nospam@gmail.com> wrote:
> >>> How about an application environment whereby the nature of the
> >>> application environment required a well established shared disk
> >>> strategy rather than a shared nothing strategy?
> >>>
> >>> Reference: Pro's and Con's of shared disk vs. shared nothing
> >>> <http://www.benstopford.com/2009/11/24/understanding-the-shared-
> noth
> >>> ing-architecture/>
> >>
> >> Some reading for you Kerry:
> >>
> >> https://en.wikipedia.org/wiki/GFS2
> >
> > If you had read one of my recent posts regarding this topic, you would
> > have seen where I stated "shared disk (OpenVMS, Linux GFS2 and z/OS)"
>
> Yep.
>
> > But I stated well established .. this fully supported GFS2 technology
> > was only integrated into RHEL since V5.3. (2010 timeframe).
>
> That (2010 timeframe) is pretty new in the VMS world (8.4 was released in
> 2010 I believe).
>

Integrated OpenVMS Clustering was introduced back in OpenVMS V4.0 - back in
the 1983-84 timeframe. Hence, OpenVMS clustering has been battle tested and
refined in mission critical environments for approx. 40 years now.

> But that (release was January 20th 2009) is actually pretty well
established in
> the Linux world. RHEL is at 9.0 / 8.7 today. And 5.x is long out of
support.
>
> > Also, GFS2 is not
> > currently widely used in the Linux world.
>
> True.
>
> But that is because the IT world today use databases with their own sync
> mechanisms not file system with an OS provided DLM.
>
> The demand is not there.
>

Again - both shared nothing and shared disk cluster (including multi-site)
strategies have pro's and con's, but the data sync'ing across distributed
shared nothing systems while at the same time addressing typical CAP
(consistency, availability, partitioned data - pick two) is not an easy
thing to support in real life.

As a reference:
<http://highscalability.com/blog/2015/10/12/making-the-case-for-building-sca
lable-stateful-services-in-t.html>
Extract - "A stateless architecture is easy to scale horizontally and only
requires simple round-robin load balancing. What’s not to love? Perhaps the
increased latency from the roundtrips to the database. Or maybe the
complexity of the caching layer required to hide database latency problems.
Or even the troublesome consistency issues."

See rest of article.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 2022-11-11, <kemain.nospam@gmail.com> <kemain.nospam@gmail.com> wrote:
>> -----Original Message-----
>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Simon Clubley
>> via Info-vax
>>
>> Some reading for you Kerry:
>>
>> https://en.wikipedia.org/wiki/GFS2
>>
>
> If you had read one of my recent posts regarding this topic, you would have
> seen where I stated "shared disk (OpenVMS, Linux GFS2 and z/OS)"
>

Yes, I saw those. You conveniently missed that little bit out when trying
to say shared disks were a unique selling point for VMS. :-)

> But I stated well established .. this fully supported GFS2 technology was
> only integrated into RHEL since V5.3. (2010 timeframe). Also, GFS2 is not
> currently widely used in the Linux world.
>

Percentage wise or absolute numbers ?

On an absolute numbers basis, I wonder how many use GFS2 compared to VMS
shared disks ?

BTW, GFS2 was something VSI was actively looking at for the new filesystem.

Simon.

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

On Tuesday, November 1, 2022 at 7:13:03 PM UTC-5, Dave Froble wrote:
> On 11/1/2022 3:48 PM, Phillip Helbig (undress to reply) wrote:
> > In article <tjrs45$erh$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
> > <ar...@vajhoej.dk> writes:
> >
> >> I am not aware of buying VMS licenses should not be easy. You
> >> contact VSI, you pay and you get your license. Anyone have had
> >> problems?
> >>
> >> Some may think the price is too high. But heck I also think that
> >> Ferrari's are too expensive as I can't afford one, but that is life.
> >
> > No, the issue is that most people can't get a non-expiring license.
> > CURRENT customers are not moving to x86 because of that; getting new
> > ones will be even more difficult.
> >
> Customers aren't moving to x86, yet, because there are no native compilers.
> Most will not choose cross compilers. At least that is my opinion.
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

Once the native compilers are available for x86, maybe VSI could try to go after the AI crowd. There are neural nets in Fortran already:

https://github.com/modern-fortran/neural-fortran

On 2022-11-15, Robert Carleton <rbc@rbcarleton.com> wrote:
>
> Once the native compilers are available for x86, maybe VSI could try to go after the AI crowd. There are neural nets in Fortran already:
>
> https://github.com/modern-fortran/neural-fortran

That will probably be as well-received as the move a few years ago to
position VMS as something suitable for the blockchain world. :-)

There's nothing that seems to be unique to VMS for AI that can be a selling
point for VMS.

Simon.

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

On 11/15/2022 11:01 AM, Robert Carleton wrote:
> On Tuesday, November 1, 2022 at 7:13:03 PM UTC-5, Dave Froble wrote:
>> On 11/1/2022 3:48 PM, Phillip Helbig (undress to reply) wrote:
>>> In article <tjrs45$erh$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
>> Customers aren't moving to x86, yet, because there are no native compilers.
>> Most will not choose cross compilers. At least that is my opinion.
>
> Once the native compilers are available for x86, maybe VSI could try to go after the AI crowd.

That does not sound attractive to me.

AI is depending on:
* low cost systems, read: no money to pay for OS, which makes
it not interesting for VSI
* high-end GPU's or even custom HW, which is not supported by VMS

Arne

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Simon Clubley
> via Info-vax
> Sent: Monday, November 14, 2022 2:56 PM
> To: info-vax@rbnsn.com
> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
> Subject: Re: [Info-vax] The real problem that needs solving to grow VMS
>
> On 2022-11-11, <kemain.nospam@gmail.com>
> <kemain.nospam@gmail.com> wrote:
> >> -----Original Message-----
> >> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Simon
> >> Clubley via Info-vax
> >>
> >> Some reading for you Kerry:
> >>
> >> https://en.wikipedia.org/wiki/GFS2
> >>
> >
> > If you had read one of my recent posts regarding this topic, you would
> > have seen where I stated "shared disk (OpenVMS, Linux GFS2 and z/OS)"
> >
>
> Yes, I saw those. You conveniently missed that little bit out when trying
to
> say shared disks were a unique selling point for VMS. :-)
>

Nice try.

Re-read that post. I clearly stated there were pro's and con's with shared
disk vs. shared nothing application architectures.

My reference clearly stated that shared disk application architectures have
both advantages and disadvantages compared to shared nothing architectures.

> > But I stated well established .. this fully supported GFS2 technology
> > was only integrated into RHEL since V5.3. (2010 timeframe). Also, GFS2
> > is not currently widely used in the Linux world.
> >
>
> Percentage wise or absolute numbers ?

There has been many public testimonials in the past regarding OpenVMS
clusters in very mission critical environments.

Perhaps I missed them, but can you provide any external references to Linux
GFS2 used in mission critical and very HA clusters?

>
> On an absolute numbers basis, I wonder how many use GFS2 compared to
> VMS shared disks ?
>
> BTW, GFS2 was something VSI was actively looking at for the new
filesystem.
>
> Simon.
>

As an option for OpenVMS Customers - not a total rip-n-replace.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 2022-11-16, <kemain.nospam@gmail.com> <kemain.nospam@gmail.com> wrote:
>> -----Original Message-----
>> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Simon Clubley
>> via Info-vax
>>
>> Percentage wise or absolute numbers ?
>
> There has been many public testimonials in the past regarding OpenVMS
> clusters in very mission critical environments.
>
> Perhaps I missed them, but can you provide any external references to Linux
> GFS2 used in mission critical and very HA clusters?
>

Well, one reference would be VSI. They clearly considered it to be good
enough for their largest customers who need such capabilities.

>>
>> On an absolute numbers basis, I wonder how many use GFS2 compared to
>> VMS shared disks ?
>>
>> BTW, GFS2 was something VSI was actively looking at for the new
> filesystem.
>
> As an option for OpenVMS Customers - not a total rip-n-replace.
>

You are correct Kerry. It was an option being looked at by VSI to
allow VMS to carry out some of the workloads that Linux can do but
which VMS currently cannot do.

With that in mind, we are back to my original (still unanswered)
question. What is the unique selling point for VMS that would allow
a new site to consider it in spite of all the problems with doing so ?

Adding functionality to make VMS do what another OS can already do
is not by itself a unique selling point.

Simon.

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

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Simon Clubley
> via Info-vax
> Sent: Thursday, November 17, 2022 9:35 AM
> To: info-vax@rbnsn.com
> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
> Subject: Re: [Info-vax] The real problem that needs solving to grow VMS
>
> On 2022-11-16, <kemain.nospam@gmail.com>
> <kemain.nospam@gmail.com> wrote:
> >> -----Original Message-----
> >> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Simon
> >> Clubley via Info-vax
> >>
> >> Percentage wise or absolute numbers ?
> >
> > There has been many public testimonials in the past regarding OpenVMS
> > clusters in very mission critical environments.
> >
> > Perhaps I missed them, but can you provide any external references to
> > Linux
> > GFS2 used in mission critical and very HA clusters?
> >
>
> Well, one reference would be VSI. They clearly considered it to be good
> enough for their largest customers who need such capabilities.
>
> >>
> >> On an absolute numbers basis, I wonder how many use GFS2 compared
> to
> >> VMS shared disks ?
> >>
> >> BTW, GFS2 was something VSI was actively looking at for the new
> > filesystem.
> >
> > As an option for OpenVMS Customers - not a total rip-n-replace.
> >
>
> You are correct Kerry. It was an option being looked at by VSI to allow
VMS to
> carry out some of the workloads that Linux can do but which VMS currently
> cannot do.
>
> With that in mind, we are back to my original (still unanswered) question.
> What is the unique selling point for VMS that would allow a new site to
> consider it in spite of all the problems with doing so ?
>
> Adding functionality to make VMS do what another OS can already do is not
> by itself a unique selling point.
>
> Simon.
>

See earlier post with whitepaper link regarding comparisons of shared
nothing vs. shared disk App architectures.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On Saturday, November 5, 2022 at 4:59:18 AM UTC+11, Dave Froble wrote:
> On 11/4/2022 9:52 AM, Simon Clubley wrote:
> > On 2022-11-03, Dave Froble <da...@tsoft-inc.com> wrote:
> >> On 11/3/2022 9:20 AM, Simon Clubley wrote:
> >>> On 2022-11-02, Dave Froble <da...@tsoft-inc.com> wrote:
> >>>>
> >>>> Software that solves specific issues for a particular vertical market many times
> >>>> will not exist in other software packages. The list can be rather long. Just a
> >>>> few examples:
> >>>>
> >>>> Handling of cores
> >>>> Superscession of part numbers
> >>>>
> >>>> The lack of either of those examples is a total show stopper.
> >>>>
> >>>> This is applications that have over 40 years of specific development for this
> >>>> particular vertical market. Some obsolete. Some quite recent.
> >>>>
> >>>> The customers have looked hard for those "alternate ERP packages". The search
> >>>> has failed.
> >>>>
> >>>> One customer is trying a cloud solution. Looks like they are on course for a
> >>>> future crater.
> >>>>
> >>>> You can claim all you want about alternatives. Doesn't mean any exist.
> >>>>
> >>>> The most common response from potential new vendors is "we can't do that".
> >>>>
> >>>
> >>> What is it precisely about supersessions that new vendors can't do ?
> >>
> >> The biggest issue with potential new vendors is that they seem to have never
> >> heard of the concept, and don't want to hear about it.
> >>
> >
> > I'm finding that rather hard to understand. Parts management, regardless
> > of industry, has a number of universal factors associated with it, and
> > supersession management is one of the core ones.
> >
> > I could understand them having issues with the more complex scenarios
> > (which depends on how much effort they put into their software), but basic
> > supersessions, where exactly one existing part number is renamed to exactly
> > one new part number, are easy to implement.
> Consider simple things such as gaskets and such. Sourced from multiple mfgs,
> each with their own part numbers, which can change quite often. A superscession
> loop of more than 20 part numbers is quite normal.
> > Who exactly are these vendors ?
> >
> > Simon.
> >
> Small outdoor power equipment distributors.
>
> Software vendors in the auto parts business have attempted to enter this market
> multiple times, and have failed every time. Talking about some rather large
> software vendors.
>
> It is strange, as one would think that auto parts software should work. Has not.
>
> Believe it or not, there are instances where things need to be specific, and one
> size fits all fails miserably.
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

I don't believe you use any relational DB for your application do you?
(I base this on that I don't recall you mentioning things like using RDB in your posts but I could be wrong)

A relational DB would certainly help with standardized offerings but as you said, your application appears to have a lot of specific coding / loose model / one off representation needs

In regards to your application, I would think a Graph DB, something like Neo4j, would have no issues modelling the data and relationships in the application you work on and would certainly support the flexibility required to link various objects and relationships together in flexible arrangements. Most of the relationships that you probably have buried in code would be defined in the Graph DB relationship mapping

Neo4j / Graph DB's are used by most of the large social media companies to model billions of relationships involving multiple depths of relationships. They remind me of the old object DB's, except more developed and on steroids

One use case for Neo4j is that of the US army, that uses Neo4j to track a Bill of Materials. Probably something similar in concept to what your application tracks in terms of object relationships?

This is worth a quick read.
https://neo4j.com/blog/top-10-use-cases-bill-of-materials/

Some of the models can be quite involved

https://nodexlgraphgallery.org/Pages/Graph.aspx?graphID=230312

It runs on Linux, Windows, Mac OS but sadly, not VMS

You can even download the desktop version and kick the tires with it

I've been trying to use it to model software testing components for a large software conversion project, as a learning exercise, I can see the potential but I lack the knowledge of Neo4j to quickly knock out solutions, so it's a hard grind of learning in my own time :-(

On 11/22/2022 10:46 AM, IanD wrote:
> I don't believe you use any relational DB for your application do
> you? (I base this on that I don't recall you mentioning things like
> using RDB in your posts but I could be wrong)

Dave is known to use index-sequential files.

> A relational DB would certainly help with standardized offerings but
> as you said, your application appears to have a lot of specific
> coding / loose model / one off representation needs
>
> In regards to your application, I would think a Graph DB, something
> like Neo4j, would have no issues modelling the data and relationships
> in the application you work on and would certainly support the
> flexibility required to link various objects and relationships
> together in flexible arrangements. Most of the relationships that you
> probably have buried in code would be defined in the Graph DB
> relationship mapping
>
> Neo4j / Graph DB's are used by most of the large social media
> companies to model billions of relationships involving multiple
> depths of relationships. They remind me of the old object DB's,
> except more developed and on steroids

I believe graph databases are closed to the old network model databases
(like VAX CODASYL database) than to object oriented databases.

> One use case for Neo4j is that of the US army, that uses Neo4j to
> track a Bill of Materials. Probably something similar in concept to
> what your application tracks in terms of object relationships?
>
> This is worth a quick read.
> https://neo4j.com/blog/top-10-use-cases-bill-of-materials/
>
> Some of the models can be quite involved
>
> https://nodexlgraphgallery.org/Pages/Graph.aspx?graphID=230312

> I've been trying to use it to model software testing components for a
> large software conversion project, as a learning exercise, I can see
> the potential but I lack the knowledge of Neo4j to quickly knock out
> solutions, so it's a hard grind of learning in my own time :-(

They have some market share.

It is my impression that they are mostly used for analytical work
and not so much for for transactional/CRUD work. Not to just save
and retrieve data but for trying to get some insight out of the data.

How that fits with Dave's usage I have no idea.

> It runs on Linux, Windows, Mac OS but sadly, not VMS

Neo4J is one of those mixed open source / commercial products.

So the commercial version is not available for VMS and the
open source version has never been tested on VMS, but Neo4J
is written in Java and Scala, so in theory it may run on
VMS.

Anyone with interest and lots of time could try to get
3.x running on VMS Itanium - that has Java 8 (4.x requires
Java 11 and 5.x requires Java 17, so those are not options).

Arne

On 2022-11-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 11/22/2022 10:46 AM, IanD wrote:
>> I don't believe you use any relational DB for your application do
>> you? (I base this on that I don't recall you mentioning things like
>> using RDB in your posts but I could be wrong)
>
> Dave is known to use index-sequential files.
>

Even better. :-) It's David's own ISAM solution written in Macro-32
that he uses. :-)

> > I've been trying to use it to model software testing components for a
> > large software conversion project, as a learning exercise, I can see
> > the potential but I lack the knowledge of Neo4j to quickly knock out
> > solutions, so it's a hard grind of learning in my own time :-(
>
> They have some market share.
>
> It is my impression that they are mostly used for analytical work
> and not so much for for transactional/CRUD work. Not to just save
> and retrieve data but for trying to get some insight out of the data.
>
> How that fits with Dave's usage I have no idea.
>

It doesn't. David's problem is a normal transaction based problem with
issuing and managing items, but with the added complexity that the part
number can change on a regular basis. Supersessions and supersession loops
are part of normal parts management and the surprise is not the problem,
but the fact the vendors his customers are talking to can't handle them.

Simon.

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

On 11/23/2022 8:11 AM, Simon Clubley wrote:
> On 2022-11-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/22/2022 10:46 AM, IanD wrote:
>>> I don't believe you use any relational DB for your application do
>>> you? (I base this on that I don't recall you mentioning things like
>>> using RDB in your posts but I could be wrong)
>>
>> Dave is known to use index-sequential files.
>>
>
> Even better. :-) It's David's own ISAM solution written in Macro-32
> that he uses. :-)

Well to be fair, the original idea for the database came from Lee Bitterman, and
the original ISAM implementation was written by Dan Rosen. Both very smart
guys. The original implementation was in Basic+. I'll admit to some
refinements along the way.

>>> I've been trying to use it to model software testing components for a
>>> large software conversion project, as a learning exercise, I can see
>>> the potential but I lack the knowledge of Neo4j to quickly knock out
>>> solutions, so it's a hard grind of learning in my own time :-(
>>
>> They have some market share.
>>
>> It is my impression that they are mostly used for analytical work
>> and not so much for for transactional/CRUD work. Not to just save
>> and retrieve data but for trying to get some insight out of the data.
>>
>> How that fits with Dave's usage I have no idea.
>>
>
> It doesn't. David's problem is a normal transaction based problem with
> issuing and managing items, but with the added complexity that the part
> number can change on a regular basis. Supersessions and supersession loops
> are part of normal parts management and the surprise is not the problem,
> but the fact the vendors his customers are talking to can't handle them.

Some of the younger people in IT seem to lack understanding of some fundamentals.

--
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 11/23/2022 9:00 AM, Dave Froble wrote:
> On 11/23/2022 8:11 AM, Simon Clubley wrote:
>> On 2022-11-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 11/22/2022 10:46 AM, IanD wrote:
>>>> I've been trying to use it to model software testing components for a
>>>> large software conversion project, as a learning exercise, I can see
>>>> the potential but I lack the knowledge of Neo4j to quickly knock out
>>>> solutions, so it's a hard grind of learning in my own time :-(
>>>
>>> They have some market share.
>>>
>>> It is my impression that they are mostly used for analytical work
>>> and not so much for for transactional/CRUD work. Not to just save
>>> and retrieve data but for trying to get some insight out of the data.
>>>
>>> How that fits with Dave's usage I have no idea.
>>
>> It doesn't. David's problem is a normal transaction based problem with
>> issuing and managing items, but with the added complexity that the part
>> number can change on a regular basis. Supersessions and supersession
>> loops
>> are part of normal parts management and the surprise is not the problem,
>> but the fact the vendors his customers are talking to can't handle them.
>
> Some of the younger people in IT seem to lack understanding of some
> fundamentals.

In general terms you are using:

application----embedded NoSQL key value store database (VMS
index-sequential files)

or depending on view:

application----embedded custom database (hierachical? network?
other?)----embedded NoSQL key value store database (VMS index-sequential
files)

Ian noted that *if* you wanted to change that then instead
of the obvious:

application----relational database

there are also the possibility of:

application----NoSQL graph database

Anything can probably be made to work with enough effort - the question
is what is the best solution.

My point was that I only think that the NoSQL graph database
is a good solution if the core problem is analytical not
transactional in nature.

Simon stated that it is transactional.

(and continue to express his surprise that more standard
item management systems can't handle it - which is not
really relevant for the choice of database paradigm)

Arne

On 11/23/2022 9:24 AM, Arne Vajhøj wrote:
> On 11/23/2022 9:00 AM, Dave Froble wrote:
>> On 11/23/2022 8:11 AM, Simon Clubley wrote:
>>> On 2022-11-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 11/22/2022 10:46 AM, IanD wrote:
>>>>> I've been trying to use it to model software testing components for a
>>>>> large software conversion project, as a learning exercise, I can see
>>>>> the potential but I lack the knowledge of Neo4j to quickly knock out
>>>>> solutions, so it's a hard grind of learning in my own time :-(
>>>>
>>>> They have some market share.
>>>>
>>>> It is my impression that they are mostly used for analytical work
>>>> and not so much for for transactional/CRUD work. Not to just save
>>>> and retrieve data but for trying to get some insight out of the data.
>>>>
>>>> How that fits with Dave's usage I have no idea.
>>>
>>> It doesn't. David's problem is a normal transaction based problem with
>>> issuing and managing items, but with the added complexity that the part
>>> number can change on a regular basis. Supersessions and supersession loops
>>> are part of normal parts management and the surprise is not the problem,
>>> but the fact the vendors his customers are talking to can't handle them.
>>
>> Some of the younger people in IT seem to lack understanding of some fundamentals.
>
> In general terms you are using:
>
> application----embedded NoSQL key value store database (VMS index-sequential files)
>
> or depending on view:
>
> application----embedded custom database (hierachical? network?
> other?)----embedded NoSQL key value store database (VMS index-sequential files)
>
> Ian noted that *if* you wanted to change that then instead
> of the obvious:
>
> application----relational database
>
> there are also the possibility of:
>
> application----NoSQL graph database
>
> Anything can probably be made to work with enough effort - the question
> is what is the best solution.
>
> My point was that I only think that the NoSQL graph database
> is a good solution if the core problem is analytical not
> transactional in nature.
>
> Simon stated that it is transactional.
>
> (and continue to express his surprise that more standard
> item management systems can't handle it - which is not
> really relevant for the choice of database paradigm)

Correct.

There is usually more than one solution to most problems. And a RDBMS has many
advantages. If I was starting over today, I'd most likely attempt to use a RDBMS.

As for the "standard" of "one size fits all", that too often is a very poor
solution. Creating pretzels rarely fits a solution that needs a straight line.

--
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 11/23/2022 11:48 AM, John Dallman wrote:
> In article <tll90k$cotm$1@dont-email.me>, davef@tsoft-inc.com (Dave
> Froble) wrote:
>> On 11/23/2022 8:11 AM, Simon Clubley wrote:
>>> It doesn't. David's problem is a normal transaction based problem
>>> with issuing and managing items, but with the added complexity that
>>> the part number can change on a regular basis. Supersessions and
>>> supersession loops are part of normal parts management and the
>>> surprise is not the problem, but the fact the vendors his customers
>>> are talking to can't handle them.
>> Some of the younger people in IT seem to lack understanding of some
>> fundamentals.
>
> Many of them are taught about relational databases as some kind of holy
> writ, the answer to everything that reality has to adjust to. The
> original promoters of relational databases tended to do that, and their
> ideas have been uncritically accepted.

20 years ago relational databases was *it* for persistence. Today
it is a bit more blurred.

The 21 yo CS student that are very active on SO will
probably say MongoDB (NoSQL document store).

The web 3.0 startup currently running out of VC capital
will probably also say MongoDB.

The desktop app developer will probably say SQLite (relational).

The small or large business needing to store money data related
to their business will probably say Oracle DB or MS SQLServer
or PostreSQL or MySQL (relational). [this is the VMS market!!]

The web scale business needing to store info on a large
portion of the worlds population will probably say
sharded MySQL or PostgreSQL (relational) and
for certain high volume data RocksDB or similar
(NoSQL key value store) for the transactional
processing and then Cassandra or HBase (NoSQL
wide column store) for data analysis.

Arne

On 2022-11-23 14:00:03 +0000, Dave Froble said:

> On 11/23/2022 8:11 AM, Simon Clubley wrote:
>>
>> ...David's problem is a normal transaction based problem with issuing
>> and managing items, but with the added complexity that the part number
>> can change on a regular basis. Supersessions and supersession loops are
>> part of normal parts management and the surprise is not the problem,
>> but the fact the vendors his customers are talking to can't handle them.
>
> Some of the younger people in IT seem to lack understanding of some
> fundamentals.

Some of the older people in IT, too. IT is big and increasingly
complex. Which means everybody has gaps in their knowledge.

--
Pure Personal Opinion | HoffmanLabs LLC

In article <tk9jug$12ar$1@gioia.aioe.org>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 11/2/2022 9:30 AM, Simon Clubley wrote:
>[snip]
>> could you also answer why people would be
>> willing to put the future of their company at risk by buying a product
>> from a small vendor (VSI) that will stop working if that vendor goes bust ?
>
>If VSI goes bust - which there is no indication that it will - and
>if there is noone picking up VMS - which seems unlikely if there
>are companies willing to pay - and it falls unlucky at the
>end of a license period and if the server is critical and if
>they did not negotiate and got a forever license from VSI, then
>it would be a problem.
>
>But that is a lot of if's.

That _is_ a lot of if's, but still "what if?"s that need to be
addressed, and none of them are relevant to Linux. A small
likelihood of catastrophic failure is still non-zero; why chance
it when one need not?

- Dan C.

On 12/14/2022 8:59 AM, Dan Cross wrote:
> In article <tk9jug$12ar$1@gioia.aioe.org>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 11/2/2022 9:30 AM, Simon Clubley wrote:
>> [snip]
>>> could you also answer why people would be
>>> willing to put the future of their company at risk by buying a product
>>> from a small vendor (VSI) that will stop working if that vendor goes bust ?
>>
>> If VSI goes bust - which there is no indication that it will - and
>> if there is noone picking up VMS - which seems unlikely if there
>> are companies willing to pay - and it falls unlucky at the
>> end of a license period and if the server is critical and if
>> they did not negotiate and got a forever license from VSI, then
>> it would be a problem.
>>
>> But that is a lot of if's.
>
> That _is_ a lot of if's, but still "what if?"s that need to be
> addressed, and none of them are relevant to Linux. A small
> likelihood of catastrophic failure is still non-zero; why chance
> it when one need not?

Many can play the ""what if" game ...

Would we ever have left the caves, if some were willing to try something new, or
in the case of VMS, something old?

You seem to think Linux is a better choice. Fine. But that doesn't make you
right, or wrong. Just different.

Bottom line, some of us like VMS. The question is, why do you attempt to talk
us out of it?

I might ask, "why chance Linux if one need not?"

--
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/14/22 09:32, Dave Froble wrote:
> On 12/14/2022 8:59 AM, Dan Cross wrote:
>> In article <tk9jug$12ar$1@gioia.aioe.org>,
>> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>>> On 11/2/2022 9:30 AM, Simon Clubley wrote:
>>> [snip]
>>>>                            could you also answer why people would be
>>>> willing to put the future of their company at risk by buying a product
>>>> from a small vendor (VSI) that will stop working if that vendor goes
>>>> bust ?
>>>
>>> If VSI goes bust - which there is no indication that it will - and
>>> if there is noone picking up VMS - which seems unlikely if there
>>> are companies willing to pay - and it falls unlucky at the
>>> end of a license period and if the server is critical and if
>>> they did not negotiate and got a forever license from VSI, then
>>> it would be a problem.
>>>
>>> But that is a lot of if's.
>>
>> That _is_ a lot of if's, but still "what if?"s that need to be
>> addressed, and none of them are relevant to Linux.  A small
>> likelihood of catastrophic failure is still non-zero; why chance
>> it when one need not?
>
> Many can play the ""what if" game ...
>
> Would we ever have left the caves, if some were willing to try something
> new, or in the case of VMS, something old?
>
> You seem to think Linux is a better choice.  Fine.  But that doesn't
> make you right, or wrong.  Just different.
>
> Bottom line, some of us like VMS.  The question is, why do you attempt
> to talk us out of it?
>
> I might ask, "why chance Linux if one need not?"

Because the risk of any of the above if's is much less with
Linux than VMS.

But, as you said, it doesn't make either right or wrong, only
different. Personally, I would love to see VMS back in the
Desktop-to-Datacenter market. I think it would be a great
option for DOD where security is much more important than
most businesses. (Yes, I have heard the constant mantra about
VMS's security shortcomings but with the right backing and
financing it has the potential to be much more secure than
Linux or Windows both of which are widely used throughout
the DOD!)

We can always dream, I guess.

bill

On 2022-12-14, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Bottom line, some of us like VMS. The question is, why do you attempt to talk
> us out of it?
>

He's not talking you out of it. He's pointing out things that people who
are not emotionally attached to VMS are going to base their decisions on.

> I might ask, "why chance Linux if one need not?"
>

Because it currently has way better security than VMS does ?

Simon.

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

On 12/14/2022 1:51 PM, Simon Clubley wrote:
> On 2022-12-14, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> Bottom line, some of us like VMS. The question is, why do you attempt to talk
>> us out of it?
>>
>
> He's not talking you out of it. He's pointing out things that people who
> are not emotionally attached to VMS are going to base their decisions on.

And you really believe that Linux is perfect, has no down sides, has no issues?

>> I might ask, "why chance Linux if one need not?"
>>
>
> Because it currently has way better security than VMS does ?

One day, when I was preaching security, a customer told me "my boss doesn't care
about security". I doubt that is the same today. Since then their WEENDOZE
systems had a case of "ransomware" which cost them quite a bit. The reality was
that the VMS systems were not touched. Not saying it cannot happen, but in that
particular case, VMS WAS NOT TOUCHED! I'm guessing the boss now is concerned
with security.

:-)

--
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 2022-12-14, Dave Froble <davef@tsoft-inc.com> wrote:
> On 12/14/2022 1:51 PM, Simon Clubley wrote:
>> On 2022-12-14, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> Bottom line, some of us like VMS. The question is, why do you attempt to talk
>>> us out of it?
>>>
>>
>> He's not talking you out of it. He's pointing out things that people who
>> are not emotionally attached to VMS are going to base their decisions on.
>
> And you really believe that Linux is perfect, has no down sides, has no issues?
>

Nothing is perfect, including VMS or Linux.

However, Linux is a _lot_ better suited to today's world than VMS
currently is.

Simon.

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

On Wednesday, December 14, 2022 at 2:10:17 PM UTC-5, Simon Clubley wrote:
> On 2022-12-14, Dave Froble <da...@tsoft-inc.com> wrote:
> > On 12/14/2022 1:51 PM, Simon Clubley wrote:
> >> On 2022-12-14, Dave Froble <da...@tsoft-inc.com> wrote:
> >>>
> >>> Bottom line, some of us like VMS. The question is, why do you attempt to talk
> >>> us out of it?
> >>>
> >>
> >> He's not talking you out of it. He's pointing out things that people who
> >> are not emotionally attached to VMS are going to base their decisions on.
> >
> > And you really believe that Linux is perfect, has no down sides, has no issues?
> >
> Nothing is perfect, including VMS or Linux.
>
> However, Linux is a _lot_ better suited to today's world than VMS
> currently is.
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
Given that I am aware of a number of customer sites that were hit with security issues with NO issues at all with the OpenVMS systems, I would disagree. At these same sites, ALL Windows systems were compromised and some of the Linux based ones were too. Only the OpenVMS systems escaped unscathed.

Dan