Micro Focus to be acquired by Open Text

[Neil Rieck]

Back in the day after HP split into HP and HPE, a lot of HPE software products went to Micro Focus as Micro Focus merged with "HPE Software".

Here's the final blurb from 2017:
https://www.microfocus.com/about/press-room/article/2017/micro-focus-completes-merger-with-hpe-software/

I just read that Micro Focus is being acquired by Open Text:
https://www.itworldcanada.com/article/open-text-to-acquire-micro-focus-in-all-cash-us6-billion-deal/499781

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net

[Johnny Billquist]

I still wonder if there are any PDP-11 layered software sources still at
HP(E) somewhere. Officially much went to Mentec when things were sold
there, but Mentec's copies seems to have been lost. And also, Mentec
pretty much didn't any further releases of any of the layered software,
so if something were still around at HP(E), that would be pretty much up
to date.

What was/is the story with VSI? Did all the layered products also move
over, or did HP(E) keep some of it, and that's what's included here?

Johnny

[Robert A. Brooks]

On 8/29/2022 8:21 AM, Johnny Billquist wrote:

> What was/is the story with VSI? Did all the layered products also
> move over, or did HP(E) keep some of it, and that's what's included
> here?

As far as I know, we (VSI) got all the layered products that had been supported
by the VMS infrastructure at HPE.

Products like DEC/EDI, which were supported at the end by a non-engineering group, were
not transferred to VSI.

I'm largely responsible for all the non-compiler layered products at VSI.

--
-- Rob

[Marc Van Dyck]

Robert A. Brooks wrote :

Ah, you'll do ACMS then ? How is it going ?

--
Marc Van Dyck

[Robert A. Brooks]

Well, we've released VSI ACMS for Alpha and IA64, and it's in use at various customer sites.

For X86_64, we need CDD and Rdb, which are used in the build of ACMS.

I will probably make an effort to build the non-Rdb-dependent parts of ACMS soon.

--
-- Rob

[Dave Froble]

So, you'll apply for ISV status with Oracle, if they have such a program?

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

[Arne Vajhøj]

On 8/29/2022 10:51 AM, Dave Froble wrote:
> On 8/29/2022 9:31 AM, Robert A. Brooks wrote:
>> For X86_64, we need CDD and Rdb, which are used in the build of ACMS.
>>
>> I will probably make an effort to build the non-Rdb-dependent parts of
>> ACMS soon.
>
> So, you'll apply for ISV status with Oracle, if they have such a program?

Oracle products usually are free for development even without
registering as ISV.

Arne

[Arne Vajhøj]

On 8/29/2022 8:03 AM, Neil Rieck wrote:
> Back in the day after HP split into HP and HPE, a lot of HPE software products went to Micro Focus as Micro Focus merged with "HPE Software".
>
> Here's the final blurb from 2017:
> https://www.microfocus.com/about/press-room/article/2017/micro-focus-completes-merger-with-hpe-software/
>
> I just read that Micro Focus is being acquired by Open Text:
> https://www.itworldcanada.com/article/open-text-to-acquire-micro-focus-in-all-cash-us6-billion-deal/499781

AFAIK HPE software did not include anything for VMS.

I saw the acquisition note too.

One company with a problematic product suite buying another
company with a problematic product suite.

OpenText has 3 ECM's in a market where customers prefer MS SharePoint.

Micro Focus has a bunch of non attractive stuff as well:
the Borland ALM stuff (customers prefer open source or cheap
cloud today), SUSE Linux (Redhat, Redhat clones, Ubuntu,
Debian etc. dominate that market), the infamous Autonomy
stuff from HPE software.

The only product with a good reputation must be MF Cobol.

Arne

[Marc Van Dyck]

Robert A. Brooks explained :

Wasn't a replacement for CDD, without the RDB dependency, discussed at
some point ? I vaguely remember something but not the details.

--
Marc Van Dyck

[Hein RMS van den Heuvel]

On Tuesday, August 30, 2022 at 6:02:08 AM UTC-4, Marc Van Dyck wrote:
> Robert A. Brooks explained :

> >
> > For X86_64, we need CDD and Rdb, which are used in the build of ACMS.
> >
> > I will probably make an effort to build the non-Rdb-dependent parts of ACMS
> > soon.
> Wasn't a replacement for CDD, without the RDB dependency, discussed at
> some point ? I vaguely remember something but not the details.
>
> --
> Marc Van Dyck

The old CDD, without relational backend, while clunky, did just fine for Datatrieve, ACMS, TDMS, DECforms, Cobol, Basic,...
Bring it back!

Hein

[Stephen Hoffman]

On 2022-08-30 10:02:03 +0000, Marc Van Dyck said:

> Wasn't a replacement for CDD, without the RDB dependency, discussed at
> some point ? I vaguely remember something but not the details.

Yes. That CDD work was discussed. Datatrieve did add enough support to
allow that product to function without Oracle CDD/Repository installed,
too.

As for Micro Focus, they had merged with Attachmate some years ago, and
Attachmate had Reflection terminal emulator support and X Window System
server support,


--
Pure Personal Opinion | HoffmanLabs LLC

[Jan-Erik Söderholm]

And Attachmate got Reflection when they marged with WRQ. They had
the emulator "Extra!" since before, which happens to be the main
emulator at my customer (today run from Citrix servers).

[Arne Vajhøj]

I always liked Reflection.

But the reality today is that putty is good enough for most.

Arne

[Jan-Erik Söderholm]

Sure. But Reflection was still "better"... :-)

Putty lacks the 7-bit national character sets.
Both Reflection and Extra can handle those.

I had some Reflection files (could have been 2.7 or 7.2,
I do not remember the version) that could just be copied
to some Windows system without running some "installation"
program and just run.

Even Rocket Software sells some terminal emulation products.
https://www.rocketsoftware.com/product-categories/terminal-emulation

And, just FYI, Rocket software was co-founded by Johan Gedda, who
today is also the Chairman of, and main investor in, VSI.
https://www.linkedin.com/in/johanm4/

[Robert A. Brooks]

On 8/31/2022 6:04 PM, Jan-Erik Söderholm wrote:
> Den 2022-08-31 kl. 23:32, skrev Arne Vajhøj:

>>
>> I always liked Reflection.
>>
>> But the reality today is that putty is good enough for most.
>>
>> Arne
>>
>>
>
> Sure. But Reflection was still "better"... :-)

Sorry; you both lose.

PowerTerm is the best.

--
-- Rob

[Arne Vajhøj]

On 8/31/2022 6:04 PM, Jan-Erik Söderholm wrote:
> Den 2022-08-31 kl. 23:32, skrev Arne Vajhøj:
>> On 8/31/2022 2:07 AM, Jan-Erik Söderholm wrote:
>>> Den 2022-08-31 kl. 00:19, skrev Stephen Hoffman:
>>>> On 2022-08-30 10:02:03 +0000, Marc Van Dyck said:
>>>> As for Micro Focus, they had merged with Attachmate some years ago,
>>>> and Attachmate had Reflection terminal emulator support and X Window
>>>> System server support,
>>>
>>> And Attachmate got Reflection when they marged with WRQ. They had
>>> the emulator "Extra!" since before, which happens to be the main
>>> emulator at my customer (today run from Citrix servers).
>>
>> I always liked Reflection.
>>
>> But the reality today is that putty is good enough for most.
>

> Sure. But Reflection was still "better"... :-)
>
> Putty lacks the 7-bit national character sets.
> Both Reflection and Extra can handle those.

Putty doesn't handle soft fonts either.

But ...

Arne

[Dave Froble]

There is that "good enough" shit again ...

Whatever happened to "strive for perfection"?

[Arne Vajhøj]

On 8/31/2022 7:18 PM, Dave Froble wrote:
> On 8/31/2022 5:32 PM, Arne Vajhøj wrote:
>> On 8/31/2022 2:07 AM, Jan-Erik Söderholm wrote:
>>> Den 2022-08-31 kl. 00:19, skrev Stephen Hoffman:
>>>> On 2022-08-30 10:02:03 +0000, Marc Van Dyck said:
>>>> As for Micro Focus, they had merged with Attachmate some years ago, and
>>>> Attachmate had Reflection terminal emulator support and X Window System
>>>> server support,
>>>
>>> And Attachmate got Reflection when they marged with WRQ. They had
>>> the emulator "Extra!" since before, which happens to be the main
>>> emulator at my customer (today run from Citrix servers).
>>
>> I always liked Reflection.
>>
>> But the reality today is that putty is good enough for most.
>

> There is that "good enough" shit again ...
>
> Whatever happened to "strive for perfection"?

If striving for perfection doesn't cost anything, then
it is fine.

But if it cost then one evaluate whether the perfectness
is worth the money.

Arne

[David Goodwin]

For odd character sets and other things putty doesn't do or doesn't do well enough,
C-Kermit for Windows may be an option. This was known as Kermit 95 back when it
was a commercial product and it still retains most of its features. The new SSH
implementation is still very new though; the next beta in a fortnight or so should
improve that somewhat.

Supported character sets: https://kermitproject.org/k95manual/charsets.html

[Johnny Billquist]

putty is acceptable, I guess. But at least in one situation, it differs
from how a VT-terminal behaves, and the developer preferred to keep it
that way after I pointed it out. Several other incompatibilities I
pointed out were fixed, though. So not totally unreasonable, but I'm not
entirely happy when there are deviations.

Johnny

[Simon Clubley]

On 2022-08-31, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
> Den 2022-08-31 kl. 23:32, skrev Arne Vajhøj:
>>
>> I always liked Reflection.
>>
>> But the reality today is that putty is good enough for most.
>>
>

> Sure. But Reflection was still "better"... :-)
>
> Putty lacks the 7-bit national character sets.
> Both Reflection and Extra can handle those.
>

But haven't we moved on from this in the same way as we have moved on
from requiring DEC keyboards instead of PC keyboards to access VMS
systems ?

Shouldn't VMS systems be generating code sets that are compatible
with how code systems work today, not how they worked 30+ years ago ?

How do the Nordic special characters get represented in the 7-bit
character sets anyway or do they use 8-bits for some of the characters ?

I can't think of any Swedish places with any special characters, but
how would the following places have been represented in the old days ?

Flåm
Bodø

In ISO-8859-1, the special characters in the above are encoded as 8-bit
characters (and are broken as expected when displayed using UTF-8 :-)).

What positions would the special characters above have occupied in the
old days ?

For the benefit of anyone whose terminal emulator messes up the above,
this is a dump/record of the file I created with those above examples:

Record number 1 (00000001), 5 (0005) bytes, RFA(0001,0000,0000)

6D E56C4609 .Flåm........... 000000

Record number 2 (00000002), 5 (0005) bytes, RFA(0001,0000,0008)

F8 646F4209 .Bodø........... 000000

Simon.

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

[Johnny Billquist]

What do VMS have to do with this? This might as well be very application
specific. And what people are talking about are the 7-bit national
character sets, which obviously cannot be ISO-8859-x since they are all
8-bit character sets.

In fact, what we're talking about (if we talk specifically about
Swedish) is ISO-646-SE, where the characters []\{}| are used for ÄÅÖäåö.

And if you happen to run an application that is using ISO-646-whatever,
then you'd better have a terminal that can display it properly as well.
All DEC VT terminals can.

Johnny

[Stephen Hoffman]

On 2022-09-01 18:04:31 +0000, Simon Clubley said:

> But haven't we moved on from this in the same way as we have moved on
> from requiring DEC keyboards instead of PC keyboards to access VMS
> systems ?
>
> Shouldn't VMS systems be generating code sets that are compatible with
> how code systems work today, not how they worked 30+ years ago ?

If you're maintaining retired-in-place apps into app oblivion or are
maintaining apps until staff retirement, platform changes—such as added
character encoding, or widening the available keyboard support—just
aren't necessary, and often aren't desirable.

If you're working on new app deployments or on wholly new apps, sure,
the existing implementation details and limits are somewhere between
difficult and annoying, and more effort.

If you're unwary enough to stray outside of DEC MCS / mostly ISO 8859-1
/ Latin-1 with your app.

Character encoding is endemic; in DCL, APIs, filenames including UTF-8
and sorting-related discussions, RFAs, FIDs, file sizes.

The fun awaiting here with increased storage sizes and storage
capacities and storage addressing and storage features and encodings is
~endless.

ODS-5 / EFS support has not yet landed in many apps, 64-bit storage
addressing, and I've had difficulty even finding whatever doc was made
available for the UTF-8 support that snuck out.

Descriptors—arguably an ancestral form of an object—presently lack any
support for language and character encoding storage.

This is also a completely self-solving problem, of course. Albeit slowly.

[Jan-Erik Söderholm]

Den 2022-09-01 kl. 21:06, skrev Johnny Billquist:
> On 2022-09-01 20:04, Simon Clubley wrote:
>> On 2022-08-31, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>>> Den 2022-08-31 kl. 23:32, skrev Arne Vajhøj:
>>>>
>>>> I always liked Reflection.
>>>>
>>>> But the reality today is that putty is good enough for most.
>>>>
>>>
>>> Sure. But Reflection was still "better"... :-)
>>>
>>> Putty lacks the 7-bit national character sets.
>>> Both Reflection and Extra can handle those.
>>>
>>
>> But haven't we moved on from this in the same way as we have moved on
>> from requiring DEC keyboards instead of PC keyboards to access VMS
>> systems ?
>>
>> Shouldn't VMS systems be generating code sets that are compatible
>> with how code systems work today, not how they worked 30+ years ago ?
>>
>> How do the Nordic special characters get represented in the 7-bit
>> character sets anyway or do they use 8-bits for some of the characters ?

Just read up a little.

https://en.wikipedia.org/wiki/National_Replacement_Character_Set

>>
>> I can't think of any Swedish places with any special characters, but
>> how would the following places have been represented in the old days ?
>>
>>     Flåm
>>     Bodø
>>
>> In ISO-8859-1, the special characters in the above are encoded as 8-bit
>> characters (and are broken as expected when displayed using UTF-8 :-)).

Yes, in ISO-8859-1, these are in the upper half of the 8-bit set.
And in UTF8 they are dual byte characters, of course.

But that doesn't help those having a lot of applications
having hard-coded text output in 7-bit national char sets.

>>
>> What positions would the special characters above have occupied in the
>> old days ?

https://en.wikipedia.org/wiki/National_Replacement_Character_Set

>>
>> For the benefit of anyone whose terminal emulator messes up the above,
>> this is a dump/record of the file I created with those above examples:
>>
>> Record number 1 (00000001), 5 (0005) bytes, RFA(0001,0000,0000)
>>
>>                           6D E56C4609 .Flåm........... 000000
>>
>> Record number 2 (00000002), 5 (0005) bytes, RFA(0001,0000,0008)
>>
>>                           F8 646F4209 .Bodø........... 000000
>

That is not created using 7-bit char sets. If you look up the codes
E5 and F8 you will find them in the ISO-8859-1 8-bit char set, not
in the 7-bit char-set.

https://sv.wikipedia.org/wiki/ISO/IEC_8859-1

> What do VMS have to do with this? This might as well be very application
> specific. And what people are talking about are the 7-bit national
> character sets, which obviously cannot be ISO-8859-x since they are all
> 8-bit character sets.
>
> In fact, what we're talking about (if we talk specifically about Swedish)
> is ISO-646-SE, where the characters []\{}| are used for ÄÅÖäåö.
>
> And if you happen to run an application that is using ISO-646-whatever,
> then you'd better have a terminal that can display it properly as well.
> All DEC VT terminals can.
>
>   Johnny

Jonny is of course completely right here.
Simon is lacking knowledge the Nordic ASCII 7-bit chat sets.

Extra (and Reflection) terminal emulators handles this just fine.
Putty does not, there is no 7-bit character sets at all there.

There was a time when having parity on any serial communication
was "standard", and that limitied you to 7-bit character sets.
The 8'th bit was the parity bit.

[Arne Vajhøj]

On 9/1/2022 2:04 PM, Simon Clubley wrote:
> On 2022-08-31, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>> Den 2022-08-31 kl. 23:32, skrev Arne Vajhøj:
>>> I always liked Reflection.
>>>
>>> But the reality today is that putty is good enough for most.
>>
>> Sure. But Reflection was still "better"... :-)
>>
>> Putty lacks the 7-bit national character sets.
>> Both Reflection and Extra can handle those.
>
> But haven't we moved on from this in the same way as we have moved on
> from requiring DEC keyboards instead of PC keyboards to access VMS
> systems ?
>
> Shouldn't VMS systems be generating code sets that are compatible
> with how code systems work today, not how they worked 30+ years ago ?
>
> How do the Nordic special characters get represented in the 7-bit
> character sets anyway or do they use 8-bits for some of the characters ?
>
> I can't think of any Swedish places with any special characters, but
> how would the following places have been represented in the old days ?
>
> Flåm
> Bodø
>
> In ISO-8859-1, the special characters in the above are encoded as 8-bit
> characters (and are broken as expected when displayed using UTF-8 :-)).
>
> What positions would the special characters above have occupied in the
> old days ?

First the background info about what this is all about
------------------------------------------------------

ANSI ASCII ~ ISO-646 ~ ECMA-6 is a character set going back to
the mid 60's. It only define 0-127 so it can work with 7 bit
comm.

128 character was not enough to cover all western languages,
so there were actually multiple mappings defined:

ISO-646 for English
ISO-646-DK for Danish
ISO-646-SE for Swedish
etc.

The differences was related to only a few characters.

Most relevant for Danes and Swedes are:

0x5B 0x5C 0x5D 0x7B 0x7C 0x7D
ISO-646 [ \ ] { | }
ISO-646-DK Æ Ø Å æ ø å
ISO-646-SE Ä Ö Å ä ö å

(I hope those 8 byte characters goes through)

In DEC VT terminals these "national variants" became
known as NRCS (National Replacement Character Sets).

Then is this stuff obsolete?
----------------------------

With the arrival of 8 bit character sets in the form
of DECMCS ~ ISO-8859 ~ ECMA-94 (~ CP-125x) in the mid 80's then
those national variants became obsolete.

(which was a blessing for all programmers as the values
changed in the national variants are widely used in
programming languages !)

My personal experience is that the national variants
dropped out of mainstream IT during the 90's.

So an application using those national variants should
probably have been rewritten sometime in the mid 90's
to use ISO-8859 (and rewritten again late 00's
to use UTF-8).

But as we all know then applications does not always
get rewritten.

And this would not just be a code change but also
a data conversion.

So I am not surprised that there still exist VMS
applications using national variants of ASCII.

That is how the real world is.

Arne

[Phillip Helbig (undress to reply)]

In article <631149a3$0$702$1472...@news.sunsite.dk>,

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:

> First the background info about what this is all about
> ------------------------------------------------------

Good summary.

> ANSI ASCII ~ ISO-646 ~ ECMA-6 is a character set going back to
> the mid 60's. It only define 0-127 so it can work with 7 bit
> comm.
>
> 128 character was not enough to cover all western languages,
> so there were actually multiple mappings defined:
>
> ISO-646 for English
> ISO-646-DK for Danish
> ISO-646-SE for Swedish
> etc.
>
> The differences was related to only a few characters.
>
> Most relevant for Danes and Swedes are:
>
> 0x5B 0x5C 0x5D 0x7B 0x7C 0x7D
> ISO-646 [ \ ] { | }

> ISO-646-DK à à à Ê Þ å
> ISO-646-SE à à à À ö å

>
> (I hope those 8 byte characters goes through)

I was going to ask "what 8-byte characters?" since I didn't see any when
reading your post. Now, on a VT320 using NEWSRDR, I see them when
composing this post in EDT, but probably not as you intended me to see
them.

> In DEC VT terminals these "national variants" became
> known as NRCS (National Replacement Character Sets).
>
> Then is this stuff obsolete?
> ----------------------------
>
> With the arrival of 8 bit character sets in the form
> of DECMCS ~ ISO-8859 ~ ECMA-94 (~ CP-125x) in the mid 80's then
> those national variants became obsolete.

In general, yes. But considering just VMS and the applications which
comes with it, one is essentially stuck with MCS. Yes, I have a script
which converts "pseudocode" text (using two-character mnemonics which
otherwise don't occur in the language in question) to the corresponding
8-bit characters for a particular encoding, then specify that encoding
for the resulting HTML page. I can thus create a document in, say,
Serbian using Cyrillic letters on VMS and it will look as it should when
viewed in or printed from a web browser. But that's just me. :-)

I am a heavy user of LaTeX, and of VMS. At some point some fork of TeX
allowed one to input 8-bit characters, e.g. ä instead of \"a, but there
is no easy way to do that on VMS in general (especially if one wants to
read the source). (There are some advantages to using the 8-bit
characters directly.)

> (which was a blessing for all programmers as the values
> changed in the national variants are widely used in
> programming languages !)
>
> My personal experience is that the national variants
> dropped out of mainstream IT during the 90's.

I remember getting email from Sweden using the Swedish replacement
characters around 1993. I wrote an EDT macro to globally search and
replace them in both directions to make reading and writing email to
that particular Swedish colleague easier.

[Jan-Erik Söderholm]

As Philip also noted, this is a very good summary that even
Simon should be able to understand... :-)

I do not think I ever have had any issues with that in Cobol...

>
> My personal experience is that the national variants
> dropped out of mainstream IT during the 90's.
>
> So an application using those national variants should
> probably have been rewritten sometime in the mid 90's
> to use ISO-8859 (and rewritten again late 00's
> to use UTF-8).

I did write a document with a suggestion to change our
applications from 7-bit NRCS to 8-bit MCS (ISO-8859-1).
That was in 2008 and it was never done since the system
was planned for decomission in "3-4 years" anyway...

It's fine for the end-users (uses Attchmate Extra that
supports 7-bit NRCS) but we in the support uses Putty
and see the characters as Arne showed above. No big deal.

This is for the old VT-screen applications. For the new
web based apps, we use ISO-8859-1. We try to avoid UTF8.

[Jan-Erik Söderholm]

Den 2022-09-02 kl. 04:42, skrev Phillip Helbig (undress to reply):
> In article <631149a3$0$702$1472...@news.sunsite.dk>,
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:
>
>> First the background info about what this is all about
>> ------------------------------------------------------
>
> Good summary.
>
>> ANSI ASCII ~ ISO-646 ~ ECMA-6 is a character set going back to
>> the mid 60's. It only define 0-127 so it can work with 7 bit
>> comm.
>>
>> 128 character was not enough to cover all western languages,
>> so there were actually multiple mappings defined:
>>
>> ISO-646 for English
>> ISO-646-DK for Danish
>> ISO-646-SE for Swedish
>> etc.
>>
>> The differences was related to only a few characters.
>>
>> Most relevant for Danes and Swedes are:
>>
>> 0x5B 0x5C 0x5D 0x7B 0x7C 0x7D
>> ISO-646 [ \ ] { | }
>> ISO-646-DK Æ Ø Å Ê Þ å
>> ISO-646-SE Ä Ö Å À ö å
>>
>> (I hope those 8 byte characters goes through)
>
> I was going to ask "what 8-byte characters?" since I didn't see any when

> reading your post. Now, on a VT320 using NEWSRDR,...

Ah! Thanks Phillip! It is always welcome with a Friday-joke! :-)

[Arne Vajhøj]

On 9/1/2022 10:42 PM, Phillip Helbig (undress to reply) wrote:
> In article <631149a3$0$702$1472...@news.sunsite.dk>,
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:
>> Most relevant for Danes and Swedes are:
>>
>> 0x5B 0x5C 0x5D 0x7B 0x7C 0x7D
>> ISO-646 [ \ ] { | }
>> ISO-646-DK Æ Ø Å Ê Þ å
>> ISO-646-SE Ä Ö Å À ö å
>>
>> (I hope those 8 byte characters goes through)
>
> I was going to ask "what 8-byte characters?" since I didn't see any when
> reading your post.

8 bit ..............

:-)

> Now, on a VT320 using NEWSRDR, I see them when
> composing this post in EDT, but probably not as you intended me to see
> them.

They seem to have been UTF-8'ified or something now.

Arne

[Arne Vajhøj]

On 9/2/2022 4:54 AM, Jan-Erik Söderholm wrote:
> Den 2022-09-02 kl. 02:09, skrev Arne Vajhøj:
>> With the arrival of 8 bit character sets in the form
>> of DECMCS ~ ISO-8859 ~ ECMA-94 (~ CP-125x) in the mid 80's then
>> those national variants became obsolete.
>>
>> (which was a blessing for all programmers as the values
>> changed in the national variants are widely used in
>> programming languages !)
>
> I do not think I ever have had any issues with that in Cobol...

Cobol, Fortran and VMS Basic seems to work fine with
just ().

But a lot of languages (C, C++, Pascal, Ada, Java, Python,
PHP etc.) also use [] and/or {} in their syntax.

>> So an application using those national variants should
>> probably have been rewritten sometime in the mid 90's
>> to use ISO-8859 (and rewritten again late 00's
>> to use UTF-8).
>
> I did write a document with a suggestion to change our
> applications from 7-bit NRCS to 8-bit MCS (ISO-8859-1).
> That was in 2008 and it was never done since the system
> was planned for decomission in "3-4 years" anyway...

The wellknown:

$ write sys$output f$fao("This system will be gone by !SL",
f$cvtime(,,"YEAR") + 3)

syndrome.

:-)

Arne

[Jan-Erik Söderholm]

Correct. It has been "3-4 years" since I come there in 2006.
Apart from last year, when it changed to "at least 5 years"...

Realy hard to do any long-term planning for the systems.
We are still running on the same DS20e/666 systems that
I installed in May 2006.

[Phillip Helbig (undress to reply)]

In article <6311f61c$0$703$1472...@news.sunsite.dk>,
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:

> On 9/2/2022 4:54 AM, Jan-Erik Söderholm wrote:

> > Den 2022-09-02 kl. 02:09, skrev Arne VajhÞj:
> >> With the arrival of 8 bit character sets in the form
> >> of DECMCS ~ ISO-8859 ~ ECMA-94 (~ CP-125x) in the mid 80's then
> >> those national variants became obsolete.
> >>
> >> (which was a blessing for all programmers as the values
> >> changed in the national variants are widely used in
> >> programming languages !)
> >
> > I do not think I ever have had any issues with that in Cobol...
>

> Cobol, Fortran and VMS Basic seems to work fine with
> just ().
>
> But a lot of languages (C, C++, Pascal, Ada, Java, Python,
> PHP etc.) also use [] and/or {} in their syntax.

Modern Fortran can use [].

[Arne Vajhøj]

On 9/2/2022 8:30 AM, Jan-Erik Söderholm wrote:
> Den 2022-09-02 kl. 14:24, skrev Arne Vajhøj:
>> On 9/2/2022 4:54 AM, Jan-Erik Söderholm wrote:
>>> Den 2022-09-02 kl. 02:09, skrev Arne Vajhøj:
>>>> So an application using those national variants should
>>>> probably have been rewritten sometime in the mid 90's
>>>> to use ISO-8859 (and rewritten again late 00's
>>>> to use UTF-8).
>>>
>>> I did write a document with a suggestion to change our
>>> applications from 7-bit NRCS to 8-bit MCS (ISO-8859-1).
>>> That was in 2008 and it was never done since the system
>>> was planned for decomission in "3-4 years" anyway...
>>
>> The wellknown:
>>
>> $ write sys$output f$fao("This system will be gone by !SL",
>> f$cvtime(,,"YEAR") + 3)
>>
>> syndrome.
>>
>> :-)
>

> Correct. It has been "3-4 years" since I come there in 2006.
> Apart from last year, when it changed to "at least 5 years"...

They are softening up.

:-)

> Realy hard to do any long-term planning for the systems.
> We are still running on the same DS20e/666 systems that
> I installed in May 2006.

Maybe they would consider VMS x64-64 running on ESXi
VM's.

Assuming the company already runs dozens/hundreds/thousands
of ESXi VM's, then it could make sense.

Arne

[Jan-Erik Söderholm]

That sure is an option. There is a large VM environmen...

[Simon Clubley]

On 2022-09-01, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
> Den 2022-09-01 kl. 21:06, skrev Johnny Billquist:
>> On 2022-09-01 20:04, Simon Clubley wrote:
>>> On 2022-08-31, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>>>>
>>>> Sure. But Reflection was still "better"... :-)
>>>>
>>>> Putty lacks the 7-bit national character sets.
>>>> Both Reflection and Extra can handle those.
>>>>
>>>
>>> But haven't we moved on from this in the same way as we have moved on
>>> from requiring DEC keyboards instead of PC keyboards to access VMS
>>> systems ?
>>>
>>> Shouldn't VMS systems be generating code sets that are compatible
>>> with how code systems work today, not how they worked 30+ years ago ?
>>>
>>> How do the Nordic special characters get represented in the 7-bit
>>> character sets anyway or do they use 8-bits for some of the characters ?
>
> Just read up a little.
>
> https://en.wikipedia.org/wiki/National_Replacement_Character_Set
>

Thank you.

Professionally, I've grown up with 8-bit character sets and then, later,
UTF-8, so seeing this earlier standard looks really weird and alien to me.

Having jogged my memory, about the only thing I can remember from my early
professional days was having to talk to some old (old at the time, not now)
printers by sending them '#' for the pound sign, but that was to do with
how you talked to the (old) printer.

The idea that the same 7-bit character position can mean different
things in adjacent countries (such as Norway and Sweden) is indeed a
very alien idea to me and that would mean a company operating in both
countries would have some serious data interchange issues.

>
> Jonny is of course completely right here.
> Simon is lacking knowledge the Nordic ASCII 7-bit chat sets.
>

You are quite right Jan-Erik. I'm used to the 8-bit way of thinking
and this is a very different mindset.

[Arne Vajhøj]

What about CDC Display code?

:-)

Hint: 6 bit! (well 6 or 6/12 bit)

Arne

[Simon Clubley]

On 2022-09-01, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
> First the background info about what this is all about
> ------------------------------------------------------
>
> ANSI ASCII ~ ISO-646 ~ ECMA-6 is a character set going back to
> the mid 60's. It only define 0-127 so it can work with 7 bit
> comm.
>
> 128 character was not enough to cover all western languages,
> so there were actually multiple mappings defined:
>
> ISO-646 for English
> ISO-646-DK for Danish
> ISO-646-SE for Swedish
> etc.
>
> The differences was related to only a few characters.
>
> Most relevant for Danes and Swedes are:
>
> 0x5B 0x5C 0x5D 0x7B 0x7C 0x7D
> ISO-646 [ \ ] { | }
> ISO-646-DK Æ Ø Å æ ø å
> ISO-646-SE Ä Ö Å ä ö å
>

[snip]

>
> So I am not surprised that there still exist VMS
> applications using national variants of ASCII.
>
> That is how the real world is.
>

Thank you for the detailed writeup Arne. As I have just told
Jan-Erik, it's a very different mindset to the one I am used to. :-)

Simon.

PS: I do now understand why this was done, but at the same time, for any
VMS systems still doing this, it could easily give the impression to people
not familiar with VMS of how once again "that VMS system is different from
all the other systems we use."

[Phillip Helbig (undress to reply)]

In article <tesv2l$2he8s$1...@dont-email.me>, Simon Clubley

<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> The idea that the same 7-bit character position can mean different
> things in adjacent countries (such as Norway and Sweden) is indeed a
> very alien idea to me and that would mean a company operating in both
> countries would have some serious data interchange issues.

My guess is that ä and ö had the same positions as æ and ø as they are
essentially the same letter.

Note that the Swedish alphabet ends with å ä ö and the Norwegian/Danish
with æ ø å. :-)

Hoping that my EDT-produced 8-bit characters make it through. :-)

[Arne Vajhøj]

On 9/2/2022 9:05 AM, Simon Clubley wrote:

> On 2022-09-01, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>> Just read up a little.
>>
>> https://en.wikipedia.org/wiki/National_Replacement_Character_Set

> Professionally, I've grown up with 8-bit character sets and then, later,
> UTF-8, so seeing this earlier standard looks really weird and alien to me.

> The idea that the same 7-bit character position can mean different
> things in adjacent countries (such as Norway and Sweden) is indeed a
> very alien idea to me and that would mean a company operating in both
> countries would have some serious data interchange issues.

ISO-8859 has the same basic issue. Multiple meanings of same
code - not per country like for ISO-646 but per region.

One country could be using ISO-8859-1 (western europe) and
the neighbor country could be using ISO-8859-2 (eastern europe).

Arne

[John Dallman]

In article <63120065$0$705$1472...@news.sunsite.dk>, ar...@vajhoej.dk

(Arne Vajhøj) wrote:

> What about CDC Display code?
>
> :-)
>
> Hint: 6 bit! (well 6 or 6/12 bit)

<https://en.wikipedia.org/wiki/CDC_display_code> That's ... well, it
looks insane to me, but I presume it was at least somewhat suited to the
needs of the time. I don't believe the 63- and 64-character variations
can ever have been a good idea, though.

John

[Johnny Billquist]

Very good point. There is nothing old/weird here. ISO-646 is no
different than ISO-8859 really. Same value can mean different things,
depending on which character set we're talking about.

And as someone mentioned UTF-8, they really need to understand that
UTF-8 is not a character encoding at all, but an encoding of large
values in 8-bit quantities. What they most likely mean is Unicode, which
actually is identical with ISO-8859-1 for the first 256 code points.

It's just that if you encode Unicode using UTF-8, then a character like
Ä becomes two bytes, yes. But the value is actually identical to the one
in ISO-8859-1.

And as far as data interchange issues goes, yes. It can be sortof a
problem if a text have a character that does not exist in another
character set. And there is no way to solve this properly. Same problem
with the different ISO-8859 character sets. This is one reason Unicode
was created. So that all characters would be possible to represent
uniquely. In my opinion Unicode sortof failed, though. Because they
instead fell into the trap of the same character ending up having
multiple code points because of typographic reasons, traditional
silliness, or just plain stupidity. (Unicode shouldn't really care about
typographic issues, but it sometimes do.)

Johnny

[Johnny Billquist]

On 2022-09-02 15:22, Phillip Helbig (undress to reply) wrote:
> In article <tesv2l$2he8s$1...@dont-email.me>, Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> The idea that the same 7-bit character position can mean different
>> things in adjacent countries (such as Norway and Sweden) is indeed a
>> very alien idea to me and that would mean a company operating in both
>> countries would have some serious data interchange issues.
>
> My guess is that ä and ö had the same positions as æ and ø as they are
> essentially the same letter.

I think/seem to remember they do.

> Note that the Swedish alphabet ends with å ä ö and the Norwegian/Danish
> with æ ø å. :-)

That is if we are talking about collating them, yes. However, in the
character table (Swedish) they are in the order ä ö å, which means that
when you want to collate words in Swedish with ISO-646-SE, you cannot go
by plain value. And that was annoying. And unfortunately, the wrong
order persisted in ISO-8859-1 as well.

And then we have German, which collate ä along with a, just to make the
whole international world even more messed up. :-)

> Hoping that my EDT-produced 8-bit characters make it through. :-)

They did.

Johnny

[Arne Vajhøj]

It sort of made sense as the CDC system at the time operated on 60 bit
entities (18 bit addresses of 60 bit words).

10 characters of 6 bits in a 60 bit word is manageable.

5-10 characters of 6/12 bits in a 60 bit word is somewhat manageable.

7.5 characters of 8 bit in a 60 bit word is not fun.

Arne

[Johnny Billquist]

On 2022-09-02 14:24, Arne Vajhøj wrote:
> On 9/2/2022 4:54 AM, Jan-Erik Söderholm wrote:
>> Den 2022-09-02 kl. 02:09, skrev Arne Vajhøj:
>>> With the arrival of 8 bit character sets in the form
>>> of DECMCS ~ ISO-8859 ~ ECMA-94 (~ CP-125x) in the mid 80's then
>>> those national variants became obsolete.
>>>
>>> (which was a blessing for all programmers as the values
>>> changed in the national variants are widely used in
>>> programming languages !)
>>
>> I do not think I ever have had any issues with that in Cobol...
>
> Cobol, Fortran and VMS Basic seems to work fine with
> just ().
>
> But a lot of languages (C, C++, Pascal, Ada, Java, Python,
> PHP etc.) also use [] and/or {} in their syntax.

Well, BASIC is really fond of $, which usually also gets replaced with
another character in these NRCS. ;-)

I'll leave it at that.

But I sortof half-fondly remember using RSTS/E in Sweden in the early
80s. Accounts were PPNs, enclosed in brackets. Also used for the
directory. I had Ä120,114Å. :-)

Johnny

[Johnny Billquist]

On 2022-09-02 15:16, Simon Clubley wrote:
> PS: I do now understand why this was done, but at the same time, for any
> VMS systems still doing this, it could easily give the impression to people
> not familiar with VMS of how once again "that VMS system is different from
> all the other systems we use."

I can give you a program for Linux right now, that also expects
ISO-646-SE, in case you really insist on thinking that this has anything
to do with VMS.

Johnny

[Johnny Billquist]

Just waiting for someone to bring up the PDP-10 now. Bytes are of
variable length in the hardware, but 5 7-bit bytes in one word was
common, with just one wasted bit per word.
But again, 8-bit bytes would waste 4 bits per word...

Johnny

[Arne Vajhøj]

On 9/2/2022 10:48 AM, Johnny Billquist wrote:
> On 2022-09-02 14:24, Arne Vajhøj wrote:
>> On 9/2/2022 4:54 AM, Jan-Erik Söderholm wrote:
>>> Den 2022-09-02 kl. 02:09, skrev Arne Vajhøj:
>>>> With the arrival of 8 bit character sets in the form
>>>> of DECMCS ~ ISO-8859 ~ ECMA-94 (~ CP-125x) in the mid 80's then
>>>> those national variants became obsolete.
>>>>
>>>> (which was a blessing for all programmers as the values
>>>> changed in the national variants are widely used in
>>>> programming languages !)
>>>
>>> I do not think I ever have had any issues with that in Cobol...
>>
>> Cobol, Fortran and VMS Basic seems to work fine with
>> just ().
>>
>> But a lot of languages (C, C++, Pascal, Ada, Java, Python,
>> PHP etc.) also use [] and/or {} in their syntax.
>
> Well, BASIC is really fond of $, which usually also gets replaced with
> another character in these NRCS. ;-)
>
> I'll leave it at that.

True.

Typical:

¤

> But I sortof half-fondly remember using RSTS/E in Sweden in the early
> 80s. Accounts were PPNs, enclosed in brackets. Also used for the
> directory. I had Ä120,114Å. :-)

Did it allow <> instead of []?

Arne

[Dave Froble]

Back in the early 1970s I took a course in Cobol at University. Cobol on the
PDP-10 used 6 bit characters. 6 characters per 36 bit word.

There, you got your mention ...

:-)

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

On 2022-09-02, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 9/2/2022 9:05 AM, Simon Clubley wrote:
>> On 2022-09-01, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>>> Just read up a little.
>>>
>>> https://en.wikipedia.org/wiki/National_Replacement_Character_Set
>
>> Professionally, I've grown up with 8-bit character sets and then, later,
>> UTF-8, so seeing this earlier standard looks really weird and alien to me.
>
>> The idea that the same 7-bit character position can mean different
>> things in adjacent countries (such as Norway and Sweden) is indeed a
>> very alien idea to me and that would mean a company operating in both
>> countries would have some serious data interchange issues.
>
> ISO-8859 has the same basic issue. Multiple meanings of same
> code - not per country like for ISO-646 but per region.
>

That's a good point. OTOH, during all the time I have needed 8-bit
characters, I have never had to switch away from ISO-8859-1 so far
and from what I can tell, the several ISO-8859 variants I have just
looked at (1/2/4/9/10) appear to have common characters before 0x80.

BTW, https://en.wikipedia.org/wiki/ISO/IEC_8859-1#History contains an
amusing story about how the French delegate managed to screw up the
development of part of ISO-8859-1. :-)

[Phillip Helbig (undress to reply)]

In article <63120837$0$703$1472...@news.sunsite.dk>,

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> writes:

> On 9/2/2022 9:05 AM, Simon Clubley wrote:

> > On 2022-09-01, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
> >> Just read up a little.
> >>
> >> https://en.wikipedia.org/wiki/National_Replacement_Character_Set
>

> > Professionally, I've grown up with 8-bit character sets and then, later,
> > UTF-8, so seeing this earlier standard looks really weird and alien to me.
>

> > The idea that the same 7-bit character position can mean different
> > things in adjacent countries (such as Norway and Sweden) is indeed a
> > very alien idea to me and that would mean a company operating in both
> > countries would have some serious data interchange issues.
>

> ISO-8859 has the same basic issue. Multiple meanings of same
> code - not per country like for ISO-646 but per region.
>

> One country could be using ISO-8859-1 (western europe) and
> the neighbor country could be using ISO-8859-2 (eastern europe).

True, but ISO-8859-15 covers most Latin-alphabet languages.

[Phillip Helbig (undress to reply)]

In article <tet4ng$hpm$1...@news.misty.com>, Johnny Billquist
<b...@softjar.se> writes:

> And then we have German, which collate À along with a, just to make the
> whole international world even more messed up. :-)

>
> > Hoping that my EDT-produced 8-bit characters make it through. :-)
>

> They did.

Yours didn't. :-(

I guess that the above is ä. Yes, ä and a are sometimes collated, but
more often ä is collated before or after a or ae.

[Arne Vajhøj]

On 9/2/2022 2:00 PM, Simon Clubley wrote:
> On 2022-09-02, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 9/2/2022 9:05 AM, Simon Clubley wrote:
>>> The idea that the same 7-bit character position can mean different
>>> things in adjacent countries (such as Norway and Sweden) is indeed a
>>> very alien idea to me and that would mean a company operating in both
>>> countries would have some serious data interchange issues.
>>
>> ISO-8859 has the same basic issue. Multiple meanings of same
>> code - not per country like for ISO-646 but per region.
>>
>
> That's a good point. OTOH, during all the time I have needed 8-bit
> characters, I have never had to switch away from ISO-8859-1 so far
> and from what I can tell, the several ISO-8859 variants I have just
> looked at (1/2/4/9/10) appear to have common characters before 0x80.

Yes - that is still good old ASCII.

Arne

[Arne Vajhøj]

Strictly speaking ISO-8859-15 is still western Europe only.

It is basically the same as ISO-8859-1 with Euro sign
and a few other added.

The few other do include 4 eastern European letters, but it
is not a full replacement for ISO-8859-2.

Arne

[Johnny Billquist]

SIXBIT. Yay! That was popular at DEC for a while. Funny thing is that
SIXBIT was also used on PDP-8, but they choose to do it differently than
the PDP-10 for some reason. Just adding to the confusion.

(PDP-10 took the ASCII and subtracted 48 and then masked with 63, while
PDP-8 took the ASCII and masked it with 63, if I remember right.)

Johnny

[Johnny Billquist]

On 2022-09-02 21:01, Phillip Helbig (undress to reply) wrote:
> In article <tet4ng$hpm$1...@news.misty.com>, Johnny Billquist
> <b...@softjar.se> writes:
>
>> And then we have German, which collate À along with a, just to make the
>> whole international world even more messed up. :-)
>>
>>> Hoping that my EDT-produced 8-bit characters make it through. :-)
>>
>> They did.
>
> Yours didn't. :-(

I think your news reader can't deal with UTF-8. My post's headers say:

Content-Type: text/plain; charset=UTF-8; format=flowed

Yours say:

Content-Type: text/plain; charset=ISO-8859-15

So your newsreader probably tries to process everything it receives as
ISO-8859-15, and then my post turns out the way you see it.

> I guess that the above is ä. Yes, ä and a are sometimes collated, but
> more often ä is collated before or after a or ae.

Yeah. I was essentially saying that ä is considered a variant or
combination of a possibly followed by e in German, while in Swedish it
is a unique letter of its own, with its own place in the alphabet. No
relationship with a at all.

Johnny

[Johnny Billquist]

On 2022-09-02 16:58, Arne Vajhøj wrote:
> On 9/2/2022 10:48 AM, Johnny Billquist wrote:
>> On 2022-09-02 14:24, Arne Vajhøj wrote:
>>> On 9/2/2022 4:54 AM, Jan-Erik Söderholm wrote:
>>>> Den 2022-09-02 kl. 02:09, skrev Arne Vajhøj:
>>>>> With the arrival of 8 bit character sets in the form
>>>>> of DECMCS ~ ISO-8859 ~ ECMA-94 (~ CP-125x) in the mid 80's then
>>>>> those national variants became obsolete.
>>>>>
>>>>> (which was a blessing for all programmers as the values
>>>>> changed in the national variants are widely used in
>>>>> programming languages !)
>>>>
>>>> I do not think I ever have had any issues with that in Cobol...
>>>
>>> Cobol, Fortran and VMS Basic seems to work fine with
>>> just ().
>>>
>>> But a lot of languages (C, C++, Pascal, Ada, Java, Python,
>>> PHP etc.) also use [] and/or {} in their syntax.
>>
>> Well, BASIC is really fond of $, which usually also gets replaced with
>> another character in these NRCS. ;-)
>>
>> I'll leave it at that.
>
> True.
>
> Typical:
>
> ¤

Yeah. I think the official name is "currency symbol" or something like
that. People just said "sol" (Swedish for "sun").

>
>> But I sortof half-fondly remember using RSTS/E in Sweden in the early
>> 80s. Accounts were PPNs, enclosed in brackets. Also used for the
>> directory. I had Ä120,114Å. :-)
>
> Did it allow <> instead of []?

Nope. VMS and RSX have that, but RSTS/E didn't/don't.

Johnny

[Kerry Main]

Re: PDP8 .. a nice historical PDP8 and other early compute players perspective - I believe by Richard (Richie) Lary:
<http://sunsite.tus.ac.jp/pub/academic/computer-science/history/pdp-8/docs/WHAT-IS-A-PDP8>
<https://www.youtube.com/watch?v=lp2NSbJ2H1k>

Regards,

Kerry Main
Kerry dot main at starkgaming dot com







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

[Phillip Helbig (undress to reply)]

In article <tevcei$9eq$1...@news.misty.com>, Johnny Billquist

<b...@softjar.se> writes:

> I think your news reader can't deal with UTF-8. My post's headers say:
>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Yours say:
>
> Content-Type: text/plain; charset=ISO-8859-15
>
> So your newsreader probably tries to process everything it receives as
> ISO-8859-15, and then my post turns out the way you see it.

Right. I would be happy to install a UTF newsreader on VMS. :-|

> Yeah. I was essentially saying that ä is considered a variant or
> combination of a possibly followed by e in German, while in Swedish it
> is a unique letter of its own, with its own place in the alphabet. No
> relationship with a at all.

That is true today. Historically, it was borrowed from German.

Interestingly, when 8-bit characters are not available, Germans usually
write "ae" for "ä" and Swedes write "a".

[Kerry Main]

> -----Original Message-----
> From: Kerry Main <kemain...@gmail.com>
> Sent: September-03-22 10:15 AM
> To: 'comp.os.vms to email gateway' <info...@rbnsn.com>
> Subject: RE: [Info-vax] Micro Focus to be acquired by Open Text
>
> > -----Original Message-----
> > From: Info-vax <info-vax...@rbnsn.com> On Behalf Of Johnny
> > Billquist via Info-vax
> > Sent: September-03-22 7:58 AM
> > To: info...@rbnsn.com
> > Cc: Johnny Billquist <b...@softjar.se>
> > Subject: Re: [Info-vax] Micro Focus to be acquired by Open Text
> >

> Re: PDP8 .. a nice historical PDP8 and other early compute players
> perspective - I believe by Richard (Richie) Lary:
> <http://sunsite.tus.ac.jp/pub/academic/computer-science/history/pdp-
> 8/docs/WHAT-IS-A-PDP8>

Correction to above link:
<https://web.archive.org/web/20040825183612/http://sunsite.tus.ac.jp/pub/academic/computer-science/history/pdp-8/docs/WHAT-IS-A-PDP8>

Really good historical Richie Lary link on DEC, PDP8, VAX and VMS:

[Arne Vajhøj]

On 9/3/2022 7:12 AM, Johnny Billquist wrote:
> On 2022-09-02 16:58, Arne Vajhøj wrote:
>> On 9/2/2022 10:48 AM, Johnny Billquist wrote:
>>> On 2022-09-02 14:24, Arne Vajhøj wrote:
>>>> On 9/2/2022 4:54 AM, Jan-Erik Söderholm wrote:
>>>>> Den 2022-09-02 kl. 02:09, skrev Arne Vajhøj:
>>>>>> With the arrival of 8 bit character sets in the form
>>>>>> of DECMCS ~ ISO-8859 ~ ECMA-94 (~ CP-125x) in the mid 80's then
>>>>>> those national variants became obsolete.
>>>>>>
>>>>>> (which was a blessing for all programmers as the values
>>>>>> changed in the national variants are widely used in
>>>>>> programming languages !)
>>>>>
>>>>> I do not think I ever have had any issues with that in Cobol...
>>>>
>>>> Cobol, Fortran and VMS Basic seems to work fine with
>>>> just ().
>>>>
>>>> But a lot of languages (C, C++, Pascal, Ada, Java, Python,
>>>> PHP etc.) also use [] and/or {} in their syntax.
>>>
>>> Well, BASIC is really fond of $, which usually also gets replaced
>>> with another character in these NRCS. ;-)
>>>
>>> I'll leave it at that.
>>
>> True.
>>
>> Typical:
>>
>> ¤
>
> Yeah. I think the official name is "currency symbol" or something like
> that. People just said "sol" (Swedish for "sun").

Thinking about it - the PHP programmers would also miss $.

:-)

>>> But I sortof half-fondly remember using RSTS/E in Sweden in the early
>>> 80s. Accounts were PPNs, enclosed in brackets. Also used for the
>>> directory. I had Ä120,114Å. :-)
>>
>> Did it allow <> instead of []?
>
> Nope. VMS and RSX have that, but RSTS/E didn't/don't.

I wonder whether the <> support was due to ISO-646-national.

Arne

[Jan-Erik Söderholm]

It might not have been the root cause, but on an Swedish keyboard
layout, typing <> is easier and faster then typing []...

I try to say to our programmers that it is fine to use <> for
their command line work, but to always use [] in command files
and when defining logical names.

I have seen some freeware utilities that fails on logicals
that uses <> in directory definitions.

[Dave Froble]

On 9/2/2022 10:48 AM, Johnny Billquist wrote:

> Well, BASIC is really fond of $, which usually also gets replaced with another
> character in these NRCS. ;-)
>
> I'll leave it at that.

Please don't. I'm curious, because I've not had the need to use "$" in Basic,
at least as far as I can remember, which these days might not be so far.

[Dave Froble]

On 9/3/2022 7:32 PM, Dave Froble wrote:
> On 9/2/2022 10:48 AM, Johnny Billquist wrote:
>
>> Well, BASIC is really fond of $, which usually also gets replaced with another
>> character in these NRCS. ;-)
>>
>> I'll leave it at that.
>
> Please don't. I'm curious, because I've not had the need to use "$" in Basic,
> at least as far as I can remember, which these days might not be so far.
>
>

Ok, forget that request. Somehow I totally forgot the "$" to denote a string
variable.

Basic can be rather fond of "%" also.

:-)

[Chris Townley]

On 04/09/2022 00:36, Dave Froble wrote:
> On 9/3/2022 7:32 PM, Dave Froble wrote:
>> On 9/2/2022 10:48 AM, Johnny Billquist wrote:
>>
>>> Well, BASIC is really fond of $, which usually also gets replaced
>>> with another
>>> character in these NRCS. ;-)
>>>
>>> I'll leave it at that.
>>
>> Please don't.  I'm curious, because I've not had the need to use "$"
>> in Basic,
>> at least as far as I can remember, which these days might not be so far.
>>
>>
>
> Ok, forget that request.  Somehow I totally forgot the "$" to denote a
> string variable.
>
> Basic can be rather fond of "%" also.
>
> :-)
>

I have never once used the $ in a string variable. Every program or
module I wrote in Basic (many thousands of them) started with:

OPTION TYPE = EXPLICIT

so all variables of whatever type were declared, and I never used those
suffixes

The $ is of course used in system and library calls

--
Chris

[Phillip Helbig (undress to reply)]

In article <tf0h5i$2r64k$1...@dont-email.me>,
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik....@telia.com>
writes:

> It might not have been the root cause, but on an Swedish keyboard
> layout, typing <> is easier and faster then typing []...
>
> I try to say to our programmers that it is fine to use <> for
> their command line work, but to always use [] in command files
> and when defining logical names.

I followed that rule when I used VMS from a PC keyboard. On the other
hand, since <> is used deep within VMS (check the output of INSTALL
LIST), I suspect that it will always work.

> I have seen some freeware utilities that fails on logicals
> that uses <> in directory definitions.

Yes. Well written utilities handle such cases, of course. :-)

[Johnny Billquist]

Indirectly maybe. But as far as I can remember, the direct reason why
VMS and RSX supports it was because at some point DEC made a decision to
start using it as directory/uic delimiters in all their OSes. But then
the decision was reversed. I don't know/remember the details now. But
the point is that TOPS-20 fully changed to using <> (not sure about
Tops-10), but VMS and RSX didn't. But they added the ability to use it,
since TOPS-20 systems did do the change, so you ended up in a situation
where both were accepted.

RSTS/E was sortof more on its own. Hardly even had proper DECnet back
then, and wasn't really in the midst of such discussions.

But the reason that the for a while decided that they should use <>
might have been because of ISO-646. I have no idea.

Johnny

[Johnny Billquist]

Even when you have fancy BASICs that have explicit variable
declarations, and ignoring system and library calls, you still have all
the string functions in BASIC which include $.

LEFT$, RIGHT$, MID$, STR$, SPACE$, STRING$, NUM$... The list goes on and
on...

Johnny

[Johnny Billquist]

On 2022-09-03 15:34, Phillip Helbig (undress to reply) wrote:
> In article <tevcei$9eq$1...@news.misty.com>, Johnny Billquist
> <b...@softjar.se> writes:
>
>> I think your news reader can't deal with UTF-8. My post's headers say:
>>
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>
>> Yours say:
>>
>> Content-Type: text/plain; charset=ISO-8859-15
>>
>> So your newsreader probably tries to process everything it receives as
>> ISO-8859-15, and then my post turns out the way you see it.
>
> Right. I would be happy to install a UTF newsreader on VMS. :-|

Ah. So that's where you're sitting. Yeah, then it all makes sense. :-)

>> Yeah. I was essentially saying that ä is considered a variant or
>> combination of a possibly followed by e in German, while in Swedish it
>> is a unique letter of its own, with its own place in the alphabet. No
>> relationship with a at all.
>
> That is true today. Historically, it was borrowed from German.

Who knows who borrowed from who, or if it was actually borrowed or just
grew out from the same sources. (Yes, I do find such implied claims of
ownership somewhat strange.)

> Interestingly, when 8-bit characters are not available, Germans usually
> write "ae" for "ä" and Swedes write "a".

True. And funny. I guess it's because since in Swedish, we never
consider ä to be just a different form of ae, it don't come naturally to
try to think, or write it as such. So the closest is to try and find
something that is visually close, and that leads to a.
Basically another effect of ä being a letter of its own.

johnny

[Single Stage to Orbit]

On Sun, 2022-09-04 at 13:07 +0200, Johnny Billquist wrote:
> > The $ is of course used in system and library calls
>
> Even when you have fancy BASICs that have explicit variable
> declarations, and ignoring system and library calls, you still have
> all the string functions in BASIC which include $.
>
> LEFT$, RIGHT$, MID$, STR$, SPACE$, STRING$, NUM$... The list goes on
> and on...

Latest VB.Net still has these, sans the '$' symbols. Hey, at least it
pays the bills and supports all the emulators I use :-D
--
Tactical Nuclear Kittens

[Arne Vajhøj]

On 9/4/2022 1:29 PM, Single Stage to Orbit wrote:
> On Sun, 2022-09-04 at 13:07 +0200, Johnny Billquist wrote:
>>> The $ is of course used in system and library calls
>>
>> Even when you have fancy BASICs that have explicit variable
>> declarations, and ignoring system and library calls, you still have
>> all the string functions in BASIC which include $.
>>
>> LEFT$, RIGHT$, MID$, STR$, SPACE$, STRING$, NUM$... The list goes on
>> and on...
>
> Latest VB.Net still has these, sans the '$' symbols.

It seems to have with $ as well.

Module Program
Sub Main()
Dim s As String = "ABC"
Console.WriteLine(Mid(s, 2, 1))
Console.WriteLine(Mid$(s, 2, 1))
Console.WriteLine(s.Substring(1, 1))
Console.ReadKey()
End Sub
End Module

outputs:

B
B
B

here.

Arne

[Single Stage to Orbit]

On Sun, 2022-09-04 at 14:54 -0400, Arne Vajhøj wrote:
> On 9/4/2022 1:29 PM, Single Stage to Orbit wrote:
> > On Sun, 2022-09-04 at 13:07 +0200, Johnny Billquist wrote:
> > > > The $ is of course used in system and library calls
> > >
> > > Even when you have fancy BASICs that have explicit variable
> > > declarations, and ignoring system and library calls, you still
> > > have
> > > all the string functions in BASIC which include $.
> > >
> > > LEFT$, RIGHT$, MID$, STR$, SPACE$, STRING$, NUM$... The list goes
> > > on
> > > and on...
> >
> > Latest VB.Net still has these, sans the '$' symbols.
>
> It seems to have with $ as well.

I hadn't realised it still supported the $ functions, I thought they
had been left behind with the demise of VB6. I absolutely hated VB6.
--
Tactical Nuclear Kittens

[Dave Froble]

With my experience in VAX Basic et;al, I was able to use VB6. I still haven't
figured out VB.net. Haven't tried too hard either.

[Arne Vajhøj]

On 9/4/2022 6:56 PM, Dave Froble wrote:
> On 9/4/2022 5:18 PM, Single Stage to Orbit wrote:
>> On Sun, 2022-09-04 at 14:54 -0400, Arne Vajhøj wrote:
>>> On 9/4/2022 1:29 PM, Single Stage to Orbit wrote:
>>>> On Sun, 2022-09-04 at 13:07 +0200, Johnny Billquist wrote:
>>>>> Even when you have fancy BASICs that have explicit variable
>>>>> declarations, and ignoring system and library calls, you still
>>>>> have
>>>>> all the string functions in BASIC which include $.
>>>>>
>>>>> LEFT$, RIGHT$, MID$, STR$, SPACE$, STRING$, NUM$... The list goes
>>>>> on
>>>>> and on...
>>>>
>>>> Latest VB.Net still has these, sans the '$' symbols.
>>>
>>> It seems to have with $ as well.
>>
>> I hadn't realised it still supported the $ functions, I thought they
>> had been left behind with the demise of VB6. I absolutely hated VB6.
>
> With my experience in VAX Basic et;al, I was able to use VB6.  I still
> haven't figured out VB.net.  Haven't tried too hard either.

The GUI part of VB6 is very different, but the language
itself is still very BASICish.

VB.NET language is way more different.

Some say that VB.NET is not Basic at all but C# with Basic keywords.

:-)

But the OOP, Generics and FP features make it very
far from traditional Basic.

Arne