Does anyone know if it is still possible to get a hobbyist
license for that?

Web site is up but I get errors when trying requesting a
hobbyist license.

Arne

On Tuesday, September 12, 2023 at 5:02:37 PM UTC-7, Arne Vajhøj wrote:
> Does anyone know if it is still possible to get a hobbyist
> license for that?
>
> Web site is up but I get errors when trying requesting a
> hobbyist license.
I think I knew some years ago that they were discontinuing all product licenses.

But maybe if you ask nice, they will do it.

On 9/12/2023 8:08 PM, gah4 wrote:
> On Tuesday, September 12, 2023 at 5:02:37 PM UTC-7, Arne Vajhøj wrote:
>> Does anyone know if it is still possible to get a hobbyist
>> license for that?
>>
>> Web site is up but I get errors when trying requesting a
>> hobbyist license.
>
> I think I knew some years ago that they were discontinuing all product licenses.
>
> But maybe if you ask nice, they will do it.

https://kednos.com/ says:

<quote>
After many years supplying PL/I compilers to OpenVMS and Tru64 UNIX
users around the world, from October 2016, Kednos will cease trading.
The PL/I compilers, run-time libraries and integration tools will no
longer be updated or supported by Kednos. Licenses for commercial
purposes can still be obtained on an "as is" basis
</quote>

and https://kednos.com/kednos/Hobbyist still exist.

But hobbyist license request fails.

Arne

On 9/12/2023 8:18 PM, Arne Vajhøj wrote:
> On 9/12/2023 8:08 PM, gah4 wrote:
>> On Tuesday, September 12, 2023 at 5:02:37 PM UTC-7, Arne Vajhøj wrote:
>>> Does anyone know if it is still possible to get a hobbyist
>>> license for that?
>>>
>>> Web site is up but I get errors when trying requesting a
>>> hobbyist license.
>> I think I knew some years ago that they were discontinuing all product
>> licenses.
>>
>> But maybe if you ask nice, they will do it.
>
> https://kednos.com/ says:
>
> <quote>
> After many years supplying PL/I compilers to OpenVMS and Tru64 UNIX users around
> the world, from October 2016, Kednos will cease trading. The PL/I compilers,
> run-time libraries and integration tools will no longer be updated or supported
> by Kednos. Licenses for commercial purposes can still be obtained on an "as is"
> basis
> </quote>
>
> and https://kednos.com/kednos/Hobbyist still exist.
>
> But hobbyist license request fails.
>
> Arne
>

I seem to recall that Tom died a few years ago. Don't know if anyone else was
involved.

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

On Tuesday, September 12, 2023 at 5:36:32 PM UTC-7, Dave Froble wrote:

(snip)

> I seem to recall that Tom died a few years ago. Don't know if anyone else was
> involved.

Someone has to be paying for the domain and web server.

On Tue, 2023-09-12 at 20:18 -0400, Arne Vajhøj wrote:
> https://kednos.com/ says:
>
> <quote>
> After many years supplying PL/I compilers to OpenVMS and Tru64 UNIX
> users around the world, from October 2016, Kednos will cease trading.
> The PL/I compilers, run-time libraries and integration tools will no
> longer be updated or supported by Kednos.  Licenses for commercial
> purposes can still be obtained on an "as is" basis
> </quote>
>
> and https://kednos.com/kednos/Hobbyist still exist.
>
> But hobbyist license request fails.

if they are not doing anything with these, they should release it all.
--
Tactical Nuclear Kittens

On Wednesday, September 13, 2023 at 1:01:18 AM UTC-7, Single Stage to Orbit wrote:
> On Tue, 2023-09-12 at 20:18 -0400, Arne Vajhøj wrote:

(snip)

> > and https://kednos.com/kednos/Hobbyist still exist.
> > But hobbyist license request fails.
> if they are not doing anything with these, they should release it all.

Some years ago for a school networking project, I bought a GatorStar
Appletalk gateway.

(By the time most had stopped using such, and they were available
for low prices on eBay. Actually, that was close to the first thing
I bought on eBay.)

The company had released the last version of the software
for free upgrades, and free magic installation codes.
(I don't remember the licensing it had earlier.)

But in that case, the company was still there to do it.

Not so many companies do that, though.

On Wednesday, September 13, 2023 at 9:01:18 AM UTC+1, Single Stage to Orbit wrote:
> On Tue, 2023-09-12 at 20:18 -0400, Arne Vajhøj wrote:
> > https://kednos.com/ says:
> >
> > <quote>
> > After many years supplying PL/I compilers to OpenVMS and Tru64 UNIX
> > users around the world, from October 2016, Kednos will cease trading.
> > The PL/I compilers, run-time libraries and integration tools will no
> > longer be updated or supported by Kednos. Licenses for commercial
> > purposes can still be obtained on an "as is" basis
> > </quote>
> >
> > and https://kednos.com/kednos/Hobbyist still exist.
> >
> > But hobbyist license request fails.
> if they are not doing anything with these, they should release it all.
> --
> Tactical Nuclear Kittens

Not that long ago, I was playing with the Kednos PL/I compiler 3.8-003 for VAX. It does some rather excellent code optimisations but gets a bit weird with procedures that have multiple entry points - I've used them as single-level closures or just encapsulating some locally accessible global state. I don't recall other PL/I compilers being so sensitive during syntax analysis though. The Kednos compiler trips up really badly on the simplest of syntax errors (missing semicolons most obviously) and the fallout is quite spectacular. Although floating types will map appropriately to F, G/D or H representation, I was also a little disappointed that integer handling appears limited to a maximum of 32 bits (31 + sign bit).
It was a nice trip down memory lane.

K

> On Wednesday, September 13, 2023 at 9:01:18 AM UTC+1, Single Stage to Orbit wrote:
> > On Tue, 2023-09-12 at 20:18 -0400, Arne Vajhøj wrote:
> > > https://kednos.com/ says:
> > >
> > > <quote>
> > > After many years supplying PL/I compilers to OpenVMS and Tru64 UNIX
> > > users around the world, from October 2016, Kednos will cease trading.
> > > The PL/I compilers, run-time libraries and integration tools will no
> > > longer be updated or supported by Kednos. Licenses for commercial
> > > purposes can still be obtained on an "as is" basis
> > > </quote>
> > >
> > > and https://kednos.com/kednos/Hobbyist still exist.
> > >
> > > But hobbyist license request fails.
> > if they are not doing anything with these, they should release it all.
> > --
> > Tactical Nuclear Kittens

For example:

randomise: procedure;
declare for$secnds entry(float binary(24)) returns (float binary(24));
declare time float binary(24);
declare seed fixed binary(31) static internal initial(999);
%include mth$random;
time = for$secnds(0e0);
seed = time;
return;
getseed: entry returns(fixed binary(31));
return(seed);
rnd: entry returns(float binary(24));
return(mth$random(seed));
rndrange: entry (a,b) returns(fixed binary(31));
declare (a,b) fixed binary(31);
declare (af,bf) float binary(24);
af=float(a,24); bf=float(b,24);
return (fixed(af + (bf-af+1.0)*mth$random(seed),31));
end randomise;

K

Arne Vajh??j <arne@vajhoej.dk> wrote:
> Does anyone know if it is still possible to get a hobbyist
> license for that?
>

Yes, it is still possible.

> Web site is up but I get errors when trying requesting a
> hobbyist license.
>

There were two problems. The first (which is fixed) related
to some instrafstructure being moved around.

The second (license mail server appearing in Spamhaus) is
begin fixed. Unfortunately with moving things around there
was a PTR problem and the HELO banner does not match.

Hopefully all should be resolved by tomorrow.

Regards, Tim.

gah4 <gah4@u.washington.edu> wrote:
> On Tuesday, September 12, 2023 at 5:02:37???PM UTC-7, Arne Vajh??j wrote:
>> Does anyone know if it is still possible to get a hobbyist
>> license for that?
>>
>> Web site is up but I get errors when trying requesting a
>> hobbyist license.
>
> I think I knew some years ago that they were discontinuing all product licenses.
>

Kednos did cease to operate a few years ago. Tom Linden did pass not
too long after that. It took a while, but the IP has now moved to
new hands and work is being done to port to x86-64.

> But maybe if you ask nice, they will do it.
>

Licenses are still available. Kednos has gone, but the compilers
have not.

PS Apologies to anyone who received a mail reply. It has been a
very long time since using a news reader and reply rather than
followup was my downfall :-0

On 9/13/2023 1:35 PM, Tim Sneddon wrote:
> gah4 <gah4@u.washington.edu> wrote:
>> On Tuesday, September 12, 2023 at 5:02:37???PM UTC-7, Arne Vajh??j wrote:
>>> Does anyone know if it is still possible to get a hobbyist
>>> license for that?
>>>
>>> Web site is up but I get errors when trying requesting a
>>> hobbyist license.
>>
>> I think I knew some years ago that they were discontinuing all product licenses.
>>
>
> Kednos did cease to operate a few years ago. Tom Linden did pass not
> too long after that. It took a while, but the IP has now moved to
> new hands and work is being done to port to x86-64.

Hey. Are you saying that PL/I will (at some point in time)
be available for VMS x86-64?

If yes - are you at liberty to elaborate a bit?

Arne

Single Stage to Orbit <alex.buell@munted.eu> wrote:
> On Tue, 2023-09-12 at 20:18 -0400, Arne Vajh??j wrote:
>> https://kednos.com/??says:
>>
>> <quote>
>> After many years supplying PL/I compilers to OpenVMS and Tru64 UNIX
>> users around the world, from October 2016, Kednos will cease trading.
>> The PL/I compilers, run-time libraries and integration tools will no
>> longer be updated or supported by Kednos.?? Licenses for commercial
>> purposes can still be obtained on an "as is" basis
>> </quote>
>>
>> and https://kednos.com/kednos/Hobbyist??still exist.
>>
>> But hobbyist license request fails.
>
> if they are not doing anything with these, they should release it all.

Thankfully in this case something is happening and the compiler
IP has been transferred to new owners.

However, releasing everything to the public domain is not an
option. The compilers at Kednos have been used to produce just
about every non-IBM PL/I compiler around. There has been quite
a bit of sharing over the years between Kednos (previously
Uniprise, Language Processors and Translation Systems) and so
simply releasing it just isn't an option.

Regards, Tim.

Arne Vajh??j <arne@vajhoej.dk> wrote:
> On 9/13/2023 1:35 PM, Tim Sneddon wrote:
>> gah4 <gah4@u.washington.edu> wrote:
>>> On Tuesday, September 12, 2023 at 5:02:37???PM UTC-7, Arne Vajh??j wrote:
>>>> Does anyone know if it is still possible to get a hobbyist
>>>> license for that?
>>>>
>>>> Web site is up but I get errors when trying requesting a
>>>> hobbyist license.
>>>
>>> I think I knew some years ago that they were discontinuing all product licenses.
>>>
>>
>> Kednos did cease to operate a few years ago. Tom Linden did pass not
>> too long after that. It took a while, but the IP has now moved to
>> new hands and work is being done to port to x86-64.
>
> Hey. Are you saying that PL/I will (at some point in time)
> be available for VMS x86-64?

Yes, that is correct.

>
> If yes - are you at liberty to elaborate a bit?
>

There is currently work underway to get PL/I to GEM BL50
on Alpha. Unfortunately, PL/I was stuck at BL26 for a long
time.

This has been a slow process, but is starting to yield
results.

When the Alpha update is verified correct against the
regression test library a new Alpha kit (V5.0) will be
released. My guess is that it will be in Jan 2024.

Regards, Tim.

On 9/13/2023 1:48 PM, Tim Sneddon wrote:
> Arne Vajh??j <arne@vajhoej.dk> wrote:
>> Hey. Are you saying that PL/I will (at some point in time)
>> be available for VMS x86-64?
>
> Yes, that is correct.
>
>>
>> If yes - are you at liberty to elaborate a bit?
>>
>
> There is currently work underway to get PL/I to GEM BL50
> on Alpha. Unfortunately, PL/I was stuck at BL26 for a long
> time.
>
> This has been a slow process, but is starting to yield
> results.
>
> When the Alpha update is verified correct against the
> regression test library a new Alpha kit (V5.0) will be
> released. My guess is that it will be in Jan 2024.

And then you need to get it to VMS x86-64.

Is the plan to make an agreement with VSI and use the
same GEM to LLVM thing they are using?

Arne

On Wednesday, September 13, 2023 at 6:37:49 AM UTC-7, cao...@pitbulluk.org wrote:

(snip)

> Not that long ago, I was playing with the Kednos PL/I compiler 3.8-003 for VAX.
> It does some rather excellent code optimisations but gets a bit weird with procedures
> that have multiple entry points - I've used them as single-level closures or just
> encapsulating some locally accessible global state.
> I don't recall other PL/I compilers being so sensitive during syntax analysis though.

I don't know anything about the actual compiler at all. Recursive descent compilers
are well known for failing in a strange way with syntax errors.

> The Kednos compiler trips up really badly on the simplest of syntax errors
> (missing semicolons most obviously) and the fallout is quite spectacular.

The PL/I compiler I used most over the years, is the IBM PL/I(F) compiler
that dates back to the 1960's. I do remember an error message like
"SEMICOLON MISSING, ONE INSERTED" where it inserts one into the
internal representation and continues on. Often with strange results.

If I can get a hobbyist license for the VAX compiler, I will try running it..

> Although floating types will map appropriately to F, G/D or H representation,
> I was also a little disappointed that integer handling appears limited to a
> maximum of 32 bits (31 + sign bit).
> It was a nice trip down memory lane.

That would agree with VAX. Though following IBM, and the VAX hardware,
it should have FIXED DEC(15,0).

Does Alpha have 64 bit multiply and divide?

I even forget now, does x86-64 hardware have multiply and divide with 128 bit
product and dividend?

On 9/13/2023 3:13 PM, gah4 wrote:
> On Wednesday, September 13, 2023 at 6:37:49 AM UTC-7, cao...@pitbulluk.org wrote:
>> Although floating types will map appropriately to F, G/D or H representation,
>> I was also a little disappointed that integer handling appears limited to a
>> maximum of 32 bits (31 + sign bit).
>> It was a nice trip down memory lane.
>
> That would agree with VAX. Though following IBM, and the VAX hardware,
> it should have FIXED DEC(15,0).
>
> Does Alpha have 64 bit multiply and divide?

In instruction set?

Multiply: yes.

Division: no. But obviously you can divide two 64 bit integers in your
favorite HLL.

> I even forget now, does x86-64 hardware have multiply and divide with 128 bit
> product and dividend?

I don't think so.

Arne

On Wed, 2023-09-13 at 17:43 +0000, Tim Sneddon wrote:
> > if they are not doing anything with these, they should release it
> > all.
>
> Thankfully in this case something is happening and the compiler
> IP has been transferred to new owners.
>
> However, releasing everything to the public domain is not an
> option.  The compilers at Kednos have been used to produce just
> about every non-IBM PL/I compiler around.  There has been quite
> a bit of sharing over the years between Kednos (previously
> Uniprise, Language Processors and Translation Systems)  and so
> simply releasing it just isn't an option.

Still, at least they are doing things with it now.
--
Tactical Nuclear Kittens

On Wednesday, September 13, 2023 at 12:28:45 PM UTC-7, Arne Vajhøj wrote:

(snip, I wrote)

> > Does Alpha have 64 bit multiply and divide?

> In instruction set?

> Multiply: yes.

With 128 bit product?

> Division: no. But obviously you can divide two 64 bit integers in your
> favorite HLL.

But PL/I allows for a scaling factor for FIXED BIN values.
That often requires a shift before the divide, so you really want a double
length dividend and product for divide and multiply instructions.

> > I even forget now, does x86-64 hardware have multiply and divide with 128 bit
> > product and dividend?

> I don't think so.

It has been usual for a long time, for hardware to have multiply and divide with
double length product and dividend. Many algorithms depend on that, though few
HLLs have a way to do it. (Other than call an assembly language routine.)

It seems that 64 bit processors don't all do it.

On 9/13/23 12:52 PM, Arne Vajhøj wrote:
> On 9/13/2023 1:48 PM, Tim Sneddon wrote:
>> Arne Vajh??j <arne@vajhoej.dk> wrote:
>>> Hey. Are you saying that PL/I will (at some point in time)
>>> be available for VMS x86-64?
>>
>> Yes, that is correct.
>>
>>>
>>> If yes - are you at liberty to elaborate a bit?
>>>
>>
>> There is currently work underway to get PL/I to GEM BL50
>> on Alpha. Unfortunately, PL/I was stuck at BL26 for a long
>> time.
>>
>> This has been a slow process, but is starting to yield
>> results.
>>
>> When the Alpha update is verified correct against the
>> regression test library a new Alpha kit (V5.0) will be
>> released. My guess is that it will be in Jan 2024.
>
> And then you need to get it to VMS x86-64.
>
> Is the plan to make an agreement with VSI and use the
> same GEM to LLVM thing they are using?

I'm pretty sure that would be the only game in town without
reimplementing the whole thing to use LLVM directly.

This is interesting news. Wasn't it Volkswagen that could never move to
Itanium because of no PL/I because of disagreements over who would
update things to current GEM? I never expected VMS on x86 to do better
than Itanium as far as preserving availability of old software, but this
may be one case where it does.

On 9/13/2023 4:53 PM, gah4 wrote:
> On Wednesday, September 13, 2023 at 12:28:45 PM UTC-7, Arne Vajhøj wrote:
> (snip, I wrote)
>>> Does Alpha have 64 bit multiply and divide?
>
>> In instruction set?
>
>> Multiply: yes.
>
> With 128 bit product?

No.

>> Division: no. But obviously you can divide two 64 bit integers in your
>> favorite HLL.
>
> But PL/I allows for a scaling factor for FIXED BIN values.
> That often requires a shift before the divide, so you really want a double
> length dividend and product for divide and multiply instructions.
>
>>> I even forget now, does x86-64 hardware have multiply and divide with 128 bit
>>> product and dividend?
>
>> I don't think so.
>
> It has been usual for a long time, for hardware to have multiply and divide with
> double length product and dividend. Many algorithms depend on that, though few
> HLLs have a way to do it. (Other than call an assembly language routine.)
>
> It seems that 64 bit processors don't all do it.

Big integers in software is pretty standard today. You can get
128 or 245 or 512 or 1024 bit integers or whatever if you want to.
In software. And on todays hardware it will be pretty fast anyway.

Arne

On Wednesday, September 13, 2023 at 5:53:20 PM UTC-7, Arne Vajhøj wrote:

(snip, I wrote)
> > It has been usual for a long time, for hardware to have multiply and divide with
> > double length product and dividend. Many algorithms depend on that, though few
> > HLLs have a way to do it. (Other than call an assembly language routine..)
> > It seems that 64 bit processors don't all do it.

> Big integers in software is pretty standard today. You can get
> 128 or 245 or 512 or 1024 bit integers or whatever if you want to.
> In software. And on todays hardware it will be pretty fast anyway.
I suppose so.
It is reasonable to expect HLLs to support what the hardware supports.

I remember in the TeX documentation for the program, TeX has (had)
Pascal programs to compute the product and quotient of 32 bit values
with 16 bits after the binary point. Very easy if you have the double length
instructions, not at all easy in Pascal.

He suggests assembly versions of those two operations.

But computers were slower then.

If you are using them to implement multiple precision arithmetic, you
want to use the largest ones supported by the hardware. But yes,
often enough they are fast enough.

On 9/13/2023 9:06 PM, gah4 wrote:
> On Wednesday, September 13, 2023 at 5:53:20 PM UTC-7, Arne Vajhøj wrote:
>
> (snip, I wrote)
>>> It has been usual for a long time, for hardware to have multiply and divide with
>>> double length product and dividend. Many algorithms depend on that, though few
>>> HLLs have a way to do it. (Other than call an assembly language routine.)
>
>>> It seems that 64 bit processors don't all do it.
>
>> Big integers in software is pretty standard today. You can get
>> 128 or 245 or 512 or 1024 bit integers or whatever if you want to.
>> In software. And on todays hardware it will be pretty fast anyway.
>
> I suppose so.
> It is reasonable to expect HLLs to support what the hardware supports.
>
> I remember in the TeX documentation for the program, TeX has (had)
> Pascal programs to compute the product and quotient of 32 bit values
> with 16 bits after the binary point. Very easy if you have the double length
> instructions, not at all easy in Pascal.
>
> He suggests assembly versions of those two operations.
>
> But computers were slower then.
>
> If you are using them to implement multiple precision arithmetic, you
> want to use the largest ones supported by the hardware. But yes,
> often enough they are fast enough.

Here is some C code using GMP library:

#include <stdio.h>
#include <string.h>
#include <time.h>

#include <gmp.h>

#define N1 1000000000
#define N2 10

int main(int argc, char *argv[])
{ /* setup */
mpz_t a, b, c;
mpz_init_set_str(a, "123456789123456789123456789", 10);
mpz_init_set_str(b, "987654321987654321987654321", 10);
mpz_init(c);
/* check functionality */
mpz_mul(c, a, b);
mpz_out_str(stdout, 10, c);
printf("\n");
mpz_div(c, c, b);
mpz_out_str(stdout, 10, c);
printf("\n");
/* check performance */
time_t t1 = time(NULL);
for(int j = 0; j < N2; j++)
{
for(int i = 0; i < N1; i++)
{
mpz_mul(c, a, b);
}
}
time_t t2 = time(NULL);
printf("%.0f bigmuls per second\n", N1 * 1.0 * N2 / (t2 - t1));
/* cleanup */
mpz_clear(a);
mpz_clear(b);
mpz_clear(c);
return 0;
}

It does around 100 million bigmuls per second here.

Arne

On 9/13/2023 10:03 PM, Arne Vajhøj wrote:
> On 9/13/2023 9:06 PM, gah4 wrote:
>> On Wednesday, September 13, 2023 at 5:53:20 PM UTC-7, Arne Vajhøj wrote:
>> (snip, I wrote)
>>>> It has been usual for a long time, for hardware to have multiply and
>>>> divide with
>>>> double length product and dividend. Many algorithms depend on that,
>>>> though few
>>>> HLLs have a way to do it. (Other than call an assembly language
>>>> routine.)
>>>> It seems that 64 bit processors don't all do it.
>>
>>> Big integers in software is pretty standard today. You can get
>>> 128 or 245 or 512 or 1024 bit integers or whatever if you want to.
>>> In software. And on todays hardware it will be pretty fast anyway.
>> I suppose so.
>> It is reasonable to expect HLLs to support what the hardware supports.
>>
>> I remember in the TeX documentation for the program, TeX has (had)
>> Pascal programs to compute the product and quotient of 32 bit values
>> with 16 bits after the binary point.  Very easy if you have the double
>> length
>> instructions, not at all easy in Pascal.
>>
>> He suggests assembly versions of those two operations.
>>
>> But computers were slower then.
>>
>> If you are using them to implement multiple precision arithmetic, you
>> want to use the largest ones supported by the hardware.  But yes,
>> often enough they are fast enough.
>
> Here is some C code using GMP library:

> It does around 100 million bigmuls per second here.

Based on some very old measurements I believe a VAX 780
could do around 0.5 million MULL3 instructions per second.

HW has improved over 45 years ...

Arne

Arne Vajh??j <arne@vajhoej.dk> wrote:
> On 9/13/2023 1:48 PM, Tim Sneddon wrote:
>> Arne Vajh??j <arne@vajhoej.dk> wrote:
>>> Hey. Are you saying that PL/I will (at some point in time)
>>> be available for VMS x86-64?
>>
>> Yes, that is correct.
>>
>>>
>>> If yes - are you at liberty to elaborate a bit?
>>>
>>
>> There is currently work underway to get PL/I to GEM BL50
>> on Alpha. Unfortunately, PL/I was stuck at BL26 for a long
>> time.
>>
>> This has been a slow process, but is starting to yield
>> results.
>>
>> When the Alpha update is verified correct against the
>> regression test library a new Alpha kit (V5.0) will be
>> released. My guess is that it will be in Jan 2024.
>
> And then you need to get it to VMS x86-64.
>

Correct.

> Is the plan to make an agreement with VSI and use the
> same GEM to LLVM thing they are using?

Correct again. The "thing" is G2L (GEM-to-LLVM).

Regards, Tim.