On 8/8/2021 10:37 AM, Arne Vajhøj wrote:
> On 8/7/2021 8:24 PM, Bill Gunshannon wrote:
>> On 8/7/21 7:40 PM, Arne Vajhøj wrote:
>>> On 8/7/2021 6:42 PM, Bill Gunshannon wrote:
>>>> On 8/7/21 5:56 PM, Arne Vajhøj wrote:
>>>>> On 8/7/2021 7:59 AM, Bill Gunshannon wrote:
>>>>>> Go read some
>>>>>> of the stuff on LinkedIn about "Legacy Systems". Not specifically
>>>>>> about VMS but the attitude is even if it still does the job if it
>>>>>> is old (ie. COBOL) it is bad and a problem.
>>>>>
>>>>> Being old is not a problem in itself.
>>>>
>>>> Being old is never a problem in itself. I'm old and regularly
>>>> compete with people less than half my age, successfully.
>>>>
>>>>> It becomes a problem if:
>>>>> - it is out of support
>>>>
>>>> Lack of support for one part of an IS should not be a reason to
>>>> abandon it in its entirety.
>>>
>>> If that part cannot be replaced: yes it is.
>>
>> If your running a VAX then it might be a problem. But, believe it
>> or not, most legacy systems are not running on old or non-existant
>> hardware. VMS being the main exception. :-)
>
> Things goes out of support all the time.
>
> CPU architectures (ISA).
>
> OS. Either completely or on specific CPU architecture.
>
> Database servers, web servers, application servers,
> message queue servers, cache servers etc.. Either completely
> or on specific OS or on specific OS and CPU architecture
> combination.
>
> Libraries.
>
> Shrinking OS are obviously harder hit than growing OS, but
> it is far from a VMS specific problem.
>
>>> And even if that part can be replaced then the question is at what
>>> cost compared top the replacement. And it also raises the question
>>> about whether other parts will go out of support soon.
>>
>> As has been stated here numerous times in the past, unless you are
>> running custom hardware and doing things like device control this
>> is not likely to be a problem.
>
> Of course it is a problem.
>
> Remember what happened when Oracle announced that they would
> drop support for VMS in Oracle DB client library? Not only was it a
> problem for those using Oracle DB, but it also worried those
> using Oracle Rdb a bit.
>
>>>>> - it is hard to find people with skills
>>>>
>>>> That is a fixable problem.
>>>>
>>>> https://edscoop.com/college-legacy-programming-langauges-grant-bill/
>>>
>>> That is a good proposal.
>>>
>>> But do you expect serious companies to base their future on that
>>> such a bill get approved,
>>
>> I have little doubt that it will be approved. Financially it is a
>> totally non-apparent bump in the budget.
>>
>>> that funding will continue in the future
>>
>> That will depend on whether or not academia decides to swallow their
>> pride and get behind the idea. I am doing what I can to try and help
>> it, but for totally non-technical reasons it is going to be a hard sell.
>>
>>> and that students will be interested?
>>
>> I had students interested in legacy systems when I still worked at
>> the University even with members of the faculty attacking much of
>> what I was selling.
>
> Bottom line: lots of hope but nothing sure.
>
> Most businesses will prefer a technology where they know
> they can get people over a technology where they hope
> they can get people.
>
>>>>> - it is expensive to maintain
>>>>
>>>> In the case of legacy systems expense is more objective than
>>>> subjective. A little research will show how the majority of
>>>> these modernization projects usually run way over budget and
>>>> seldom accomplish their original goal.
>>>
>>> Huge IT projects are in general risky.
>>>
>>> Migration projects are no exception.
>>>
>>
>> Which is all the more reason to stay the course and clearly
>> understand "modernization" before you start throwing terms
>> around. A COBOL IS running on a PDP-11 or TOPS system does
>> not need a new language. Re-writting it in Java or C# or
>> even Python will get you nothing but a potential for new
>> bugs, inefficiencies and business logic problems.
>
> Not true.
>
> It will get you on a supported platform where you can
> easily get people with the skills.
>
> Yes - a migration come with some risk.
>
> Main risk mitigation factor is the skills of those
> doing the migration.
>
> Arne

Quite often I wonder about people's motivations.

One thought is the benefits, and to whom, of suggesting changing of
applications and systems.

For a company, running computer systems is a cost, not a profit, in most
cases. So, spending more money to make a change may or may not be in
the company's best interest. Usually it is not.

However, looking at the employees, what is the benefit to them? More
work? Enhancing their resume?

Enhancing a resume does nothing for the current employer. It is
harmful, since the employees may be suggesting unneeded work, and costs,
and to quite likely leave the company when a better offer is obtained,
perhaps because of the enhanced resume.

I question the motivations ....

--
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 8/8/2021 1:56 PM, Dave Froble wrote:
> Quite often I wonder about people's motivations.
>
> One thought is the benefits, and to whom, of suggesting changing of
> applications and systems.
>
> For a company, running computer systems is a cost, not a profit, in most
> cases.  So, spending more money to make a change may or may not be in
> the company's best interest.  Usually it is not.
>
> However, looking at the employees, what is the benefit to them?  More
> work?  Enhancing their resume?
>
> Enhancing a resume does nothing for the current employer.  It is
> harmful, since the employees may be suggesting unneeded work, and costs,
> and to quite likely leave the company when a better offer is obtained,
> perhaps because of the enhanced resume.
>
> I question the motivations ....

Everybody is trying to maximize their own benefits.

Some employees may be looking to get something more widely used
on their resume for future career purposes and push for change.

Some employees may be push back on change because it may
change their status from expert in the old technology to beginner
in the new technology.

Vendors of the old technology (if such still exist) will
want to keep the customer.

Vendors of the new technology will want to get a new
customer.

Various consultants will want to make money making
recommendations.

Somebody in the company leadership will need to
analyze all the different input and decide what is
best for the company.

Arne

On 8/7/2021 8:24 PM, Bill Gunshannon wrote:
> On 8/7/21 7:40 PM, Arne Vajhøj wrote:
>> On 8/7/2021 6:42 PM, Bill Gunshannon wrote:
>>> On 8/7/21 5:56 PM, Arne Vajhøj wrote:
>>>> - it does not integrate with newer system that it need to
>>>>    integrate with
>>>
>>> With the exception of Dave's system (I actually know very little
>>> about VMS BASIC) I can think of no legacy system that can not be
>>> integrated into a modern system.  I have had no problems doing web
>>> programming with COBOL.
>>
>> Anything can be somewhat integrated using various hacks.
>
> I needed no hacks to get COBOL running on the web.  It's a mindset
> problem, not a technical one.

Literally nay programming language can be used to write
a CGI script.

But there is a very long way from the 1995 CGI scripts
to modern web solutions.

Did you Cobol web app support:
- session sharing across cluster
- OAuth integration
- LDAP integraion
- verification of client certificate
- Redis or memcached for cache
- exposing status / load info to load balancer
- reporting stats and health check to IBM Tivoli / CA Unicenter / Zabbix
- reporting to Prometheus
- HTTP/2 push
- web sockets
- switching to in-cloud managed service for database
- having accept request header determine response format
?

Arne

Den 2021-08-08 kl. 22:42, skrev Arne Vajhøj:
> On 8/7/2021 8:24 PM, Bill Gunshannon wrote:
>> On 8/7/21 7:40 PM, Arne Vajhøj wrote:
>>> On 8/7/2021 6:42 PM, Bill Gunshannon wrote:
>>>> On 8/7/21 5:56 PM, Arne Vajhøj wrote:
>>>>> - it does not integrate with newer system that it need to
>>>>>    integrate with
>>>>
>>>> With the exception of Dave's system (I actually know very little
>>>> about VMS BASIC) I can think of no legacy system that can not be
>>>> integrated into a modern system.  I have had no problems doing web
>>>> programming with COBOL.
>>>
>>> Anything can be somewhat integrated using various hacks.
>>
>> I needed no hacks to get COBOL running on the web.  It's a mindset
>> problem, not a technical one.
>
> Literally nay programming language can be used to write
> a CGI script.
>
> But there is a very long way from the 1995 CGI scripts
> to modern web solutions.
>
> Did you Cobol web app support:
> - session sharing across cluster
> - OAuth integration
> - LDAP integraion
> - verification of client certificate
> - Redis or memcached for cache
> - exposing status / load info to load balancer
> - reporting stats and health check to IBM Tivoli / CA Unicenter / Zabbix
> - reporting to Prometheus
> - HTTP/2 push
> - web sockets
> - switching to in-cloud managed service for database
> - having accept request header determine response format
> ?
>
> Arne
>
>

Are we/you talkning about an application that runs "on the web"
without any other help from a normal web server?

In the OpenVMS case, most of your points above would be handled
by WASD (just as I know that one best) and the Cobol code just
do the business logic. Maybe a small C-jacket to handle the
CGI API against WASD also. But there is nothing stopping some
Cobol code to be the main business logic in an web solution.

Today, and particular on an real environment such as OpenVMS
(not some embedded thing), I do not see why one would put all
the functionallity, that already has been developed and debugged
by a tool such as WASD, into your own application.

On 8/7/21 10:25 PM, Dave Froble wrote:
> On 8/7/2021 7:40 PM, Arne Vajhøj wrote:
>> On 8/7/2021 6:42 PM, Bill Gunshannon wrote:
>>> On 8/7/21 5:56 PM, Arne Vajhøj wrote:
>>>> On 8/7/2021 7:59 AM, Bill Gunshannon wrote:
>>>>>                                                       Go read some
>>>>> of the stuff on LinkedIn about "Legacy Systems".  Not specifically
>>>>> about VMS but the attitude is even if it still does the job if it
>>>>> is old (ie. COBOL) it is bad and a problem.
>>>>
>>>> Being old is not a problem in itself.
>>>
>>> Being old is never a problem in itself.  I'm old and regularly
>>> compete with people less than half my age, successfully.
>
> Wrestling?
>
> :-)

CrossFit

>
>>>> It becomes a problem if:
>>>> - it is out of support
>>>
>>> Lack of support for one part of an IS should not be a reason to
>>> abandon it in its entirety.
>>
>> If that part cannot be replaced: yes it is.
>
> Anything can be replaced.  The required effort may or may not be excessive.
>
>> And even if that part can be replaced then the question is at what
>> cost compared top the replacement. And it also raises the question
>> about whether other parts will go out of support soon.
>
> Vs the cost of doing a replacement?
>
>>>> - it is hard to find people with skills
>>>
>>> That is a fixable problem.
>>>
>>> https://edscoop.com/college-legacy-programming-langauges-grant-bill/
>>
>> That is a good proposal.
>>
>> But do you expect serious companies to base their future on that
>> such a bill get approved, that funding will continue in the future
>> and that students will be interested?
>
> Students are interested in getting jobs.

Well, not all of them. Take Philosophy Majors for instance. :-)

But when I was still working students were in fact interested.
It was the faculty who were not. Their interest is in driving
the bus, not getting the passengers to where they need to be.

>
> Now, the damn educators who think they know everything, maybe they
> should not have jobs.

I have always thought the worst professors were those who had
never been anything but students and professors. Professors
who had held real jobs in their field always seemed better to
me.

>
>>>> - it does not integrate with newer system that it need to
>>>>    integrate with
>>>
>>> With the exception of Dave's system (I actually know very little
>>> about VMS BASIC) I can think of no legacy system that can not be
>>> integrated into a modern system.  I have had no problems doing web
>>> programming with COBOL.
>
> Basic is no different than any other language.

Not exactly true. While modern BASIC has c ome a long way it
will never escape its roots which were not in the IT Production
world. Like Pascal it was intended to teach concepts and,
believe it or not, one of those concepts was not programming
per se.

>
>> Anything can be somewhat integrated using various hacks.
>>
>> But good integration will often be either impossible or
>> expensive.
>
> BULLSHIT !!!!

I agree with this.

>
>>>> - it is expensive to maintain
>>>
>>> In the case of legacy systems expense is more objective than
>>> subjective.  A little research will show how the majority of
>>> these modernization projects usually run way over budget and
>>> seldom accomplish their original goal.
>>
>> Huge IT projects are in general risky.
>>
>> Migration projects are no exception.
>
> And if it ain't broke, why fix it?

Or, to be closer to the concept of IT modernization, if only one
part is broken, fix that part but don't re-write the whole thing
in a different language becuase a period was missing.

bill

On 8/8/21 10:45 AM, Arne Vajhøj wrote:
> On 8/7/2021 10:25 PM, Dave Froble wrote:
>> On 8/7/2021 7:40 PM, Arne Vajhøj wrote:
>>> On 8/7/2021 6:42 PM, Bill Gunshannon wrote:
>>>> On 8/7/21 5:56 PM, Arne Vajhøj wrote:
>>>>> It becomes a problem if:
>>>>> - it is out of support
>>>>
>>>> Lack of support for one part of an IS should not be a reason to
>>>> abandon it in its entirety.
>>>
>>> If that part cannot be replaced: yes it is.
>>
>> Anything can be replaced.  The required effort may or may not be
>> excessive.
>
> The effort of creating a CPU replacement or an OS replacement
> or a database replacement will be excessive for sure.

They already exist. Again, using VAX as an example, the CPU, in
fact, the entire system is replaceable with SIMH or something
similar. OS? How many real world IT systems are so integrated
with the OS that another can't provide the services necessary to
accomplish the same task. (I am not talking about features some
users like, I am talking about accomplishing the requirements of
an IS. And, databases are a dime a dozen today. Most newer
databases can deliver everything the older ones can and much more.
And, usually, at a higher rate of efficiency.

>
>>> And even if that part can be replaced then the question is at what
>>> cost compared top the replacement. And it also raises the question
>>> about whether other parts will go out of support soon.
>>
>> Vs the cost of doing a replacement?
>
> The logic goes like:
> - if it cost 1 M$ to replace A
> - if it cost 2 M$ to migrate
> - then just looking at A make migration a bad  plan
> - but if B, C, D and E are all going to go out of support within
>   the next 3 years and they will also cost 1 M$ a piece to replace
>   the the migration business case looks much better
>

There is a lot more to costing such a migration than this simple
example. But migration can still be the better of the choices
especially if it is limited to what really needs to be done to
migrate and not blanket replacement of everything with something
else.

>>>>> - it is hard to find people with skills
>>>>
>>>> That is a fixable problem.
>>>>
>>>> https://edscoop.com/college-legacy-programming-langauges-grant-bill/
>>>
>>> That is a good proposal.
>>>
>>> But do you expect serious companies to base their future on that
>>> such a bill get approved, that funding will continue in the future
>>> and that students will be interested?
>>
>> Students are interested in getting jobs.
>>
>> Now, the damn educators who think they know everything, maybe they
>> should not have jobs.
>
> Business has to act according to how the world is not how
> the world should be.

Or, they can contribute to fixing things if it is in their best
interest. GDIT has the contract for the DOD EMR System. It is
at least hundreds of thousands of lines (maybe over a million,
I haven't actually seen it) of COBOL running in an IBM environment.
They have offered internships to college students for years. I
expect that a number of the people now maintaining the system
started as interns. The Bill mentioned above is just another
way to spur this movement on in spite of academia's attempts to
prevent it.

>
>>>>> - it is expensive to maintain
>>>>
>>>> In the case of legacy systems expense is more objective than
>>>> subjective.  A little research will show how the majority of
>>>> these modernization projects usually run way over budget and
>>>> seldom accomplish their original goal.
>>>
>>> Huge IT projects are in general risky.
>>>
>>> Migration projects are no exception.
>>
>> And if it ain't broke, why fix it?
>
> If you have commitments from vendors that the HW and SW
> will be supported for 10+ years and you get hundreds
> of qualified applicants when you put up a job ad and
> the users are happy with the cost and time to integrate with
> other solutions, then there is no reason to fix anything.
>
> But ...
>

Lack of currently qualified programmers should never be justification
for re-writing a program in a different language. The real problem
is just too easy to solve.

bill

On 8/8/21 10:37 AM, Arne Vajhøj wrote:
> On 8/7/2021 8:24 PM, Bill Gunshannon wrote:
>> On 8/7/21 7:40 PM, Arne Vajhøj wrote:
>>> On 8/7/2021 6:42 PM, Bill Gunshannon wrote:
>>>> On 8/7/21 5:56 PM, Arne Vajhøj wrote:
>>>>> On 8/7/2021 7:59 AM, Bill Gunshannon wrote:
>>>>>>                                                       Go read some
>>>>>> of the stuff on LinkedIn about "Legacy Systems".  Not specifically
>>>>>> about VMS but the attitude is even if it still does the job if it
>>>>>> is old (ie. COBOL) it is bad and a problem.
>>>>>
>>>>> Being old is not a problem in itself.
>>>>
>>>> Being old is never a problem in itself.  I'm old and regularly
>>>> compete with people less than half my age, successfully.
>>>>
>>>>> It becomes a problem if:
>>>>> - it is out of support
>>>>
>>>> Lack of support for one part of an IS should not be a reason to
>>>> abandon it in its entirety.
>>>
>>> If that part cannot be replaced: yes it is.
>>
>> If your running a VAX then it might be a problem.  But, believe it
>> or not, most legacy systems are not running on old or non-existant
>> hardware.  VMS being the main exception.  :-)
>
> Things goes out of support all the time.
>
> CPU architectures (ISA).
>
> OS. Either completely or on specific CPU architecture.
>
> Database servers, web servers, application servers,
> message queue servers, cache servers etc.. Either completely
> or on specific OS or on specific OS and CPU architecture
> combination.
>
> Libraries.
>
> Shrinking OS are obviously harder hit than growing OS, but
> it is far from a VMS specific problem.

But, replacements are available for all of the things you
mentioned above. Unless it's more about religion than getting
the job done.

>
>>> And even if that part can be replaced then the question is at what
>>> cost compared top the replacement. And it also raises the question
>>> about whether other parts will go out of support soon.
>>
>> As has been stated here numerous times in the past, unless you are
>> running custom hardware and doing things like device control this
>> is not likely to be a problem.
>
> Of course it is a problem.
>
> Remember what happened when Oracle announced that they would
> drop support for VMS in Oracle DB client library? Not only was it a
> problem for those using Oracle DB, but it also worried those
> using Oracle Rdb a bit.

See comment above.

>
>>>>> - it is hard to find people with skills
>>>>
>>>> That is a fixable problem.
>>>>
>>>> https://edscoop.com/college-legacy-programming-langauges-grant-bill/
>>>
>>> That is a good proposal.
>>>
>>> But do you expect serious companies to base their future on that
>>> such a bill get approved,
>>
>> I  have little doubt that it will be approved.  Financially it is a
>> totally non-apparent bump in the budget.
>>
>>>                            that funding will continue in the future
>>
>> That will depend on whether or not academia decides to swallow their
>> pride and get behind the idea.  I am doing what I can to try and help
>> it, but for totally non-technical reasons it is going to be a hard sell.
>>
>>> and that students will be interested?
>>
>> I had students interested in legacy systems when I still worked at
>> the University even with members of the faculty attacking much of
>> what I was selling.
>
> Bottom line: lots of hope but nothing sure.

The one thing that is sure is what Cartwright said, if we do nothing
the problem will get worse. Using only one facet, COBOL, I have seen
the number of jobs looking for COBOL programmers go up by orders of
magnitude over the last year or so. It was a problem before but I
think some of the side effects of the pandemic have exacerbated it
resulting in a recent major change.

>
> Most businesses will prefer a technology where they know
> they can get people over a technology where they hope
> they can get people.

Funny, none of this has eaten into IBM's business at all, at least as
far as I have seen. And when you see the word "legacy" in the mentioned
article, they mostly mean IBM. Sadly, VMS isn't even oin the radar.

>
>>>>> - it is expensive to maintain
>>>>
>>>> In the case of legacy systems expense is more objective than
>>>> subjective.  A little research will show how the majority of
>>>> these modernization projects usually run way over budget and
>>>> seldom accomplish their original goal.
>>>
>>> Huge IT projects are in general risky.
>>>
>>> Migration projects are no exception.
>>>
>>
>> Which is all the more reason to stay the course and clearly
>> understand "modernization" before you start throwing terms
>> around.  A COBOL IS running on a PDP-11 or TOPS system does
>> not need a new language.  Re-writting it in Java or C# or
>> even Python will get you nothing but a potential for new
>> bugs, inefficiencies and business logic problems.
>
> Not true.
>
> It will get you on a supported platform where you can
> easily  get people with the skills.

It will also get you a program that was originally written with
a language designed to do the job replaced by a general purpose
language not designed to do any particular task.

>
> Yes - a migration come with some risk.
>
> Main risk mitigation factor is the skills of those
> doing the migration.

Skills can be acquired. Most of the languages used for these legacy
ISes are much less complicated than modern languages. Complication
was added by academia to show how brilliant they were. It brings
nothing to the table as far as getting the job done.

bill

On 8/8/21 4:42 PM, Arne Vajhøj wrote:
> On 8/7/2021 8:24 PM, Bill Gunshannon wrote:
>> On 8/7/21 7:40 PM, Arne Vajhøj wrote:
>>> On 8/7/2021 6:42 PM, Bill Gunshannon wrote:
>>>> On 8/7/21 5:56 PM, Arne Vajhøj wrote:
>>>>> - it does not integrate with newer system that it need to
>>>>>    integrate with
>>>>
>>>> With the exception of Dave's system (I actually know very little
>>>> about VMS BASIC) I can think of no legacy system that can not be
>>>> integrated into a modern system.  I have had no problems doing web
>>>> programming with COBOL.
>>>
>>> Anything can be somewhat integrated using various hacks.
>>
>> I needed no hacks to get COBOL running on the web.  It's a mindset
>> problem, not a technical one.
>
> Literally nay programming language can be used to write
> a CGI script.
>
> But there is a very long way from the 1995 CGI scripts
> to modern web solutions.
>
> Did you Cobol web app support:
> - session sharing across cluster
> - OAuth integration
> - LDAP integraion
> - verification of client certificate
> - Redis or memcached for cache
> - exposing status / load info to load balancer
> - reporting stats and health check to IBM Tivoli / CA Unicenter / Zabbix
> - reporting to Prometheus
> - HTTP/2 push
> - web sockets
> - switching to in-cloud managed service for database
> - having accept request header determine response format
> ?
>

No, but then, neither did the PHP program I was replacing. :-)

bill

On 2021-08-08, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <sen4f7$sfu$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>On 2021-08-07, Bob Eager <news0009@eager.cx> wrote:
>>>
>>> I always thought that the primary purpose of LMF was a 'light touch' way
>>> of making sure that compaies kept up with their licensing, even if the
>>> company was a bit disorganised.
>>>
>>
>>There is a major change between then and now.
>>
>>Back in those days hardware cost a _lot_ of money. If you had enough
>>money to buy the hardware, you also had enough money to buy the
>>software.
>>
>>These days hardware is cheap compared to the cost of the software.
>>There is a much stronger motivation for some people to try and
>>break the licencing so they can run the expensive software on
>>cheap hardware.
>>
>>The old LMF is no longer suitable for purpose in this new world
>>with its different dynamics and I would be absolutely amazed
>>if VSI were not looking at making the licencing software much
>>stronger as a result.
>
> HOW is it no longer suitable? More WEENDOZE-like licensing? There
> have been publications of a Micro$oft checksum sieve too. Is theirs
> unsuitable as well?
>

A third party has created a tool that can generate valid functioning
licences as required without having needed to steal any private
signing keys (for example) from VSI or HPE.

That should tell you all you need to know about whether using the
LMF as it stands is still a viable option in today's world of low-cost
hardware and high-cost VMS software.

I'll now make another prediction related to VMS hobbyist licences:

Sometime around the end of the year or shortly afterwards, the
discussion about VAX hobbyist licences will start again as the
last valid hobbyist licences for the VAX architecture expire and
hobbyist VAX systems stop working.

Someone will ask if they can get hold of new VAX licences and
someone else will suggest that this pakgen tool can be used to
generate a set of new hobbyist licences. :-(

Someone may even post instructions to use this tool or even post
a set of VAX licences to comp.os.vms or elsewhere. If that happens
all hell will break loose and may even result in the cancellation
of the VSI hobbyist program.

Just remember this before you do that: VSI are under no obligation
to offer a hobbyist program. By helping to create VAX licences in
this way, you may end up destroying the future x86-64 hobbyist program.

Simon.

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

On 8/8/2021 8:47 PM, Simon Clubley wrote:
> On 2021-08-08, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <sen4f7$sfu$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>> On 2021-08-07, Bob Eager <news0009@eager.cx> wrote:
>>>>
>>>> I always thought that the primary purpose of LMF was a 'light touch' way
>>>> of making sure that compaies kept up with their licensing, even if the
>>>> company was a bit disorganised.
>>>>
>>>
>>> There is a major change between then and now.
>>>
>>> Back in those days hardware cost a _lot_ of money. If you had enough
>>> money to buy the hardware, you also had enough money to buy the
>>> software.
>>>
>>> These days hardware is cheap compared to the cost of the software.
>>> There is a much stronger motivation for some people to try and
>>> break the licencing so they can run the expensive software on
>>> cheap hardware.
>>>
>>> The old LMF is no longer suitable for purpose in this new world
>>> with its different dynamics and I would be absolutely amazed
>>> if VSI were not looking at making the licencing software much
>>> stronger as a result.
>>
>> HOW is it no longer suitable? More WEENDOZE-like licensing? There
>> have been publications of a Micro$oft checksum sieve too. Is theirs
>> unsuitable as well?
>>
>
> A third party has created a tool that can generate valid functioning
> licences as required without having needed to steal any private
> signing keys (for example) from VSI or HPE.
>
> That should tell you all you need to know about whether using the
> LMF as it stands is still a viable option in today's world of low-cost
> hardware and high-cost VMS software.
>
> I'll now make another prediction related to VMS hobbyist licences:
>
> Sometime around the end of the year or shortly afterwards, the
> discussion about VAX hobbyist licences will start again as the
> last valid hobbyist licences for the VAX architecture expire and
> hobbyist VAX systems stop working.
>
> Someone will ask if they can get hold of new VAX licences and
> someone else will suggest that this pakgen tool can be used to
> generate a set of new hobbyist licences. :-(
>
> Someone may even post instructions to use this tool or even post
> a set of VAX licences to comp.os.vms or elsewhere. If that happens
> all hell will break loose and may even result in the cancellation
> of the VSI hobbyist program.

Why should VSI care about VAX?

If VSI is going to continue with the CL, then there is no reason to look
elsewhere for PAKs, and, hobbyists would feel more at ease reporting
something to VSI, than if they used a non-VSI PAK.

Now, if you're going to say that VSI might get upset with the concept of
people continuing to have hobbyist VMS systems, should VSI cease to
exist, well, again, why should VSI care?

> Just remember this before you do that: VSI are under no obligation
> to offer a hobbyist program. By helping to create VAX licences in
> this way, you may end up destroying the future x86-64 hobbyist program.

Or, it maybe a non-event ...

--
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 8/8/2021 7:07 PM, Bill Gunshannon wrote:

> Not exactly true. While modern BASIC has c ome a long way it
> will never escape its roots which were not in the IT Production
> world. Like Pascal it was intended to teach concepts and,
> believe it or not, one of those concepts was not programming
> per se.

Interesting statement. Coming from someone who admits to not being
familiar with the language.

Perhaps older implementations of Basic were as described.

Some time back, as I recall things, some of the compiler people at DEC
asked the question, "why cannot every language be able to do what others
do?". The result was the implementation of many new features in Basic.

Sadly, not unsigned integers.

Also sadly, some of the performance inhibitors in Basic, such as the
issue when returning from a subprogram.

So, I'd ask for you to explain your statement.

--
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 8/8/21 9:23 PM, Dave Froble wrote:
> On 8/8/2021 7:07 PM, Bill Gunshannon wrote:
>
>> Not exactly true.  While modern BASIC has c ome a long way it
>> will never escape its roots which were not in the IT Production
>> world.  Like Pascal it was intended to teach concepts and,
>> believe it or not, one of those concepts was not programming
>> per se.
>
> Interesting statement.  Coming from someone who admits to not being
> familiar with the language.

Misunderstanding, again. What I am is not an expert in VMS BASIC.
I have used BASIC since the Kemeny/Kurtz days. I have done real
production work using BASIC on everything from Micros to Mainframes.
I have done business, financial and engineering programming in BASIC.

>
> Perhaps older implementations of Basic were as described.

I stated that modern BASIC had improved but that doesn't change the
original purpose. The idea of "fixing" these languages (like they
also tried with Pascal even after the original author of Pascal
gave them an alternative) is little more than a band-aid when you
consider there were/are languages designed to do the work people
try to do with these languages.

>
> Some time back, as I recall things, some of the compiler people at DEC
> asked the question, "why cannot every language be able to do what others
> do?".  The result was the implementation of many new features in Basic.

Exactly. "Lets put a band-aid on the language rather than do the proper
software engineering task of choosing the right tool for the job."

>
> Sadly, not unsigned integers.

Sometimes having a feature can result in some interesting errors. I
have seen them, caused by unsigned integers, personally.

>
> Also sadly, some of the performance inhibitors in Basic, such as the
> issue when returning from a subprogram.
>
> So, I'd ask for you to explain your statement.
>

Simple: Choose the right tool for the job.
BASIC, like Pascal was intended to teach certain concepts. It was
not intended as a production language. Production languages existed,
even when BASIC and Pascal were created. In those days, new languages
weren't just ego trips. They were designed for particular tasks.
They should be used for the tasks they were designed for. That is
a major part of real software engineering.

bill

On 2021-08-08, Dave Froble <davef@tsoft-inc.com> wrote:
>
> Why should VSI care about VAX?
>

Because of expected trust and honourable behaviour on the part of
the hobbyists if VSI decide to give them free access to what is
otherwise an expensive product.

Is this concept of honourable behaviour really so hard to understand ?

Simon.

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

On 8/9/2021 8:08 AM, Simon Clubley wrote:
> On 2021-08-08, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> Why should VSI care about VAX?
>>
>
> Because of expected trust and honourable behaviour on the part of
> the hobbyists if VSI decide to give them free access to what is
> otherwise an expensive product.
>
> Is this concept of honourable behaviour really so hard to understand ?
>
> Simon.
>

As I may have mentioned, there is no need for "cheating" as long as VSI
exists. As long as the VSI CL program exists, there is valid usage of
VSI releases of VMS. So it won't happen.

VSI has no interest in VAX. So why should they care if some hobbyists
do whatever necessary to continue to run VAX/VMS?

Hobbyists enjoying the VSI CL are not hobbyists attempting to continue
to run VAX/VMS. VSI's releases of VMS are NOT the same as VAX/VMS.
What is your justification of trying to consider them both the same thing?

But let's address the plight of VAX/VMS and how it might relate to the
loss of use of VSI's VMS releases. Does anyone (other than Simon)
expect entities who depend upon VSI's releases of VMS to keep their
businesses viable, and the employees who depend upon those businesses
for their jobs, just cease to exist if something happened to VSI?

Read that last paragraph carefully and then explain what should happen
should VSI cease operations.

Is it "honorable behaviour" to expect businesses to just give up? If
sos, then I do not understand.

--
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 8/9/2021 7:59 AM, Bill Gunshannon wrote:
> On 8/8/21 9:23 PM, Dave Froble wrote:
>> On 8/8/2021 7:07 PM, Bill Gunshannon wrote:
>>
>>> Not exactly true. While modern BASIC has c ome a long way it
>>> will never escape its roots which were not in the IT Production
>>> world. Like Pascal it was intended to teach concepts and,
>>> believe it or not, one of those concepts was not programming
>>> per se.
>>
>> Interesting statement. Coming from someone who admits to not being
>> familiar with the language.
>
> Misunderstanding, again. What I am is not an expert in VMS BASIC.
> I have used BASIC since the Kemeny/Kurtz days. I have done real
> production work using BASIC on everything from Micros to Mainframes.
> I have done business, financial and engineering programming in BASIC.
>
>>
>> Perhaps older implementations of Basic were as described.
>
> I stated that modern BASIC had improved but that doesn't change the
> original purpose. The idea of "fixing" these languages (like they
> also tried with Pascal even after the original author of Pascal
> gave them an alternative) is little more than a band-aid when you
> consider there were/are languages designed to do the work people
> try to do with these languages.
>
>>
>> Some time back, as I recall things, some of the compiler people at DEC
>> asked the question, "why cannot every language be able to do what
>> others do?". The result was the implementation of many new features
>> in Basic.
>
> Exactly. "Lets put a band-aid on the language rather than do the proper
> software engineering task of choosing the right tool for the job."
>
>>
>> Sadly, not unsigned integers.
>
> Sometimes having a feature can result in some interesting errors. I
> have seen them, caused by unsigned integers, personally.
>
>>
>> Also sadly, some of the performance inhibitors in Basic, such as the
>> issue when returning from a subprogram.
>>
>> So, I'd ask for you to explain your statement.
>>
>
> Simple: Choose the right tool for the job.
> BASIC, like Pascal was intended to teach certain concepts. It was
> not intended as a production language. Production languages existed,
> even when BASIC and Pascal were created. In those days, new languages
> weren't just ego trips. They were designed for particular tasks.
> They should be used for the tasks they were designed for. That is
> a major part of real software engineering.
>
> bill
>
>
>

You seem to be implying that VMS Basic is not a "right tool for the
job". Does your opinion (that's what it is) out weight the opinions of
others? There have been and still are many serious applications
implemented using VMS Basic. Are all those people who use VMS Basic
"wrong"?

Who gets to decide?

--
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 Monday, August 9, 2021 at 7:59:18 AM UTC-4, Bill Gunshannon wrote:
> On 8/8/21 9:23 PM, Dave Froble wrote:
> > On 8/8/2021 7:07 PM, Bill Gunshannon wrote:
> >
> >> Not exactly true. While modern BASIC has c ome a long way it
> >> will never escape its roots which were not in the IT Production
> >> world. Like Pascal it was intended to teach concepts and,
> >> believe it or not, one of those concepts was not programming
> >> per se.
> >
> > Interesting statement. Coming from someone who admits to not being
> > familiar with the language.
> Misunderstanding, again. What I am is not an expert in VMS BASIC.
> I have used BASIC since the Kemeny/Kurtz days. I have done real
> production work using BASIC on everything from Micros to Mainframes.
> I have done business, financial and engineering programming in BASIC.
> >
> > Perhaps older implementations of Basic were as described.
> I stated that modern BASIC had improved but that doesn't change the
> original purpose. The idea of "fixing" these languages (like they
> also tried with Pascal even after the original author of Pascal
> gave them an alternative) is little more than a band-aid when you
> consider there were/are languages designed to do the work people
> try to do with these languages.

The backstory of Wirth's interaction with the Pascal Standards Committee is a long one.
He wasn't very interested in standardizing/extended the base Pascal language definition.
That was ANSI/IEEE770X3.97-1983 and ISO/IEC 7185. The committees (a joint IEEE P770,
ANSI X3J9, and ISO/TC97/SC5/WG2) created a new standard, Extended Pascal (ISO/IEC 10206
in 1990), to both standardize existing practice among the various vendors plus add features
to the language to make it a better tool for writing medium to large-scale projects. DEC was
very involved with this standard and I wrote several pieces of it. VAX Pascal ended up with
many of the standard features but some had slightly different syntax. The foreword to
ISO/IEC 10206:1990 has lots of useful information.

John, secretary, X3J9/IEEE P770

On 08/09/21 13:29, Dave Froble wrote:
> On 8/9/2021 8:08 AM, Simon Clubley wrote:
>> On 2021-08-08, Dave Froble <davef@tsoft-inc.com> wrote:
>>>
>>> Why should VSI care about VAX?
>>>
>>
>> Because of expected trust and honourable behaviour on the part of
>> the hobbyists if VSI decide to give them free access to what is
>> otherwise an expensive product.
>>
>> Is this concept of honourable behaviour really so hard to understand ?
>>
>> Simon.
>>
>
> As I may have mentioned, there is no need for "cheating" as long as VSI
> exists. As long as the VSI CL program exists, there is valid usage of
> VSI releases of VMS. So it won't happen.
>
> VSI has no interest in VAX. So why should they care if some hobbyists do
> whatever necessary to continue to run VAX/VMS?
>
> Hobbyists enjoying the VSI CL are not hobbyists attempting to continue
> to run VAX/VMS. VSI's releases of VMS are NOT the same as VAX/VMS. What
> is your justification of trying to consider them both the same thing?
>
> But let's address the plight of VAX/VMS and how it might relate to the
> loss of use of VSI's VMS releases. Does anyone (other than Simon) expect
> entities who depend upon VSI's releases of VMS to keep their businesses
> viable, and the employees who depend upon those businesses for their
> jobs, just cease to exist if something happened to VSI?
>
> Read that last paragraph carefully and then explain what should happen
> should VSI cease operations.
>
> Is it "honorable behaviour" to expect businesses to just give up? If
> sos, then I do not understand.
>

I've said this before, but the way to get round that, what has become
the standard business model for os's these days, is for the media to
be free to use, but the money is made via support and patch availability
contracts. Suse, Redhat and others have made millions via that business
model, so we know it it does work. The majority of hobbyist users will
never buy support, just noise in the big picture, but pro users will,
which is where the ongoing revenue stream is to be found. Hard code LMF
type systems just scream out: We don't trust you to do the right thing,
not the best encouragement for sales, when the whole world and dog
have found a better way.

LMF and that sort of license business model, like department stores,
are an idea that will never work in the modern age and won't encourage
the curious to download vms to see how good it is. A lot of people,
including myself, download and install various os's every year, just to
evaluate them. Even Oracle make their os's free to use none commercially
, with again, the money made via support contracts.

On 8/9/2021 11:26 AM, chris wrote:
> I've said this before, but the way to get round that, what has become
> the standard business model for os's these days, is for the media to
> be free to use, but the money is made via support and patch availability
> contracts. Suse, Redhat and others have made millions via that business
> model, so we know it it does work.

It works great for Redhat and SUSE yes.

So if a bunch of big companies are willing to fund VMS development
like they do for Linux then VSI could have a great business
using the same model.

But if VSI has to fund VMS development themselves then they
will likely be looking more at Microsoft than at Redhat.

> LMF and that sort of license business model, like department stores,
> are an idea that will never work in the modern age and won't encourage
> the curious to download vms to see how good it is. A lot of people,
> including myself, download and install various os's every year, just to
> evaluate them. Even Oracle make their os's free to use none commercially
> , with again, the money made via support contracts.

Oracle Linux is a clone of Redhat Linux. Again if VSI got VMS
maintained for free and they just need to wrap up a build with their
logo, then it would work great for them as well.

Arne

In article <septub$cp5$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-08-08, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <sen4f7$sfu$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>On 2021-08-07, Bob Eager <news0009@eager.cx> wrote:
>>>>
>>>> I always thought that the primary purpose of LMF was a 'light touch' way
>>>> of making sure that compaies kept up with their licensing, even if the
>>>> company was a bit disorganised.
>>>>
>>>
>>>There is a major change between then and now.
>>>
>>>Back in those days hardware cost a _lot_ of money. If you had enough
>>>money to buy the hardware, you also had enough money to buy the
>>>software.
>>>
>>>These days hardware is cheap compared to the cost of the software.
>>>There is a much stronger motivation for some people to try and
>>>break the licencing so they can run the expensive software on
>>>cheap hardware.
>>>
>>>The old LMF is no longer suitable for purpose in this new world
>>>with its different dynamics and I would be absolutely amazed
>>>if VSI were not looking at making the licencing software much
>>>stronger as a result.
>>
>> HOW is it no longer suitable? More WEENDOZE-like licensing? There
>> have been publications of a Micro$oft checksum sieve too. Is theirs
>> unsuitable as well?
>>
>
>A third party has created a tool that can generate valid functioning
>licences as required without having needed to steal any private
>signing keys (for example) from VSI or HPE.

That *tool* is in the LICENSE code on VMS. A PAKGEN license enables it.

>That should tell you all you need to know about whether using the
>LMF as it stands is still a viable option in today's world of low-cost
>hardware and high-cost VMS software.

Many third parties use PAKGEN for their licensing too. I'd caution
against the "signing" mechanisms because third parties using OpenVMS
installation mechanisms got fucked when it was added to those tools.
Thankfully, that was corrected.

>I'll now make another prediction related to VMS hobbyist licences:
>
>Sometime around the end of the year or shortly afterwards, the
>discussion about VAX hobbyist licences will start again as the
>last valid hobbyist licences for the VAX architecture expire and
>hobbyist VAX systems stop working.
:
:
MOVL #1,R0
RET

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 08/09/21 16:41, Arne Vajhøj wrote:
> On 8/9/2021 11:26 AM, chris wrote:
>> I've said this before, but the way to get round that, what has become
>> the standard business model for os's these days, is for the media to
>> be free to use, but the money is made via support and patch availability
>> contracts. Suse, Redhat and others have made millions via that business
>> model, so we know it it does work.
>
> It works great for Redhat and SUSE yes.

One assumes that the current development has been funded somehow and
vsi will have little if any income stream at present, so I don't see
why such a more relaxed and trusting business model should not work,
once it's ready for show time.

Don't really see what your argument is there and you don't address
the comments I was making at all. All i'm saying is, the fewer
restrictions vsi place on availability and use, the more likely it
is gain traction and new business. LMF type systems show a basic
insecurity and lack of confidence and trust about the product.

>
> So if a bunch of big companies are willing to fund VMS development
> like they do for Linux then VSI could have a great business
> using the same model.
>
> But if VSI has to fund VMS development themselves then they
> will likely be looking more at Microsoft than at Redhat.
>
>> LMF and that sort of license business model, like department stores,
>> are an idea that will never work in the modern age and won't encourage
>> the curious to download vms to see how good it is. A lot of people,
>> including myself, download and install various os's every year, just to
>> evaluate them. Even Oracle make their os's free to use none commercially
>> , with again, the money made via support contracts.
>
> Oracle Linux is a clone of Redhat Linux. Again if VSI got VMS
> maintained for free and they just need to wrap up a build with their
> logo, then it would work great for them as well.

Even the latest Solaris 11 is free to download and use non commercially,
so if Oracle thinks that's a good business headed, they probably know
what they are doing. ultra hard headed as they are...

>
> Arne

On 8/9/21 8:34 AM, Dave Froble wrote:
> On 8/9/2021 7:59 AM, Bill Gunshannon wrote:
>> On 8/8/21 9:23 PM, Dave Froble wrote:
>>> On 8/8/2021 7:07 PM, Bill Gunshannon wrote:
>>>
>>>> Not exactly true.  While modern BASIC has c ome a long way it
>>>> will never escape its roots which were not in the IT Production
>>>> world.  Like Pascal it was intended to teach concepts and,
>>>> believe it or not, one of those concepts was not programming
>>>> per se.
>>>
>>> Interesting statement.  Coming from someone who admits to not being
>>> familiar with the language.
>>
>> Misunderstanding, again.  What I am is not an expert in VMS BASIC.
>> I have used BASIC since the Kemeny/Kurtz days.  I have done real
>> production work using BASIC on everything from Micros to Mainframes.
>> I have done business, financial and engineering programming in BASIC.
>>
>>>
>>> Perhaps older implementations of Basic were as described.
>>
>> I stated that modern BASIC had improved but that doesn't change the
>> original purpose.  The idea of "fixing" these languages (like they
>> also tried with Pascal even after the original author of Pascal
>> gave them an alternative) is little more than a band-aid when you
>> consider there were/are languages designed to do the work people
>> try to do with these languages.
>>
>>>
>>> Some time back, as I recall things, some of the compiler people at DEC
>>> asked the question, "why cannot every language be able to do what
>>> others do?".  The result was the implementation of many new features
>>> in Basic.
>>
>> Exactly.  "Lets put a band-aid on the language rather than do the proper
>> software engineering task of choosing the right tool for the job."
>>
>>>
>>> Sadly, not unsigned integers.
>>
>> Sometimes having a feature can result in some interesting errors.  I
>> have seen them, caused by unsigned integers, personally.
>>
>>>
>>> Also sadly, some of the performance inhibitors in Basic, such as the
>>> issue when returning from a subprogram.
>>>
>>> So, I'd ask for you to explain your statement.
>>>
>>
>> Simple: Choose the right tool for the job.
>> BASIC, like Pascal was intended to teach certain concepts.  It was
>> not intended as a production language.  Production languages existed,
>> even when BASIC and Pascal were created.  In those days, new languages
>> weren't just ego trips.  They were designed for particular tasks.
>> They should be used for the tasks they were designed for. That is
>> a major part of real software engineering.
>>
>> bill
>>
>>
>>
>
> You seem to be implying that VMS Basic is not a "right tool for the
> job".

Depends on the job. I only have an inkling into just what the
program(s) you do in BASIC are or do but I suspect from a real
software engineering standpoint BASIC was the wrong tool. What
made it the right tool may have been just your familiarity with
it.

> Does your opinion (that's what it is) out weight the opinions of
> others?

My opinion based on decades of research by people much better at this
stuff than I am, but, yes, my opinion. Does the CDC's opinion on how
to handle COVID outweigh ordinary people's opinions? They claim to be
backed by "science". I, too, claim to be backed by computer science.
In the end, everyone is free to do as they please. The discussion is
purely academic. I have done many things in many different fields of
endeavor that I was told (usually after the fact) were impossible.

> There have been and still are many serious applications
> implemented using VMS Basic.  Are all those people who use VMS Basic
> "wrong"?

"Wrong" is another of those words that can be more subjective than
objective. Could those applications actually be better if done
in a more suitable language? Probably. Are they doing the task
that was needed to be done. Yes. One of the big things I have
argued about (academically) was efficiency. The answer I usually
get is the state of technology today does not require efficiency
in programs. People love to complain about MS and Bloatware but
when it comes right down to it no one really cares and they continue
to use the bloated and inefficient software.

>
> Who gets to decide?
>

Like for everything else in life, at least for the moment, the
individual gets to decide. Lets hope it stays that way.

bill

On 08/09/21 17:19, chris wrote:
> business headed,

Typo: business headed, should read, business model.

LMF type systems belong to a past age of greed, mistrust and
assumptions about customer honesty and have no place in the
modern age. One of the primary reasons why vax and vms was
dumped by so many uni departments and businesses, but some never
learn.

Similar problems with embedded development tools, and compilers
in the past, where the software install was node locked,
sometimes with a dongle as well. Endless problems if it was
necessary to install on different machine, with vendors even
charging a fat fee for the "privilege". Open source tools
changed that forever, just as open source operating systems
changed the os market as well.

Dump LMF comletely, free to download and evaluate or for non
commercial use, but subscription support contract model for
ongoing patches and updates, jsut as everyone else does...

On 2021-08-07 00:41:16 +0000, Simon Clubley said:

> For example, VSI are very clearly in a mindset that's all about
> collecting ongoing revenue from the users and making sure the users
> don't try "cheating".

Welcome to Monday in a Pandemic, where the elves just try to stock
enough duct tape and patch cables and spells to keep the computadoras
trabajando sobre todo; trying to keep as much as can be kept
sorta-working.

Once upon a time, in a place far, far away, a few of the elves met in
council to discuss replacement licensing spells. The then-available
replacement licensing spells were found no more capable than the
existing spells. And the replacement spells were seriously expensive.
One risk with the then-common replacement spells that didn't arise with
the existing spells was the common use of a network warlock for spell
verification. Should that remote warlock be inaccessible for any
reason, the folks with valid spells would be Most Put Out. Or worse.
The elves also realized that the existing spells and related services
would have to be maintained for the foreseeable future too, even with a
successful replacement. The elves then lived with the usual grumbling
ever after. The End.

Once upon a time, in a place far, far into the future, these failing
licensing spells merely emit ever-larger puffs of greasy orange smoke,
with connectivity messages and spell-supporting information, eventually
with spell-degradation of sorts arising as the remote warlocks get
increasingly cranky, and with telemetry data for both failed and
successful spells all uploaded to the Bureau of Spells and Spellcasting
located at Castle Burlington. With the full magical integration across
all of the Castle Burlington elf and warlock computing spells services,
with on-line license spell purchasing, this new single-spell design
eliminates the need for many of the spells entirely (your Castle
Burlington ID and password is enough), allows the elves to access all
the resources of Castle Burlington, and to directly access supporting
books and resources and documents, to maintain compliance with the
Bureau of Spells and Spellcasting of course, and to otherwise enjoy the
benefits of Spells as a Service provided by Castle Burlington. The
elves and a few warlocks then grumbled ever after. The End.

--
Pure Personal Opinion | HoffmanLabs LLC

On 8/9/2021 12:19 PM, chris wrote:
> On 08/09/21 16:41, Arne Vajhøj wrote:
>> On 8/9/2021 11:26 AM, chris wrote:
>>> Even Oracle make their os's free to use none commercially
>>> , with again, the money made via support contracts.
>>
>> Oracle Linux is a clone of Redhat Linux. Again if VSI got VMS
>> maintained for free and they just need to wrap up a build with their
>> logo, then it would work great for them as well.
>
> Even the latest Solaris 11 is free to download and use non commercially,
> so if Oracle thinks that's a good business headed, they probably know
> what they are doing. ultra hard headed as they are...

True.

But I don't think Solaris future looks particular great. Oracle is
going Linux.

Arne

On 08/09/21 18:19, Arne Vajhøj wrote:
> On 8/9/2021 12:19 PM, chris wrote:
>> On 08/09/21 16:41, Arne Vajhøj wrote:
>>> On 8/9/2021 11:26 AM, chris wrote:
>>>> Even Oracle make their os's free to use none commercially
>>>> , with again, the money made via support contracts.
>>>
>>> Oracle Linux is a clone of Redhat Linux. Again if VSI got VMS
>>> maintained for free and they just need to wrap up a build with their
>>> logo, then it would work great for them as well.
>>
>> Even the latest Solaris 11 is free to download and use non commercially,
>> so if Oracle thinks that's a good business headed, they probably know
>> what they are doing. ultra hard headed as they are...
>
> True.
>
> But I don't think Solaris future looks particular great. Oracle is
> going Linux.
>
> Arne

Perhaps so, but desn't change the fact that Oracle have made a support
only business model a success, Linux or Solaris. A vast range of s/w
from that site, same business.

That would also solve the hobbyist question, as they generate no
revenue in any case. Why bother with hobby program at all, other
than for reasons of control...