LMF Licence Generator Code

[Lawrence D’Oliveiro]

I had a look at the original pakgen.c source from mirrors.pdp-11.ru. I get the impression somebody disassembled a bunch of VAX machine language, then did a straight transliteration into C code.

So I thought I would clean it up a bit. And I managed to knock its size down by a couple hundred lines. I also wrote a Python version, which is less than half the size of the original, and also add a few features. For example, I was able to add the HARDWARE_ID, TOKEN and VERSION atttributes by guessing at their codes. So far I haven’t been able to figure out the RELEASE_DATE and TERMINATION_DATE attributes, most likely because I can’t get the right date-encoding format.

[E Thump]

On Thursday, August 5, 2021 at 5:55:23 AM UTC+1, Lawrence D’Oliveiro wrote:
> I had a look at the original pakgen.c source from mirrors.pdp-11.ru. I get the impression somebody disassembled a bunch of VAX machine language, then did a straight transliteration into C code.
>
> So I thought I would clean it up a bit. And I managed to knock its size down by a couple hundred lines. I also wrote a Python version, which is less than half the size of the original, and also add a few features. For example, I was able to add the HARDWARE_ID, TOKEN and VERSION atttributes by guessing at their codes. So far I haven’t been able to figure out the RELEASE_DATE and TERMINATION_DATE attributes, most likely because I can’t get the right date-encoding format.

Hi - I sent you a message on LinkedIn - I can't find an email address for you.
cheers
e

[David Sweeney]

It should come as no surprise that creating a hacked version of pakgen to generate license PAKs for any VMS or OpenVMS product is not legal. The webmaster of the mirroring site has been contacted to remove the pakgen source from the site. Lawrence, whether or not the site removes the code you cannot use or share PAKGEN hack you are creating.

Dave Sweeney

[jimc...@gmail.com]

On Friday, August 6, 2021 at 6:55:11 AM UTC-7, dsweene...@gmail.com wrote:
> It should come as no surprise that creating a hacked version of pakgen to generate license PAKs for any VMS or OpenVMS product is not legal. The webmaster of the mirroring site has been contacted to remove the pakgen source from the site. Lawrence, whether or not the site removes the code you cannot use or share PAKGEN hack you are creating.
>
> Dave Sweeney

Versions of PAKGEN.C are available all over the Internet in various forums. Even if the mirrors site removes it, the cat is out of the bag there.

In many (most?) jurisdictions, it's also perfectly legal to author, refactor, and share code like PAKGEN. You're not in a position to tell Lawrence whether or not he can share that code.

[Lawrence D’Oliveiro]

By the way, some people seem to be under the impression that LMF is/was some kind of copyright enforcement tool. DEC’s own documentation made it clear this was not the intention.

[Bob Eager]

He *can* share anything he likes. Whether he should, and whether it is
legal (which it will be in many jurisdictions) is a separate matter.

But that's up to him.
--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

[Phillip Helbig (undress to reply)]

In article <47e66171-ea70-40e4...@googlegroups.com>,

"jimc...@gmail.com" <jimc...@gmail.com> writes:

> In many (most?) jurisdictions, it's also perfectly legal to author,
> refactor, and share code like PAKGEN.

Perhaps. But is it legal to use it? In any case, a reference would be
helpful. I doubt that VSI or anyone else would bother generating
licenses if it were perfectly legal to create one's own.

[Phillip Helbig (undress to reply)]

In article <3d90d9d7-99d3-404e...@googlegroups.com>,

DEC's documentation never said that it was OK to use something like a
rogue tool to generate a license to avoid buying a real one. Also,
apart from both having to do with intellectual property, licenses and
copyright have little in common.

[Simon Clubley]

Even _if_ that is the case Jim, this situation could provoke
a strong response from VSI.

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".

As such, I would not be surprised to find out that VSI are
considering implementing a much stronger version of the LMF for
the x86-64 VMS production versions.

Right now would be an ideal time to implement such a change as there
are no production licences for x86-64 VMS at the moment, so there are
no backwards compatibility issues if they implement a replacement
right now.

They could take a signed licence keys approach and later on
actually implement signed images in VMS that cannot be tampered
with to patch out the licence checks. The days when you had to
support manually entering a licence key have probably passed.

BTW, if VSI do that, you will not be able to patch the resulting
images to bypass the licence checks on the time-limited licences
if VSI do go bust.

Simon.

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

[Dave Froble]

On 8/6/2021 8:41 PM, Simon Clubley wrote:
> On 2021-08-06, jimc...@gmail.com <jimc...@gmail.com> wrote:
>> On Friday, August 6, 2021 at 6:55:11 AM UTC-7, dsweene...@gmail.com wrote:
>>> It should come as no surprise that creating a hacked version of pakgen to generate license PAKs for any VMS or OpenVMS product is not legal. The webmaster of the mirroring site has been contacted to remove the pakgen source from the site. Lawrence, whether or not the site removes the code you cannot use or share PAKGEN hack you are creating.
>>>
>>> Dave Sweeney
>>
>> Versions of PAKGEN.C are available all over the Internet in various forums. Even if the mirrors site removes it, the cat is out of the bag there.
>>
>> In many (most?) jurisdictions, it's also perfectly legal to author, refactor, and share code like PAKGEN. You're not in a position to tell Lawrence whether or not he can share that code.
>
> Even _if_ that is the case Jim, this situation could provoke
> a strong response from VSI.
>
> 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".

The first part of that is reasonable and how things must be if VSI and
VMS are going to be around for a while.

The second part is unreasonable paranoia. Who and where are these
"cheaters"? I don't know of any. Does anyone? Most of us are just
happy that VSI is there to support us, and we understand they need
revenue to do so. Which is why I prefer they have recurring revenue
rather than one time license sales.

--
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

[Simon Clubley]

If VSI were not worried about such things, they would not be
implementing time-limited licences on production machines.

Whether they are actually _right_ to be worried about such things
is a question I cannot answer.

[Phillip Helbig (undress to reply)]

In article <seklum$7q3$1...@dont-email.me>, Dave Froble

<da...@tsoft-inc.com> writes:

> The second part is unreasonable paranoia. Who and where are these
> "cheaters"? I don't know of any. Does anyone? Most of us are just
> happy that VSI is there to support us, and we understand they need
> revenue to do so. Which is why I prefer they have recurring revenue
> rather than one time license sales.

I don't know, but the fact that one can find such things on the net
shows that there must be some interest, and obviously cheaters would not
publicize that fact.

But if cheaters were a non-problem, why have LMF at all?

[Bob Eager]

On Sat, 07 Aug 2021 08:21:34 +0000, Phillip Helbig (undress to reply)
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.

Why on earth HP couldn't have generated perpetual PAKs for VAX, I don't
know. Incompetence is by far the most likely reason - well, and
disinterest.

[Bill Gunshannon]

I agree with this entirely. It is not cheaters that VSI needs to
fear it is management who come out of MBA school with no knowledge
of anything not Microsoft or Linux and will see moving from VMS to
one of those as "modernization" of a legacy system. 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. I recently saw an article
that blamed delays processing one of the government handouts on the
fact that the system is written in COBOL. I am sure that when it
comes time to replace a VMS system they will offer VAX benchmarks
as proof that VMS is just a dog that needs to be put out of its
misery.

bill

[Bill Gunshannon]

I suspect that it is "Hobbyists" that are and are likely to continue
using pakgen.c. I doubt any legitimate business would as the legal
implications (even without VSI being involved) as a serious concern.
You don't think the auditors or legal department would be looking at
this?

>
> But if cheaters were a non-problem, why have LMF at all?
>

Because it was already in the code they got and removing it might be
problematic at the moment.

bill

[Bill Gunshannon]

On 8/7/21 5:20 AM, Bob Eager wrote:
> On Sat, 07 Aug 2021 08:21:34 +0000, Phillip Helbig (undress to reply)
> wrote:
>
>> In article <seklum$7q3$1...@dont-email.me>, Dave Froble
>> <da...@tsoft-inc.com> writes:
>>
>>> The second part is unreasonable paranoia. Who and where are these
>>> "cheaters"? I don't know of any. Does anyone? Most of us are just
>>> happy that VSI is there to support us, and we understand they need
>>> revenue to do so. Which is why I prefer they have recurring revenue
>>> rather than one time license sales.
>>
>> I don't know, but the fact that one can find such things on the net
>> shows that there must be some interest, and obviously cheaters would not
>> publicize that fact.
>>
>> But if cheaters were a non-problem, why have LMF at all?
>
> 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.
>
> Why on earth HP couldn't have generated perpetual PAKs for VAX, I don't
> know. Incompetence is by far the most likely reason - well, and
> disinterest.

My vote would be for disinterest.

bill

[Arne Vajhøj]

I have always seen LMF and VMS software license check not as protection
against software piracy but as assistance to those managing licenses.
It is possible to see what licenses are there. It is possible to see
units and expiration dates. Software stop working in case someone forget
to renew licenses, which will make someone notice it.

Arne

[Phillip Helbig (undress to reply)]

In article <in7b49...@mid.individual.net>, Bill Gunshannon

<bill.gu...@gmail.com> writes:

> >> The second part is unreasonable paranoia. Who and where are these
> >> "cheaters"? I don't know of any. Does anyone? Most of us are just
> >> happy that VSI is there to support us, and we understand they need
> >> revenue to do so. Which is why I prefer they have recurring revenue
> >> rather than one time license sales.
> >
> > I don't know, but the fact that one can find such things on the net
> > shows that there must be some interest, and obviously cheaters would not
> > publicize that fact.
>

> I suspect that it is "Hobbyists" that are and are likely to continue
> using pakgen.c.

That makes little sense, as hobbyist licenses have been available for
the asking for decades.

[Bob Eager]

On Sat, 07 Aug 2021 20:33:12 +0000, Phillip Helbig (undress to reply)
wrote:

But they haven't been available for some months for VAX, and there will
be no more.

[Bill Gunshannon]

There have been times when there was no response from HP for
extended periods of time. And, we now have the VAX debacle.
No one is going to audit a Hobbyist System so there is little
if any chance of it becoming a problem.

Production systems on the other hand...

You know, our legal department refused permission to sign
the license for the last Edu Program offered by HP. I
hardly expect they would have allowed generation of our
own licenses using pakgen.c.


bill

[Arne Vajhøj]

On 8/7/2021 7:59 AM, Bill Gunshannon wrote:
> On 8/6/21 8:59 PM, Dave Froble wrote:
>> The second part is unreasonable paranoia.  Who and where are these
>> "cheaters"?  I don't know of any.  Does anyone?  Most of us are just
>> happy that VSI is there to support us, and we understand they need
>> revenue to do so.  Which is why I prefer they have recurring revenue
>> rather than one time license sales.
>
> I agree with this entirely.

Given that VMS is mostly for professional usage and that
software piracy is not common for professional usage, then
it is not likely that software piracy is a major problem.

>   It is not cheaters that VSI needs to
> fear it is management who come out of MBA school with no knowledge
> of anything not Microsoft or Linux and will see moving from VMS to
> one of those as "modernization" of a legacy system.

If you replace a system with a significantly newer system then
it seems fair to call it a modernization.

One just need to understand that newer does not guarantee
better.

>   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.

It becomes a problem if:
- it is out of support
- it is hard to find people with skills
- it does not integrate with newer system that it need to
integrate with
- it is expensive to maintain

Arne

[Dave Froble]

It has occurred to me that VSI should have the opportunity to know who
is using x86 VMS. From the beginning, they implement some sort of
reporting scheme. For VMS to run, it has to check in with VSI. There
may be situations where such is not feasible, but, that can also be handled.

Now, if someone is on VAX, Alpha, or itanic and has a valid HP license,
if they wish to stay there, that could be done. If someone wants to
"cheat" on VAX, Alpha, or itanic, why does VSI care, x86 is their
immediate future.

[Bill Gunshannon]

On 8/7/21 5:56 PM, Arne Vajhøj wrote:
> On 8/7/2021 7:59 AM, Bill Gunshannon wrote:
>> On 8/6/21 8:59 PM, Dave Froble wrote:
>>> The second part is unreasonable paranoia.  Who and where are these
>>> "cheaters"?  I don't know of any.  Does anyone?  Most of us are just
>>> happy that VSI is there to support us, and we understand they need
>>> revenue to do so.  Which is why I prefer they have recurring revenue
>>> rather than one time license sales.
>>
>> I agree with this entirely.
>
> Given that VMS is mostly for professional usage and that
> software piracy is not common for professional usage, then
> it is not likely that software piracy is a major problem.
>
>>                             It is not cheaters that VSI needs to
>> fear it is management who come out of MBA school with no knowledge
>> of anything not Microsoft or Linux and will see moving from VMS to
>> one of those as "modernization" of a legacy system.
>
> If you replace a system with a significantly newer system then
> it seems fair to call it a modernization.

I quoted modernization because it is usual used as an epithet like
"legacy". It is frequently change for changes sake.

>
> One just need to understand that newer does not guarantee
> better.

And change for changes sake is seldom a good thing.

>
>>                                                       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.

> - it is hard to find people with skills

That is a fixable problem.

https://edscoop.com/college-legacy-programming-langauges-grant-bill/

> - 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.

> - 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.

bill

[Simon Clubley]

On 2021-08-07, Bob Eager <news...@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.

[Arne Vajhøj]

On 8/7/2021 6:40 PM, Dave Froble wrote:
> It has occurred to me that VSI should have the opportunity to know who
> is using x86 VMS.  From the beginning, they implement some sort of
> reporting scheme.  For VMS to run, it has to check in with VSI.  There
> may be situations where such is not feasible, but, that can also be
> handled.

In general such requiring internet access or as a fallback a
phone call is not popular with users.

And if there is little cheating then VSI already knows
the user base because they know what licenses has been
issued.

Arne

[Simon Clubley]

On 2021-08-07, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>
> I suspect that it is "Hobbyists" that are and are likely to continue
> using pakgen.c. I doubt any legitimate business would as the legal
> implications (even without VSI being involved) as a serious concern.
> You don't think the auditors or legal department would be looking at
> this?
>

Before Windows online activation was created, how many people reused
the same licence key on different PCs ? In other words, how many people
had more PCs than licences for the software which ran on them ?

[Simon Clubley]

On 2021-08-07, Bob Eager <news...@eager.cx> wrote:
>

> But they haven't been available for some months for VAX, and there will
> be no more.
>

The final hobbyist VAX licences (and HPE Alpha VMS licences) expire
at the end of this year. The final licences were given an extra year
to run.

[Arne Vajhøj]

On 8/7/2021 7:20 PM, Simon Clubley wrote:
> On 2021-08-07, Bob Eager <news...@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.

Why?

Strong license checks is a home computer software thing.

In the professional market there is not much need. Relative
few cheat. And the usual way to check against cheating
is a software license audit.

Arne

[Simon Clubley]

On 2021-08-07, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 8/7/2021 7:59 AM, Bill Gunshannon wrote:
>> On 8/6/21 8:59 PM, Dave Froble wrote:
>>> The second part is unreasonable paranoia.  Who and where are these
>>> "cheaters"?  I don't know of any.  Does anyone?  Most of us are just
>>> happy that VSI is there to support us, and we understand they need
>>> revenue to do so.  Which is why I prefer they have recurring revenue
>>> rather than one time license sales.
>>
>> I agree with this entirely.
>
> Given that VMS is mostly for professional usage and that
> software piracy is not common for professional usage, then
> it is not likely that software piracy is a major problem.
>

What about some people reusing licence keys for some Microsoft Windows
and Windows applications before online activation was implemented ?

[Arne Vajhøj]

On 8/7/2021 7:23 PM, Simon Clubley wrote:
> Before Windows online activation was created, how many people reused
> the same licence key on different PCs ? In other words, how many people
> had more PCs than licences for the software which ran on them ?

Among the home PC build it yourself enthusiasts: millions.

But that is not the market VMS is into.

Arne

[Arne Vajhøj]

On 8/7/2021 7:28 PM, Simon Clubley wrote:
> On 2021-08-07, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 8/7/2021 7:59 AM, Bill Gunshannon wrote:
>>> On 8/6/21 8:59 PM, Dave Froble wrote:
>>>> The second part is unreasonable paranoia.  Who and where are these
>>>> "cheaters"?  I don't know of any.  Does anyone?  Most of us are just
>>>> happy that VSI is there to support us, and we understand they need
>>>> revenue to do so.  Which is why I prefer they have recurring revenue
>>>> rather than one time license sales.
>>>
>>> I agree with this entirely.
>>
>> Given that VMS is mostly for professional usage and that
>> software piracy is not common for professional usage, then
>> it is not likely that software piracy is a major problem.
>
> What about some people reusing licence keys for some Microsoft Windows
> and Windows applications before online activation was implemented ?

What about that?

Home usage <> professional usage.

Arne

[Simon Clubley]

On 2021-08-07, Dave Froble <da...@tsoft-inc.com> wrote:
>
> It has occurred to me that VSI should have the opportunity to know who
> is using x86 VMS. From the beginning, they implement some sort of
> reporting scheme. For VMS to run, it has to check in with VSI. There
> may be situations where such is not feasible, but, that can also be handled.
>

SOD THAT !!!!!

That raises all kinds of security and denial of service issues.

People could be persuaded to allow this for a one-time licence
activation process but there's no way that many people are going
to allow that on an ongoing basis as part of the boot process and
then stop the boot if the check in with VSI fails.

What happens if you have external communications down ?

What happens if VSI have system availability issues ?

What happens if VSI goes bust ?

[Simon Clubley]

So you are saying that businesses never reused Windows and Windows
applications licence keys before Windows activation was invented ?

[Arne Vajhøj]

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.

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.

>> - 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?

>> - 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.

But good integration will often be either impossible or
expensive.

>> - 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.

Arne

[Arne Vajhøj]

On 8/7/2021 7:40 PM, Simon Clubley wrote:
> On 2021-08-07, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 8/7/2021 7:28 PM, Simon Clubley wrote:
>>>
>>> What about some people reusing licence keys for some Microsoft Windows
>>> and Windows applications before online activation was implemented ?
>>
>> What about that?
>>
>> Home usage <> professional usage.
>
> So you are saying that businesses never reused Windows and Windows
> applications licence keys before Windows activation was invented ?

That must have been pretty rare.

Companies in general do not want to base their business on
software piracy.

BTW, corporate Windows PC's does not activate Windows
licenses like home PC's does. MS licenses are a jungle, but
my understanding of current practice is that there are
MAK licenses where the same license can be activated multiple times
similar way as home PC's and KMS where PC's activate from
corporate KMS server without talking to MS.

Arne

[Bill Gunshannon]

On 8/7/21 7:23 PM, Simon Clubley wrote:
> On 2021-08-07, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>>
>> I suspect that it is "Hobbyists" that are and are likely to continue
>> using pakgen.c. I doubt any legitimate business would as the legal
>> implications (even without VSI being involved) as a serious concern.
>> You don't think the auditors or legal department would be looking at
>> this?
>>
>
> Before Windows online activation was created, how many people reused
> the same licence key on different PCs ?

In home use, I am sure a few. But being as every box bought by
none geeks came with a copy of the current Windows OS what reason
would people have had?

> In other words, how many people
> had more PCs than licences for the software which ran on them ?

I suspect not as many as you would like to think. See the reason above.

And between home and office it is like hobbyist and production.
While there may be some in home use (but I suspect less than
you might be hoping for to support your argument) among office
systems I expect the number is a statistically insignificant
number greater than zero.

I am a geek and all of my Windows systems (a dwindling number lately)
have been legitimately licensed and that includes the 98, NT and 2000
systems I still play with.

bill

[Bill Gunshannon]

I suspect that most of the home PC build it yourself market are
not running Windows at all but Linux, BSD or something else.

bill

[Bill Gunshannon]

On 8/7/21 7:35 PM, Simon Clubley wrote:
> On 2021-08-07, Dave Froble <da...@tsoft-inc.com> wrote:
>>
>> It has occurred to me that VSI should have the opportunity to know who
>> is using x86 VMS. From the beginning, they implement some sort of
>> reporting scheme. For VMS to run, it has to check in with VSI. There
>> may be situations where such is not feasible, but, that can also be handled.
>>
>
> SOD THAT !!!!!
>
> That raises all kinds of security and denial of service issues.
>
> People could be persuaded to allow this for a one-time licence
> activation process but there's no way that many people are going
> to allow that on an ongoing basis as part of the boot process and
> then stop the boot if the check in with VSI fails.
>
> What happens if you have external communications down ?
>
> What happens if VSI have system availability issues ?
>
> What happens if VSI goes bust ?
>

What happens if your on SIPRnet? :-)

bill

[Bill Gunshannon]

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. :-)

>
> 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. let's limit this to the kind of
things VMS is actually used for in most cases.

>
>>> - 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.

>
>>> - 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.

>
> But good integration will often be either impossible or
> expensive.

I would like to see examples of this, Real ones, not some of the
typical contrived examples I usually see where the target moves
with every new iteration. There are a lot of modern, used everyday
ISes that are based on what are called legacy systems and languages.
MOst of the users never notice.

>
>>> - 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.

bill

[Bill Gunshannon]

On 8/7/21 7:40 PM, Simon Clubley wrote:
> On 2021-08-07, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 8/7/2021 7:28 PM, Simon Clubley wrote:
>>>
>>> What about some people reusing licence keys for some Microsoft Windows
>>> and Windows applications before online activation was implemented ?
>>
>> What about that?
>>
>> Home usage <> professional usage.
>>
>
> So you are saying that businesses never reused Windows and Windows
> applications licence keys before Windows activation was invented ?
>

Highly unlikely. Legal would have people fired for that. And,
it would be totally unnecessary as the cost is a write-off like
the phone bill, the purchase of the computer, etc. etc. etc.

bill

[Dave Froble]

On 8/7/2021 7:35 PM, Simon Clubley wrote:
> On 2021-08-07, Dave Froble <da...@tsoft-inc.com> wrote:
>>
>> It has occurred to me that VSI should have the opportunity to know who
>> is using x86 VMS. From the beginning, they implement some sort of
>> reporting scheme. For VMS to run, it has to check in with VSI. There
>> may be situations where such is not feasible, but, that can also be handled.
>>
>
> SOD THAT !!!!!

I didn't say it would be a good idea, it was just something I thought
of. Something like that would have been much harder (or impossible) in
the 1970s and 1980s. But today, the concept of always knowing who is
running VMS might be interesting.

Perhaps it would require all VSI employees to have a top secret clearance.

:-)

> That raises all kinds of security and denial of service issues.

Perhaps, and perhaps there would be solutions.

> People could be persuaded to allow this for a one-time licence
> activation process but there's no way that many people are going
> to allow that on an ongoing basis as part of the boot process and
> then stop the boot if the check in with VSI fails.

Maybe it would not stop booting and running?

> What happens if you have external communications down ?

Phone call? Oh, wait, phones are "communications".

> What happens if VSI have system availability issues ?

Phone call?

> What happens if VSI goes bust ?

Seems like we already got that ...


Instead of complaining, why don't you think of possible solutions.
Don't bring me problems, bring me solutions.

[Dave Froble]

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?

:-)

>>> 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.

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

>>> - 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.

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

BULLSHIT !!!!

>>> - 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?

[Dave Froble]

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. :-)

People are using VAX emulators that run quite a bit faster than any VAX.

>> 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. let's limit this to the kind of
> things VMS is actually used for in most cases.

What? Common sense in c.o.v? No, we can't have any of that.

[Bob Eager]

On Sat, 07 Aug 2021 23:26:24 +0000, Simon Clubley wrote:

> On 2021-08-07, Bob Eager <news...@eager.cx> wrote:
>>
>> But they haven't been available for some months for VAX, and there will
>> be no more.
>>
>>
> The final hobbyist VAX licences (and HPE Alpha VMS licences) expire at
> the end of this year. The final licences were given an extra year to
> run.

That's what I meant by 'there will be no more'.

[Bill Gunshannon]

On 8/7/21 10:17 PM, Dave Froble wrote:
> On 8/7/2021 7:35 PM, Simon Clubley wrote:
>> On 2021-08-07, Dave Froble <da...@tsoft-inc.com> wrote:
>>>
>>> It has occurred to me that VSI should have the opportunity to know who
>>> is using x86 VMS.  From the beginning, they implement some sort of
>>> reporting scheme.  For VMS to run, it has to check in with VSI.  There
>>> may be situations where such is not feasible, but, that can also be
>>> handled.
>>>
>>
>> SOD THAT !!!!!
>
> I didn't say it would be a good idea, it was just something I thought
> of.  Something like that would have been much harder (or impossible) in
> the 1970s and 1980s.  But today, the concept of always knowing who is
> running VMS might be interesting.
>
> Perhaps it would require all VSI employees to have a top secret clearance.
>
> :-)

Having a security clearance does not automatically grant you access
to classified information.

>
>> That raises all kinds of security and denial of service issues.
>
> Perhaps, and perhaps there would be solutions.

Yes, and one of those solutions would be to move off of VMS. :-)

>
>> People could be persuaded to allow this for a one-time licence
>> activation process but there's no way that many people are going
>> to allow that on an ongoing basis as part of the boot process and
>> then stop the boot if the check in with VSI fails.
>
> Maybe it would not stop booting and running?

If it doesn't do something what would be the point?

>
>> What happens if you have external communications down ?
>
> Phone call?  Oh, wait, phones are "communications".
>
>> What happens if VSI have system availability issues ?
>
> Phone call?

If all they have is 5 customers, that might work.

>
>> What happens if VSI goes bust ?
>
> Seems like we already got that ...
>
>
> Instead of complaining, why don't you think of possible solutions. Don't
> bring me problems, bring me solutions.
>

The two sides of this discussion have opposing needs and desires. A
satisfactory solution could be more difficult than you think.

bill

[Arne Vajhøj]

Nope.

A very large portion of home built PC's are gamer rigs
running Windows.

Arne

[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:
>>>> 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

[Arne Vajhøj]

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.

>> 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

>>>> - 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.

>>>> - 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 ...

Arne

[VAXman-]

In article <sekme9$96d$1...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2021-08-06, Dave Froble <da...@tsoft-inc.com> wrote:
>> On 8/6/2021 8:41 PM, Simon Clubley wrote:
>>>
>>> Even _if_ that is the case Jim, this situation could provoke
>>> a strong response from VSI.
>>>
>>> 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".
>>
>> The first part of that is reasonable and how things must be if VSI and
>> VMS are going to be around for a while.

>>
>> The second part is unreasonable paranoia. Who and where are these
>> "cheaters"? I don't know of any. Does anyone? Most of us are just
>> happy that VSI is there to support us, and we understand they need
>> revenue to do so. Which is why I prefer they have recurring revenue
>> rather than one time license sales.
>>
>

>If VSI were not worried about such things, they would not be
>implementing time-limited licences on production machines.
>
>Whether they are actually _right_ to be worried about such things
>is a question I cannot answer.

LMF, the way it has been used by the keepers and caretakers of VMS, isn't
strong. However, when it was implemented, VMS engineering said it wasn't
intended to be a enforcement tool. There are fields in the LMF PAK that
can be employed to make PAK verification stronger. I routinely make use
of the hardware ID and token fields to strengthen enforcement. Perhaps,
before complaining about a VMS tool, you should learn a little bit more
about the tool.

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

I speak to machines with the voice of humanity.

[VAXman-]

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 <news...@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?

[Dave Froble]

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 ....

[Arne Vajhøj]

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

[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

[Jan-Erik Söderholm]

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.

[Bill Gunshannon]

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

[Bill Gunshannon]

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

[Bill Gunshannon]

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

[Bill Gunshannon]

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

bill

[Simon Clubley]

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.

[Dave Froble]

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 ...

[Dave Froble]

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.

[Bill Gunshannon]

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

[Simon Clubley]

On 2021-08-08, Dave Froble <da...@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 ?

[Dave Froble]

On 8/9/2021 8:08 AM, Simon Clubley wrote:
> On 2021-08-08, Dave Froble <da...@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.

[Dave Froble]

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?

[John Reagan]

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

[chris]

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.

[Arne Vajhøj]

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

[VAXman-]

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 <VAX...@SendSpamHere.ORG> wrote:

>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

[chris]

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

[Bill Gunshannon]

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

[chris]

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...

[Stephen Hoffman]

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

[Arne Vajhøj]

True.

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

Arne

[chris]

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...

[Simon Clubley]

On 2021-08-09, Dave Froble <da...@tsoft-inc.com> wrote:
> On 8/9/2021 8:08 AM, Simon Clubley wrote:
>> On 2021-08-08, Dave Froble <da...@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.
>

Yes it will if VSI terminate the hobbyist program for some reason or
restrict its functionality for some reason.

Given some of the sense of entitlement we have seen, some people will
not accept that and look for ways to break the licencing on the existing
VSI hobbyist kits before this change or retirement was made.

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

You really don't get this honourable behaviour thing do you David ?

How a person conducts themself in one area can be used as an indicator
for how they will conduct themself in another area.

If you feel free to bypass a VAX licence, you are likely to feel free
to bypass a VSI hobbyist licence if the VSI hobbyist program gets changed
for some reason.

> 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?
>

I have explained that above.

> 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?
>

You are moving the discussion away from hobbyist programs and to
business use.

However, to answer your question: No, I don't expect them to cease to
exist either. What I expect is for them to have done is to come up with
plans for how they would handle the failure of a vendor if they start
doing business with that vendor.

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

Careful David, I'm getting told off for considering that possibility. :-)

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

What you should have done is before you committed to a vendor was to
consider what you would do if that vendor goes bust one day.

And to their credit, it looks like everyone is doing this. Why do you
think there is such a strong negative reaction to the time limited
production licences ?

[Simon Clubley]

On 2021-08-09, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>
> 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.
>

That's great right until Castle Burlington burns down or isn't
viable to keep running any longer.

[Arne Vajhøj]

On 8/9/2021 1:37 PM, chris wrote:
> 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.
>

> 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.

Having doubt about one products future and getting the other product
most maintained by somebody else is not what I would consider a
successful business model for VSI to adopt.

> 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...

True.

And if VSI would make money from VMS HW then it would be a lot
easier to make it work out. But they are not.

Arne

[chris]

On 08/09/21 18:48, Simon Clubley wrote:
> On 2021-08-09, Dave Froble<da...@tsoft-inc.com> wrote:
>> On 8/9/2021 8:08 AM, Simon Clubley wrote:
>>> On 2021-08-08, Dave Froble<da...@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.
>>
>
> Yes it will if VSI terminate the hobbyist program for some reason or
> restrict its functionality for some reason.
>
> Given some of the sense of entitlement we have seen, some people will
> not accept that and look for ways to break the licencing on the existing
> VSI hobbyist kits before this change or retirement was made.
>
>> VSI has no interest in VAX. So why should they care if some hobbyists
>> do whatever necessary to continue to run VAX/VMS?
>>
>
> You really don't get this honourable behaviour thing do you David ?
>
> How a person conducts themself in one area can be used as an indicator
> for how they will conduct themself in another area.

All relationships in life depend on trust, but that applies to both
sides. If a company is seen as greedy or mistrustful, then why should
customers trust them ?. Things like lmf start of at the wrong side
of trust and some, right or wrong, may take that as an excuse to
cheat the system themselves. Much better to be seen on the right side
of trust, setting an example, which encourages others to do the right
thing as well.

Remember the business model chosen by DEC, and we all know how that
ended...

[chris]

On 08/09/21 19:04, Arne Vajhøj wrote:
> On 8/9/2021 1:37 PM, chris wrote:
>> 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.
>>
>> 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.
>
> Having doubt about one products future and getting the other product
> most maintained by somebody else is not what I would consider a
> successful business model for VSI to adopt.

Of course, but we are not suggesting that and in any case, Oracle always
have, right back to the days of Sun, done all the Solaris development
in house, millions of $, but have made money from it none the less.

Found a generous attitude with IBM as well, in that when evaluating an
old power machine, found a utility on the IBM web site that worked out
all the patches needed for the version of aix, then emailed a link to
download the whole lot in one hit. No charge, no license questions and
no pack drill. Just got the job done.

Get better results in business if you are seen as being generous and
willing to help, but that seems obvious to me...

[Bill Gunshannon]

On 8/9/21 12:47 PM, chris wrote:
> 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.

As someone who was there and fought against the removal of VMS from
academic circles, you are just plain wrong. No one other than the
administrator knew what LMF was or what it did. VMS went away from
academia because it was seen as old and not moving forward. It was
legacy. (There's that word again!!) It was dropped at the same time
that other legacy items like COBOL and Fortran and Pascal (and, yes,
Ada) were left in the dust.


Even after it left academia the schools still used it administratively.
It left that market when the canned packages everyone was using (like
Banner) dropped support for it. You would have to ask them why they
decided to abandon VMS. What does Oracle say about it??

bill

[Stephen Hoffman]

On 2021-08-09 17:56:40 +0000, Simon Clubley said:

> That's great right until Castle Burlington burns down or isn't viable
> to keep running any longer.

The castle "burned down" once before, and with the vendor having been
presenting platform porting sessions. No SaaS license time limits that
time of course, which is your central concern here. Outside of that one
licensing detail, the remaining customers clearly already have a fairly
high tolerance for the platform vendor disappearing.

If the SaaS licensing is a concern (and it may well be), then work with
VSI for license escrow and/or for longer licenses and/or for longer
support subscriptions, and/or review or plan or start porting, and/or
start making the existing app code more portable, and/or expect to
negotiate with whatever entity acquires the rights to the swamp that
the castle burned down, fell over, and sank into. There are other
options. Check with the local organization's corporate legal and
corporate risk folks, too.

I've worked with piles of FORTRAN and which were and are fairly
portable, and with other apps which are tied pretty tightly to OpenVMS
features. And I'm aware of apps that have already ported, or that are
porting.

[John Dallman]

In article <serrmi$1akh$1...@gioia.aioe.org>, chris-...@tridac.net (chris)
wrote:

> On 08/09/21 19:04, Arne Vajhøj wrote:
> > On 8/9/2021 1:37 PM, chris wrote:
> >> 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.

Oracle are not primarily in the OS business. Nor were Sun.

Sun were in the hardware business, and became non-viable when commodity
hardware with Linux became far more cost-effective than their own
hardware with Solaris.

Oracle are in the database software business. The database is free to
evaluate, but /not/ to use for commercial production work.

> Of course, but we are not suggesting that and in any case, Oracle
> always have, right back to the days of Sun, done all the Solaris
> development in house, millions of $, but have made money from it
> none the less.

They seem to have rather lower levels of spending on that these days.

John

[chris]

On 08/09/21 21:35, John Dallman wrote:
> In article<serrmi$1akh$1...@gioia.aioe.org>, chris-...@tridac.net (chris)
> wrote:
>
>> On 08/09/21 19:04, Arne Vajhøj wrote:
>>> On 8/9/2021 1:37 PM, chris wrote:
>>>> 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.
>
> Oracle are not primarily in the OS business. Nor were Sun.
>
> Sun were in the hardware business, and became non-viable when commodity
> hardware with Linux became far more cost-effective than their own
> hardware with Solaris.
>
> Oracle are in the database software business. The database is free to
> evaluate, but /not/ to use for commercial production work.

Of course, all that is public knowledge and here at least, have been
using Sun kit for far longer than vms. That's sad, because VMS was the
first serious OS I worked with and I really liked it. At least with
some other proprietary systems, I can evaluate at no cost and use them
without limit for non commercial purposes. More likely to find something
to recommend to clients under such conditions.

>
>> Of course, but we are not suggesting that and in any case, Oracle
>> always have, right back to the days of Sun, done all the Solaris
>> development in house, millions of $, but have made money from it
>> none the less.
>
> They seem to have rather lower levels of spending on that these days.

Yes, nothing stays the same, but still doesn't negate the point I was
trying to make about successful software licensing models...


>
> John

[chris]

I guess books have been written on that subject, but the OS market
has far more choices now than in the past. Any OS trying to make
headway needs to have as few encumbrances as possible and be simple
to get started with. Just download, install and go, ideally. If it
looks like hard work, people will go elsewhere...

[Bill Gunshannon]

Anybody here know what licensing model Unisys uses? They don't call
it a Hobbyist Program but I have Unisys 2200 running on Intel here.
Works under Windows or Linux. Just like the days when I did Univac
1100 running Exec-8. Still supports the 68/74 COBOL compiler I used
when I did this every day.

bill

[chris]

Perhaps no one really cares about a few enthusiasts running older
operating systems. I have several pdp and vax machines, where
there are none of the original DEC os's available to run
legally. I can run several versions of unix from the unix
historical society, but no DEC os's, making all that older
hardware orphans. Did a lot of work on PDP and vax machines
years ago, but no provision now and even have some RA60 packs
full of that work, but are any RA60 drives alive now ?. Maybe
in the US, but not in the uk. I'm sure all this has been done
to death in the past here, but no solution, it seems...

[Bill Gunshannon]

If you mean the Unisys I was talking about it isn't something old. It
is their current Mainframe Software System. The comments about Univac
1100 and Exec-8 was merely to point out that they continue to support
their older systems along with current technology.

> I have several pdp and vax machines, where
> there are none of the original DEC os's available to run
> legally. I can run several versions of unix from the unix
> historical society, but no DEC os's, making all that older
> hardware orphans. Did a lot of work on PDP and vax machines
> years ago, but no provision now and even have some RA60 packs
> full of that work, but are any RA60 drives alive now ?. Maybe
> in the US, but not in the uk. I'm sure all this has been done
> to death in the past here, but no solution, it seems...

Still doesn't answer the question about what licensing system Unisys
uses.

bill

[Arne Vajhøj]

On 8/9/2021 4:34 PM, John Dallman wrote:
> In article <serrmi$1akh$1...@gioia.aioe.org>, chris-...@tridac.net (chris)
> wrote:
>> On 08/09/21 19:04, Arne Vajhøj wrote:
>>> On 8/9/2021 1:37 PM, chris wrote:
>>>> 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.
>
> Oracle are not primarily in the OS business. Nor were Sun.
>
> Sun were in the hardware business, and became non-viable when commodity
> hardware with Linux became far more cost-effective than their own
> hardware with Solaris.
>
> Oracle are in the database software business. The database is free to
> evaluate, but /not/ to use for commercial production work.

Oracle is in a lot of businesses today.

Database business.

ERP/CRM business.

Middleware business (WebLogic etc.).

I believe they are trying to get out of the HW & OS business (SPARC
servers and Solaris).

They are trying to get into the cloud business.

Arne

[chris]

On 08/09/21 23:46, Bill Gunshannon wrote:

>>>
>>
>> Perhaps no one really cares about a few enthusiasts running older
>> operating systems.
>
> If you mean the Unisys I was talking about it isn't something old. It
> is their current Mainframe Software System. The comments about Univac
> 1100 and Exec-8 was merely to point out that they continue to support
> their older systems along with current technology.
>

I guess Unisys have been around long enough to realise that a few
home hackers are no threat to their business and may even encourage
it in an unofficial way. A more relaxed attitude like that is
good for business as well, rather than veiled threats about legal
action against such people. I would be more likely to support such
a company anyway. Bad attitude always gets up peoples noses.

>
>> I have several pdp and vax machines, where
>> there are none of the original DEC os's available to run
>> legally. I can run several versions of unix from the unix
>> historical society, but no DEC os's, making all that older
>> hardware orphans. Did a lot of work on PDP and vax machines
>> years ago, but no provision now and even have some RA60 packs
>> full of that work, but are any RA60 drives alive now ?. Maybe
>> in the US, but not in the uk. I'm sure all this has been done
>> to death in the past here, but no solution, it seems...
>
> Still doesn't answer the question about what licensing system Unisys
> uses.

No idea, but why don't you ask them ?...

>
> bill
>
>

[Arne Vajhøj]

>>> 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.
>>

>> 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.

I guess you can take 3 different approaches to evaluating Basic.

The anecdotal approach.

Basic was created in the mid 60's specifically for teaching.

Dartmouth Basic was not that useful for real world usage.

And computer scientists soon started criticizing Basic. Including
Dijkstra "It is practically impossible to teach good programming to
students that have had a prior exposure to BASIC: as potential
programmers they are mentally mutilated beyond hope of regeneration."

And that must mean that everything Basic will forever be bad.

The engineering approach.

Does the language has the data types, control structures, IO
support etc. to enable writing business applications.

Dartmouth Basic did not.

But VMS Basic seems to have what is needed. Data types
including decimal. Conditional and loops. Sequential and
index-sequential IO.

There are a few warts: implicit type by last character in
variable name, lack of thread safety etc..

But overall VMS Basic is no worse than other VMS
procedural language.

Good solid 1980's technology.

And if one has to chose one of those traditional
1980's VMS procedural languages (Fortran, Cobol,
Basic, Pascal, C) then Pascal and Basic seems
by far the most obvious to use - they will result in
less more readable code than the other.

VB.NET Microsoft's latest incarnation of Basic
is a full blown OOP language with some FP support.

Good solid 2000's technology.

Microsoft's previous incarnation VB6 and VBS had
some limitations but were definitely usable as well.

The empirical approach.

VMS Basic has a piece of the VMS application development
market - I don't know exactly how how big - but while
Ada, PL/I etc. are gone then Basic is still supported, so
Dave is not the only user.

VB6 and VBS (in ASP) must have been one of the worlds
most used programming languages 1995-2005. It must have
been usable.

VB.NET is definitely lacking behind C# but are still widely
used. It must be useful.

++++

Trying to evolve existing languages into a different type
of language is not always a success.

I believe nobody in the Cobol community liked OO Cobol.

Fortran 77 to Fortran 90 was really an entirely new language
and a lot of users were lost in the process.

The Ada 83 to Ada 95 made the language very complicated.

The FP stuff added to Java 8 is not pretty.

But other are more lucky.

Object-Pascal and Delphi may not be super elegant addon
of OO, but the users liked it.

VMS Basic and the later MS Basic implementation also
managed to add totally new features (full OO for VB.NET,
somewhat OO for VB6/VBS) and be popular with
users.

Basic seems to be good language to extend.

So Jon Reagan - when do we see OO in VMS Basic?

:-)

Arne

[Lawrence D’Oliveiro]

So, it looks like it is not permitted for my code to be published freely.

So the next best thing, that I can think of, is to publish a step-by-step description of the algorithm, with enough detail that anybody can write their own PAK generator program. Would you like that?

What’s that phrase I was trying to think of ... oh yes: “protected speech”.

[Arne Vajhøj]

On 8/8/2021 4:52 PM, Jan-Erik Söderholm wrote:
> 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
>> ?

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

What is important is what the solution provide.

How that solution is implemented:
* one server communicating with scripts running in different processes
* one server running code in different modules within the process
* a standalone module including a standalone server
does not matter so much, except that the first approach tend to
make a lot of things more difficult.

> 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.

The Cobol code has no problem doing the business logic. The
problem is with the web context on top of that.

And I don't think WASD/Apache/OSU can solve much of the
above as it mostly have to be embedded in the application.

# session sharing across cluster

The web server cannot share the application's
session object across the cluster as it does not
have access to it.

# OAuth integration
# LDAP integraion

The web server can use use for accepting/denying
access to the application and pass on username,
but if the application want to query for roles
of that username, then the web server cannot help.

# verification of client certificate

Does the web server pass enough information on to
application about SSL for it to verify?

# Redis or memcached for cache

Pure application. The web server can not cache info it
does not have access to.

# exposing status / load info to load balancer

The web server can be load balanced based on general web server
status. But it will not be able to load balance based on
the state in the application.

# reporting stats and health check to IBM Tivoli / CA Unicenter / Zabbix
# reporting to Prometheus

Pure application. The web server can not provide info
it does not have access to.

# HTTP/2 push

The web server may support HTTP/2, but it cannot embed stuff
in the response by itself. And unless CGI protocol has been
heavily extended to allow passing the info, then the application
cannot pass it.

# web sockets

The web server may support it, but how does it get it to the application
via CGI?

# switching to in-cloud managed service for database

Pure application

# having accept request header determine response format

Pure application. Also definitely doable in Cobol - just
requiring a lot of lines of code to do it.

> 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.

I am definitely not arguing against using an existing web server
(or application server).

That is a given. The only question is standalone or embedded.

My point is that there are technologies that:
- works with existing web servers
- provides a ton of features useful in web context that a
Cobol CGI script does not have

Arne

[Arne Vajhøj]

On 8/9/2021 7:54 PM, Arne Vajhøj wrote:
> Basic was created in the mid 60's specifically for teaching.
>
> Dartmouth Basic was not that useful for real world usage.

BTW, if anyone want Dartmouth Basic, then there is an
implementation of 4th edition available here:

https://github.com/emesx/jBasic

It seems to work fine.

C:\Work>type test.bas
10 for x = 1 to 10
20 print x
30 next x
40 end

C:\Work>jbasic test.bas
1.0
2.0
3.0
4.0
5.0
6.0
7.0
8.0
9.0
10.0

Arne

PS: Requires Java 8.

[Arne Vajhøj]

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

That may be the case.

But PHP would have supported a lot of that out of the box.

# session sharing across cluster

Supported.

(implementation is not that great as it relies on shared storage,
but it is there, and those with a need to be more
scalable can use Redis or memcached)

# OAuth integration

Extension exist.

# LDAP integraion

Supported.

(need to be anebaled at build though)

# verification of client certificate

There are ways to get the info checked and passed
by web server to PHP in $_SERVER variable.

# Redis or memcached for cache

Extensions exist.

# exposing status / load info to load balancer

Not sure.

# reporting stats and health check to IBM Tivoli / CA Unicenter / Zabbix

Supported.

# reporting to Prometheus

Client lib exist.

# HTTP/2 push

Libraries exist.

# web sockets

Library exist.

# switching to in-cloud managed service for database

If using PDO good chance that it will work.

# having accept request header determine response format

Great XML and JSON support but unlike Java and .NET an
actual if statement is needed.

Arne

[Dave Froble]

On 8/9/2021 11:26 AM, chris wrote:

> 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 <da...@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.

I don't have a problem with VSI requiring support for commercial use.
I've been saying that for years now. It is the way to go.

But my customers are important to me, and, I cannot promote anything
that would cripple or destroy their businesses, and their employees jobs.

I'm thinking that VSI would have similar intent, and for all we know,
there is already something to address that. We just aren't aware of it.

--
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

[Dave Froble]

Truth ...

The moe people exposed to VMS, the better it is for VSI ...

[Dave Froble]

On 8/9/2021 1:48 PM, Simon Clubley wrote:
> On 2021-08-09, Dave Froble <da...@tsoft-inc.com> wrote:
>> On 8/9/2021 8:08 AM, Simon Clubley wrote:
>>> On 2021-08-08, Dave Froble <da...@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.
>>
>
> Yes it will if VSI terminate the hobbyist program for some reason or
> restrict its functionality for some reason.

There is, and will not be any such restrictions. The hobbyist program
is good for VMS, and what's good for VMS is good for VSI. There are
reasons hobbyist programs started, and those reasons continue to be valid.

> Given some of the sense of entitlement we have seen, some people will
> not accept that and look for ways to break the licencing on the existing
> VSI hobbyist kits before this change or retirement was made.
>
>> VSI has no interest in VAX. So why should they care if some hobbyists
>> do whatever necessary to continue to run VAX/VMS?
>>
>
> You really don't get this honourable behaviour thing do you David ?

I'm thinking that you're going way overboard with it.

> How a person conducts themself in one area can be used as an indicator
> for how they will conduct themself in another area.

I don't know the numbers, but VAX hobbyists are not x86 hobbyists.

VAX hobbyists are people interested in history, what they have used in
the past, and such.

x86 hobbyists might be more into trying out VMS to see what it can do,
and perhaps consider it for future commercial use.

> If you feel free to bypass a VAX licence, you are likely to feel free
> to bypass a VSI hobbyist licence if the VSI hobbyist program gets changed
> for some reason.

Logic says that is highly unlikely. If they were not desirable, they
would never have been started.

>> 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?
>>
>
> I have explained that above.
>
>> 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?
>>
>
> You are moving the discussion away from hobbyist programs and to
> business use.

I was never concerned with the hobbyist program. I am concerned for my
customers, and that is where my loyalty lies.

> However, to answer your question: No, I don't expect them to cease to
> exist either. What I expect is for them to have done is to come up with
> plans for how they would handle the failure of a vendor if they start
> doing business with that vendor.

The plan is to do whatever is necessary.

>> Read that last paragraph carefully and then explain what should happen
>> should VSI cease operations.
>>
>
> Careful David, I'm getting told off for considering that possibility. :-)
>
>> Is it "honorable behaviour" to expect businesses to just give up? If
>> sos, then I do not understand.
>>
>
> What you should have done is before you committed to a vendor was to
> consider what you would do if that vendor goes bust one day.

That thinking might do away with vendors.

> And to their credit, it looks like everyone is doing this. Why do you
> think there is such a strong negative reaction to the time limited
> production licences ?

I'm confident VSI will be listening to paying customers. Perhaps not so
much to c.o.v.

[Oswald Knoppers]

Op dinsdag 10 augustus 2021 om 01:20:04 UTC+2 schreef Arne Vajhøj:

I thought Oracle was a law firm.

Oswald

[Phillip Helbig (undress to reply)]

In article <serhfr$f1o$1...@gioia.aioe.org>, chris <chris-...@tridac.net> writes:

> Even Oracle make their os's free to use none commercially,
> with again, the money made via support contracts.

Unless there has been a big change, that is NOT true of Rdb. At least
at one time one could download a kit (not the latest) with no support if
one were DEVELOPING a COMMERCIAL application. While that is
non-commercial (as long as it doesn't make money), it is a SMALL subset
of non-commercial use and definitely NOT some sort of hobbyist or
community license.

As for folks wondering why VSI could possibly care about VAX: If the
message that gets through is that (some subset of) VMS users don't
care about being legal, then VSI might think that continuing the
Community License is a bad idea since some people might abuse it in
order to avoid a commercial license. Saying "MY type if illegal use is
justified but some other type is not" doesn't cut it. If people
respected only the laws they agree with, then there would be no need for
laws. Another possibility is that it gives them a reason to stick to
subscription licenses, since non-expiring licenses would allow people to
continue without paying support.

People can debate about how likely various scenarios are. Personally,
I'm concerned that a few loud people give the (hopefully wrong)
impression that most hobbyists don't care about sticking to the rules
and that that could adversely affect the Community License and maybe
even strengthen the case for subscription as opposed to non-expiring
licenses.