In article <631149a3$0$702$14726298@news.sunsite.dk>,
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@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.

Den 2022-09-02 kl. 02:09, skrev Arne Vajhøj:
> On 9/1/2022 2:04 PM, Simon Clubley wrote:
>> On 2022-08-31, Jan-Erik Söderholm <jan-erik.soderholm@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
> ------------------------------------------------------

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

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

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.

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

Den 2022-09-02 kl. 04:42, skrev Phillip Helbig (undress to reply):
> In article <631149a3$0$702$14726298@news.sunsite.dk>,
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@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! :-)

On 9/1/2022 10:42 PM, Phillip Helbig (undress to reply) wrote:
> In article <631149a3$0$702$14726298@news.sunsite.dk>,
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@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

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

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

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.

In article <6311f61c$0$703$14726298@news.sunsite.dk>,
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@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 [].

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

Den 2022-09-02 kl. 14:42, skrev 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

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

On 2022-09-01, Jan-Erik Söderholm <jan-erik.soderholm@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.soderholm@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.

Simon.

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

On 9/2/2022 9:05 AM, Simon Clubley wrote:
> On 2022-09-01, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>> Den 2022-09-01 kl. 21:06, skrev Johnny Billquist:
>>> On 2022-09-01 20:04, Simon Clubley wrote:
>>>> 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.

What about CDC Display code?

:-)

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

Arne

On 2022-09-01, Arne Vajhøj <arne@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."

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

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

On 9/2/2022 9:05 AM, Simon Clubley wrote:
> On 2022-09-01, Jan-Erik Söderholm <jan-erik.soderholm@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

In article <63120065$0$705$14726298@news.sunsite.dk>, arne@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

On 2022-09-02 15:42, Arne Vajhøj wrote:
> On 9/2/2022 9:05 AM, Simon Clubley wrote:
>> On 2022-09-01, Jan-Erik Söderholm <jan-erik.soderholm@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).

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

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

On 9/2/2022 10:33 AM, John Dallman wrote:
> In article <63120065$0$705$14726298@news.sunsite.dk>, arne@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.

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

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

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

On 2022-09-02 16:45, Arne Vajhøj wrote:
> On 9/2/2022 10:33 AM, John Dallman wrote:
>> In article <63120065$0$705$14726298@news.sunsite.dk>, arne@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.
>
> 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.

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

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

On 9/2/2022 10:57 AM, Johnny Billquist wrote:
> On 2022-09-02 16:45, Arne Vajhøj wrote:
>> On 9/2/2022 10:33 AM, John Dallman wrote:
>>> In article <63120065$0$705$14726298@news.sunsite.dk>, arne@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.
>>
>> 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.
>
> 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

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: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2022-09-02, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 9/2/2022 9:05 AM, Simon Clubley wrote:
>> On 2022-09-01, Jan-Erik Söderholm <jan-erik.soderholm@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. :-)

Simon.

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

In article <63120837$0$703$14726298@news.sunsite.dk>,
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:

> On 9/2/2022 9:05 AM, Simon Clubley wrote:
> > On 2022-09-01, Jan-Erik Söderholm <jan-erik.soderholm@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.